On Thu, Jan 21, 2010 at 5:12 PM, keith
<keith_hodges@yahoo.co.uk> wrote:
The trunk process is a "grand project" which hasn't produced anything of any use for 6 months. It signs up the community for an ongoing wait of 12-18 months per release. It ties you in to the "grand project" ethos which we all said we didn't want.
Nonsense. In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits. There are lots of other things also; go look at the recent changes list. Trunk is actually progressing very nicely.
Hi Elliot,
First of all these things are of no use to me, because my code base will take about 2 months to port, longer since I now have to port the tools as well.
But lots of other people are using the progress just fine. Pharo is harvesting work from Squeak and vice verce. All it takes is will and knowledge of the available tools. Monticello is a huge enabler.
You might think you are doing the community a service, but actually you haven't provided stuff or "captured knowledge" that the existing community can use easily. All you have done is encouraged some members of the community to abandon the rest of us, moving over to developing stuff for a new image that I cant use, leaving behind compatibility. My production images don't have closures, the customer asks for an update, I cant load the latest seaside if it uses closures for example. This is the same as the pharo "stuff compatibility" attitude and they are also developing stuff I cant use.
That's one viewpoint (an intellectual horizon of radius zero as Albert said). From another perspective what I've done is set the stage for a series of VMs which have significantly better performance, the first (in use at Teleplace) showing 5x the performance of the existing VMs, eliminated a major short-comming of the Squeak/Pharo execution core by eliminating non-reentrant blocks and providing the ability to write much cleaner code, and have made Squeak/Pharo execution semantics ANSI-compliant and equivalent to other leading dialects.
If you hadn't spend the last 6 months having a hissy fit you would find you weren't as far behind or as inconvenienced. You might also have participated in porting the closure bootstrap (which does exist as changesets on my blog site and has been adapted to three different Squeak distros so far) to your context. Instead you've chosen to disengage, and make a signally unconstructive return. I find myself unsympathetic to your concerns.
For example, Magma runs in Pharo and 3.7 - 3.10, apparently you provide closures, but if closures aren't available as a loadable/applyable feature for 3.7 then magma has to choose either not bother to use closures, maintain two or three codebases, or drop support for older images. The knowledge to implement closures has been redone 3 times now, in trunk, pharo, and cuis, but I don't have the expertise to do it myself.
and what would be the point of maintaining an evolving package for old images? Eventually the old becomes the obsolete; the cost-benefit ratio falls below 1. If you want to be a curator then that's up to you, but I get the impression that this community wants to be productive and self-expressive. The past is past.
(& BTW the knowledge on how to implement closures is widespread (mine is based on a lisp implementation strategy), and what you're talking about is the bootstrap, not the implementation).
I think you misunderstand me my gripe is not about making progress, it is about throwing all the knowledge into one disorganised pot, aka "trunk".
Whatever. Looks like you failed over two years to make a new release, got upset when people finally lost patience and started work again, and that you lack the objectivity to realise your part in your misfortune.
If you had kept the knowledge needed to implement closures as a separate initiative, in a separate repo, with separate change sets, scripts etc then other people could harvest that knowledge, either all or in part, and you would be contributing "knowledge" that I could import into my codebase. Perhaps cobalt would like closures too. Cobalt is not going to be able to move to build on trunk-alpha overnight either, so they are going to have to do it all over again.
Again, the change sets are there, but one problem with change sets is the lack of tool support for evolving them. The only way I know is to manually back-merge fixes. Alas I can't afford the time; I have further progress to make.
The same goes for bug fixes. Previously we had 100 fixes ready to load into 3.10 from mantis, all documented, and supplied in their natural form "changesets". Throwing fixes into trunk, dilutes the knowledge, and makes it only useful for trunk users and no one else. I cant harvest a fix out of trunk, into my image.
The usefulness of both changesets and packages and the tensions between them is a really interesting and large topic that I'm not going to address here, but putting things in well-defined packages that can be unloaded from a trunk image does not dilute important knowledge (the change history in a package is richer than in a changeset, as there are multiple changes, each with a comment) and is clearly more useful to users other than trunk users because of the degree of interchange between Pharo, Squeak and Cuis that is obvious at the moment (new text editor, faster buffered file reading, native fonts, etc, etc). These exchanges are being done by people who are happy with Monticello but more interested in the message than the medium. Your criticisms seem very much to me like sour grapes from one who is set in his ways and wants to take his marbles away because others want to play a different game. You were the one who wouldn't release Bob open source.
I suggested a compromise back in August, that Andreas ignored completely. That if trunk development was split into clearly defined initiatives with separate projects, then we would be able to work together.
Is that what you were doing? I thought you were flinging mud. I certtainly didn't get the impression you were offering a compromise.
Again feel free to correct me if I am wrong.
I think I'm pissing in the breeze. Surprise me if I'm wrong.
Eliot