[OLPC library] etoys implementation

Wed Jun 25 16:24:04 EDT 2008

Very well, let's create some Etoys documents.

On Wed, Jun 25, 2008 at 1:55 AM, John Gilmore <gnu at toad.com> wrote:
> 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.

You are clearly unclear on the concept. It is not that some essential
tutorial is missing. The handle halo is in fact the entire user
interface to visual objects. Everything else is accessed by opening a
code viewer from the handle halo of any visible object (the eye icon
on the left side of the halo), and navigating from there. What is
missing is a description of the object hierarchy and some modest
guidance on exploring it.

It would be useful to have a novice programmer's tutorial specific to
Etoys in the OLPC Library, of course, to explain a bit of the
navigation and the way to work with objects and their methods. Or it
may be that we just need a FAQ.

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

I'm not clear why you call an APL workspace a "jumble". There are
commands to list the functions and the variables separately, and you
can easily view the code of any function. Furthermore, people wrote
utilities to dump a workspace out to a readable and executable text
file in one of the APL overlay character encodings. There are also
utilities to list which variables are used (as globals or as locals)
in each function. Today we could do it in Unicode. Humans (well, APL
programmers anyway :-) ) can read such files, and the base interpreter
can use one to recreate the workspace from scratch. Certainly there
was never any confusion between the user's workspace and the
interpreter itself, whereas most of Smalltalk is written in Smalltalk,
with no distinction between system classes and user classes.

Anyway, the Journal has nothing to do with the structure of Etoys.

> and Holger's explanation of why it's
> "non-free" reinforced that.  Of course I have no idea how it's
> actually implemented inside.

Why is that "of course"? That information was published in 1981 in the
original Smalltalk books. It was implemented in somewhat the same way
as a Forth system or any other bootstrapped interpreter, with a set of
machine-language primitives sufficient to allow all of the rest to be
written in the language.

> (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.)

That's how you read Forth source, too, with 'words' and 'see'. This is
trivial to do in Smalltalk. Open a code viewer from any object halo,
and have at it. Open the Supplies toolkbox from the top toolbar, and
examine any of the object types you find. You can find a tree of the
low-level classes in the original Smalltalk books.

> 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.  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. Then there's a separate Compiler that turns
> Squeak/Smalltalk source code into bytecode objects that the
> interpreter can run?

Presumably we have to get those translators and compilers into Debian
also. Has any of this been done?

> 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.  Avoid http://wiki.squeak.org/squeak/1053 until
> somebody rewrites it in English.

It is incomplete, but I didn't find anything obscure there other than
the names of Smalltalk object classes. Of course, I have read the
original Smalltalk books and have other experience that you don't. I
think that the problem is that so much of the Smalltalk system is
written in Smalltalk, so you can't make real sense of the
implementation docs until you have a basic idea of Smalltalk
programming.

But what is the problem with this?

"If one wanted to build a Smalltalk image starting from only the
system sources, one could do so by creating an empty dictionary
object, compiling all the classes into it (this would require a
pre-existing compiler), and then initializing all the class
dictionaries and the global variables above. Most class variable
dictionaries get properly initialized by an 'initialize' method, and
most of the globals have a method somewhere for creating and
initializing them as well. To find these methods, inspect Smalltalk
itself, select the global in question, and then invoke the
'references' command from the variable list menu."

All the rest is "mere corroborative detail, designed to give an air of
verisimilitude to an otherwise bald and unconvincing narrative."

> The rest of the internals doc is
> sketchy copies of emails, with newer headings that say things like
> "The last system where this worked is 2.7 (January 2000)".
>
> I haven't yet found similar documentation for eToys, which is
> apparently something "built on" squeak rather than "built in"?

Yes, it's all just object definitions.

> 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.
>
> Anyway, it looks like there's lots of stuff hiding under the covers in
> Squeak and eToys, but it's so undocumented that only a zealot would
> ever figure out where or how to start.

No rwarring here, John. Don't even hint at it.

"The Squeak team never builds a system in this manner because we find
it easier to work with a running system all the time. For the very
rare cases in which this is not possible (changing the formats in the
ObjectMemory, for instance), we use a special tool called the
SystemTracer. The SystemTracer builds an image from scratch, but
working from an existing system, not from the source code files."

You might not understand these reasons, but you do not have the right
to declare that they don't exist.

> Perhaps the team should
> someday spend a month or two on documentation -- after all, it's an
> education project, and if nobody can even find your source code, how
> are they going to read it and educate themselves?

This has long been the intention. Alan Kay asked me to assist in it
last year, but I have felt that there were more pressing matters. You
could be a great asset to the documentation process, as a technically
sophisticated would-be user who can tell us exactly what we have
failed to explain so far. I can't stop what I am doing to gather
information and questions, and write these documents myself, but I
would be happy to clarify the issues for anybody else willing to do
the grunt work but not willing to learn everything from scratch in
order to do it.

Anyway, John, why don't you start with the source for GNU Smalltalk,
gst, which is in Debian? See http://smalltalk.gnu.org/ for a
description.

"The Smalltalk for those who can type...GNU Smalltalk is a free
implementation of the Smalltalk-80 language."

Sources at http://smalltalk.gnu.org/download/cvs. Manual:
http://www.gnu.org/software/smalltalk/manual/

You could also Google  smalltalk tutorial  or  squeak tutorial  or
etoys tutorial. It would help us if you went through some of them, and
pointed out which answered any of your questions, and what specific
questions remained.

But start with the tutorials packaged with Etoys. You have apparently
done the Demon Dungeon exploration to learn the handles. Have you
completed the Etoys Challenge game, where you snap programming tiles
together and modify values? Have you tried the Make a Project project?
Have you opened the Supplies box from the top toolbar and examined the
objects there using the Viewer?

> Or some zealot
> could do the supposedly trivial implementation exercise of making
> source code go into separate files, and being able to actually compile
> source from files into binaries in files, rather than compiling only
> from running images to running images.

Not totally trivial, but no harder than it was in APL. You can create
an object for it, with methods to traverse the object definition tree
and write out source code where it is available to a linear file or to
a hyperlinked set of pages, in the manner of Doxygen or PyDoc, or to
UML. I would be quite pleased to have a ToyDoc or SqueakDoc available,
even though experienced users will probably always prefer the internal
tools.

Then the rest of the question is to find or create a set of C files
that would generate the objects and methods not defined in Squeak
itself and different from GNU Smalltalk, and assemble the results into
an executable image that could read all the Smalltalk source for a
particular image. Or a file that gst could run to create an Etoys
equivalent.

There are strong reasons why Smalltalk developers generally don't work
this way, but creating these facilities would be a boon to language
experimenters, in addition to getting Etoys into Debian Free.

> These improvements would make
> the freedom or lack thereof of Squeak/eToys more visible to ordinary
> programmers -- like me, or the Debian team.
>
>        John
> _______________________________________________
> Devel mailing list
> Devel at 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