[IAEP] etoys now available in Debian's non-free repository

[Edward Cherlin]

I am no slouch at understanding a bootstrap process, but it has taken
me a few days to find the information I'm trying to understand by
myself, given the refusal to even consider that someone might need
this information in order to answer Debian's concerns, and thus the
refusal to provide the pointers to it. So it is no surprise to me that
Debian still has those concerns. It is no good being right if you
can't explain or demonstrate _why_ you are right in terms that make
sense to someone else who is willing to understand, but doesn't know
how.

On Fri, Jun 27, 2008 at 11:17 AM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
> 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.

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.
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. This may be necessary in order to educate the Debian license
people. It might even be useful to somebody who wanted to base another
language on Smalltalk. Yes, they should probably modify the Smalltalk
interpreter in the image instead, and use Smalltalk to run, test, and
debug it, and export/translate/compile everything necessary once it's
all working. But it's their choice.

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

Right. So that means we have to educate them. Which means, just as in
Piaget's research, we have to educate ourselves first about how the
Debian people have constructed their understanding of the programming
process, and how we can assist them to construct an improved model.
Saying, "We're right! What's the matter with you people?" doesn't cut
it.

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.

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?

We had an issue like this in the IETF on multilingual URIs in
ASCII-encoded UTF-8. It was claimed that this would break everything,
so we showed how to translate between this form and normal UTF-8 in
two or three lines of Perl for each direction. The final question was
whether Japanese users would be able to type a mixed ASCII-Japanese
URL containing Katakana, Hiragana, and Kanji. So I didn't just say,
"Motiron dekiru naa! Nihonjin wa baka da to omou desyou ka nee?" I
gave it to them, keystroke by keystroke, with the keyboard layout and
IME switching and the conversions to Kana and Kanji. And then they
said, Oh, of course. Now I can see that there isn't a problem. OK, we
can make a standard for this.

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

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.

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.

Who here is with Debian? Whom do we have to convince?

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

Yes. Good. Show them.

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

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

So
* You open an object that lets you write code as text and run it.
* You define an object and its methods, giving the class(es) it
inherits from and the rest of the apparatus.
* 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.
* 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.
* Then you run some command that sends a message to the object
resulting in some visible effect.

Et voila! Nothing left to misunderstand.

>  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
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



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