Hi -
I just spent some in 3.10 and while I felt that there wasn't much that personally excited me about it, there were still plenty of fixes that were interesting enough for me so that I'll have to spend significant time to integrate them into Croquet. And if you look at what has recently gone into Croquet [1] I'm pretty sure you'll find the same the other way around (for example the font caching fixes come directly from Croquet). After looking over 3.10 it again occurred to me how splintered the larger Squeak community is when it comes to some of the core parts of its software.
I think that at some point we'll have to admit that using individual images is a reality that we simply need to accept and deal with it accordingly. And one of the key parts is to understand how to share code across these different images.
The trouble with code sharing is that the most important packages are still completely bound to particular images. There is no "Collection" package that I can load in from 3.4 through 3.10 and expect it to work. There is no common "Numbers", no "Streams", no "Files", Sockets, Sound, Exceptions, anything package. While there are plenty of application-level packages that support a range of images, there is almost nothing at the core of Squeak that can be used across different images.
And I'm curious if there is interest in changing this. At least on the level where it's fairly non-controversial (e.g., I wouldn't be planning on starting with metclasses, m17n, or compiler) it could be a pretty interesting for various projects to be able to have a common code base, with decent tests to ensure it runs on all the the supported image versions etc. So that, for example, if there is an improvement to Dictionary you can benefit from it implicitly regardless of whether you are using a particular image or not.
In short, what I'm looking for is something like a set of "standard packages" which are supported beyond the particular image they apply to. In thinking about this, two questions came to my mind:
1. Is this technically feasible? I'm not certain about this given how tightly various of the core packages depend on the particular idiosyncrasies of particular images. But it'd be interesting to find out whether (for example) we could make up a "standard Number package" that can easily be installed and supported in various versions.
2. Perhaps more importantly, is there any interest in doing something like this? Since it would most certainly require serious work it could only be done if other people feel the same like I do and are willing to put in some time and effort. If people are happy with where they are today (which is quite possible) then this is a no-win situation.
*If* something like this works, it may be one step out of the image lock-in that we currently endure. It could also help focusing various (currently completely disjoint) parts of the community on help improving a shared base.
Comments welcome.
Cheers, - Andreas
[1] https://lists.duke.edu/sympa/arc/croquet-dev/2007-05/msg00035.html
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images. A "core" team could be responsible for this. Perhaps it consists of the improved Squeak classes from the ST-80 image. Or fundamental classes, like the ones you listed, that most everyone agrees should be included. The fundamental classes wouldn't be packages, they'd just be the basic building block for other packages to be added.
For some reason, I thought there was a team like this. Isn't there?
Wouldn't it be technically feasible, no matter how hard it is? The question is what amount of work is acceptable for the community to pursue.
brad
Brad Fuller wrote:
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images.
This is basically what we have today and it doesn't work. There is too much power concentrated in the hands of whoever "owns" that image; it *will* get abused for personal / project interests. Secondly, because it's an image it needs to take a stand on a variety of issues that people can reasonably disagree about. For example, whether m17n support should be part of that image. Or whether traits should be. Or whether a new compiler should be. And lastly, when the disagreement about any of these aspects arises, the only thing that anyone can do is to fork. Which gets us precisely where we are today: to the point where it's effectively impossible to collaborate on the parts that you agree on but stay separate on those parts that you disagree.
An image simply cannot address these issues because I'm not proposing (and not inclined to) collaborate on an actual artifact. I'm proposing to collaborate on a set of libraries that are of common interest.
Cheers, - Andreas
On Sun July 22 2007 9:54 pm, Andreas Raab wrote:
Brad Fuller wrote:
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images.
This is basically what we have today and it doesn't work. There is too much power concentrated in the hands of whoever "owns" that image; it *will* get abused for personal / project interests.
Perhaps, but I don't see it. If it's a group of individuals that are charged with core requirements, why would they abuse it? I don't see that sort of animosity here. Maybe there is and I don't see it.
Secondly, because it's an image it needs to take a stand on a variety of issues that people can reasonably disagree about. For example, whether m17n support should be part of that image. Or whether traits should be. Or whether a new compiler should be.
Yes, I agree that it would be difficult to determine. That's why I suggested to get back to the basic ST-80 features (but with the bug fixes (etc) that Squeak today encompasses.) I know the problem are the edges, though.
And lastly, when the disagreement about any of these aspects arises, the only thing that anyone can do is to fork.
That doesn't have to be. There could be some clear rules that we follow of what to do in those cases. It could be as simple as not including the portion that people are disagreeing to. Or there could be a process where it's brought before more people to help decide. There are a lot of possibilities.
Which gets us precisely where we are today: to the point where it's effectively impossible to collaborate on the parts that you agree on but stay separate on those parts that you disagree.
To me, it sounds more of a social issue and not a technical one (not that there are not technical hurdles.)
An image simply cannot address these issues because I'm not proposing (and not inclined to) collaborate on an actual artifact. I'm proposing to collaborate on a set of libraries that are of common interest.
Cheers,
- Andreas
On 7/22/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Yes, I agree that it would be difficult to determine. That's why I suggested to get back to the basic ST-80 features (but with the bug fixes (etc) that Squeak today encompasses.)
But an image - any image - necessarily goes beyond "basic ST-80 features". An image tends to include a UI, but should this be MVC, Morphic, or Tweak? With what fonts? With what icons, color themes, etc? An image tends to include dev tools, but should these be based on Browser or OmniBrowser? An image has a metaclass hierarchy, but based around Behavior or Trait?
The set of necessary things for an image does include some contentious areas. However, I think Andreas is right that there are some areas that are (I believe) much less contentious, like the Collection and Number hierarchies, as well as (mostly) Stream, Exception, Socket, etc. These aren't enough by themselves to make a full image, so we'll never agree on a "base image" to build everything else from. But it does seem reasonable (both socially and technically) to jointly manage improvements to these standard packages, across the many forks and versions of Squeak. I'd certainly love to see this happen.
Avi
Me too. Having good libraries that we can share would be really nice.
Stef
Yes, I agree that it would be difficult to determine. That's why I suggested to get back to the basic ST-80 features (but with the bug fixes (etc) that Squeak today encompasses.)
But an image - any image - necessarily goes beyond "basic ST-80 features". An image tends to include a UI, but should this be MVC, Morphic, or Tweak? With what fonts? With what icons, color themes, etc? An image tends to include dev tools, but should these be based on Browser or OmniBrowser? An image has a metaclass hierarchy, but based around Behavior or Trait?
The set of necessary things for an image does include some contentious areas. However, I think Andreas is right that there are some areas that are (I believe) much less contentious, like the Collection and Number hierarchies, as well as (mostly) Stream, Exception, Socket, etc. These aren't enough by themselves to make a full image, so we'll never agree on a "base image" to build everything else from. But it does seem reasonable (both socially and technically) to jointly manage improvements to these standard packages, across the many forks and versions of Squeak. I'd certainly love to see this happen.
Avi
On 7/23/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Perhaps, but I don't see it. If it's a group of individuals that are charged with core requirements, why would they abuse it? I don't see that sort of animosity here. Maybe there is and I don't see it.
"Animosity" is the wrong word. There is diagreement. People can disagree without being disagreeable. In fact, any two people will disagree about *something*. If two people agree on everything than one of them is unnecessary.
And lastly, when the disagreement about any of these aspects arises, the only thing that anyone can do is to fork.
That doesn't have to be. There could be some clear rules that we follow of what to do in those cases. It could be as simple as not including the portion that people are disagreeing to. Or there could be a process where it's brought before more people to help decide. There are a lot of possibilities.
If you say that you only include the portion that people agree to, then you let the most conservative people hold up progress. Sometimes you just have to be change and make some people unhappy.
A good example is traits. The 3.9 team put traits in the image. Lots of people didn't like it. I'm not sure I do. However, there is no question that the only way to see whether traits is good is to use it, and nobody wants to build a library on traits unless it is standard. Now that it is in the image, people are starting to use it. It will probably take another year or two before we can see for sure whether traits is worth the trouble.
There isn't any way to compromise with something like traits. It is too core. it is easier to compromise with peripheral parts of the system. That is why it is good to reduce the size of the system and reduce the opportunity for conflict. But you can't eliminate all possibility of conflict. Adding features to the language, which is what traits does, will alwas be contentious. You either do it or don't do it. Saying "it is a package that you can load if you want" is a death warrent for language features.
-Ralph Johnson
Andreas Raab andreas.raab@gmx.de writes:
Brad Fuller wrote:
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images.
This is basically what we have today and it doesn't work. There is too much power concentrated in the hands of whoever "owns" that image; it *will* get abused for personal / project interests.
Yes, but we do have a messy political process for keeping anything really perverse from happening. That process can even be changed, and surely your recommendations for such changes would have a whole lot of weight.
Within the existing political process, the thing to do pronto is to get someone on the Squeak Foundation Board, if you do not already have someone sufficiently sympathetic. Additionally, it never hurts to keep an eye on the current release manager and communicate your concerns to them, e.g. on which bug fixes to prioritize.
Aside from that, it has been a long stated goal of many volunteers to separate Squeak into packages, and part of the reason is so that we can have a non-controversial core and a non-controversial set of optional but standard packages. A lot has happened as part of the 3.10 release, as Ralph described. Thus, the interest is certainly here, if the technical details work out.
On the technical side, sharing packages would mean Croquet has to play nice as an extension to a standard core and standard set of packages. Small deltas from the standard component swould be fine, but big ones will be a headache. It looks like a tough engineering call on your part. Is the work of making Croquet sit on top of standard Squeak, low enough that there is a net payoff from automatically inheriting fixes to the standard image?
Lex
Lex Spoon wrote:
Yes, but we do have a messy political process for keeping anything really perverse from happening. That process can even be changed, and surely your recommendations for such changes would have a whole lot of weight.
I'm not interested in changing the way squeak.org operates; I'm only interested in collaborating on particular packages (if there is mutual interest).
On the technical side, sharing packages would mean Croquet has to play nice as an extension to a standard core and standard set of packages. Small deltas from the standard component swould be fine, but big ones will be a headache. It looks like a tough engineering call on your part. Is the work of making Croquet sit on top of standard Squeak, low enough that there is a net payoff from automatically inheriting fixes to the standard image?
You are completely misinterpreting my intent. I am not planning to put Croquet "on top of standard Squeak" (what exactly does that mean anyway?) I have been looking for packages for which collaboration is feasible, useful, and of mutual benefit.
Cheers, - Andreas
On 7/22/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images. A "core" team could be responsible for this. Perhaps it consists of the improved Squeak classes from the ST-80 image. Or fundamental classes, like the ones you listed, that most everyone agrees should be included. The fundamental classes wouldn't be packages, they'd just be the basic building block for other packages to be added.
For some reason, I thought there was a team like this. Isn't there?
There is a team responsible for making the next release of the Squeak image. I am the leader of the 3.10 release, Edgar J. De Cleene manages the build process and so does most of the work, and lots of people fix bugs and submit changes for Edgar to process.
Our main goal has been to take things OUT of the image. The 3.9 group also took a lot of things out of the image. But the image is still far from "core". For example, it still has eToys, even though eToys is big and most people don't use it. That is because my rule was "remove anything that we can load back in" and we haven't been able to get eToys loaded back in when we delete it.
A basic image has to have a compiler, and there are at least two compilers out there. There are dozens of browsers, which should you use? Should you include Morphic? Croquet uses Tweak, instead.
Pavel Krivanek has done some very cool work on KernelImage, which is an image with no GUI and no tools. It has a compiler, and it has Monticello. It has a command line UI and you can tell Monticello to load Morphic and any programming tools that you want. So, you can build up a fairly standard image from it. This is much more a "core image" than anything else that is readily available. It has some bugs, but I think it is getting close to being usable, and perhaps it should be the next Squeak image after 3.10.
Craig Latta has a system called Spoon, which is even smaller. A basic Spoon image doesn't have a compiler, but can load methods and classes from another image, which does have a compiler. Thus, you can easily build up an image with whatever compiler you want. Spoon is a much more radical system then KernelImage, which is really just a slimmed down Squeak, but I am only talking about the "slimmed-down Squeak" part of Spoon. Since it is more radical, Spoon is further away from becoming the standard, but it also has more potential benefits.
One of the few things we added in 3.10 was Lex Spoon's "Package Universe". Package Universe is a way to load packages. It is sort of like SqueakMap, but it only holds packages that are supposed to work in 3.10 and it keeps track of dependencies between packages, so it has "one click loading". Damien Cassou has used Package Universe to define his "squeak-dev" image. So, the basic 3.10 image has only one browser and has few extra programming tools, but if you load "squeak-dev" then suddenly you have the macho programmers image with code coloring, autocompletion, four kinds of browsers, and so on. Package Universe means that it is really possible to have a core image with lots of more complex images built upon it. At the moment, there is just squeak-dev and squeak-web, but it is easy to image dozens of more complex images.
If we used Package Universe with KernelImage, the base image wouldn't have any programming tools and wouldn't even have a GUI. All that would be in more complex images.
But we aren't there yet!
-Ralph
On Jul 23, 2007, at 9:53 , Ralph Johnson wrote:
Our main goal has been to take things OUT of the image. The 3.9 group also took a lot of things out of the image. But the image is still far from "core". For example, it still has eToys, even though eToys is big and most people don't use it. That is because my rule was "remove anything that we can load back in" and we haven't been able to get eToys loaded back in when we delete it.
I agree that etoys should not be part of a core image - but I can't let "most people don't use it" get by uncommented. Unless you do not count kids as "people", I assert that many more people use etoys than everything else in Squeak. They're just not posting to squeak-dev.
- Bert -
Il giorno lun, 23/07/2007 alle 10.13 +0200, Bert Freudenberg ha scritto:
On Jul 23, 2007, at 9:53 , Ralph Johnson wrote:
Our main goal has been to take things OUT of the image. The 3.9 group also took a lot of things out of the image. But the image is still far from "core". For example, it still has eToys, even though eToys is big and most people don't use it. That is because my rule was "remove anything that we can load back in" and we haven't been able to get eToys loaded back in when we delete it.
I agree that etoys should not be part of a core image - but I can't let "most people don't use it" get by uncommented. Unless you do not count kids as "people", I assert that many more people use etoys than everything else in Squeak. They're just not posting to squeak-dev.
Are they using the standard Squeak.org images? or are they using other images, such as the ones from Squeakland.org?
Giovanni
2007/7/23, Ralph Johnson johnson@cs.uiuc.edu:
If we used Package Universe with KernelImage, the base image wouldn't have any programming tools and wouldn't even have a GUI. All that would be in more complex images.
But we aren't there yet!
I tried to build a squeak-dev image on top of MinimalMorphic (= KernelImage + Morphic). The only problem I found was the absence of the Preferences tool.
On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou damien.cassou@gmail.com wrote:
2007/7/23, Ralph Johnson johnson@cs.uiuc.edu:
If we used Package Universe with KernelImage, the base image wouldn't have any programming tools and wouldn't even have a GUI. All that would be in more complex images.
But we aren't there yet!
I tried to build a squeak-dev image on top of MinimalMorphic (= KernelImage + Morphic). The only problem I found was the absence of the Preferences tool.
How big a problem is that?
2007/7/23, Blake blake@kingdomrpg.com:
On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou damien.cassou@gmail.com wrote:
I tried to build a squeak-dev image on top of MinimalMorphic (= KernelImage + Morphic). The only problem I found was the absence of the Preferences tool.
How big a problem is that?
It depends:
- if you don't need the Preferences, it might work. But I didn't tried because I'm not sure people are interested in a squeak-dev image without being able to set preferences. And setting the preferences right is part of the job of the squeak-dev image.
- if you care about the Preferences, Pavel told me it was not easy to load as a package because there are a lot of things that need to be loaded too.
Il giorno lun, 23/07/2007 alle 11.35 +0200, Damien Cassou ha scritto:
2007/7/23, Blake blake@kingdomrpg.com:
On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou damien.cassou@gmail.com wrote:
I tried to build a squeak-dev image on top of MinimalMorphic (= KernelImage + Morphic). The only problem I found was the absence of the Preferences tool.
How big a problem is that?
It depends:
- if you don't need the Preferences, it might work. But I didn't tried
because I'm not sure people are interested in a squeak-dev image without being able to set preferences. And setting the preferences right is part of the job of the squeak-dev image.
- if you care about the Preferences, Pavel told me it was not easy to
load as a package because there are a lot of things that need to be loaded too.
This could be the trigger for a new Preferences system. The current one isn't that good, IMHO.
Ciao,
Giovanni
Giovanni Corriga <giovanni <at> corriga.net> writes:
This could be the trigger for a new Preferences system. The current one isn't that good, IMHO.
Ciao,
Giovanni
Yes, Preferences should be limited to providing some kind of registration machinery and basic UI and IO services rather than holding the state of all possible packages.
Maybe this can even be done with some kind of <#annotation: > (name is less-controversial than pragma). This way, if Preferences is in the image, it interprets the annotations; if not, then no harm with Undeclared or something...
Nicolas
2007/7/23, nicolas cellier ncellier@ifrance.com:
Yes, Preferences should be limited to providing some kind of registration machinery and basic UI and IO services rather than holding the state of all possible packages.
Maybe this can even be done with some kind of <#annotation: > (name is less-controversial than pragma). This way, if Preferences is in the image, it interprets the annotations; if not, then no harm with Undeclared or something...
I'm not sure annotations are used for that kind of things:
- the preference system would have to browse all methods of all classes to detect these annotations - in which method do you put the annotation? - in your code, how do you access the preference? and if the preference system is not present, how do you code this?
Damien Cassou <damien.cassou <at> gmail.com> writes:
I'm not sure annotations are used for that kind of things:
- the preference system would have to browse all methods of all
classes to detect these annotations
- in which method do you put the annotation?
- in your code, how do you access the preference? and if the
preference system is not present, how do you code this?
VW use them to hook application-dependent-items to launcher menu bar. Which class enumerates the annotations and what event triggers the enumeration? I do not know the implementation details... I only know this is possible.
We should isolate generic Preference services from application packages. My assumptions is that these services are mainly: - reading/writing preferences in a file (IO) - and modifying them through an interface (UI).
Basic idea is to have application preferences stored in local class variables. Preferences could automate UI and IO given registered information: - at least getter and setter and some basic UI (roughly like a web form) - Some information classifying preferences are also needed for presentation, in order to avoid random sort in IO and UI (much like VW menus).
Preferences (un)registration can be: - implicit: via annotations in the methods providing class/getter/setter/UIForm - explicit: send Preferences registration messages from within MyApp initialize. In the latter case, a Preference class MUST be in the image; or we SHOULD protect code with something equivalent to: Smalltalk at: #Preferences ifPresent: [].
That's only very basic ideas. Implementation deserves further analysis if retained.
Nicolas
Like in VisualWorks. Damien have a look at the example on the Pragma class
stef
On 23 juil. 07, at 12:21, Damien Cassou wrote:
2007/7/23, nicolas cellier ncellier@ifrance.com:
Yes, Preferences should be limited to providing some kind of registration machinery and basic UI and IO services rather than holding the state of all possible packages.
Maybe this can even be done with some kind of <#annotation: > (name is less-controversial than pragma). This way, if Preferences is in the image, it interprets the annotations; if not, then no harm with Undeclared or something...
I'm not sure annotations are used for that kind of things:
- the preference system would have to browse all methods of all
classes to detect these annotations
- in which method do you put the annotation?
- in your code, how do you access the preference? and if the
preference system is not present, how do you code this?
-- Damien Cassou
On 23-Jul-07, at 23-Jul;3:21 AM, Damien Cassou wrote:
- the preference system would have to browse all methods of all
classes to detect these annotations
This turns out to be incorrect; you detect the notation during package loading. You have to load the package for the preference to be relevant, During the load you typically have to compile the method or otherwise scan it to make connections; at that point you clearly have an opportunity to deal with any pragmas, annotations, problems or chocolate.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Gargoyle (n.), olive-flavored mouthwash.
This could be the trigger for a new Preferences system. The current one isn't that good, IMHO.
yes
Ciao,
GiovanniYes, Preferences should be limited to providing some kind of registration machinery and basic UI and IO services rather than holding the state of all possible packages.
Maybe this can even be done with some kind of <#annotation: > (name is less-controversial than pragma). This way, if Preferences is in the image, it interprets the annotations; if not, then no harm with Undeclared or something...
Yes annotations can give a nice registration mechanism.
Now the key problem is should the code be loadable in 3.7.... I think that it should not. You cannot improve a system that should be backward compatible. Look at mac. they discard regularly old support and add new ones.
Stef
On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou damien.cassou@gmail.com wrote:
I tried to build a squeak-dev image on top of MinimalMorphic (= KernelImage + Morphic). The only problem I found was the absence of the Preferences tool.
How big a problem is that?
It depends:
- if you don't need the Preferences, it might work. But I didn't tried
because I'm not sure people are interested in a squeak-dev image without being able to set preferences. And setting the preferences right is part of the job of the squeak-dev image.
- if you care about the Preferences, Pavel told me it was not easy to
load as a package because there are a lot of things that need to be loaded too.
Because the code was not designed to be decomposed. A registration mechanism may help there.
Stef
El 7/23/07 4:53 AM, "Ralph Johnson" johnson@cs.uiuc.edu escribió:
That is because my rule was "remove anything that we can load back in" and we haven't been able to get eToys loaded back in when we delete it.
Yes we could unload and load Etoys and Nebraska as Squeak3.10alpha.7091W.zip.
Damien could do a dev image with it , so I have some feedback thanks he.
The reason for not doing is unloading gives us more SystemNavigation default unimplemented.
3.10 7130 have now 179 and most of this was on the image for as old as 3.7.
I could do a more stripped version of 3.10 and put in on my ftp and if Klaus wish he could host it.
Edgar
What if make things in such way, to allow different versions of same package live in same image? And track dependencies between packages using imports?
I discussed this idea on IRC channel with gulik (sorry cant recall his name) about his namespaces project. I proposed to add 'imports' inst var to packages.
Idea is simple: - each package defined as a set of classes and methods. - each reference to global name not declared it package itself, must be declared in imported packages.
Only a few packages, like 'Kernel' don't require to import anything to work. Others may require different set of packages to work.
All we need to change is a global lookup semantics: instead of looking up the system dictionary, we should start looking for name from same package , which contains the method.
On 23/07/07, Brad Fuller bradallenfuller@yahoo.com wrote:
Instead of 'standard packages', what if there was an image consisting of the fundamental classes required -- the basic building blocks for all images. A "core" team could be responsible for this. Perhaps it consists of the improved Squeak classes from the ST-80 image. Or fundamental classes, like the ones you listed, that most everyone agrees should be included. The fundamental classes wouldn't be packages, they'd just be the basic building block for other packages to be added.
For some reason, I thought there was a team like this. Isn't there?
Wouldn't it be technically feasible, no matter how hard it is? The question is what amount of work is acceptable for the community to pursue.
brad
On 7/22/07, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I just spent some in 3.10 and while I felt that there wasn't much that personally excited me about it, there were still plenty of fixes that were interesting enough for me so that I'll have to spend significant time to integrate them into Croquet. And if you look at what has recently gone into Croquet [1] I'm pretty sure you'll find the same the other way around (for example the font caching fixes come directly from Croquet). After looking over 3.10 it again occurred to me how splintered the larger Squeak community is when it comes to some of the core parts of its software.
I think that at some point we'll have to admit that using individual images is a reality that we simply need to accept and deal with it accordingly. And one of the key parts is to understand how to share code across these different images.
The trouble with code sharing is that the most important packages are still completely bound to particular images. There is no "Collection" package that I can load in from 3.4 through 3.10 and expect it to work. There is no common "Numbers", no "Streams", no "Files", Sockets, Sound, Exceptions, anything package. While there are plenty of application-level packages that support a range of images, there is almost nothing at the core of Squeak that can be used across different images.
In fact, there is a Files repository at http://source.squeakfoundation.org/files/ which is supposed to have merged with http://source.squeakfoundation.org/IO but hasn't.
There should be a Collection package. And Numbers and Exceptions.
source.squeakfoundation.org is supposed to be a host for MC repositories for core packages. Some of them are more active than others, and a lot seem to be missing.
I think we can get repositories for other categories IF people volunteer to manage them. But these repositories will work only if the people who volunteer actually do the work when it is needed.
When you say "load in from 3.4 through 3.10 and expect it to work" I assume you mean that it will probably work, but you won't know for sure unless you test it because 3.4 was built with an earlier version of Collection/Number/etc and it is possible that the new "improved" version will break something. If there were a single Collection repository then someone who used 3.4 could at least load the latest version and see if it works. The way things stand, it is pretty hard for anyone to even know what to load.
-Ralph
Ralph Johnson <johnson <at> cs.uiuc.edu> writes:
There should be a Collection package. And Numbers and Exceptions.
source.squeakfoundation.org is supposed to be a host for MC repositories for core packages. Some of them are more active than others, and a lot seem to be missing.
I think we can get repositories for other categories IF people volunteer to manage them. But these repositories will work only if the people who volunteer actually do the work when it is needed.
...
Andreas is right. Core classes are present in each and every fork. Bug fix and enhancements (like speed) should be shared. Collecting them is tedious (the release team knows). There is currently a lot of duplicated work (fork oblige).
Technically: -----------
Remember you might need atomic loading for such core classes (they are used by Compiler, Monticello, ChangeSet etc...). Is this solved?
I am also quite sure that every fork will extend these core classes. Preliminary work is to identify these extensions and mark them as such...
Socially: --------
Who is the authority to decide what goes in core and what is an extension? How to handle deprecation across several images (see the #hex mess for example)? Shouldn't there be a backward-compatibility extension created?
The underlying goal of current organization seems to build a not-so-minimal high quality core image, one on which to rebuild next version forks. What do fork maintainers think of such approach? Shouldn't members of major forks participate to the debate of what goes in core? Wouldn't this help integrating fixes/enhancements happening in forks?
Proposal: --------
Why not a distributed authority approach? For example, a change can be accepted once 3 out of 4 forks agreed on it. Or maybe qualified majority (2 yes, 1 no or less). Not responding in time is an abstention. Without majority, the change remains a specific extension. I know, decision process sounds heavier than current process... But this should provide better rationale and overall improvement, and decrease duplicated technical work.
Nicolas
I would love to have that! I have the impression that the only way there is to have tests (for what is really possible to tests). We could really have a task force focussing on key packages and working so that they are sharable and that when there is a change we know it, identify it, and can control the evolution of the package.
Stef
On 23 juil. 07, at 01:36, Andreas Raab wrote:
Hi -
I just spent some in 3.10 and while I felt that there wasn't much that personally excited me about it, there were still plenty of fixes that were interesting enough for me so that I'll have to spend significant time to integrate them into Croquet. And if you look at what has recently gone into Croquet [1] I'm pretty sure you'll find the same the other way around (for example the font caching fixes come directly from Croquet). After looking over 3.10 it again occurred to me how splintered the larger Squeak community is when it comes to some of the core parts of its software.
I think that at some point we'll have to admit that using individual images is a reality that we simply need to accept and deal with it accordingly. And one of the key parts is to understand how to share code across these different images.
The trouble with code sharing is that the most important packages are still completely bound to particular images. There is no "Collection" package that I can load in from 3.4 through 3.10 and expect it to work. There is no common "Numbers", no "Streams", no "Files", Sockets, Sound, Exceptions, anything package. While there are plenty of application-level packages that support a range of images, there is almost nothing at the core of Squeak that can be used across different images.
And I'm curious if there is interest in changing this. At least on the level where it's fairly non-controversial (e.g., I wouldn't be planning on starting with metclasses, m17n, or compiler) it could be a pretty interesting for various projects to be able to have a common code base, with decent tests to ensure it runs on all the the supported image versions etc. So that, for example, if there is an improvement to Dictionary you can benefit from it implicitly regardless of whether you are using a particular image or not.
In short, what I'm looking for is something like a set of "standard packages" which are supported beyond the particular image they apply to. In thinking about this, two questions came to my mind:
- Is this technically feasible? I'm not certain about this given
how tightly various of the core packages depend on the particular idiosyncrasies of particular images. But it'd be interesting to find out whether (for example) we could make up a "standard Number package" that can easily be installed and supported in various versions.
- Perhaps more importantly, is there any interest in doing
something like this? Since it would most certainly require serious work it could only be done if other people feel the same like I do and are willing to put in some time and effort. If people are happy with where they are today (which is quite possible) then this is a no-win situation.
*If* something like this works, it may be one step out of the image lock-in that we currently endure. It could also help focusing various (currently completely disjoint) parts of the community on help improving a shared base.
Comments welcome.
Cheers,
- Andreas
[1] https://lists.duke.edu/sympa/arc/croquet-dev/2007-05/msg00035.html
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Avi Bryant -
Bert Freudenberg -
Blake -
Brad Fuller -
Damien Cassou -
Edgar J. De Cleene -
Giovanni Corriga -
Igor Stasenko -
Lex Spoon -
nicolas cellier -
Ralph Johnson -
stephane ducasse -
tim Rowledge