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

[Tony Anderson]

Hi, James

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 keys to move code to the XO to test). The fact that 
Browse does not support flex and the unique XO screen, programming for 
the XO requires testing on an XO.


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 wrong to 
send a message to our learners that they cannot participate unless they 
have ready access to the internet


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 > wrote:




2017-03-14 7:13 GMT-05:00 Walter Bender >:



On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson
> 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

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

[James Simmons]

Tony,

The code for the EPUB utility is here:

https://github.com/sugarlabs/ebooktools

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

striphtml.py

and

genbook.sh

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*:

https://www.amazon.com/Format-Your-Own-Damned-Book-ebook/dp/B06WP5N93F

This has not sold a single copy.

James Simmons


On Fri, Mar 17, 2017 at 8:24 PM, Tony Anderson 
wrote:

> 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 

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

[Tony Anderson]

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

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

[James Simmons]

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 
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  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_ander...@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 

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

[Tony Anderson]

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

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

[James Simmons]

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  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 
> 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 
>> 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:
>>>

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

[Tony Anderson]

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

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

[James Simmons]

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

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

[Tony Anderson]

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 > wrote:




2017-03-14 7:13 GMT-05:00 Walter Bender >:



On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson
> 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 

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

[James Simmons]

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  wrote:

>
>
> 2017-03-14 7:13 GMT-05:00 Walter Bender :
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson 
>> 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@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> 
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Laura V.
> * I SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Walter Bender]

On Tue, Mar 14, 2017 at 10:28 AM, Laura Vargas 
wrote:

>
>
> 2017-03-14 7:13 GMT-05:00 Walter Bender :
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson 
>> 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?
>

Maybe we can organize a sprint? I've added the repo to quite a few already.
But many many more to go.

>
>
>> You proposal has no bearing on where the repo is hosted, as it should
>> not.
>>
>>>
>>> Tony
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> 
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Laura V.
> * I SomosAZUCAR.Org*
>
> “No paradox, no progress.”
> ~ Niels Bohr
>
> Happy Learning!
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Laura Vargas]

2017-03-14 7:13 GMT-05:00 Walter Bender :

>
>
> On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson 
> 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@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> 
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Laura V.
* I SomosAZUCAR.Org*

“No paradox, no progress.”
~ Niels Bohr

Happy Learning!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Walter Bender]

On Tue, Mar 14, 2017 at 12:45 AM, Tony Anderson 
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). You proposal has no bearing on where the repo is hosted, as it
should not.

>
> Tony
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Tony Anderson]

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.


Tony
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Tony Anderson]

Hi, Walter

On 03/14/2017 11:02 AM, Alex Perez wrote:
ASLO is not a source code repository. It’s a convenience to end users. 
I know you think they should be one and the same, and in theory they 
could be, but I don’t necessarily see the benefit.


The source code repository for a Sugar activity is the activity bundle. 
ASLO is the source for Sugar activity bundles so it is, in that sense, a 
source code repository.


I don’t see a reason why ASLO couldn’t simply be a front-end, pointing 
to .xo activity files which are mirrored elsewhere (even HTTP-accessible 
via Git/GitHub, or via a global CDN). That said, there is some value in 
hosting the activities directly on ASLO. There is also some risk, since, 
if ASLO goes offline, so does access to all activities.


I don't think anyone cares where the ASLO link goes. Actually, mirrors 
of ASLO would be helpful.


However, a link to github is not a link to a bundle. It requires python 
setup.py dist_xo to create a bundle from github.


Now we have duplicate systems for developers: developer hub on ASLO and 
gaining access to the Sugarlabs github site.



Git can absolutely be used locally (with branches, tags, etc) without 
external access to the Internet. It was designed to be use this way. 
That said, I don’t see why Git needs to be a sugar activity. It just 
needs to be a dependency of the development-specific Sugar packages 
(RPM/deb/etc)


I assume by development specific you mean release specific.

