[Sugar-devel] Minor update to Make Your Own Sugar Activities!
Tony Anderson
tony_anderson at usa.net
Fri Mar 17 21:24:32 EDT 2017
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
> <mailto: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 <mailto:godiard at gmail.com>> wrote:
>>
>> Have you tried Develop activity?
>>
>> http://activities.sugarlabs.org/en-US/sugar/addon/4058
>> <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 <mailto: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 <http://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 <mailto:tony_anderson at usa.net>>
>>> wrote:
>>>
>>> Hi, James
>>>
>>> If you go to activities.sugarlabs.org
>>> <http://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
>>>> <mailto:laura at somosazucar.org>> wrote:
>>>>
>>>>
>>>>
>>>> 2017-03-14 7:13 GMT-05:00 Walter Bender
>>>> <walter.bender at gmail.com
>>>> <mailto:walter.bender at gmail.com>>:
>>>>
>>>>
>>>>
>>>> On Tue, Mar 14, 2017 at 12:45 AM, Tony
>>>> Anderson <tony_anderson at usa.net
>>>> <mailto: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
>>>>> <http://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
>>>> <mailto:Sugar-devel at lists.sugarlabs.or>g
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Walter Bender
>>>> Sugar Labs
>>>> http://www.sugarlabs.org
>>>>
>>>>
>>>> _______________________________________________
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.or
>>>> <mailto:Sugar-devel at lists.sugarlabs.or>g
>>>> 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.or
>>>> <mailto:Sugar-devel at lists.sugarlabs.or>g
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> <mailto:Sugar-devel at lists.sugarlabs.org>
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>> _______________________________________________
>> Sugar-devel mailing list Sugar-devel at lists.sugarlabs.org
>> <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>>
>> --
>> photo
>> *Gonzalo Odiard* Lider de proyecto
>> tel.: <tel:tel.:+4210-7748>2081-6424 y 2082-0312 |
>> www.trinom.io <http://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
>> <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
> _______________________________________________ Sugar-devel
> mailing list Sugar-devel at lists.sugarlabs.org
> <mailto:Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-devel
> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170318/b236728b/attachment-0001.html>
More information about the Sugar-devel
mailing list