|Anonymous | Login||08-09-2020 09:01 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0006839||[Squeak] Kernel||major||always||01-07-08 10:16||01-11-08 00:37|
|Summary||0006839: #comeFullyUpOnReload: not sent to MorphExtension's otherProperties (anIdentityDictionary)|
Situation: using a fresh playfield for creating UML morphs with connectors (using the Connector2 package), then:
o save the playfield to disk, quit without snapshot.
o load the .pr file, it will reload as Project.
o change the Project and save again to disk, again quit without snapshot.
o load the Project and explore the World
The NCUMLDiagramMorph's MorphExtension instance variable otherProperties, is not rehashed.
Quit without snapshot and before loading the Project again, put a break in Set>>#comeFullyUpOnReload: (which is responsible for the missing #rehash).
The method will not break for IdentityDictionaries (but it breaks for 2-3 other "normal" Dictionaries).
I've attached a .pr file which exhibits the above.
This report seems to describe a situation similiar to
- http://bugs.squeak.org/view.php?id=6721 [^]
|Attached Files||scanner-M6839.pr [^] (117,165 bytes) 01-07-08 10:19|
(0011645 - 205 - 235 - 437 - 437 - 437 - 437)
According to Edgar:
This problem occured in a prefix image and is due to the changes of == to = in project reading code.
(0011646 - 21 - 21 - 21 - 21 - 21 - 21)
|fix in 3.10.1 branch.|
(0011647 - 140 - 140 - 140 - 140 - 140 - 140)
|Please supply a test demonstrating that indeed #comeFullyUpOnReload: is sent to instances of IdentityDictionary before you close this issue.|
(0011675 - 736 - 808 - 808 - 921 - 921 - 921)
I agree your test is desirable. Though I think in this case the problem was that #comeFullyUpOnReload: was broken by the change.
I resolved this report because it is essentially a duplicate of 6721.
I included tests in 6721 to detect dictionaries whose keys had lost their values. That was sort of what crops up when #comeFullyUpOnReload: does not work correctly.
In any event, wouldn't it be less confusing if followup and additional tests are added to the other report and this is resolved again as the duplicate of that?
You are welcome to add additional tests to 0006721 if you think they will be needed. I just could not think of anything more clever than the dictionary integrity test.
|01-07-08 10:16||kwl||New Issue|
|01-07-08 10:19||kwl||File Added: scanner-M6839.pr|
|01-09-08 03:58||wiz||Relationship added||duplicate of 0006721|
|01-09-08 04:00||wiz||Note Added: 0011645|
|01-09-08 04:03||wiz||Status||new => resolved|
|01-09-08 04:03||wiz||Fixed in Version||=> 3.10|
|01-09-08 04:03||wiz||Resolution||open => duplicate|
|01-09-08 04:03||wiz||Assigned To||=> wiz|
|01-09-08 04:03||wiz||Note Added: 0011646|
|01-09-08 05:39||kwl||Status||resolved => feedback|
|01-09-08 05:39||kwl||Resolution||duplicate => reopened|
|01-09-08 05:39||kwl||Note Added: 0011647|
|01-11-08 00:37||wiz||Note Added: 0011675|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
57 total queries executed.|
39 unique queries executed.