[Gsoc] Python export functionality for Turtle Blocks

[Marion Zepf]

Hi Walter,

Thank you for your help with the terminology.

You're right, a side-by-side view of blocks and python code is very
demanding, not just in terms of implementing it, but also during run time.
 We would have to capture every modification to either side and transform
the code back and forth a lot.  Probably I should leave that for a future
project.
But I will keep it in mind and regard the export funtionality as part of a
bigger project with this side-by-side view as its goal.  That gives me some
guidance for upcoming design decisions.

As I'm working on my project proposal, I came accross SugarLab's
application template:
http://www.google-melange.com/gsoc/org/google/gsoc2013/sugarlabs2013
Point 1 under "YOU AND THE COMMUNITY" asks for the impact of my project on
the SugarLabs community.  It says I should give my own answer plus two from
the community.  Would you mind giving me yours?  And how can I get other
community members to answer this question for me?  Shall I use this mailing
list or another, or IRC?

I would also like to know whether I need a full development environment of
Sugar set up, since I only work on one activity.  The template requires it
in point 1 under "Miscellaneous".

As a rough outline of my schedule, do you think the following is realistic
and in accordance with the requirements/ guidelines?
3 weeks: determine what code needs to be shared by TurtleArt and the
exported code, and restructure the modules to isolate this part
3 weeks: get first transformation from a block to python code working (only
for one or a few example blocks)
midterm evaluation
6 weeks: transformations of all other blocks to python code

Regarding the missing documentation, maybe I can fill some gaps while I get
familiar with the code before the coding phase starts.  I know that this is
harder to do once you are familiar with the code because then you suddenly
take lots of things for granted that would need to be explained.

Thank you.
Marion


2013/4/28 Walter Bender <walter.bender at gmail.com>

