- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Tools with Proxy support

by Esteban Maringolo

It is really difficult to work with these, and it's been like that for a long time (I remember these issues with Pharo 3 and 4). Or at least with GLORP Proxies (I don't know if those you're working with are any different). I put a breakpoint in the Proxy to find what was triggering it and the breakpoint was ignored. I put `1 halt` and my image hung. Pressed Alt+. and the fireworks started. Â¯\_(ã)_/Â¯ Esteban A. Maringolo On Fri, Aug 7, 2020 at 8:59 PM Martin McClure <martin(a)hand2mouse.com> wrote: > > Hi Esteban, > > I also have trouble with this sort of thing in Pharo -- inspectors > sending messages to objects under inspection that are not understood, or > that do not respond in the way the inspector expects. > > It is possible to build a basic inspector that sends no messages at all > to the inspected object (using the mirror methods), and it would be nice > to have that option in Pharo. > > It's also possible to have a "careful" inspector that uses a mirror > method to determine the class of the inspected object, then uses either > the purely-mirroring inspector or the richer inspector, depending on > whether the object's class inherits from Object. Since the GemStone > clients make use of proxy objects, GemStone's inspectors take this > general approach. They're not perfect either, but problems are > considerably fewer. > > Regards, > -Martin > > On 8/7/20 4:33 PM, Esteban Maringolo wrote: > > Hi, > > > > I'm having a hard time trying to debug some Glorp code in Pharo 8 > > because the inspectors and the glamour things are triggering the > > instantiation of my Proxy objects. > > > > I don't know how the inspectors, variable lists, and other tool work, > > but I assume there should be a way to reimplement something in Proxy > > to avoid causing a MessageNotUnderstood that triggers the > > instantiation. > > > > If there is no way for it (I guess there is, looking at some gt* > > selectors in ProtoObject), please consider having a debugPrintString > > (and debugPrintOn:) in the upcoming Spec2 based tools. :-) > > > > Best regards, > > > > Esteban A. Maringolo > > >

Aug. 8, 2020

Re: [Pharo-dev] Tools with Proxy support

by Martin McClure

Hi Esteban, I also have trouble with this sort of thing in Pharo -- inspectors sending messages to objects under inspection that are not understood, or that do not respond in the way the inspector expects. It is possible to build a basic inspector that sends no messages at all to the inspected object (using the mirror methods), and it would be nice to have that option in Pharo. It's also possible to have a "careful" inspector that uses a mirror method to determine the class of the inspected object, then uses either the purely-mirroring inspector or the richer inspector, depending on whether the object's class inherits from Object. Since the GemStone clients make use of proxy objects, GemStone's inspectors take this general approach. They're not perfect either, but problems are considerably fewer. Regards, -Martin On 8/7/20 4:33 PM, Esteban Maringolo wrote: > Hi, > > I'm having a hard time trying to debug some Glorp code in Pharo 8 > because the inspectors and the glamour things are triggering the > instantiation of my Proxy objects. > > I don't know how the inspectors, variable lists, and other tool work, > but I assume there should be a way to reimplement something in Proxy > to avoid causing a MessageNotUnderstood that triggers the > instantiation. > > If there is no way for it (I guess there is, looking at some gt* > selectors in ProtoObject), please consider having a debugPrintString > (and debugPrintOn:) in the upcoming Spec2 based tools. :-) > > Best regards, > > Esteban A. Maringolo >

Aug. 7, 2020

Tools with Proxy support

by Esteban Maringolo

Hi, I'm having a hard time trying to debug some Glorp code in Pharo 8 because the inspectors and the glamour things are triggering the instantiation of my Proxy objects. I don't know how the inspectors, variable lists, and other tool work, but I assume there should be a way to reimplement something in Proxy to avoid causing a MessageNotUnderstood that triggers the instantiation. If there is no way for it (I guess there is, looking at some gt* selectors in ProtoObject), please consider having a debugPrintString (and debugPrintOn:) in the upcoming Spec2 based tools. :-) Best regards, Esteban A. Maringolo

Aug. 7, 2020