etoys now available in Debian's non-free repository

[Edward Cherlin]

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.

I gather that all of this can be done by a fairly trivial Smalltalk
program. Would somebody write it and post it, and would somebody run
it and make the results available? Then if Albert agrees we've done
it, we can invite Debian to examine it, and get back to work.

On Thu, Jun 26, 2008 at 11:15 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
> At Thu, 26 Jun 2008 18:47:11 -0700,
> Edward Cherlin wrote:
>>
>> On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan <acahalan at gmail.com> wrote:
>> > I'm glad that Debian didn't break the rules for etoys.
>> > You're claiming to be open source, yet you've LOST the
>> > source code decades ago.
>>
>> This turns out not to be the case. All of the source code for the
>> parts of Etoys written in Squeak/Smalltalk is in the image.
>
>  ... is in .sources and .changes and the image holds the compiled
> results of them and each of these compiled results hold a file offset
> of the source chunk.
>
>> The .sources file and .changes file contain all of this code nicely
>> formatted.
>
>  Yes.
>
>> The core of Smalltalk, the part not written in Smalltalk,
>> is also available in both source and in binary parts of the usual
>> image. The usual tools for handling all of this are in
>> Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
>> Python, or what you like.
>
>  Oh, yes.  Speaking of which, Dan did a version in Java:
>
> http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/
>
>> Now, for the rest of you, let's see what we can produce, to make
>> Albert happy, but more importantly Debian. We have .sources and
>> .changes. Albert and Debian would like to see source for the VM, in
>> the manner of gst, and the binary core of Smalltalk that goes with it.
>> What can we show them, and what would it take to show them the rest?
>> "The Squeak system includes code for generating a new version of the
>> virtual machine (VM) on which it runs. It also includes a VM simulator
>> written in itself (Squeak). For this reason, it is easily ported."
>> What's missing? Is there anything in bytecode without Smalltalk
>> source? It doesn't seem so. The primitives like memory management and
>> BitBlockTransfer get translated to C and compiled along with the VM.
>> Is that right?
>
>  Yes.
>
>  A sidenote. The repository on squeakvm.org seems is a tree of .c and
> .h source files and you can compile it by gcc to produce the VM.
> However, many of these files are not the "sources" in a strict sense;
> These .c and .h files are target files from another phase.
>
>  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
> (only if) somebody claims that Squeak's way of doing is wrong, that
> person should also claim that Scheme48 should be taken out from
> Debian.
>
>> "Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
>> using the full range of Smalltalk semantics, including blocks."
>> http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work.
>> So apparently we can translate all of the Smalltalk tools for creating
>> code files and rebuilding an image to C source, and we can presumably
>> preserve the original comments from the Smalltalk.
>
>  I'm not sure what you mean by "code files" and "an image to C source".
>
>> Since the result was a complete Squeak
>> image with all Smalltalk source code, and C source where needed, is
>> anything else missing?
>
>  "No" would be the answer, If I understand your question.
>
>> "The interpreter is structured as a single
>> class that gets translated to C along with the ObjectMemory and BitBlt
>> classes." Is that it?
>
>  The modern version has basically different set of primitives in
> different files, but that is it.
>
>> Is there any reason not to simply check .changes into git?
>
>  The public version of (so to speak) .changes and .sources are
> already in the SVN on dev.laptop.org, and it is installed in
> /usr/share/etoys.
>
>>  Should we
>> have a way to split out changes to specific objects, and write a tool
>> to merge a sequence of such changes into a .changes file? Hm, it
>> appears that this is unnecessary with Monticello and squeakvm.org.
>
>  Before commiting it, we need to ask why splitting the file adds any
> value (when the editor can provide such views to the user).
>
>> As far as I am concerned, you should write any such tools in
>> Smalltalk/Squeak, and offer that source code to anybody who demands a
>> translation to another language. No, I'm wrong, not a problem. We can
>> translate it to C ourselves. There you go.
>
>  The Squeak-to-C translator is designed specifically to translate the
> subset of Smalltalk that can be mapped onto C.  IOW, you write C code
> in Smalltalk syntax, and debug it in Smalltalk.  For writing
> interesting tools, you would certainly like to use the full power of
> Smalltalk language but then it wouldn't be translatable to C.
>
>  If any such tool is written in Smalltalk, you would give the
> Smalltalk code to other people.  That is source.  Translated C program
> isn't source; it is a target object file that uses characters between
> 0x00-0x7f.
>
>> Or set up an instance of Monticello for Etoys versioning
>> and package management.
>
>  Not Monticello, but this was tried.  But the problem is that it just
> adds unnecessary complexity and gets in the way of *actual*
> development effort.
>
> -- 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