I have changed the example to

(declaim
 (optimize (debug 3) (speed 0) (safety 3)))

(defun provide-runtime-value ()
  (sxhash (random 100000)))

(defun generate-lambda (x)
  `(lambda ()
     (let ((y ,(+ x 7))
       (z (provide-runtime-value)))
       (break)
       (print y)
       (print (+ z 4)))))

(defun test ()
  (let ((lm (generate-lambda 8)))
    (funcall (compile nil lm))))

but it still shows no local variables.

Regards,
Roman

2011/2/14 Pascal J. Bourguignon <pjb@informatimago.com>
Roman Marynchak <roman.marynchak@gmail.com> writes:

> Hello,
>
>  I want to debug the code which is generated and compiled during the program execution. While there is a workaround (I can dump the code into a file and load it on the fly), I would like to ask for a more
> elegant solution (if any).
>
>   The next very simplified code demonstrates the real-life problem:
>
> (declaim (optimize (debug 3) (speed 0) (safety 3)))
>
> (defun generate-lambda (x)
>   `(lambda ()
>      (let ((y ,(+ x 7))
>             (z ,(* x x)))
>        (break)
>        (print y)
>        (print z))))
>
> (defun test ()
>   (let ((lm (generate-lambda 8)))
>     (funcall (compile nil lm))))
>
> After this code is compiled and loaded, I evaluate (test) and SLIME
> shows that there is no information about the locals in the generated
> lambda:
>
> Backtrace:
>   0: (BREAK "break")
>   1: ((LAMBDA ()))
>       [No Locals]
>   2: (TEST)
>       Locals:
>         LM = (LAMBDA () ..)
>   3: (SB-INT:SIMPLE-EVAL-IN-LEXENV (TEST) #<NULL-LEXENV>)
>   4: ((LAMBDA ()))
>
> Is there any way to make these local variables visible?

My guess is that despite (debug 3), the compiler optimize out the
useless variables.

My advice would be to make use of the variable, ie. to mutate them:

 (defun generate-lambda (x)
  `(lambda ()
     (let ((y ,(+ x 7))
           (z ,(* x x)))
       (break)
       (print y)
       (print z)
       (setf y (+ y z)
             z (- y z)
             y (- y z)))))



--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Sbcl-help mailing list
Sbcl-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help