etoys now available in Debian's non-free repository

[Edward Cherlin]

On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan <acahalan at gmail.com> 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