Re: 0006721: Identity dictionarys sometimes can't find their keys

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Jerome Peace
Hi all,

I could use some help getting some crucial tests into trunk.

The patches are in the mantis report of the title.
http://bugs.squeak.org/view.php?id=6721

The ill hashed dictionaries have been detected in Fun Squeak.

I am worried that there is something in the main image that causes conditions to occur so that dictionaries are not rehashed when needed.

The problem is that a mis-hashed dictionary will show up only as other symptoms. Code that seemingly doesn't work as expected. Without a ready test to run tracking it back to the true problem is difficult.

I have no MC skills so I am asking for someone to take over harvesting from the report.

Thank you in advance.

Yours in curiosity and service, --Jerome Peace





     

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Levente Uzonyi-2
On Sat, 27 Feb 2010, Jerome Peace wrote:

> Hi all,
>
> I could use some help getting some crucial tests into trunk.
>
> The patches are in the mantis report of the title.
> http://bugs.squeak.org/view.php?id=6721
>

nil is a valid key in Dictionary and IdentityKeyDictionary. A better test
would be something like this:

{ Dictionary. IdentityDictionary } do: [ :dictionaryClass |
  dictionaryClass allInstancesDo: [ :dictionary |
  dictionary keysAndValuesDo: [ :key :value |
  self assert: (dictionary at: key) == value ] ] ].

Or, if you want to use lower level (private) methods:

{ Dictionary. IdentityDictionary } do: [ :dictionaryClass |
  dictionaryClass allInstancesDo: [ :dictionary |
  dictionary array doWithIndex: [ :association :index |
  association ifNotNil: [
  self assert: (dictionary scanFor: association key) = index ] ] ] ]

> The ill hashed dictionaries have been detected in Fun Squeak.
>

The tests above can be used to track down dictionaries which have an
invalid state.


Levente

> I am worried that there is something in the main image that causes conditions to occur so that dictionaries are not rehashed when needed.
>
> The problem is that a mis-hashed dictionary will show up only as other symptoms. Code that seemingly doesn't work as expected. Without a ready test to run tracking it back to the true problem is difficult.
>
> I have no MC skills so I am asking for someone to take over harvesting from the report.
>
> Thank you in advance.
>
> Yours in curiosity and service, --Jerome Peace
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Jerome Peace
In reply to this post by Jerome Peace

Hi Levente,

Thank you for your suggestions.

I am not aiming myself at revising my tests. If you wish to add to them great. I suggest adding specific suggestions and code to the mantis report.

For some dictionaries "nil" has become a valid key. The tests in the report were designed for 3.9 - 3.10 where Dan Ingalls innocent suggestion that #= replace #==  caused a coder to break #comeFullyUpOnReload. I had to design a test that proved dictionaries we not getting hashed correctly just to prove somebody had caused a problem.

The difficulty with dictionary problems is they appear like a will-of-the-wisp causing very hard to track down mischief. Trust me on this.

The problem may be recurring so its important to have tests IN THE IMAGE. That can be run to find them. For Identity dictionaries these test have proven to work if used. I haven't experimented with the new dictionary flavors or even with other dictionaries, just the one class.

The thing I am asking for help with is getting the test from change sets on a mantis report to live code in an image. I don't have any skill with MC. I am a Luddite with regards to it and have not taken the first steps to mastery. This suits me as a debugger. I can find, analyse, and patch bugs with the old methods. It leaves a gap in getting code committed. So I either need a book on MC for Luddites or someone to help by committing the code to resolve the issue. That's what I asked for.

Once the tests are where they can be used, improvements will be welcome. The existing tests are good enough to start with. Without something the image is likely to have bugs way to hard to chase.

More help in devising and PROVING tests that will find other problems is welcome. It was not the aim of my post however.

Cheers --Jer

>Levente Uzonyi leves at elte.hu
>Sun Feb 28 13:19:40 UTC 2010 replied to:

>On Sat, 27 Feb 2010, Jerome Peace wrote:
>
>> Hi all,
>>
>> I could use some help getting some crucial tests into trunk.
>>
>> The patches are in the mantis report of the title.
>> http://bugs.squeak.org/view.php?id=6721
>>
>
>nil is a valid key in Dictionary and IdentityKeyDictionary. A better test
>would be something like this:
>
>{ Dictionary. IdentityDictionary } do: [ :dictionaryClass |
> dictionaryClass allInstancesDo: [ :dictionary |
> dictionary keysAndValuesDo: [ :key :value |
> self assert: (dictionary at: key) == value ] ] ].
>
>Or, if you want to use lower level (private) methods:
>
>{ Dictionary. IdentityDictionary } do: [ :dictionaryClass |
> dictionaryClass allInstancesDo: [ :dictionary |
> dictionary array doWithIndex: [ :association :index |
> association ifNotNil: [
> self assert: (dictionary scanFor: association key) = index ] ] ] ]
>
>> The ill hashed dictionaries have been detected in Fun Squeak.
>>
>
>The tests above can be used to track down dictionaries which have an
>invalid state.
>
>
>Levente
>
>> I am worried that there is something in the main image that causes conditions to occur so that dictionaries are not rehashed when needed.
>>
>> The problem is that a mis-hashed dictionary will show up only as other symptoms. Code that seemingly doesn't work as expected. Without a ready test to run tracking it back to the true problem is difficult.
>>
>> I have no MC skills so I am asking for someone to take over harvesting from the report.
>>
>> Thank you in advance.
>>
>> Yours in curiosity and service, --Jerome Peace
>


     

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Levente Uzonyi-2
On Sun, 28 Feb 2010, Jerome Peace wrote:

>
> Hi Levente,
>
> Thank you for your suggestions.
>
> I am not aiming myself at revising my tests. If you wish to add to them great. I suggest adding specific suggestions and code to the mantis report.
>
> For some dictionaries "nil" has become a valid key. The tests in the report were designed for 3.9 - 3.10 where Dan Ingalls innocent suggestion that #= replace #==  caused a coder to break #comeFullyUpOnReload. I had to design a test that proved dictionaries we not getting hashed correctly just to prove somebody had caused a problem.

nil was always a valid key for Dictionary and IdentityDictionary. Sets
were the collections which couldn't contain nil.


Levente

>
> The difficulty with dictionary problems is they appear like a will-of-the-wisp causing very hard to track down mischief. Trust me on this.
>
> The problem may be recurring so its important to have tests IN THE IMAGE. That can be run to find them. For Identity dictionaries these test have proven to work if used. I haven't experimented with the new dictionary flavors or even with other dictionaries, just the one class.
>
> The thing I am asking for help with is getting the test from change sets on a mantis report to live code in an image. I don't have any skill with MC. I am a Luddite with regards to it and have not taken the first steps to mastery. This suits me as a debugger. I can find, analyse, and patch bugs with the old methods. It leaves a gap in getting code committed. So I either need a book on MC for Luddites or someone to help by committing the code to resolve the issue. That's what I asked for.
>
> Once the tests are where they can be used, improvements will be welcome. The existing tests are good enough to start with. Without something the image is likely to have bugs way to hard to chase.
>
> More help in devising and PROVING tests that will find other problems is welcome. It was not the aim of my post however.
>
> Cheers --Jer
>
>> Levente Uzonyi leves at elte.hu
>> Sun Feb 28 13:19:40 UTC 2010 replied to:
>
>> On Sat, 27 Feb 2010, Jerome Peace wrote:
>>
>>> Hi all,
>>>
>>> I could use some help getting some crucial tests into trunk.
>>>
>>> The patches are in the mantis report of the title.
>>> http://bugs.squeak.org/view.php?id=6721
>>>
>>
>> nil is a valid key in Dictionary and IdentityKeyDictionary. A better test
>> would be something like this:
>>
>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>> dictionaryClass allInstancesDo: [ :dictionary |
>> dictionary keysAndValuesDo: [ :key :value |
>> self assert: (dictionary at: key) == value ] ] ].
>>
>> Or, if you want to use lower level (private) methods:
>>
>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>> dictionaryClass allInstancesDo: [ :dictionary |
>> dictionary array doWithIndex: [ :association :index |
>> association ifNotNil: [
>> self assert: (dictionary scanFor: association key) = index ] ] ] ]
>>
>>> The ill hashed dictionaries have been detected in Fun Squeak.
>>>
>>
>> The tests above can be used to track down dictionaries which have an
>> invalid state.
>>
>>
>> Levente
>>
>>> I am worried that there is something in the main image that causes conditions to occur so that dictionaries are not rehashed when needed.
>>>
>>> The problem is that a mis-hashed dictionary will show up only as other symptoms. Code that seemingly doesn't work as expected. Without a ready test to run tracking it back to the true problem is difficult.
>>>
>>> I have no MC skills so I am asking for someone to take over harvesting from the report.
>>>
>>> Thank you in advance.
>>>
>>> Yours in curiosity and service, --Jerome Peace
>>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Igor Stasenko
On 28 February 2010 19:56, Levente Uzonyi <[hidden email]> wrote:

