Mantis - Squeak
Viewing Issue Advanced Details
3386 Etoys major always 03-29-06 05:05 04-25-06 14:44
feedback 3.9  
0003386: 3.9 can't load legacy etoys project
3.9 can't load etoys projects saved from <3.8 (i.e. squeakland),
though can load projects saved from 3.9.
squeakdebug.log is attached.
In #category: of "a subclass of Player" (being loaded) ,
"oldCategory" is not string but IdentityDictionary returned from #basicCategory, and that is passed to #class:recategorizedFrom:to:, then results the error.
related to 0003591closed dvf problems about loading legacy etoys project in 7032 
 SqueakDebug.log [^] (4,576 bytes) 03-29-06 05:05
 categoryFixForEtoys.cs [^] (698 bytes) 04-03-06 21:37
 SqueakDebug2.log [^] (4,468 bytes) 04-25-06 11:16

04-03-06 21:36   
Apparently, the behaviors that come into the image have in their ivar #category an object other than nil. This ivar is now used to cache the category of a class or trait, hence causing some trouble with the unexpected value.
A trivial fix is to simply check whether we have a symbol or not. The attached cs does this change. However, its a hack and the values stored in the ivar just get lost. Can somebody with etoys knowlede check why they are there whether they are still in use? Because if this was the case, we would have a problem...
04-04-06 09:34   
for 7022
04-14-06 13:33   
Even with categoryFixForEToys.cs (was not integrated to 7022), loading legacy project causes (other) error (sometimes emergency evaluator shows up):
ByteSymbol(Object)>>doesNotUnderstand: #setSubject: .
that is called from "a subclass of Player class(ClassDescription)>>organization"
04-25-06 11:27   
Reminder sent to: al, MarcusDenker

I uploaded squeakdebug2.log, that is results of loading a legacy project by 7024-with-categoryFixForEtoys.cs.
(note that the cs hasn't been integareted yet, even in 7024)
04-25-06 14:44   
I looked at the SqueakDebug2.log and this seems to be a different issue. The problem is that we have new instvars in Behavior, hence "organization" has shifted by 2. The EToys project loading does not seem to take format changes of classes into account.
Since the ivar shift is an issue for the VM as well, we are going to change this in the near future. This will probably go into one of the next releases. So I suggest to test this again later.

Once again, I really suggest that the responsible person of EToys for 3.9 (who is this?) has a look as I don't know EToys at _all_. The previous submitted fix categoryFixForEtoys.cs should only go into 3.9 if he thinks that is an appropriate solution!