[Sugar-devel] Minor update to Make Your Own Sugar Activities!

James Simmons nicestep at gmail.com
Fri Mar 17 11:40:11 EDT 2017


I strongly agree that students should be exposed to the command line and
learn all about Software Tools. The key, I think, is to give them fun
things to do that demonstrate the power of the command line. They need
something more interesting than Hello World and calculating the current
value of the thirty dollars used to buy Manhattan Island.

I've used Python and shell scripts to write a utility that converts a Word
or Libre Office document saved as HTML as an XHTML file that can be
converted into a nice EPUB using Sigil. I've got another utility that takes
an Instagram web page saved to the clipboard using Inspect Element in
Firefox and downloads all the images. (Both of these use the Beautiful Soup

Whenever a student has a tedious job to do he should think about how a
shell script and some Python might do it for him.

It sounds like you've been programming computers longer than I have. Where
I work they think I knew Charles Babbage personally.

James Simmons

On Thu, Mar 16, 2017 at 9:33 PM, Tony Anderson <tony_anderson at usa.net>

> Gonzalo,
> I did look at the activity. However, I think there is immense value in
> introducing learners to the Terminal activity and the nano text editor.
> Through the shell, Sugar users have access to the file system and to all of
> the power of the Unix programming environment.
> At the moment the tutorial shows learners how to run their program as a
> shell command (hello.py as hello in /usr/local/bin). It doesn't show how to
> interpret options and arguments, but that might be very instructive to
> develop understanding of how command line programs work. Probably, the
> tutorial should discuss pipes and how they work with programs implemented
> as filters. I still have the book - Kernighan and Pike, Unix Programming
> Environment.
> When James and I started programming, constructive learning (called
> on-the-job training) was the only way to learn to program. He is absolutely
> correct - in that era you learned to write the complete program. I still
> remember that IBM 1401 programs started at memory location 333 (after the
> last position used by the printer). Our notion of an IDE was to have the
> card punch near the computer (as I recall, a standard tray held 2000
> punched cards).
> There were libraries (punched card decks that could be added to programs)
> and own code procedures you could add to another program (e.g. a custom
> sort routine). There was even version control in punched cards (coding in
> cols 73-80) that enabled patches to be placed after a card deck that would
> overlay the earlier code at load time.
> Later, risc proponents were aghast that the Intel architecture segmented
> memory in 64kb segments, when at that time (8080) that was larger than the
> typical installed memory. The 64 in the Commodore 64 highlighted a design
> flaw in the Apple II that limited its memory capacity to 48kb. Apple's
> architects at the time couldn't imagine a personal computer with that much
> memory.
> I fondly remember mentoring a middle-school student who was programming
> the IBM 1620, a decimal machine. His only reference was the IBM system
> manual. So he programmed in machine language. I obtained an Assembler
> manual (Autocoder), but he was happy to continue programming with absolute
> addresses. One day he came with a problem. He had gotten an error: out of
> memory.  What to do - he then learned about overlays - the technique of the
> day. But how to you introduce overlays to a program written on punch cards
> using absolute addresses and machine language? Game over.
> In his book James talks about virtual memory beginning with the System
> 360. I would rather refer back to RPG on the 1401 which was an emulator for
> the IBM tab machines (IBM 407). It was often claimed that most of the
> cycles on the System 360 were used running RPG programs written to emulate
> tab programs (implemented by wires on a punchboard). This is an historical
> forerunner to our current effort to rewrite Sugar activities in javascript.
> Tony
> On 03/16/2017 11:24 PM, James Simmons wrote:
> Gonzalo,
> I looked at it maybe two years ago. I still lurk on the mailing lists for
> this project but I'm not actively developing anything, so my opinions may
> have passed their sell by date.
> James Simmons
> On Thu, Mar 16, 2017 at 6:33 AM, Gonzalo Odiard <godiard at gmail.com> wrote:
>> Have you tried Develop activity?
>> http://activities.sugarlabs.org/en-US/sugar/addon/4058
>> On Thu, Mar 16, 2017 at 12:32 AM, Tony Anderson < <tony_anderson at usa.net>
>> tony_anderson at usa.net> wrote:
>>> James,
>>> Sugar now provides in the Journal a link to the Documents directory.
>>> This, of course, has the problem that the display does not show
>>> subdirectories. I have toyed with the idea of having the tutorials use
>>> Sugar Commander and the excellent gedit activity instead of the shell and
>>> nano. However, at the end I believe that the Terminal activity is simple to
>>> use and that learners should become familiar with the file system through
>>> shell commands. The nano editor is easy to use.
>>> I think that a second round of tutorials introducing Sugar Commander,
>>> gedit, and git could be introduced for learners already familiar with shell
>>> commands and nano.
>>> Tony
>>> On 03/15/2017 10:49 PM, James Simmons wrote:
>>> Tony,
>>> I own an XO laptop from the first Give One Get One promotion, so I know
>>> what it can do. I've used the Terminal Activity and I wrote the Sugar
>>> Commander Activity because I thought that the original design of Sugar,
>>> which made your thumb drive look like the Journal, was not such a hot idea.
>>> In my opinion files and directories should look like files and directories
>>> and the Journal should look like the Journal. I know that some of the newer
>>> XO's can switch to a GNOME desktop.
>>> I never tried developing Activities on an XO because I never had to. It
>>> is definitely easier to do things the way I do it, and for someone living
>>> in the U.S. with reliable internet it's pretty cheap. I agree that this is
>>> not the case for all the students, or even most of them. It's a case of "to
>>> those who have, more shall be given."
>>> I had the same situation when I wrote *E-Book Enlightenment*. Free
>>> e-books in English are plentiful, other languages not so much. I had to
>>> write chapters on making e-books, figuring out what is in the public
>>> domain, photographing book pages, building a device to hold books in place
>>> for being photographed, doing optical character recognition, donating books
>>> to PG and archive.org, etc.
>>> Maybe MYOSA needs a chapter on using the XO for developing applications,
>>> installing Git and using it locally, etc. My own XO has been in a drawer
>>> for a couple of years.
>>> James Simmons
>>> On Wed, Mar 15, 2017 at 12:46 AM, Tony Anderson <
>>> <tony_anderson at usa.net>tony_anderson at usa.net> wrote:
>>>> Hi, James
>>>> If you go to activities.sugarlabs.org, you can register via the
>>>> register link at the top right. This is not registration for Sugarlabs but
>>>> for ASLO.
>>>> As I understand the github repository, access with the ability to
>>>> commit changes is closely held. The enables proposed changes to be vetted
>>>> before a commit.
>>>> However, the web page has a sign in link which gives limited access
>>>> (create pull requests and comment on them, for example). That same two-step
>>>> process is used for ASLO. The developer submits the change which puts it
>>>> into a sandbox pending review.
>>>> Actually Sugar has files, directories and a command shell (Terminal
>>>> activity). It is relatively easy to switch activities via the Frame. I say
>>>> this from several years of experience developing on the XO (easier than
>>>> using usb flash keys to move code to the XO to test). The fact that Browse
>>>> does not support flex and the unique XO screen makes testing on an XO
>>>> essential if that is the target.
>>>> The process of making changes via github to the Sugar core is certainly
>>>> reasonable. However, nothing in this procedure interferes with a developer
>>>> modifying and testing a change on an installed Sugar independently of the
>>>> internet. Access to the internet being needed only to submit the change.
>>>> The issue is not to use Sugar for everything, it is to use the
>>>> available computer for everything (XO). In general, the XO is the first
>>>> computer our users have used and, aside from an Android device, the only
>>>> computer available. While used desktops and laptops are available, the
>>>> $100+ funds are not available.
>>>> The 'current setup' you mention depends on ready access to the
>>>> internet, something not available for at least 2/3 of our users. It is a
>>>> strength of Sugar that the source code is immediately available to the user
>>>> without need of a repository (except access to activities not installed - a
>>>> need supplied by a schoolserver). This allows learners to get into
>>>> programming in a meaningful way using only what is installed on the XO.
>>>> Tony
>>>> On 03/14/2017 11:25 PM, James Simmons wrote:
>>>> All,
>>>> I only meant to make the manual actually tell where we currently put
>>>> our code repositories, without rewriting the whole chapter. (I had hoped
>>>> that a Google Code-In mentee might do that, but it didn't happen). The one
>>>> piece of information that is still lacking is how to have your account
>>>> added to the sugarlabs organization. That happened so long ago that I
>>>> forgot how it happened. If someone could remind me I'll add that
>>>> information to the note.
>>>> I haven't done any Sugar development in years but I do program
>>>> computers for a living and I use Git in my day job.
>>>> Sugar has some good Activities to teach programming, but I don't think
>>>> it is a great Activity development platform. For that you really need files
>>>> and directories and a command shell, the ability to run Sugar as more than
>>>> one user at a time, etc.
>>>> I understand the desire to use Sugar for everything, but I think it
>>>> would always get in the way. You wouldn't expect to be able to develop an
>>>> iphone app on an iphone, or at least I wouldn't.
>>>> If I wanted to teach Activity development to children I'd get some
>>>> reconditioned desktop computers and install Fedora and Sugar on them. I
>>>> have used nothing but reconditioned computers myself for years. It is
>>>> amazing to me what you can get reconditioned on Amazon and elsewhere for
>>>> around a hundred bucks. This is basically my price range for a "new"
>>>> computer, and for that I can get a Lenovo or other quality brand with more
>>>> than adequate disk space and memory. These computers are built for use in
>>>> offices and have many years of life left in them. In Fedora you can run
>>>> Sugar as a desktop environment as well as in a window. You can hook them up
>>>> to a TV or a projector (something I remember many people wanted to do with
>>>> the XO).
>>>> I don't see ASLO being separate from Git as a problem. I think of it
>>>> like the production environment at work. If it's good enough to use it goes
>>>> on ASLO. If not, it stays in Git, but I might push my code to the central
>>>> repository so others could fool around with it.
>>>> Part of teach a child programming should be teaching him good work
>>>> habits, and I think our current setup promotes that.
>>>> James Simmons
>>>> On Tue, Mar 14, 2017 at 9:28 AM, Laura Vargas < <laura at somosazucar.org>
>>>> laura at somosazucar.org> wrote:
>>>>> 2017-03-14 7:13 GMT-05:00 Walter Bender < <walter.bender at gmail.com>
>>>>> walter.bender at gmail.com>:
>>>>>> On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson <
>>>>>> <tony_anderson at usa.net>tony_anderson at usa.net> wrote:
>>>>>>> On 03/14/2017 12:03 PM, Alex Perez wrote:
>>>>>>> I would think ASLO could simply be made to inspect the contents of
>>>>>>> an activity, upon upload, (since it’s just a zip file), and look for the
>>>>>>> necessary string within activity.info, such that it could be
>>>>>>> displayed under a “details” section of an Activity, within ASLO.
>>>>>>> What I propose is that the ASLO page have a link to the github
>>>>>>> repository. See the attached screenshot which shows a link to home page. I
>>>>>>> would see this link being added here.
>>>>>> +1. But that can be done if (1) we include the repo path in the info
>>>>>> file and (2) do the work on ALSO to display it (I think alsroot was looking
>>>>>> into this).
>>>>> +1 to add the repository link field on ASLO.
>>>>> This is an example where we all agree that something needs to be done.
>>>>> Now, how do you propose we get it done?
>>>>>> You proposal has no bearing on where the repo is hosted, as it should
>>>>>> not.
>>>>>>> Tony
>>>>>>> _______________________________________________
>>>>>>> Sugar-devel mailing list
>>>>>>> <Sugar-devel at lists.sugarlabs.org>Sugar-devel at lists.sugarlabs.org
>>>>>>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>> --
>>>>>> Walter Bender
>>>>>> Sugar Labs
>>>>>> <http://www.sugarlabs.org>http://www.sugarlabs.org
>>>>>> _______________________________________________
>>>>>> Sugar-devel mailing list
>>>>>> <Sugar-devel at lists.sugarlabs.org>Sugar-devel at lists.sugarlabs.org
>>>>>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>> --
>>>>> Laura V.
>>>>> * I&D SomosAZUCAR.Org*
>>>>> “No paradox, no progress.”
>>>>> ~ Niels Bohr
>>>>> Happy Learning!
>>>>> _______________________________________________
>>>>> Sugar-devel mailing list
>>>>> <Sugar-devel at lists.sugarlabs.org>Sugar-devel at lists.sugarlabs.org
>>>>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>> _______________________________________________
>>> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>>> _______________________________________________ Sugar-devel mailing
>>> list Sugar-devel at lists.sugarlabs.org http://lists.sugarlabs.org/lis
>>> tinfo/sugar-devel
>> --
>> [image: photo]
>> *Gonzalo Odiard* Lider de proyecto
>> tel.:  <tel.:+4210-7748>2081-6424 y 2082-0312 | www.trinom.io    Av
>> Calchaqui 4936· 2do Piso. Quilmes
>> <http://www.facebook.com/trinomiosrl>
>> <https://www.linkedin.com/company/trinom-io>
>> _______________________________________________ Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org http://lists.sugarlabs.org/lis
>> tinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170317/66a19b9b/attachment-0001.html>

More information about the Sugar-devel mailing list