[Gsoc] Python export functionality for Turtle Blocks

[Marion Zepf]

Hi Walter,

Thank you for your help!  Your answer sounds very inspiring.

I've also been busy in the meantime, and I now have a working Sugar
development environment and I have started a Wiki page on my project:
http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export
It's not yet complete, but I've already filled in the project description.
 The rest will of course follow as soon as possible.

Marion


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

> Here's my blurb:
>
> The primary goal of Turtle Blocks is to engage children in programming,
> specifically the joy of debugging. But also to give them a sense of
> empowerment over the tools that they use. Hence Turtle Blocks (as opposed
> to its sister project Turtle Art) exposes the learner to as much of the
> system as possible, through sensor blocks, Python blocks, etc. At the same
> time, Turtle Blocks is not an end in of itself. The further goal is to
> encourage the learners to move beyond block-based projects and get
> acquainted with the more expressive text-based languages. This project is
> an experiment to determine if providing a Python version of the block-based
> programming environment might provide a stepping stone to making this
> transition. Until we implement Sugar itself as a Turtle Blocks project,
> this experiment is a worthwhile bet at turning Sugar users into Sugar
> developers.
>
> -walter
>
>
> 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 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
>>>
>>
>>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/gsoc/attachments/20130501/1953ea57/attachment-0001.html>