etoys now available in Debian's non-free repository

Fri Jun 27 03:42:07 EDT 2008

On Fri, Jun 27, 2008 at 12:04 AM,  <david at lang.hm> wrote:
> On Thu, 26 Jun 2008, 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,
>
> so far so good
>
>>  and they don't care how we generate them
>
> I think you are wrong here

I don't think your opinion or mine count. Debian's counts. What did they say?

>> , or what mix of
>> languages we use, as long as there are Free/Open Source compilers and
>> any other needed apparatus for them.
>
> this part is again correct.
>
>> 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.
>
> if you send them C that's generated and call that your source, it's the same
> thing as writing your code in C and sending assembler as your 'source'
> (assuming there was a cpu independant assembler)

The analogy doesn't work. If I have C, I'll send the C. I have friends
who used to write APL and ship Ada as source, and their military
customers never complained. If the generated C is well-structured and
has the comments from the Smalltalk embedded, so that people can
understand it, what's the problem?

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

I personally don't mind which files are generated or how. If .source,
.changes, and VM source are sufficient, hooray. If we generate the
files some other way, hooray. I want to see readable, commented C and
Smalltalk, or some other such combination.

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