Monticello, SM2, BFAV in 3.7alpha
ducasse at iam.unibe.ch
Mon Feb 2 08:53:40 UTC 2004
Ok today I stop my strike from Squeak-dev and I will see if I can help
I just want to say a word there because I was a bit surprised by your
email (still understand it).
- Monticello is not henryk module
(you know that ***we*** were some of the fews that really tried to
understand and push henryk modules)
monticello is really close to ginsu (joseph will never deliver
anything but this is another story).
- Can you tell me what you do not like in monticello. (I have a list of
things that I do not like
especially the lack of dependencies but avi has a first solution). I
think that giving feedback
is important for avi and the rest of people.
- What I see is that we need a way to express (yesterday I read some
email of the old mailing list on modules)
load dependent code
load ***atomically*** code
be able to say that a method is belonging automatically to another
changeset (not like it is done now)
we need a real representation of what is happening in the system and
changesets do not support
that (ask alex about the mess we got to split our KCP changes in 3.5
so that they could be put in 3.6,
may be this was our mistake we should have jsut do not care at all of
squeak and just steal what
could be stolen there. I know you contribute! so this is not against
you but I have to argue with people
here so that they spend time to make sure that their changes are not
loading bytecode (alex already did some experiences with that)?
- Changesets are hopeless to build robust process.
Ask nathanael the mess we got because they only record changes.
- So I'm not saying that we should have a packaging system in the image
this is with this kind of attitude that we are sure Squeak will
stay where it is.
Do you have an alternative?
- Categories are a stupid packaging system, making categories real
- please note that I'm talking about module (with import and visibility
I just talking about identifying the right piece of code and its
On 27 janv. 04, at 00:35, Michael Rueger wrote:
> Doug Way wrote:
>> goran.krampe at bluefish.se wrote:
>>> PS. We did more or less decide to stuff Monticello into Basic -
>>> it is high time now that SM2 is running?
>> We could, if the current version of Monticello is reasonably stable.
>> We should at least put it on the to-do list for 3.7alpha if we're
>> sure we want to add it. http://minnow.cc.gatech.edu/squeak/3491
> I may be the lonely kid on the block here, but I'm against it on
> principle. I don't use the Monticello for a variety of reasons, but
> besides that I don't want *any* (can I double bold this?) packaging
> system in the basic system.
> Packaging systems have the tendency to viral themselves into all
> aspects of the core system and once they are there, nobody even has
> the chance to come up with a different approach.
Have you some other approaches? Because for me maintaining a script by
hand is ***painfull***
Does not scale.
> The total and utterly failure of the module system, from which we had
> to back out as we couldn't remove it any more, taught us a lesson,
> please let's remember it.
yes it was too ***complex*** and we are again one the fews that really
monticello is no rocket science it is just a good and simple approach
of the problem (like Ginsu was).
> I'm not saying that Monticello is not a usable (and hopefully at some
> point stable) system, but packaging should not be built-in. Period.
> I like the SM approach, as it does not enforce a particular packaging
> approach, but rather allows people to post their code in whatever
> loadable format they want.
I'm not saying that we should have monticello in the image. but I'm
saying that we should have a way
to get rid of the terrible mess of changesets, fileout:asHtml and other
But apparently we are living in a perfect world.
More information about the Squeak-dev