[squeak-dev] [Cuis] Cuis

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 22 04:23:29 UTC 2010


On Thu, Jan 21, 2010 at 5:12 PM, keith <keith_hodges at 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.


>
> Keith
>

Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100121/3dca19ea/attachment.htm


More information about the Squeak-dev mailing list