[Gsoc] Python export functionality for Turtle Blocks

[Marion Zepf]

Hi Walter, hi Raúl,

I'm close to finished with my project proposal and I'll be submitting it
today.  Here is the link again:
http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export

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?

Marion


2013/5/2 Marion Zepf <marion.zepf at gmail.com>

> Hi Raúl,
>
> Thank you for your elaborate answer to my question.  That's an entirely
> new, and very interesting, perspective on the Python export functionality.
>
> In terms of the technical approach you suggest, I agree in principle
>> but I suspect there might be shortcuts that you might
>> want to test to get a faster feedback on how this shall look. I.e.:
>> instead of refactoring TA initially to allow it to run projects
>> from exported Python you might want to have a way of transforming the
>> Python code back to TA's internal DSL and run
>> that (this was actually Walter's idea, which I think should give you a
>> good start). Anyway, there's many ways to skin this Turtle :-)
>
> 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.
> 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.
>
> Marion
>
>
> 2013/5/1 Raúl Gutiérrez Segalés <rgs at itevenworks.net>
>
>> (re-sending - forgot to hit reply-all)
>>
>> Hi Marion,
>>
>> On 30 April 2013 17:13, Marion Zepf <marion.zepf at gmail.com> wrote:
>> > Hi Raúl,
>> >
>> > My name is Marion.  I am a student applying for the GSoC.  I would like
>> to
>> > work on a Python export feature for Turtle Blocks.  Here is a brief
>> > description of my project proposal:
>> >
>> > 'Turtle Blocks Python export' lets the user export their programming
>> project
>> > from the Turtle Blocks activity to a Python script. The generated Python
>> > code can be run outside of Turtle Blocks, for example from the command
>> line
>> > or in the Pippy IDE.
>> > This tool is designed for users who are already proficient Turtle Block
>> > programmers and want to move on to text-based programming. It helps them
>> > transfer their knowledge and skills from block-based to text-based
>> > programming, as they can see their own creations in a new programming
>> > language. Thus, they can focus on the new language rather than the
>> content
>> > of the program.
>> >
>> > You can find a more detailed description on
>> >
>> http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export
>> >
>> > One of the questions I have to answer for my application is, 'If your
>> > project is successfully completed, what will its impact be on the Sugar
>> Labs
>> > community?' I am required to include answers from the Sugar Labs
>> community.
>> > Walter has already given me his, and I would like to ask you for your
>> answer
>> > to this question.
>>
>> In my mind, the big take away here is that we'll enable portability of
>> Turtle Art projects. Being able to translate TA internal
>> code into external languages (initially Python, eventually Javascript
>> perhaps, or others) will allow this fundamental learning activity to
>> reach other platforms and a much broader audience. The question we've
>> got in front of us is not if Sugar or Turtle Art belong in the Cloud;
>> it's just how fast can we get there.
>>
>> This project is a key step towards our goal of getting Sugar/Turtle
>> Art onto more hands.
>>
>> In terms of the technical approach you suggest, I agree in principle
>> but I suspect there might be shortcuts that you might
>> want to test to get a faster feedback on how this shall look. I.e.:
>> instead of refactoring TA initially to allow it to run projects
>> from exported Python you might want to have a way of transforming the
>> Python code back to TA's internal DSL and run
>> that (this was actually Walter's idea, which I think should give you a
>> good start). Anyway, there's many ways to skin this Turtle :-)
>>
>> Have fun!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/gsoc/attachments/20130503/240e8ade/attachment.html>