Thanks everybody for the feedback/discussions, it helped a lot. I made a new
version that is simpler and better, as well as more correct.
===
Name: STON-Core-SvenVanCaekenberghe.72
Author: SvenVanCaekenberghe
Time: 14 April 2016, 2:17:40.799554 pm
UUID: 80f809ee-2693-47c7-adf5-d56a9647d78c
Ancest
Not really about modifying during iteration, if an object you try to remove: is
in the wrong slot, you'll most likely get a CannotBeFound error.
Which you can work around by iterating indexes and nilling directly, doing so
in reverse merely minimizes the amount of work needed to potentially fill
The specified operation of fixing a badly hashed set will, if you go in reverse
;)
Removing (or, nilling, then checking for subsequent hits) only ever moves
objects at indexes following the one you removed at (and have already verified
to be correct)
Adding might result in the removed object bei
Yeah, I just realised that iterating and changing a dictionary or set at the
same time won't work ;-)
> On 06 Apr 2016, at 16:01, Henrik Johansen
> wrote:
>
> If you are iterating over a Set with incorrectly placed objects, remove:
> calls aren't going to do you much good ;)
> Not to mention,
If you are iterating over a Set with incorrectly placed objects, remove: calls
aren't going to do you much good ;)
Not to mention, even nilling the slot directly, then add:'ing, still means you
have to scan subsequent entries up to the next empty slot for potentially
better placement, if the obj
> On 06 Apr 2016, at 15:34, Nicolai Hess wrote:
>
>
>
> 2016-04-06 15:25 GMT+02:00 Sven Van Caekenberghe :
> Hi Nicolai,
>
> > On 06 Apr 2016, at 14:56, Nicolai Hess wrote:
> >
> >
> >
> > 2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe :
> > Fix for review:
> >
> > ===
> > Name: STON-Core-
2016-04-06 15:25 GMT+02:00 Sven Van Caekenberghe :
> Hi Nicolai,
>
> > On 06 Apr 2016, at 14:56, Nicolai Hess wrote:
> >
> >
> >
> > 2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe :
> > Fix for review:
> >
> > ===
> > Name: STON-Core-SvenVanCaekenberghe.71
> > Author: SvenVanCaekenberghe
> > Ti
Hi Nicolai,
> On 06 Apr 2016, at 14:56, Nicolai Hess wrote:
>
>
>
> 2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe :
> Fix for review:
>
> ===
> Name: STON-Core-SvenVanCaekenberghe.71
> Author: SvenVanCaekenberghe
> Time: 6 April 2016, 2:22:24.782251 pm
> UUID: 64b8b741-365e-41fe-aa98-565e3
g.
Sven
> Best regards,
> Henrik
>
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Sven
> Van Caekenberghe
> Sent: Wednesday, April 6, 2016 2:27 PM
> To: Pharo Development List
> Subject: Re: [Pharo-dev] [Ph
2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe :
> Fix for review:
>
> ===
> Name: STON-Core-SvenVanCaekenberghe.71
> Author: SvenVanCaekenberghe
> Time: 6 April 2016, 2:22:24.782251 pm
> UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24
> Ancestors: STON-Core-SvenVanCaekenberghe.70
>
> Fix a bug where
...@lists.pharo.org] On Behalf Of Sven
Van Caekenberghe
Sent: Wednesday, April 6, 2016 2:27 PM
To: Pharo Development List
Subject: Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a
dictionary if the keys are references
Fix for review:
===
Name: STON-Core-SvenVanCaekenberghe.71
Author
Fix for review:
===
Name: STON-Core-SvenVanCaekenberghe.71
Author: SvenVanCaekenberghe
Time: 6 April 2016, 2:22:24.782251 pm
UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24
Ancestors: STON-Core-SvenVanCaekenberghe.70
Fix a bug where STONReferences occurring as keys in Dictionaries or elements in
Sets
https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Dictionaries-and-Sets-when-references-occur-in-its-keys-or-elements
fix coming
> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe wrote:
>
>>
>> On 05 Apr 2016, at 13:02, Nicolai Hess wrote:
>>
>>
>>
>> 2016-04-05 12:32 GMT
> On 05 Apr 2016, at 13:02, Nicolai Hess wrote:
>
>
>
> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque
> :
>
>
> On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
>
> > Like I said, it is a hashing issue, sometimes it will be correct by
> > accident.
> >
> > I hope you did not have t
2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <
cyril.ferli...@gmail.com>:
>
>
> On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
>
> > Like I said, it is a hashing issue, sometimes it will be correct by
> accident.
> >
> > I hope you did not have to much trouble with this bug, I guess it m
On 05/04/2016 12:09, Sven Van Caekenberghe wrote:
> Like I said, it is a hashing issue, sometimes it will be correct by accident.
>
> I hope you did not have to much trouble with this bug, I guess it must have
> been hard to chase.
>
> Is it urgent ?
>
> I probably can give you a quick fix,
>
> Like I said, it is a hashing issue, sometimes it will be correct by
> accident.
>
> I hope you did not have to much trouble with this bug, I guess it must
> have been hard to chase.
>
The hardest thing often is to suspect the system or external libraries, but
it wasn't that bad.
Is it urgent
> On 05 Apr 2016, at 11:50, Peter Uhnák wrote:
>
> This is
> Pharo #50666
> Moose 6.0 build #1437
> STON-Core-SvenVanCaekenberghe.67
>
> (I also loaded STON-Core-SvenVanCaekenberghe.70 but the result is the same).
>
> One thing to note: it doesn't fail always… for me it seems that about every
This is
Pharo #50666
Moose 6.0 build #1437
STON-Core-SvenVanCaekenberghe.67
(I also loaded STON-Core-SvenVanCaekenberghe.70 but the result is the
same).
One thing to note: it doesn't fail always… for me it seems that about every
ten or so attempts it succeeds.
Peter
On Tue, Apr 5, 2016 at 11:4
Hi Peter,
Strange indeed. It did not fail for me in 5.0 with the standard STON version,
but it does fail in 4.0 with the latest STON. Asking the bogus dictionary to
#rehash seems to fix the problem. I will investigate and turn you example into
a unit test.
Sven
> On 05 Apr 2016, at 11:14, Pe
20 matches
Mail list logo
