<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general">
    <title>gmane.lisp.steel-bank.general</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3542"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3541"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3540"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3539"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3538"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3537"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3536"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3535"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3534"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3533"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3532"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3531"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3530"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3529"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3528"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3527"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3526"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3525"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3524"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3523"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3542">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3542</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-21T20:18:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3541">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3541</link>
    <description>&lt;pre&gt;

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/
&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-21T06:25:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3540">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3540</link>
    <description>&lt;pre&gt;

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/
&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-21T05:59:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3539">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3539</link>
    <description>&lt;pre&gt;
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&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
&lt;/pre&gt;</description>
    <dc:creator>Rupert Swarbrick</dc:creator>
    <dc:date>2012-05-18T22:24:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3538">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3538</link>
    <description>&lt;pre&gt;

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 &amp;amp;&amp;amp; 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”, t&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-18T20:13:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3537">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3537</link>
    <description>&lt;pre&gt;
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-contrib&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-18T18:57:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3536">
    <title>Re: Drawing a call graph of a block of lisp code (general lisp question)</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3536</link>
    <description>&lt;pre&gt;
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 #\&amp;gt; (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) 
       &lt;/pre&gt;</description>
    <dc:creator>David Creelman</dc:creator>
    <dc:date>2012-05-17T06:53:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3535">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3535</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;delirium:~/tmp]
(defun foo (x)
 (declare (optimize (debug 2)))
 (let* ((y (- x x))
        (z (/ x y)))
   (+ y z)))
[nikodemus&amp;lt; at &amp;gt;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 &amp;lt;http://www.sbcl.org/&amp;gt;.

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-&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-17T11:11:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3534">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3534</link>
    <description>&lt;pre&gt;
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) #&amp;lt;NULL-LEXENV&amp;gt;)
   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 &lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-16T04:37:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3533">
    <title>Re: traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3533</link>
    <description>&lt;pre&gt;

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
&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-15T05:25:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3532">
    <title>traceback line numbers</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3532</link>
    <description>&lt;pre&gt;
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 ha&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-14T23:33:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3531">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3531</link>
    <description>&lt;pre&gt;

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/
&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-13T20:02:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3530">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3530</link>
    <description>&lt;pre&gt;

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

&lt;/pre&gt;</description>
    <dc:creator>Pascal J. Bourguignon</dc:creator>
    <dc:date>2012-05-13T16:57:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3529">
    <title>Re: Drawing a call graph of a block of lisp code (general lisp question)</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3529</link>
    <description>&lt;pre&gt;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/
&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-13T09:38:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3528">
    <title>Re: Drawing a call graph of a block of lisp code(general lisp question)</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3528</link>
    <description>&lt;pre&gt;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/
&lt;/pre&gt;</description>
    <dc:creator>Ph. Marek</dc:creator>
    <dc:date>2012-05-13T09:14:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3527">
    <title>Drawing a call graph of a block of lisp code (generallisp question)</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3527</link>
    <description>&lt;pre&gt;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 -&amp;gt; fun1
  caller -&amp;gt; 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

-------------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>David Creelman</dc:creator>
    <dc:date>2012-05-13T08:58:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3526">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3526</link>
    <description>&lt;pre&gt;

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/
&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-13T08:34:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3525">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3525</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help
&lt;/pre&gt;</description>
    <dc:creator>Nikodemus Siivola</dc:creator>
    <dc:date>2012-05-13T08:30:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3524">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3524</link>
    <description>&lt;pre&gt;

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 la&lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-13T08:02:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3523">
    <title>Re: improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3523</link>
    <description>&lt;pre&gt;

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 op&lt;/pre&gt;</description>
    <dc:creator>Pascal J. Bourguignon</dc:creator>
    <dc:date>2012-05-13T01:40:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.lisp.steel-bank.general/3522">
    <title>improving error messages for concatenate</title>
    <link>http://permalink.gmane.org/gmane.lisp.steel-bank.general/3522</link>
    <description>&lt;pre&gt;
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&amp;gt; (concatenate  "foo" "bar")
; Evaluation aborted on #&amp;lt;TYPE-ERROR expected-type: (OR CONS SYMBOL 
SB-KERNEL:INSTANCE) datum: "foo"&amp;gt;.

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 (#&amp;lt;THREAD "repl-thread" 
RUNNING {C208B11}&amp;gt;)

Backtrace:
   0: (CONCATENATE "foo" "bar")[:OPTIONAL]
   1: (CONCATENATE "foo")[:EXTERNAL]
   2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONCATENATE "foo" "bar") 
#&amp;lt;NULL-LEXENV&amp;gt;)
   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 &lt;/pre&gt;</description>
    <dc:creator>Faheem Mitha</dc:creator>
    <dc:date>2012-05-12T19:15:48</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.steel-bank.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.steel-bank.general</link>
  </textinput>
</rdf:RDF>

