On 2/23/06, Brad Fuller brad@sonaural.com wrote:

...

...

Total authorized voters: 343 Actual votes cast so far: 125

This says to me that the community, although small, cares about leadership and where squeak is heading.

Well... As a fraction of squeak-dev subscribers, we're at roughly 10%... Maybe I'm a pessimist (unlikely) or maybe my expectations are too high, but that's not really much. It's probably enough to declare a usable election result, but I really do hope that next year, we can make a leap to a substantially higher proportion of list subscribers (which, I think, is maybe half of the community of squeak developers - purely a guesstimate from the number of people I meet who are involved in various open source projects but don't subscribe to the accompanying mailing lists).

Cees De Groot puso en su mail :

Well... As a fraction of squeak-dev subscribers, we're at roughly 10%... Maybe I'm a pessimist (unlikely) or maybe my expectations are too high, but that's not really much. It's probably enough to declare a usable election result, but I really do hope that next year, we can make a leap to a substantially higher proportion of list subscribers (which, I think, is maybe half of the community of squeak developers - purely a guesstimate from the number of people I meet who are involved in various open source projects but don't subscribe to the accompanying mailing lists).

Maybe if nobody wish reelection and votes counts for each person.

Or if "masters" behave like you, gentle with people , good leading and not trying all do his way.

I vote only in the hope what new people and some of old correct the crash course to the iceberg, what shy people don't say but thing is the current 3.9 release.

Edgar

___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

Marcus Denker puso en su mail :

It is of course the decision of the new SqF board what to do with 3.9a, if the board decides that it is complete crap, they should throw it away.

If 3.9 was the good product what you believe, what its the logic of a 3.8.1 release ?

All time I read about legal consequences of using Squeak, what if Disney charges who cause actual Squeak don't read jpg because they just wish base his killer app on this ?

And people what only have poor dial up connection what in old good times connect and retrieve updates (as Smalland SqueakPlugin-dev.image still does) .

Now they should pay huge money if wish do the 12 mb download each few days.

I see you are working on the new releases now, and I know you are a good a dedicated Squeaker, so maybe things improve soon.

And all my sends was complete ignored, so I fix my own Squeak , do tutorials, train students, and sit and wait until winds change.

Edgar

___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar

On 24.02.2006, at 12:05, Lic. Edgar J. De Cleene wrote:

Marcus Denker puso en su mail :

...

It is of course the decision of the new SqF board what to do with 3.9a, if the board decides that it is complete crap, they should throw it away.

If 3.9 was the good product what you believe, what its the logic of a 3.8.1 release ?

Bugfixes? Every software project in the world does this: There are stable and unstable branches of Linux, for example. This is industry practice, and good one. It was just ignored by the Squeak community until now.

All time I read about legal consequences of using Squeak, what if Disney charges who cause actual Squeak don't read jpg because they just wish base his killer app on this ?

Not that I understant what you are saying... But in general: How are the legal problems with the license related to what we added to 3.9a?

And people what only have poor dial up connection what in old good times connect and retrieve updates (as Smalland SqueakPlugin-dev.image still does) .

Now they should pay huge money if wish do the 12 mb download each few days.

This is indeed a problem that I, too want to see fixed. The current setup with MC is far from perfect.

I see you are working on the new releases now, and I know you are a good a dedicated Squeaker, so maybe things improve soon.

And all my sends was complete ignored, so I fix my own Squeak , do tutorials, train students, and sit and wait until winds change.

Are your changes in the Mantis Bugtracker? Keep in mind that there are over 300 items in the bug tracker... we can not garantee to react on everything directly.

Marcus

On 24.02.2006, at 13:04, Lic. Edgar J. De Cleene wrote:

Marcus Denker puso en su mail :

...

Not that I understant what you are saying... But in general: How are the legal problems with the license related to what we added to 3.9a?

3.9.7001 could use jpg ? No ? 3.9. 6705 yes, so someone broke and I want jpg back.

Ah, there is a bug in the Traits implementation wrt. to primitives. The Traits guys now how to fix it, so this will be definitely fixed soon.

You know, 3.9 is in "alpha" which means: "Please test, but we are sure that there are problems".

You are saying same thing different, Mantis is difficult, and real masters are busy for reviewing things.

In one case I have a two years wait for a trivial fix and my original send was great improved by Scott Wallace. His explain of how the all thing should be is one of the first what I show to my students of very good Squeak code and things to note. And still all community should wait two years...

Yes, these cases happen... and this used to be *very* much worse in the past!

We tried to improve getting community submissions in, but this does not mean that there is a garantee of having a reaction to everything you send.

I send a proposal for unify the different clases, globals, etc what keep pictures into image and example to my own team and still waiting why is not a good solution. And this is crucial for shrink the image properly...

So, did you add this this mantis? Stuff sent to the list by email are lost very soon.

Send proposal for cleaning Morph and same.

There is a Team for Morphic. Are you on the Mailinglist?

Marcus

Hi Stef -

Two notes on your message:

Our goal is to have a small image [...]

I will point out that since 3.6 (the first version where we had a distinction between basic and full and where an image got substantially smaller) the basic image has only grown; now to a size where it rivals the size of 3.6 full. Mind you, the *basic* 3.9 image is almost as large as the *full* 3.6. You can draw your own conclusions from that (easily verifiable) fact.

Now .cs are not the future. All the good project work with MC (croquet, sophie, seaside, tweak....

I'm sorry to disappoint you, but for our next project at VPRI we just pulled out of Monticello. In short, Monticello is a great way of doing things if you have an environment which is based on "builds" (e.g., you basically throw existing content away, build a new system and load that content back in).

For maintaining a live system Monticello is simply a nightmare. It's slow, it doesn't work in the right way for incremental migrations and you are spending 90% of your time to deal with situations that change sets solve in a nano-second. It's simply not worth the hazzle for maintaining a live system.

So I wouldn't declare change sets dead quite yet; neither would I claim they are "not the future" when it comes to maintaining a live system. In fact, I believe they are. For example, just compare how long it takes to update a 3.7 to 3.8 image vs. 3.8 to 3.9 - it literally takes *ages*, it requires "extra" change sets to do things that Monticello simply cannot do and by the end of the day updating a 3.8 to current 3.9 alpha doesn't even work. I cannot recall a single case of where this has ever happened with change sets.

I think a discussion about how Monticello fits a working style that can be used to maintain a live system is overdue by now. Having been there, having seen the immense pain Monticello inflicts on both sides of the maintenance chain (not only is it a pain for the person doing the maintenance, it is also a pain for the person on the receiving end of the maintenance) I think we can say with some certainty that Monticello fails in this regard and that another approach is needed.

Cheers, - Andreas

On Feb 25, 2006, at 4:54 AM, Andreas Raab wrote:

I think a discussion about how Monticello fits a working style that can be used to maintain a live system is overdue by now. Having been there, having seen the immense pain Monticello inflicts on both sides of the maintenance chain (not only is it a pain for the person doing the maintenance, it is also a pain for the person on the receiving end of the maintenance) I think we can say with some certainty that Monticello fails in this regard and that another approach is needed.

Good idea.

First, let me mention that Monticello was designed with maintaining live system in mind. I think where it falls down is with scale. If you're working on a system with lots of packages, packages containing lots of code, packages with lots of ancestry, or with changes cutting across lots of packages, it does get slow. Also, we try to deal with some aspects of this slowness with caching, which can take up a lot of memory. So, yes speed is a problem for anything but small projects.

You also mentioned that "it doesn't work the right way for incremental migrations." The strategy Monticello uses it to compare the version being loaded with what is already in the image and make only the necessary changes. Are you finding that this is the wrong strategy for your needs? Or perhaps that Monticello isn't executing that strategy well?

I also agree that a different approach is required. I don't think the way ancestry information is modelled in Monticello will allow for much more optimization, so we'll have to change something fundamental. I have some ideas about the direction to take, but I'd be interested in hearing what you think would be useful.

Colin

Aside from general tool irritations (basically morphic problems along with simple UI design failings) the only big annoyance I have with MC is the way that it violates a very longstanding idiom - so longstanding that I think you would find it encoded in my mRNA - of always running the class initialise method after loading changes to a class. I can't begin to think of the number of times I've been screwed by that.

Mostly I just find MC works. I'm sure it could be better but really, it basically just works.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Who is General Failure and why is he reading my disk?

Colin Putney wrote:

First, let me mention that Monticello was designed with maintaining live system in mind. I think where it falls down is with scale.

Actually, I think there are some very fundamental issues when using Monticello in a live system, e.g., a system which has live instances of the classes being changed. The most important ones I can think about (which have nothing to do with scale) are renaming classes and series of class migrations.

For example, when you rename class Foo into Bar Monticello is utterly unable to recognize this and will happily convert all of your existing instances into ObsoleteFoo's. That's deadly in a live system. Similarly, if you change the shape of a class multiple times and require intermediate steps to update existing instances, Monticello will often (by combining all the changes into a single one) wreck utter havoc upon the system. Or take "reclassifications" (e.g., moving methods between packages) - unless you take great care, methods may simply be removed. Or doIts - many a time we need to do one-time fix-ups and those may only be appropriate at a single point in the evolution of the live system (e.g., cannot be handled in an initialize method). Monticello has no good way of dealing with that. And I won't even go into dependencies (e.g., you need change A before change B before change C) since this is only partly a Monticello issue (but MC does make it hard to serialize changes properly).

All of these have caused me lots of trouble and none of them has much to do with scale. I think that the key issue is that because of the snapshot approach that Monticello uses, it simply lacks information. Information like whether class Foo has been renamed to Bar (contrary to adding Bar and removing Foo), information like whether a method has been moved out of a package vs. it being removed from the system. And since it looses the intent of the change it needs to guess later on and it just guesses wrong as often as it guesses right.

Interestingly, this information *is* available in change sets which is really at the root of my claim that change sets are better suited to maintain live systems. Speed, scale, cross-cutting changes are (albeit important) secondary to these more fundamental issues.

You also mentioned that "it doesn't work the right way for incremental migrations." The strategy Monticello uses it to compare the version being loaded with what is already in the image and make only the necessary changes. Are you finding that this is the wrong strategy for your needs? Or perhaps that Monticello isn't executing that strategy well?

It's really both. If I rename class Morph to FooMorph I cannot afford Monticello to nuke all Morphs. If I move Object>>size between packages I cannot afford Monticello to nuke that method just because I load an updated version of the package that contained #size before (even if I load the other package later chances are that my system has long died since then).

I also agree that a different approach is required. I don't think the way ancestry information is modelled in Monticello will allow for much more optimization, so we'll have to change something fundamental. I have some ideas about the direction to take, but I'd be interested in hearing what you think would be useful.

Well, it's a hard problem. One idea might be to actually record the changes and use that in cases where it is relevant (e.g., remove vs. classification etc). I'm certain there are issues with that approach but it might be worthwhile to think about.

Cheers, - Andreas

Todd Blanchard wrote:

They seem to be good at different things. Monticello is all about maintaining packages and in my view is a much *SAFER* mechanism for loading in new functionality (packaged code) than changesets. For one thing, it does a good job of preflighting the changes and if its going to have issues it will tell you and you can bail on it or it will help you get to the desired final state. So as a librarian - MC is DA BOMB.

Agreed. As a programmer who is trying to build a system from first principles MC is vastly superior to change sets.

However, when it comes to maintaining modules and packages (chunks of capability that are a "THING"), I feel that changesets are AWFUL, crap out more often than not because my image isn't in the starting state the changeset was based on and changeset loading doesn't preflight well. If it fails I have an image in an indeterminate state and have to quit and relaunch to get back the last saved (and sane) state. I can't begin to count the number of times I've set out to load a .sar file and had it crap out because something in my image wasn't in the state that file expected.

It's a funny set of tradeoffs since I could counter this with pointing out that it is now pretty much impossible for anybody to keep up-to-date with the latest alphas. All of your changes will be wiped out by loading that latest one-line fix which means you have to rebuild your image from first principles whenever anything changes (e.g., all the freaking time ;-) I wonder how many people these days actively track 3.9alpha (if at all) and how many of those do *any* of their own work in these images. Personally, I stopped doing it after a few more important changes got wiped clean, where (in the past) I've typically used the latest-greatest to make sure things get tested properly.

As an exercise, try grabbing a 3.6 basic image and see if, using old .sar's on SqueakMap, you can get an image configured with Kom, Seaside, Postgres, and GLORP and let me know how many tries it takes you.

Yup. Agreed. And countered by: Try grabbing a 3.8 image and get it to 3.9 using Monticello alone ;-) And then use the update stream and see it fail, too, because there are apparently some dependencies which need to be carefully observed and have been condensed by Monticello in the wrong form. [Disclaimer: Haven't tested this very recently; I tried it a couple of weeks ago and got totally hosed].

This is because changesets don't capture the expected initial and final state - only the transitions - and that is seldom enough when you're trying to work in a team and build a single "thing".

We really need a tool that knows both.

Agreed as well.

Cheers, - Andreas

On Feb 25, 2006, at 11:08 PM, Andreas Raab wrote:

Well, it's a hard problem. One idea might be to actually record the changes and use that in cases where it is relevant (e.g., remove vs. classification etc). I'm certain there are issues with that approach but it might be worthwhile to think about.

It's a hard problem in general, but dealing properly with class renames isn't all that hard - we just need to track classes by some kind of unique ID (which we assign the first time we see them and maintain from then on) rather than by name. This would be a very shallow change to MC, and even making it backwards compatible shouldn't be *that* hard.

Avi

Avi said: "It's a hard problem in general, but dealing properly with class renames isn't all that hard - we just need to track classes by some kind of unique ID (which we assign the first time we see them and maintain from then on) rather than by name. This would be a very shallow change to MC, and even making it backwards compatible shouldn't be *that* hard."

Harmony, the module/versioning tool I developed about ten years ago, did exactly that: it tracked classes, Modules, Subsystems and Systems by GUID (a System is roughly analogous to an Envy config map--it specified the complete set of classes and methods that would be resident in the image.)

Harmony could also export either "absolute" or "relative" versions of modules (or subsystems, or systems.) The "relative" exports were somewhat like changesets, except that they were generated by version difference computations.

Harmony permitted the same methods and class definitions to reside in any number of modules, the same modules to reside in any number of Subsystems, and the same Subsystesm to reside in any number of Systems. An extension method was simply any method in a module in which the method's class definition did not reside. Version conflicts were won by whichever module got loaded last--but the losing modules would be marked as changed. Conflicts were only possible when loading modules a la carte, instead of as part of a containing Subsystem or System.

Harmony, unlike Envy, neither required nor used a central server. It was designed to allow team members to work "offline," and enable them to merge their work with that of others whenever convenient.

What Harmony didn't do was provide any namespace support. I now realize that that was a big mistake (another big mistake was not providing very much documentation.) In fact, were I to attempt such a project again, there's a variety of things I would do differently, although there would proably be some resemblance to the feature set I describe above.

Craig Latta's Naiad system is also based on GUIDs. Craig and I had many discussions about the architecture and design of Harmony a decade ago.

When you combine Namespaces with GUIDs, you get a synergistic effect that is better and more powerful than the sum of its parts. The effect is to give classes and modules a kind of "object identity" AT DESIGN/CODE TIME that is persistable and transportable across address spaces. This is a key, fundamental benefit of the Naiad/Spoon architecture. Go Craig!

--Alan

On 24.02.2006, at 13:07, Patrick Mauritz wrote:

Marcus Denker wrote:

...

This is indeed a problem that I, too want to see fixed. The current setup with MC is far from perfect.

provide xdelta[1] or bsdiff[2] files then? some stats: 7000: zip 13495279 bytes, image 20750832 bytes, changes 22681123 bytes 7001: zip 13481005 bytes, image 20679256 bytes, changes 22723916 bytes 7002: zip 13511250 bytes, image 20707776 bytes, changes 22798872 bytes

bsdiff files 7000-7001: image 299297 bytes, changes 5534 bytes total: 234831 bytes 7001-7002: image 981158 bytes, changes 11060 bytes total: 992268 bytes

they only work against the originally downloaded file, but that could be at least a usable workaround until there's some way to do a proper image update via MC.

Good idea! I will do that.

Marcus

Il giorno sab, 25/02/2006 alle 09.54 +0100, Serge Stinckwich ha scritto:

Marcus Denker a écrit :

We also need like Linux a maintainer for the stable and the unstable branches. When the 3.9 stable version will be out, we have to find someone (or a team) for doing 3.9.1, 3.9.2, ... versions.

Couldn't the 3.9 team do that?

Giovanni