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

[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

[John Aspinall]

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:

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

[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

--
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 iliad+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/iliad/298ae9e2-566d-4d27-9948-5f58092a7796%40googlegroups.com.

[John Aspinall]

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

To unsubscribe from this group and stop receiving emails from it, send an email to il...@googlegroups.com.