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