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 <[EMAIL PROTECTED]> 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@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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel