Very well, let's create some Etoys documents. On Wed, Jun 25, 2008 at 1:55 AM, John Gilmore <[EMAIL PROTECTED]> 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@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