live object debugging support

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

live object debugging support

Siemen Baader
Hi everyone,

IlCurrentContext#value is bugging me. I code in the Pharo debugger and when it is invoked through a web request, the ILCurrentContext value is nil, so ILWidgets do not render anymore in the debugging / inspector session. So I'm losing some og the many benefits of live object programming.

Could we save a ILContext value in ILObject the be returned by ILObject#context whenever ILCurrentContext#value is nil, and perhaps set it up it in IliadKom or wherever ILCurrentContext is initialized upon a request (I'm not sure exactly where, and if it is the same place for regular GET and xhr requests)?

This is of course a bit of a monkey patch, but perhaps valid and practical.

What do you think? Any pointers appreciated!

cheers
Siemen

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CAM47Zxrwu4RZbRxMrzTKYSat4awxx4FX8f_nnp%2Ba%2BSAd-NEaGw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: live object debugging support

Siemen Baader
A little update on this:

I monkeypatched ILCurrentContext class#use:during:, which is called from ILDisptcher#dispatchRequest to save the previous value of the context.

ILCurrentContext class #use: anObject during: aBlock
   debugContext := anObject.
   ^ aBlock
    on: self
    do:
    [ :notification | notification resume: anObject ]

--- and ---

ILCurrentContext class#value
   self signal ifNil: [ ^ debugContext ].
    debugContext := self signal.
    ^ self signal

This actually helps a bit, but falls short because ILObject#application is tripped up when subsequent HTTP requests request assets with a different path than the current ILApplication -  they overwrite the path in the context and ILRouter then is unable to find the debugged application based on its path.

I'll see if I can hack myself close enough to allow live object debugging, or if it requires a restructuring of the session manager etc.

I recall that the problem was also discussed on the Seaside. I'm a bit surprised that people accept this dev experience since live objects are a key motivation to use Pharo or other live Smalltalks.

-- Siemen

On Tue, Oct 8, 2019 at 3:06 PM Siemen Baader <[hidden email]> wrote:
Hi everyone,

IlCurrentContext#value is bugging me. I code in the Pharo debugger and when it is invoked through a web request, the ILCurrentContext value is nil, so ILWidgets do not render anymore in the debugging / inspector session. So I'm losing some og the many benefits of live object programming.

Could we save a ILContext value in ILObject the be returned by ILObject#context whenever ILCurrentContext#value is nil, and perhaps set it up it in IliadKom or wherever ILCurrentContext is initialized upon a request (I'm not sure exactly where, and if it is the same place for regular GET and xhr requests)?

This is of course a bit of a monkey patch, but perhaps valid and practical.

What do you think? Any pointers appreciated!

cheers
Siemen

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CAM47Zxo8FvfM1VsmiVbsHvx8O3FYPccqNf6%2Bk5KBqYC%3DVRQLvQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: live object debugging support

rko281
Hi Siemen,

It should be the case that when stepping through code in the debugger the active ILCurrentContext and other process/context-specific variables are respected. This was fixed quite a while ago - see here:


Unfortunately this doesn't help when evaluating arbitrary code snippets in the debugger. Usually I handle this on a case-by-case basic by caching the current context (or whatever) in a temporary variable.

Hope this helps,

John


On Wednesday, October 9, 2019 at 9:52:34 AM UTC+1, Siemen Baader wrote:
A little update on this:

I monkeypatched ILCurrentContext class#use:during:, which is called from ILDisptcher#dispatchRequest to save the previous value of the context.

ILCurrentContext class #use: anObject during: aBlock
   debugContext := anObject.
   ^ aBlock
    on: self
    do:
    [ :notification | notification resume: anObject ]

--- and ---

ILCurrentContext class#value
   self signal ifNil: [ ^ debugContext ].
    debugContext := self signal.
    ^ self signal

This actually helps a bit, but falls short because ILObject#application is tripped up when subsequent HTTP requests request assets with a different path than the current ILApplication -  they overwrite the path in the context and ILRouter then is unable to find the debugged application based on its path.

