Sugar Labs - User contributions [en]

Summer of Code/2013/Turtle Blocks Python export project

2013-10-07T18:18:06Z

Marion Zepf: highlight link to final report

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

The summer is over, so I have written a '''[[Media:Final_Report_on_Turtle_Blocks_Python_export.pdf|final report]]''' on my project. It gives an overview of the task, my ideas and their implementation, as well as the final status of the project.

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
** August 26 – September 1 (1 week)
*** Introduce disjunctions of <code>Type</code>s, <code>ArgSlot</code>s, argument lists, and <code>Primitive</code>s.
*** Adjust the export functionality to the type system.
*** Start re-writing 'old' <code>Primitive</code>s to make use of the new type system.
*** Write new documentation about how to create a new block, including creating new <code>Primitive</code>s.
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Screen dimensions from the 'Presentation templates' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** Heaps from the 'Extra options' palette
** September 9 – September 15 (1 week)
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
*** Events and user input from the 'Sensors' palette
*** Sounds and sprites from the 'Media' palette
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-10-07T18:15:33Z

Marion Zepf: fix link to final report

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

The summer is over, so I have written a [[Media:Final_Report_on_Turtle_Blocks_Python_export.pdf|final report]] on my project. It gives an overview of the task, my ideas and their implementation, as well as the final status of the project.

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
** August 26 – September 1 (1 week)
*** Introduce disjunctions of <code>Type</code>s, <code>ArgSlot</code>s, argument lists, and <code>Primitive</code>s.
*** Adjust the export functionality to the type system.
*** Start re-writing 'old' <code>Primitive</code>s to make use of the new type system.
*** Write new documentation about how to create a new block, including creating new <code>Primitive</code>s.
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Screen dimensions from the 'Presentation templates' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** Heaps from the 'Extra options' palette
** September 9 – September 15 (1 week)
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
*** Events and user input from the 'Sensors' palette
*** Sounds and sprites from the 'Media' palette
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-10-07T18:14:28Z

Marion Zepf: link to final report

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

The summer is over, so I have written a [[File:Final_Report_on_Turtle_Blocks_Python_export.pdf|final report]] on my project. It gives an overview of the task, my ideas and their implementation, as well as the final status of the project.

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
** August 26 – September 1 (1 week)
*** Introduce disjunctions of <code>Type</code>s, <code>ArgSlot</code>s, argument lists, and <code>Primitive</code>s.
*** Adjust the export functionality to the type system.
*** Start re-writing 'old' <code>Primitive</code>s to make use of the new type system.
*** Write new documentation about how to create a new block, including creating new <code>Primitive</code>s.
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Screen dimensions from the 'Presentation templates' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** Heaps from the 'Extra options' palette
** September 9 – September 15 (1 week)
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
*** Events and user input from the 'Sensors' palette
*** Sounds and sprites from the 'Media' palette
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

File:Final Report on Turtle Blocks Python export.pdf

2013-10-07T17:09:36Z

Marion Zepf: Final report on the GSoC project "Turtle Blocks Python Export" by Marion Zepf

Final report on the GSoC project "Turtle Blocks Python Export" by Marion Zepf

Summer of Code/2013/Turtle Blocks Python export project

2013-09-24T13:15:34Z

Marion Zepf: update timeline

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
** August 26 – September 1 (1 week)
*** Introduce disjunctions of <code>Type</code>s, <code>ArgSlot</code>s, argument lists, and <code>Primitive</code>s.
*** Adjust the export functionality to the type system.
*** Start re-writing 'old' <code>Primitive</code>s to make use of the new type system.
*** Write new documentation about how to create a new block, including creating new <code>Primitive</code>s.
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Screen dimensions from the 'Presentation templates' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** Heaps from the 'Extra options' palette
** September 9 – September 15 (1 week)
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
*** Events and user input from the 'Sensors' palette
*** Sounds and sprites from the 'Media' palette
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-23T15:15:13Z

Marion Zepf: remove the footnotes in the timeline

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
*** Screen dimensions from the 'Presentation templates' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** August 26 – September 1 (1 week)
*** Heaps from the 'Extra options' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-23T15:12:49Z

Marion Zepf: describe the type-system branch in the gitorious repo

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

=== gsoc-python-export on gitorious ===

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. It contains the latest '''stable''', i.e. working, version of TurtleArt and the export tool.

The branch <code>type-system</code> contains some work-in-progress on the type system for <code>Primitive</code> objects that I am currently introducing. It's a major change that affects how blocks are executed and exported to ASTs. Therefore, this branch should be considered '''unstable''', i.e. there is no guarantee that things will work or even that you'll get useful error messages. As soon as the type system is fully established and everything works again, this branch will be merged back into <code>primitive-class</code>.

The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].

=== ta-python-export-dev on github ===

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** August 26 – September 1 (1 week)
*** Heaps from the 'Extra options' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-18T11:57:59Z

Marion Zepf: explain branches in the two repositories

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a repository called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] in the SugarLabs Gitorious system. If you would like to have a look at my latest progress, check out the <code>primitive-class</code> branch. (The <code>master</code> branch is only used for submitting merge requests to [https://git.sugarlabs.org/turtleart/mainline the main TurtleArt repository].)

Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub. There, the <code>master</code> branch is the most recent one.

== Timeline ==

The following timeline is being modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** August 26 – September 1 (1 week)
*** Heaps from the 'Extra options' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-16T14:46:52Z

Marion Zepf: timeline: squeeze in two new awesome ideas

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a <code>Primitive</code> for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Introduce strong typing to <code>Primitive</code>s.
*** Pass argument blocks to the functor as <code>Primitive</code> objects, not as ASTs or return values of a function call.
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** August 26 – September 1 (1 week)
*** Heaps from the 'Extra options' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-16T13:51:32Z

Marion Zepf: timeline: add tutorial on defining Prims; move external functions down a week

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Write a tutorial on how to define a Primitive for a new block, so other TA (plugin) developers can make their blocks exportable.
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Heaps from the 'Extra options' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** August 26 – September 1 (1 week)
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-02T20:26:06Z

Marion Zepf: decision: show status bar when running exported code

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Heaps from the 'Extra options' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.
* The status bar may be shown when the exported code is run, as is necessary and appropriate during execution.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-02T20:17:08Z

Marion Zepf: delay 'screen dimensions' (has low priority)

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Heaps from the 'Extra options' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?
* Should the status bar be shown when the exported code is run?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-02T20:15:59Z

Marion Zepf: formatting

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Heaps from the 'Extra options' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette
*** Presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette
*** Printing and loading blocks and palettes from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?
* Should the status bar be shown when the exported code is run?

Summer of Code/2013/Turtle Blocks Python export project

2013-08-02T20:14:17Z

Marion Zepf: update schedule

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works. Add <code>Primitive</code> objects for the first five blocks and the 'repeat' block.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs. Implement special handling for loop blocks when transforming them to ASTs. The sample program basics-square.ta can now be exported to python code.
* July 22 – July 28 (1 week): Introduce constant arguments to <code>Primitive</code> objects. Add a <code>Primitive</code> object for the 'forever' block.
* July 29 – August 2: The exported Python code now uses TurtleArt's internal execution engine. This makes infinite loops executable and enables the user to watch the program run. Add a <code>Primitive</code> object for the 'clean' block. Implement nice error handling when exporting a project and when running the exported code.
* Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to a few blocks (those that have a <code>Primitive</code> object), but it can easily be extended to cover the rest.

* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** The complete 'Pen' palette
*** Boolean operations from the 'Numeric operators' palette
*** The rest of the loops from the 'Flow operators' palette
*** Conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** The complete 'Pen colors' palette
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Variables from the 'Action stacks' palette
*** Action stacks (functions) from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Heaps from the 'Extra options' palette
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?
* Should the status bar be shown when the exported code is run?

Summer of Code/2013/Turtle Blocks Python export project

2013-07-11T21:51:31Z

Marion Zepf: update decisions; move deferred ones to new Deferred section

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).
* All blocks (including the ones introduced by plugins) reference a <code>Primitive</code> object, which can be called to execute the block in TA, or transformed into a Python AST.
** Type conversion and other modification of the arguments of a block is done by ''slot wrappers''. A slot wrapper is a <code>Primitive</code> that is attached to the argument of another <code>Primitive</code>. Slot wrappers are called/ transformed before the <code>Primitive</code> itself.

=== Pending ===

The following design issues have yet to be decided:

=== Deferred ===

The following design issues have not yet been decided, but are being deferred due to their low priority:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)?
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?
* Should the status bar be shown when the exported code is run?

Summer of Code/2013/Turtle Blocks Python export project

2013-07-11T21:43:23Z

Marion Zepf: add details to timeline

This page tracks the progress of [[User:Marion Zepf|Marion Zepf]]'s GSoC project, "Turtle Blocks Python export." An abstract and a motivational statement can be found on the [[Summer of Code/2013/Turtle Blocks Python export|project proposal]] page, along with other details.

The mentors for this project are [[User:Walter|Walter Bender]] and [http://wiki.laptop.org/go/User:Claudia_Urrea Claudia Urrea].

== Repositories ==

I develop my project in a branch called [https://git.sugarlabs.org/~mzepf/gsoc-python-export gsoc-python-export] on Gitorious. Design documents, sample code, etc. go into [https://github.com/outofthecave/ta-python-export-dev ta-python-export-dev] on GitHub.

== Timeline ==

The following timeline will be modified as the project evolves.

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'setxy', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
** July 1 – July 5 (1 week): Test the two Python code generators for suitability for my project. Develop a concept of how the blocks know what Python code they will be transformed into.
** July 6 – July 12 (1 week): Replace previous implementation of primitives (the backend of the blocks) with a class whose instances can be called to execute the block, or be transformed to a Python AST (class <code>Primitive</code>). Use the class in TA and make sure calling instances works.
** July 13 – July 21 (1 week): Work on transforming <code>Primitive</code> objects to Python ASTs.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

== Decisions ==

This section lists important design decisions.

* The generated Python code will setup a window without menus and palettes. It will only be a plain canvas. Turtles will be visible with their (default or custom) sprites because this is the only way to make sprites move in TA.
* Code in named stacks will be put into functions with the same name. Blocks appended to the 'start' block will be put into a function called <code>start()</code>. Unnamed stacks will also be put into extra functions with auto-generated names (e.g., <code>unnamed_stack_1()</code>).
* Run only the block stack that has a 'start' block at the top. If there is no 'start' block, notify the user, but don't execute unnamed stacks. (TA itself should show the same behavior.)
* Assume the generated code will be run in GNOME, but keep the <code>running_sugar</code> flag, so it can be ported to Sugar later.
* The path to the TA installation must be in the environment variable <code>PYTHONPATH</code>.
* Boxes and actions are stored in a dictionary in order to allow for arbitrary names (e.g., names that start with a number or names that are read from the content of a box).

=== Pending ===

The following design issues have yet to be decided:

* Enable the user to control the speed of execution (e.g., by setting a global <code>step_time</code>)? ''deferred on 2013-06-14''
** How to implement this? E.g., call a <code>wait(step_time)</code> function in between two steps?
* Should the status bar be shown when the exported code is run?
* Blocks introduced by plugins: Should the plugin provide info about how to transform its blocks into Python?
* How to handle type conversion between numbers and strings that is done implicitly in TA?
** E.g., resolve types when converting the code (possible?), and output the code specific to the type.

Summer of Code/2013/Turtle Blocks Python export project

2013-06-24T09:22:14Z

Marion Zepf: add pending decision re. type conversion

Summer of Code/2013/Turtle Blocks Python export project

2013-06-23T12:37:51Z

Marion Zepf: add pending decision on blocks introduced by plugins

Summer of Code/2013/Turtle Blocks Python export project

2013-06-23T09:48:37Z

Marion Zepf: add decisions on TA installation path, dictionary for boxes and actions

Summer of Code/2013/Turtle Blocks Python export project

2013-06-14T16:53:20Z

Marion Zepf: update decisions after meeting with Walter

Summer of Code/2013/Turtle Blocks Python export project

2013-06-14T15:12:22Z

Marion Zepf: add a decision on running unnamed stacks; defer the pending decision on the speed of execution

Summer of Code/2013/Turtle Blocks Python export project

2013-06-14T13:35:00Z

Marion Zepf: add a pending decision re speed of execution

Summer of Code/2013/Turtle Blocks Python export project

2013-06-14T10:51:10Z

Marion Zepf: add section on pending design decisions; add a pending decision

Summer of Code/2013/Turtle Blocks Python export project

2013-06-13T22:14:26Z

Marion Zepf: add decision to convert named and unnamed stacks to functions

Summer of Code/2013/Turtle Blocks Python export project

2013-06-13T18:57:53Z

Marion Zepf: design decision on which graphical elements to include in the output

User:Marion Zepf

2013-06-13T16:49:27Z

Marion Zepf: add contact information

I am a student who has been accepted for the Google Summer of Code 2013. I am working on the project "[[Summer of Code/2013/Turtle Blocks Python export project|Turtle Blocks Python export]]." Here are some related links:
* description of the project idea (as provided by the Sugar developer community): [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export functionality for TurtleBlocks]]
* my project proposal for the GSoC, which includes an abstract: [[Summer of Code/2013/Turtle Blocks Python export]]

== Contact Information and Profiles ==

* IRC: mzepf on FreeNode.net
* email: marion döt zepf ät gmail döt com
* GitHub: [https://github.com/outofthecave outofthecave]

Summer of Code/2013/Turtle Blocks Python export

2013-06-13T16:38:54Z

Marion Zepf: typo

My name is [[User:Marion Zepf|Marion Zepf]] and I have been accepted to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export functionality for TurtleBlocks]]. Please find my project proposal below. An up-to-date progress report on this project can be found on [[Summer of Code/2013/Turtle Blocks Python export project|its wiki page]].

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefited from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>

The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Background ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with analyzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everything into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

My project will also make Turtle Blocks more attractive for older learners (youths or adults). It allows them to learn the basic concepts of programming first, without having to hassle with the syntax of a text-based programming language. Once they have understood the basics, they can move on to learning the syntax of Python. This way, my project can help increase 'programming literacy' all over the world.

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export project

2013-06-13T16:36:09Z

Marion Zepf: add mentors, repositories, section for decisions

Summer of Code/2013/Turtle Blocks Python export project

2013-06-13T16:24:11Z

Marion Zepf: add timeline (copied from proposal page)

User:Marion Zepf

2013-06-13T16:20:54Z

Marion Zepf: add link to project progress page; state that I've been accepted for the GSoC

Summer of Code/2013/Turtle Blocks Python export

2013-06-13T16:13:59Z

Marion Zepf: add link to project progress page

My name is [[User:Marion Zepf|Marion Zepf]] and I have been accepted to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my project proposal below. An up-to-date progress report on this project can be found on [[Summer of Code/2013/Turtle Blocks Python export project|its wiki page]].

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefited from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>

The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Background ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with analyzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everything into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

My project will also make Turtle Blocks more attractive for older learners (youths or adults). It allows them to learn the basic concepts of programming first, without having to hassle with the syntax of a text-based programming language. Once they have understood the basics, they can move on to learning the syntax of Python. This way, my project can help increase 'programming literacy' all over the world.

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export project

2013-06-13T16:11:16Z

Marion Zepf: create page to track the progress of my GSoC project, "Turtle Blocks Python export"

Summer of Code/2013

2013-06-13T16:05:28Z

Marion Zepf: add link to the project progress page of Turtle Blocks Python export

[[Summer of Code/2013/Application|A draft copy of our application]]

The proposals were moved to http://wiki.sugarlabs.org/go/GSoC/2013/Proposals

= Approved Projects=

__TOC__

== Sugar Core ==

=== Sugar Framework for writing activity in full HTML5 ===

[[File:Sugarhtml5.png|300px]]

The objective is to develop a JavaScript framework allowing to write Sugar activities in full HTML5/JavaScript. The framework will expose to JavaScript an API to call Sugar features:
* Journal/Datastore,
* Collaboration/Telepathy,
* Toolbar handling,
* Sugar look&feel - for example via a CSS style sheet usable on HTML controls
* Access to Sugar settings (buddy name, colors, current language, ...),
* View source.
Like PhoneGap/Cordova, the framework will come with a template to develop and package easily a new HTML5 activity. A basic tutorial will be include too.
The work could be inspired by the work done with Enyo Framework in [http://booki.flossmanuals.net/make-your-own-sugar-activities/_draft/_v/1.0/developing-sugar-activities-using-html5/ 1]. By the way, the resulting framework should be JavaScript framework agnostic (no need for jQuery, Enyo, ...). More on this works [[HTML5 activities|here]].

''Mentor'': [mailto:lionel@olpc-france.org Lionel Laské]

''Co-Mentor'': Daniel Narvaez

Level: Advanced

Benefits to the Student: A chance to learn from touching almost every corner of an advanced system.

Benefits to the Community: We'll greatly expand the reach of the project by opening the door to JavaScript programmers. Plus it will force us to clean up our APIs.

Student: Suraj

Wiki:

=== Project sharing website ===

Create a Project Hosting Site similar to the Scratch website where kids can share the projects they have created using various Sugar Activities. The site should foster collaboration and sharing of projects. The Web Site should be built using a free web framework so that it can be installed at deployment sites. Some features include:

* Ability to engage and connect with friends and classmates using various Social Networking sites/techniques.
* Ability to post projects from various Sugar Activities (ex: Turtle Blocks, Etoys, Memorize, Physics, etc.)
* Separate landing pages for different audiences (kids, teachers, parents, etc.)
* Section to share kid created art from projects
* Ability for users to create galleries (of their own projects, favorite projects, subject specific topics, etc.)
* Ability to have “private classroom spaces”
* Tools to support community management of the site
* Multi-language support

''Contact'': [[User:MrSteve]]

''Co-mentor'': [[User:dogi]]

Level: Advanced

Benefits to the Student: Learn more about web services

Benefits to the Community: We need more mechanisms for sharing ideas and work. This is low-hanging fruit.

Student: Rahul Gaur

Wiki:

=== Implement help mechanism for activities using Mallard ===

[http://projectmallard.org/ Mallard] is a mark-up language that makes it easy to provide user help. It would be a nice feature to add Mallard-like help to activities, accessed through a mechanism similar to the view source mechanism. We need to sort through two issues: integration into Sugar and integration into our i18n / L10n system.

''Contact'': [[User:Walter]]

''Co-mentor'': [[User:Aneesh Dogra]]

''Co-mentor'': [[User:Francis]]

Student: Kalpa Welivitigoda

Wiki page: http://wiki.sugarlabs.org/go/GSoC/2013/MallardHelp

Level: Advanced

Benefits to the Student: Learn about lots of cool tools.

Benefits to the Community: Most of our help is in the wiki and in English. This will enable us to reach our users more directly and in their first language.

=== Social Sugar ===

Design and Develop GUI components that can help Sugar to reflect user's social interactions from external platforms. A perfect target can be the Group-View that shows user's friends and their shared activities [http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor#Groups], but it _could_ also show social information about these friends, IE social networks or sharing platforms publications. This would also give this zoom-level added value.

Community members are already working on the backend component to support this feature [http://lists.sugarlabs.org/archive/sugar-devel/2013-March/042055.html]. This is also a great opportunity to complement other GSoC-2013 proposals.

''Contact'': [[User:tch]]

Level: Intermediate

Benefits to the Student: (a) Learn about Sugar's core, UI Design and web services and (b) interact with community members and other GSoC participants.

Benefits to the Community: Social interaction is a key element in the learning process, therefore we should promote this.

Student: Akshit Khurana

Wiki:

== Sugar Activities ==

=== Python export functionality for Turtle Blocks ===

[[File:TurtleArt.svg]] [[File:Pippy.svg]]

A goal of Turtle Blocks is not just to get children programming, but to launch them out of block world into text-based languages where they can develop more sophisticated programs. While Turtle Blocks is written in Python and can be extended by importing Python modules, it currently exports only in its native block language and in Logo. For this project, we'd want to enable a Python export option so that programmers can take their Turtle projects and extend them into full-fledged Python projects. The hypothesis is that this would lead more children to grow their programming skills beyond simple block programs.

''Contact'': [[User:Walter]]

''Co-mentor'': Tony Forster

Level: Advanced

Benefits to the Student: Lots of good Python hacking involved

Benefits to the Community: We'll have a vehicle for studying whether or not we can bring students of programming from block worlds to text-based programming and debugging.

Student: Marion Zepf

Wiki: [[Summer of Code/2013/Turtle Blocks Python export project]]

=== Add recording to Music Keyboard activity ===

[[File:Music keyboard screenshot.png]]

Music Keyboard activity uses part of TamTamMini code to play sounds. Should be good add the capability of record the played sound.

Requires familiarity with Python.

''Contact'': [[User:Godiard]]

Level: Beginner

Benefits to the Student: Learn about python and music libraries (csound)

Benefits to the Community: More shared spaces for expression is aligned with our pedagogical goals.

'''More information ''' http://wiki.sugarlabs.org/go/Activities/MusicKeyboard

Student: Anna Rudkovskaya

Wiki:

=== ASL Open Video Chat ===

Open Video Chat is an Free/Open Source video conferencing activity for the XO laptop. This project was originally started in March 2010 with funding from the National Technical Institute for the Deaf in Rochester NY.

'''Focus'''

The primary focus of Open Video Chat is to provide streaming video at frame rates that are suitable for communicating with sign language. This ends up being somewhere between 20 and 30 frames per second.

'''Current Features'''
* 20 FPS video
* preview window
* text chat

'''Desired Features'''
*RTP protocol implementation
*faster frame rate (30+ FPS)
*audio
*higher resolution video

IRC
* The contributors of Open Video Chat frequent #rit-foss on freenode

''Contact'': [[User:decause]]

Level: Intermediate/Advanced

Benefits to the Student: Learn about gstreamer video pipelines. Learn about sugar networking stack and services (Telepathy). Learn about Python and Sugar UI.

Benefits to the Community: The Video/Text chat software is nearly complete (90%), it just needs to be ported to latest version of sugar and include new telepathy bindings.

Source Code: [https://github.com/FOSSRIT/Open-Video-chat Github Repository]
Activity Page: [http://activities.sugarlabs.org/en-US/sugar/addon/4305 A.SL.O]

Student: Casey DeLorme

Wiki:

== Infrastructure ==

=== Translation Server ===

Student: Erik Price

Wiki:

Summer of Code/2013/Turtle Blocks Python export

2013-05-03T11:55:18Z

Marion Zepf: corrected spelling

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefited from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>

The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Background ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with analyzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everything into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

My project will also make Turtle Blocks more attractive for older learners (youths or adults). It allows them to learn the basic concepts of programming first, without having to hassle with the syntax of a text-based programming language. Once they have understood the basics, they can move on to learning the syntax of Python. This way, my project can help increase 'programming literacy' all over the world.

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-03T11:50:48Z

Marion Zepf: +additional information

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>

The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with anaylzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

My project will also make Turtle Blocks more attractive for older learners (youths or adults). It allows them to learn the basic concepts of programming first, without having to hassle with the syntax of a text-based programming language. Once they have understood the basics, they can move on to learning the syntax of Python. This way, my project can help increase 'programming literacy' all over the world.

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-03T10:45:04Z

Marion Zepf: timeline: removing my notes

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>

The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" />
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with anaylzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-03T10:42:42Z

Marion Zepf: +abstract, +learning experience as a child

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== Abstract ==

Turtle Blocks teaches children an important skill in today's world: programming. Its block-based graphical interface makes abstract concepts like loops easy to understand and fun to play with. But it does not yet support the next step in learning: writing code in a 'real' programming language. My project fills this gap by automatically converting block programs to Python code. It enables the children to transfer their knowledge to a text-based language and to focus on acquiring the new syntax.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with anaylzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

When I looked out of my window, I could see a hill with houses on the top. I would often move my head around, especially up and down, to see how the position of the houses would change with respect to the window frame. It took me a long time, but I eventually figured out that I had to imagine a straight line going out from my eyes to the house I wanted to see. If that line was interrupted by the window frame, I could not see the house. By moving my head around, I would change the angle of the line and some previously hidden houses would become visible. From this experience I learned that I can figure out how things work just by taking a closer look at them and playing around with them.

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T20:55:35Z

Marion Zepf: grammar correction

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with anaylzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
Thus, the Sugar Labs community can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T20:53:35Z

Marion Zepf: +my background

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

I am a student of computational linguistics in my 6th semester.
I have three years of experience in writing Python programs of various kinds - from simple command line utilities to GUI applications (using pygame and tkinter) and code generators for Java code.
I also have strong competence in the object oriented programming paradigm.
Moreover, I am familiar with commonly used frameworks and tools like version control software (svn, git), the Eclipse IDE, and autotools.
I learn quickly, so I expect to acquire good skills in GTK before the start of the coding phase.

Through my linguistic education, I can draw on substantial experience with grammars, parsers, and syntax trees.
This experience will help me with anaylzing the block code and transforming it into Python code.

My interest in educational software was sparked during my work on [http://purl.org/icall/view VIEW] (Visual Input Enhancement of the Web), an online language tutoring system.
During the past two years, I have made many contributions to VIEW, including, for example, the automatic recognition of main content, headlines, and boilerplate on web pages.
I also improved the user interface of its browser toolbar, and decreased the server's response time by enabling multi-threading.

My working style is characterized by a high level of documentation, be it inline comments or commit messages.
I also keep my code modular, which makes it easy for others to build on my work.
This way, Sugar labs can profit ideally from my contribution, even after the end of the GSoC.

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T15:59:02Z

Marion Zepf: +what if I get stuck, +keeping the community informed

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

From experience I know that physical activity often helps me with getting rid of a thinking blockade. So, I will first take a short walk or do some household work to get fresh ideas into my head. If that does not help, I will suspend work on the feature that is causing the problem and work on a different feature in the meantime, until my mentor becomes available again.

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

I plan to document the progress of my work through commit messages in an online repository. When I am faced with an important design decision, I will discuss it with other developers on the mailing list or on IRC. In addition, I will set up a Wiki page to announce the outcomes of such decisions and to keep track of my timeline.

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T15:34:01Z

Marion Zepf: +Sugar pilot deployment

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

My old primary school has an immigrant rate of about 80%, and many kids are socially disadvantaged. This results in a big difference in learning speed between individual children in one class, which is problematic for traditional "chalk and talk" teaching methods. I think that Sugar would enable each child to learn at its own pace without feeling left out if they are slower than their classmates. Faster learners can easily move on to other activities when they are done and no longer disturb the lesson because they are bored.

In the first year, the school often faces the difficulty of teaching children who do not speak the class language (German). With its clean graphical interface and recognizable icons, Sugar could help these children understand the material without the need to translate everyhing into their mother language.

I can set up contact to the school and act as an interpreter if necessary.

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T15:05:16Z

Marion Zepf: +impact on the Sugar labs community

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

Many Sugar activities allow exporting the user's creations as a sound file, a picture, a video, or a simple text file, which can then be imported into other activities. In the case of this project, the user can export their block program to Python code and view, edit, and run it in the Pippy and Terminal activities. Combining several activities to create a single piece of work inspires users' creativity. Moreover, it makes Sugar a coherent system, rather than just an arbitrary collection of activities. Users will view it as a tool kit that helps them realize their ideas, no matter which forms they take. This unlimitedness is an important aspect of Sugar's quality, and thus it ensures continued interest in Sugar in the future.

[[User:Walter|Walter Bender]], mentor of this project: 
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.

[[User:Rgs|Raúl Gutiérrez Segalés]], Turtle Art contributor: 
In my mind, the big take away here is that we'll enable portability of
Turtle Art projects. Being able to translate TA internal
code into external languages (initially Python, eventually Javascript
perhaps, or others) will allow this fundamental learning activity to
reach other platforms and a much broader audience. The question we've
got in front of us is not if Sugar or Turtle Art belong in the Cloud;
it's just how fast can we get there. 
This project is a key step towards our goal of getting Sugar/Turtle
Art onto more hands.

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T14:07:50Z

Marion Zepf: added concrete dates to the timeline

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. Only cover the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. Deal with the other modules when implementing the corresponding blocks.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. Only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Implement transformations of the rest of the 'Turtle' palette, and the complete 'Pen' and 'Pen colors' palettes. (These should be similar enough to the first four blocks that they can be implemented quickly.)
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** August 3 – August 11 (1 week)
*** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
*** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** August 12 – August 18 (1 week)
*** Variables from the 'Action stacks' palette and heaps from the 'Extra options' palette
*** Loops from the 'Flow operators' palette and functions from the 'Action stacks' palette
** August 19 – August 25 (1 week)
*** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
*** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
** August 26 – September 1 (1 week)
*** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** September 2 – September 8 (1 week)
*** Events and user input from the 'Sensors' palette<ref name="requires-add-imports" group="note" />
*** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette<ref name="requires-add-imports" group="note" />
** September 9 – September 15 (1 week)
*** Multiple turtles and custom turtle shells from the 'Extra options' palette<ref name="requires-add-imports" group="note" />
*** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette:<ref name="requires-add-imports" group="note" /> These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.
* September 16 – September 23 (1 week): Test exporting different kinds of blocks in combination. Fix the last bugs. Clean up.

'''Notes'''
<references group="note">
<ref name="requires-add-imports">This may require importing additional modules from Turtle Blocks.</ref>
</references>

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-05-02T13:17:30Z

Marion Zepf: +timeline (preliminary)

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.
I plan to work on this project Thu-Sun, approximately from noon until midnight.

=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

* June 17 – June 30 (2 weeks): Determine what code needs to be shared by Turtle Blocks and the exported code. Restructure the modules to isolate this part, so it can easily be imported. This only covers the modules that are necessary to run blocks from the 'Turtle', 'Pen', and 'Pen colors' palettes. The other modules will be dealt with when the corresponding blocks are implemented.
* July 1 – July 21 (3 weeks): Implement the first transformations from blocks to Python code. This will only cover the following blocks from the 'Turtle' palette: 'forward', 'back', 'left', and 'right'. Make sure the exported code imports the correct modules from Turtle Blocks and can be run on the command line (or in Pippy). Keep the implementation modular, so more blocks can be added easily.
* July 22 – July 28 (1 week): Rest of the 'Turtle' palette, and complete 'Pen' and 'Pen colors' palettes. These should be similar enough to the first four blocks that they can be implemented quickly.
* July 29 – August 2: Midterm evaluation: Block programs can be exported to Python code that can be run outside of Turtle Blocks. The export functionality is limited to blocks from the 'Turtle', 'Pen', and 'Pen colors' palette, but it can easily be extended to cover the other blocks.
* August 3 – September 15 (6 weeks): Implement transformations of all other blocks to Python code:
** Numeric operations from the 'Numeric operators' palette and screen dimensions from the 'Presentation templates' palette
** Boolean operations from the 'Numeric operators' palette and conditionals from the 'Flow operators' palette
** Variables and functions from the 'Action stacks' palette
** Loops from the 'Flow operators' palette
** Heaps from the 'Extra options' palette
** Runtime control (e.g., exit, suspension) from the 'Flow operators' palette
** External functions (chr, int, mathematical function, tamyblock.py) from the 'Extra options' palette
** Comments from the 'Extra options' palette: This is especially difficult because Python's <code>ast</code> module does not support comments natively.
** Events and user input from the 'Sensors' palette
** Sounds and sprites from the 'Media' palette and presentation templates from the 'Presentation templates' palette
** Multiple turtles and custom turtle shells from the 'Extra options' palette
** Display management (hide/ show blocks, toggle full screen) from the 'Presentation templates' palette, and printing and loading blocks and palettes from the 'Extra options' palette: These are very specific to Turtle Blocks. We need further discussion how this should look in the output of the exported Python code.

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-04-30T23:22:19Z

Marion Zepf: +screenshot of my Sugar devel env

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.


=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

[[File:Marion-Zepf_devel-env-screenshot.png|400px|Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address.]]

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

File:Marion-Zepf devel-env-screenshot.png

2013-04-30T23:16:36Z

Marion Zepf: Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address, as required for the Google Summer of Code 2013.

Screenshot of Marion Zepf's development environment of Sugar with the 'restart' label replaced with her email address, as required for the Google Summer of Code 2013.

Summer of Code/2013/Turtle Blocks Python export

2013-04-30T08:37:42Z

Marion Zepf: t-shirt size, formatting

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.


=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''

=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''

=== What will you do if you get stuck on your project and your mentor isn't around? ===

=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''

=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''

S (female)

=== Describe a great learning experience you had as a child. ===

=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-04-29T14:42:13Z

Marion Zepf: +project description

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.


=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== Project description ===
''What is the name of your project? Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''

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

The Python export functionality will be implemented in pure Python, drawing on the internal block code interpreter of Turtle Blocks to convert the blocks to a representation of the program flow. I will then use the <code>ast</code> module<ref>http://docs.python.org/2.6/library/ast.html</ref> to build the Python syntax tree from this representation. In order to serialize the syntax tree to a string, which can then be written to a file, I plan to use either the <code>codegen</code> module<ref>http://dev.pocoo.org/hg/sandbox/file/b2aea937f5bb/ast/codegen.py</ref><ref>https://gist.github.com/mattbasta/791312</ref> or the <code>unparse</code> module.<ref>http://svn.python.org/view/python/trunk/Demo/parser/unparse.py?view=markup</ref>


The exported Python code will need to import a few classes from Turtle Blocks to set up a window etc. I will isolate these classes from the Turtle Blocks code, so it can easily be imported into the generated code.

=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''

=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''
=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''
=== What will you do if you get stuck on your project and your mentor isn't around? ===
=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''
=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''
=== Describe a great learning experience you had as a child. ===
=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

== References ==
<references />

Summer of Code/2013/Turtle Blocks Python export

2013-04-29T12:41:13Z

Marion Zepf: created page from application template; filled section About me

My name is [[User:Marion Zepf|Marion Zepf]] and I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please find my application below.

== About me ==

=== What is your name? ===
Marion Zepf

=== What is your email address? ===
[mailto:marion.zepf@gmail.com marion.zepf@gmail.com]

=== What is your Sugar Labs wiki username? ===
[[User:Marion Zepf|Marion Zepf]]

=== What is your IRC nickname? ===
I do not have a fixed nickname, but I try to use "mzepf" if it is available.

=== What is your primary language? ===
''(We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)''

My native language is German, but I am more comfortable in English when it comes to computers and programming.

=== Where are you located, and what hours do you tend to work? ===
''(We also try to match mentors by general time zone if possible.)''

I am located in Stuttgart and Tübingen, Germany. My time zone is Central European Summer Time (CEST) or UTC+02:00 during summer.



=== Have you participated in an open-source project before? ===
''If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?''

This is my first open-source project. In the past, I have benefitted from open-source software countless times. Now I want to give something back to the community.

== About my Project ==

=== What is the name of your project? ===
''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?''
=== What is the timeline for development of your project? ===
''The Summer of Code work period is June 17 - September 23; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (August 2); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.''
=== My Backround ===
''Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.''

== Me and the Community ==

=== Impact on the Sugar Labs community ===
''If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.''
=== Sugar pilot deployment ===
''Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?''
=== What will you do if you get stuck on your project and your mentor isn't around? ===
=== Keeping the community informed about problems and questions ===
''How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?''

== Miscellaneous ==

=== Screenshot of my Sugar development environment ===
''We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.''
=== What is your t-shirt size? ===
''(Yes, we know Google asks for this already; humor us.)''
=== Describe a great learning experience you had as a child. ===
=== Additional information ===
''Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?''

User:Marion Zepf

2013-04-29T12:15:22Z

Marion Zepf: linking to my proposal

I am a student applying for the Google Summer of Code 2013. I would like to work on the project [[Summer_of_Code/2013#Python_export_functionality_for_Turtle_Blocks|Python export funtionality for TurtleBlocks]]. Please have a look at the wiki page for my proposal: [[Summer of Code/2013/Turtle Blocks Python export]]