etoys now available in Debian's non-free repository

[david at lang.hm]

On Fri, 27 Jun 2008, Edward Cherlin wrote:

> Subject: Re: etoys now available in Debian's non-free repository
> 
> 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?

I don't think ayone has asked them this exact question.

>>> , 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?

remember that there are several reasons for the source requirement

1. so that people can check that there isn't bad stuff in the code

2. so that people can change the code

3. so that people can contribute changes to others

4. so that people can learn how the code works

checking for bad stuff could be done on generated C code. changing the 
code can be done with generated C code.

but the resulting C code is worhless for people contributing changes if 
the people they are trying to contribute the changes to are working in 
smalltalk.

learning how the code works _could_ be done on generated C code (although 
not well). my Dad tought himself C by taking the K&R book, typing in the 
examples and examining the resulting binaries, but he came from a 
mainframe systems background. most people won't go to that extreme.

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

remember that te GPL talks about the 'preferred form for modification'. 
generated files are definantly not that form.

in this case the dispute is that the squeek/etoys people are arguing that 
there 'preferred form' is the monolithic blob/bundle and others are 
objecting to that and asking for it to be broken down a bit so that the 
various pieces can be dealt with seperatly

the fact that etoys is diverging from the upstream squeek/smalltak is an 
example (in many people's opinion) of the problem cause by everything 
being dealt with as a monolithic chunk.

a similar situation would be if someone were to write a python program 
that edited the python source, but bundled the editor, the program, and 
the python interpreter into one binary. then when you ask for the source 
they offered to give you the C code that the python translates to.

if this were to happen people would rightly demand that this blob be 
seperated into the python interpreter, the editing tools, and the programs 
being worked on, and not accept the C code as being the source.

it sounds to me as if that is the same request being made of the etoys 
people (and if it's not it should be). it doesn't mater what language the 
individual pieces are in (for the python analogy above, the editor could 
be a C-based thing that gets loaded into the python interpreter as a 
module), what matters is sperating the various pieces cleanly into their 
various pieces (the readable, commented code you refer to above)

David Lang

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