etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

At Thu, 26 Jun 2008 18:47:11 -0700,
Edward Cherlin wrote:
> 
> 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.

  ... is in .sources and .changes and the image holds the compiled
results of them and each of these compiled results hold a file offset
of the source chunk.

> The .sources file and .changes file contain all of this code nicely
> formatted.

  Yes.

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

  Oh, yes.  Speaking of which, Dan did a version in Java:

http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/

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

  Yes.

  A sidenote. The repository on squeakvm.org seems is a tree of .c and
.h source files and you can compile it by gcc to produce the VM.
However, many of these files are not the "sources" in a strict sense;
These .c and .h files are target files from another phase.

  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
(only if) somebody claims that Squeak's way of doing is wrong, that
person should also claim that Scheme48 should be taken out from
Debian.

> "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.

  I'm not sure what you mean by "code files" and "an image to C source".

> Since the result was a complete Squeak
> image with all Smalltalk source code, and C source where needed, is
> anything else missing?

  "No" would be the answer, If I understand your question.

> "The interpreter is structured as a single
> class that gets translated to C along with the ObjectMemory and BitBlt
> classes." Is that it?

  The modern version has basically different set of primitives in
different files, but that is it.

> Is there any reason not to simply check .changes into git?

  The public version of (so to speak) .changes and .sources are
already in the SVN on dev.laptop.org, and it is installed in
/usr/share/etoys.

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

  Before commiting it, we need to ask why splitting the file adds any
value (when the editor can provide such views to the user).

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

  The Squeak-to-C translator is designed specifically to translate the
subset of Smalltalk that can be mapped onto C.  IOW, you write C code
in Smalltalk syntax, and debug it in Smalltalk.  For writing
interesting tools, you would certainly like to use the full power of
Smalltalk language but then it wouldn't be translatable to C.

  If any such tool is written in Smalltalk, you would give the
Smalltalk code to other people.  That is source.  Translated C program
isn't source; it is a target object file that uses characters between
0x00-0x7f.

> Or set up an instance of Monticello for Etoys versioning
> and package management.

  Not Monticello, but this was tried.  But the problem is that it just
adds unnecessary complexity and gets in the way of *actual*
development effort.

-- Yoshiki