[squeak-dev] New Collections modifications in the inbox

Hi!

I uploaded my latest modifications to collections to the inbox. The
suggested load/merge order is:

Collections-ul.144
Kernel-ul.251
Collections-ul.145

To load/merge these packages, you should have both Collections-ul.140 and
Collections-ul.143 loaded/merged.

Since the trunk doesn't have enough tests for the Collections package I
decided to load these changes into the latest pharo image and run the
tests. All of them pass, except for the tests for
WeakKeyToCollectionDictionary, but that's because of a bug in the tests
(The tests add SmallIntegers as values instead of Collections to the
dictionary. Unfortunately they all pass with the original implementation,
because #rehash is never sent to the dictionary).

To see if it's worth (or not) to use these changes I wrote a small
benchmark for Dictionary which can be found here:
http://leves.web.elte.hu/collections/ .

Cheers,
Levente

Levente Uzonyi wrote:
> Since the trunk doesn't have enough tests for the Collections package I
> decided to load these changes into the latest pharo image and run the
> tests.

How about merging these tests into trunk? This would make it easier for
other improvements as well.

Cheers,
   - Andreas

Hi Levente -

I've been looking at the changes in the inbox, but I can't seem to find
a load order that allows one to reliably load these packages.
Unfortunately, the mix of new methods, removals, and deprecations leads
to a virtually impossible set of constraints and I've not been able to
find a straightforward solution.

Can you provide a specific order in which to load these packages into
the trunk so that I can devise a proper set of update maps?

Thanks,
   - Andreas

Levente Uzonyi wrote:

Hi!

On Mon, 28 Sep 2009, Andreas Raab wrote:

Merge the packages in the following order:
Collections-ul.137
Collections-ul.138
Collections-ul.139
Collections-ul.140
Collections-ul.141
Kernel-ul.249
Collections-ul.142
Kernel-ul.250
Collections-ul.143
Collections-ul.144
Kernel-ul.251
Collections-ul.145

I'm about to upload 3 more packages to the inbox, that's 15 packages to
merge (some of them have conflicts).
If mc would have a more predictable load order for methods, like - add
all, change all, remove all - then it would be easier to package similar
changes.

Cheers,
Levente

Levente Uzonyi wrote:
> Merge the packages in the following order:

Phew. That was quite a bit but it's done now. Thanks for the load order.

> I'm about to upload 3 more packages to the inbox, that's 15 packages to
> merge (some of them have conflicts).

When you do this, can you update your image before applying the changes?
I had to do some "pseudo-merges" (i.e., manually installing the patches
and ignoring its history) since MC for some reason considered the
changes to be conflicts. It would be good if we could avoid this going
forward.

> If mc would have a more predictable load order for methods, like - add
> all, change all, remove all - then it would be easier to package similar
> changes.

Yeah, I did a small change that helps with that but I think we do need
atomic install for methods. Having just spend some time in the relevant
methods I actually think that's not too hard to do but it'll require
some testing. The good news is I have some good test candidate packages
to try ;-)

Thanks for all your work, and keep it coming!

Cheers,
   - Andreas

Hi!

On Tue, 29 Sep 2009, Andreas Raab wrote:

> When you do this, can you update your image before applying the changes? I
> had to do some "pseudo-merges" (i.e., manually installing the patches and
> ignoring its history) since MC for some reason considered the changes to be
> conflicts. It would be good if we could avoid this going forward.
>

The new packages are in the inbox. I usually start from a fresh, updated
image when I'm about to add something to the trunk, but this was a special
case. It would be nice the have the inbox repository added to mc in
the prebuilt images to make it even easier to contribute.

Cheers,
Levente

Hi!

On Tue, 29 Sep 2009, Andreas Raab wrote:

> When you do this, can you update your image before applying the changes?
I
> had to do some "pseudo-merges" (i.e., manually installing the patches
and
> ignoring its history) since MC for some reason considered the changes to
> be conflicts. It would be good if we could avoid this going forward.
>

The new packages are in the inbox. I usually start from a fresh, updated
image when I'm about to add something to the trunk, but this was a special
case. It would be nice the have the inbox repository added to mc in the
prebuilt images to make it even easier to contribute.

Cheers,
Levente