headers
Tamas Papp | 6 Oct 2011 15:03
Picon

SBCL source location

Hi,

I am using the debian packages for sbcl (and sbcl-source), and I have
a problem with SLIME finding the definition for functions defined in
the SBCL source.  Eg if I do M-. on copy-seq, the xref buffer starts
with "(No location)", and *slime-events* reports things like

 (:error "Error: failed to find the WRITE-DATE of
/build/sbcl-a405QP/sbcl-1.0.51.0/src/code/seq.lisp:\n         No such file or directory"))

Is there a way I can tell an SBCL compiled by somebody else that its
sources are located in /usr/share/sbcl-source?

Thanks,

Tamas

PS.: Should I report this as a bug?
PS.: $ dpkg -l 'sbcl*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                   Version                           Description
+++-======================================-=================================-==============================================================================
ii  sbcl                                   2:1.0.51.0-1                      Common Lisp compiler and development system
un  sbcl-common                            <none>                            (no description available)
ii  sbcl-doc                               2:1.0.51.0-1                      Documentation for Steel Bank Common Lisp
un  sbcl-fasl-loader-78                    <none>                            (no description available)
ii  sbcl-source                            2:1.0.51.0-1                      Source code files for SBCL
(Continue reading)

Permalink | Reply | 2 comments |
headers
Didier Verna | 6 Oct 2011 16:03
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

Re: SBCL source location

Tamas Papp <tkpapp <at> gmail.com> wrote:

> I am using the debian packages for sbcl (and sbcl-source), and I have
> a problem with SLIME finding the definition for functions defined in
> the SBCL source.

  That's not an answer to your question, but given the reactivity of
Debian these days, I think you'd be better off compiling your own
version of SBCL anyways. It's quite simple.

--

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Permalink | Reply | 0 comments |
headers
Peter Keller | 7 Oct 2011 05:42
Picon
Favicon

Re: rounding issue

On Fri, Sep 02, 2011 at 08:39:11PM +0100, Christophe Rhodes wrote:
> Peter Keller <psilord <at> cs.wisc.edu> writes:
> no, sorry, that line should still be there but return "shifted" instead
> of "(1+ shifted)".  So: if the fractional bits are bigger than 0.5; then
> use (1+ shifted); if they're smaller than 0.5, use shifted; if they are
> exactly 0.5 then if the shifted value is odd, use (1+ shifted) otherwise
> use shifted.  Proper round-to-even logic, not at all confusing.

Hello,

So it turns out your fix isn't quite right:

Linux > sbcl
This is SBCL 1.0.51.41-6113d10, 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.

;; This works
* (round (* 10.004939019999991d0 1e8))

1000493902
-8.344650268554688d-7

;; this works too.
* (round 100000000000000.6d0)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 7 Oct 2011 10:12
Favicon

Re: rounding issue

Peter Keller <psilord <at> cs.wisc.edu> writes:

> * (round 100000000000000.6)
>
> debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING
>                                               {AAA58B1}>:
>   The value NIL is not of type INTEGER.

Um, how did that happen?  There's a missing alternative branch in the IF
in the binding of ROUNDED in %unary-round?  People shouldn't let me
drive.

It should read
  (if (minusp exp)
      (... complicated fractional-bits stuff ...)
      shifted)
as any fule kno.

Sorry.  Juho, can I slip this in under your freeze radar?

Cheers,

Christophe

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matt Kaufmann | 19 Oct 2011 01:08
Picon

Problem with top-level prompt and dispatch-macro-character

Hi --

Consider the following simple reader extension:

(defun sharp-bang-read (stream char n)
    (declare (ignore char n))
    (read stream)
    (read stream))
(set-dispatch-macro-character #\# #\! #'sharp-bang-read)

Now suppose I issue the following:

#! 3 4

I'd expect the reader to read 4, and it does.  But with SBCL, I don't
get the prompt back until I hit <return>.  (I used SBCL 1.0.51 on a
Mac and SBCL 1.0.49 on Linux.)

I tried Allegro CL, CCL, CLISP, GCL, and Lispworks, and didn't have
this problem with those Lisps.  I did however have this problem with
CMUCL, perhaps not surprisingly given SBCL's heritage (as I understand
it).

Is this an SBCL bug, or am I doing something wrong?

Below is a sequence of inputs followed by a corresponding log, in case
it's helpful.  In the log, I've inserted <return> to show where I had
to hit that key to get back to the top-level prompt.

==============================
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stig Hemmer | 19 Oct 2011 01:39
Picon

Re: Problem with top-level prompt and dispatch-macro-character

The problem is that the last (READ STREAM) reads the following newline
and discards it.  The REPL then needs another newline to end the line.

This is in fact according to spec, here is what the description of READ says:

When *read-suppress* is false, read throws away the delimiting
character required by certain printed representations if it is a
whitespace[2] character; but read preserves the character (using
unread-char) if it is syntactically meaningful, because it could be
the start of the next expression.

You can use READ-PRESERVING-WHITESPACE instead to get the effect you want.

Stig Hemmer

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
Permalink | Reply | 1 comment |
headers
Matt Kaufmann | 19 Oct 2011 02:01
Picon

Re: Problem with top-level prompt and dispatch-macro-character

Thank you for the quick reply!  That solves my problem.

Actually, your reply led me to read the spec more carefully, and I
realized that since I'm calling read recursively, I should probably
use recursive-p = t, thus:

(defun sharp-bang-read (stream char n)
  (declare (ignore char n))
  (read stream t nil t)
  (read stream t nil t))

That solves the problem, too; I'll probably go with this unless I hear
that it's not a good idea.

Regards, and thanks again,
Matt
   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	   d=gmail.com; s=gamma;
	   h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	    :cc:content-type;
	   bh=xcoQgmorEd54v46wec6y8N9Oet7ACI8+R8FCKE3IoEg=;
	   b=SY03NE/ZsmZlTT9YJeBtFjCnC8Zjqllv4IYVsh+KtIpD+B+JReUr9/63clezFXVj0O
	    JMmlUGyxuQ0+k+YUvVoIEJMtS5hebu1Ur55bNp97VBBhCqFJdt7ddlQluOF9D8H46SGw
	    jiovfxh/ZtC7M1o0tpqICNTUl/mukca1H+T5s=
   MIME-Version: 1.0
   Date: Wed, 19 Oct 2011 01:39:19 +0200
   From: Stig Hemmer <stighemmer <at> gmail.com>
   Cc: sbcl-help <at> lists.sourceforge.net
   Content-Type: text/plain; charset=ISO-8859-1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 26 Oct 2011 12:35
Gravatar

Re: SBCL source location

On 6 October 2011 16:03, Tamas Papp <tkpapp <at> gmail.com> wrote:

> Is there a way I can tell an SBCL compiled by somebody else that its
> sources are located in /usr/share/sbcl-source?

Something along the lines of

 (setf (logical-pathname-translations "SYS")
       '(("SYS:SRC;**;*.*.*" #P"/usr/share/sbcl-source/src/**/*.*")
         ("SYS:CONTRIB;**;*.*.*" #P"/usr/share/sbcl-source/contrib/**/*.*")))

should do the trick.

Cheers,

  -- nikodemus

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning <at> Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
Permalink | Reply | 0 comments |
headers
Carlos Konstanski | 26 Oct 2011 17:19

can't find core file from cron

When I run SBCL from a shell or from SLIME, everything is roses. But if I
try to run a shebang script from cron, it looks in the wrong place for
sbcl.core. Instead of looking in /usr/lib64/sbcl/sbcl.core (the correct
location), it looks in /usr/local/lib/sbcl//sbcl.core (double slashes appear
in /var/log/messages, so I duplicated them here).

If I run the same shebang script directly from xterm, it runs fine as usual.
This is definitely tied to cron somehow.

I tried adding --core to the shebang line in the script to no avail.

Any fixes/workarounds? An environment variable that dictates where the core
file is to be found perhaps?

Thanks,

Carlos

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning <at> Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
Permalink | Reply | 2 comments |
headers
Nikodemus Siivola | 26 Oct 2011 17:53
Gravatar

Re: can't find core file from cron

On 26 October 2011 18:19, Carlos Konstanski
<ckonstanski <at> pippiandcarlos.com> wrote:

> When I run SBCL from a shell or from SLIME, everything is roses. But if I
> try to run a shebang script from cron, it looks in the wrong place for
> sbcl.core. Instead of looking in /usr/lib64/sbcl/sbcl.core (the correct
> location), it looks in /usr/local/lib/sbcl//sbcl.core (double slashes appear
> in /var/log/messages, so I duplicated them here).

Yah. The inability to provide multiple options for shebang scripts is a pain.

#!sbcl --script

assumes that --core is either in the standard location
/usr/local/lib/sbcl or in a locate indicated by SBCL_HOME.

Since you have it in a non-standard location, and cron doesn't have
your usual environment set up, it can't find it.

Using

  SBCL_HOME=/usr/lib64/sbcl your-script

in cron should work, I think. I don't remember offhand if cron allow
you to set up the environment like that, but if it doesn't you can use
env for that -- or do

  sbcl --core /usr/lib64/sbcl/sbcl.core --script your-script

instead.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane