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