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!
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
Hi!
On Mon, 28 Sep 2009, Andreas Raab wrote:
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?
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Levente Uzonyi -
Levente Uzonyi