i don't see a problem with git being a 'gnome' application in a sugar 
installation. Essentially, the developer needs to make a commit of the 
base activity which could be done with the directory in 
/home/olpc/Activities (in Ubuntu, the activity may be in 
/usr/share/sugar/activities; however, the user can copy to his own 
/home/myname/Activities). This would enable reversion to the previous 
commit in case a change breaks the activity.


If one wanted to update an activity, say TuxMath, now the first step 
would be to clone the repository not install the activity itself.


This is an incorrect assumption.

This illustrates the problem. Yes, one can install the activity and does 
not need to refer to the github repository. However, this assumes that 
the version in ASLO is the currently released version. The Browse and 
TuxMath activities on github are not available on ASLO, TuxMath is not 
distributed with 0.110. So a developer who starts with the ASLO version 
starts with one that is broken. I don't believe the ASLO version 
activity.info links to the github repository. (It hasn't been updated 
since 2010). Clone is probably the wrong word. I suspect the mechanism 
is to download the zip file and then run setup.py locally.


Tony

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Tony Anderson]

Hi, Walter and Alex

Alex, if you are referring to maintaining ASLO, +1.

My point was not about either gitorious or github but the fact that by 
design the source code for every activity (with some binary exceptions) 
is in the bundle.
It is always clear where the source is located, in the bundle. Frankly, 
I don't see either gitorious or github as relevant to Sugar activities. 
If we want to encourage learning about version control (a focus of a 
recent GSOC), we should find a way to deliver git with Sugar.


As I mentioned many months ago, the appropriate place for the link to 
the the github repository is ASLO. If the link were there, I could click 
on it immediately.


With the current scheme, to find out where the repository  is, I need to 
find the activity on ASLO, download, install (or unzip) it, use the 
Terminal activity and nano to display activity.info, and then get back 
on the internet to use the url. Alternatively, I could go to the 
github/Sugar labs site and scroll through up to seven screens to find it.


Tony

On 03/14/2017 11:02 AM, Alex Perez wrote:

Tony/Walter,

On Mar 13, 2017, at 7:28 PM, Walter Bender > wrote:


Tony,

Not sure I agree about your asserts regarding github vs gitroious.


Count me in here..


(1) the were/are many activities that were not hosted in gitorious 
long before we switched to github, so it wasn't obvious where to find 
the source repo *before* the switch. This is one of the reasons I 
started add the repo path to the activity.info 
 file.
(2) ALSO needs work and maintenance regardless of where the repos are 
hosted.


And it is incumbent upon Sugar Labs and the board to ensure that this 
happens, even if it requires you to spend actual money to make it happen.


-walter

On Mon, Mar 13, 2017 at 10:02 PM, Tony Anderson 
> wrote:


Hi James,

Your book is a wonder and should be much more actively promoted.
It is one of the major contributions of Sugar to constructive
learning.

I believe the use of git.sugarlabs.org
 and github are major steps backwards
from the original conception of Sugar activities as something
which users could develop and make available to the community.



Why do you believe this? It’s simply a convention for version control, 
one which millions of people understand, and does not preclude the use 
of the latter mechanism you describe. They are not mutually exclusive. 
Additionally, anyone can download a tarball/zip file of source code, 
or of a tagged release, from github, even if they have zero clue about 
how git works. Git is a convenience for *developers*



In the first place, the activity bundle contains the source code
that is actually being executed. Second, there is a simple
version system in activity.info . The
Developer Hub at activities.sugarlabs.org
 supplies an adequate means to
control maintenance activities (in the PR sense of having someone
monitor changes before releasing them for general use).



We do definitely need to expand upon the filtering abilities, to 
prevent, say, an x86-only activity from being installed on ARM, and 
vice versa.



If one wanted to update an activity, say TuxMath, now the first
step would be to clone the repository not install the activity
itself.



This is an incorrect assumption.



