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