Always getting WARequestContextNotFound while debugging

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

Always getting WARequestContextNotFound while debugging

Tim Johnson-2
Hi,

Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?

It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window.  

Basically, it seems like I can't interact with anything but the topmost item in a debugger anymore, but I could be totally wrong about that.

I don't suppose this would have anything to do with proxying through Apache or nginx...?

I'm also having trouble clicking on individual stack items in the Seaside Walkback, but that might be unrelated, or related to the proxy.

Here is a sample stack when trying to inspect/print something three items down in the stack after hitting "Debug" on a Seaside Walkback.  I am wondering if something is up with WADynamicVariable in Squeak lately:

WACurrentRequestContext class>>defaultValue
WACurrentRequestContext(WADynamicVariable)>>defaultAction
UndefinedObject>>handleSignal:
Context>>handleSignal:
WACurrentRequestContext(Exception)>>signal
WACurrentRequestContext class(Exception class)>>signal
WACurrentRequestContext class(WADynamicVariable class)>>value
PCardLoggedInComponent(WAObject)>>requestContext
PCardLoggedInComponent(WAObject)>>session
PCardLoggedInComponent>>DoItIn:
Compiler>>evaluateCue:ifFail:
Compiler>>evaluateCue:ifFail:logged:
Compiler>>evaluate:in:to:environment:notifying:ifFail:logged:
[] in SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
BlockClosure>>on:do:
SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
SmalltalkEditor(TextEditor)>>printIt
SmalltalkEditor(TextEditor)>>printIt:
SmalltalkEditor(TextEditor)>>dispatchOnKeyboardEvent:
SmalltalkEditor(TextEditor)>>keyStroke:


Thanks,
Tim J


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Thomas Brodt-2
Hi Tim,

access to the current request context is handled through signalling a
request notification and getting the request context as the notification
resume value. See class WACurrentRequestContext which is a notification.
If you are running requests regularly in the normal control flow, some
outer methods establish a handler which catches the notification and
returns the current context. See implementers of #push:during: and
#use:during: which do that. This allows to get e.g. the request (or
other so called dynamic variables) without having to pass it along the
call chain as parameter or have it as instance variable.

If you are executing arbitrary code in the debugger through
print/inspect/do it, this outer notification handler is missing and the
request notification is then unhandled, which results in another "real"
exception WARequestContextNotFound because the context is not found.

HTH

Thomas

Am 11.04.2019 um 06:27 schrieb Tim Johnson:

> Hi,
>
> Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?
>
> It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window.
>
> Basically, it seems like I can't interact with anything but the topmost item in a debugger anymore, but I could be totally wrong about that.
>
> I don't suppose this would have anything to do with proxying through Apache or nginx...?
>
> I'm also having trouble clicking on individual stack items in the Seaside Walkback, but that might be unrelated, or related to the proxy.
>
> Here is a sample stack when trying to inspect/print something three items down in the stack after hitting "Debug" on a Seaside Walkback.  I am wondering if something is up with WADynamicVariable in Squeak lately:
>
> WACurrentRequestContext class>>defaultValue
> WACurrentRequestContext(WADynamicVariable)>>defaultAction
> UndefinedObject>>handleSignal:
> Context>>handleSignal:
> WACurrentRequestContext(Exception)>>signal
> WACurrentRequestContext class(Exception class)>>signal
> WACurrentRequestContext class(WADynamicVariable class)>>value
> PCardLoggedInComponent(WAObject)>>requestContext
> PCardLoggedInComponent(WAObject)>>session
> PCardLoggedInComponent>>DoItIn:
> Compiler>>evaluateCue:ifFail:
> Compiler>>evaluateCue:ifFail:logged:
> Compiler>>evaluate:in:to:environment:notifying:ifFail:logged:
> [] in SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
> BlockClosure>>on:do:
> SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
> SmalltalkEditor(TextEditor)>>printIt
> SmalltalkEditor(TextEditor)>>printIt:
> SmalltalkEditor(TextEditor)>>dispatchOnKeyboardEvent:
> SmalltalkEditor(TextEditor)>>keyStroke:
>
>
> Thanks,
> Tim J
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Mariano Martinez Peck
In reply to this post by Tim Johnson-2


On Thu, Apr 11, 2019 at 1:27 AM Tim Johnson <[hidden email]> wrote:
Hi,

Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?

It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window. 

Basically, it seems like I can't interact with anything but the topmost item in a debugger anymore, but I could be totally wrong about that.

