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. The .sources file and .changes file contain all of this code nicely formatted. 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. The Smalltalk community is puzzled that anybody would prefer to work on Smalltalk in something other than Smalltalk. > Hacking up binary images is > shockingly horrible software non-engineering. It isn't hacking up, and it isn't a binary image. They mostly leave .sources alone, and write code in Smalltalk, which normally goes into the .changes file as structured text within a structured and documented programming object until a new release. The .changes file is recompiled whenever needed, such as when refactoring previously defined objects. > GNU Smalltalk is built in a relatively normal way. s/normal/conventional/ >OLPC could > ship that instead, assuming that Smalltalk is desirable. No point. Anybody who wants to can extract the source code from an Etoys image and create the objects you desire. That is the point. You, and apparently some of the Debian people, are complaining about two things, as far as I can tell. One is that the Etoys people haven't given you a directory tree of text files including appropriate makefiles that would recreate the entire Etoys image, bit-identical to what they ship. I'm happy to discuss that, since creating those files would apparently let Etoys go into the Free repository. The other complaint is that all of the tools for working on Smalltalk source are written in Smalltalk, except for the bits to be compiled in C. I don't get it. All of your C tools are in C. A .tgz of a directory tree of files is a binary object just as much as an Etoys image is, neither more nor less. If your tree includes the sources for some app, plus emacs and gcc and the necessary libraries (source or binary), the .tgz is still a binary object with all of your tools in it. In the extreme case we have a complete Gentoo distribution, and we compile _everything_ from source, including another instance of gcc. I can examine the sources elsewhere, but I have to trust the compiler to some extent, and a lot of other code that I haven't examined. Most of it has been examined by somebody, but there are arcane parts of X, for example, where I don't know that you or even Jim Gettys could give me the name of anybody who still understands it. In any case, this has no practical significance. If _you_ want to write tools external to Etoys and Smalltalk that replicate functions in Smalltalk, knock yourself out. But does Debian want them? I don't see any reason to. But it doesn't matter what I think. What does Debian think? 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? "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. Would that make Albert happy? What about Debian? Albert, would you take a look at http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html? It explains the bootstrapping process from Apple Smalltalk to Squeak, including writing tools in Smalltalk to generate compilable C code from a Smalltalk interpreter written in Smalltalk, and writing a small C program to interface to the OS. Since the result was a complete Squeak image with all Smalltalk source code, and C source where needed, is anything else missing? "The interpreter is structured as a single class that gets translated to C along with the ObjectMemory and BitBlt classes." Is that it? 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? Is there any reason not to simply check .changes into git? 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. Hey, Albert, check _this_ out. http://www.wiresong.ca/Monticello/UserManual/ Well, we'll see if anybody still has issues. 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. I'm hoping that the answers to all of these questions will allow us to go back to Debian and say, Sorry for the misunderstanding, here is everything you asked for (Smalltalk/Squeak source code files, reasonably commented C source for VM and toolset). And to put into our git whatever people want in git, without making pointless busywork for the Etoyers. Or set up an instance of Monticello for Etoys versioning and package management. Win-win-win. -- 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