Re: G1G1 updates, Lennon video and other vids
At Sat, 27 Dec 2008 14:42:51 -0500, Samuel Klein wrote: > > Hi, > > The Lennon video that's been murmured about for weeks has been > released. I'm curious to see reactions from the list. I have to agree wtih David on making a dead cerebrity say something he didn't say. And, while the message of "Imagine" and Lennon have "some" overlap with the mission of OLPC, but it is not as big as one might think. Looking at Yoko Ono has been saying and doing, she/they are more into new-agey, peseudo-sciencey, and not quite a good message in conjunction with education. I like some of the songs, and I don't oppose to progressive art and their activities, but I feel it awkward if people treat Lennon as a big symbol for practical world changer and not to mention for education.) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-open] The 40th Anniversary of the Dynabook event at Computer History Museum
At Thu, 30 Oct 2008 19:12:46 -0700, Edward Cherlin wrote: > > On Wed, Oct 29, 2008 at 1:45 AM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > > At Tue, 28 Oct 2008 14:24:09 -0400, > > Brian Jordan wrote: > >> > >> Cool! (bump) > > > > Yes and thanks. The third panelist has been announced and it is > > none other than Mary Lou Jepsen. > > > > http://www.computerhistory.org/events/index.php?id=1221864610 > > Are they going to get Doug Engelbart for the panel? No. However, there is an event for him and the demo: http://stanfordtickets.org/tickets/calendar/view.aspx?id=2324 -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Allowing an activity to be launched multiple times in parallel
Technical arguments aside, I thought that people feel the stop/resume model of Activity important to Sugar. If so, I think the stop/resume model does invite the idea of limiting to one instance of activity at a time. Two parallel Write sessions? Then, we might as well consider to switch to the documents and applications model. -- Yoshiki At Wed, 29 Oct 2008 20:23:48 -0400, Benjamin M. Schwartz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Deepak Saxena wrote: > > On the XO, if we try to edit two documents concurrently on Write, we should > > in my opinion only have on instance of write running which can switch > > quickly > > between document objects so the user percieves it as two separate instances. > > I disagree strongly, for several reasons. > > 1. Bitfrost requires that each instance be isolated from every other. > Each instance only has access to the Journal items to which the user has > explicitly granted it access. Allowing multiple "apparent instances" to > share data behind the scenes represents a privilege-combining attack. > This is especially apparent if one instance has been launched with > P_NETWORK but not P_CAMERA, and the other has been launched with the > reverse privileges. > > 2. A key feature of the Sugar Activity system is that writing Activities > is _easy_. The goal is to minimize the amount of work required to write > an Activity. Asking Activity authors to juggle multiple virtual instances > creates tremendous complexity that is likely to produce bugs even when > performed by experts (e.g. Browse), for no user-visible gain. > > 3. Two separate Activity instances already share a great deal, because > the Linux kernel automatically uses CoW to keep only one copy of read-only > memory needed by multiple processes. Each Write instance uses no CPU when > idle, so RAM is the only overhead. > > As a matter of efficiency, there is certainly more we can do to decrease > the memory overhead of running multiple instances. People are working to > improve the efficiency of our X icon caching system and python launcher. > Even better would be to work on the python interpreter upstream to improve > memory usage and reduce the dirtying of pages that could be shared. > > - --Ben > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkkI/pQACgkQUJT6e6HFtqTCBgCfQg0RDoRC38U1mWmwzQSgfxJe > i+AAn1nWN9EyvkYNJGSniZ5xfOxviyRd > =Upkp > -END PGP SIGNATURE- > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-open] The 40th Anniversary of the Dynabook event at Computer History Museum
At Tue, 28 Oct 2008 14:24:09 -0400, Brian Jordan wrote: > > Cool! (bump) Yes and thanks. The third panelist has been announced and it is none other than Mary Lou Jepsen. http://www.computerhistory.org/events/index.php?id=1221864610 It looks like the registration is still open (didn't sound like so many seats are remaining though). -- Yoshiki > 2008/9/24 Yoshiki Ohshima <[EMAIL PROTECTED]>: > > There will be an interesting event. It is even sponsored by OLPC! > > > > http://www.computerhistory.org/events/index.php?id=1221864610 > > > > -- Yoshiki > > > > -- > > > > CHM Presents > > The 40th Anniversary of the Dynabook > > > > > > SPONSOR > > Sponsored by One Laptop Per Child > > > > Alan Kay, Charles Thacker, and moderated by Steve Hamm, BusinessWeek > > > > > > DATE & TIME > > Wednesday, November 05, 2008 > > > > 6:00 p.m. Member's Reception - CHM Members only > > 7:00 p.m. Program > > Wine for the Member's Reception provided by the Mountain Winery > > > > LOCATION > > 1401 N. Shoreline Boulevard > > Mountain View, CA 94043 > > > > Call 650-810-1005 for information. > > > > ABSTRACT OF TALK > > The roots of "personal computers" -- that is, machines that are not shared > > between users -- date back to at least the late 1950s. Within a decade, > > several more of these "one machine, one user" computers were developed; and > > the idea of a user having direct control over the computer was established, > > at least within academia. > > > > In 1968, young computer scientist Alan Kay gave a presentation on the FLEX > > Machine at a meeting of computer science graduate students and saw the > > first working versions of a new flat panel plasma display technology. This > > led to discussions about how nice it would be to (someday) place the FLEX > > computer itself on the back of such a display to make a notebook-sized > > computer. > > > > A visit a few months later to MIT computer scientist and educator Seymour > > Papert and to a school with children doing advanced math with Papert's LOGO > > programming language, produced an epiphany in Kay. He decided to make "A > > Personal Computer For Children Of All Ages." This was to be in the form of > > a compact notebook using both tablet and keyboard, a flat-screen display, > > GUI, and the wireless networking that defense funding agency ARPA was > > starting to experiment with. > > > > This idea eventually acquired the name "Dynabook" as an homage to what the > > printed book has meant to civilization and learning. It is also a gesture > > to a future in which not just the content of "books" will be dynamic, but > > the relationship of people to computers will itself also change. > > > > The founding of Xerox PARC a few years after the Dynabook concept provided > > support and a context for developing many of these ideas. In fact, the PARC > > "Alto" workstation was originally called "the interim Dynabook". Many of > > the results from this research influenced commercial computing, including > > the bit-mapped screen, high-quality text and graphics, overlapping windows > > and an icon-based GUI, desktop publishing, object-oriented programming, and > > many others. > > > > Join Steve Hamm of BusinessWeek as he moderates a panel discussion to > > celebrate this idea that provided metaphor, motivation and inventions for > > the personal computers of today. > > > > This event is generously sponsored by One Laptop Per Child. > > > > Panelists: > > - Alan Kay > > - Charles Thacker > > - TBD > > ___ > > Olpc-open mailing list > > [EMAIL PROTECTED] > > http://lists.laptop.org/listinfo/olpc-open > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Another Journal Ideas
Thank you, Scott! > Yes, what you've described is more-or-less the plan of record: don't > store any metadata which can be extracted from the actual content, and > use plugins in the indexing service to extract interesting metadata > from a variety of "real" formats. Good. So I wasn't so "off". I tried to figure out what your design was like, but from remote and just looking at the slides it wasn't so easy. Reading your reply, only difference (?) is on the UI side; "encouraging" the activity designers to have the data in the document itself and make it visible. > The few bits of metadata which > can't be representing in existing document formats (non-path tags, > "action id", etc) will be stored in xattrs, which are compatible with > all modern Unix systems (including Mac OS X). They may be lost during > transport to non-XOs, which is why we'll try to minimize the number of > these bits as much as possible. This also makes us as robust as > possible against indexer failures: we should always be able to rebuild > the index using nothing but the information on disk (and possibly > taking advantage of better indexers and metadata extractors when we do > so). Good. FAT32 formatted USB memory seems that second most used storage, so taking it into account from the beginning (this time) would be good. > Non-local search is possible (see part 4 of my journal screencast), > but probably not transparently: you will have to select a particular > friend whose journal you want to look in. This seems more reasonable > (to me, at least) in an environment without perfect connectivity: if > you try to search everyone's journal all the time, it's hard to know > whether you didn't find any matches for your search because there > really weren't any, or if the person who had the matching document > wasn't on line. If you explicitly selected the person to search, it > can be made a lot more obvious whether or not their journal is > available to search at this moment in time. (Where "available to > search" may mean "cached on a local schoolserver"; it doesn't > necessarily have to mean, "my friend's XO is turned on and connected > to the internet right now".) > --scott > > -- > ( http://cscott.net/ ) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Another Journal Ideas
Hello, As pointed out elsewhere, the NLS system had a data storing and sharing mechanism called "Journal". It allowed full-text search, versioning, hyperlinking/annotations and sharing among users. http://www.bootstrap.org/augdocs/augment-33076.htm The sharing and searching let people do interesting things; like when somebody stored a document that includes "To: DCE" in the document somewhere, and if DCE searches for "To: DCE", the resulting list automatically became his message inbox, for example. Anyway, that is a bit of historical background (so anybody who thinks the OLPC's journal is a new idea, I have a bit of issue^^:) And there are some requirements/desire for the new system: + Recent discussion goes that some people use full text searching more, and tagging less. And, my observation is that kids are not going to tag documents, if it has to be done in a separated window. "Out of Sight, Out of Mind" is the proverb. + There is some desire to support legacy applications seemlessly. + And also, there is a need for running Sugar on the other operating systems. These things suggests that the whole concept of "metadata" may not be a good one. So, here is another simple Journal-like data organization idea. - In the Activity/Application UI, the place for tags, document title, etc. should be readily visible. For example, in a word processor, an "empty" document contains something like: Creator: yoshiki Title: No Name from the beginning. These "fields" are just text. The user may "fill" them at any point, and when the document is saved, these lines are also saved as a part of the same data. (By default. More to come later.) When I was a school kid, that was how I and all other students wrote essays. It is just a blank paper with grids and, I just wrote the name and title in the same way as the main body of the essay. - For a JPEG picture created by Record, the data can be stored in a comment in EXIF. - For an application like Etoys, the data file is actually a zip containing a few files. The "metadata" can be stored as another fixed named file in the zip. The word processor example can do something like this, too. - Optionally, the programmer of an activity writes a little program that knows how to extract the data. (let us call it a "metadata extractor".) - An activity simply stores the data file into a file system location. So, unmodified X application can save data. - The new "Journal" system calls the metadata accessor to extract the data. Journal can certainly cache it. - Let us say for every week, the Journal can create a new directory for the activity. The data stored in the previous week or time period stays in a directory. So that let you access the old data in a time-indexed manner. So, the advantage of this approach is: - An unmodified application can save and load data from file system. - Any platform can support this. We don't have to rely on the DBus, but also it is not incompatible with the already Sugarized acitivities that can save data via DBus; the backend of Journal stores the file into the proper location. - The application programmer can write a small program and the Journal can extract the metadata for better views. But it is optional; even without the extractor, the system runs fine. - The time-based access can be made fast. A downside is: - It wouldn't be easy to get some kind of metadata like "who you worked with". But there can be an API to query it from an activity and the activity can store it in the data. Alternatively, we can still recommend people to do DBus-based access to Journal when possible, and Journal could add it for the activity. Just a thought. I shared this now and then with some people, but it seems to be a good time to brain dump^^; -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Etoys supports the DC input
Hello, It's been available for a while, but I'd like to announce that Etoys running on XO supports the DC input. To try it: - Launch Etoys. - Drag out the "Object Catalog" from the Tresure Box. - Go to "Multimedia" category in the Object Catalog. - Drag out "WorldStethoscope". - Right click on the instantiated WorldStethoscope and click on the light blue eye icon to open its viewer. - Click on "basic" category header to get a menu, and choose "sound" to go to sound category. - Press Start in the WS. Some of the numbers in the viewer start changing. Whisle into the microphone. - Press Menu of WS, and choose "add a graph...". May be pick "sonogram". - You can open more than one graph on the same data. Press Menu of WS, and choose "add a graph...". May be pick "spectrum." You can see sonogram and spectrum graph (and signal if you open it) at the same time. - Connect a sensor to the jack. Press "AC" button to switch to "DC". - The tiles can be used in the Etoys tile scripting, so kids can make stuff with them. etc., etc. The UI needs one more face lift, but it works ok. If you don't have XO, you can still buy the WorldStethoscope hardware (http://www.academianetwork.co.jp/service/) that converts the sensor output to audio and do effectively the same thing on any computer with a sound input. The version in 764 has a little bug so that it leaves the mic LED on even after quitting Etoys (it is fixed in the latest Joyride). But it is usable. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
At Thu, 25 Sep 2008 14:37:09 -0500, Sameer Verma wrote: > > On Thu, Sep 25, 2008 at 12:39 PM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > >> > BTW, the spreadsheet is at > >> > http://spreadsheets.google.com/ccc?key=p_Xhb6KcXLyEViA50CnCaDg&hl=en > >> > >> So by that metric, Terminal is the best activity. Huh? > > > > Yeah. Do these numbers mean anything? What is the point of > > averaging unrelated numbers? Averaging lines of code score and > > usability score almost looks like an idea of an innumerate. > > > The numbers are just fillers. They don't mean anything. The idea is > for you guys to fill in numbers based on a metric and not because its > popular on the list. Feel free to edit as needed. I still don't get it... Even if people edit the spreadsheet "as needed", at what point is it going to start "making sense"? The question is whether things can be put on one dimentional axis in this way. As you also know, using numbers doesn't necessarily make it "unbiased". -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
> > BTW, the spreadsheet is at > > http://spreadsheets.google.com/ccc?key=p_Xhb6KcXLyEViA50CnCaDg&hl=en > > So by that metric, Terminal is the best activity. Huh? Yeah. Do these numbers mean anything? What is the point of averaging unrelated numbers? Averaging lines of code score and usability score almost looks like an idea of an innumerate. Teaching kids how to treat these scores properly would be a great lesson. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
At Tue, 23 Sep 2008 10:57:36 -0700,
Deepak Saxena wrote:
>
> On Sep 23 2008, at 03:40, Albert Cahalan was caught saying:
> > Determining the RAM requirement for an activity goes something like
> > the following:
> >
> > awk '/Dirty/{x+=$2} END{print x}' < /proc/12345/smaps
> >
> > (after exercising all functionality)
>
> I like the idea overall but this part worries me. An activity such
> as etoys has a lot of functionality.
For Etoys, the memory usage grows only when you load a project or
instanciate widgets (give or take, when you display a compressed
bitmap, it expands automatically and eats more memory, etc.). So,
about it will be 30MB and it will stay flat whatever you do. We can
reduce the base size, if that is the priority.
-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Clock activity? Activities about time?
At Mon, 01 Sep 2008 16:38:19 -0400, Chris Ball wrote: > > Hi Bastien, > >> is there a Sugar activity displaying a simple clock? > > Yes; search for Clock on http://wiki.laptop.org/go/Activities. > >> What activities can be used to teach things about time? (seconds, >> minutes, hours, days, weeks, months, years, decades, centuries...) > > I don't think there is one yet. We could do this in a Pippy example, > or in eToys? Last time around, I made this Etoy: http://dev.laptop.org/~yoshiki/etoys/Clock.004.pr The idea behind it was to be able to move hands around, and show the relationship between the values and the angle of hands. http://dev.laptop.org/ticket/5255 -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Scratch localization.
At Wed, 27 Aug 2008 18:54:18 +0200, Bert Freudenberg wrote: > > > Am 27.08.2008 um 18:38 schrieb C. Scott Ananian: > > > Scratch appears to require manual editing of the Scratch.ini file in > > order to come up in a language other than English. Is there any way I > > can pass a command-line option in bin/scratch-activity to set the > > Language preference based on the value of $LANG? I'd prefer that we > > not have to ship a different Scratch bundle per-country. > > The Right Way to do it would be using the LocalePlugin, as Etoys > does. The Scratch 1.3 version adapted the LocalePlugin and it appears to be working (at least on Windows). So, I think it is getting there. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository
> Continuing with the biological analogy, the folks who want to be able to > bootstrap a Squeak/etoys image (starting from 'scratch' without such an image) > want literally to be able to make ontogeny recapitulate phylogeny -- not > necessarily every time an image starts, possibly not necessarily every time > Squeak is 'built' -- but at least with similar frequency and the ease of > bootstrapping gcc using a different C compiler. (Like using a turtle egg to > hatch a dinosaur ;-) I believe that the question is not whether a system can do it or not. Smalltalk-72 did it, GNU Smalltalk and Scheme 48 do it, and our fonc project is right now taking similar approach. So bootstrapping is possible. However, given the current status, the trade off between having to change the existing system fundamental way and its value is the question. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Albert,
> You'd be all set if you had Smalltalk source code that you
> could feed into any random Smalltalk system to create
> your build tools.
>
> While I happen to like C, and it's a very popular way to
> achieve the required ability to bootstrap, it isn't needed.
> You even get a certain amount of respect from writing
> the whole thing in Smalltalk. Use GNU Smalltalk.
Your view on systems are way too limited. Where did this "any
random Smalltalk" came from? For example, if you write a GUI
application in Python, it doesn't mean that it only uses standard
Python's features. It certainly is going to use GTK or some other GUI
bindings. Then, you cannot feed it to another Python implementation
that doesn't have it.
Please just don't make up new "complaint" whenever the old one
didn't work.
> You might even scrape by with Squeak building itself.
> (not involving "copy the currently running image")
> If you can create a new image from loose UTF-8 text
> files and standard media files, without any data being
> swiped from the currently running image, then you've
> met the requirement.
Not to mention that don't make up "requirement".
> > http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html
>
> That's in interesting read.
The trouble is that people make such wrong claims before reading
such a basic document.
> It does admit to depending on a system image from decades ago:
>
> "Alter the ST-80 SystemTracer to write an image in the new format."
> "no longer needing to port images forward from Apple Smalltalk"
And?
> > What is the source management system for the Etoys and Squeak VMs? Is
> > _everything_ done in Smalltalk and kept in the image file? Wait, I see
> > it. http://www.squeakvm.org/cgi-bin/viewcvs.cgi/. Albert?
>
> That appears to be the OS interface layer. No problem there.
> Feel free to write that in Smalltalk instead though.
Vast majority part in this repository is written in Smalltalk.
Please understand the problem before spreading wrong impressions.
> The really important thing is an ability to generate
> everything from source. That means you can create a new
> image without grabbing bits from an existing image.
But after seeing my big C file idea:
-
unsigned char image[] = {0x12, 0x34, };
int
main()
{
FILE *image = fopen("etoys.image", "w");
fwrite(image, sizeof(image), 1, image);
fclose(image);
}
-
then you will probably make up new "important thing".
-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Hi, Edward,
Thank you (again) for thinking about these things!
Well, now I see a reply from Alan. I'll try to concentrate on the
pure technical part.
> >> I think that the result of all this is that we can produce all of the
> >> C (or some other language, maybe CLOS) and Smalltalk source files that
> >> Debian wants (even if we think of the C as compiler output, we don't
> >> have to bother them with that interpretation.) One of the compilers
> >> translates a subset of Smalltalk to C, but I gather that other
> >> compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
> >> their chosen target language.
>
> Now I see that this is unnecessary. We have the directly executable
> Smalltalk source for the VM, including memory management and graphics
> primitives written in Smalltalk. It is already in the .sources
> files.
A little correction is that the source for the VM is in a separated
package called VMMaker; the etoys image currently doesn't contain it.
> We can therefore provide all of the source code for Etoys in a
> conventional file system in the way that users of compiled languages
> expect.
There still seems some misunderstanding, but I can't tell how.
The word "therefore" cannot connect the previous sentense with the one
that follows here. .sources (and .changes) contains the all behaviors
of objects. and it is in text.
> I find it useful to meet people half way in such a situation. Well, we
> don't have to have our code in a conventional file system, but here is
> how you can fairly trivially create such a file system and rebuild an
> image, even though we never do this in practice. Well, almost never.
> Aha! You can do it that way, somebody might need to do it that way,
> that's what I'm looking for in the first place. So give. Don't tell me
> I don't need to know.
Hmm. I'm not sure what you mean by rebuilding an image. If you
mean to do it from the situation there is no .image it would be very
hard. For example, the "nil" object (the sole instance of its class
named UndefinedObject) sits at the beginning of the image file. You
cannot create the memory words that represents the instance in
meaningful manner from text (in the current Squeak way of doing).
You can have a big C file that looks like:
-
unsigned char image[] = {0x12, 0x34, };
int
main()
{
FILE *image = fopen("etoys.image", "w");
fwrite(image, sizeof(image), 1, image);
fclose(image);
}
-
And this .c file is all text. This could satisfy Debian people, if
they accept some other languages that are bootstrapped.
> I want to _see_ that fairly trivial script. I want Debian to see it
> and to be able to run it and examine its output. Once they understand
> how one can generate "source code" in the traditional form whenever
> desired from the real source, and where that real source lives, they
> may be able to believe in using the code in the image and not
> bothering with generating a conventional representation. They seem to
> want proof that we can do something unnecessary but comforting. Well,
> it shouldn't be any real effort, so why not give them that
> demonstration?
The misunderstanding may lie around what kind of translated C can be
compiled and executed. We can have a smaller image that is 1MB or so
(can be even smaller but I don't a real point to go for extreme) and
file in everything else to build the etoys.image. But I cannot see
anywhere that transated code plays any role in the picture.
> Somebody, somewhere, gave Debian the impression that .sources and
> .changes do not contain the code for everything. I don't know how this
> happened. You are almost correct that we don't need to show them the
> translated stuff. But given the damage that has been done, we now have
> to show them the entire process from full Smalltalk source to
> generated code to new image, and the generated C is part of that
> process, even if not source.
They contain all code (plus some history even). They don't contain
the instanciated objects. They can contain texutal expressions that
creates objects, but the textual expressions have to be compiled by
the Compiler object that needs to exist.
> So let's just show them where all the code is and how to get at it in
> a way that they already understand, so that they can begin to
> understand why they don't need to do it that way.
I should know who are they.
>
> Who here is with Debian? Whom do we have to convince?
I dug up an email archive of squeak-dev
a few month back and find a name ("Thomas Viehmann").
> > David:
> >
> > breaking out the .source and .changes files that have been referred to in
> > this thread and having the build process create the resulting blob that
> > you use would probably be acceptable (and far more useful as people can
> > then send out patches to those files)
> >
> >
> > We are already sending out textual files called "changesets" to
> > people. That is the way we work.
>
> That doe
Re: etoys now available in Debian's non-free repository
At Thu, 26 Jun 2008 23:43:45 -0700,
Edward Cherlin wrote:
>
> I think that the result of all this is that we can produce all of the
> C (or some other language, maybe CLOS) and Smalltalk source files that
> Debian wants (even if we think of the C as compiler output, we don't
> have to bother them with that interpretation.) One of the compilers
> translates a subset of Smalltalk to C, but I gather that other
> compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
> their chosen target language. As I understand it, Debian wants to see
> a commented set of semi-human-readable code in ASCII files (although
> we can discuss using Unicode source) together with various multimedia
> files in known open formats, from all of which an Etoys image can be
> constructed, and they don't care how we generate them, or what mix of
> languages we use, as long as there are Free/Open Source compilers and
> any other needed apparatus for them.
As Alan precisely put it ("we are dealing with stories, not
reality."), this seems to be a backward way to work on this problem.
When (if) Debian guys asked something based on wrong understanding,
what we should do is not to cater the wrong story, but have them have
real understanding.
The reality is that the all description of classes and methods are
already accessible (even in text files like .sources and .changes) and
anyone can see all the code, and modify in the way the core developers
do. That is the equal basis we provide to the world. Giving the
translated stuff, except the C code for the virtual machine that is
needed for bootstraping purpose, is wrong.
David, Antoine, and Jonas, thank you for the comments. But let us
not take this way anyway.
(Still I see some comments that says "the source code is in the
image" but it is absolutely false. In the image, the compiled result
of source is stored, and the texual code is always kept outside of the
image.)
David:
breaking out the .source and .changes files that have been referred to in
this thread and having the build process create the resulting blob that
you use would probably be acceptable (and far more useful as people can
then send out patches to those files)
We are already sending out textual files called "changesets" to
people. That is the way we work.
Jonas:
If I understand correctly, the Squeak community accepts patches
generated from their binary images.
So the real question is, if images built from C sources can generate
patches acceptable by the Squeak community.
"Generate" is a wrong word! We write code textually in a text editor
(happens to be written in Smalltalk) and save it. Of course the
patches ("changesets") are valid, we accept them. We won't notice if
the changesets are written in Squeak, a image running on different VM,
Emacs or vi. It is just text. The only difference is that the effect
of "accepting" (saving) takes effects right away, as it is running in
the same session. Just as same as writing Emacs Lisp in Emacs.
(Think writing lisp-mode.el in Emacs.)
The image contains pre-made objects starting from nil, true, false,
etc., to the Compiler and beyond. It also contains pre-loaded artwork
and user contents. But all of them can be modified, and accessed
fully.
-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
At Thu, 26 Jun 2008 18:47:11 -0700, Edward Cherlin wrote: > > On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > > I'm glad that Debian didn't break the rules for etoys. > > You're claiming to be open source, yet you've LOST the > > source code decades ago. > > This turns out not to be the case. All of the source code for the > parts of Etoys written in Squeak/Smalltalk is in the image. ... is in .sources and .changes and the image holds the compiled results of them and each of these compiled results hold a file offset of the source chunk. > The .sources file and .changes file contain all of this code nicely > formatted. Yes. > The core of Smalltalk, the part not written in Smalltalk, > is also available in both source and in binary parts of the usual > image. The usual tools for handling all of this are in > Smalltalk/Squeak. Nothing prevents you from rewriting them in C, > Python, or what you like. Oh, yes. Speaking of which, Dan did a version in Java: http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/ > Now, for the rest of you, let's see what we can produce, to make > Albert happy, but more importantly Debian. We have .sources and > .changes. Albert and Debian would like to see source for the VM, in > the manner of gst, and the binary core of Smalltalk that goes with it. > What can we show them, and what would it take to show them the rest? > "The Squeak system includes code for generating a new version of the > virtual machine (VM) on which it runs. It also includes a VM simulator > written in itself (Squeak). For this reason, it is easily ported." > What's missing? Is there anything in bytecode without Smalltalk > source? It doesn't seem so. The primitives like memory management and > BitBlockTransfer get translated to C and compiled along with the VM. > Is that right? Yes. A sidenote. The repository on squeakvm.org seems is a tree of .c and .h source files and you can compile it by gcc to produce the VM. However, many of these files are not the "sources" in a strict sense; These .c and .h files are target files from another phase. It is almost the same manner as Scheme48 ships scheme48vm.c. If (only if) somebody claims that Squeak's way of doing is wrong, that person should also claim that Scheme48 should be taken out from Debian. > "Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs > using the full range of Smalltalk semantics, including blocks." > http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work. > So apparently we can translate all of the Smalltalk tools for creating > code files and rebuilding an image to C source, and we can presumably > preserve the original comments from the Smalltalk. I'm not sure what you mean by "code files" and "an image to C source". > Since the result was a complete Squeak > image with all Smalltalk source code, and C source where needed, is > anything else missing? "No" would be the answer, If I understand your question. > "The interpreter is structured as a single > class that gets translated to C along with the ObjectMemory and BitBlt > classes." Is that it? The modern version has basically different set of primitives in different files, but that is it. > Is there any reason not to simply check .changes into git? The public version of (so to speak) .changes and .sources are already in the SVN on dev.laptop.org, and it is installed in /usr/share/etoys. > Should we > have a way to split out changes to specific objects, and write a tool > to merge a sequence of such changes into a .changes file? Hm, it > appears that this is unnecessary with Monticello and squeakvm.org. Before commiting it, we need to ask why splitting the file adds any value (when the editor can provide such views to the user). > As far as I am concerned, you should write any such tools in > Smalltalk/Squeak, and offer that source code to anybody who demands a > translation to another language. No, I'm wrong, not a problem. We can > translate it to C ourselves. There you go. The Squeak-to-C translator is designed specifically to translate the subset of Smalltalk that can be mapped onto C. IOW, you write C code in Smalltalk syntax, and debug it in Smalltalk. For writing interesting tools, you would certainly like to use the full power of Smalltalk language but then it wouldn't be translatable to C. If any such tool is written in Smalltalk, you would give the Smalltalk code to other people. That is source. Translated C program isn't source; it is a target object file that uses characters between 0x00-0x7f. > Or set up an instance of Monticello for Etoys versioning > and package management. Not Monticello, but this was tried. But the problem is that it just adds unnecessary complexity and gets in the way of *actual* development effort. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://list
A greater cause (Re: etoys now available in Debian's non-free repository)
Hello, Sorry for causing some email traffic last a few days. We, everybody who are participating the project, including Albert, John, Bert and myself, are working for a greater cause; that is to empower children all over the world via computer technology and education. There are some difference of opinions, but let us not lose the sight of the bigger goal. Etoys is already installed millions of computers, and children all over the world have been using it several years. If we get Etoys to the hands of more children, more children can exchange projects, share ideas, work together, and unite. It doesn't matter whether the computer they use is XO or not because Etoys happens to run everywhere. And, on XO, I heard from people at deployments/pilots often that Etoys is one of the most important activity. So, I think that trying to get Etoys into major Linux distributions serves for the greater cause. Of course, even if Etoys gets in a Linux distribution, not every user/developer has to work on Etoys nor everybody has to understand how it is implemented. For those, it is just several unfamiliar files on their disk and there is absolutely no harm. On the other hand, we would like to get more people to help Etoys development And I can assure you that you can go deeper than any other systems once you dive in. Please join us! Even if your only computer is XO, you can participate as good as the core developers. (If you are good, you can join/take over the core team, in fact.) Also, please think about making a similar/better system in any other languages. Alan Kay gave a keynote speach at Euro Python a few years ago and urged the community to think about it. It seems that a few project got started but it takes years to be somewhat usable. Finally, thank you for everybody who have been involved in the actual process of getting Etoys accepted to these distributions! -- Yoshiki In a sense, Albert, John, Frank and others are kindly playing the devil's adovocate role so that we can write stuff that we usually don't. Thank you guys, too^^; ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Albert, > The very foundation of the Linux development community > (which Squeak developers are asking to be accepted by) > includes an expectation that software can be handled in > certain ways. I don't know if it is *very* foundation, yeah there is an expectation. I know it because I was one of them. But the questions are that what would be the greater benefit for everybody, and whether the exepectation justifies to limit other people's freedom. The technical stuff you wrote below (ah, Bert replied, too) *can* be done (though not common practices) with Etoys/Squeak. How many times you try to spread the same false information, the fact doesn't change. Anyway, you now seem to agree that Etoys qualifies as open source. That is good. > and a certain degree of modularity (parts are interchangable across > similar projects and versions, allowing distributions to mix and > match). Again and again and again, you can just write a method or two internally or externally and send it to your friend or post it to trac, etc. And a person who are using similar versions of Squeak, he can just load it. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
> Right. I'm also not explaining why software freedom is > good, why maintainability is good, why interoperability > is good, etc. Values are values. That is alright. You tried several claims to say Etoys is not open source based on incorrect ideas, and now it seems that you exhausted such claims. So we are probaly in the agreement that Etoys is open source. That is all that matters. Whether is is easy to maintain, etc. aren't the central issue. > I got that. The fundamental problem is the patch collection. There > is a problem even if you can distribute the result. Patches need to > be applied. If you do that, and distribute a blob, then we're back > to the blob problem. If you don't do that, then we have the Minix > problem. There is no real "blob" involved in this discussion, so I don't know what to say. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys now available in Debian's non-free repository
Albert, Before drifting to a new topic, let me make sure one thing; did you get convinced that FSF's definition of software freedom doesn't contradict with a binary image file with right tools to fully explore/understand/modify it? If not, please explain. If so, I understand that you don't like it, and that is ok with me. In the following, you are discussing "my preference" part but here goes: At Thu, 26 Jun 2008 02:41:00 -0400, Albert Cahalan wrote: > > Sure, but I actually can get an independent implementation > of an editor for such data -- it doesn't depend on itself. You can edit a file out with your favorite text editor and file it in to the image to do any kind of stuff. > A good situation would be that you can build the image from > plain text just like GNU Smalltalk does. That could happen on > the laptop when the activity starts, or when the activity is created. > > The next best thing would be to supply a custom editor > which is **external** to the image, along with any other > tools needed to edit and create the image. It should be > possible to start from some standard build tools, feeding > in a mix of source code and standard media files, to end > up with a set of tools. Note that you could write such > tools in Smalltalk if you used GNU Smalltalk, which is > able to be bootstrapped. You never explained why these things are "good". > This solution essentially > treats the image like a multimedia file instead of code. > (a dump tool is all you have AFAIK; there is no editor > that can reliably edit a VM image) We don't exactly treat the image file as "code". Image is a snapshot of state of objects. > It's also a problem for change tracking, shared development, > use of one's favorite editor, code sharing with GNU Smalltalk, etc. You can of course file out and file in textual code and if the code is compatible with GNU Smalltalk, you can share the code. > This idea of applying patch collections is disturbing. It reminds > me of the terrible mess that Minix was back in 1991, when the > license permitted people to share patches but not code with > the patches applied. Here you have a technical limit instead > of a legal one, but I expect that the result is not much different. No, no. You don't get it. Applying patch happens when building a release image and the resulting image gets into a package to be distributed. It is just the same as compiling an executable binary from source code and distribute the binary. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
After writing the most of reply here, I found it now largely
off-topic (thanks to Frank for understanding!)
At Wed, 25 Jun 2008 21:00:24 -0400,
Frank Ch. Eigler wrote:
>
>
> Yoshiki Ohshima <[EMAIL PROTECTED]> writes:
>
> >> The gist of the argument is that one can't currently know what's
> >> really inside an etoys image, except beyond what it itself tells us,
> >
> > BTW, do you now agree that this was not true?
> >
> > If you give me an image file and ask me "why the word at offset
> > 0x12345 in the file is 0x89ABCDEF?", I can answer that by opening the
> > image file externally with InterpreterSimulator, examine the bits and
> > answer something like "this is a second slot of an Array that points
> > to a number object, and the array is pointed to by this, this and ths
> > object.", etc.
>
> Yes, that sounds much better (from a security/trust point of view)
> than having to ask the virtual machine itself to introspect.
Well, if you understand more about the relationship between
InterpreterSimulator and the VM, external or not would not make so
much difference. And, the VM is compiled by a foreign system (a C
compiler), there cannot be a place to hide something like Tompson's
attack. External or not wouldn't be the factor.
(And you probably meant that better than "asking the image itself".)
> It stills seems somewhat too low level to enable version control.
> (Back in the early 90's, when I wrote Smalltalk code for a living
> (sort of), we ended up having to use external system
> ("teamwork/envy" IIRC) to get decent version control and
> reproducible builds.)
Of course, what you would like to version control is the code people
write. ENVY and others are designed for that purpose.
For doing version control, we could more or less freeze an image to
be a base (like our etoys-dev-3.0.image), and make a release image
automatically by applying the updates
(http://tinlizzie.org/updates/etoys/updates/) and evaluate the do it
("ReleaseBuilderSqueakland new prepareReleaseImageForOLPC") from a
Makefile (if that makes people happy). The diffs are all in small
textual files. As long as you trust the base image, you only have to
look at the updates.
Now and then, we may want to change the base image. We do something
that gave the perception to people that the previous base image is
trustable there and that would do.
> It may be a useful exercise to run this over the whole etoys image to
> identify those parts that are recompilable from the .source/.changes
> files, those that represent plain data that could be serialized, and
> perchance surprise objects whose existence was only known to Alan Kay
> or Adele Goldberg back in the 80s. :-)
I don't know in what sense it is *useful*, but the core image of Spoon
(http://netjam.org/projects/spoon/) is 1,337 bytes (and of course
every byte is understood).
-- Yoshiki
(And '80s is wrong time to go back in that sense, and Alan Kay and
Adele Goldberg aren't the names to be mentioned in that context.)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
At Tue, 24 Jun 2008 17:12:23 -0400, Frank Ch. Eigler wrote: > > The gist of the argument is that one can't currently know what's > really inside an etoys image, except beyond what it itself tells us, BTW, do you now agree that this was not true? If you give me an image file and ask me "why the word at offset 0x12345 in the file is 0x89ABCDEF?", I can answer that by opening the image file externally with InterpreterSimulator, examine the bits and answer something like: "this is a second slot of an Array that points to a number object, and the array is pointed to by this, this and ths object.", etc. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
At Tue, 24 Jun 2008 17:12:23 -0400, Frank Ch. Eigler wrote: > > The gist of the argument is that one can't currently know what's > really inside an etoys image, except beyond what it itself tells us, BTW, have you now understood that this was not true? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
At Wed, 25 Jun 2008 19:09:12 -0400, Frank Ch. Eigler wrote: > > "Edward Cherlin" <[EMAIL PROTECTED]> writes: > > > [...] Can gst bring in a .sources file and a .changes file and > > create a working image? > > It doesn't have to. It builds "gst.im" from scratch at every > bootstrap. If squeak/etoys did something close to that, many > concerns would be pacified. Yes, for GNU Smalltalk, these are not .sources file and .changes file but you can create an image file. BTW, Smalltalk-72 had a text file called ALLDEFS that is the bootstrap file for the entire system. For Smalltalk, bootstraping from a text file is not a new concept. While Dan and others were experimenting different ideas like image, somehow a part of free software community made very rigid by people who only know one way of doing it and now we are having this conversation. For those who are curious, try Smalltalk-72 emulator available here: http://map1.squeakfoundation.org/sm/accountbyid/a6930213-b578-49b1-862e-228cc5ab39e7/package/b98225e0-151d-4508-88fe-483db46f9814/autoversion/1 BTW, As pointed out many times, we are not sticking to Squeak because it is Smalltalk; but because it has Etoys. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
> > Each of image will make a .sources file so you > > get two .sources file. Then, use diff (perhaps you might want to > > convert CR to LF before that) to see the difference. > > Is this .sources output what Debian is asking for? If not, why not, > and what would we have to do to complete it from their point of > view? To be honest, I've missed the earlier conversation on this and I don't know somebody at Debian officially *asked for* a specific thing to make it meet their requirement... I looked back Holger's email and saw: -- The reasons are described in more detail in /usr/share/doc/etoys/README.non-free - readable for the next 72h at http://paste.debian.net/6962/ -- but couldn't see the URL. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
> >> There's also a warning at http://wiki.squeak.org/squeak that if you > >> want to run eToys, you need to run a different version of Squeak than > >> everybody else. > >> > > > > *That* is Etoys. What is wrong with it? > > > Just out of curiosity: > Exactly how is it different from vanilla squeak? (If there is such a > thing at all.) Whichever two images you would like to compare (why not write "Squeak"?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Each of image will make a .sources file so you get two .sources file. Then, use diff (perhaps you might want to convert CR to LF before that) to see the difference. > Is it a different VM, or just a different distribution since it has a > different binary blob? The VM is well synchronized with the trunk VM. They were identical a few weeks ago. We now have a few more patches in the OLPC VM branch but it is not significant. The VM is a separeted rpm BTW. Why do you refer it to as "binary blob"? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
John, I separated the real Etoys implementation part from your email. Hopefully it helps to focus on different aspects of discussion. > It took some searching, but I found a paper on the design of the guts > of Squeak: > > ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html > > I don't know if it is still good documentation for the current > implementation, but it gives some idea of how Squeak was originally > built. At the basic part on how it works, the paper is still valid and good. The performace increased since then quite a bit, and there are other semi-major improvements, but that is ok. Probably you can find a copy of the proceedings (OOPSLA '97) somewhere if you like the paper version. > The interpreter was written and maintained in a subset of high-level > Squeak (smalltalk) but there's also a translator that translates > that interpreter into C, which is then compiled to produce a binary > interpreter. Whether it does this dynamically or statically I have > no idea. Because it is into C, it is statically done. In the later versions and platform that support loading shared libraries (called "plugins") onto the VM, you could write some code for plugin in Squeak, generate C, compile the C code to make a shared library and load it onto the running Squeak session. But that is besides the point. > Then there's a separate Compiler that turns > Squeak/Smalltalk source code into bytecode objects that the > interpreter can run? Yes. The Compiler is written in Squeak and the compiled result of the Compiler itself is in the image. > There's another page that purports to talk about how a Squeak image is > built, but after explaining how most people "never quite feel at home > in a Squeak .changes file", it degenerates into details that make no > sense to an outsider. The paper definitely serves its intended audience (programming language designers and implementors.) The paper is cited quite often by papers from other language communities. > I haven't yet found similar documentation for eToys, which is > apparently something "built on" squeak rather than "built in"? Where did you find built on vs. built in discussion? It doesn't sound like an important distinction. The Etoys system is a bunch of additional code written in Squeak. There are some deep changes in the base classes of Squeak to support Etoys so it just happen to be distributed as a separated packaged version called Etoys. There is no good documentation (as far as I know) on how Etoys is implemented other than the source. But again, the code is nicely hyperlinked and the live system is there, learning it is possible if you know Squeak. (Etoys is like an application. How many applications you use have good documentation how they are implemented, though?) > There's also a warning at http://wiki.squeak.org/squeak that if you > want to run eToys, you need to run a different version of Squeak than > everybody else. *That* is Etoys. What is wrong with it? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Hi, John, > My only experience with Squeak/eToys up til now was trying it on the > OLPC as a naive user. Poking at objects on the screen with the > handles, since that was the only tutorial offered. The way the darn > thing "saved its workspace" in the friggin Journal whenever you tried > to quit it reminded me of ancient APL interpreters that contained a > jumble of code and data, and Holger's explanation of why it's > "non-free" reinforced that. Of course I have no idea how it's > actually implemented inside. (There's apparently no tarball that I > could unpack and examine to find out, either; I'd have to learn how to > run their GUI just to look at their implementation.) Is this discussion still on whether Etoys can be in Debian? Whether it can or cannot doesn't depend on whether Journal is friggn, the way it saves the workspace content, or the fact that you have to learn how to run (?) the GUI to look at its implementation. The fact that you better to (strictly speaking, you don't have to) use a particular editor is a requirement? (BTW, http://wiki.laptop.org/go/Smalltalk_Development_on_XO might be helpful. Read SqueakV3.sources as EtoysV3.sources in the page, though. http://static.squeak.org/tutorials/BankAccount.html is obsolete, but a classic tutorial.) Lack of some documentation is a problem, but once you know where to click in the GUI, *all* code are nicely hyperlinked together so that reading code and learning it becomes so easy and encouraging. That is why many developers who used to it lose motivation to write getting started documents^^; It is definitely learnable. There are many new (young and old) poeple get interested in Smalltalk all the time and poking around. Papers are published to prestige and not-so-prestige computer science conferences constantly on making deep changes to Smalltalk or making applications, etc. There are companies that are making products. By its nature, it is true that it is much, much easier to get started when you have somebody who already knows it around but it is sometimes hard to find such a person. But let us not derail the discussion. This discssion is not about making you like Etoys/Squeak. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] fixing etoys
> Yoshiki Ohshima wrote:
> > Again, start up time is not a problem. Etoys start up looks a bit
> > slow on XO, but that is because the DBus communication that has to be
> > done.
>
> I frequently hear DBus being accused of latency. As badly
> implemented as it might be, I can't believe a daemon relaying
> a bunch of bytes over a UNIX domain socket can introduce more
> than 1ms of lag per message, even on a very slow processor.
>
> Has anybody ever analyzed the actual DBus traffic? With timings?
> How many messages are we talking about?
It seems that you are right! I took profile data in Etoys and the
DBus part accounts for about 60-70ms on start up. Other 3 seconds are
spent on Squeak part and I think I could speed them up a bit.
The following two message tallys are taken from two different part
of code upon start up. They should cover most of it.
Sorry for the false alerm.
-- Yoshiki
--
- 1761 tallies, 2164 msec.
**Tree**
95.3% {2062ms} SystemDictionary>>send:toClassesNamedIn:with:
|43.2% {935ms} Delay class(Behavior)>>startUp:
| |17.0% {368ms} SecurityManager class>>startUp
| | |17.0% {368ms} SecurityManager>>startUp
| | | 17.0% {368ms} SecurityManager>>loadSecurityKeys
| | |16.8% {364ms} Object class>>readFrom:
| | | 10.6% {229ms} Array(Object)>>isKindOf:
| | | 6.2% {134ms} Compiler class>>evaluate:
| | |6.2% {134ms} Compiler class>>evaluate:for:logged:
| | | 6.2% {134ms} Compiler class>>evaluate:for:notifying:logged:
| | |6.2% {134ms}
Compiler>>evaluate:in:to:notifying:ifFail:logged:
| | | 6.0% {130ms} Compiler>>translate:noPattern:ifFail:
| | |6.0% {130ms}
Parser>>parse:class:noPattern:context:notifying:ifFail:
| | | 4.7% {102ms} Parser>>init:notifying:failBlock:
| | |4.7% {102ms} Parser(Scanner)>>scan:
| | | 4.7% {102ms} Parser(Scanner)>>scanToken
| | |4.7% {102ms} Parser(Scanner)>>xLitQuote
| | | 4.7% {102ms} Parser(Scanner)>>scanToken
[4.7% {102ms} Parser(Scanner)>>xLitQuote
[ 2.4% {52ms} Parser(Scanner)>>scanToken
[|2.4% {52ms} Parser(Scanner)>>xLitQuote
[ 2.3% {50ms} Parser(Scanner)>>scanLitVec
[2.3% {50ms} Parser(Scanner)>>scanToken
[ 2.3% {50ms} Parser(Scanner)>>xLitQuote
| |14.2% {307ms} FileDirectory class>>startUp
| | |9.7% {210ms} FileDirectory class>>setDefaultDirectory:
| | | |9.4% {203ms} FilePath class>>pathName:
| | | | 9.4% {203ms} FilePath class>>pathName:isEncoded:
| | | |9.4% {203ms} FilePath>>pathName:isEncoded:
| | | | 9.4% {203ms} LanguageEnvironment
class>>defaultFileNameConverter
| | | |9.4% {203ms} SystemDictionary>>platformName
| | | | 9.4% {203ms} SystemDictionary>>getSystemAttribute:
| | | |9.4% {203ms} SystemDictionary(Object)>>deprecated:block:
| | | | 9.4% {203ms} Preferences
class>>showDeprecationWarnings
| | | |9.4% {203ms} Preferences
class>>valueOfFlag:ifAbsent:
| | |3.1% {67ms} SmalltalkImage>>openSourceFiles
| | | 3.0% {65ms} FileDirectory class>>openSources:andChanges:forImage:
| | |2.6% {56ms} FileDirectory class>>openSources:forImage:
| |7.3% {158ms} ExternalSettings class>>startUp
| | |7.3% {158ms} ExternalSettings class>>preferenceDirectory
| | | 6.2% {134ms} SmalltalkImage>>vmPath
| | |6.2% {134ms} FilePath class>>pathName:isEncoded:
| | | 6.2% {134ms} FilePath>>pathName:isEncoded:
| | |6.2% {134ms} ByteString(String)>>convertFromWithConverter:
| |3.8% {82ms} Delay class>>startUp
|34.4% {744ms} WeakArray class>>startUp:
| |34.4% {744ms} WeakArray class>>restartFinalizationProcess
| | 34.2% {740ms} Semaphore class>>forMutualExclusion
|13.0% {281ms} AutoStart class>>startUp:
| |7.4% {160ms} AutoStart class>>checkForPluginUpdate
| | |7.4% {160ms} PasteUpMorph>>install
| | | 6.2% {134ms} PasteUpMorph>>installFlaps
| | |4.8% {104ms} Project>>assureFlapIntegrity
| | | 4.8% {104ms} IdentityDictionary(Dictionary)>>removeKey:ifAbsent:
| |5.6% {121ms} AutoStart class>>checkForUpdates
| | 5.6% {121ms} PasteUpMorph>>install
| |3.5% {76ms} PasteUpMorph>>displayWorldSafely
| | |3.5% {76ms} WorldState>>displayWorldSafely:
| | | 3.5% {76ms} PasteUpMorph>>displayWorld
| | |3
Re: [IAEP] etoys now available in Debian's non-free repository
Thank you, Jim! I've missed previous conversation on this one so it is probably redundant, but here is some additional information: > > We then make sure that the stage2 and stage3 binaries are identical. > > (This check has caught hundreds of bugs in gcc, binutils, and in > > vendor compilers.) > > > > Ah, yes, I remember this. I've even struggled to do this once or twice, > but that was about 15 years ago... Yeah, I used to just try it, too. (Incidentally, I needed to test GCC 2.95.2 compiler in this way in a few months ago. I needed to edit a few header files to make it work on FC7.) > > This is quite different from the eToys situation, in which there is a > > single binary implementation of the language; It is not a binary implementation of the language. > > and the sources, where > > present, are all mixed into a binary blob that's only readable by the > > single implementation. Not true. Just open .sources file and .changes file in /usr/share/etoys with your favorite editor that understands UTF-8 and can handle big files. The remaining stuff that some people might have concerns are pre-loaded contents. But these are contents and not different from a .sh shell script for shell or .py python program. > > I have the same concerns that Debian does. Is > > there even a tool internal to eToys that confirms that everything in a > > blob includes the matching source? Of course there is. Why do you imagine that there may not be? > > Let alone a tool that would > > extract that source and rebuild the blob from scratch, using a > > virgin binary environment. The sources is .sources file and .changes file. You don't have to extract it. What you can extract from the .image file alone is decompiled string. > > We could've bootstrapped GCC once, and limped along ever afterward > > with binaries built from that one original GCC binary. (In a sense, > > the entire C compiler market has done this. Bell Labs' original C > > compiler was bootstrapped from a BCPL compiler, and every other C > > compiler probably bootstrapped from Bell's C compilers.) Instead, the > > GCC maintainers built lots of infrastructure to allow GCC to be > > bootstrapped anytime somebody wants to. And to test it regularly. > > That's the part that eToys hasn't done. Start Etoys, open a workspace and type something like: SystemNavigation current allBehaviorsDo: [:cls | cls name displayAt: [EMAIL PROTECTED] cls compileAll]. , select it and press ctrl-D. The system just recompiles all method definitions from the source. Or, you can compare the previous result and new result by something like: old := Object compiledMethodAt: #printOn:. Object recompile: #printOn:. (Object compiledMethodAt: #printOn:) = old. (and it will return "true".) I sometimes do run this test for all methods when I change something deep in the Compiler. Yes, sure I do it multiple times so that the Compiler compiled by my Compiler generates the same code for the Compiler. > The VM (virtual machine), which is compiled using a C compiler and > exquisitely examined regularly for performance reasons, and recompiled > with some regularity with your favorite C compiler. As I understand it, > Squeak generates this C code itself. Yes, the debugging can be even done in Smalltalk. > This VM interprets the image file, and so this C code of the VM can and > is regularly examined, as Yoshiki points out, and for which the code can > be decompiled by tools and examined. In fact, the binary image is > routinely decompiled whenever debugging is done in Squeak. It is decompiled and then the corresponding portion of the .sources file or .changes file is brought in and shown in the debugger. So that the user can see the actual source (the exact way the programmer has written, with comment and proper indentation). > So as Yoshiki points out, it is actually feasible to complete this loop > and verify the binary in the image file has the same result; external > programs (have) exist(ed) to do so, in Yoshiki's example, in Squeak. In > this case, the Thompson attack seems unlikely; having Squeak able to > recognize you are compiling a program intended to decompile an image > seems pretty far-fetched to me (it isn't the same as a compiler > recognizing it is compiling itself). Again, nothing would be gained from making it externally, but it is highly unlikely that there is something hidden around the program part in the image. Nobody can prove that something doesn't exist, but from other content part has some malicious thing now. And it would be really hard to have the machine instruction pointer to point to a portion of ByteArray in the image and run it (for example). -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] etoys now available in Debian's non-free repository
After seeing that Jim Gettys and Alan Kay combined failed to convince a guy on a software issue, it is uncertain that how much I can add^^; But here goes: At Wed, 25 Jun 2008 00:04:36 +0200, Bert Freudenberg wrote: > > > Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler: > > > The gist of the argument is that one can't currently know what's > > really inside an etoys image, except beyond what it itself tells us, > > This is indeed a valid concern. As I wrote before, an external tool > could be written to examine what exactly is in the image. Yes, and the argument seems to be going as if having these tools externally would make some difference. However, I think that whether it is inside or not doesn't make any real difference. Frank, *all* bits in the binary image file is well-understood. In fact, we can open the binary file from an externally running program (called InterpreterSimulator written in Squeak) and examine every bits in the file. All bytecodes in the image file can be decompiled to human readable text files and that could also be done externally; not exactly that, but I once wrote such a thing. (It was modified InterpreterSimulator; wo it happened to be written in Squeak^^;) You can also "compile" all code by calling something like: SystemNavigation current allBehaviorsDo: [:cls | cls compileAll]. to make sure that the compiled bytecode in the image reflect the source code text (the code for the compiler included). For knowing what bytecodes do and how fast it runs, many people have been looking at the generated C code and assembly code for the VM to make sure that the VM does the right thing. (I mean many people.) Of course, one cannot prove that something (bad) would ever never happen with any piece of software; Squeak probably has some vulnerability, but we are not talking about vulnerability, but intentionally put malicious code, yes? We can (almost) assure that nobody has spotted any intentionally put malicious code in the image file. And subsequent incremental changes are either in the form of text change set, or some content. A sizable community will make sure that malicious code won't get in. I don't think Squeak's vulnerability is not particularly higher than other language interpreters (it would be somewhat lower than most of other scripting languages, as Squeak has somrestrictions on what you can do with external C libraries.) I can imagine a random analog would be a situation where an email client is compromized and executes the binary in an email it receives. But you wouldn't reject the client because of the vulnerability; rather you would fix it and use it as an example of strength of open-source development, right? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: fixing etoys
At Tue, 24 Jun 2008 14:16:22 -0400, Albert Cahalan wrote: > > Here are some ideas that might help you fix some of the problems > with start-up performance, shut-down performance, open source, > and software engineering practices. First, Etoys' start up time is very fast. And shutdown/saving could be very fast if we can save the whole image. What is slow is scanning relevant objects from the image upon saving, due to lack of modularity in the image. > You're trying to do a persistant system image on an OS that wasn't > really designed for it. If you were on an exotic system with a > persistant image (like EROS, KeyKOS, or OS/400), you might be able > to cut the power at any time without losing more than a few seconds > of work. The key here is that the persistant system image OSes > continuously write out changes to disk. They do this atomicly, > and in small chunks, rather than overwriting everything at once in > a dangerous non-atomic operation. > > Start with that. Break each object out into a separate file. > Your database becomes a directory rather than a big blob file. > When an in-memory object changes, you write a copy to a fresh > new file on disk. You keep the old on-disk copy around until > the new one has been synched. (fsync or sync probably, but be > very careful to avoid doing this more than once every few > seconds) You may need subdirectories for better performance; > it is very unwise to rely on Reiserfs-like performance when > having large directories. Saving the Squeak image to disk is not slow. (Back then, Ted Kaehler had a memory system called OOZE for older Smalltalk that does the checkpointing and constant object-grained swapping. ALTO had a memory problem that caused the system crashes once or twice a day without any reasons. OOZE kept people from losing their work except last 30 seconds or so.) > On-demand loading is required for start-up performance. Again, start up time is not a problem. Etoys start up looks a bit slow on XO, but that is because the DBus communication that has to be done. Otherwise, all it needs to do is reading a continuous 20MB file into a continuous memory region and scanning the memory once. > Inheritance from a read-only image will cut per-instance disk size. > On a Debian system, install the read-only image under /usr/share > and the per-instance changes somewhere under $HOME. On the XO, > the read-only image stays in the activity and the per-instance > part goes into the journal. For older XO system software which > does not support grouping multiple files into single Journal entries, > you'll have to do it yourself with a standard archive format. > There are three to choose from: tar, cpio, pax. > > To make things maintainable outside of the walled garden, store the > objects in text form. Make them be like nicely formatted source code. > Be permissive in parsing them, and try to preserve any comments that > might be added by users with regular text editors. Try to maximize > compatibility with GNU Smalltalk. But code and objects are different. Vast majority of incremental changes including object creation and setting preferences are already maintained outside of the walled garden. The latest image is (essentially) just a serial applications of updates available at: http://tinlizzie.org/updates/etoys/updates/ from an early image. > If you have bulk data that would not reasonably be editable with > a text editor, such as PNG images, then leave that part in binary. > > To cut down on dirty anonymous pages in memory, and thus greatly > improve the situation on low-memory swapless systems like the XO, > you could do mmap(...,PROT_WRITE|PROT_READ,MAP_PRIVATE,...) on the > binary blobs at startup. This should just be things like PNG images. I don't say there is a problem, such as the problem of modularity, and suggestions similar to yours have been made before. But it seems that you really don't know how it works and what are the real problems. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unicode for Etoys
At Thu, 19 Jun 2008 12:05:13 -0700, Edward Cherlin wrote: > > Trac Issue #4011 "Put the Pango support for Etoys in place." is marked > for Update 2. > > What is the holdup? This is a blocker for Mongolian Cyrillic, Greek > http://www.olpcnews.com/countries/greece/using_xos_in_greece.html, > Ethiopian Amharic, any Arabic trials, Dari and Pashto in Afghanistan, > and Cambodian Khmer. > > Issue #4894 "Support cyrillic" says that the code was fixed but the > fonts for Greek and Cyrillic weren't put in the distribution. > * milestone changed from Update.1 to Update.2 > > Oops. The greek and cyrillic fonts aren't actually distributed and loaded ... > > > What is the status? It is making progress again. New patches are pushed to the Etoys update stream, and a patch to the VM is sent around. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [squeak-dev] Re: squeak image sometimes takes very long to be responsive after XO suspend
I forgot to mention one thing. So, Ties, you might be already doing this, but one workaround for the problem is to instruct kids not to touch the keys or touchpad when the unit is suspended... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [squeak-dev] Re: squeak image sometimes takes very long to be responsive after XO suspend
Tomeu and all, At Fri, 16 May 2008 13:53:16 +0200, Tomeu Vizoso wrote: > > On Fri, May 16, 2008 at 1:50 PM, Ties Stuij <[EMAIL PROTECTED]> wrote: > > > > Basically when coming out of suspend, the Squeak process takes up lots > > of cpu power and can be unresponsive for about a minute on build 703 > > (other builds not yet tested). > > What about: > > - launch etoys > - check its pid > - attach to it with strace -p PID and log the output to a file > - suspend > - resume > - check what etoys is doing in that file > > Good luck, I'm now looking into this, but this may not be an issue with Etoys. I did strace but don't really see any anomaly. (Saw some interesting things, but.) Suppose I start Pippy and run the "Lines" example, and press the power button to suspend. The laptop suspends and the power LED blinks. But, here is an interesting happens; if I rub the touch pad quickly, or put my four fingers together on the keyboard (at shift, ctrl, tab and `) and slide them over the keyboard to cause a lot of key input (while the laptop is suspended), the the pattern of power LED blinking changes. The LED stays on for a while and turns to off, and come back to on, etc. If I press the power button while the abnormal LED pattern is going, the button press is often ignored. Or, it wakes up one second or such but goes back to sleep. If these things happen, waking up the unit takes time. Etoys doesn't have to be running. When Etoys is running, but you don't touch the laptop while it is suspended, it doesn't happen (that often). This is on a G1G1 machine, update.1-708 with the firmware that comes with it. I created a track ticket (#7196). -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Video from last week's country meetings.
> Please let me know the exact URL you had trouble viewing, and > double-check the sizes against the index listing on > http://download.laptop.org/content/conf/20080520-country-wkshp/Video/2008-05-20/ > to ensure you have the whole file. There are multiple versions of > each talk, and it's possible that I goofed encoding some of them, but > it's tedious for me to view them all (again!) to figure out which one > you might have been having problems with. The source DVD seems to be > complete, so I should be able to correct any problems you find. For the Alan's talk, the audio part does go all the way to then end, but in the middle of talk, a USB device detection sound occurs, and a Window explorer covers the screen, and the video part froze there. The page is: http://download.laptop.org/content/conf/20080520-country-wkshp/Video/2008-05-20/13-Beyond-Printing%20(small).html It is hard to explain, but if you just access the above page on a computer, and ignore it 20 minutes and come back, you'll see what is the problem. (During the actual talk, the audience didn't see that problem, so the problem could be at the encoding time and if that was the case, it would be nice to correct it from the orignal recording.) I haven't tried the ogg version. Sorry. > On the other hand, I can't help it if the slides for some of the talks > are uninformative =). (Actually, I'm already doing what I can, which > is trying to get video to supplement the slides.) Perhaps getting Alan's Etoys image for the talk might be good? Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Video from last week's country meetings.
At Mon, 26 May 2008 14:58:06 -0400, C. Scott Ananian wrote: > > On 5/23/08, C. Scott Ananian <[EMAIL PROTECTED]> wrote: > > I've posted the agenda for this week's country meetings, and slides > > from most talks, at: > > http://wiki.laptop.org/go/Presentations/May_2008_Country_Workshop > > This includes Nicholas' talk on Tuesday where he announced the XO-2. > > I've now encoded and uploaded video from all of last Tuesday's talks; > links at the url above. Hopefully I will be able to get a copy of the > videotapes for the rest of the week tomorrow and start encoding and > posting them. I'm missing some Friday slides that I'm trying to chase > down as well. Thank you! However, the video part of Alan Kay's talk is frozen at one point and never comes back. Is it possible to resurrect it? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: View Source question
> So, I'm really not (at this time) interested in peeling layers, or that > it's a no-brainer in squeak, or frankly (again at this time) deeper > implications or philosophy. > > The philosophy is interesting and challenging, but I just want to figure > out how to implement a feature that the XO was supposed to have. Mainly > so that it can be there to show 'hey, we said we'd do this, and we did it'. I didn't mean to contribute any philosophical discussion. All I'm saying is that if you want to say "'hey, we said we'd do this, and we did it'", you can write your code in Squeak and that is it. Hit Alt-, or view source key and, say, open -> browser, or hit Alt-. and get the dynamic execution context, etc. You can modify the running code on the fly, etc. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
ideals and practice (Re: View Source question)
Edward, I put Reply-To: header (I don't know if it goes through). Please send the reply to Its.an.education.project, if it continues. For the middle part of this email, you are just paraphrasing what I wrote, so I see not much difference. > This is a great thread. It is bringing out a lot of useful information > from many points of view. You ask good questions, Yoshiki, which is a > more important skill than giving good answers. It's a pleasure to work > with you. Thanks! (this wasn't sarcasm, right?^^;) > > I'm not sure if Python has that edge over Squeak, but probably it > > does. > > From which point of view? A significant fraction of the world's > software infrastructure is now implemented in Python, and Python is > clearly a more appropriate language for the novice than BASIC, C, > Pascal, Java, or the other languages usually favored in education and > commerce. I have been always agreeing with that (Python has been used widely and have a big mind share). Python is the practical choice, even though the creator doesn't seem to like the project (Open Source is great^^;). If "access to most of the rest of the GNU/Linux world" means to access the mind share, documentation, and etc., it is simply true. But, if it was about viewing the source of the rest of the GNU/Linux world in the environment, Squeak can just do the same as any other program written in any other programming language. (BTW, I never suggested that Squeak/Smalltalk should have been used.) > The issue is not technical superiority on some measure. It isn't. My point was that people who know about computer systems would like to show a technically better system to kids, if it is somewhat used as a reference. (Not that I think most of kids are going to see the code, nor I claim there is another practical platform exists.) Some may say "hey, if you don't know an alternative, just accept the status quo." But this project has been going for a while, and the longer times goes the more interesting the question "if we had started from something different, where would have we been" become. > > And, it wasn't conceivable to actually do in that short > > time, an OS-less system would have made more sense for the target > > system; as you know, Ivan was thinking the possibility of "full Python > > machine".) > > Eh, LISP machine, Smalltalk machine, FORTH machine, APL machine. All > great technical innovations, all market flops, if they were even > implemented fully. Computers should be general-purpose. Currently, dominant architectures are essentially C and Fortran machines. And as Jecel wrote, market flop and technical superiority are just very different things. My boss sums it up by saying "evolution doesn't optimize", meaning that the natural selection process only makes an "ok" situation (unless it is on the dying branch), but doesn't reach the best possibility. > Now if somebody wants to design and implement a Parrot machine that > will support dozens of languages, we can talk. But Parrot isn't > ready. Yeah, timing is always bad. VPRI's new project is not ready at all. > > If we are trying use the OLPC XO as the trojan horse of > > disseminating a better idea of computer including operating system, it > > is unfortunate that we needed to use Linux. It is the most practical > > system to use in the short term, but basically we are using it because > > it is the de-facto standard. (And people are rather thinking it > > better because it is not Windows. Strange. Without real education > > content, neither is good enough.) > > Linux is, of course, way better than Windows. Not least in supporting > better education software and content, because we can integrate > security, collaboration, and fantastically low power consumption into > the kernel. It is probably true for security. I don't know if it is true for collaboration and low power consumption. Especially for collaboration, what would prevent Windows and apps on it to be collaborative? -- Yoshiki (My flight was delayed 90 minutes, but I finally arrived Kendall Square...) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
contents (Re: View Source question)
> > Creating content that is culturally and personally meaningful to children > > across the world is a huge challenge. > > The thorny issue of content has also been a subject of debate from the > very beginning. The gist of the debate was in regard to the proper > balance between OLPC providing content vs countries and 3rd parties > taking responsibility vs community content vs providing tools for > children and teachers to provide/localize content. We haven't yet done > enough along any dimension. Just the framing of the debate itself is > probably flawed. It is. (Sorry for the tone in previous emails.) It is almost clear that OLPC is not going to do the contents work but the new organizations would be a good place to do so. Hopefully, the countries should do the curriculum making (teachers' participation would be even better), but since we try to set up a richer learning environment than conventional education, the burden is higher. And, to share/alleviate the burden, some organization should have even more seeds for content that the teachers and educators can grow from and tailor to their needs requirements. In short, it would be more work, and I was wondering what kind of changes was on horizon. I posted a rough description of such a example to the other mailing list, hpoing to get more volunteers to do the similar so that we would have a big repository of examples. Then, teachers can pick and choose and extend some examples and make their own. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: View Source question
> Indeed, that is one of the virtues of Squeak. Python was somewhat of a > compromise in this respect, but it has the virtual that opens up ready > access to most of the rest of the GNU/Linux world. I'm not sure if Python has that edge over Squeak, but probably it does. > Alas, this is a feature that, as has already been mentioned, hasn't > had enough time and attention yet. It'd be nice to "architect" what > view source means in these different environments to provide a > starting point for developers as per the original post in this thread. "Yes" in one sense. ... But, here I'd like to change the topic a bit (and it would be more suitable for the its.an.education.project mailing list). If there is any real operating system researchers around, they would "raise eyebrows" when they hear the idea of letting the kids learn Linux as *the* example. Remember the discussion between Linus Torvalds and Andrew Tannenbaum, and Tannenbaum was right about Linux has nothing great in regards to its technology. Linus was great at forming the community by listening people, but its success wasn't about its technology. (There are arguably better systems like OpenBSD. And, it wasn't conceivable to actually do in that short time, an OS-less system would have made more sense for the target system; as you know, Ivan was thinking the possibility of "full Python machine".) If we are trying use the OLPC XO as the trojan horse of disseminating a better idea of computer including operating system, it is unfortunate that we needed to use Linux. It is the most practical system to use in the short term, but basically we are using it because it is the de-facto standard. (And people are rather thinking it better because it is not Windows. Strange. Without real education content, neither is good enough.) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Etoys] squeak image sometimes takes very long to be responsive after XO suspend
> Basically when coming out of suspend, the Squeak process takes up lots > of cpu power and can be unresponsive for about a minute on build 703 > (other builds not yet tested). Hmm. Interestingly, windows VM has similar problem. If you suspend Windows with Squeak running, resuming takes long time, and you have to "send" a lot of user events by moving mouse a lot. > Also we loose sound. Which sometimes comes back after a while. Either > on it's own or perhaps because another application is opened. This > could be a coincidence though. This is bad, too. I wonder a button that calls: SoundPlayer shutDown. SoundPlayer startUp. and press it when the symptom occurs resets it or not. > Especially the unresponsiveness is a problem, because it messes up the > classes. Typically a teacher will explain a concept after which the > students will do an activity for a short while. After which they will > close the XO again to go on with the rest of the course. The XO's > can't stay open because they are to distractive and because they eat > battery power, and perhaps take up to much space (the benches these > children work at are tiny). Having to either wait for the activity, or > restart the image (or XO, whatever the child feels comfortable with) > kills the flow, and the children get very impatient. This should be fixed, yes. We should try strace'ing Tomeu suggested, and possibly we even should investigated the situation on Windows. Thank you for reporting. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: View Source question
> What's the best path for making an activity 'view source' friendly? > Reverse engineering from Chat, which is? Some other way? Perhaps you could write it in Squeak. The entire dynamic and static state and environment including source code is readily available for "viewing" to the user, and you can even make on-the-fly changes. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: very simple datastore reimplementation
> and that's it. It's a trivial thing, will work on any fs, on any OS, > no magic tricks needed. We can do fast searches on based on the > "documents metadata", and the only "slow" op is mounting a device > where the documents metadata is stale or missing. I like along this line, too. In fact, Journal can be mostly a smarter version of "recent documents" feature. That can hide the hierarachical file system, and present "documents" in the time-based view. On a file system that doesn't support the owner/group permission, an activity could mess up the other activities data; but the user can do it from the command line even for the internal file system more or less. I would imagine that separated metadata can be optional. For Text-type documents (including Etoys), we can as well just make the tags in the document itself. For a picture, it can be EXIF and can have comments, etc. Any file can have comments, and since we are operating some limited kind of files anyway, the Journal can support them one by one. On a related note: tagging the document at a separate place wouldn't work well (http://dev.laptop.org/ticket/6128). This is another reason to make the "tags" just appear inside documents. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 15 computer science collegians looking for a project
> We are a group of 15 collegians, studying 'Applied Computer Science' > at the University of Applied Sciences in Iserlohn (Germany) and we > are looking for a project for the OLPC within the scope of our subject > "Computer-Networks". Our professor (Prof. Martin Hühne) let us choose > our own topic, leading us directly to our first problem: What can > we do? Are some of you interested in a help system? Depending on the context (i.e., what the user is doing), the help system would access the locally stored help content, or go online and fetch relevant help and show it. Could be coupled with keyword search. Some members can write the retrival mechanism, some others can write the search engine, some others can create contents, etc. Just a thought, -- Yoshiki P.S. To the following, many would oppose, but how about putting a little friendly character on screen so that the user can ask some questions? We toyed with the idea to have two characters that also talk to each other so that the user is not so intimidated. In different incarnation, camera and microphone can be used to determine how much the user is concentrate on the screen, etc. and give different advice. (Well, making a good one along this line would be much more than 3 months work anyway, so don't worry about it, but there may be something along this line.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Auto backlight management?
At Thu, 24 Apr 2008 22:43:53 -0400, John Watlington wrote: > > > Bert misread the spec. When the backlight is switched off, the screen > automatically switches to B&W mode. Why would you want to take > that out of the control of the user ? Did he misread the spec? What you wrote here and what he wrote there: - There is, however, a DCON mode specifically designed for the b/w reflective case, the anti-aliasing can be turned off and a color-to- gray mixing turned on, but again, this is done manually (in the current UI it is coupled to turning off the backlight). - sound like the same thing. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [squeak-dev] Re: to be deployed Epaati version is out!
Ties, Please try attached change set. In Epaati-10, it seems to remove almost all objects. (There are uninstanciated uniclasses left; that may have to be removed by calling some methods like: Player abandonUnnecessaryUniclasses and Player removeUninstantiatedSubclassesSilently -- Yoshiki MoreOkTochange-yo.1.cs Description: Binary data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: to be deployed Epaati version is out!
And, compiling textual code, including class definition, etc. in the file out part of the project is quite slow. I noticed that some projects have seemingly unnecessary class definitions of Players (I don't know why these are there), and if you can eliminate them in one way or another (you can see it in the that would help. The Football game project has fairly large class. I would suggest to have the class be part of the image so that the project doesn't have to compile the code upon loading. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: to be deployed Epaati version is out!
> I'm playing with Epaati-10 a bit. Entering > Grade2/Math/Unit4/IIM4_2_money identification.011.pr and coming back > (the instance of Project did get collected, but the accompanying > PasteUpMorph serving as its world along with all objects and players > are lingering. Now, I'm (again) looking at the issue so hopefully I > get to something... Just a progress report, but the issue is basically around #rootsIncludingPlayers not finding all classes, and the problem is caused by a project that has scripts that reference to an object that was trashed. Namely, - You created object A and object B. - You wrote a script C at object B that refers to object A (This creates the uniclass for B). - You wrote a script D at object A that refers to object B. (This creates the uniclass for A). - You dismissed/trashed object B. - The project was saved. What happens is that to keep the script D running and project working, the system exports the object B into the saved project as well. But because it is trashed, it is not "in the world", but referenced from the scripts. Epaati loads such a project, and upon exiting the project, it tries to remove the project. From #okToChangeSilently, #rootsIncludingPlayers is called to find the uniclasses used in the project. But the logic only looks at the objects in the world, and overlook the object B and the B's uniclass. Because B has a script that refers to A, pretty much everything in the project is kept because the world is reachable through A's owner chain. I still think Etoys/Smalltalk is almost suitable for what you are doing, but loading and unloading a lot of project in a session wasn't a typical use case. In a sense Epaati is stretching it. But it is fixable fortunately. One thing we definitely should do is to make #rootsIncludingPlayers better. I can think of a few different ways. One thing you should do is revisit your projects and make sure that every object refered to from the project to "live" in the project. IIM4_2_money identification.011.pr, for example, has quite a few of such objects. To check these guys, open a workspace in a fresh epaati.image, and evaluate: old := PasteUpMorph allInstances. Then load IIM4_2_money identification.011.pr and come back. In the same workspace evaluate: new := PasteUpMorph allInstances. new := (new copyFrom: old size + 1 to: new size). new := new select: [:e | e knownName = 'page']. and look at the submorphs of these pages bound to new. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: to be deployed Epaati version is out!
Hello, I think you used the display scaling a lot... The biggest problem with it is that it defaults to 32-bit depth Display and all artwork loaded into or created became 32-bit depth. You could look at the SketchMorphs in it and convert them to 16-bit (or even 8-bit with some loss of quality) to save the space at runtime and on disk. (It looks like halo is disabled in the projects. How can I get it back for debugging?) > One of our most pressing problems has to do with continual image > growth, when opening multiple projects. After opening and closing > around 20 projects on an XO, the amount of memory the vm uses > (according to the vm stats), has climbed from 60 to 95 mb, and soon > afterwards we get an out of memory error. > > First I thought that old projects were lingering around, but they do > seem to be garbage-collected eventually. There is no reference or > pointer to them to be found in any case. I haven't had the time to do > any space profiling to see who or what could then be the cause of the > trouble. I'm playing with Epaati-10 a bit. Entering Grade2/Math/Unit4/IIM4_2_money identification.011.pr and coming back (the instance of Project did get collected, but the accompanying PasteUpMorph serving as its world along with all objects and players are lingering. Now, I'm (again) looking at the issue so hopefully I get to something... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Community-news] on Sugar
At Wed, 23 Apr 2008 23:47:09 +0200, Hilaire Fernandes wrote: > > 2008/4/23 Korakurider <[EMAIL PROTECTED]>: > > > So I am assuming the policy would apply to effort porting activities to > > windows. > > But this should make us much slower... > > Not necessary. Application developed within Squeak/Smalltalk will for > most of them do not need any porting effort. Not necessarily, yes. But if they want to have a layer on top of Windows, and require the COM interface and blah-blah-blah, making Squeak play nicely with it wouldn't be too effortless. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] Lieutenant Governor Pat Quinn on HB5000
At Thu, 10 Apr 2008 22:10:45 -0700, Edward Cherlin wrote: > > On Thu, Apr 10, 2008 at 9:04 PM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > > There was been strong Etoys experiment going in Illinois, especially > > at Columbia College and UIUC. > > Excellent. Can you point us to some groups or individuals, or > published documents, or whatever? The SqueakFest site from last a couple of years would be handy: http://imamp.colum.edu/eceim/squeakfest07/ http://interactive.colum.edu/partners/squeakfest/ Carol Ann Stowe and Valerie Scarlata would be good contacts. http://imamp.colum.edu/eceim/squeakfest07/contact.php For people at UIUC, check out http://squeakcmi.org. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] Lieutenant Governor Pat Quinn on HB5000
There was been strong Etoys experiment going in Illinois, especially at Columbia College and UIUC. I don't know how much olpc-chicago overlaps with that group, but it would be nice to be able to say that "we already have been doing the test of (a part of) software long time in the state." -- Yoshiki At Tue, 8 Apr 2008 20:42:36 -0700, Edward Cherlin wrote: > > On Tue, Apr 8, 2008 at 7:59 PM, Jameson Chema Quinn > <[EMAIL PROTECTED]> wrote: > > This is fascinating. I would say that the first triaging you should do to > > make this a reality for September is to reduce the number of grade levels > > you target to an absolute minimum. More than 3 would be crazy, two is > > better. > > This is presently set up to be the choice of the schools or school > districts. But we can of course inform them of the resources currently > available, and what might become available. > > > Possibilities: > > 6/7: pros: 2/3 of the students in a junior high, yet you can count on > > having most of them there for 2 or 3 years. cons: late grade = lots of > > testing; jealous 8th graders. > > > > 3/4 or 4/5 : good ages, but not good saturation. > > > > 3/6 : good variety, more logistics. > > > > Once you decide this, a lot more will follow. > > I want to do K-2. The laptop works well for illiterate users. It has a > minimum of text and a maximum of icons in the Sugar User Interface, > and we will have literacy software built in. I also want to do 3-5, > the ages where we know we can have the maximum impact with programming > in Smalltalk. We will have to have the whole discussion, and not try > to optimize beforehand. > > "Premature optimization is the root of all evil."--Donald Knuth, > quoting C. A. R. Hoare > > > Also I had a link for you: http://www.ck12.org/ <-- just starting up but has > > some funding and possibly an inside track to getting more, trying to make > > open-source textbooks attractive to public schools, worth giving them a call > > to see if they are interested in (ready to) collaborating with you. Illinois > > would definitely be a feather in their cap. You need all the help you can > > get with can get with content. > > Excellent. They are just up the road from me. I'll go see them right away. > > > Good luck! > > > > Jameson > > > > > > > > On Tue, Apr 8, 2008 at 4:49 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I talked with Ryan Croke of Illinois Lieutenant Governor Pat Quinn's > > > office today. They are keen on this project, and would like to arrange > > > for us to assist in getting the program designed for the best possible > > > outcome. HB5000 is moving rapidly through the House, and will then go > > > to the Senate, which is likely to turn it over to the Education > > > Committee for public hearings. We should organize to bring our XOs and > > > our children to Springfield for the hearings. > > > > > > Among the questions: > > > > > > Schools will be allowed to choose from among the available laptops. > > > The program should capture the differences in outcomes between schools > > > using different hardware and software, using appropriate measures LG > > > Quinn's office agrees. Nicholas Negroponte is strongly opposed to > > > "bake-offs", but the world doesn't work the way he wants. > > > > > > We need to work with the legislature, the Education authority, and > > > with schools on appropriate integration of laptops into curricula, and > > > provide at least draft versions of electronic textbooks on all > > > requested subjects. Much of what we want to do has yet to be designed. > > > In fact, the software that we want to build the textbooks on has in > > > some major cases yet to be designed. How much can we promise for the > > > start of the next school year in September? That depends very strongly > > > on who steps up to do it. > > > > > > It is very important in pilot projects to do good experimental design > > > before hand so that the results contain usable information, not merely > > > data. We need to talk to people who know something about these issues, > > > who also understand what we are trying to measure. > > > > > > What training can be put together for the summer before? We need to > > > demonstrate the meaning and value of learning by doing through > > > collaborative discovery, aka Constructionism. Then we need to provide > > > the toolkit for teachers to apply it, and provide feedback mechanisms > > > so that their experience and insights steadily improve the process. > > > > > > This program requires dedicated resources, and management, on our side > > > and several others. That means that we need to look for funding. > > > Anybody know a good grant writer? > > > > > > No Child Left Behind creates perverse incentives that can interfere > > > with the program. Can we get waivers from the Federal Government for > > > the trials? > > > > > > -- > > > > > > > > > > > > Edward Cherlin > > > End Poverty at a Profit by teaching children business >
Re: Open Simulator with Physics Engine
It is not something done with a physics engine, but there are a few particle systems written in Etoys. For example, if you launch Etoys, click on "Gallery of Projects", and click on the thumbnail third from the left in the bottom row. It is an ideal gas simulation (in 2D). You can modify the parameters like pressure (called "gravity" because the green top wall is falling down all the time), and turtleCount that controls the number of gas molecules. But also you can modify the actual simulation code while the simulation is running, change stuff in the script called "oneStep", or perhaps you can assign different values to the "speed" variables to these molecules' own variables, etc., etc. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to create a new MIME type for a Sugar activity?
At Mon, 11 Feb 2008 17:35:59 +, Martin Dengler wrote: > > Is there a possibility to make a distinction between "ability to > handle" and "claims [as the default handler]"? As an outsider / > random developer, I understand why Etoys should declare it can handle, > say, text/html, but I don't understand why Etoys should be the default > handler for text/html. It seems that "the infrastructure for it is already in place": http://dev.laptop.org/ticket/6145 The (similar) issue is lingering some months: http://dev.laptop.org/ticket/2535 http://dev.laptop.org/ticket/3273 For text/html, Etoys doesn't have to be the default... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to create a new MIME type for a Sugar activity?
Albert, > > The MIME type of application/zip works, but Etoys is > > using that one too. > > Whatever you invent, Etoys will claim it in the next release. > It does not matter if Etoys has any ability to handle the data. No. If it is something that somebody invent for their app, we don't have to do that (unless it makes sense). > I'm half serious too, as is clear to anybody who has looked at > the list of MIME types claimed by Etoys and tried them. > Almost none make sense. It's like some kind of land grab. The last one you brought up, MIDI, was left behind with the Journal integration effort but now it is fixed, BTW... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity hosting application: Time
Hi, Jason, > My point is that to get kids understand the sense of time, the > programmer doesn't have to build a single "the game"; like what you > have on the wiki page, in a game, a kids walks up to the blackboard > and write something. There, if the activity has simple yet flexible > interaction, they can make more "games". So, the good focus for a > programmer would be to provide such a interface. > > but how one would go about providing that interface? How would one like you, right? Think and experiment, I would say. One idea is to make an "active essay" on it. There are bunch of "active essays" on the net (google "active essay"). An explanation in text written in one place with interactive elements on the side. On computer, that is a powerful technique of explain something. > I wouldn't count on it that much (you know how China deals with > timezones, and how summer is like in high-latitute places, right?). > > We were looking for a way to change the position of the sun based on the > longitude and latitude and time of year(xearth > seemed promising). I'm actually not sure how china deals with time zones, > but as long as the laptop's system time is > correct, I don't think that should be a problem. It is up to you, of course, but I would try to find a simpler solution. Historically, the position of the sun was used in the definition time; however, as more variables put into the concept, it now is more "artificial". Verbal explanation is unavoidable for artificial concepts. > Ah, but stuff like "60 seconds is 1 minute", "60 minutes is 1 hour", > "24 hours is a day", "but the face only has 12 numbers", etc. are not > that "discoverable". > > Hopefully that would be something they would notice with moving the clock > hands and seeing the digital clock change to > 59 seconds/minutes before 00. I thought you were suggesting that we need some "explanation"? Letting people notice something is not usually easy. Kids and adult can be easily superstitious when seeing some phenomena without explanation. (We say that modern science was invented only 400 years ago in the human history of hundreds of thousands of years. Carefully observing something requires a lot of preparation and training.) > When I attended a conference in Chicago, a presenter from UIUC gave > a talk. In the talk, she showed a blank map of Illinois and started > with a remark: "Welcome to Chicago! But do you know that, outside > Chicago, there is a larger area called Illinois?" For an outsider > like me, Illinois is one thing so I thought you might know her.^^; > > I see your point, but seeing as cooperation in the olpc project started with > the new year, I don't have any connections > outside of the IMSA chapter. There wasn't really a point here; it was rather just a joke (shall I explain what is funny about the joke? ^^;) Sorry for making random guess. Again, the above is just my suggestions. but don't be shy about doing different stuff. My boss often tells me that "Most of ideas are bad. The trick is to abandon bad ideas quickly." (Not that your ideas are bad, but better ones may be floating around.) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to create a new MIME type for a Sugar activity?
Hello, > 1). The Etoys activity does not try to open the file, at all, ever. > EToys takes a long time to start up and shut down and it is really > annoying when I open the file with EToys instead of my own activity. For for the record, Etoys doesn't take a long time to start up. It is the fastest activity to start up. The shut down time can be optimized in a "lossy" way that we might take after all. (And, if you hold the "stop" button for a second, you get a delayed menu. From there you can say "quit without save".) > 2). My Activity *does* open the file. > 3). The Zip files containing images show up in the Journal with my own > Activity's icon, which looks like a slide projector. > > To accomplish this I have created my Zip files with the extension > ".slides" and I'd like to be able to use the MIME type > "application/slides" for such files. > > I'm also interested in creating a reader program for Gutenberg etexts. > I'd like these files to have their own MIME type too so they don't get > opened by the Write activity by mistake. I was thinking of using a file > suffix of ".book" and a MIME type of "text/book" for these. > > I tried using a mimetypes.xml file in the bundle but that didn't work. > I couldn't find an example of an Activity that used such a file so I'm > not certain I'm doing it correctly. > > I'd appreciate any information on MIME types or on alternative > approaches that would solve problems 1-3. Thanks much, Etoys is probably the good example^^; Looking into the "tree" for Etoys (http://dev.laptop.org/git?p=projects/etoys;a=summary), etoys.xml which will be installed to /usr/share/mime/packages by Makefile(.in) and activity.info(.in) that lists the accepted types. Of course, if you write your slide show in Etoys, that would be a lot faster (and easier for some people)... Hope this helps, -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity hosting application: Time
Hi, Jason, > Translating the 12 hour to 24 hour notation of the submission to whichever > the other player is using shouldn't be a > problem. Also the game isn't time zone dependent. Translating these isn't a big problem technically, yes. Again, I was just thinking that that wouldn't be the kick-ass feature for an educational clock activity. (When I attended a conference in France, the organizer wrote "20h30" on the blackboard and said "the night session begins at twenty-thirty". Some in the audience reponded: "And, what time is it exactly?") > Do you envision that these two kids connect to each other when they > don't understand what the other's language and find a good time of the > day when they can connect, and discuss about an artificial and > abstract concept like time? > > True, perhaps discussions would be less helpful, but I think the time game is > still something that would help. My point is that to get kids understand the sense of time, the programmer doesn't have to build a single "the game"; like what you have on the wiki page, in a game, a kids walks up to the blackboard and write something. There, if the activity has simple yet flexible interaction, they can make more "games". So, the good focus for a programmer would be to provide such a interface. > I think the natural time clock should be close enough to the actual > appearance outside so that the children will connect > the ideas. I wouldn't count on it that much (you know how China deals with timezones, and how summer is like in high-latitute places, right?). It would be nice there is *also* an abstract form of explanation. > Also, the clock can be updated to the time it is right now. Thus in that > way it should be its own > explanation. Ah, but stuff like "60 seconds is 1 minute", "60 minutes is 1 hour", "24 hours is a day", "but the face only has 12 numbers", etc. are not that "discoverable". > It appears that you are a high-school student... That is really > great! Please don't take above as discouragement. I'm really trying > to encourage people who are trying to make educational activity (as > you know, there aren't many for XO.) It is really valuable to see > that somebody (who is young and close to the target age group!) think > about making activity. > > I am a senior at IMSA, and am aware of the development process, so I know > your comments aren't discouragement. Thanks! > Do you know Kathleen Harness? > > Should I? Well, she is helping Etoys activity contents development, and her group at http://www.squeakcmi.org/index.php is for example hosting an "OLPC meeting" (as on the web). Also, she was on a local newspaper recently. When I attended a conference in Chicago, a presenter from UIUC gave a talk. In the talk, she showed a blank map of Illinois and started with a remark: "Welcome to Chicago! But do you know that, outside Chicago, there is a larger area called Illinois?" For an outsider like me, Illinois is one thing so I thought you might know her.^^; -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity hosting application: Time
Hi, Jason, > I filed a ticket sometime ago (http://dev.laptop.org/ticket/5255). > I sure wish something like this will be incorporated. > > I think this should be covered in the dragability of each individual hand. Very good! > Another ticket that seems to inspire you > (http://dev.laptop.org/ticket/2778) > > This was the main basis for the project, and we believe we addressed all the > issues raised in the comments. Some say that designing is completed when nothing cannot be removed. In other words, trying to address all the issues raised by random people is not always a good idea. (It includes the issues raised by me as well!) > discusses timezones and > collaboration. But I'd say that these are secondary issue. Who > believes that it is worth to pay the effort to have kids in Nigeria > and Brazil look at each other's clock and discuss something (Could > they discuss something worthwhile?) If you can move hands at will, > that would be much better. > > The time game would allow for collaboration, and also for (perhaps) > meaningful discussions between two children I was talking more about practical issues like the language difference and (yes) time difference, 12 hours vs. 24 hours notation difference, etc. As you wrote below, kids won't "discover" these concepts by their own. Do you envision that these two kids connect to each other when they don't understand what the other's language and find a good time of the day when they can connect, and discuss about an artificial and abstract concept like time? > As a child you can't understand time(in the form of a clock) until it is > explained to you. Which is where this > activity will (hopefully) come in. I wasn't saying that kids can make stuff before understanding it. There needs to be good guidance that leads them to the deeper understanding. (For some more background, refer to some discussion around http://squeakland.org/pipermail/squeakland/2007-August/003719.html and hopefully the video linked from the email.) You wrote that your Time activity have analog, digital and natural display of time but with these, you have to "explain" it to kids. What kind of supporting material do you think is needed? Can the explanation be on the laptop as well? Can it be interactive? Can the explanation and the real thing be seen on the same screen at the same time? It appears that you are a high-school student... That is really great! Please don't take above as discouragement. I'm really trying to encourage people who are trying to make educational activity (as you know, there aren't many for XO.) It is really valuable to see that somebody (who is young and close to the target age group!) think about making activity. -- Yoshiki Do you know Kathleen Harness? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity hosting application: Time
At Thu, 31 Jan 2008 18:16:04 -0600, Jason Rock wrote: > > 1. Project name : Time Sounds good! > 5. URLs of similar projects : None that I know of You might have looked at Clock and concluded that these are substantially different, but you know the Clock activity, right? (It doesn't matter, but just to make sure.) I filed a ticket sometime ago (http://dev.laptop.org/ticket/5255). I sure wish something like this will be incorporated. Another ticket that seems to inspire you (http://dev.laptop.org/ticket/2778) discusses timezones and collaboration. But I'd say that these are secondary issue. Who believes that it is worth to pay the effort to have kids in Nigeria and Brazil look at each other's clock and discuss something (Could they discuss something worthwhile?) If you can move hands at will, that would be much better. Actually, I'd say that adding the built-in game would be secondary as well. If kids can interact with the clock in very easy and simple way, they sure will invent their own "games"; such as puzzles, timer, etc., etc. (not everything may not be on the laptop, but that is ok). -- Yoshiki Yes, that reminds me of the idea of scriptable clock; http://dev.laptop.org/~yoshiki/etoys/Clock.004.pr It would be nice if kids "make" their own Clock to understand it better. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Using Matplotlib in Measure Activity
At Thu, 31 Jan 2008 12:38:01 -0500, Benjamin M. Schwartz wrote: > > On Thu, 2008-01-31 at 01:32 -0500, Arjun Sarwal wrote: > > For some time I have been thinking about extending the functionality > > of Measure Activity into a tool that also allows for graphical > > analysis of data acquired not just from sensors/mic but data acquired > > from any source. > > (1) A standard format for data sets. > > (2) To allow for a variety of multiple views, representations and > > basically allowing more control over the way data is represented > > What you are describing is precisely the plotter component of any > standard spreadsheet. In my experience, plotting data is by far the > most common use of spreadsheets by children. I would welcome such an > Activity, and indeed, there is an effort to provide a spreadsheet for > OLPC. > > I do not think is makes sense to merge measurement of signals with data > analysis. I would suggest that "Measure Signals" and "Process Data" > should be separate activities, with an easy Keep-Resume path between > them. Really? What happens if a kid want to see real-time data in different way(s)? If there is an oscilloscope that is only able to show data from 10 seconds ago or such, it would be useless. Let us say we write an equivalent thing of Measure in Etoys. Then, kids can make their own graphing tool interactively. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Classroom tools
At Tue, 15 Jan 2008 14:11:40 -0800, Edward Cherlin wrote: > At the schoolroom level, the difference is between knowing rules for > manipulating variables, and understanding what a variable is. > (Basically, a variable name is a pronoun that can refer to a different > number each time it is used.) Caleb Gattegno was particularly good at > inducing understanding of arithmetic and elementary algebra using > Cuisenaire rods. Everybody involved in XO software and content should > read his work. In fact, a Cuisenaire rod activity would be brilliant. Yes. In fact, the idea of making the numbers viewable as rods and making them addable in Etoys has been popping on and off quite while. Scott Wallace even has an experimental implementation. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Classroom tools
"One way or another" is what I wrote, and letting them cut papers and weigh is a great idea, I think. As you wrote, it is important to have teachers understand, or able to help, impotant ideas. And assembling a repository of what are impotant ideas and techiniques to teach them would be essential addition to the current OLPC effort. -- Yoshiki At Tue, 15 Jan 2008 00:13:58 -0800, Edward Cherlin wrote: > > On Jan 14, 2008 10:06 PM, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > > > But let me say one more thing. Making use of "constructionism" theory > > > doesn't means the unnecessity of the teachers, but the role of the > > > teachers changes. > > > > Yes, I think tools for supporting teacher who want to do the > > traditional style of teaching is eventually necessary. > > > > And, even in "Learning learning", many subjects that are invented > > are not discoverable by kids' own. (Alan Kay said "Children are not > > going to invent calculus".) a kid should be helped by teacher(s) in > > one way or another to learn "powerful ideas". > > Alan Kay has examples of children discovering parts of calculus with > some assistance. > > It is important that teachers know about the really important ideas, > and about how to introduce children to them without thinking that they > can simply teach it in language. I started working on a Kindergarten > Calculus idea a while ago. Show the children that you can put a > straightedge against any shape to get the direction of that shape at > that point. Ask why the straightedge is level at the top or bottom. > Assist them to find the third case in which the tangent can be level. > That's the essence of differential calculus. The rest is deriving > formulas and doing calculations. > > Similarly for integral calculus. Draw a figure on paper, cut it out > and weigh it. Now, how can you help children to discover that these > two operations are inverses? That's the Fundamental Theorem of > Calculus. (I have a solution, but I am sure that there are others.) > > Given that we can teach understanding of the fundamental ideas in > Kindergarten, we have the opportunity to rethink at what ages the rest > can be brought in. Traditional thinking is that you can't start until > the students are capable of understanding all of the subject. This is > very close to complete nonsense. Weapons-grade bolonium, in fact. > > > -- Yoshiki > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > > > > -- > Edward Cherlin > End Poverty at a Profit by teaching children business > http://www.EarthTreasury.org/ > "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Classroom tools
> But let me say one more thing. Making use of "constructionism" theory > doesn't means the unnecessity of the teachers, but the role of the > teachers changes. Yes, I think tools for supporting teacher who want to do the traditional style of teaching is eventually necessary. And, even in "Learning learning", many subjects that are invented are not discoverable by kids' own. (Alan Kay said "Children are not going to invent calculus".) a kid should be helped by teacher(s) in one way or another to learn "powerful ideas". -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Give One Get One laptop for software development
Edward, > Yeah, I discovered that yesterday when I got my physical machine. Congratulations! > I've been build my emulated XOs from the ext3 images as described > somewhere on the wiki. If there's a way to build an emulated XO > using a jffs2 image instead, I'll switch over to that. I noticed the issue while ago when a friend of mine mentioned the thread on his blog: http://d.hatena.ne.jp/sumim I should have let you know earlier (sorry). The good news is that we have *some* disk space, at least, more than you originally thought^^; -- Yoshiki BTW, sumim-san's blog is a fun one for Rubist, especially for those who has opinions on Smalltalk^^; ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Give One Get One laptop for software development
Edward, > a. There isn't enough room for the RPM on the base 1 GB hard drive. This, and what you wrote to the Ruby mailing list makes me think that there is some differerence between your environment and a typical installment on XO. A clean installation of later Update.1 gives me about 65% free space. your emulation environment doesn't take the compression of jffs2 into account, or you have something else installed? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Give One Get One laptop for software development
Jake, > How do you swap out the window manager? I missed the question earlier, sorry. The simplest thing is to edit /usr/bin/olpc-session. The last line of it reads currently: exec /usr/bin/sugar You can change it so that: #exec /usr/bin/sugar twm& exec xterm Then alt-ctrl-erase to restart the X session. If frees up 80MB or such. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Conway's Life activity
Hi, Ross, > I think it would be neat to have a dedicated activity for it, with the > ability to save interesting patterns in the journal, and so forth. I'm not sure if a dedicated activity is neater or not (I know people who would say "yes"), but it is surely possible with the Etoys version to save interesting patterns in the Journal. Different rules, different ways to make the initial state different colors, more variables, more states, etc., etc., can be all packaged in a Journal entry. The logic to count the neighboring on-cells is end-user accessible, and it is packaged as well so that the user can even change that. (After all, I just wrote it while I was waiting for an appointment at a clinic. That means anybody can just do it if you have an XO.) You could write a script so that the you "paint" the picture of an initial state and set it. > I was planning to put in a rule-editing system not unlike Autocell: > http://www.topshareware.com/Cellular-Automata-download-9567.htm > (I couldn't find any pages about it, just the download link. Fairly > old Windows program.) Could you elaborate the rule-editing system of Autocell at any chance (over the holidays^^;)? I thought a rule-editting system in which you can specify the before and after state visually is nice, and also the concise description people use would be also nice for different audience. But of course there will be much more different ways, I'm sure. Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Conway's Life activity
That reminds me of a version in Etoys. http://dev.laptop.org/~yoshiki/etoys/LifeGame.006.pr The nice thing about Etoys version is that you can edit the rule dynamically by drag-and-drop while the simulation is running. You can just try "what-if" simualtions whenever you like. On some installations, it may run very slowly; a plugin for accerating the particle system is missing in the VM. Try it after we resolve the issue. One can think to write a graphical DSL for specifying CA rules in Etoys. That would be a fun project for hackers... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Give One Get One laptop for software development
Danilo, > I'm a student at State University of Campinas, Brazil. I'm researching > efficient implementation of Elliptic Curve Cryptography in constrained > environments. I'm working with an ARM XScale PXA270 platform but would > like also to work with a x86-based constrained platform. I think the > OLPC laptop is an interesting option for many reasons. > > I'd like to know if one of those laptops of the Give One Get One program > are suitable for software development? I guess so, but would like to be > sure. > > Do I need any special hardware or cable to connect to the OLPC laptop > from my desktop? A telnet or SSH connection is all I need. It highly depends on what you want to develop and how. From what you described, you are not interested in developing software for for Sugar. If so, you can certainly replace the window manager to, say, twm and start a terminal emulator to use the X Window System in somewhat more conventional way. The size of your program won't be too large, so GCC should be fine to compile your software with the memory XO have. You can of course compile your software on another computer and copy to run. > I want real timings, so I think an emulated solution would not be > suitable. It sounds like you will want/need to do some assembly language programming. Geode LX has some features to generate random number sequences (and AES accelarator). I thought it has some statistic counter stuff, but don't know how to use it (or I don't know what it is, in fact). As others wrote, the XO keyboard is not great... But I'd say with some training, it is not unusable. So it is conceivable to do the whole development on XO. (What are the "many reasons" that makes it an interesting option for you?) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Etoys] Smalltalk development on XO
Karl, > > Any comments are welcome. Thank you! > Looks really good. I noticed a few issues with the code representation. > Maybe add a link to http://squeakbyexample.org/ Oh, I meant to say "any comments and corrections are welcome". Please edit and fix! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Smalltalk development on XO
Hello, I wrote a little wiki page that explains how to start and do Smalltalk development on XO. It is still "draft" status, but hopefully it gives interested people something to look at: http://wiki.laptop.org/go/Smalltalk_Development_on_XO Any comments are welcome. Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Voice IM project proposal
> Just as a reminder, there is push-to-talk already built into EToys, > though I haven't tried it for awhile--it certainly used to work just > fine. Ah, yes. I remember that now. We are not exactly happy with the UI and the push-to-talk nature and unoptimized long latency, but it still seems to work nicely on later Joyride builds. To try it: * Put two XOs on the same mesh so that they can see each other in the neighborhood view. * Start Etoys on one of them (let us say this is machine A.) * You probably want to dive in to a "new project" by clicking the top cloud on machine A. * from the menu bar at the top, press the share button (circle with a dot) and choose "My Neighborhood" on machine A. * a few seconds later, the shooting star icon is visible on machine B's neighborhood view. * On machine B, click on the shooting star in the neighborhood view. This will connect these two instances. (Just a normal way for any activity on XO.) * If the sharing works properly, you will see a "badge" on each machine. Click on yellow "A" button on each. * You'll get an obscure, small UI. There are three checkboxes. Check the right most box on each machine. * Hold the button labeled "Talk" on machine A (or B), talk to the microphone, and release the button. You'll hear the voice on the other. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Status of Develop.activity?
> The old 8-bit computer BASIC editors often would simply refuse to > let you enter bad syntax. The language was also quite easy. Sorry to > all the LISP fans out there, but "220 GOTO 200" is really easy for kids > to understand. The XO is sorely lacking in something so easy to use. > The other stuff (Python, Smalltalk, Java, etc.) is really hard > compared to BASIC. Well, if one were trying to discourage kids, then > the modern stuff would be perfect for that. > > I have to admit that VB development is very easy to start with. > Things would be really different if kids could "draw" an activity, > click on objects to add bits of BASIC, and then click to spit out > a *.xo that is fully functional. The sweet spot of these versions of BASIC with line numbers is around 20-100 lines of programs, and you wouldn't do too much of object-oriented GUI programming, etc., etc in it. It is still ok for writing and learning simple programs, but writing a useful .xo in it would be something I wouldn't recommend. Nerds had written 10s of thousands of lines of code, but you wouldn't recommend that in the 21st century, right? (Of course I don't agree that Smalltalk is really hard compared to BASIC, but that is different story.) (No, that Etoys thing again!?) And, you can readily do syntax- and namespace-aware interactive editing of Smalltalk in Etoys/Squeak on XO, and make an "executable" with full multimedia capability and everything on XO for XO, basically. (There is a missing piece to make the actual .xo file from Etoys project. Bert did the "proof of concept" work and we would need to make it accessible to people). You can even do the RAD style programming, BTW. > Finally we have the problem of NO systems programming language > being supplied. It's less than 9 MB for the whole C development > environment, including a decent collection of *-devel packages. > You even get a second language thrown in for free, x86 assembly. > Pretty much everything that matters is written in C, including > the Python interpreter. That was your point in November as well: http://lists.laptop.org/pipermail/devel/2007-November/007947.html but there are two responses to that post. (About the actual size and also the runtime memory requirement.) Did you look at them? > This I like to hear. Eating one's own dog food is very good. Yes. I like it, too. I could do virtually all my development work for Etoys on XO without compromizing too much (just the keyboard with harder to use shift keys and a bit of sluggishness.). > Note that non-activity developers need to put aside some RAM > for the activities. (sugar developers, I'm looking at you!) > Booting with "mem=128m" ought to do the job. In less than a > year, the system memory usage has more than doubled. I hear > that people are actually doing development on workstations > with lots of RAM and fast CPUs, and it shows. I share the same feeling here. 128MB is pretty big chunk of memory. I went to Cambridge several times in last two years and observed that the designers were making UI mockups on a faster computer in Adobe Illustrator and Photoshop. The visual appearances were indeed pretty good for the first glance, but also that seemed like a recipe for making bloated UI for a slow computer. I wish the design work would have been done on slower computers. In that way, you can get better guess on the actual performance, the memory usage. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Official signed ship.2 candidate 650
> Official signed images for build 650 are now at: > http://download.laptop.org/xo-1/os/official/650/jffs2/ > You can also use: > olpc-update 650 From what version should I try this? Naturally my B4s are loaded with 135x. Should I install (signed?) 648 and Q2D05 first? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
Thank you one more time, Morgan, > Due to scalability issues, Ship.2 (the G1G1 release) is configured with > a non-existant jabber server, ship2.jabber.laptop.org. We are working on > server scalability for Update.1 which will enable the use of a server > without totally killing it for everyone. That plan is to only show > presence for a limited number of XOs in Neighborhood view, consisting of > your friends, some XOs from the same network segment as you (being XOs > on the same LAN or same part of the ISP's network to give some sort of > "near you" presence, and some random XOs - with some way to search for > other XOs so you can "friend" them. Ok. And, it answers some questions I had as well: http://lists.laptop.org/pipermail/devel/2007-October/007055.html > In the mean time, G1G1 users can consider > http://wiki.laptop.org/go/Run_your_own_jabber_server (not for the faint > of heart though). This sure will happen^^; I have to admit that I didn't know that the control panel was already there. So, it is conceivable that one good highschooler can set up and invite others in town to there. Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
Thank you, Morgan, I just imagined that having the "ask expert" key, (a la "view source" key) would be handy and the familiar tool (i.e., the Chat) can be used to ask the people with proper background... Just 0.03 USD. -- Yoshiki At Tue, 04 Dec 2007 10:32:08 +0200, Morgan Collett wrote: > > Yoshiki Ohshima wrote: > > I signed up the mailing list. But the IRC is not what the Chat > > activity on the XO uses, right? > > No, Chat is based on Jabber. (It uses PS's chat rooms, not 1-1 IM, and > the rooms for activities are obscurely named as they use the activity ID > in the JID, so while it is possible to use a desktop jabber client to > talk to a Chat instance, it's not easy...) > > There is an IRC Activity (http://wiki.laptop.org/go/XoIRC) although I > don't know whether it will be included by default. > > Since Telepathy has an IRC connection manager, we should investigate > using that on the XO... > > Morgan > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: clean installation of 643.
Thank you, John, > The autoinstaller is not working properly. This is a known problem, but > given that the preferred method of upgrade is now over the network, it > has not been a priority. Is preferred method really over the network? I'm so ignorant about it, but what is the current theory of upgrading? Does the current scheme let people download a 300MB file over the wireless? (I haven't tried it by myself, but does T-Mobile connection stable enough to let them do it generally?) There was long discussion of partial update, XO-to-XO update, etc. How is it going? Or is it just working? > To install the firmware from a USB stick using OFW: > flash path_to_file >where path_to_file is usually something like u:q2d05.rom > You can use: dir u: to list the contents of the USB stick. > > To install a build from a USB stick using OFW: > copy-nand path_to_file > > This will overwrite all data on the laptop. Make sure to backup > anything > you want to keep! Yes, I have been doing this now and then. Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
Hi, Kim, > To start, I think it will be great to be on the olpc irc channel. We can also > start an olpc-support channel and there > are some people working on a 'community-support' mailing list > (please sign up if you like). I signed up the mailing list. But the IRC is not what the Chat activity on the XO uses, right? > As we get more organized we'll post other ways that people can help > to answer questions and provide support. Great! > Thanks for asking! Well, I know I'm asking for trouble. But at the same time I'm curious to see. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
Hello, I don't know the plan of any sort, but presumably there will be the users of XO through G1G1 in the US and Canada (and other places) very soon. Is there any a jabber server (say) for them, or a forum, mailing lists of sort that they are going to be directed? Would a developer with B4 be able to look at it or participate it and see how software working for them (and possibly trouble shoot)? -- Yoshiki At Sat, 1 Dec 2007 13:47:58 -0500, Kim Quirk wrote: > > [1.1 ] > > [1.2 ] > Yes! If you have a 'secure' machine running 649 (ship2 release) you will be > able to open the browser; click on "other" > on the left hand side, then on "about your xo". > > This will bring you to a "tour of the laptop". Scroll all the way to the > bottom to find the link "apply for a developer > key". > > We just got the link in there at the last minute, so it might move to a more > prominent position in the future. > > Regards, > Kim > > On Dec 1, 2007 1:39 PM, Gerard J. Cerchio < [EMAIL PROTECTED]> wrote: > > Alexander M. Latham wrote: > > --- Yoshiki Ohshima wrote: > > Great! but sorry for my ignorance but what "a signed copy" means? > > Shall we test it on our (B4) laptops? Or it'll make it hard for > > future update? > > > > > http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ > > > > is the same thing but "unsigned"? > > > > -- Yoshiki > > --- end of quote --- > > > > Signed means that it will work on a write protected machine. If you're > laptop is not write protected, the unsigned > version will work exactly the same. > > > > - AlexL > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > > > > > Is it going to be possible to unlock a G1G1 for development? > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Gerard, > I am properly admonished and shall hold my performance speculations > until my machines arrive. I just wanted to mention that it is not conceivable. (I even took a picture but forgot to put a link: http://dev.laptop.org/~yoshiki/pictures/pict0425.jpg ) The performance is probably a less-challenging issue. Giving flexibility to developers and users while proctecting an activity from others is another thing. I thought using another activity as a library in yours in the same address space was something the security people would like to avoid. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed 648 (ship.2 release candidate)
> A signed copy of build 648, which is our ship.2 release candidate, is now at: > http://download.laptop.org/xo-1/os/official/648/jffs2/ > This build contains firmware q2d05, available separately at: > http://dev.laptop.org/pub/firmware/q2d05/ Great! but sorry for my ignorance but what "a signed copy" means? Shall we test it on our (B4) laptops? Or it'll make it hard for future update? http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build648/devel_jffs2/ is the same thing but "unsigned"? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Thank you, Mike, > That said, activities which use the high-level components only might be > able to be ported just by rewriting the Sugar APIs with a Win32 > compatibility layer a port of Telepathy and a bit of bailing wire. That > might let children communicate and access the materials... but that > would be a fairly involved project, and I don't know if we'd find all > that many Win32 developers interested in attempting it. That would be useful for longer term. TamTam on Windows would be cool so you can jam with a Windows user over the net, for example. > > And, I see that one of the biggest downside of our software is that > > kids cannot participate the software development effort from their > > laptops (except...). If we are to look at different platforms, it is > > nice to think about easy support of on-laptop-development. I don't > > care if it is on Windows or Mac OS; on top of Windows (or Mac OS), you > > as an end-user can still do a lot. (Basically the same argument in > > "filtered Internet access is better than no Internet access".) > > > Yes, we really need to get "Develop" development un-stuck. We currently > have only Pippy (which doesn't do files) and the Squeak IDE available > on-machine. We need that full Python IDE available for the children > ASAP. After all, we've got a whole key on the keyboard devoted to it. > Even if the IDE is just file-open/close/create, file-tabs and syntax > highlighting it would be sufficient to start programming on-machine. Yes. Maybe a Python IDE in Squeak is not a so bad idea. At some time soon, somebody in Etoys/Smalltalk community need to write up how to start Smalltalk programming on XO, such as making writable copies of etoys.image and etoys.changes to a directory and turn "eToyFriendly" preference off, etc. (Ah, that is almost it^^;) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Gerard, > Yoshi, I think full OLE would be very limited by the hardware. I > have no hardware, > I have experience with an older generation geode on the Jhai PC project > without the video > sub-processor, and find in many cases, the geode is the little chip that > could, but full > multi media documents running multiple renderers seems out of the > resources' reach even > to this geode fan. Well, I know that I can make a user document with a running movie clip, real time view-finder of camera, spectrum analysis of audio input, and a user-scripted simulation going at the same time on B4 (4-5 fps is not so great though). These widgets are running in the same address space but that is offset by some facts such as Etoys display model is not optimal, our code for playing movie, copying bits of video frames to make the player a real end-user scriptable object, FFT are not optimized, etc. It should be possible to provide an ok experience for most of the time and I was not talking unrealistic rant, I believe. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Active activities as Widgets
Hello, > > I would like the ability to exploit other active activities in my own > > activity. > > Rainbow is designed to specifically disallow this. What I'm going to write here is not really based on the current code (of which I don't know too much detail), but just an idea (tually based on an idea of my colleagues)... If activities do not always have to run in full-screen, and each activity exposes some of its capabilities and properties so that they can be accessed via DBus or some other inter-process messaging mechanism, these activities don't have to be running in the same address space, and don't have to share files to work together. X Window System can surely display many windows and doesn't care if these windows are created from the same process or not. To the user, a window created by a process for an activity would just look like a fat "widget". It would be OpenDoc on X with process separation, sort of. In a sense, this would not be that big departure from current Sugar+DBus combination. A security system for it could still decide which activity can see whose property, so it can be effective. > > If a video conference is already active, and the participants wish to > > PlayGo I would like to have a panel in the PlayGo application that > > allows the video call to continue throughout the game. I came upon this > > idea when I was trying to duplicate the Chat activity within PlayGo just > > to allow the players to talk to one another. I asked my self, why > > duplicate code, connections and system resources that are probably > > already running in RAM? > > Sugar will gain a feature called overlay chat, once we've got higher > priority collaboration stuff completed, which will automagically add > chat functionality to any (sugarised, python) activity. There's no time > frame on this feature yet though. But think about more general cases. Imagine a user wants to create a multimedia document with movie, audio, text, painting, etc., etc. laid out in one document on one screen. (Let's say a realization of BulletinBoard activity.). If you can use existing activities to write yours, it would be so simple. To the user, it just looks like a multimedia document and each of these media objects are alive, but internally, they are different processes, looking at different directory, and doesn't know each other. I think OLPC people heard about it and/or thought about it. I admit that if each activity consumes 15MB or such, this wouldn't fly. Nonetheless I think this is an iteresting thought. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: clean installation of 643.
Alex, > In the future, if you're only updating the ofw, you should just get > to the ok prompt and type: ok flash path_to_file Yes, I know that, but it is not a good way to check if there is a bug or not^^; > Also, after the firmware is upgraded, it reboots the machine, which > would then lead the machine into trying to do an upgrade instead of > a clean install if you don't hold the square key. That is probably > why it created a backup and tried to restore from it. This means > there may be some issues with the auto-reinstallation process, which > should be looked into. Yes, that explains. Thank you! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
clean installation of 643.
I tried to do clean install of 643 and it failed. Actually, it worked
for the first time. Then, I realized that I forgot to put Q2D05
firmware on my USB memory. So I put the .rom file and tried the clean
installation again. Then during the boot process I got:
--
Restoring from backup
tar: Short read
Traceback (most recent call last):
File "/init", line 110, in
backup_or_restore()
File "/init", line 87, in backup_or_restore
do_restore()
File "/init", line 77, in do_restore
safe_sh("tar -xz -f " + backup_file + " -C /restore")
File "/initutil.py", line 26, in safe_sh
raise RuntimeError("Command exited with non-zero exit status.")
--
-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: kids cannot participate (was Re: WSJ)
> > And, I see that one of the biggest downside of our software is that
> > kids cannot participate the software development effort from their
> > laptops (except...). If we are to look at different platforms, it is
> > nice to think about easy support of on-laptop-development. I don't
> > care if it is on Windows or Mac OS; on top of Windows (or Mac OS), you
> > as an end-user can still do a lot. (Basically the same argument in
> > "filtered Internet access is better than no Internet access".)
>
> The fix is simple.
Cool.
> At bare minimum, the build process should ensure that all the various
> *-devel RPMs can be installed. Right now they do not all install.
> I'm unable to get SDL-Pango and librsvg. Just a few days ago we were
> missing libX11 and even gcc itself.
> Note that a **very** complete development environment is only 9 MB.
> That includes the C compiler, all the standard header files, and
> even the odds and ends like libSDL.
Wow. That is almost too good to believe. I did install gcc while
ago (and tried it now as well) and compiled some stuff. "yum install
gcc" downloads 8.5MB of files (extracted files would be bigger on
disk), and "make" command is about 0.5MB. Other stuff such as X11
headers, etc., etc. were not included in "odds and ends"? How much
disk space do you think we need for making, for example, a .xo file
for a simple app? The svn and git clients are not a part of a
"complete development environment?
> It's a crying shame that the laptop includes every impractical
> sandboxed toy out of academia, but fails to include **the** systems
> programming language. All of the important things are written in C,
> including Python!
Even if it will be additional 50MB or such, it is just equivalent of
dozens of high-res pictures. Yes, it would be nice to have an easy
install of a "complete development environment" for XO on XO.
(Too bad the development of Develop is stalled.)
-- Yoshiki
I don't understand what you are implying in this paragraph ("every",
"impractical", "sandboxed", "toy", and "out of academica" Some
words may apply to some activities we have, but connecting them
together doesn't make a meaningful sentense), but yes, it is a shame
that most of developers even don't try to develop their software on
it.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: WSJ
> > It's not About the Hardware: > > In principle, that is true. > > In practice, it is the hardware that has been responsible for all the > attention. Alan Kay once said: "Reality is a low-pass filter." (High-frequency ideas cannot go through it.) > If the project had been just a software framework to support > constructivist education, the worldwide response would have been "ho > hum, yet another program/operating system/GUI/whatyoumaycallit". Thank god our project is not like that. With that hardware and great software and content (that potentially also work on other hardware) will make a kick-ass learning platform. The latter needs more attention to really achieve that. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WSJ
Mike, > but if a country wants to choose Classmates or EEEs, that's fine, we > *still* want to help educate those children. Yes, I totally agree with this, and other sections on teacher training and documentation, etc., etc. > * we should port to the other inexpensive laptops, if a country > decides to go with EEEs or Classmates, we should be in there > offering an EEE or Classmate-optimised Sugar + Activities + > Content that they can load onto those machines > o we should also port to the thin-client-style setups seen > in e.g. Canonical's deployments of computing labs in the > developing world It sounded in the article, though, that some countries have chosen Classmates because of MS Windows. How about porting parts of current OLPC software that is worthwhile for Windows users? What would such parts be? And, I see that one of the biggest downside of our software is that kids cannot participate the software development effort from their laptops (except...). If we are to look at different platforms, it is nice to think about easy support of on-laptop-development. I don't care if it is on Windows or Mac OS; on top of Windows (or Mac OS), you as an end-user can still do a lot. (Basically the same argument in "filtered Internet access is better than no Internet access".) -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC XEyes
> Voila. Now you have an "Eyes" project in your Journal ready for > endless hours of sillyness. Exactly. One of such sillyness (with educational value in mind^^;) was my Clock Project. It (hopefully) shows the power of user constructable sillyness has actually some value... http://dev.laptop.org/~yoshiki/etoys/Clock.004.pr http://lists.laptop.org/pipermail/devel/2007-November/007666.html -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Acoustic distance measurement applications
Ben and everybody, The multiple-click problem prevented me from trying the acoustic distance measurement activity for a while, but finally I could do it last night on 637. Thi is pretty cool! This reminds me of a story I heard from my boss and I thought you would be interested in it, too: --- The graph activity was by some Physics professors at Tufts University, including Ron Thornton (who has been a major figure in physics education via computers since the Apple II). He has lots of stuff online (but I couldn't find the specific reference for this work (ca. 1990). Basically, they found that a pre-test that would accurately predict the final grade was apptitude at reading graphs. Then they decided to try teaching some of their students how to read graphs -- and one of the main ways was to use a Polaroid camera range finder on the screen of the computer and the student using whole body movement back and forth to try to match different graphs on the screen: distance, velocity, acceleration, etc. They reported that this worked very well. We made a Hypercard version of this and tried it on children and teachers and found it worked very well. --- Basically, looking at a graph and acting as a component or derivative of the graph is a great way to improve physics "sense" and it results in a better grade. He thinks that using the "whole body" instead of just finger tips is a key. This would be a great match with Acoustic Measure. For this purpose, perhaps the interval of noise should be configurable and can be made shorter, and the read-out values should be able to be used by other things like a graph drawing/showing program. Also, have you thought about making an explanation for kids, perhaps in the form of an "active essay"? The current implementation is a bit like a magic, and I bet many kids who try it would say: "it can measure the distance because they are 'talking' to each other" or something like that based on the "story mode" of thinking when asked how it works. A kid-accessible scientific explanation would be very nice. Since the essence of the measurement should be very, very small (perhaps just one or lines, leaving all the details of binary sequence and speed of sound variation), that would be a quite fun reading for kids. Just my 2 yen. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Because somehow this email arrived to may inbox three months later,^^;, it is a good time to write a reminder. > 1) eToys: > It would be very nice to have support for Analog Input in eToys. For a month or so, Etoys has a support for Analog Input, in a sense that it can basically do what amixer does. Etoys has been supporting audio input and various ways to analyze it. For example, if you launch Etoys, go to the treasure box, bring Object Catalog out, go to "Multimedia" category, and bring up "SpectrumAnalyzer". By talkin, whistling, etc. you can see what it does. It has different kinds of display, etc. However, the current SpectrumAnalyzer was written more or less for a demo, and not really up to the real use. As I summarized at: http://dev.laptop.org/ticket/4586 Combined with the underlying facility for analog input in Etoys, kids could write their own programs by using the input data to analyze it and play with it. Also, we could show the same data in different representations, such as time domain and frequency domain, at the same time side by side, so that a wave can be viewed in various ways. I asked Arjun while ago if he would have time to try to enhance SpectrumAnalyzer in Etoys. He said after polishing up Measure for these deadlines, he wants to give it a shot (I still think he is the ideal person). However, if others on the list have ideas and time and desire, please think about enhancing SpectrumAnalyzer (or write a better one). Thank you! -- Yoshiki <>___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates for Update.1 from Joyride
Jim, > So in short, we're screwing down the lid on Update.1. But we likely > have to do a Ship.2 build, and that on top of a feature release is a bad > idea, so we'll let Update.1 slip and be sane about letting it be ready > when it is ready, rather than having to throw it over the wall on > December 1, ready or not. There are bugs that are fixed in 637 but not in 623. Do we just close these bugs on trac, even though we know that they do exist in a version that is yet to be shipped? I think the answer is yes, but just checking... -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Telling time (was: StopWatch activity)
> -1 to the idea that we should deliberately leave out features in order to > encourage kids to program. O, ye of little > faith. I don't see anybody said this, but yes, that would be bad. The environment should come rich set of tools/widgets etc. that make the environment "rich". Several clock examples should be part of it (That is why I just made one). But, these tools should be used by kids to make more stuff, and also these should be "openable" to see inside. That is what I mean by saying "kids should be making clocks." -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Etoys] A "Clock" project in Etoys
> > http://dev.laptop.org/~yoshiki/etoys/Clock.004.pr > > > > One way or another, please load it onto Etoys (on a non-XO > > environment, drag-and-drop from Finder or Explorer. On XO, access the > > URL with browse, copy it to a USB memory and resume it from Journal, > > Ugh, is downloading and resuming projects directly broken again? This > used to work fine. Yup. Testing this kind of use case was another purpose of this exercise. Just clicking on the link in Browse doesn't seem to do anything except saying "download complete". On the Joyride build at some point yesterday, I can drag the link from Browse to the Frame, choose "Add to Journal" in the menu that pops up when I do mouse-over on the icon, go to Journal, and resume the entry. Obscure, to say the least. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Telling time (was: StopWatch activity)
Nick, At Thu, 15 Nov 2007 17:13:34 -0500, nick knouf wrote: > > > Bert Freudenberg writes: > > > > > I question the very assumption that continuously telling > > > the time is even remotely important on a learning machine > > > for kids in elementary school age. > > > > Dealing with time is a critical life skill that must be learned. > > Having a clock is thus very important. > > Whose time? Hours minutes seconds? Days since a recent feast? When > the sun is at a certain position in the sky? Since I last saw you on > the road? How much do I quantize? Is quantization of time even a > concept I am familiar with? Well, it seems that you are responding to a wrong message. > The notion of time is _highly_ contingent on situated cultural > factors. Just because in the West we measure things using hours, > minutes, and seconds, does not mean that the entire world does so. > In fact, our conception of time is directly related to churches and > clock towers in the middle ages (see Lewis Mumford on this idea) > first, and then assembly lines and educational/disciplinary > institutions (see Foucault) . The rest of the world has not > necessarily adopted our way of dividing days into ever smaller > chunks---perhaps there is no quantization at all! > > A clock application, especially given the areas of deployment, is > _not_ something you rush into with the assumption that you can merely > write a graphic display of 00:00:00. One must understand the local > conditions to know how time is told _on the ground_ and be careful to > not impose a Western notion of quantization and temporal division > that might be entirely foreign. So, what do you think about the idea of letting kids make their own clocks? -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
A "Clock" project in Etoys
Hello, After having a conversation with one of my colleague (Ian), I couldn't resist, and I happened to have some spare time while helping a TA as an unofficial TA. So I made a Clock project in Etoys. The file is available at: http://dev.laptop.org/~yoshiki/etoys/Clock.004.pr One way or another, please load it onto Etoys (on a non-XO environment, drag-and-drop from Finder or Explorer. On XO, access the URL with browse, copy it to a USB memory and resume it from Journal, or hit Alt-, for "Show Source" -> 'open...' -> 'file list...' and navigate to the .pr file). After it starts, don't forget to move the mouse around! The fun thing about it is that only non-trivial thing the user needs is a text version of Clock that is available in the Object Catalog. Everything else is built with simple Text, Ellipse, Rectangle, and Star. (The digital clock uses another pre-made widget.) The essense of rotating the analog clock hands is three equations each of which decides the angle of a hand. The script shown in the project has such three lines. In the other words, kids don't have to know any more magic than setting the heading of objects. (The script has other two lines, but these are used to provide some effect for the digital clock.) You can change the equations dynamically to make, for example, the clock goes backward. The variables are accessible to the user, so learning about the clock, such as angles and rate, etc. can be done from this project. -- Yoshiki There is a bug. If the digits in the analog clock is truncated, press "resetResult" button. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
