[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
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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.mine...@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 > >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
Ciao Roberto, Whenever you remove a class that is still referenced in the system, an ObsoleteClass takes the place of the removed class. In the late-bound spirit of Smalltalk, the system allows removing the classes and dealing with the current references later. If i may question the source of your problem: "a Dictionary (containing receivers of method calls, i.e., classes) that I need to serialize in a file (i.e., using Fuel)", are you sure you need to serialize the actual classes? or just the names? or even a description of the class within Ring? Think about what you are modeling with a Dictionary that holds , and maybe try to reify that concept. Fernando On Mon, Apr 1, 2013 at 9:58 PM, Max Leske wrote: > 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.mine...@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 >> >> > >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
On 01/04/13 10:51 AM, roberto.minelli-bhdirlqp...@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.
Re: [Pharo-project] Collect all references to AnObsoleteFoo
On Apr 1, 2013, at 9:58 PM, Max Leske 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.mine...@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 >> >> > >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
Thanks Fernando, On Apr 1, 2013, at 11:51 PM, Fernando Olivero wrote: > Ciao Roberto, > > Whenever you remove a class that is still referenced in the system, an > ObsoleteClass takes the place of the removed class. In the late-bound > spirit of Smalltalk, the system allows removing the classes and > dealing with the current references later. I see. I'm not sure I agree with this philosophy, but I see the point. > If i may question the source of your problem: "a Dictionary > (containing receivers of method calls, i.e., classes) that I need to > serialize in a file (i.e., using Fuel)", are you sure you need to > serialize the actual classes? or just the names? or even a description > of the class within Ring? Think about what you are modeling with a > Dictionary that holds , and maybe try to > reify that concept. I totally agree with you Fernando. That was just a quick and dirty prototype ;) > Fernando > > > > > On Mon, Apr 1, 2013 at 9:58 PM, Max Leske wrote: >> 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.mine...@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 >>> >>> >> >> >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
Thanks for your answer! On Apr 2, 2013, at 12:03 AM, Yanni Chiu 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?
Re: [Pharo-project] Collect all references to AnObsoleteFoo
On 02/04/13 12:50 AM, roberto.minelli-bhdirlqp...@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.
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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 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. > > > FLDecoder-globalClassNamed.st Description: Binary data
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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 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 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. >> >> >> >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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 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 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 wrote: > On 02/04/13 12:50 AM, roberto.minelli-bhdirlqp...@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. > > > >
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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.mine...@usi.ch < roberto.mine...@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 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 > 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 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
Re: [Pharo-project] Collect all references to AnObsoleteFoo
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 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.mine...@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 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 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 wrote: > > On 02/04/13 12:50 AM, roberto.minelli-bhdirlqp...@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
Re: [Pharo-project] Collect all references to AnObsoleteFoo
p 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.mine...@usi.ch < roberto.mine...@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 > 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.mine...@usi.ch < > roberto.mine...@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 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 > 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 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 > > >