The ASLO site needs some work. Currently, the latest version is
not necessarily exposed (see Browse or TuxMath, for example). In
some cases, activities do not support Arm or use Hulahop and
there is no way to specify which versions of Sugar or its
platforms are supported. The availability of maintainers who know
the PhP implementation of ASLO is apparently dwindling. Perhaps
Sugar Labs could undertake to re-implement ASLO using Python
(Django, flask, ...) or javascript to broaden the base of
potential maintainers.





However, dependence on github creates a duplicate repository for
the source code. With 400+ activities, there is no mechanism in
github to make the activities visible. Currently it may require
searching 7 screens to find if an activity is there (unlike ASLO
which has an effective search capability).



ASLO is not a source code repository. It’s a convenience to end users. 
I know you think they should be one and the same, and in theory they 
could be, but I don’t necessarily see the benefit.



I am sympathetic to the desire to acquaint our users with git and
the concept of version control. However, this approach limits the
opportunity to those who have internet access (probably a
minority of our users).



I don’t see a reason why ASLO couldn’t simply be a front-end, pointing 
to .xo activity files which are mirrored elsewhere (even 

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

[Alex Perez]

Tony/Walter,

> On Mar 13, 2017, at 7:28 PM, Walter Bender  wrote:
> 
> Tony,
> 
> Not sure I agree about your asserts regarding github vs gitroious.

Count me in here..
> 
> (1) the were/are many activities that were not hosted in gitorious long 
> before we switched to github, so it wasn't obvious where to find the source 
> repo *before* the switch. This is one of the reasons I started add the repo 
> path to the activity.info  file.
> (2) ALSO needs work and maintenance regardless of where the repos are hosted.

And it is incumbent upon Sugar Labs and the board to ensure that this happens, 
even if it requires you to spend actual money to make it happen.
> 
> -walter
> 
> On Mon, Mar 13, 2017 at 10:02 PM, Tony Anderson  > wrote:
> Hi James,
> 
> Your book is a wonder and should be much more actively promoted. It is one of 
> the major contributions of Sugar to constructive learning.
> 
> I believe the use of git.sugarlabs.org  and github 
> are major steps backwards from the original conception of Sugar activities as 
> something which users could develop and make available to the community.

Why do you believe this? It’s simply a convention for version control, one 
which millions of people understand, and does not preclude the use of the 
latter mechanism you describe. They are not mutually exclusive. Additionally, 
anyone can download a tarball/zip file of source code, or of a tagged release, 
from github, even if they have zero clue about how git works. Git is a 
convenience for *developers*

> In the first place, the activity bundle contains the source code that is 
> actually being executed. Second, there is a simple version system in 
> activity.info . The Developer Hub at 
> activities.sugarlabs.org  supplies an 
> adequate means to control maintenance activities (in the PR sense of having 
> someone monitor changes before releasing them for general use). 

We do definitely need to expand upon the filtering abilities, to prevent, say, 
an x86-only activity from being installed on ARM, and vice versa.
> 
> If one wanted to update an activity, say TuxMath, now the first step would be 
> to clone the repository not install the activity itself. 

This is an incorrect assumption. 
> 
> The ASLO site needs some work. Currently, the latest version is not 
> necessarily exposed (see Browse or TuxMath, for example). In some cases, 
> activities do not support Arm or use Hulahop and there is no way to specify 
> which versions of Sugar or its platforms are supported. The availability of 
> maintainers who know the PhP implementation of ASLO is apparently dwindling. 
> Perhaps Sugar Labs could undertake to re-implement ASLO using Python (Django, 
> flask, ...) or javascript to broaden the base of potential maintainers. 

> 
> However, dependence on github creates a duplicate repository for the source 
> code. With 400+ activities, there is no mechanism in github to make the 
> activities visible. Currently it may require searching 7 screens to find if 
> an activity is there (unlike ASLO which has an effective search capability). 

ASLO is not a source code repository. It’s a convenience to end users. I know 
you think they should be one and the same, and in theory they could be, but I 
don’t necessarily see the benefit.
> 
> I am sympathetic to the desire to acquaint our users with git and the concept 
> of version control. However, this approach limits the opportunity to those 
> who have internet access (probably a minority of our users). 

I don’t see a reason why ASLO couldn’t simply be a front-end, pointing to .xo 
activity files which are mirrored elsewhere (even HTTP-accessible via 
Git/GitHub, or via a global CDN). That said, there is some value in hosting the 
activities directly on ASLO. There is also some risk, since, if ASLO goes 
offline, so does access to all activities.

> A more effective approach would be to determine how git could be installed in 
> Sugar ( a git activity?) so that it can be used. Your book could then be used 
> as a basis for helping our users learn to develop activities using 
> version-control. In this way version control can be used locally by the 
> developer prior to submitting an updated or new activity to ASLO (which may 
> well involve a visit to an internet cafe). 

Git can absolutely be used locally (with branches, tags, etc) without external 
access to the Internet. It was designed to be use this way. That said, I don’t 
see why Git needs to be a sugar activity. It just needs to be a dependency of 
the development-specific Sugar packages (RPM/deb/etc)
> 
> Tony
> 
> Tony
> 
> 
> On 03/14/2017 03:39 AM, James Simmons wrote:
>> All,
>> 
>> I have been neglecting the manual Make Your Own Sugar Activities! ever since 
>> I first wrote it. However, I did manage to make one 

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

[Walter Bender]

Tony,

Not sure I agree about your asserts regarding github vs gitroious.

(1) the were/are many activities that were not hosted in gitorious long
before we switched to github, so it wasn't obvious where to find the source
repo *before* the switch. This is one of the reasons I started add the repo
path to the activity.info file.
(2) ALSO needs work and maintenance regardless of where the repos are
hosted.

-walter

On Mon, Mar 13, 2017 at 10:02 PM, Tony Anderson 
wrote:

> Hi James,
>
> Your book is a wonder and should be much more actively promoted. It is one
> of the major contributions of Sugar to constructive learning.
>
> I believe the use of git.sugarlabs.org and github are major steps
> backwards from the original conception of Sugar activities as something
> which users could develop and make available to the community. In the first
> place, the activity bundle contains the source code that is actually being
> executed. Second, there is a simple version system in activity.info. The
> Developer Hub at activities.sugarlabs.org supplies an adequate means to
> control maintenance activities (in the PR sense of having someone monitor
> changes before releasing them for general use).
>
> If one wanted to update an activity, say TuxMath, now the first step would
> be to clone the repository not install the activity itself.
>
> The ASLO site needs some work. Currently, the latest version is not
> necessarily exposed (see Browse or TuxMath, for example). In some cases,
> activities do not support Arm or use Hulahop and there is no way to specify
> which versions of Sugar or its platforms are supported. The availability of
> maintainers who know the PhP implementation of ASLO is apparently
> dwindling. Perhaps Sugar Labs could undertake to re-implement ASLO using
> Python (Django, flask, ...) or javascript to broaden the base of potential
> maintainers.
>
> However, dependence on github creates a duplicate repository for the
> source code. With 400+ activities, there is no mechanism in github to make
> the activities visible. Currently it may require searching 7 screens to
> find if an activity is there (unlike ASLO which has an effective search
> capability).
>
> I am sympathetic to the desire to acquaint our users with git and the
> concept of version control. However, this approach limits the opportunity
> to those who have internet access (probably a minority of our users).
>
> A more effective approach would be to determine how git could be installed
> in Sugar ( a git activity?) so that it can be used. Your book could then be
> used as a basis for helping our users learn to develop activities using
> version-control. In this way version control can be used locally by the
> developer prior to submitting an updated or new activity to ASLO (which may
> well involve a visit to an internet cafe).
>
> Tony
>
> Tony
>
>
> On 03/14/2017 03:39 AM, James Simmons wrote:
>
> All,
>
> I have been neglecting the manual *Make Your Own Sugar Activities!* ever
> since I first wrote it. However, I did manage to make one needed update in
> the laziest way possible. Since Sugar Labs has moved away from
> git.sugarlabs.org in favor of GitHub since I wrote the version control
> chapter I have added the following note to that chapter:
>
> *Important Note*: When this chapter was written Sugar Labs was still
> using *git.sugarlabs.org * as its code
> repository. While this still exists, the preferred repository is now
> https://github.com/, using the *sugarlabs* organization. This chapter is
> still a reasonable introduction to using Git, but when you set up your
> project repository you should use the excellent instructions provided on
> GitHub instead of the Gitorious instructions provided here.
>
>
> I hope this helps in some way.
>
> James Simmons
>
>
>
> ___
> Sugar-devel mailing 
> listSugar-devel@lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Tony Anderson]