I'll see if I can hack myself close enough to allow live object debugging, or if it requires a restructuring of the session manager etc.

I recall that the problem was also discussed on the Seaside. I'm a bit surprised that people accept this dev experience since live objects are a key motivation to use Pharo or other live Smalltalks.

-- Siemen

On Tue, Oct 8, 2019 at 3:06 PM Siemen Baader <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="_aebxppDCgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">siemen...@...> wrote:
Hi everyone,

IlCurrentContext#value is bugging me. I code in the Pharo debugger and when it is invoked through a web request, the ILCurrentContext value is nil, so ILWidgets do not render anymore in the debugging / inspector session. So I'm losing some og the many benefits of live object programming.

Could we save a ILContext value in ILObject the be returned by ILObject#context whenever ILCurrentContext#value is nil, and perhaps set it up it in IliadKom or wherever ILCurrentContext is initialized upon a request (I'm not sure exactly where, and if it is the same place for regular GET and xhr requests)?

This is of course a bit of a monkey patch, but perhaps valid and practical.

What do you think? Any pointers appreciated!

cheers
Siemen

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: live object debugging support

Siemen Baader
Hi John,

thanks for your reply!

How do you cache the value? ILCurrentContext#value is nil as soon as I am in the debugger when it is opened by Pharo after an exception is thrown during a web request.

cheers
Siemen

On Wed, Oct 9, 2019 at 11:20 AM John Aspinall <[hidden email]> wrote:
Hi Siemen,

It should be the case that when stepping through code in the debugger the active ILCurrentContext and other process/context-specific variables are respected. This was fixed quite a while ago - see here:


Unfortunately this doesn't help when evaluating arbitrary code snippets in the debugger. Usually I handle this on a case-by-case basic by caching the current context (or whatever) in a temporary variable.

Hope this helps,

John


On Wednesday, October 9, 2019 at 9:52:34 AM UTC+1, Siemen Baader wrote:
A little update on this:

I monkeypatched ILCurrentContext class#use:during:, which is called from ILDisptcher#dispatchRequest to save the previous value of the context.

ILCurrentContext class #use: anObject during: aBlock
   debugContext := anObject.
   ^ aBlock
    on: self
    do:
    [ :notification | notification resume: anObject ]

--- and ---

ILCurrentContext class#value
   self signal ifNil: [ ^ debugContext ].
    debugContext := self signal.
    ^ self signal

This actually helps a bit, but falls short because ILObject#application is tripped up when subsequent HTTP requests request assets with a different path than the current ILApplication -  they overwrite the path in the context and ILRouter then is unable to find the debugged application based on its path.

I'll see if I can hack myself close enough to allow live object debugging, or if it requires a restructuring of the session manager etc.

I recall that the problem was also discussed on the Seaside. I'm a bit surprised that people accept this dev experience since live objects are a key motivation to use Pharo or other live Smalltalks.

-- Siemen

On Tue, Oct 8, 2019 at 3:06 PM Siemen Baader <[hidden email]> wrote:
Hi everyone,

IlCurrentContext#value is bugging me. I code in the Pharo debugger and when it is invoked through a web request, the ILCurrentContext value is nil, so ILWidgets do not render anymore in the debugging / inspector session. So I'm losing some og the many benefits of live object programming.

Could we save a ILContext value in ILObject the be returned by ILObject#context whenever ILCurrentContext#value is nil, and perhaps set it up it in IliadKom or wherever ILCurrentContext is initialized upon a request (I'm not sure exactly where, and if it is the same place for regular GET and xhr requests)?

This is of course a bit of a monkey patch, but perhaps valid and practical.

What do you think? Any pointers appreciated!

cheers
Siemen

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/CAM47Zxru9kNa76BJNsEfUZnjCWDv0tfwLPZx4MDF3X6KM0O5hg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: live object debugging support

rko281
Hi Siemen - here's an example using the ILCounter example class:

increase

| ctx |
ctx := ILCurrentContext  value.
self halt.
count := count + 1.
self markDirty

After the halt ctx should hold the active ILCurrentContext for you to inspect etc.. In fact you can put the halt at the start of the method; stepping through "ctx := ILCurrentContext value" should set the value correctly since it's executing in the original context.

It's less straightforward if you're debugging an error; in this case I'd temporarily modify a method before the error occurs to cache the active context.

Cheers.

John



On Wednesday, October 9, 2019 at 11:15:29 AM UTC+1, Siemen Baader wrote:
Hi John,

thanks for your reply!

How do you cache the value? ILCurrentContext#value is nil as soon as I am in the debugger when it is opened by Pharo after an exception is thrown during a web request.

cheers
Siemen

On Wed, Oct 9, 2019 at 11:20 AM John Aspinall <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="n79m-SBICgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">john.a...@...> wrote:
Hi Siemen,

It should be the case that when stepping through code in the debugger the active ILCurrentContext and other process/context-specific variables are respected. This was fixed quite a while ago - see here:

<a href="http://forum.world.st/How-to-debug-code-using-DynamicVariable-td4764336.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fforum.world.st%2FHow-to-debug-code-using-DynamicVariable-td4764336.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMoCYuUC06Uzyf_iQbD_1AgGJmbg&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fforum.world.st%2FHow-to-debug-code-using-DynamicVariable-td4764336.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHMoCYuUC06Uzyf_iQbD_1AgGJmbg&#39;;return true;">http://forum.world.st/How-to-debug-code-using-DynamicVariable-td4764336.html

Unfortunately this doesn't help when evaluating arbitrary code snippets in the debugger. Usually I handle this on a case-by-case basic by caching the current context (or whatever) in a temporary variable.

Hope this helps,

John


On Wednesday, October 9, 2019 at 9:52:34 AM UTC+1, Siemen Baader wrote:
A little update on this:

I monkeypatched ILCurrentContext class#use:during:, which is called from ILDisptcher#dispatchRequest to save the previous value of the context.

ILCurrentContext class #use: anObject during: aBlock
   debugContext := anObject.
   ^ aBlock
    on: self
    do:
    [ :notification | notification resume: anObject ]

--- and ---

ILCurrentContext class#value
   self signal ifNil: [ ^ debugContext ].
    debugContext := self signal.
    ^ self signal

This actually helps a bit, but falls short because ILObject#application is tripped up when subsequent HTTP requests request assets with a different path than the current ILApplication -  they overwrite the path in the context and ILRouter then is unable to find the debugged application based on its path.

I'll see if I can hack myself close enough to allow live object debugging, or if it requires a restructuring of the session manager etc.

I recall that the problem was also discussed on the Seaside. I'm a bit surprised that people accept this dev experience since live objects are a key motivation to use Pharo or other live Smalltalks.

-- Siemen

On Tue, Oct 8, 2019 at 3:06 PM Siemen Baader <[hidden email]> wrote:
Hi everyone,

IlCurrentContext#value is bugging me. I code in the Pharo debugger and when it is invoked through a web request, the ILCurrentContext value is nil, so ILWidgets do not render anymore in the debugging / inspector session. So I'm losing some og the many benefits of live object programming.

Could we save a ILContext value in ILObject the be returned by ILObject#context whenever ILCurrentContext#value is nil, and perhaps set it up it in IliadKom or wherever ILCurrentContext is initialized upon a request (I'm not sure exactly where, and if it is the same place for regular GET and xhr requests)?

This is of course a bit of a monkey patch, but perhaps valid and practical.

What do you think? Any pointers appreciated!

cheers
Siemen

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="n79m-SBICgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">il...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Iliad project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/cca4757f-f9ed-43d2-bbb9-6c0c38bd241c%40googlegroups.com.