headers
Christophe Rhodes | 3 Jan 2005 00:02
Picon
Picon
Favicon

Re: compiling 0.8.18 from cvs (with clisp)

Pascal J.Bourguignon <pjb <at> informatimago.com> writes:

>   cvs update -rsbcl_0_8_18
>   export INSTALL_ROOT=/usr/local/languages/sbcl
>   sh clean.sh
>   sh make.sh '/usr/local/bin/clisp -q -ansi -norc -Kbase'
>
> ends with:
>
> The following special variables were not defined:
>  SB!C::HEAD
> 0 errors, 1 warning

I think I've fixed this problem in sbcl-0.8.18.11.  Would you mind
giving that version a try to see if there are any other lurking
problems?

Thanks for the report,

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 0 comments |
headers
Milan Zamazal | 5 Jan 2005 15:01
X-Face
Favicon

Segmentation fault in save-lisp-and-die

When I compile and load my Lisp software and try to save it with
save-lisp-and-die in SBCL 0.8.18 from Debian i386, I receive the
following response:

  [doing purification: roots handlers stack bindings static
  debugger invoked on a SIMPLE-ERROR in thread 28799:
    segmentation violation at #XB7EEF835

  You can 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 (leaving debugger, returning to toplevel).
    1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.

  debugger invoked on a TYPE-ERROR in thread 28799:
    The value NIL is not of type SB-DI:FRAME.

  [...]

  debugger invoked on a TYPE-ERROR in thread 28799:
    The value NIL is not of type SB-DI:FRAME.

  You can 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 (leaving debugger, returning to toplevel).
    1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
  Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
  *
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 5 Jan 2005 20:02
Picon
Picon
Favicon

Re: Segmentation fault in save-lisp-and-die

Milan Zamazal <pdm <at> zamazal.org> writes:

> When I compile and load my Lisp software and try to save it with
> save-lisp-and-die in SBCL 0.8.18 from Debian i386, I receive the
> following response:
>
>   [doing purification: roots handlers stack bindings static
>   debugger invoked on a SIMPLE-ERROR in thread 28799:
>     segmentation violation at #XB7EEF835
>   [... yuk errors of doom ... ]
>
> Is there a way to find out more about that problem so that it can be
> fixed?

Ask the debian maintainer for the unstripped sbcl binary file.  Then,
start sbcl, do everything until the save-lisp-and-die call.  Attach
gdb (loading the symbol table from the unstripped binary -- this is
why you need it), call save-lisp-and-die, and find out what is
segfaulting.  (It looks to be something in the C code).

Also, be very very sure before you go to all of this bother that you
haven't got any stale fasls loaded.

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blossom | 7 Jan 2005 03:25

compile-file apparently returning wrong value for error-p

Hi,

It appears that compile-file is incorrectly returning a value of T for
error-p even though the output diagnostics indicate that the
compilation produced only a warning.  [I'd also like to know how to
get rid of the warning...]

I'm using SBCL 0.8.17 on Linux 2.6.8 on x86 arch.

Suggestions?

Thanks,
Eric

----------------------------------------------------------------

[eb <at> bufo load]$ sbcl
This is SBCL 0.8.17, 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.
; loading system definition from
; #P"/usr/local/lib/sbcl/systems/sb-bsd-sockets.asd" into #<PACKAGE "ASDF3844">
; registering #<SYSTEM SB-BSD-SOCKETS {9D61439}> as SB-BSD-SOCKETS
; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {92A7439}> as SB-BSD-SOCKETS-TESTS
; loading system definition from #P"/usr/local/lib/sbcl/systems/sb-posix.asd"
; into #<PACKAGE "ASDF4006">
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sean Ross | 10 Jan 2005 15:31
Picon

Unreadably-printable strings and open.


Hi all,

  I've recently discovered that vectors with an array-element-type
  of base-char cannot be printed readably using SBCL 0.8.18.11 
  on x86 Linux. Although this does seem to be legal according to
  CLHS, regarding the double-quote reader creating strings of type
  character and array similarity requirements, it is unfortunate
  since the following code

  (let ((*print-readably* t))
    (open "/tmp/test.out" :direction :output))

  fails with a PRINT-NOT-READABLE error due to namestring returning
  a simple-base-string and make-fd-stream using the ~S format-directive
  in the parameter list.

  I don't know what an appropriate fix is but changing make-fd-stream
  to use the ~A format-directive is a fix of sorts. 

Regards, 
  Sean.

--

-- 
"My doctor says that I have a malformed public-duty gland and a
 natural  deficiency in moral fibre," he muttered to himself, "and
 that I am therefore excused from saving Universes."
 - Life, the Universe, and Everything     Douglas Adams.

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blossom | 12 Jan 2005 07:13

Control stack exhausted... SB-KERNEL::SIMPLIFY-UNIONS

I'm running into control stack exhaustion when trying to
compile a particular macro expansion (see below).

I'm using SBCL 0.8.17 on x86 Linux 2.6.8

Questions:

 (1) Can I increase the size of the control stack somehow?
     I RTFM, but didn't see anything relevant.  Is it a function of my
     ram + swap or is there a (tunable) limit in SBCL?

 (2) Are there declarations, etc that I could add to the code to get it
     to compile?

 (3) Any other suggestions for getting this to compile, including
     idioms, restructuring, etc.

Thanks,
Eric

----------------------------------------------------------------

Control stack exhausted (no more space for function call frames).  This is probably due to heavily nested or
infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away.
   [Condition of type SB-KERNEL::CONTROL-STACK-EXHAUSTED]

Restarts:
  0: [ABORT] Abort handling SLIME request.
  1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel).
  2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul F. Dietz | 12 Jan 2005 13:18
Favicon

Re: Control stack exhausted... SB-KERNEL::SIMPLIFY-UNIONS

Eric Blossom wrote:
> I'm running into control stack exhaustion when trying to
> compile a particular macro expansion (see below).
> 
> I'm using SBCL 0.8.17 on x86 Linux 2.6.8
> 
> Questions:
> 
>  (1) Can I increase the size of the control stack somehow?
>      I RTFM, but didn't see anything relevant.  Is it a function of my
>      ram + swap or is there a (tunable) limit in SBCL?
> 
>  (2) Are there declarations, etc that I could add to the code to get it
>      to compile?
> 
>  (3) Any other suggestions for getting this to compile, including
>      idioms, restructuring, etc.

Get rid of all the separate calls to EX-FLOAT and instead map across
a list or lists of arguments.  This will probably solve all the problems
(I think you're seeing SBCL being too precise in analyzing integer
types, which is making the size of the types explode.)

	Paul

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Blossom | 12 Jan 2005 16:12

Re: Re: Control stack exhausted... SB-KERNEL::SIMPLIFY-UNIONS

On Wed, Jan 12, 2005 at 06:18:07AM -0600, Paul F. Dietz wrote:
> Eric Blossom wrote:
> >I'm running into control stack exhaustion when trying to
> >compile a particular macro expansion (see below).
> >
> >I'm using SBCL 0.8.17 on x86 Linux 2.6.8
> >
> >Questions:
> >
> > (1) Can I increase the size of the control stack somehow?
> >     I RTFM, but didn't see anything relevant.  Is it a function of my
> >     ram + swap or is there a (tunable) limit in SBCL?
> >
> > (2) Are there declarations, etc that I could add to the code to get it
> >     to compile?
> >
> > (3) Any other suggestions for getting this to compile, including
> >     idioms, restructuring, etc.
> 
> Get rid of all the separate calls to EX-FLOAT and instead map across
> a list or lists of arguments.  This will probably solve all the problems
> (I think you're seeing SBCL being too precise in analyzing integer
> types, which is making the size of the types explode.)
> 
> 	Paul

Thanks, will do.

Eric
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 17 Jan 2005 20:47
Picon
Picon
Favicon

Re: compile-file apparently returning wrong value for error-p

[ delayed response... ]

Eric Blossom <eb <at> comsec.com> writes:

> It appears that compile-file is incorrectly returning a value of T for
> error-p even though the output diagnostics indicate that the
> compilation produced only a warning.  [I'd also like to know how to
> get rid of the warning...]

The correct value for errorp given a full warning /is/ T, I'm afraid.

> ; file: /home/eb/build/autod/load/test.lisp
> ; in: DEFUN FLATTEN-FORMAT
> ;     (CL-PPCRE:REGISTER-GROUPS-BIND (HEAD CH (#'PARSE-INTEGER REPEAT) TAIL)
> ;                                  ("(.*)(.)\\(([0-9]+)\\)(.*)" COBOL-FMT)
> ;                                  (CONCATENATE 'STRING
> ;                                               HEAD
> ;                                               (MAKE-STRING REPEAT
> ;                                                            :INITIAL-ELEMENT
> ;                                                            (CHAR CH 0))
> ;                                               TAIL))
> ; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF PROGN 
> ; --> LET* LET IF 
> ; ==>
> ;   NIL
> ; 
> ; caught WARNING:
> ;   The binding of ARRAY is not a STRING:
> ;     NIL
> ;   See also:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Koenraad De Smedt | 17 Jan 2005 20:53
Picon
Picon

iso-latin-1 characters on OSX

I am using SBCL on OSX under Apple's X11.

Problem: upper-ascii characters are not being read; the reader just stops.

Examples:  "æøå"  'æøå

This occurs when simply running SBCL in an xterm or via Emacs, using iso-latin-1 characters and
corresponding Emacs encoding.

This might be an X11 implementation problem; however, other process communication from Emacs does handle
iso-latin-1 characters.  In Emacs, I can for example start a shell and grep such characters without a problem.

K

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 4 comments |

Gmane