[Gsoc] Python export functionality for Turtle Blocks

Walter Bender walter.bender at gmail.com
Sun Apr 28 23:18:25 EDT 2013


On Sun, Apr 28, 2013 at 7:36 PM, Marion Zepf <marion.zepf at gmail.com> wrote:

> 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'll write something up. Also, I've CC'd Raul, whom may be able to do the
same.


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

I think you should get the whole environment running both to experience TA
in the Sugar context (I think it is much nicer there) and to get a sense of
how all of the piece fit together (for example, I could imagine using the
TA Python output in the Python editor, Pippy, that comes with Sugar).

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

Sounds about right.

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

+1

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


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


More information about the GSoC mailing list