Hello,
the following freezes the Squeak UI: - implement a callback as "self halt zork" - trigger the callback in the webbrowser (e.g. click on an anchor with this callback) - the debugger pops up - click on the callback method, step over halt, step over zork - the web browser will now show the error in the usual way - press debug - UI is frozen, image is still alive _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> - click on the callback method, step over halt, step over zork
I cannot reproduce that. I get an internal error displayed in the web browser. > - UI is frozen, image is still alive The problem is that you are trying to request another page in the same session, while you have the stepping debugger open. Every session has a mutex that prevents the handling of multiple requests though. Since the debugger runs in the GUI thread this locks up Squeak. If I press Ctrl+. and close the old debugger, I get a new one on the message not understood zork. So everything seems normal here. Generally you should avoid stepping over code that causes a response to be sent out to the browser, like the error with the #zork, or when doing a #call: or #answer:. In the current implementation this cannot possibly work within a single debugger, as there are many different processes involved (every request gets a new process). Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> > - click on the callback method, step over halt, step over zork
> > I cannot reproduce that. I get an internal error displayed in the web browser. Sorry, that's for Seaside 2.9. > > - UI is frozen, image is still alive And that's for Seaside 2.8 (what you are probably using): > The problem is that you are trying to request another page in the same > session, while you have the stepping debugger open. Every session has > a mutex that prevents the handling of multiple requests though. Since > the debugger runs in the GUI thread this locks up Squeak. > > If I press Ctrl+. and close the old debugger, I get a new one on the > message not understood zork. So everything seems normal here. > > Generally you should avoid stepping over code that causes a response > to be sent out to the browser, like the error with the #zork, or when > doing a #call: or #answer:. In the current implementation this cannot > possibly work within a single debugger, as there are many different > processes involved (every request gets a new process). -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Holger Kleinsorgen-3
On 10-Apr-08, at 7:06 AM, Holger Kleinsorgen wrote: > - UI is frozen, image is still alive Hi Holger, I've run into this myself. I haven't been able to pin down the exact cause, but I believe it's something like this: by opening a debugger, you are effectively transferring execution of the callback from a Seaside process to the UI process. When you step over the method that produces an HTTP response, Seaside uses an escape continuation to replace the stack of the UI process with the stack of the process that was serving the HTTP request. Once the response has been sent to the browser, that process exits, leaving you without a UI process. It's probably not exactly like that, and probably the exact steps are different in the different versions of Seaside, but the effect is always that the UI process is destroyed when the HTTP response is sent out. Fortunately, there's an easy work around. Just press cmd-. to create a new UI process and you're fine. Colin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>> - UI is frozen, image is still alive
> > Hi Holger, > > I've run into this myself. I haven't been able to pin down the exact > cause, but I believe it's something like this: by opening a debugger, > you are effectively transferring execution of the callback from a > Seaside process to the UI process. When you step over the method that > produces an HTTP response, Seaside uses an escape continuation to > replace the stack of the UI process with the stack of the process that > was serving the HTTP request. Once the response has been sent to the > browser, that process exits, leaving you without a UI process. > > It's probably not exactly like that, and probably the exact steps are > different in the different versions of Seaside, but the effect is always > that the UI process is destroyed when the HTTP response is sent out. > Fortunately, there's an easy work around. Just press cmd-. to create a > new UI process and you're fine. thank you both for the explanation and the solution. > And that's for Seaside 2.8 (what you are probably using): exactly _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |