gmane.lisp.steel-bank.general

Re: traceback line numbers

Nikodemus Siivola — 2012-05-21T20:18:33


Yes,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: traceback line numbers

Faheem Mitha — 2012-05-21T06:25:52


On Mon, 21 May 2012, Nikodemus Siivola wrote:





Thanks Nikodemus, nice work. Since 1.0.57 has just been released, will 
this be in 1.0.58?

                                                        Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: traceback line numbers

Nikodemus Siivola — 2012-05-21T05:59:25


This particular bug is now fixed on git master as of this morning, and
will be in the next release -- but is not in 1.0.57 yet.

Cheers,

 -- nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: traceback line numbers

Rupert Swarbrick — 2012-05-18T22:24:26

Specifically, the following lines are in my ~/.sbclrc:

;; Tell SBCL that it's sources are in debian-land.
(sb-ext:set-sbcl-source-location (pathname "/usr/share/sbcl-source/"))

Presumably it's the same for you...
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: traceback line numbers

Nikodemus Siivola — 2012-05-18T20:13:38


Yes. :)


See SB-EXT:SET-SBCL-SOURCE-LOCATION.


Hard to tell, but I would strongly prefer not to add distro specific
bits to the manual. General advice on the subject is a different matter.

SET-SBCL-SOURCE-LOCATION is documented in the manual, but not mentioned
in the chapter on debugger.


We're always interested in patches. :) Documentation is very welcome.
See HACKING file in the distribution for patch submission guidelines.


Thank you.


The manual build assumes you have a freshly built SBCL in the same tree.

After running

  sh make.sh --fancy

successfully, you get output which tells you how to build the manual. Ie.

  cd doc/manual && make

make-doc.sh does the same thing pretty much, but is there for compatibility
with old scripts from time of the dinosaurs.


I think sooner or later we want to have a User Guide and a Reference Manual
as separate entities. Current manual strikes an uneasy balance between the two.


--snip--
2.4.1 Editor Integration

Though SBCL can be used running “bare”, the recommended mode of
development is with an editor connected to SBCL, supporting not only
basic lisp editing (paren-matching, etc), but providing among other
features an integrated debugger, interactive compilation, and
automated documentation lookup.

Currently SLIME1 (Superior Lisp Interaction Mode for Emacs) together
with Emacs is recommended for use with SBCL, though other options
exist as well.

SLIME can be downloaded from http://www.common-lisp.net/project/slime/.
--snap--

More could, and perhaps should be said, but I don't think it's a good
idea to expand on Slime in depth in the SBCL manual.


I'll let someone else field this. If no-one picks up the slack, remind
me next week.

Cheers,

 -- nikodemus (sorry about the short answers, in a bit of a rush)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: traceback line numbers

Faheem Mitha — 2012-05-18T18:57:57

Hi Nikodemus,

On Thu, 17 May 2012, Nikodemus Siivola wrote:


Sorry, I don't follow. I looked at
http://clhs.lisp.se/Body/d_optimi.htm.  I see the line

"(quality 3) can be abbreviated to quality."

which I missed in my first two readings of that section, so perhaps
you meant to write


or possibly

?




Ah. Ok. I've tried installing sbcl-source in Debian, which apparently
exists for this purpose, but haven't yet managed to get it to work. It
is looking in the wrong place - I need to get it to look in
/usr/share/doc/sbcl-source/ as opposed to
/build/buildd-sbcl_1.0.56.0-1-i386-KfmyJG/sbcl-1.0.56.0/src/. Any
tips?

This looks like something that could also be usefully documented in
the manual for Debian/Ubuntu users, who probably number a sizeable
proportion of SBCL users. However, I'm not attempting documentation
since I can't get it to work.


I see. Is this bug documented anywhere? I could not find it. I can report 
it if you want.

I don't know whether the SBCL developers are interested to
user-contributed patches to the manual, but I made one, mostly out of
your replies to my question. See below and attached. Some comments:

* The patch is just suggestions. Use or discard as you wish.

* I was unable to compile the manual to test the patch. I get