> On Sun, 28 Feb 2010, Jerome Peace wrote:
>
>>
>> Hi Levente,
>>
>> Thank you for your suggestions.
>>
>> I am not aiming myself at revising my tests. If you wish to add to them
>> great. I suggest adding specific suggestions and code to the mantis report.
>>
>> For some dictionaries "nil" has become a valid key. The tests in the
>> report were designed for 3.9 - 3.10 where Dan Ingalls innocent suggestion
>> that #= replace #==  caused a coder to break #comeFullyUpOnReload. I had to
>> design a test that proved dictionaries we not getting hashed correctly just
>> to prove somebody had caused a problem.
>
> nil was always a valid key for Dictionary and IdentityDictionary. Sets were
> the collections which couldn't contain nil.
>
except WeakKeyDictionary, for obvious reason.

>
> Levente
>
>>
>> The difficulty with dictionary problems is they appear like a
>> will-of-the-wisp causing very hard to track down mischief. Trust me on this.
>>
>> The problem may be recurring so its important to have tests IN THE IMAGE.
>> That can be run to find them. For Identity dictionaries these test have
>> proven to work if used. I haven't experimented with the new dictionary
>> flavors or even with other dictionaries, just the one class.
>>
>> The thing I am asking for help with is getting the test from change sets
>> on a mantis report to live code in an image. I don't have any skill with MC.
>> I am a Luddite with regards to it and have not taken the first steps to
>> mastery. This suits me as a debugger. I can find, analyse, and patch bugs
>> with the old methods. It leaves a gap in getting code committed. So I either
>> need a book on MC for Luddites or someone to help by committing the code to
>> resolve the issue. That's what I asked for.
>>
>> Once the tests are where they can be used, improvements will be welcome.
>> The existing tests are good enough to start with. Without something the
>> image is likely to have bugs way to hard to chase.
>>
>> More help in devising and PROVING tests that will find other problems is
>> welcome. It was not the aim of my post however.
>>
>> Cheers --Jer
>>
>>> Levente Uzonyi leves at elte.hu
>>> Sun Feb 28 13:19:40 UTC 2010 replied to:
>>
>>> On Sat, 27 Feb 2010, Jerome Peace wrote:
>>>
>>>> Hi all,
>>>>
>>>> I could use some help getting some crucial tests into trunk.
>>>>
>>>> The patches are in the mantis report of the title.
>>>> http://bugs.squeak.org/view.php?id=6721
>>>>
>>>
>>> nil is a valid key in Dictionary and IdentityKeyDictionary. A better test
>>> would be something like this:
>>>
>>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>>>        dictionaryClass allInstancesDo: [ :dictionary |
>>>                dictionary keysAndValuesDo: [ :key :value |
>>>                        self assert: (dictionary at: key) == value ] ] ].
>>>
>>> Or, if you want to use lower level (private) methods:
>>>
>>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>>>        dictionaryClass allInstancesDo: [ :dictionary |
>>>                dictionary array doWithIndex: [ :association :index |
>>>                        association ifNotNil: [
>>>                                self assert: (dictionary scanFor:
>>> association key) = index ] ] ] ]
>>>
>>>> The ill hashed dictionaries have been detected in Fun Squeak.
>>>>
>>>
>>> The tests above can be used to track down dictionaries which have an
>>> invalid state.
>>>
>>>
>>> Levente
>>>
>>>> I am worried that there is something in the main image that causes
>>>> conditions to occur so that dictionaries are not rehashed when needed.
>>>>
>>>> The problem is that a mis-hashed dictionary will show up only as other
>>>> symptoms. Code that seemingly doesn't work as expected. Without a ready test
>>>> to run tracking it back to the true problem is difficult.
>>>>
>>>> I have no MC skills so I am asking for someone to take over harvesting
>>>> from the report.
>>>>
>>>> Thank you in advance.
>>>>
>>>> Yours in curiosity and service, --Jerome Peace
>>>
>>
>>
>>
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Levente Uzonyi-2
On Sun, 28 Feb 2010, Igor Stasenko wrote:

