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.
<br><br>Andrew<br><br><div><span class="gmail_quote">On 5/4/07, <b class="gmail_sendername">Mac Chan</b> <<a href="mailto:emailmac@gmail.com">emailmac@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/4/07, Pierre THIERRY <<a href="mailto:nowhere.man@levallois.eu.org">nowhere.man@levallois.eu.org</a>> wrote:<br>> Except it's now more flexible, and there's a conditional branching and a<br>> cache miss that won't go in Hunchentoot's critical path.
<br><br>Not that I insist we put something something redundant into<br>Hunchentoot's critical path, as stated in my reply to Edi, I found a<br>workaround and I'm happy that I can go back to the way that I used to<br>
work with tbnl. No complaints here.<br><br>But I find it funny that you repeatedly say that there _will_ be a<br>cache miss using the debug-value macro. How do you know? Maybe you<br>meant _potential_? I think it's incredibly painful to consider that
<br>scenario when one is writing lisp code. Even with years of c<br>programming I have only come to see one or two examples of loop<br>unrolling at work.<br><br>Have you done any loop unrolling in lisp? (maybe lisp compiler is
<br>smart enough to do that...) Do you declare all the types in your code?<br>I think most people come to lisp for fast prototyping and<br>implementation correctness. Lisp by default is fast enough for most<br>things.<br>
<br>> In your case, you'd still do (leak-variables *leak* ...) in a handler to<br>> capture the various variables you need, and it's not restricted to<br>> dynamic variables related to Hunchentoot. Then you'd evaluate
<br>> (setf-leaked-variables *leak*) in the REPL and you're in the exact<br>> situation *debug-mode* was bringing you in.<br>><br>> Don't, your wish is just a macro away:<br><br>No it isn't. You're creating more work for me. In my toy example if I
<br>were to add a few more products in the cart using the browser, I'll<br>need to evaluate (setf-leaked-variables *leak*) to have it reflect in<br>*session*.<br><br>In fact I need to eval (setf-leaked-variables *leak*) everytime I
<br>change something with the browser. That would take away all of fun,<br>wouldn't you agree?<br><br>-- Mac<br>_______________________________________________<br>tbnl-devel site list<br><a href="mailto:tbnl-devel@common-lisp.net">
tbnl-devel@common-lisp.net</a><br><a href="http://common-lisp.net/mailman/listinfo/tbnl-devel">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br></blockquote></div><br>