I agree with Mac. For me it's a question of "how much work I can do without having to open the browser to test the functionality". Maybe it's a bad design that I use, but I refer to the *session* variables not only from the final *dispatch-table* function but from some intermediary ones too. That means I can only test them by opening the web page. It would be great if I could build the whole functionality from slime and only check the final stage from the browser.
Andrew
On 5/4/07, Mac Chan emailmac@gmail.com wrote:
On 5/4/07, Pierre THIERRY nowhere.man@levallois.eu.org wrote:
Except it's now more flexible, and there's a conditional branching and a cache miss that won't go in Hunchentoot's critical path.
Not that I insist we put something something redundant into Hunchentoot's critical path, as stated in my reply to Edi, I found a workaround and I'm happy that I can go back to the way that I used to work with tbnl. No complaints here.
But I find it funny that you repeatedly say that there _will_ be a cache miss using the debug-value macro. How do you know? Maybe you meant _potential_? I think it's incredibly painful to consider that scenario when one is writing lisp code. Even with years of c programming I have only come to see one or two examples of loop unrolling at work.
Have you done any loop unrolling in lisp? (maybe lisp compiler is smart enough to do that...) Do you declare all the types in your code? I think most people come to lisp for fast prototyping and implementation correctness. Lisp by default is fast enough for most things.
In your case, you'd still do (leak-variables *leak* ...) in a handler to capture the various variables you need, and it's not restricted to dynamic variables related to Hunchentoot. Then you'd evaluate (setf-leaked-variables *leak*) in the REPL and you're in the exact situation *debug-mode* was bringing you in.
Don't, your wish is just a macro away:
No it isn't. You're creating more work for me. In my toy example if I were to add a few more products in the cart using the browser, I'll need to evaluate (setf-leaked-variables *leak*) to have it reflect in *session*.
In fact I need to eval (setf-leaked-variables *leak*) everytime I change something with the browser. That would take away all of fun, wouldn't you agree?
-- Mac _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel