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

James Simmons nicestep at gmail.com
Sat Mar 18 17:11:53 EDT 2017


The code for the EPUB utility is here:


This is the repository I set up for *E-Book Enlightenment.* The relevant
files are:




You export your manuscript as HTML with the file name input.html, then run
genbook.sh. That creates a file named TOC.xhtml that you can import into
Sigil. You would then use the "Split At Markers" menu option to split this
file into one file per chapter. If you're handy with Sigil you can make a
fully formatted EPUB with just a few clicks of the mouse.

After I wrote my two OLPC manuals I got the bug to write a bunch of other
stuff. I had a typewritten rough draft of my days in the Hare Krishna
movement which I had written 30 years before, and I used the techniques I
researched in *E-Book Enlightenment* to do OCR on the pages, then revised
it for publication as *The Life And Times Of Bhakta Jim*. After that I
wrote a novel, then started a second one. I got pretty good at publishing
things as e-book and Create Space books, and it never occurred to me that I
knew things that other authors did not until I started corresponding with a
science fiction author in Canada and found out how much she was paying
people to do things I was doing for myself. That led me to write *Format
Your Own Damned Book*:


This has not sold a single copy.

James Simmons

On Fri, Mar 17, 2017 at 8:24 PM, Tony Anderson <tony_anderson at usa.net>

> Hi, James
> I think your code to convert html to epub could be useful. At the moment,
> my preferred scheme is to write tutorials using the Zim Wiki, then export
> them to html. However, epub files might be easier to download and to read
> with Browse. I have patched Browse so that it downloads pdf, epub, and
> plain/text files instead of streaming since the users do not have time in
> class to read them. BeautifulSoup is indeed a marvel. Much of the content
> on the school server comes from scraping websites (e.g. ASLO).
> I completely agree on the need to move beyond hello world (it is still the
> customary place to start). In the case of Python, Al Sweigart has written
> three books on programming for children (Invent Your Own Game in Python)
> and they have Creative Commons licenses. The style is to present a program
> and then to work through line by line explaining the code. With Pippy
> students can convert the examples to Sugar activities. Many of the programs
> are rewrites of Basic programs from David Ahl's Basic Computer Games.
> He has written a fourth book 'Automate the Boring Stuff with Python'.
> Sadly, the problem is how to relate these tasks with real tasks for
> students. One idea I would like to explore is to use Python to process
> Soccer records (such as World Cup). Rwanda follows the English Premier
> League very closely. Perhaps a program to update records with results of
> fixtures (games in Euro talk). The program could then try to predict who
> will survive group play or chances of a particular team reaching the
> finals. While not matching baseball for 'big data', world soccer has a lot
> including current ranks of national teams.
> One of my goals is to use projects to motivate learning in science,
> mathematics, language and other subjects. For example, at a conference I
> talked to a speaker about simple ways to get into computer vision. His
> professor assigned the task of putting the camera under a simple frame able
> to hold ping-pong balls. The camera is put underneath the frame and the
> program is to identify when a ping pong ball is in the frame and its color.
> Such a project is easy to understand, but far from trivial to program.
> Another possibility to go from lunar lander to an attempt to model the
> trajectory of a rocket. (My first computer application as an trainee was
> working with a range safety program to model what would happen if a rocket
> engine shut down prematurely and where would it land? ).
> Programmable robots represent a fertile opportunity to use computer vision
> and to learn the limitations of sensors and programming to meet real-time
> requirements.
> Possibly the most intriguing is to design a program which improves based
> on experience. I think this area is made more difficult by attempts to
> relate the algorithms to human learning. If you skip that discussion and
> get to how the program can change its behavior from experience,  it should
> be reachable. For example, could a program improve its ability to play the
> game of mastermind? Or could a program use computer vision to be able to
> play pong? (too processor intensive, but could get students into C and
> learning a lot about limitations in computer performance).
> As always, there is an incredible gap between what learners could uncover
> with the XO and Sugar and what is actually attempted. This is not helped by
> the current attempt to trivialize education (in computers it is often
> called ICT - a term which to me is like scraping one's fingernails on the
> blackboard).
> Tony
> On 03/17/2017 11:40 PM, James Simmons wrote:
> Tony,
> 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
> library).
> 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>
> wrote:
>> 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>
>> 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.or>Sugar-devel at lists.sugarlabs.org
>>>>>>>> <http://lists.sugarlabs.org/lis>http://lists.sugarlabs.org/lis
>>>>>>>> tinfo/sugar-devel
>>>>>>> --
>>>>>>> Walter Bender
>>>>>>> Sugar Labs
>>>>>>> <http://www.sugarlabs.org>http://www.sugarlabs.org
>>>>>>> _______________________________________________
>>>>>>> Sugar-devel mailing list
>>>>>>> <Sugar-devel at lists.sugarlabs.or>Sugar-devel at lists.sugarlabs.org
>>>>>>> <http://lists.sugarlabs.org/lis>http://lists.sugarlabs.org/lis
>>>>>>> tinfo/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.or>Sugar-devel at lists.sugarlabs.org
>>>>>> <http://lists.sugarlabs.org/lis>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/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/lis
>> tinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170318/a3820d0b/attachment-0001.html>

More information about the Sugar-devel mailing list