faheem< at >orwell:/usr/local/src/sbcl/sbcl/doc$ sh make-doc.sh
for module in :sb-md5 :sb-queue :sb-concurrency :sb-rotate-byte :sb-grovel :sb-sprof :sb-bsd-sockets :sb-cover :sb-posix; do \
                 test -f "../../contrib/"/`echo $module | tr -d :`/test-passed \
                 || { echo "The documented contrib $module seems \
                            to have failed its tests." && exit 1; } \
         done
The documented contrib :sb-md5 seems                            to have failed its tests.
make: *** [docstrings] Error 1

I tried similar commands like `make` in doc/manual, but get the same
error. This doesn't seem to have anything to do with my patch. I get
the same error with a pristine copy. Maybe the developers could
document how to build this?

* The SBCL manual is a bit "high level", at least for a beginning
user. In particular, it could use more concrete examples, e.g. in the
debugging section. Also, I think details of interactive sessions are
useful, again, for the beginner at least.

* I notice your manual doesn't mention SLIME anywhere. I don't know 
whether this is by design, but I added a reference to the SLIME debugger 
at what seemed like the natural place. An argument for including this is 
that SLIME is what most of your users will be using anyway.

* I don't understand the last section in that source level debugging
   section, namely

#####################################################################

If enclosing source is printed by giving an argument to
< at >command{source} or < at >command{vsource}, then the actual source form is
marked by wrapping it in a list whose first element is
< at >samp{#:***HERE***}.  In the previous example, < at >code{source 1} would
print:

< at >example
; File: /usr/me/mystuff.lisp

(DEFUN FOO ()
   (#:***HERE***
    (MYMAC))
   ...)
< at >end example

#######################################################################

What is the use of this feature? What happens differently for different 
versions of the argument?

                                                         Regards, Faheem

[Snip SBCL interpreter session].

diff --git a/doc/manual/debugger.texinfo b/doc/manual/debugger.texinfo
index 82e6b7d..9cef672 100644
--- a/doc/manual/debugger.texinfo
+++ b/doc/manual/debugger.texinfo
< at >< at > -654,6 +654,62 < at >< at > return, then the < at >command{source} command would print:
  Note that the macro use was printed, not the actual function call form,
  < at >code{(myfun)}.

+Here is a more concrete example not involving a macro. Suppose the file
+< at >file{/usr/me/foo.lisp} looked like this:
+
+< at >lisp
+(defun foo (x)
+  (declare (optimize debug))
+  (let* ((y (- x x))
+         (z (/ x y)))
+    (+ y z)))
+< at >end lisp
+
+Then we can run the following commands to get the source form. We first
+compile, load and execute < at >code{(foo)}, and then use the
+< at >command{source} command as before.
+
+< at >example
+* (compile-file "foo.lisp")
+* (load *)
+* (foo 1)
+
+debugger invoked on a DIVISION-BY-ZERO in thread
+#<THREAD "main thread" RUNNING {1003600EA3}>:
+  arithmetic error DIVISION-BY-ZERO signalled
+Operation was SB-KERNEL::DIVISION, operands (1 0).
+
+Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
+
+restarts (invokable by number or by possibly-abbreviated name):
+  0: [ABORT] Exit debugger, returning to top level.
+
+(SB-KERNEL::INTEGER-/-INTEGER 1 0)
+0] source
+
+#<SB-DI::COMPILED-DEBUG-FUN SB-KERNEL::INTEGER-/-INTEGER> has no
+debug-block information.
+0] d
+(FOO 1)
+1] source
+
+; file: /Users/nikodemus/tmp/foo.lisp
+
+(/ X Y)
+1]
+< at >end example
+
+For the form to be printed, the source must be compiled with a debugger
+optimization level greater than or equal to 2.
+
+This command does not work currently for code defined at the REPL or via
+< at >code{eval}. See bug >>bug number here<<.
+
+An alternative to using the source command is to use the SLIME debugger
+sldb within SLIME. Pressing v on a frame will make the cursor jump to
+the location of the form which is giving the error in the source, and
+while the key is depressed the source form will be highlighted.
+
  If enclosing source is printed by giving an argument to
  < at >command{source} or < at >command{vsource}, then the actual source form is
  marked by wrapping it in a list whose first element isdiff --git a/doc/manual/debugger.texinfo b/doc/manual/debugger.texinfo