Hi James,

Your book is a wonder and should be much more actively promoted. It is 
one of the major contributions of Sugar to constructive learning.


I believe the use of git.sugarlabs.org and github are major steps 
backwards from the original conception of Sugar activities as something 
which users could develop and make available to the community. In the 
first place, the activity bundle contains the source code that is 
actually being executed. Second, there is a simple version system in 
activity.info. The Developer Hub at activities.sugarlabs.org supplies an 
adequate means to control maintenance activities (in the PR sense of 
having someone monitor changes before releasing them for general use).


If one wanted to update an activity, say TuxMath, now the first step 
would be to clone the repository not install the activity itself.


The ASLO site needs some work. Currently, the latest version is not 
necessarily exposed (see Browse or TuxMath, for example). In some cases, 
activities do not support Arm or use Hulahop and there is no way to 
specify which versions of Sugar or its platforms are supported. The 
availability of maintainers who know the PhP implementation of ASLO is 
apparently dwindling. Perhaps Sugar Labs could undertake to re-implement 
ASLO using Python (Django, flask, ...) or javascript to broaden the base 
of potential maintainers.


However, dependence on github creates a duplicate repository for the 
source code. With 400+ activities, there is no mechanism in github to 
make the activities visible. Currently it may require searching 7 
screens to find if an activity is there (unlike ASLO which has an 
effective search capability).