> On Sat, Apr 27, 2013 at 5:58 PM, Marion Zepf <marion.zepf at gmail.com>wrote:
>
>> Hi Walter,
>>
>> Sorry I always take so long to answer.  I'm planning to devote more time
>> to this project in the coming weeks.
>>
>
> No problem. I've been busy too.
>
>
>>
>> I think the code should run standalone, but it will require importing
>>> some modules from turtlebloicks. The idea would be to refactor turtleblocks
>>> to be able to use those same modules.
>>
>> I'm not sure I understand what you mean by "refactor turtleblocks".  Do
>> you mean the code that's necessary for running exported python code should
>> be put into an extra module for easy importing?  Then it could be shared by
>> the TurtleBlocks code and all exported code.
>>
>
> That is exactly what I had in mind. In part, I want to make the code
> easier to understand.
>
>
>>
>> Taking this a little farther, what do you expect users to do with the
>> exported code?  Of course, it's supposed to help them with the step from
>> block-based programming to writing code in a 'real' programming language.
>>  But how exactly does this export feature achieve that?
>>
>
> Not really sure. This is somewhat of an experiment.
>
>
>>  My guess would be that the kids would create some code using
>> TurtleBlocks, export it to python code, and have a look at it.  Then they
>> would go back to TurtleBlocks and modify their code to see how that changes
>> the python code.  This way, they would learn the connection between the
>> blocks and the python code step-by-step.  Do you think this is a realistic
>> learning scenario?  If so, I think a side-by-side view of blocks and python
>> code (with instant synchronization between the two) would be more helpful
>> than a simple export feature.
>>
>
> You may be correct. I have hesitated to go too far down this path because
> it is complex and inherently not very robust. That said, it is something we
> should consider.
>
> There are some other "debugging" options we should explore as well, such
> as single-stepping through the code, or running the code backwards. (I
> recently introduced the idea of break points to make debugging easier.)
>
>
>> I'm also slowly starting to understand the structure of the code and to
>> find out which parts are relevant to the project I want to do.  I'm a bit
>> confused about the terminology, though.  Could you please explain what
>> primitives, docks, and connections are?  I have already found out that the
>> 'name' attribute of a block specifies which prototype/ template block the
>> user picked from the toolbars to create this block.  But then I'm not sure
>> what the 'type' attribute stands for.  Do you have a dictionary or other
>> documentation of the terminology used in TurtleBlocks somewhere?
>>
>
> Other than the inline comments, I've not done a very good job of
> documenting the internal structure. (Something else we should add to the
> list.)
>
> primitives are the Python code associated with blocks
> docks and connections are the plumbing: where the blocks connect to one
> and another to constitute program flow. Connection 0 is always the way into
> a block; connection n is always the way out of a block. There may be
> additional (lateral) connections as well.
> type is used to distinguish between blocks that are part of a program from
> blocks that are used as prototypes (on the palettes) to make other blocks,
> or blocks in the trash.
>
> Hope that helps.
>
> -walter
>
>>
>> Thank you.
>> Marion
>>
>>
>> 2013/4/24 Walter Bender <walter.bender at gmail.com>
>>
>>>
>>>
>>>
>>> On Wed, Apr 24, 2013 at 10:43 AM, Marion Zepf <marion.zepf at gmail.com>wrote:
>>>
>>>> Hi Walter,
>>>>
>>>> Thank you for the tips.  I now have a development version of only
>>>> TurtleBlocks running in GNOME.
>>>>
>>>> I've also had a brief look at tabasics.py and talogo.py.  tabasics is
>>>> very easy to understand, but I'll probably take a little longer for talogo.
>>>>
>>>
>>> talogo is a bit complex.
>>>
>>>
>>>>  Can I ask you my beginner's questions while I go through it?
>>>>
>>>
>>> Sure.
>>>
>>>>
>>>> As for the purpose of the project, I was wondering where the generated
>>>> code is supposed to run.  Is it supposed to be self-contained, so it can be
>>>> run on other machines that don't have TurtleBlocks installed, or is it
>>>> supposed to run only in connection with TurtleBlocks?  If the latter is the
>>>> case, should people include the code via the tamyblock module and the
>>>> corresponding block, or do we also need conversion from python code back to
>>>> TurtleBlock internal code?
>>>>
>>>
>>> I think the code should run standalone, but it will require importing
>>> some modules from turtlebloicks. The idea would be to refactor turtleblocks
>>> to be able to use those same modules.
>>>
>>> regards.
>>>
>>> -walter
>>>
>>>
>>>>
>>>> Thank you.
>>>> Marion
>>>>
>>>>
>>>> 2013/4/21 Walter Bender <walter.bender at gmail.com>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 21, 2013 at 8:07 AM, Marion Zepf <marion.zepf at gmail.com>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> My name is Marion Zepf and I am interested in the project 'Python
>>>>>> export functionality for Turtle Blocks'.  Python is my favorite programming
>>>>>> language and I often teach programming or other computer skills to my
>>>>>> friends and family.  I think it is very important to teach programming to
>>>>>> children because it is a very important skill in today's world.  Children
>>>>>> are also very keen on playing around with the programming language, which
>>>>>> is very important for learning new features of it.  This is why I would
>>>>>> like to make the step from block-based programming to writing code easier
>>>>>> for them.
>>>>>>
>>>>>> My Background
>>>>>> I am a student of computational linguistics in my 6th semester.  I
>>>>>> taught myself Python programming before I went to university.  So, I have
>>>>>> three years of experience in writing Python programs of various kinds -
>>>>>> from simple command line utilities to GUI applications (using the pygame
>>>>>> and tkinter libraries) and code generators for Java code.  I also have
>>>>>> strong competence in the object oriented programming paradigm.  I am new to
>>>>>> Berkeley Logo, but I learn quickly, so I expect to acquire good Logo skills
>>>>>> in a few days.
>>>>>> This will be my first contribution to the open source community.
>>>>>>  However, I am familiar with commonly used frameworks and tools like
>>>>>> version control software (svn, git), Eclipse IDE, and autotools.
>>>>>> I have made myself familiar with the TurtleArt Activity in Sugar On A
>>>>>> Stick as well as in the Debian package 'turtleart'.
>>>>>>
>>>>>> Before I start writing my project proposal, I have a few questions
>>>>>> about this project:
>>>>>> (1) Which git repositories/ branches should I clone?  I have found a
>>>>>> list of repositories on
>>>>>> http://wiki.sugarlabs.org/go/Development_Team/Source_Code
>>>>>> but I am not sure which ones I need and how to fit them together.
>>>>>>
>>>>>
>>>>> You can try to get a Sugar environment running [1] or just clone
>>>>> Turtle Blocks itself [2] and run it in GNOME.
>>>>>
>>>>>
>>>>>> (2) I understand that TurtleArt is written in Python, but the code
>>>>>> that users generate by putting together the blocks is in a different,
>>>>>> internal language.  Is there documentation available for the syntax and
>>>>>> semantics of this language?
>>>>>>
>>>>>
>>>>> Not much to help with there.  There is an OK guide to creating blocks
>>>>> in tabasic.py. The internal parser is talogo.py
>>>>>
>>>>>>
>>>>>> Thank you.
>>>>>> Marion
>>>>>>
>>>>>> _______________________________________________
>>>>>> GSoC mailing list
>>>>>> GSoC at lists.sugarlabs.org
>>>>>> http://lists.sugarlabs.org/listinfo/gsoc
>>>>>>
>>>>>>
>>>>> regards.
>>>>>
>>>>> -walter
>>>>>
>>>>> [1] http://sugarlabs.org/~buildbot/docs/build.html
>>>>> [2] git.sugarlabs.org/turtleart
>>>>>
>>>>> --
>>>>> Walter Bender
>>>>> Sugar Labs
>>>>> http://www.sugarlabs.org
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>>
>>
>>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/gsoc/attachments/20130429/27d08336/attachment-0001.html>