> On 28 February 2010 19:56, Levente Uzonyi <[hidden email]> wrote:
>> On Sun, 28 Feb 2010, Jerome Peace wrote:
>>
>>>
>>> Hi Levente,
>>>
>>> Thank you for your suggestions.
>>>
>>> I am not aiming myself at revising my tests. If you wish to add to them
>>> great. I suggest adding specific suggestions and code to the mantis report.
>>>
>>> For some dictionaries "nil" has become a valid key. The tests in the
>>> report were designed for 3.9 - 3.10 where Dan Ingalls innocent suggestion
>>> that #= replace #==  caused a coder to break #comeFullyUpOnReload. I had to
>>> design a test that proved dictionaries we not getting hashed correctly just
>>> to prove somebody had caused a problem.
>>
>> nil was always a valid key for Dictionary and IdentityDictionary. Sets were
>> the collections which couldn't contain nil.
>>
> except WeakKeyDictionary, for obvious reason.
There are other exceptions, like MethodDictionary. I meant the classes
here and not the hierarchy they represent.


Levente

>
>>
>> Levente
>>
>>>
>>> The difficulty with dictionary problems is they appear like a
>>> will-of-the-wisp causing very hard to track down mischief. Trust me on this.
>>>
>>> The problem may be recurring so its important to have tests IN THE IMAGE.
>>> That can be run to find them. For Identity dictionaries these test have
>>> proven to work if used. I haven't experimented with the new dictionary
>>> flavors or even with other dictionaries, just the one class.
>>>
>>> The thing I am asking for help with is getting the test from change sets
>>> on a mantis report to live code in an image. I don't have any skill with MC.
>>> I am a Luddite with regards to it and have not taken the first steps to
>>> mastery. This suits me as a debugger. I can find, analyse, and patch bugs
>>> with the old methods. It leaves a gap in getting code committed. So I either
>>> need a book on MC for Luddites or someone to help by committing the code to
>>> resolve the issue. That's what I asked for.
>>>
>>> Once the tests are where they can be used, improvements will be welcome.
>>> The existing tests are good enough to start with. Without something the
>>> image is likely to have bugs way to hard to chase.
>>>
>>> More help in devising and PROVING tests that will find other problems is
>>> welcome. It was not the aim of my post however.
>>>
>>> Cheers --Jer
>>>
>>>> Levente Uzonyi leves at elte.hu
>>>> Sun Feb 28 13:19:40 UTC 2010 replied to:
>>>
>>>> On Sat, 27 Feb 2010, Jerome Peace wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I could use some help getting some crucial tests into trunk.
>>>>>
>>>>> The patches are in the mantis report of the title.
>>>>> http://bugs.squeak.org/view.php?id=6721
>>>>>
>>>>
>>>> nil is a valid key in Dictionary and IdentityKeyDictionary. A better test
>>>> would be something like this:
>>>>
>>>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>>>>        dictionaryClass allInstancesDo: [ :dictionary |
>>>>                dictionary keysAndValuesDo: [ :key :value |
>>>>                        self assert: (dictionary at: key) == value ] ] ].
>>>>
>>>> Or, if you want to use lower level (private) methods:
>>>>
>>>> { Dictionary. IdentityDictionary } do: [ :dictionaryClass |
>>>>        dictionaryClass allInstancesDo: [ :dictionary |
>>>>                dictionary array doWithIndex: [ :association :index |
>>>>                        association ifNotNil: [
>>>>                                self assert: (dictionary scanFor:
>>>> association key) = index ] ] ] ]
>>>>
>>>>> The ill hashed dictionaries have been detected in Fun Squeak.
>>>>>
>>>>
>>>> The tests above can be used to track down dictionaries which have an
>>>> invalid state.
>>>>
>>>>
>>>> Levente
>>>>
>>>>> I am worried that there is something in the main image that causes
>>>>> conditions to occur so that dictionaries are not rehashed when needed.
>>>>>
>>>>> The problem is that a mis-hashed dictionary will show up only as other
>>>>> symptoms. Code that seemingly doesn't work as expected. Without a ready test
>>>>> to run tracking it back to the true problem is difficult.
>>>>>
>>>>> I have no MC skills so I am asking for someone to take over harvesting
>>>>> from the report.
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Yours in curiosity and service, --Jerome Peace
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Jerome Peace
In reply to this post by Igor Stasenko

Levente Uzonyi leves at elte.hu
Sun Feb 28 17:56:00 UTC 2010 replied:


>nil was always a valid key for Dictionary and IdentityDictionary. Sets
>were the collections which couldn't contain nil.


>Levente

Ha. I knew there was a good reason for having someone look over your shoulder as you program. I stand corrected.

Never the less, the tests were useful in finding bugs.

Even if 'nil' can be a legitimate key its presence is often the sign of a bug. The only instance my test found pointed to the initialization of GeeMailMorph being misplaced to UndefinedObject class. So even though I stumbled on to it with a mis-assumption the test found it. I think it's valuable to go looking, then note the legitimate exceptions in the test.

