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
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
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@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
Hi Esteban. Try look into Ghost framework: https://github.com/pharo-ide/Ghost. I carefully put GT support methods into a separate package Ghost-GTSupport . It also includes a tool to collect all messages from given scenario (like opening inspector) which could help you: student := GHStudent new. student inspect. "then check messages:" student learning studiedMessages For new tools upcoming into Pharo 9 the other support package will be required. Also consider implementing Glorp proxies with Ghost. Use GHStudent as an example and I can answer any questions. Then we will have a single place (Ghost) to adopt to any tooling changes. Ñб, 8 авг. 2020 г. в 00:35, Esteban Maringolo <emaringolo@gmail.com>:
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
participants (3)
-
Denis Kudriashov -
Esteban Maringolo -
Martin McClure