On Tuesday, April 10, 2012 12:19:06 AM UTC-7, nunb wrote: > > Then I delete a row in Company table that is linked to an employee in >> another table. >> Run the employee page (that lists them). >> Got an error There is no method >> #<STANDARD-GENERIC-FUNCTION WEBLOCKS-CLSQL-DEMO::COMPANY-NAME (1)> >> when called with arguments (NIL). >> >> > Then simply create the GF for the value nil > > Thanks. Added defmethod for NIL
> > > >> The web-server (hunchentoot) running the weblocks demo becomes >> unresponsive, until restarted. >> >> > If you mean that page hangs, then you're probably in debug mode, and your > lisp is displaying a stacktrace to help you debug the error. And you can > fix it live, and then the page will render (if the browser hasn't already > timed out). This is a GOOD thing. > The problem was fixed by deleting cookies (posted above). I had tried both normal and debug modes. > It hasn't halted the webserver. If you open another tab to the same site > (localhost?) the webserver wll spin up another thread to service the new > request. > That's the expected behavior but got confused because: 1) The same main page "url" was giving a static page or a class view depending on session cookies, so unresponsive main page (that I wrongly expected to show only a static text page) gave the impression that new listen threads are not being served. 2) It took me many iterations of running into all sorts of runtime errors and even javascript internal-errors, trying to make weblocks-clsql-demo work on Linux or MacOS (based on changes suggested in various threads). I am using quicklisp's March 30th dependency libraries on SBCL 1.53/MacOS. Hence an impression of fragile weblocks environment was formed (mainly due to incompatible libraries versions, not the weblocks code itself). It was not until I got a private patch of clsql-fluid from Scott (in this forum last week), that clsql-demo worked. > Unless you are running a single-threaded lisp, which I would wager you are > doing. > I had tested both on SBCL/Centos and SBCL/MacOS 10.6.8 (compiled sbcl with threading feature on Mac) > > >> Does that mean that unless all parts of a web application are written >> very carefully, making sure that all error exceptions/conditions >> are caught, a single runtime error can make the webserver stuck. >> >> > I don't even know how to respond to this. If you want help please > thoroughly describe your stack (OS, lisp, libraries etc). > I did consider the possibility that the weblocks author assumed that user is responsible to catch all error conditions (at least at some catch-all level), if they want to keep the web server alive (even if it is an independent listener library). This made more sense when I compared it to a more absurd assumption on hand: that weblock author could not imagine a good lisp programmer ever writing incorrect code. :-) > > > -- You received this message because you are subscribed to the Google Groups "weblocks" group. To view this discussion on the web visit https://groups.google.com/d/msg/weblocks/-/jSiRfgNNXsAJ. 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.