I would love to see my tests in the image and your test improvements as well. I am still looking for a MC savvy code partner to take over some of the driving.

Cheers --Jer

"Debugger's don't need exact knowledge as long at they have interesting tests and a willingness to learn."  --Fearless Bugtrackers secret codex




     

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Levente Uzonyi-2
On Sun, 28 Feb 2010, Jerome Peace wrote:

>
> Levente Uzonyi leves at elte.hu
> Sun Feb 28 17:56:00 UTC 2010 replied:
>
>
>> nil was always a valid key for Dictionary and IdentityDictionary. Sets
>> were the collections which couldn't contain nil.
>
>
>> Levente
>
> Ha. I knew there was a good reason for having someone look over your shoulder as you program. I stand corrected.
>
> Never the less, the tests were useful in finding bugs.
>
> Even if 'nil' can be a legitimate key its presence is often the sign of a bug. The only instance my test found pointed to the initialization of GeeMailMorph being misplaced to UndefinedObject class. So even though I stumbled on to it with a mis-assumption the test found it. I think it's valuable to go looking, then note the legitimate exceptions in the test.
>
> I would love to see my tests in the image and your test improvements as well. I am still looking for a MC savvy code partner to take over some of the driving.

I added the general purpose integrity tests to the Trunk. Details here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/145266.html
I think a test which fails when an object has a valid (and supported)
state is simply wrong.

Here are a few links which cover MC:
http://wiki.squeak.org/squeak/43
http://www.wiresong.ca/Monticello/UserManual/
http://wiki.squeak.org/squeak/1287
http://www.youtube.com/watch?v=eCwzcOk6vY4
http://vimeo.com/groups/squeak/videos/7783848
etc. (probably SBE/PBE has a chapter about MC too)


Levente

>
> Cheers --Jer
>
> "Debugger's don't need exact knowledge as long at they have interesting tests and a willingness to learn."  --Fearless Bugtrackers secret codex
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 0006721: Identity dictionarys sometimes can't find their keys

Jerome Peace
In reply to this post by Igor Stasenko
Hi Levente,

Thanks.

>Levente Uzonyi leves at elte.hu
>Tue Mar 2 02:21:38 UTC 2010 wrote:
>
>On Sun, 28 Feb 2010, Jerome Peace wrote:
>
>>
>> Levente Uzonyi leves at elte.hu
>> Sun Feb 28 17:56:00 UTC 2010 replied:
>>
>>
>>> nil was always a valid key for Dictionary and IdentityDictionary. Sets
>>> were the collections which couldn't contain nil.
>>
>>
>>> Levente
>>
>> Ha. I knew there was a good reason for having someone look over your shoulder as you program. I stand corrected.
>>
>> Never the less, the tests were useful in finding bugs.
>>
>> Even if 'nil' can be a legitimate key its presence is often the sign of a bug. The only instance my test found pointed to the initialization of GeeMailMorph being misplaced to UndefinedObject class. So even though I stumbled on to it with a mis-assumption the test found it. I think it's valuable to go looking, then note the legitimate exceptions in the test.
>>
>> I would love to see my tests in the image and your test improvements as well. I am still looking for a MC savvy code partner to take over some of the driving.
>
>I added the general purpose integrity tests to the Trunk. Details here:
>http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/145266.html
>I think a test which fails when an object has a valid (and supported)
>state is simply wrong.

Cool. Thanks for the help.

On reflection, I agree that as an image acceptance test, the 'nil' key test doesn't hack it. On the other hand it does makes an excellent probe. Still not having it in the test suite is correct.

I am stuck working as a one man team. So I very much appreciate your supplying a second opinion. Its damn hard to double guess oneself.

The other important result is there is a test IN THE IMAGE for this critical bug which is known to happen. Good work.

>
>Here are a few links which cover MC:
>http://wiki.squeak.org/squeak/43
>http://www.wiresong.ca/Monticello/UserManual/
>http://wiki.squeak.org/squeak/1287
>http://www.youtube.com/watch?v=eCwzcOk6vY4
>http://vimeo.com/groups/squeak/videos/7783848
>etc. (probably SBE/PBE has a chapter about MC too)
>
Thank you again. I would like to master MC. At the very least it would allow me to be a more knowledgeable Luddite. Besides at the moment there seems to be no help for it. Even Etoys is committing to it. Sigh.

Thanks for the help. I appreciate the partnering.

Yours in curiosity and service, --Jerome Peace

"In theory, there is no difference between theory and practice. But, in practice, there is." --Yogi
>