I don't suppose this would have anything to do with proxying through Apache or nginx...?

I'm also having trouble clicking on individual stack items in the Seaside Walkback, but that might be unrelated, or related to the proxy.



Hi Tim,

I know that feeling. That's why some time ago I implemented my own workaround (super hackish):


--
Mariano Martinez Peck

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Johan Brichau-2
This is cool

I wonder if we could integrate it into Seaside…

I’ll put it on my stack to investigate ;)

On 11 Apr 2019, at 15:23, Mariano Martinez Peck <[hidden email]> wrote:



On Thu, Apr 11, 2019 at 1:27 AM Tim Johnson <[hidden email]> wrote:
Hi,

Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?

It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window.  

Basically, it seems like I can't interact with anything but the topmost item in a debugger anymore, but I could be totally wrong about that.

I don't suppose this would have anything to do with proxying through Apache or nginx...?

I'm also having trouble clicking on individual stack items in the Seaside Walkback, but that might be unrelated, or related to the proxy.



Hi Tim,

I know that feeling. That's why some time ago I implemented my own workaround (super hackish):


-- 
Mariano Martinez Peck
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Mariano Martinez Peck


On Fri, Apr 12, 2019 at 12:26 PM Johan Brichau <[hidden email]> wrote:
This is cool

I wonder if we could integrate it into Seaside…

I’ll put it on my stack to investigate ;)


It's hackish..... but you will get it immediately. 
If we can polish it and make it a bit less hackish, it may be a good idea to include it. 

Let me know!

--
Mariano Martinez Peck

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Tim Johnson-2
In reply to this post by Thomas Brodt-2
Hi Thomas,

Thank you for the explanation!  I am happy to build a better understanding of this mechanism, especially as I work to master exceptions, handlers, and return values.

I still have this foggy memory that in the era of Seaside 2.6/2.7/2.8, I had access to most/all variables in the debugger.  Am I mistaken?

Best,
Tim J

> On Apr 11, 2019, at 12:11 AM, Thomas Brodt <[hidden email]> wrote:
>
> Hi Tim,
>
> access to the current request context is handled through signalling a request notification and getting the request context as the notification resume value. See class WACurrentRequestContext which is a notification. If you are running requests regularly in the normal control flow, some outer methods establish a handler which catches the notification and returns the current context. See implementers of #push:during: and #use:during: which do that. This allows to get e.g. the request (or other so called dynamic variables) without having to pass it along the call chain as parameter or have it as instance variable.
>
> If you are executing arbitrary code in the debugger through print/inspect/do it, this outer notification handler is missing and the request notification is then unhandled, which results in another "real" exception WARequestContextNotFound because the context is not found.
>
> HTH
>
> Thomas
>
> Am 11.04.2019 um 06:27 schrieb Tim Johnson:
>> Hi,
>>
>> Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?
>>
>> It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window.
>>
>> Basically, it seems like I can't interact with anything but the topmost item in a debugger anymore, but I could be totally wrong about that.
>>
>> I don't suppose this would have anything to do with proxying through Apache or nginx...?
>>
>> I'm also having trouble clicking on individual stack items in the Seaside Walkback, but that might be unrelated, or related to the proxy.
>>
>> Here is a sample stack when trying to inspect/print something three items down in the stack after hitting "Debug" on a Seaside Walkback.  I am wondering if something is up with WADynamicVariable in Squeak lately:
>>
>> WACurrentRequestContext class>>defaultValue
>> WACurrentRequestContext(WADynamicVariable)>>defaultAction
>> UndefinedObject>>handleSignal:
>> Context>>handleSignal:
>> WACurrentRequestContext(Exception)>>signal
>> WACurrentRequestContext class(Exception class)>>signal
>> WACurrentRequestContext class(WADynamicVariable class)>>value
>> PCardLoggedInComponent(WAObject)>>requestContext
>> PCardLoggedInComponent(WAObject)>>session
>> PCardLoggedInComponent>>DoItIn:
>> Compiler>>evaluateCue:ifFail:
>> Compiler>>evaluateCue:ifFail:logged:
>> Compiler>>evaluate:in:to:environment:notifying:ifFail:logged:
>> [] in SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
>> BlockClosure>>on:do:
>> SmalltalkEditor(TextEditor)>>evaluateSelectionAndDo:
>> SmalltalkEditor(TextEditor)>>printIt
>> SmalltalkEditor(TextEditor)>>printIt:
>> SmalltalkEditor(TextEditor)>>dispatchOnKeyboardEvent:
>> SmalltalkEditor(TextEditor)>>keyStroke:
>>
>>
>> Thanks,
>> Tim J
>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Tim Johnson-2
In reply to this post by Mariano Martinez Peck


