<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 3, 2013 at 4:12 AM, Marion Zepf <span dir="ltr"><<a href="mailto:marion.zepf@gmail.com" target="_blank">marion.zepf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Walter, hi Raúl,</div><div><br></div><div>I'm close to finished with my project proposal and I'll be submitting it today. Here is the link again:</div>
<div><a href="http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export" target="_blank">http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export</a><br>
</div><div><br></div><div>I was wondering how we should handle certain blocks that are very specific to the Turtle Blocks GUI in the exported code, e.g., show/ hide blocks, toggle fullscreen, load blocks/ palettes, print to the 'status bar', and change turtle shell. If we want them to work exactly as in Turtle Blocks, we need to import a lot more classes from the Turtle Blocks code into the exported code. That means that when users want to run the exported Python code on a machine that does not have Turtle Blocks installed, the user also needs to copy all the required Turtle Blocks modules to the other machine. (Thinking about this, we probably first have to decide whether and how we want to ensure that exported code can be run on other machines that don't have Turtle Blocks installed.) On the other hand, if we make these blocks have a different function in the exported code, that would confuse users. After all, the exported code is supposed to behave the same way as their block code. What are your thoughts on this?</div>
</div></blockquote><div><br></div><div>I'd ignore those blocks for the time being. Let's get the basics up and running and then we can think about which of these additional blocks adds value. (Once the user is comfortable with Python, they should be comfortable extending the block language themselves.)<br>
<br></div><div>-walter <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888">
<div><br></div><div class="gmail_extra">Marion</div></font></span><div><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/2 Marion Zepf <span dir="ltr"><<a href="mailto:marion.zepf@gmail.com" target="_blank">marion.zepf@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Raúl,<div><br></div><div>Thank you for your elaborate answer to my question. That's an entirely new, and very interesting, perspective on the Python export functionality.</div>
<div><div><br></div>
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In terms of the technical approach you suggest, I agree in principle<br>
but I suspect there might be shortcuts that you might<br>want to test to get a faster feedback on how this shall look. I.e.:<br>instead of refactoring TA initially to allow it to run projects<br>from exported Python you might want to have a way of transforming the<br>
Python code back to TA's internal DSL and run<br><span style="font-family:arial,sans-serif;font-size:12px">that (this was actually Walter's idea, which I think should give you a<br></span><span style="font-family:arial,sans-serif;font-size:12px">good start). Anyway, there's many ways to skin this Turtle :-)</span></blockquote>
</div></div><div>I agree that it is also desirable to be able to convert Python code back into TA's internal DSL. But I'm affraid that is a project of its own. I can imagine that we would run into problems when the Python code uses constructs that aren't supported in TA (e.g., classes, if I'm not mistaken). Maybe I can work on this after the GSoC.</div>
<div>My motivation was that the users should be able to run the exported Python code outside of TA, e.g., in Pippy. For this purpose, translating the Python code into TA's internal DSL is not an option because Pippy doesn't understand that language. This is why I chose to have the exported Python code import some classes from TA's code. Probably we won't even need that much refactoring to achieve this. The code seems pretty reasonably organized into modules.</div>
<span><font color="#888888">
<div><br></div><div>Marion</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/1 Raúl Gutiérrez Segalés <span dir="ltr"><<a href="mailto:rgs@itevenworks.net" target="_blank">rgs@itevenworks.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(re-sending - forgot to hit reply-all)<br>
<br>
Hi Marion,<br>
<div><br>
On 30 April 2013 17:13, Marion Zepf <<a href="mailto:marion.zepf@gmail.com" target="_blank">marion.zepf@gmail.com</a>> wrote:<br>
> Hi Raúl,<br>
><br>
> My name is Marion. I am a student applying for the GSoC. I would like to<br>
> work on a Python export feature for Turtle Blocks. Here is a brief<br>
> description of my project proposal:<br>
><br>
> 'Turtle Blocks Python export' lets the user export their programming project<br>
> from the Turtle Blocks activity to a Python script. The generated Python<br>
> code can be run outside of Turtle Blocks, for example from the command line<br>
> or in the Pippy IDE.<br>
> This tool is designed for users who are already proficient Turtle Block<br>
> programmers and want to move on to text-based programming. It helps them<br>
> transfer their knowledge and skills from block-based to text-based<br>
> programming, as they can see their own creations in a new programming<br>
> language. Thus, they can focus on the new language rather than the content<br>
> of the program.<br>
><br>
> You can find a more detailed description on<br>
> <a href="http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export" target="_blank">http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export</a><br>
><br>
> One of the questions I have to answer for my application is, 'If your<br>
> project is successfully completed, what will its impact be on the Sugar Labs<br>
> community?' I am required to include answers from the Sugar Labs community.<br>
> Walter has already given me his, and I would like to ask you for your answer<br>
> to this question.<br>
<br>
</div><div>In my mind, the big take away here is that we'll enable portability of<br>
Turtle Art projects. Being able to translate TA internal<br>
code into external languages (initially Python, eventually Javascript<br>
perhaps, or others) will allow this fundamental learning activity to<br>
reach other platforms and a much broader audience. The question we've<br>
got in front of us is not if Sugar or Turtle Art belong in the Cloud;<br>
it's just how fast can we get there.<br>
<br>
This project is a key step towards our goal of getting Sugar/Turtle<br>
Art onto more hands.<br>
<br>
In terms of the technical approach you suggest, I agree in principle<br>
but I suspect there might be shortcuts that you might<br>
want to test to get a faster feedback on how this shall look. I.e.:<br>
instead of refactoring TA initially to allow it to run projects<br>
from exported Python you might want to have a way of transforming the<br>
Python code back to TA's internal DSL and run<br>
</div>that (this was actually Walter's idea, which I think should give you a<br>
good start). Anyway, there's many ways to skin this Turtle :-)<br>
<br>
Have fun!<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Walter Bender<br>Sugar Labs<br><a href="http://www.sugarlabs.org">http://www.sugarlabs.org</a><br>
</div></div>