Re: Pharo-dev Digest, Vol 88, Issue 7

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

Re: Pharo-dev Digest, Vol 88, Issue 7

Richard Uttner
Hi Esteban and Martin,

sorry for my contribution to this topic being so late. I fully agree to
Martin's suggestion of checking if an inspected object conforms to the
rich inspector api before applying it.

For dealing with Glorp, I found an easy solution which Pavel will
integrate soon in the Glorp port he published some time ago. My approach
to find the trigger(s) resolving the proxy was simply hooking
#doesNotUnderstand: with a Transcript trace of the current message. So I
found out that it were only 3, which I list below along with my
implementation in Proxy that stopped any resolving:

gtDisplayString
     self isInstantiated
         ifTrue: [ ^self class name , ' on ', value gtDisplayString].
     ^self class name, ' uninstantiated on ', self query resultClass name

gtInspectorVariableNodesIn: aCollection
    "Taken from Object, avoiding loop over indexed variables calling
#basicSize"
    aCollection
         addAll: ((self class allSlots collect: [ :slot |
             GTInspectorSlotNode hostObject: self slot: slot ]))

readSlot: aSlot
     "Taken from Object, sent by GTInspectorSlotNode"
     ^aSlot read: self

With this approach, I was not able to trigger proxy resolution by just
navigating in the inspector, I had to explicitely send #getValue to the
slot. Hope this helps until we have a more general solution!

Best regards,

Richard

Am 08.08.2020 um 18:00 schrieb [hidden email]:

> Message: 1
> Date: Fri, 7 Aug 2020 20:33:50 -0300
> From: Esteban Maringolo<[hidden email]>
> To: Pharo Developers<[hidden email]>
> Subject: [Pharo-dev] Tools with Proxy support
> Message-ID:
> <CAJMgPC+5v4eG+qK3m7LjWmYs3H1J=[hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 7 Aug 2020 16:59:10 -0700
> From: Martin McClure<[hidden email]>
> To: Pharo Development List<[hidden email]>, Esteban
> Maringolo<[hidden email]>
> Subject: Re: [Pharo-dev] Tools with Proxy support
> Message-ID:<[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Pharo-dev Digest, Vol 88, Issue 7

Esteban A. Maringolo
Hi Richard,

Thanks for the reply, I add my comments between your lines.

On Tue, Aug 25, 2020 at 4:29 PM Richard Uttner <[hidden email]> wrote:

> sorry for my contribution to this topic being so late. I fully agree to
> Martin's suggestion of checking if an inspected object conforms to the
> rich inspector api before applying it.
>
> For dealing with Glorp, I found an easy solution which Pavel will
> integrate soon in the Glorp port he published some time ago.

Where is this port? I haven't seen it and it would be great if we
could merge it with the canonical repository at pharo-rdbms/glorp
which has been active lately (I even have a few bugfixes to submit)

> My approach
> to find the trigger(s) resolving the proxy was simply hooking
> #doesNotUnderstand: with a Transcript trace of the current message. So I
> found out that it were only 3, which I list below along with my
> implementation in Proxy that stopped any resolving:

Simple and clever.

> gtDisplayString
>      self isInstantiated
>          ifTrue: [ ^self class name , ' on ', value gtDisplayString].
>      ^self class name, ' uninstantiated on ', self query resultClass name

I had this.

> gtInspectorVariableNodesIn: aCollection
> readSlot: aSlot

I hadn't these. I'll add them as an extension to the Proxy class.

> With this approach, I was not able to trigger proxy resolution by just
> navigating in the inspector, I had to explicitely send #getValue to the
> slot. Hope this helps until we have a more general solution!

This is exactly what I needed.

Thank you very much!

Reply | Threaded
Open this post in threaded view
|

Re: Pharo-dev Digest, Vol 88, Issue 7

Pavel Krivanek-3


út 25. 8. 2020 v 21:52 odesílatel Esteban Maringolo <[hidden email]> napsal:
Hi Richard,

Thanks for the reply, I add my comments between your lines.

On Tue, Aug 25, 2020 at 4:29 PM Richard Uttner <[hidden email]> wrote:

> sorry for my contribution to this topic being so late. I fully agree to
> Martin's suggestion of checking if an inspected object conforms to the
> rich inspector api before applying it.
>
> For dealing with Glorp, I found an easy solution which Pavel will
> integrate soon in the Glorp port he published some time ago.

Where is this port? I haven't seen it and it would be great if we
could merge it with the canonical repository at pharo-rdbms/glorp
which has been active lately (I even have a few bugfixes to submit)

In a  lot of ways, it is different to the master version so transition for users may cause some troubles and there are still some failing tests. It is not safe to promote it as master for everyone but we are using it without any trouble.


> My approach
> to find the trigger(s) resolving the proxy was simply hooking
> #doesNotUnderstand: with a Transcript trace of the current message. So I
> found out that it were only 3, which I list below along with my
> implementation in Proxy that stopped any resolving:

Simple and clever.

> gtDisplayString
>      self isInstantiated
>          ifTrue: [ ^self class name , ' on ', value gtDisplayString].
>      ^self class name, ' uninstantiated on ', self query resultClass name

I had this.

> gtInspectorVariableNodesIn: aCollection
> readSlot: aSlot

I hadn't these. I'll add them as an extension to the Proxy class.

> With this approach, I was not able to trigger proxy resolution by just
> navigating in the inspector, I had to explicitely send #getValue to the
> slot. Hope this helps until we have a more general solution!

This is exactly what I needed.

Thank you very much!