[Pharo-project] Collect all references to AnObsoleteFoo
Hi, I'm getting crazy about obsolete behaviors and any help here is really appreciated. In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel). Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class. Now my question is, apart from executing this small piece of code... SmalltalkImage current fixObsoleteReferences. SystemNavigation new obsoleteBehaviors size > 0 ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.] â¦in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references? For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated. More important, I also don't know how to eliminate them. Thanks in advance, Roberto
I've had the same problem just recently but am stuck in a bit of work right now. I hope to elaborate at length tomorrow. Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them. To fix obsolete classes you need to remove all references to it, be it in a dictionary or in a compiled method where you used the class name. Can you post the list of classes that are obsolete? Cheers, Max On 01.04.2013, at 16:51, roberto.minelli@usi.ch wrote:
Hi,
I'm getting crazy about obsolete behaviors and any help here is really appreciated.
In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
Now my question is, apart from executing this small piece of code...
SmalltalkImage current fixObsoleteReferences. SystemNavigation new obsoleteBehaviors size > 0 ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
â¦in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated. More important, I also don't know how to eliminate them.
Thanks in advance, Roberto
On Apr 1, 2013, at 9:58 PM, Max Leske <maxleske@gmail.com> wrote:
Quick fix: if you *need* to serialize those classes, simply change the code so that fuel serializes them.
I already tried. But then I had problems in materialization so I aborted the trial ;)
Can you post the list of classes that are obsolete?
Obsolete classes I encountered were all "obsolete versions" of classes I defined :)
Cheers, Max
On 01.04.2013, at 16:51, roberto.minelli@usi.ch wrote:
Hi,
I'm getting crazy about obsolete behaviors and any help here is really appreciated.
In a nutshell, I have a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel).
Fuel returns an error in FLGlobalClassCluster>>#serializeGlobalClass:on: complaining that I'm trying to serialize an obsolete class.
Now my question is, apart from executing this small piece of code...
SmalltalkImage current fixObsoleteReferences. SystemNavigation new obsoleteBehaviors size > 0 ifTrue: [ SystemNavigation new obsoleteBehaviors inspect.]
â¦in which I discovered to have many obsolete references, how can I "browse" and eventually kill such references?
For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated. More important, I also don't know how to eliminate them.
Thanks in advance, Roberto
On 01/04/13 10:51 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.org wrote:
For me the entire "behavior" of obsolete classes is obscure and I don't know how those classes are originated.
They arise when you delete a class, but you still have references to the class in the image. You could have instances of the deleted class, references to the class in a method, or even subclasses that refer the the deleted class.
More important, I also don't know how to eliminate them.
Make sure there are no dangling references, before you delete the class. Another possibility depends on whether the "obsolete" class has a non-obsolete equivalent if the image where you're de-materializing the Fuel file. If there is no equivalent class, but you still want to materialize the Fuel file there, you can set up a mapping to map the object to some other class (e.g. ClassThatWasDeleted class or even just used Object class). The object will be materialized, but probably most of it's instance variable values will be thrown away. This may or may not be the behaviour you want though.
Thanks for your answer! On Apr 2, 2013, at 12:03 AM, Yanni Chiu <yanni@rogers.com> wrote:
They arise when you delete a class, but you still have references to the class in the image. You could have instances of the deleted class, references to the class in a method, or even subclasses that refer the the deleted class.
Is there any way to "browse" through such references to understand where are they?
On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.org wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it. It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me. Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object. Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code: http://ws.stfx.eu/HYWM1ZB9R45K (the first time I use the shared workspace :-) if you file in the attached file, it materializes the new A class. But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time HTH Martin On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@**public.gmane.org<roberto.minelli-BHDiRLqP7qo@public.gmane.org>wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here: http://ws.stfx.eu/OAVG8IXKWOYA Don't need to filein the workaround of my previous email. Martin On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote:
Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@**public.gmane.org<roberto.minelli-BHDiRLqP7qo@public.gmane.org>wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
Martin, your solution is awesome. I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction. Thanks a lot, R On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias@gmail.com> wrote:
As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here:
http://ws.stfx.eu/OAVG8IXKWOYA
Don't need to filein the workaround of my previous email.
Martin
On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote: Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote: On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.org wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)? If not, could be write your awesome code in the Fuel website? Thanks!!! :) On Sat, Apr 6, 2013 at 8:26 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Martin, your solution is awesome.
I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.
Thanks a lot, R
On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias@gmail.com> wrote:
As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here:
http://ws.stfx.eu/OAVG8IXKWOYA
Don't need to filein the workaround of my previous email.
Martin
On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote: Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote: On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.orgwrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
-- Mariano http://marianopeck.wordpress.com
I'd say that handling obsolete reference this way is very good! I'd put this behavior in Fuel! Cheers, R On Apr 6, 2013, at 2:27 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)? If not, could be write your awesome code in the Fuel website?
Thanks!!! :)
On Sat, Apr 6, 2013 at 8:26 AM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Martin, your solution is awesome.
I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.
Thanks a lot, R
On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias@gmail.com> wrote:
As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here:
http://ws.stfx.eu/OAVG8IXKWOYA
Don't need to filein the workaround of my previous email.
Martin
On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote: Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote: On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.org wrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
-- Mariano http://marianopeck.wordpress.com
pffff thank you. The word 'awesome' is too much, but well, I can put the snippet somewhere in the doc. I don't know if this should be the default behaviour in Fuel, since it will add the dependency to Ring. Also we can discuss about removing the "defensive" error during serialization: as you could see, technically there is no problem to serialize the obsolete class. We decided to raise an error just because as users we found that almost always when you are serializing the obsolete, it was due to some mistake, and you discover that the obsolete was in the .fuel file later when you materialize. Alternatively, we could just raise a "class not found" error during materialization. cheers, Martin ps: I'd like to see the video of Max's presentation in PharoConf! On Sun, Apr 7, 2013 at 2:47 PM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
I'd say that handling obsolete reference this way is very good! I'd put this behavior in Fuel!
Cheers, R
On Apr 6, 2013, at 2:27 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)? If not, could be write your awesome code in the Fuel website?
Thanks!!! :)
On Sat, Apr 6, 2013 at 8:26 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote: Martin, your solution is awesome.
I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction.
Thanks a lot, R
On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias@gmail.com> wrote:
As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here:
http://ws.stfx.eu/OAVG8IXKWOYA
Don't need to filein the workaround of my previous email.
Martin
On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias@gmail.com> wrote: Hi, I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code:
http://ws.stfx.eu/HYWM1ZB9R45K
(the first time I use the shared workspace :-)
if you file in the attached file, it materializes the new A class.
But this will be not useful for you, if either: - you don't have the "original class" at materialization time - you don't want to know if the class was obsolete at serialization time
HTH Martin
On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni@rogers.com> wrote: On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo@public.gmane.orgwrote:
Is there any way to "browse" through such references to understand where are they?
From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it.
It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me.
Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object.
Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure.
-- Mariano http://marianopeck.wordpress.com
participants (5)
-
Mariano Martinez Peck -
Martin Dias -
Max Leske -
roberto.minelli＠usi.ch -
Yanni Chiu