Re: etoys implementation
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.) 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? 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. 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? 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. 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? 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. 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
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: 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
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.) Is it a different VM, or just a different distribution since it has a different binary blob? ___ 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
NoiseEHC wrote: 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.) Is it a different VM, or just a different distribution since it has a different binary blob? The Etoys image is different than the main Squeak image, which is mostly used by researchers and web developers.The main Squeak image is more focused on maintaining the Smalltalk libraries and IDE features while Etoys is more like a application. One drawback of the Smalltalk image is it's monolithic nature and while the separation of the main classes and Etoy classes can be done, it's a big job and can become a hassle when all kinds of different users have their own agenda and objectives. Therefor a plethora of images are available and are specialized for their use, much like different Linux distributions. Karl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
Thanks! Why do you refer it to as binary blob? That was the first word jumped into my mind. All I know is that it is not in CVS or GIT so nothing serious. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
On Wed, Jun 25, 2008 at 11:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: [John Gilmore wrote:] 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? Yes, Etoys is precisely a version of Squeak with more objects added in. Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) More objects written in Squeak. Whichever two images you would like to compare (why not write Squeak?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Explain to John and me how you get a command line in Etoys. No, I see it. It's the text input mode in a Scriptor. http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/englisch/sqk/sqk00046.htm tells you how to operate the controls to get to a scriptor and type in it to create a changes file. doFileout Smalltalk changes fileOut. self beep: 'croak' Actually, John, everything you need is in the Etoys Help tool--Script Tiles, Object Catalog, and Halo Handles (including the Viewer and Debugger)--and the Squeak tutorial http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/index.html 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? http://wiki.squeak.org/squeak/759 Smalltalk condenseSources extracts the currently valid definitions form both the sources file and the changes file and merges these into an new sources file SourcesV3.6 (you are asked to supply the name of the new sources file). All outdated definitions are dropped. We have a 14MBytes sources and 10 MBytes changes file. When these merge we have a 16 MBytes source file and a nearly empty changes file. We therefore conclude, that the 10 MBytes of the changes contained 2 MBytes new code and 8 MBytes development history. Can gst bring in a .sources file and a .changes file and create a working image? 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? Yeah, it's mostly Smalltalk source and objects created in Smalltalk. -- 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: etoys implementation
Am 25.06.2008 um 23:25 schrieb Edward Cherlin: On Wed, Jun 25, 2008 at 11:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: [John Gilmore wrote:] 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? Yes, Etoys is precisely a version of Squeak with more objects added in. Just out of curiosity: Exactly how is it different from vanilla squeak? (If there is such a thing at all.) More objects written in Squeak. Whichever two images you would like to compare (why not write Squeak?), launch two images and evaluate: Smalltalk condenseSources. or equivalent in them. Explain to John and me how you get a command line in Etoys. No, I see it. It's the text input mode in a Scriptor. http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/englisch/sqk/sqk00046.htm tells you how to operate the controls to get to a scriptor and type in it to create a changes file. doFileout Smalltalk changes fileOut. self beep: 'croak' Actually, John, everything you need is in the Etoys Help tool--Script Tiles, Object Catalog, and Halo Handles (including the Viewer and Debugger)--and the Squeak tutorial http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Tutorials/SqOnlineBook_(SOB)/index.html Actually, to get at the Smalltalk tools, use the view-source key. This is also mapped to Alt-, if you happen to not run on the XO, while ALt- Shift-W brings up the regular Squeak main menu. Under help-preferences you can disable the etoyFriendly setting, which then brings up the main menu on a background left-click. 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? Only they can answer that. It is all the sources, yes. http://wiki.squeak.org/squeak/759 Smalltalk condenseSources extracts the currently valid definitions form both the sources file and the changes file and merges these into an new sources file SourcesV3.6 (you are asked to supply the name of the new sources file). All outdated definitions are dropped. We have a 14MBytes sources and 10 MBytes changes file. When these merge we have a 16 MBytes source file and a nearly empty changes file. We therefore conclude, that the 10 MBytes of the changes contained 2 MBytes new code and 8 MBytes development history. We currently ship an 18 MB .sources and 600 K .changes file. So the condenseSources step isn't going to make much of a difference (we did it in April to produce EtoysV3.sources). Can gst bring in a .sources file and a .changes file and create a working image? Not currently. - Bert - 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? Yeah, it's mostly Smalltalk source and objects created in Smalltalk. -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: etoys implementation
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. - FChE ___ 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
