[Gsoc] Python export functionality for Turtle Blocks

[Marion Zepf]

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.

Thank you very much.
Marion


2013/4/30 Raúl Gutiérrez Segalés <rgs at itevenworks.net>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/gsoc/attachments/20130501/50d0275f/attachment-0001.html>