On Apr 11, 2019, at 6:23 AM, Mariano Martinez Peck <[hidden email]> wrote:

On Thu, Apr 11, 2019 at 1:27 AM Tim Johnson <[hidden email]> wrote:
Hi,

Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?

It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window. 


Hi Tim,

I know that feeling. That's why some time ago I implemented my own workaround (super hackish):


Hi Mariano,

Glad I'm not alone!  :)

Thanks for this!  It is super cool.  I have loaded it successfully in Squeak 5.2 running Seaside 3.2.  

(One immediate difference I noticed:  no more Seaside walkback in the browser.  [Not a problem!  Just noting here.]  A stalled browser means I need to go to my image, where I will find a Debugger open.)

So, it did not work with Squeak out-of-the-box, but I have made the necessary modifications for it to work.  

I have adapted WADynamicVariable>>#getAllOpenedSeasideDebuggers and added a package protocol method to Debugger, such that #session just returns self.

Unfortunately I don't believe I can use this "cypress" packaged format with Squeak (I have no 'gitfiletree', only 'filetree') so I do not know how to contribute my changes (from Squeak) as a fork commit & pull request.  Therefore, attached is an old-fashioned change set file.

Summary of changes:
* adjustments for platform independence 
* searching for Squeak Debuggers now too
* package protocol on Debugger:  I assume this means this changeset won't load on platforms without a Debugger class (?)
* broke up WADynamicVariable>>#getAllOpenedSeasideDebuggers into multiple methods
* added carriage returns to Transcript shows
* typo fix

If you do have some suggestions for another way for me to contribute this please let me know.  I am quite comfortable with Git and etc., but without GitFileTree I imagine I may be out of luck.

Thanks again,
Tim







_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