I am sympathetic to the desire to acquaint our users with git and the 
concept of version control. However, this approach limits the 
opportunity to those who have internet access (probably a minority of 
our users).


A more effective approach would be to determine how git could be 
installed in Sugar ( a git activity?) so that it can be used. Your book 
could then be used as a basis for helping our users learn to develop 
activities using version-control. In this way version control can be 
used locally by the developer prior to submitting an updated or new 
activity to ASLO (which may well involve a visit to an internet cafe).


Tony

Tony

On 03/14/2017 03:39 AM, James Simmons wrote:

All,

I have been neglecting the manual /Make Your Own Sugar Activities!/ 
ever since I first wrote it. However, I did manage to make one needed 
update in the laziest way possible. Since Sugar Labs has moved away 
from git.sugarlabs.org  in favor of GitHub 
since I wrote the version control chapter I have added the following 
note to that chapter:


*Important Note*: When this chapter was written Sugar Labs was
still using *git.sugarlabs.org * as its
code repository. While this still exists, the preferred repository
is now https://github.com/, using the *sugarlabs* organization.
This chapter is still a reasonable introduction to using Git, but
when you set up your project repository you should use the
excellent instructions provided on GitHub instead of the Gitorious
instructions provided here.


I hope this helps in some way.

James Simmons



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[James Simmons]

All,

I have been neglecting the manual *Make Your Own Sugar Activities!* ever
since I first wrote it. However, I did manage to make one needed update in
the laziest way possible. Since Sugar Labs has moved away from
git.sugarlabs.org in favor of GitHub since I wrote the version control
chapter I have added the following note to that chapter:

*Important Note*: When this chapter was written Sugar Labs was still
using *git.sugarlabs.org
* as its code repository. While this still
exists, the preferred repository is now https://github.com/, using the
*sugarlabs* organization. This chapter is still a reasonable introduction
to using Git, but when you set up your project repository you should use
the excellent instructions provided on GitHub instead of the Gitorious
instructions provided here.


I hope this helps in some way.

James Simmons
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel