[Sugar-devel] GSoC 2015: Interactive JavaScript Shell

Richa Sehgal richasehgal2908 at gmail.com
Wed Mar 18 23:26:35 EDT 2015


Dear mentors,

I have submitted my proposal on official GSoC site - Google Melange. It
would be good to have feedback from all the mentors so that I can improve
upon it and submit a great proposal for the final evaluation by the Sugar
community.

Thanks a lot for all your guidance and support,
Richa Sehgal

On Sat, Mar 14, 2015 at 7:43 PM, Tony Anderson <tony_anderson at usa.net>
wrote:

>  Hi, Sebastian
>
> You must remember that I am an old curmudgeon. For me, simplicity was
> programming in assembler as opposed to typing in octal code. I entered a
> more complex world with Fortran and Cobol, simplified by Basic. Programs
> for the IBM 1401 started at position 333 since the only operating system
> was a load button and the only debugging tool was a button that dumped
> memory contents to a printer. Every program we wrote was complete. Today,
> there are few programmers who have ever written anything more complicated
> that 'Hello World' as a complete program. Today, virtually all programming
> is 'own code' to a pre-existing program. I think that the phrase 'own code'
> is now part of a curmudgeon's history - in the day it meant a subroutine
> written to be used in an existing program.
>
> My main concern with full IDEs is that the user may not be able to write a
> real program to execute in a real environment. On the other hand, the
> beginning programmer shouldn't get bogged down in boilerplate. The
> programming languages have essentially no boilerplate (shebang?). It is a
> web page that requires a fixed skeleton. However, Richa's solution hides
> that from the user. It can't be completely hidden since the learner needs
> to know how to build a web page independently of the tool. This is covered
> by the Pocket HTML lessons.
>
> The Explore section of the School Server content is organized in the form
> of a course with units and lessons. Amazingly, it now includes not one, not
> two, but three programming languages: Python, Javascript, and Shell
> Scripting.  Javascript is intended to build on a knowledge of HTML and CSS
> although the text, Eloquent Javascript actually introduces Javascript as a
> programming language and connects it to the web only in the second part
> (the third introduces node.js). Incidentally, the course based on Eloquent
> Javascript provides a 'take no mercy' approach to introducing all of these
> essential programming concepts. I am sure it would not be available to our
> students without Richa's tool. Anyone who fully understands the concepts in
> this text is 'good to go' at any level of programming.
>
> The first prerequisite course, introduces the Terminal Activity, the file
> system, and the nano text editor. With this basis, the learner has a basis
> for saving programs and web pages as files and executing them from the
> command line (or displaying in the Browse activity with file:// and a
> path. The courses Terminal 1 and Terminal 2 (from William Shotts -
> http://linuxcommand.org/tlcl.php) continues into more on the shell and
> writing shell scripts.
>
> My curmudgeon past also included putting the programs from David Ahl's
> Basic Computer Games (http://atariarchives.org/basicgames/) on a
> Commodore 64.
> The first Python course from Al Sweigart's Invent Your Own Computer Games
> With Python (http://inventwithpython.com/) shows how to program similar
> text games in Python. The second Python course from Al Sweigart's Hacking
> Secret Ciphers With Python is also introductory and text-based but in the
> domain of cryptography. The
> third course also based on a book by Al Sweigart, Making Games with Python
> and Pygame, depends on the material covered in the first two courses.
>
> WIth regard to the proposed fourth Python course, you are right on target.
> However, the introduction to Pygame does not relate it to objects. An
> important goal to this course is to develop understanding of these
> essential programming concepts: programming to an event-driven environment
> and organizing a large program to be understood for ease of maintenance and
> debugging. An important corollary is learning to read programs written by
> others.
>
> I think that Hello World is a good starting point since the learners will
> have already built Hello World as a standalone program. This allows the
> discussion to focus on what is required to run it as a Sugar Activity. For
> example, despite the complex folder that is the HelloWorld activity,
> everything is boilerplate except the 'activity.info' and 'activity.svg'
> files. The 'HelloWorld' Python program is in activity.py file. There the
> actual label('Hello World') is one line as print 'Hello World!' is in the
> original. This presents the opportunity to explain the rest of the file in
> the Sugar context. This also gives a good incentive for the learner to
> convert the Toolbar code to a module
>
> The BlockParty activity has been a favorite (I like Tetris), but it
> demonstrates a technique to build the activiity as a standalone executable
> file (__main__) and yet have it called by the framework in the Sugar
> context. This, of course, is a valuable capability of Python.
>
> This can motivate the learner to learn how to make the Python programs
> from Swegart's texts into Sugar activities.
>
> One unavoidable boilerplate issue in this course is the difference between
> sugar and sugar3. Given the direction of later Sugar builds, this topic is
> inevitable. The course will also have to cover olpcgame as a wrapper to
> pygame.
>
> The course will also include challenges to work with and improve Sugar
> Activities from ASLO. One example is converting Toolbars to the new
> standard. Another is fixing activities with Hulahop to use webkit or
> WebKit. At a more difficult level, fix InfoSlice to access the wikipediae
> on the school server. One section of the course should be to build a
> 'collaborative' Sugar activity. For example, convert a two player game
> where both players play on the same XO to one where the players are on
> different XOs. I hope to show how to make a 'king of the hill activity'
> where the two players play the game and others watch. The loser becomes a
> watcher and the longest waiting watcher becomes the challenger.
>
> Tony
>
>
>
>
> On 03/15/2015 02:39 AM, Sebastian Silva wrote:
>
> I find this discussion very interesting.
>
> It is hard for me not to think of a full IDE like creature when thinking
> of the jsfiddle tool.
>
> Perhaps I'm failing to see exactly the point or the inteded "Use Case".
>
> On my side, as a self-taught-as-a-child programmer, I appreciate
> abstraction layers very much because they allow me to think of the actual
> thing I want to implement.
>
> What I do not appreciate is boilerplate code.
>
> To really understand Hello World activity, you must understand some basic
> concepts of Object Orientation, the notion of what is GTK, event-driven
> programming, etc.
>
> Even Hello Web carries a lot of boilerplate with it.
>
> In my humble opinion it's not so bad when the boilerplate code is not seen
> (i.e. part of the toolchain, or at least, in a template).
>
> Perhaps we've exhausted the discussion and it will come to a matter of the
> design chosen by the implementors for its first iteration.
>
> Perhaps it's a good time to remember our core design ideas: Simplicity,
> Collaboration, Reflection, and try to apply them to this design.
>
> Sounds like a fun project.
>
> Regards,
> Sebastian
>
>
> El 11/03/15 a las 00:34, Richa Sehgal escibió:
>
> Hi,
>
> Regarding inclusion of libraries such as Jquery, maybe we can let students
> create templates which we can save in their web folders. The objective is
> the following: As Tony mentioned, providing them with templates might not
> make them learn the basics, but essential parts of programming. For
> example, in my initial days of coding, I used Eclipse which started a new
> file in a nice template. During my first exam, I realized that I have
> forgotten the signature of the function main (the arguments type and number
> of arguments). Since then, for any new language that I pick up, I start
> from scratch. So what we can do is that students can create templates for
> shortcuts, but at least they would have some hands-on experience. This can
> then serve like what Sebastian mentions.
>
> As for the performance, after we develop the tool, we can do a performance
> benchmark and publish the numbers for different libraries, and CSS
> functionalities. These numbers can also be used by other developers as the
> basis for their algorithms, and we can see how to improve on them and also
> study how they change as XO and Sugar evolves.
>
> Thanks
> Richa
>
> On Tue, Mar 10, 2015 at 5:05 PM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Sebastian
>>
>> I am using Zim Desktop Wiki to reformat the book into digestible lessons
>> (actually done). This makes it all html. My plan is to put this on the
>> school server so that a
>> student can download a chapter to view locally while working on it. I
>> added a button to the Browse toolbar that displays a Journal object chooser
>> and then displays the selected Journal object  - a zip file which contains
>> the web site in a compressed folder.
>>
>> I also provide a prerequisite course introducting the Terminal Activity
>> and the nano editor. The model is that students would have a directory in
>> /home/olpc/Documents named web. This directory would be used to hold thier
>> web pages. At some point when they learn about links, they can set up a
>> main page with links to the others. All
>> of this is accessible from the Browse activity by
>> file:///home/olpc/Documents/web/index.html.
>>
>> The student should learn to add jquery by reference in the head of their
>> web page. The actual js files can be downloaded from the school server (or
>> installed with Sugar by usb stick). One problem with ide approaches is that
>> it hides some of what we are trying to have the students learn. For
>> example, I seriously considered using pippy to teach Python, but concluded
>> that it would hide how to save Python programs, how to make them
>> executable, and how to share them. In a course on making Sugar Activities,
>> pippy can actually export the python code in a Sugar Activity wrapper, but
>> what does the student learn about the construction of a Sugar Activity from
>> that? I would rather they begin with the HelloWorld Activity.
>>
>> I have used a localhost for years with no problem. Since switching from
>> Firefox to Webkit, I haven't been using it but primarily because I haven't
>> tried to implement the features that required it. I am not sure it will be
>> relevant at the intial web level. In any case, jquery did not cause any
>> performance problems on an XO1.
>>
>> As regards Webkit, my concern is that in the Browse Activity it does not
>> seem to support flexible boxes, the modern way to do web layout, and in
>> many ways the key to reponsive web design.
>>
>> Tony
>>
>>
>> On 03/10/2015 10:11 PM, Sebastian Silva wrote:
>>
>>>  El 10/03/15 a las 04:58, Tony Anderson escibió:
>>>
>>>> I am working on a course based on Pocket HTML
>>>> (http://www.goer.org/HTML/) which is available via CC. At the
>>>> javascript level, I think Eloquent Javascript would be a good base and
>>>> is also CC.
>>>>
>>> Hi Tony,
>>>
>>> This is wonderful. I have had my eye on that tutorial ever since I
>>> started to think about Web activities a long time ago.
>>>
>>> My first attempt at a Web Activity was called WebSDK and was an IDE for
>>> doing web apps [1].
>>> Those were old-style web apps, the ones that had a Python mini-server
>>> running in the background.
>>> I still consider this a good approach to access Python infrastructure
>>> from Javascript, but I'm not sure how (or if) the new Web API
>>> infrastructure has replaced this mechanism.
>>>
>>> I think, in any case, for a GSOC student working on dev tools for JS on
>>> Sugar, should consider the entire IDE scenario, not just the "fiddle"
>>> part. I.e. it should be possible to deploy a mini app (or content!) from
>>> this activity.
>>>
>>> About embedding JQuery and other libraries, I would favor a "Wizard"
>>> approach. I.E. a form that will allow you to have a basic project from a
>>> template (w/ or without optional toys such as Jquery). I like the
>>> hand-holding approach especially since low performance machines can't do
>>> multi-tasking very well (so looking up docs is not easy). Therefore a
>>> version of the JS tutorial that Tony referenced would be great to have
>>> embedded,  IMHO, or included somehow. (Tony do you have an offline copy?)
>>>
>>> In order to avoid slow pages on older machines, including XO, it should
>>> be super lightweight, i.e. utilizing as little CSS3, transformations,
>>> transparency, SVG rendering, and animation as possible. At least a
>>> couple of templates should be able to run on the XO1 without issues.
>>> Hopefully some profiling feedback would be shown inline during
>>> development (such as at least load time for the "fiddle").
>>>
>>> Also, there are wrappers for web activities for versions of Sugar that
>>> don't include the Web Activities framework. Maybe include those as
>>> options in the templates. Finally, a good editor goes a long way for a
>>> good development environment (I used Ace editor component and it ran
>>> well on XO1, back in the day).
>>>
>>> The way I think of this is that you should be able to develop something
>>> relatively basic without resorting to the Internet either for sensible
>>> libraries or their respective documentation. If done really well,
>>> perhaps we could even offer an alternative to Pippy and Develop?
>>>
>>> Finally, I don't think the Webkit or even old Firefox rendering engine
>>> are a severe limitation. It's not worse than targetting Internet
>>> Explorer 6 and most web developers had to do that only a couple of years
>>> ago. I suggest you download Firefox 3.6 (from like 10 years ago) as that
>>> is the rendering engine found on Sugar 0.94 and limit yourself by what
>>> it can do. I havben't looked for a reference browser for the Webkit1
>>> engines, except Browse itself. It would be good to find out what our
>>> current engine equivalent is and document it (along with more
>>> contributions) to http://developer.sugarlabs.org/
>>>
>>> Regards and good luck.
>>>
>>> [1] http://somosazucar.org/files/2011/07/WebSDK1.png
>>>        http://somosazucar.org/files/2011/07/WebSDK2.png
>>>  .
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150318/8e8781a7/attachment-0001.html>


More information about the Sugar-devel mailing list