etoys now available in Debian's non-free repository

Yoshiki Ohshima yoshiki at vpri.org
Fri Jun 27 14:17:53 EDT 2008


At Thu, 26 Jun 2008 23:43:45 -0700,
Edward Cherlin wrote:
> 
> 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. As I understand it, Debian wants to see
> a commented set of semi-human-readable code in ASCII files (although
> we can discuss using Unicode source) together with various multimedia
> files in known open formats, from all of which an Etoys image can be
> constructed, and they don't care how we generate them, or what mix of
> languages we use, as long as there are Free/Open Source compilers and
> any other needed apparatus for them.

  As Alan precisely put it ("we are dealing with stories, not
reality."), this seems to be a backward way to work on this problem.
When (if) Debian guys asked something based on wrong understanding,
what we should do is not to cater the wrong story, but have them have
real understanding.

  The reality is that the all description of classes and methods are
already accessible (even in text files like .sources and .changes) and
anyone can see all the code, and modify in the way the core developers
do.  That is the equal basis we provide to the world.  Giving the
translated stuff, except the C code for the virtual machine that is
needed for bootstraping purpose, is wrong.

  David, Antoine, and Jonas, thank you for the comments.  But let us
not take this way anyway.

  (Still I see some comments that says "the source code is in the
image" but it is absolutely false.  In the image, the compiled result
of source is stored, and the texual code is always kept outside of the
image.)

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.

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

  The image contains pre-made objects starting from nil, true, false,
etc., to the Compiler and beyond.  It also contains pre-loaded artwork
and user contents.  But all of them can be modified, and accessed
fully.

-- Yoshiki



More information about the Devel mailing list