[Meta] Standard packages?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Meta] Standard packages?

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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Brad Fuller-2
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



Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Brad Fuller-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Avi Bryant-2
On 7/22/07, Brad Fuller <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Ralph Johnson
In reply to this post by Andreas.Raab
On 7/22/07, Andreas Raab <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Ralph Johnson
In reply to this post by Brad Fuller-2
On 7/22/07, Brad Fuller <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Ralph Johnson
In reply to this post by Brad Fuller-2
On 7/23/07, Brad Fuller <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Bert Freudenberg
In reply to this post by Ralph Johnson
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 -



Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Damien Cassou-3
In reply to this post by Ralph Johnson
2007/7/23, Ralph Johnson <[hidden email]>:
> 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.

--
Damien Cassou

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Blake-5
On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou  
<[hidden email]> wrote:

> 2007/7/23, Ralph Johnson <[hidden email]>:
>> 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?



Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Nicolas Cellier-3
In reply to this post by Ralph Johnson
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



Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Giovanni Corriga
In reply to this post by Bert Freudenberg
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


Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Damien Cassou-3
In reply to this post by Blake-5
2007/7/23, Blake <[hidden email]>:
> On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou
> <[hidden email]> 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.

--
Damien Cassou

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Edgar J. De Cleene
In reply to this post by Ralph Johnson



El 7/23/07 4:53 AM, "Ralph Johnson" <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Giovanni Corriga
In reply to this post by Damien Cassou-3
Il giorno lun, 23/07/2007 alle 11.35 +0200, Damien Cassou ha scritto:

> 2007/7/23, Blake <[hidden email]>:
> > On Mon, 23 Jul 2007 01:50:01 -0700, Damien Cassou
> > <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Nicolas Cellier-3
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


Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Damien Cassou-3
2007/7/23, nicolas cellier <[hidden email]>:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

Nicolas Cellier-3
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



Reply | Threaded
Open this post in threaded view
|

Re: [Meta] Standard packages?

stephane ducasse
In reply to this post by Andreas.Raab
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:
>
> 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
>
>


12