Tools with Proxy support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Tools with Proxy support

Esteban A. 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

Reply | Threaded
Open this post in threaded view
|

Re: Tools with Proxy support

Martin McClure-2
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Tools with Proxy support

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 <[hidden email]> 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
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Tools with Proxy support

Denis Kudriashov
In reply to this post by 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 <[hidden email]>:
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