Hi,
first of all let me express that Squeak is very cool (there is no other term) and that the work done so far deserves full respect, if I may say so.
Anyway, I've been following this mailing list for quite a while now and inspired by reading 'The Cathedral and the Bazaar' by Eric S. Raymond (http://earthspace.net/~esr/writings/cathedral-bazaar/cathedral-bazaar.html) and Netscape's 'open-source culture' efforts regarding the Communicator Source Code Release (http://www.mozilla.org) I get the impression that
S Q U E A K N E E D S C O O R D I N A T I O N !
Why? Ok, Squeak is free and everyone is invited to use Squeak for things he wants to do with Squeak. But if someone wants to use Squeak as a base for his own experiments or development he needs a reliable core system to be ensured of using a high quality starting point. For example, if I'm tired of using tools like yacc for writing a programming language parser and I want to use a Smalltalk environment invoking T-Gen as a parser generator. Since someone asked twice if T-Gen has been ported to Squeak this is a reasonable szenario. Correct me if I'm wrong but noone has answered the question yet if T-Gen is ported to Squeak and noone knows if someone is porting this piece of software to Squeak at the moment. Perhaps three or four are doing this port in parallel right now; and of course that would not be what we desire. At least I don't know if this is the case. This is dissapointing since Squeak and T-Gen are great pieces of software and they both would benefit from each other. Sadly enough T-Gen is just one example. Summarizing from my mind I give a not necessarly complete list of current Squeak projects:
o Core Class Library o Native Widgets o Self Booting Squeak o Double clickable Squeak o Applications (Draw80, T-Gen, Siren, ...) o Virtual Machine Hacking o Platform Porting o Documentation
Having so many different branches of development (which I will focus later) it is clear that there is at least some need for coordination. Given so many excellent and experienced developers (for example, how many people in the world are able to implement a Windoze Look and Feel in Smalltalk?) which are involved in the Squeak project the non-coordination is very annoying.
But where coordination could take place? Who could coordinate? Sorry guys, but sometimes I read the term 'Squeak central'. If 'Squeak central' exists it is responsible for development coordination, isn't it. I fully agree that coordination is rather a time consuming task which is not done in spare time. Assuming that I demand for volunteers who think they have time, experience, knowledge and Squeak insights for doing this. I regret that I can't fullfill any of the above mentioned request. But let me expand this demand to my squeaking wish list:
1. First of all I want a maintained Web Site (http://www.squeak.org) which contains up to date information and links for downloading latest versions for each platform and description of current projects.
2. Downloads should be distinguished between distributions with and without source code. So the most frequent download without source code should contain one virtual machine (JIT), one virtual image, one sources file, one changes file. This is nothing new you say. Right, but in addition the download should also consist of a directory containing applications (you can also use the term parcels for that) which are file-in's for extending the base virtual image for specific needs. Having said that, I demand a virtual image that only contains the core Squeak class library. Every user is able to create an image for his own purpose. For example, I think Morphic is cool but it is very slow. I get used to the MVC paradigm and I want to stick with that. That means I have to delete the Morphic framework each time I download a new image. Why not creating an morphic application which a Squeak user can easily integrate into his image? I don't give you the huge list of further applications that could be loaded into a Squeak virtual image; you know them, don't you?
3. Repeating myself: the virtual image should contain only a core class library which serves as a base for loadable applications.
4. Although I get the impression that native widgets don't have high development priority I think it is annoying that we don't have them looking at so many differents interface components of contemporary operating systems.
5. Having native widgets we don't need a self booting Squeak, do we?
6. Porting the most important applications of freely available Smalltalk code to Squeak.
7. Platform Porting and Virtual machine hacking should be independently done by experts having the Windoze branch and the Unix branch. Other operating systems should be supported as well after new releases for the main operating systems evolve.
8. Documentation for Virtual Machine Hacking can only be done by those who are writing the virtual machine, of course. From my point of view, it is ok, if the core class library is documented as comments in the source code. Tutorials with examples should be loadable as applications.
I'm sorry, if I misunderstood the concepts and ideas behind Squeak.
Thanks for reading and for your comments.
Have fun,
Joerg
Joerg Brunsmann wrote:
[...]
S Q U E A K N E E D S C O O R D I N A T I O N !But if someone wants to use Squeak as a base for his own experiments or development he needs a reliable core system to be ensured of using a high quality starting point.
Yes.
For example, if I'm tired of using tools like yacc for writing a programming language parser and I want to use a Smalltalk environment invoking T-Gen as a parser generator. Since someone asked twice if T-Gen has been ported to Squeak this is a reasonable szenario. Correct me if I'm wrong but noone has answered the question yet if T-Gen is ported to Squeak and noone knows if someone is porting this piece of software to Squeak at the moment. Perhaps three or four are doing this port in parallel right now; and of course that would not be what we desire. At least I don't know if this is the case. This is dissapointing since Squeak and T-Gen are great pieces of software and they both would benefit from each other. Sadly enough T-Gen is just one example.
I, for one, asked this question on the 28 august 97. Stephen Travis Pope replied. We had begun the port but was distracted. Erik Gjovi asked again in 28 feb 98 (6 months later). Lately, I used Dolphin Smalltalk to experiment with T-Gen. I'm not satisfied with Dolphin, I would prefer to use Squeak but T-gen is missing. I tried to begin the port of T-gen to Squeak. First we need Exceptions. Exceptions should be in the core class library of Squeak. I don't feel I have enough experience to port T-gen to Squeak, so I stopped. To do this kind of port, we need somebody who designed T-gen in the first place.
[...]
Right, but in addition the download should also consist of a directory containing applications (you can also use the term parcels for that) which are file-in's for extending the base virtual image for specific needs. Having said that, I demand a virtual image that only contains the core Squeak class library. Every user is able to create an image for his own purpose. For example, [...] Morphic is cool but it is very slow.
[...]
Why not creating an morphic application which a Squeak user can easily integrate into his image? I don't give you the huge list of further applications that could be loaded into a Squeak virtual image; you know them, don't you?
- Repeating myself: the virtual image should contain only a core
class library which serves as a base for loadable applications.
This should be the way. It should facilitate downloads. Maybe the documentation would be improved too. I prefer to add packages (or parcels) then to delete.
[...]
At 9:11 AM -0500 3/23/98, TANGUAY, LUC wrote:
[snip]
I, for one, asked this question on the 28 august 97. Stephen Travis Pope replied. We had begun the port but was distracted. Erik Gjovi asked again in 28 feb 98 (6 months later). Lately, I used Dolphin Smalltalk to experiment with T-Gen. I'm not satisfied with Dolphin, I would prefer to use Squeak but T-gen is missing. I tried to begin the port of T-gen to Squeak. First we need Exceptions. Exceptions should be in the core class library of Squeak. I don't feel I have enough experience to port T-gen to Squeak, so I stopped. To do this kind of port, we need somebody who designed T-gen in the first place.
[snip]
I started working on this, but had to put it aside for awhile. My hang up were some VM crashes with recursion (I suspect this was due to deeply recusive blocks). If there are people interested in a coordinated effort, please drop me a note via PRIVATE email.
As for exceptions, a lot depends on what you want. For porting, one needs an exception system which emulates that of the thing which you port (how's *that* for a stilted sentence!). David Farber posted to the list what appears (so far in my experience) a solid port of (to quote his message):
Bob Hinkle and Ralph Johnson's exception mechanism for V286. one of the big points of this setup is that it is supposed to mimic the ParcPlace (and even Tek) exceptions.
(For the record, Dave, this is *very* useful! Thanks.)
An aside: things do work there way into the "core distribution"--the Pluggable Web Server is a good example.
Code first, coordinate later ;) Right now that's not a bad principle.
Cheers, Bijan.
squeak-dev@lists.squeakfoundation.org
-
Bijan Parsia -
Joerg Brunsmann -
TANGUAY, LUC