etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  Hi, Edward,

  Thank you (again) for thinking about these things!

  Well, now I see a reply from Alan.  I'll try to concentrate on the
pure technical part.

> >> I think that the result of all this is that we can produce all of the
> >> C (or some other language, maybe CLOS) and Smalltalk source files that
> >> Debian wants (even if we think of the C as compiler output, we don't
> >> have to bother them with that interpretation.) One of the compilers
> >> translates a subset of Smalltalk to C, but I gather that other
> >> compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
> >> their chosen target language.
> 
> Now I see that this is unnecessary. We have the directly executable
> Smalltalk source for the VM, including memory management and graphics
> primitives written in Smalltalk. It is already in the .sources
> files.

  A little correction is that the source for the VM is in a separated
package called VMMaker; the etoys image currently doesn't contain it.

> We can therefore provide all of the source code for Etoys in a
> conventional file system in the way that users of compiled languages
> expect.

  There still seems some misunderstanding, but I can't tell how.
The word "therefore" cannot connect the previous sentense with the one
that follows here.  .sources (and .changes) contains the all behaviors
of objects. and it is in text.

> I find it useful to meet people half way in such a situation. Well, we
> don't have to have our code in a conventional file system, but here is
> how you can fairly trivially create such a file system and rebuild an
> image, even though we never do this in practice. Well, almost never.
> Aha! You can do it that way, somebody might need to do it that way,
> that's what I'm looking for in the first place. So give. Don't tell me
> I don't need to know.

  Hmm.  I'm not sure what you mean by rebuilding an image.  If you
mean to do it from the situation there is no .image it would be very
hard.  For example, the "nil" object (the sole instance of its class
named UndefinedObject) sits at the beginning of the image file.  You
cannot create the memory words that represents the instance in
meaningful manner from text (in the current Squeak way of doing).

  You can have a big C file that looks like:

-----
  unsigned char image[] = {0x12, 0x34, <goes to 1 million entries or so>};

int
main()
{
   FILE *image = fopen("etoys.image", "w");
   fwrite(image, sizeof(image), 1, image);
   fclose(image);
}
-----

And this .c file is all text.  This could satisfy Debian people, if
they accept some other languages that are bootstrapped.

> I want to _see_ that fairly trivial script. I want Debian to see it
> and to be able to run it and examine its output. Once they understand
> how one can generate "source code" in the traditional form whenever
> desired from the real source, and where that real source lives, they
> may be able to believe in using the code in the image and not
> bothering with generating a conventional representation. They seem to
> want proof that we can do something unnecessary but comforting. Well,
> it shouldn't be any real effort, so why not give them that
> demonstration?

  The misunderstanding may lie around what kind of translated C can be
compiled and executed.  We can have a smaller image that is 1MB or so
(can be even smaller but I don't a real point to go for extreme) and
file in everything else to build the etoys.image.  But I cannot see
anywhere that transated code plays any role in the picture.

> Somebody, somewhere, gave Debian the impression that .sources and
> .changes do not contain the code for everything. I don't know how this
> happened. You are almost correct that we don't need to show them the
> translated stuff. But given the damage that has been done, we now have
> to show them the entire process from full Smalltalk source to
> generated code to new image, and the generated C is part of that
> process, even if not source.

  They contain all code (plus some history even).  They don't contain
the instanciated objects.  They can contain texutal expressions that
creates objects, but the textual expressions have to be compiled by
the Compiler object that needs to exist.

> So let's just show them where all the code is and how to get at it in
> a way that they already understand, so that they can begin to
> understand why they don't need to do it that way.

  I should know who are they.
> 
> Who here is with Debian? Whom do we have to convince?

  I dug up an email archive of squeak-dev
a few month back and find a name ("Thomas Viehmann").

> > David:
> > ----
> > breaking out the .source and .changes files that have been referred to in
> > this thread and having the build process create the resulting blob that
> > you use would probably be acceptable (and far more useful as people can
> > then send out patches to those files)
> > ----
> >
> >  We are already sending out textual files called "changesets" to
> > people.  That is the way we work.
> 
> That does not answer the question asked.

  I still don't understand the question, then.

> > Jonas:
> > ----
> > If I understand correctly, the Squeak community accepts patches
> > generated from their binary images.
> >
> > So the real question is, if images built from C sources can generate
> > patches acceptable by the Squeak community.
> > ----
> >
> > "Generate" is a wrong word!  We write code textually in a text editor
> > (happens to be written in Smalltalk) and save it.  Of course the
> > patches ("changesets") are valid, we accept them.  We won't notice if
> > the changesets are written in Squeak, a image running on different VM,
> > Emacs or vi.  It is just text.  The only difference is that the effect
> > of "accepting" (saving) takes effects right away, as it is running in
> > the same session.  Just as same as writing Emacs Lisp in Emacs.
> > (Think writing lisp-mode.el in Emacs.)
> 
> I think that some people need to see a trivial example worked out step
> by step. Otherwise they think they are arguing about something that
> isn't even there.

http://wiki.laptop.org/go/Smalltalk_Development_on_XO has been around
and I mentioned it a couple of times.  It does explain how to do it.

> So
> * You open an object that lets you write code as text and run it.

  What do you mean by "open an object"?  You are thinking about Etoys
objects?  The Smalltalk part of code are often written when there is
no instance of the class you are working on.  It can be purely textual.

> * You define an object and its methods, giving the class(es) it
> inherits from and the rest of the apparatus.

  Or, you define a class and its methods.  Along the line, you may
  create an instance of the class.

> * Smalltalk stores this object as an object (duh).
> * You test your definition.
> * There is a way to write the code to an external file, creating a
> trivial changeset. You do this and quit.

http://wiki.laptop.org/go/Smalltalk_Development_on_XO  

> * You show Debian or whomever the file.
> * You open the standard image, which does not contain your new object
> and methods.
> * Then you show Debian the command that reads the file in and
> processes it to create the object and methods.

  Drag the .cs or .st file onto the running Squeak session, or specify
it from command line.  (read /usr/bin/etoys).

> * Then you run some command that sends a message to the object
> resulting in some visible effect.

  It can be in the change set.

> Et voila! Nothing left to misunderstand.

  Hopefully.

-- Yoshiki