On Oct 21, 11:20 pm, Slobodan Milnović <[email protected]> wrote: > There is actually the question that has been bugging me all day today, and > is in the subject. > > How to debug an weblocks app? The web backtrace from my point of view is a > bit terse.
The backtrace is usually enough to pinpoint issues. You can aid debugging by using the classic technique of print statements in the code or by using the TRACE macro. > I've tried to trace the functions that the backtrace reported > errors in, but all I would get was "closure XY has been called" message. > I've tried to step my weblocks app, but all I would get is an output of the > call to the weblocks app wrapped into call to step. What would be the way to > step through the weblocks app using sbcl resources? Use the BREAK function in your code to interrupt the worker thread. Then switch to the thread using sb-thread:release-foreground and step from there. > Also, one more question. As far as I was able to understand from the > available documentation, when the weblocks is started, each browser > connection creates an thread with the weblocks app and the hunchentoot > backend? Yes, that's about it. > At what point in the weblocks app this threading begins? Hunchentoot spawns the thread. The thread will eventually run the function weblocks::weblocks-dispatcher which in turn will run weblocks:handle-client-request unless we need to serve a public file. Leslie -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