index 82e6b7d..9cef672 100644
--- a/doc/manual/debugger.texinfo
+++ b/doc/manual/debugger.texinfo
< at >< at > -654,6 +654,62 < at >< at > return, then the < at >command{source} command would print:
 Note that the macro use was printed, not the actual function call form,
 < at >code{(myfun)}.
 
+Here is a more concrete example not involving a macro. Suppose the file
+< at >file{/usr/me/foo.lisp} looked like this:
+
+< at >lisp
+(defun foo (x)
+  (declare (optimize debug))
+  (let* ((y (- x x))
+         (z (/ x y)))
+    (+ y z)))
+< at >end lisp
+
+Then we can run the following commands to get the source form. We first
+compile, load and execute < at >code{(foo)}, and then use the
+< at >command{source} command as before.
+
+< at >example
+* (compile-file "foo.lisp")
+* (load *)
+* (foo 1)
+
+debugger invoked on a DIVISION-BY-ZERO in thread
+#<THREAD "main thread" RUNNING {1003600EA3}>:
+  arithmetic error DIVISION-BY-ZERO signalled
+Operation was SB-KERNEL::DIVISION, operands (1 0).
+
+Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
+
+restarts (invokable by number or by possibly-abbreviated name):
+  0: [ABORT] Exit debugger, returning to top level.
+
+(SB-KERNEL::INTEGER-/-INTEGER 1 0)
+0] source
+
+#<SB-DI::COMPILED-DEBUG-FUN SB-KERNEL::INTEGER-/-INTEGER> has no
+debug-block information.
+0] d
+(FOO 1)
+1] source
+
+; file: /Users/nikodemus/tmp/foo.lisp
+
+(/ X Y)
+1]
+< at >end example
+
+For the form to be printed, the source must be compiled with a debugger
+optimization level greater than or equal to 2.
+
+This command does not work currently for code defined at the REPL or via
+< at >code{eval}. See bug >>bug number here<<.
+
+An alternative to using the source command is to use the SLIME debugger
+sldb within SLIME. Pressing v on a frame will make the cursor jump to
+the location of the form which is giving the error in the source, and
+while the key is depressed the source form will be highlighted.
+
 If enclosing source is printed by giving an argument to
 < at >command{source} or < at >command{vsource}, then the actual source form is
 marked by wrapping it in a list whose first element is
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: Drawing a call graph of a block of lisp code (general lisp question)

David Creelman — 2012-05-17T06:53:51

Hi Nikodemus,
Thanks for that. That did the trick. It looks like Debian has built
with --fancy as there is a lot of stuff that comes back from who-calls.

I threw together some code that lets me build a call graph, I'm including the
guts of it here in case someone else would like to use it or improve it.

This will produce a graphviz style call directed graph.

For small bits of code, it may be useful. (My code has got quite
large, making a very dense, large graph, so I may need to rethink how to 
do this). Nonetheless, being able to see where stuff is called is
very useful to me, so thanks. 

(defun clean-symbol (sym)
  (substitute #\2 #\> (remove #\- (format nil "~A" sym))))

(let ((lst ())
      (fn-hash (make-hash-table))
      (package-name "MY-PACKAGE-NAME"))
  (do-symbols (jj package-name)
    (when (eq (find-package package-name) (symbol-package jj))
      (progn 
(mapcar (lambda (n) 
  (if (not (member (car n) (gethash jj fn-hash)))
      (setf (gethash jj fn-hash) (push (car n) 
       (gethash jj
fn-hash)))))
(sb-introspect:who-calls jj))
(push jj lst))))

;  (maphash (lambda (fun used) (format t "~A is used in ~A~%" fun used)) fn-hash)
  (format t "digraph mytest {~%")
  (maphash (lambda (fun used)
     (loop for x in used
do
  (format t "~A -> ~A;~%" (clean-symbol x) (clean-symbol fun))))
   fn-hash)
  (format t "}~%"))

Cheers
David


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: traceback line numbers

Nikodemus Siivola — 2012-05-17T11:11:44


It's in the standard:

  (declare (optimize foo)) == (declare (optimize (debug 3)))


Yes, that was referring the build-in debugger as distinct from Slime.
The one you get if you run SBCL in the terminal.


That was the frame for /. You don't have SBCL sources present or
configured properly, so it could not jump to the source for /.


Yes.


Yes.


That's because showing the source doesn't work currently for things
defined at the REPL or via EVAL -- it's a known bug.

[nikodemus< at >delirium:~/tmp]
(defun foo (x)
 (declare (optimize (debug 2)))
 (let* ((y (- x x))
        (z (/ x y)))
   (+ y z)))
[nikodemus< at >delirium:~/tmp]
This is SBCL 1.0.56.56.master.1-b568ed0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "foo.lisp")

; compiling file "/Users/nikodemus/tmp/foo.lisp" (written 17 MAY 2012
01:56:03 PM):
; compiling (DEFUN FOO ...)

; /Users/nikodemus/tmp/foo.fasl written
; compilation finished in 0:00:00.026
#P"/Users/nikodemus/tmp/foo.fasl"
NIL
NIL
* (load *)

T
* (foo 1)

debugger invoked on a DIVISION-BY-ZERO in thread
#<THREAD "main thread" RUNNING {1003600EA3}>:
  arithmetic error DIVISION-BY-ZERO signalled
Operation was SB-KERNEL::DIVISION, operands (1 0).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL::INTEGER-/-INTEGER 1 0)
0] source

#<SB-DI::COMPILED-DEBUG-FUN SB-KERNEL::INTEGER-/-INTEGER> has no
debug-block information.
0] d
(FOO 1)
1] source

; file: /Users/nikodemus/tmp/foo.lisp

(/ X Y)
1]

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: traceback line numbers

Faheem Mitha — 2012-05-16T04:37:51

Hi Nikodemus,

Thanks for the helpful reply. See comments below.

On Tue, 15 May 2012, Nikodemus Siivola wrote:






Ok, I tried this. You mention debug 2, but your example does not use
that, so I added it. Maybe debug 2 is the default, but if so, that is
not mentioned, at least not in the SBCl user manual. However, I get
exactly the same results as listed below with just 'debug'.

The following is with SLIME. I got the following backtrace in sldb.

Backtrace:
   0: (SB-KERNEL::INTEGER-/-INTEGER 1 0)
   1: (FOO 1)
   2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO 1) #<NULL-LEXENV>)
   3: (EVAL (FOO 1))

By "give the SOURCE command in the debugger", I assume you mean the
SBCL debugger, which is distinct from sldb, right? So, continuing with
sldb...

I pressed v with the cursor on top of frame 0. I got the following
curious error message in the minibuffer

Error: failed to find the WRITE-DATE of
/build/buildd-sbcl_1.0.56.0-1-i386-KfmyJG/sbcl-1.0.56.0/src/code/numbers.lisp:
          No such file or directory

When I put the cursor on top of frame 1, and pressed v I got

(foo 1)

in the minibuffer, and the cursor (not in focus) in the source file
jumped here

       (z (/ x y)))
          ^

namely, where the division by zero error occurs, and the form (/ x y)
briefly flashed yellow.

I assume that the change in position of the cursor in the source file
and the flashing is the main intended effect.

Without the debug, the cursor jumped to the beginning of the function,
and the whole function flashed yellow.

Anyway, if SLIME can reliably show me exactly where the error occurs
by jumping there (I haven't tested it on any complicated code), I
guess the source code line is not needed.

I tried using the SBCL debugger directly from the SBCL interpreter
(see session below) but the SOURCE command did not show me anything. I
got the message "The source path no longer exists."

                                                        Regards, Faheem

######################################################################

faheem< at >orwell[default branch:rev 35]:~/lisp$ rlwrap sbcl
This is SBCL 1.0.56.0.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
(defun foo (x)
   (declare (optimize (debug 2)))
   (let* ((y (- x x))
          (z (/ x y)))
     (+ y z)))

FOO
* (foo 1)

debugger invoked on a DIVISION-BY-ZERO in thread
#<THREAD "initial thread" RUNNING {AB19809}>:
   arithmetic error DIVISION-BY-ZERO signalled
Operation was SB-KERNEL::DIVISION, operands (1 0).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL::INTEGER-/-INTEGER 1 0)
0] down 1
(FOO 1)
1] SOURCE


debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "initial thread" RUNNING {AB19809}>:
   The source path no longer exists.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Reduce debugger level (to debug level 1).
   1:         Exit debugger, returning to top level.

(SB-DEBUG::CODE-LOCATION-SOURCE-FORM #<SB-DI::COMPILED-CODE-LOCATION FOO> 0)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: traceback line numbers

Nikodemus Siivola — 2012-05-15T05:25:37


SBCL doesn't save line numbers but relative source locations (at
sufficiently high debug level.) Source location refers to logical
position in the file: Nth toplevel form, subform N2, subsubform N3,
etc.

(defun foo (x)
  (declare (optimize debug))
  (let* ((y (- x x))
         (z (/ x y)))
    (+ y z)))

compile this, evaluate (foo 1) and give the SOURCE command in he
debugger and you'll see /exactly/ where the error occurs -- or you can
use v in the slime debugger: move on top of the frame you want to
investigate first.

(The you currently need debug 2 or greater for this information to be
saved. Perhaps that decision should be revisited. Doing that would be
relatively easy -- but needs measurements to see effect on code sizes
for large systems. It might even be that advantages of source
locations vs lines numbers should be revisited -- but doing that is a
substantial enough a change that unless a volunteer shows up and does
all the work it is unlikely to happen in near future.)

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

traceback line numbers

Faheem Mitha — 2012-05-14T23:33:28

Hi,

Maybe I'm missing something, but... why aren't line numbers of the source 
file given as part of the SBCL runtime traceback? I'm running SBCL inside 
SLIME, but the tracebacks look like they are output directly from SBCL, so 
I doubt SLIME is affecting something here. The tracebacks do mention the 
function that is causing the error, but in cases where that function is 
called several times, it would definitely be most helpful to have a line 
number.

I notice the line numbers *are* given for compilation errors, so perhaps 
this is a language or implementation limitation? I don't know much about 
CL's compilation model, except that it compiles stuff down to machine 
code. If possible, I would of course like to have the line numbers.

                                                          Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: improving error messages for concatenate

Faheem Mitha — 2012-05-13T20:02:42


On Sun, 13 May 2012, Pascal J. Bourguignon wrote:


Oh, I see. A repository for proposed standard documents. Interesting. But 
quiet.

                                                           Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: improving error messages for concatenate

Pascal J. Bourguignon — 2012-05-13T16:57:11


CDR - Common Lisp Document Repository
http://cdr.eurolisp.org/

Re: Drawing a call graph of a block of lisp code (general lisp question)

Nikodemus Siivola — 2012-05-13T09:38:44

See:

 sb-introspect:who-calls
 sb-introspect:find-function-callees

The first should be accurate and include inlined call sites. The
latter only knows about full calls. You can also build SBCL with
--fancy to get XREF data for internals as well.

Cheers,

 -- nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: Drawing a call graph of a block of lisp code(general lisp question)

Ph. Marek — 2012-05-13T09:14:47

Hello David,

...
Slime/swank have cross-reference queries, so I wouldn't be surprised if they'd 
give you a complete call-graph, too.

If they don't (yet), it would be easy to do from the callers-of and callees 
information.


Please keep me/us updated ... I'd be interested in that as well.


Regards,

Phil

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Drawing a call graph of a block of lisp code (generallisp question)

David Creelman — 2012-05-13T08:58:54

Hi,
I have a bunch of lisp code that I want to draw the call graph of (I'm
thinking of generating something with graphviz).

Has someone written something that will look for all of the function
calls in a defun? I imagine a recursive function called from a macro
could do this. I've had a go at writing it with loop, but I'm not sure
how to get it to recurse over subtrees of calls. Small confession, I'm
not real good at recursive functions. The recursive function I wrote
seemed to always end up working like flatten.

It would be nice to be able to do something like

(callgraph graph1
(defun caller (a b)
  (fun1 a)
  (fun2 b))

(defun fun1 (a)
  (print a))

(defun fun2 (a)
  (print a)))

Which would generate
digraph graph1 {
  caller -> fun1
  caller -> fun2 }

... I'm away from graphviz doco as I write this, so I may have got the
syntax slightly wrong, but hopefully this gives the idea.


Does anyone know of any modules that would do this for me?

Thanks
David

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: improving error messages for concatenate

Faheem Mitha — 2012-05-13T08:34:11


On Sun, 13 May 2012, Nikodemus Siivola wrote:


Hi Nikodemus,

Yes, I've got a Launchpad account. I even reported one SBCL bug there; 
which you fixed. Ok, I'll direct such comments there in the future.

                                                       Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: improving error messages for concatenate

Nikodemus Siivola — 2012-05-13T08:30:09


Yes, we are. They're a low priority mostly, though, but they're also
excellent introductory tasks for people new to SBCL hacking.

Launchpad is a better place for them than this list, though.

  https://launchpad.net/sbcl

If you don't want to get a Launchpad userid, you can also send mail to
sbcl-bugs, which doesn't require subscription. (Reporting directly to
Launchpad is much preferred, though -- less work for us.)

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Re: improving error messages for concatenate

Faheem Mitha — 2012-05-13T08:02:34


On Sun, 13 May 2012, Pascal J. Bourguignon wrote:


Hi Pascal,

Thanks for the reply, and the detailed explanation. I should have guessed 
that there was some reason the errors showed up this way. Does this mean 
the SBCL developers are not interested in comments about error messages? I 
don't want to spam the list pointlessly. I ask since I've seen SBCL errors 
which much more obscure than this, and might comment on them on this list 
as I came across them. They are still much better than, for example, C++ 
template error messages, though.

BTW, what does CDR mean? The first thing that comes to mind is "something 
Defect Report", but that doesn't quite fit.

Also, I don't get the significance of


Can you elaborate? Please excuse my ignorance.

                                                            Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: improving error messages for concatenate

Pascal J. Bourguignon — 2012-05-13T01:40:51


It may be trivial but it represents a lot of work:

1- it's not limited to concatenate of course.  Each operator in CL would
   benefit from newbie friendly error reporting.

2- it's not limited to sbcl all implementations do the same thing.

Namely, they defer most of the type checking (and in general, parameter
validation), to the lower level functions called.  This is sound lisp
engineering since this avoid testing for the types/validity of the
parameter at each function call.  But indeed it has the defect that the
errors are not detected early and in the most meaningful context.  It
has also the problem that implementation details changing, the exact
error reported is not the same from one implementation to another.  This
is related to the fact that very few CL operators are defined to signal
specific conditions (at very few and coarse conditions are defined).


There's matter for a nice CDR here:

- specifying a complete ontology of conditions for the CL package.

- specifying precisely for each CL operator, what condition should be
  signaled in what situation.


So, passing a string instead of a sequence type as first argument of
concatenate is indeed a type error (that's what most implementations
signal, ccl signals a subclass of program-error and allegro a subclass
of error (all are confomring:

    An error is signaled if the result-type is neither a recognizable
    subtype of list, nor a recognizable subtype of vector.

)), but the CDR could specify a more precise condition, a subclass of
type-error that would report exactly the newbie-friendly meaning:


(define-condition sequence-type-expected-error (type-error)
 ((function  :initarg :function  :reader sequence-type-expected-error-function)
  (parameter :initarg :parameter :reader sequence-type-expected-error-parameter)
  (datum     :initarg :datum     :reader sequence-type-expected-error-datum))
 (:report (lambda (err stream)
             (format stream
                    "Function ~A expected a subtype of sequence ~
                     in its ~:R parameter, instead it got the ~A ~S"
                    (sequence-type-expected-error-function err)
                    (sequence-type-expected-error-parameter err)
                    (type-of (sequence-type-expected-error-datum err))
                    (sequence-type-expected-error-datum err)))))


So:

1- you'd get this error message:

        Function concatenate expected a subtype of sequence in its first
        parameter, instead it got the (simple-base-string 3) "Abc"    

2- programs could recover more precisely from errors signaled by CL
   operators.


But again, the same work has to be done for all the CL operators (and
hopefully implemented by all implementations).



[pjb< at >kuiper :0 ~]$ clall '(concatenate "Abc" "def")'



Armed Bear Common Lisp:
========================================================================
Implementation: Armed Bear Common Lisp 1.0.1 on X86-64

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<TYPE-ERROR {5585C0DE}>
  The value "Abc" is not of type SYMBOL.
wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value


International Allegro CL Free Express Edition:
========================================================================
Implementation: International Allegro CL Free Express Edition 8.2 [Linux (x86)] (Sep 11, 2010 7:36) on x86

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<SIMPLE-ERROR < at > #x20754a3a>
  "Abc" is an invalid output type specification.
wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value


Clozure Common Lisp:
========================================================================
Implementation: Clozure Common Lisp Version 1.8-r15286M  (LinuxX8664) on x86_64

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<CCL::INVALID-TYPE-SPECIFIER #x3020007EB54D>
  Invalid type specifier: "Abc" .
wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value


CLISP:
========================================================================
Implementation: CLISP 2.49+ (2010-07-17) (built 3542867425) (memory 3542867673) on X86_64

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<SIMPLE-TYPE-ERROR #x000333FBD7A8>
  
There are no sequences of type "Abc"

wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value


CMU Common Lisp:
========================================================================
Implementation: CMU Common Lisp 20b (20B Unicode) on X86

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<TYPE-ERROR {581F5FCD}>
  Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
     "Abc" is not of type (OR CONS SYMBOL EXTENSIONS:INSTANCE)
wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value


SBCL:
========================================================================
Implementation: SBCL 1.0.55 on X86-64

Reading of: "(concatenate \"Abc\" \"def\")"
signaled no error

Evaluation of: (CONCATENATE "Abc" "def")
signaled the following error:
  #<TYPE-ERROR expected-type: (OR CONS SYMBOL SB-KERNEL:INSTANCE) datum: "Abc">
  The value "Abc" is not of type (OR CONS SYMBOL SB-KERNEL:INSTANCE).
wrote nothing on *ERROR-OUTPUT*
wrote nothing on *STANDARD-OUTPUT*
returned no value

========================================================================

[pjb< at >kuiper :0 ~]$

improving error messages for concatenate

Faheem Mitha — 2012-05-12T19:15:48

Hi,

I don't know if the SBCL developers are interested in this sort of thing. 
It may be too trivial. But, consider...

CL-USER> (concatenate  "foo" "bar")
; Evaluation aborted on #<TYPE-ERROR expected-type: (OR CONS SYMBOL 
SB-KERNEL:INSTANCE) datum: "foo">.

Traceback

The value "foo"
is not of type
   (OR CONS SYMBOL SB-KERNEL:INSTANCE).
    [Condition of type TYPE-ERROR]

Restarts:
  0: [RETRY] Retry SLIME REPL evaluation request.
  1: [*ABORT] Return to SLIME's top level.
  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" 
RUNNING {C208B11}>)

Backtrace:
   0: (CONCATENATE "foo" "bar")[:OPTIONAL]
   1: (CONCATENATE "foo")[:EXTERNAL]
   2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONCATENATE "foo" "bar") 
#<NULL-LEXENV>)
   3: (EVAL (CONCATENATE "foo" "bar"))
  --more--

This message gives no indication that the user has got it nearly correct, 
namely that is should have been

  (concatenate 'string "foo" "bar")

so, needs to include a type specifier. Also, this is not really consistent 
with the error for the list case, which actually is a much better error 
message.

CL-USER> (concatenate  (list 1 2) (list 3 4))
; Evaluation aborted on #<SIMPLE-ERROR "bad thing to be a type specifier: 
~S" {C15AE29}>.

bad thing to be a type specifier: (1 2)
    [Condition of type SIMPLE-ERROR]

Restarts:
  0: [RETRY] Retry SLIME REPL evaluation request.
  1: [*ABORT] Return to SLIME's top level.
  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" 
RUNNING {C208B11}>)

Backtrace:
   0: (SB-KERNEL:VALUES-SPECIFIER-TYPE (1 2))
   1: (SB-KERNEL:SPECIFIER-TYPE (1 2))
   2: (CONCATENATE (1 2) (3 4))
   3: (CONCATENATE (1 2))[:EXTERNAL]
   4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONCATENATE (LIST 1 2) (LIST 3 4)) 
#<NULL-LEXENV>)
   5: (EVAL (CONCATENATE (LIST 1 2) (LIST 3 4)))

If anyone wants me to, I can report this as a bug.

                                                        Regards, Faheem

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/