[Gsoc] Python export functionality for Turtle Blocks

[Walter Bender]

On Fri, May 3, 2013 at 4:12 AM, Marion Zepf <marion.zepf at gmail.com> wrote:

> 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?
>

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.)

-walter

>
> 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!
>>>
>>
>>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/gsoc/attachments/20130503/314d951b/attachment-0001.html>