I'm modifying Monticello to store Namespaced packages to a .mcz file.
However, I've come across a problem I've never seen before: MessageNotUnderstood: AnObsoleteMCNamespacedStWriter>>visitNamespaceDefinition: Where did that "AnObsolete" part come from, and why isn't my class (MCNamespacedStWriter) being used now that I've fixed the DNU? Is this something peculiar to Squeak, or is Monticello doing some wacky reflection on its own classes? Michael. |
> Where did that "AnObsolete" part come from, and why isn't my class
> (MCNamespacedStWriter) being used now that I've fixed the DNU? Is this > something peculiar to Squeak, or is Monticello doing some wacky > reflection on its own classes? A class X is renamed to AnObsoleteX when #obsolete is sent to that class. This happens when removeFromSystem:, removeFromSystem, or removeFromSystemUnlogged is invoked. I don't know what caused your problem, but here are a couple of cases where Monticello-Code removes classes: - MCClassDefinition>>unload - MczInstaller>>unloadMonticello When that happens, the obsolete class is removed from Smalltalk and added to ObsoleteSubclasses. All instances of the class now are instances of the obsolete class, and a new class defined with the same name has no relationship to the obsolete class. So if you have instances of the obsolete class around, sending messages will invoke the implementations in the obsolete class, not the current one. Again, why MCNamespacedStWriter was removed in the first place, I don't know. HTH, Martin |
In reply to this post by Michael van der Gulik
I think you have to find which method(s) call
#visitNamespaceDefinition: and recompile them. 2007/4/28, Michael van der Gulik <[hidden email]>: > I'm modifying Monticello to store Namespaced packages to a .mcz file. > However, I've come across a problem I've never seen before: > > MessageNotUnderstood: > AnObsoleteMCNamespacedStWriter>>visitNamespaceDefinition: > > Where did that "AnObsolete" part come from, and why isn't my class > (MCNamespacedStWriter) being used now that I've fixed the DNU? Is this > something peculiar to Squeak, or is Monticello doing some wacky > reflection on its own classes? > > Michael. > > > -- Damien Cassou |
In reply to this post by Michael van der Gulik
pay attention there was a change in 3.9 (marcus is proposing some
fixes). that changes the hash of classes so you get more frequently obsolete. Have a look on mantis I think that marcus published it. Stef On 28 avr. 07, at 07:24, Michael van der Gulik wrote: > I'm modifying Monticello to store Namespaced packages to a .mcz > file. However, I've come across a problem I've never seen before: > > MessageNotUnderstood: > AnObsoleteMCNamespacedStWriter>>visitNamespaceDefinition: > > Where did that "AnObsolete" part come from, and why isn't my class > (MCNamespacedStWriter) being used now that I've fixed the DNU? Is > this something peculiar to Squeak, or is Monticello doing some > wacky reflection on its own classes? > > Michael. > > > |
In reply to this post by "Martin v. Löwis"
Thanks Martin, Damien.
Martin v. Löwis wrote: >>Where did that "AnObsolete" part come from, and why isn't my class >>(MCNamespacedStWriter) being used now that I've fixed the DNU? Is this >>something peculiar to Squeak, or is Monticello doing some wacky >>reflection on its own classes? > > > A class X is renamed to AnObsoleteX when #obsolete is sent to that > class. This happens when removeFromSystem:, removeFromSystem, or > removeFromSystemUnlogged is invoked. I've discovered what happened; it was really quite simple. I implemented a method: MCNamespacedMczWriter>>snapshotWriterClass ^ MCNamespacedStWriter. Then I deleted MCNamespacedStWriter for some reason; then I decided that it was worth keeping after all and added it again. Obviously what happened was that MCNamespacedStWriter was obsoleted making the literal association in the compiled method refer to the obsoleted class. When you remove a class, is there an easy way to find all "references" to that class in a similar way to how all senders of a method can be found? If so, then I consider the above to be a bug; the browser should have alerted me to the fact that there were references to that class from some methods. Michael. |
On Apr 29, 2007, at 4:24 , Michael van der Gulik wrote: > I've discovered what happened; it was really quite simple. > > I implemented a method: > > MCNamespacedMczWriter>>snapshotWriterClass > ^ MCNamespacedStWriter. > > Then I deleted MCNamespacedStWriter for some reason; then I decided > that it was worth keeping after all and added it again. Obviously > what happened was that MCNamespacedStWriter was obsoleted making > the literal association in the compiled method refer to the > obsoleted class. > > When you remove a class, is there an easy way to find all > "references" to that class in a similar way to how all senders of a > method can be found? If so, then I consider the above to be a bug; > the browser should have alerted me to the fact that there were > references to that class from some methods. SomeClass allCallsOn - Bert - |
Free forum by Nabble | Edit this page |