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

Fri Jun 27 22:35:41 EDT 2008

To: all the parties who are worrying about this ...

Given the history (not just PARC but going all the way back to the enormous differences of style and results from the ARPA community compared to the Bell Labs community), why is there any burden of proof here? 

For example, we published in 1983 a still readily available (including online) book (Smalltalk-80 and its implementation) about how Smalltalk is implemented and bootstrapped, and there is a readily available paper about the more recent Squeak version which was built on that. And there is ample information available at the Squeak site.

Folks who are "willing to understand" actually put some effort into it instead of jumping to conclusions based on internal logic and scant information rather than available external evidence. We have seen many claims about many things -- for example, where the "source code" might or might not be -- but scant evidence that any effort was made to find out. 

As I mentioned previously, this seems more like "stories than reality". And it seems like a culture clash, where one culture thinks it is somehow "standard", and other ways are not.

The use of an "image" goes back further than Unix and C text files (one of the earliest good versions of this was BBN Lisp, which became Interlisp, in the latter part of the 60s), so this is at least as standard as any other way to build things. At PARC, this idea went further, because Smalltalk served as the entire environment of the PARC computers, and there was no separate OS, file system, etc. If you think about it this way, then you can see that the Smalltalk image is simply the entire virtual environment for Smalltalk computing. So it is quite equivalent to the package of stuff in the Unix world that includes text files, OS, tools, etc.

The "sources" and "changes" files (the changes are the incremental history to the sources) don't have to be external to the image, but they have been made so since Smalltalk started to be implemented on computers that had fallen back to the bad old idea of operating systems and file systems. This is easy to find out about in a variety of ways.

But there is something further to ponder about this method from the 70s. And that is the idea that as scaling advances under Moore's Law, it will be less and less a good idea to rebuild from scratch (and more and more difficult). For example, the most comprehensive object oriented system on the planet is the Internet itself, with the hardware computers as the objects, and TCP/IP as the underlying messaging system. This was invented and built by the very same computer research community (ARPA/PARC) that invented and built Smalltalk, the personal computers, GUI and Ethernet, etc., at PARC. 

Part of the idea here was that computing is going to have to learn how to completely build and completely change all computer systems while they are running and without being able to take them down for maintenance. This was done successfully for the Internet and for Smalltalk. Another part of the idea is that if you have a really strong and better system, why not be able to use it to improve itself (why go back to decontextualized editors and simplistic systems builds, etc.)?

In any case, all of this has been well documented and available for decades. I, for one, am happy to answer any questions put to us about how our system works (why it bootstraps so well and completely), but I have no interest in spending any time defending against opinions that are not well informed.

Best wishes to all,

Alan

----- Original Message ----
From: Edward Cherlin <echerlin at gmail.com>
To: Yoshiki Ohshima <yoshiki at vpri.org>
Cc: its.an.education.project at tema.lo-res.org; devel at lists.laptop.org
Sent: Friday, June 27, 2008 6:44:26 PM
Subject: Re: [IAEP] etoys now available in Debian's non-free repository

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
_______________________________________________
Its.an.education.project mailing list
Its.an.education.project at lists.lo-res.org
http://lists.lo-res.org/mailman/listinfo/its.an.education.project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080627/bb537586/attachment.html>