[hunchentoot-devel] resurrect tbnl's debug-value macro?

[Andrei Stebakov]

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 at gmail.com> wrote:
>
> On 5/4/07, Pierre THIERRY <nowhere.man at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20070504/cbf256af/attachment.html>