[Gsoc] Python export functionality for Turtle Blocks
Walter Bender
walter.bender at gmail.com
Sat Apr 27 18:12:35 EDT 2013
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/20130427/f15f5ed2/attachment-0001.html>
More information about the GSoC
mailing list