SeasideDynamicVariablesDebugger-Squeak-tcj.1.cs (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Mariano Martinez Peck


On Sun, Apr 14, 2019 at 2:26 PM Tim Johnson <[hidden email]> wrote:


On Apr 11, 2019, at 6:23 AM, Mariano Martinez Peck <[hidden email]> wrote:

On Thu, Apr 11, 2019 at 1:27 AM Tim Johnson <[hidden email]> wrote:
Hi,

Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?

It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window. 


Hi Tim,

I know that feeling. That's why some time ago I implemented my own workaround (super hackish):


Hi Mariano,

Glad I'm not alone!  :)

Thanks for this!  It is super cool.  I have loaded it successfully in Squeak 5.2 running Seaside 3.2.  

(One immediate difference I noticed:  no more Seaside walkback in the browser.  [Not a problem!  Just noting here.]  A stalled browser means I need to go to my image, where I will find a Debugger open.)

So, it did not work with Squeak out-of-the-box, but I have made the necessary modifications for it to work.  

I have adapted WADynamicVariable>>#getAllOpenedSeasideDebuggers and added a package protocol method to Debugger, such that #session just returns self.

Unfortunately I don't believe I can use this "cypress" packaged format with Squeak (I have no 'gitfiletree', only 'filetree') so I do not know how to contribute my changes (from Squeak) as a fork commit & pull request.  Therefore, attached is an old-fashioned change set file.

Summary of changes:
* adjustments for platform independence 
* searching for Squeak Debuggers now too
* package protocol on Debugger:  I assume this means this changeset won't load on platforms without a Debugger class (?)
* broke up WADynamicVariable>>#getAllOpenedSeasideDebuggers into multiple methods
* added carriage returns to Transcript shows
* typo fix

If you do have some suggestions for another way for me to contribute this please let me know.  I am quite comfortable with Git and etc., but without GitFileTree I imagine I may be out of luck.



I am glad to read that worked out even with some effort. Honestly, I was never mean to be generic...as you saw in the implementation. But the idea itself IS general and can be easily adapted for each dialect, as you also found out. 
And that is not even considering Squeak. 
So I really don't know how find a format that would work everywhere. 
From what I can guess you are using "metadatafull filetree" and in that project I am using "metadataless filetree" ... 
Maybe we can migrate it to Tonel, but I don't if that's supported on Squeak neither in what version. 

I guess what I would do is to simply create a separate project or a fork of mine and putting everything as "metadatafull filetree" (what you get from your squeak) and then in mine I just update README saying: 'if you use Squeak, use this repo instead"

Thoughts? 

--
Mariano Martinez Peck

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
bpi
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

bpi
Hi Mariano,

Just my 2 cents:

According to section Supported Pharo versions in https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/ExportFormats.md metadatafull filetree seems the best bet. As long as there is not much branching and merging going on, the downsides should not be too great.

What does Seaside itself use? Doesn't it have the same problem?

- Bernhard

> Am 15.04.2019 um 03:00 schrieb Mariano Martinez Peck <[hidden email]>:
>
>
> On Sun, Apr 14, 2019 at 2:26 PM Tim Johnson <[hidden email]> wrote:
>
>
>> On Apr 11, 2019, at 6:23 AM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>> On Thu, Apr 11, 2019 at 1:27 AM Tim Johnson <[hidden email]> wrote:
>> Hi,
>>
>> Since moving to Seaside 3.x in Squeak 5.x, it seems like I haven't been able to debug as well as I used to.  This has been happening for a while but I just thought I'd ask about it now.  It seems worse lately...?
>>
>> It seems like after I hit "Debug" on a Seaside Walkback, I go back to my image and enter the debugger.  Then when I try to evaluate / print / inspect various statements maybe three items down the stack, I always end up with something like a WARequestContextNotFound window.  
>>
>>
>> Hi Tim,
>>
>> I know that feeling. That's why some time ago I implemented my own workaround (super hackish):
>>
>> https://github.com/marianopeck/SeasideDynamicVariablesDebugger 
>
> Hi Mariano,
>
> Glad I'm not alone!  :)
>
> Thanks for this!  It is super cool.  I have loaded it successfully in Squeak 5.2 running Seaside 3.2.  
>
> (One immediate difference I noticed:  no more Seaside walkback in the browser.  [Not a problem!  Just noting here.]  A stalled browser means I need to go to my image, where I will find a Debugger open.)
>
> So, it did not work with Squeak out-of-the-box, but I have made the necessary modifications for it to work.  
>
> I have adapted WADynamicVariable>>#getAllOpenedSeasideDebuggers and added a package protocol method to Debugger, such that #session just returns self.
>
> Unfortunately I don't believe I can use this "cypress" packaged format with Squeak (I have no 'gitfiletree', only 'filetree') so I do not know how to contribute my changes (from Squeak) as a fork commit & pull request.  Therefore, attached is an old-fashioned change set file.
>
> Summary of changes:
> * adjustments for platform independence
> * searching for Squeak Debuggers now too
> * package protocol on Debugger:  I assume this means this changeset won't load on platforms without a Debugger class (?)
> * broke up WADynamicVariable>>#getAllOpenedSeasideDebuggers into multiple methods
> * added carriage returns to Transcript shows
> * typo fix
>
> If you do have some suggestions for another way for me to contribute this please let me know.  I am quite comfortable with Git and etc., but without GitFileTree I imagine I may be out of luck.
>
>
>
> I am glad to read that worked out even with some effort. Honestly, I was never mean to be generic...as you saw in the implementation. But the idea itself IS general and can be easily adapted for each dialect, as you also found out.
> As for the file format in Pharo, its a mess. See this: https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/ExportFormats.md
> And that is not even considering Squeak.
> So I really don't know how find a format that would work everywhere.
> From what I can guess you are using "metadatafull filetree" and in that project I am using "metadataless filetree" ...
> Maybe we can migrate it to Tonel, but I don't if that's supported on Squeak neither in what version.
>
> I guess what I would do is to simply create a separate project or a fork of mine and putting everything as "metadatafull filetree" (what you get from your squeak) and then in mine I just update README saying: 'if you use Squeak, use this repo instead"
>
> Thoughts?
>
> --
> Mariano Martinez Peck
> Email: [hidden email]
> Twitter: @MartinezPeck
> LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Always getting WARequestContextNotFound while debugging

Mariano Martinez Peck
Hi Bernhard,

Yeah, maybe, but back at that time when I did that, gitfiletree was the "most common" and I honestly wasn't thinking on Squeak.
Now in the middle it even appeared Tonel ...
Unfortunately, I don't have time enough to migrate the format neither to research which format would work for Pharo X, Squeak Y, etc. 

Thanks,

--
Mariano Martinez Peck

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside