[Gsoc] Python export functionality for Turtle Blocks

[Raúl Gutiérrez Segalés]

Hi,

sorry for the late reply - I am very happy to help with this. Please
ping me on #sugar or mail me at will.

-rgs

On 28 April 2013 20:18, Walter Bender <walter.bender at gmail.com> wrote:
> 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