[squeak-dev] ToolBuilder-Kernel changes made by Matthew Fulmer

Matthew made some enhancements to ToolBuilder, which currently held in
separate repository at
squeaksource.com/DeltaStreams under the ToolBuilder-Kernel cat.

Some of the changes would be really nice to integrate in trunk, like

- renamed PluggableListSpec>>size to listSize
- added PluggableListSpec>>listItem, as an optimization to only fetch
items in view rather than the whole list, when scrolling

or maybe i'm not aware, and they are already in trunk?
I just want to ask anyone who is interested to make an overview of
changes and decide if its safe to push them to trunk image (or
official ToolBuilder repository).

--
Best regards,
Igor Stasenko AKA sig.

Question:
If ToolBuilder has its own repository, and changes to ToolBuilder are done at separate repository at squeaksource.com/DeltaStreams, then also put into the trunk repository, then it is found in trunk that a small fix is required to ToolBuilder, where would the be fix be stored? If done just locally to trunk,  how would it ever be possible to keep ToolBuilder in its separately loadable repository in sync?

Similarly for MC. I've seen the following go by:
At 3:36 AM +0000 8/31/09, [hidden email] apparently wrote:
>Andreas Raab uploaded a new version of Monticello to project The Trunk:
>http://source.squeak.org/trunk/Monticello-ar.321.mcz

Yet it is clear that at the public repository for MC at http://www.squeaksource.com/mc/, that Monticello is already at at least version 492. How does the Andreas 321 change relate to the 492 version in the public MC repository?

What are the plans for keeping versions of separately loadable modules like Monticello, or ToolBuilder in sync?

Or if forking Monticello, shouldn't it have a different name?

Or am I missing something?

Are the planned work items for trunk documented anywhere?

Ken G. Brown

At 6:51 AM -0700 9/7/09, Igor Stasenko apparently wrote:

On Mon, Sep 07, 2009 at 12:19:19PM -0600, Ken G. Brown wrote:
> Question:
> If ToolBuilder has its own repository, and changes to ToolBuilder are done at separate repository at squeaksource.com/DeltaStreams, then also put into the trunk repository, then it is found in trunk that a small fix is required to ToolBuilder, where would the be fix be stored? If done just locally to trunk,  how would it ever be possible to keep ToolBuilder in its separately loadable repository in sync?

I think I actually abandoned those changes to ToolBuilder. They
worked fine and are only additions, and so break nothing,
however, Goran and I decided to use plain Morphic rather than
Toolbuilder, as Morphic is on more platforms than ToolBuilder.
Etoys, notably, lacks ToolBuilder.

> Similarly for MC. I've seen the following go by:
> At 3:36 AM +0000 8/31/09, [hidden email] apparently wrote:
> >Andreas Raab uploaded a new version of Monticello to project The Trunk:
> >http://source.squeak.org/trunk/Monticello-ar.321.mcz
>
> Yet it is clear that at the public repository for MC at http://www.squeaksource.com/mc/, that Monticello is already at at least version 492. How does the Andreas 321 change relate to the 492 version in the public MC repository?

Actually, monticello 1.5 is at version 648:
http://www.squeaksource.com/mc/Monticello.impl-mtf.648.mcz

dunno of any reasonable way to keep external packages updated
other than by adopting them. I have merged in some Pharo changes
into MC1.5, and can do the same for trunk, if I ever get time to
work on mc again. MC1.5 is ready for adoption, I think. It may
have trouble loading some packages, but I won't really know
until a bunch of people test it.

I'd say MC1.5 is ready for adoption, if the following conditions
can be met:
- Users write mantis bug reports about it
- bugs submitted under the Monticello category are automatically
  assigned to me, rather than Avi Bryant, so they show up in my
  inbox

In the past, mc1.5 adoption was hindered because keith and I,
the developers, never heard any report of some rather serious
loading bugs, even though we have a record of fixing any bug we
do hear about in hours.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Hi Ken -

[Regarding ToolBuilder]
This is a matter of the amount of work that people can invest. I would
very much like to keep the upstream repository for ToolBuilder in sync
but I have only so much time to spend. If you (or anyone else) would
like to help, I can add you as a developer to the squeaksource project.
Just let me know.

[Regarding MC]
The problem I am having with the latest version in squeaksource is that
as far as I know, nobody is using it. Yes, I've seen the "amused"
comments on IRC about the trunk using such an outdated version - but
it's the only version I know works, and so far nobody has proposed a
viable upgrade path. But most importantly that code needs mileage; if
you can find me someone who says they've been running it in production
for a couple of months with a reasonable work load I would feel *much*
better about it[*]. I'm not opposed to upgrading Monticello to any
version that's in the repository but I'd like to have either some
assurance that the code will be working out of the box (i.e., mileage)
or alternatively the explicit commitment from someone (Keith or anyone
else who knows their way around in the latest MC) to quickly fix issues
that come up.

[*] For example, if you would load the latest MC into a 3.10 image, hack
its ancestry so that it looks as if it's derived from the latest version
in the trunk, and then just update all the way through, this would go a
very long way in convincing me about that the code is stable.

[Planned work items]
I can only speak for my own plans here since I am in no position to tell
other people what to work on. My main focus is currently in two areas:
MVC removal (which is making progress) and some m17n simplifications
(which you've seen discussions about). That and integration of existing
fixes (strictly on a need basis) pretty much sums it up.

Others should comment themselves on what they are planning to work on.

Cheers,
   - Andreas

Ken G. Brown wrote:

2009/9/7 Ken G. Brown <[hidden email]>:
Ken, my opinion is always were to keep changes in official
repositories which belong to some package, not
the diverse set of repositories attached to some projects.
But for some time it is necessary, because developer who may want to
do own quirks is not sure if given changes
are will be useful / adopted outside his own project.
So, what i proposed is to make an overview of a changes, and if they
is generally useful for more broader audience than
single project, it may worth merging them to the main repository.



--
Best regards,
Igor Stasenko AKA sig.

On 07.09.2009, at 20:54, Matthew Fulmer wrote:

Can't you just load the ToolBuilder support into Etoys so any new tool  
using it would work, without us having to refactor much?

Also, we wouldn't mind adopting ToolBuilder in Etoys for real but  
there simply are so many issues to fix in Etoys itself that these  
things tend to never get done by the core team. Our summer release is  
imminent so it would take a few weeks but otherwise - sure, why not :)

I always wondered - why the strange package name?


Great! Can you figure out a way to load it into 3.10?

- Bert -