Home / Browse / Steel Bank Common Lisp / Mail / Archive

Steel Bank Common Lisp

Email Archive: sbcl-help (read-only)

2007:	_Jan (45)	_Feb (51)	_Mar (69)	_Apr (48)	_May (75)	_Jun (35)	_Jul (35)	_Aug (25)	_Sep (11)	_Oct (16)	_Nov (9)	_Dec (59)
2008:	_Jan (36)	_Feb (17)	_Mar (28)	_Apr (13)	_May (1)	_Jun (25)	_Jul (24)	_Aug (52)	_Sep (19)	_Oct (52)	_Nov (43)	_Dec (80)
2010:	_Jan (26)	_Feb (45)	_Mar (55)	_Apr (59)	_May (8)	_Jun (24)	_Jul (43)	_Aug (31)	_Sep (43)	_Oct (33)	_Nov (41)	_Dec (19)
2009:	_Jan (33)	_Feb (30)	_Mar (18)	_Apr (15)	_May (29)	_Jun (58)	_Jul (48)	_Aug (35)	_Sep (52)	_Oct (59)	_Nov (46)	_Dec (31)
2005:	_Jan (24)	_Feb (32)	_Mar (39)	_Apr (65)	_May (69)	_Jun (37)	_Jul (32)	_Aug (28)	_Sep (28)	_Oct (17)	_Nov (30)	_Dec (24)
2002:	_Jan	_Feb (2)	_Mar (3)	_Apr	_May (5)	_Jun	_Jul	_Aug (2)	_Sep (3)	_Oct	_Nov	_Dec (8)
2006:	_Jan (45)	_Feb (38)	_Mar (19)	_Apr (26)	_May (19)	_Jun (29)	_Jul (13)	_Aug (26)	_Sep (53)	_Oct (46)	_Nov (40)	_Dec (85)
2012:	_Jan (9)	_Feb (22)	_Mar (17)	_Apr (16)	_May (58)	_Jun (13)	_Jul (40)	_Aug (12)	_Sep (10)	_Oct (10)	_Nov (14)	_Dec (4)
2003:	_Jan (5)	_Feb (4)	_Mar (14)	_Apr	_May (27)	_Jun (10)	_Jul (3)	_Aug (28)	_Sep (27)	_Oct (3)	_Nov (14)	_Dec (19)
2004:	_Jan (32)	_Feb (15)	_Mar (21)	_Apr (69)	_May (18)	_Jun (15)	_Jul (23)	_Aug (14)	_Sep (38)	_Oct (20)	_Nov (76)	_Dec (27)
2000:	_Jan	_Feb	_Mar	_Apr	_May (1)	_Jun (2)	_Jul (2)	_Aug	_Sep	_Oct	_Nov	_Dec (3)
2001:	_Jan	_Feb	_Mar	_Apr (1)	_May (8)	_Jun	_Jul (2)	_Aug (3)	_Sep	_Oct	_Nov	_Dec
2011:	_Jan (17)	_Feb (31)	_Mar (5)	_Apr (31)	_May (17)	_Jun (28)	_Jul (15)	_Aug (38)	_Sep (21)	_Oct (25)	_Nov (21)	_Dec (21)
2013:	_Jan (9)	_Feb (8)	_Mar (17)	_Apr (10)	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec


S	M	T	W	T	F	S
			1	2	3	4

5	6	7	8	9	10	11
		(1)
12	13	14	15	16	17	18
	(1)		(13)	(1)	(5)	(1)
19	20	21	22	23	24	25
	(5)		(5)	(4)	(3)
26	27	28	29	30
	(2)	(1)		(1)

Re: [Sbcl-help] Fwd: Re: [cffi-devel] foreign library memory footprint

From: Nikodemus Siivola <nikodemus@ra...> - 2010-09-30 09:29

On 22 July 2010 18:20,  <k2msmith@...> wrote:

> Forwarding this thread to sbcl help, specifically last question.

>> > what about memory size in lisp as well ?

In SBCL you can use (sb-kernel:dynamic-usage) to obtain the number of
bytes allocated. This isn't officially supported right now, but is
unlikely to break in a hurry.

However, this same information is available from ROOM as well.

SB-SPROF can also do allocation profiling for the lisp side, should
you need that.

Cheers,

 -- Nikodemus

Re: [Sbcl-help] Shared objects

From: Peter Keller <psilord@cs...> - 2010-09-24 02:05

On Wed, Sep 15, 2010 at 11:19:16AM +0300, Nikodemus Siivola wrote:
> This is going to be ugly, and is technically unsupported right now.
> Sorry about that.

I have a minor question:

Is there an API in SBCL that I can use to determine if the executable that
is my SBCL lisp image was compiled 32-bit or 64-bit?

Thank you.

-pete

Re: [Sbcl-help] Shared objects

From: Peter Keller <psilord@cs...> - 2010-09-28 05:44

On Wed, Sep 15, 2010 at 11:19:16AM +0300, Nikodemus Siivola wrote:
[snip]
> To get the actual absolute pathname of the .so you have to duplicate
> the searching behaviour of dlopen(), which is somewhat platform
> dependent, and also depends on the current working directory at the
> time the library was loaded.

[snip]

> (defun fix-shared-object (obj new-pathname)
>   (declare (pathname new-pathname))
>   (setf (sb-alien::shared-object-pathname obj) new-pathname)
>   (setf (sb-alien::shared-object-namestring obj)
> 	(native-namestring (translate-logical-pathname new-pathname)
> 			   :as-file t))
>   obj)

The above ideas coupled with parsing the output of /sbin/ldconfig -p
has provided a reliable enough method to find and preserve the shared
libraries used by sb-sys:*shared-objects* for linux on x86 or x86-64
architectures.

Thank you *very* much for your suggestions!

Later,
-pete

Re: [Sbcl-help] [Q] sb-introspect on .asd files

From: Didier Verna <didier@lr...> - 2010-09-27 12:48

Faré <fahree@...> wrote:

> If you use it today with ASDF 2, your code will be compiled and you
> will be able to do introspection on it.

  Maybe I didn't understand you, but are you suggesting that ASDF 2 .asd
files are compiled? Because I don't see this happening. Is there a
configuration tweak that I need to know about somewhere ?

Thanks

[BTW, I just filled the bug reports that you requested on cll the other day.]

-- 
Resistance is futile. You will be jazzimilated.

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

Re: [Sbcl-help] [Q] sb-introspect on .asd files

From: Faré <fahree@gm...> - 2010-09-27 14:54

>>: Faré
>: Didier Verna

>> Note that for ASDF 3, we intend to move towards having .asd files not
>> contain any code, only single (multilpe?) defsystem statements. Then,
>> you'd define your ASDF customizations in a separate system, and use
>> :defsystem-depends-on to depend on it.
>>
>> This style isn't mandatory yet, but it might become so in the future.
>> If you use it today with ASDF 2, your code will be compiled and you
>> will be able to do introspection on it.
>
>  Maybe I didn't understand you, but are you suggesting that ASDF 2 .asd
> files are compiled? Because I don't see this happening. Is there a
> configuration tweak that I need to know about somewhere ?
>
You quoted my last two lines out of context. When in context, it appears
that what I mean is not that you should just use ASDF2, but also use this
particular style that we want to promote, where a .asd file contains no
code whatsoever, and all code is moved to other systems that are required
at defsystem parsing time with :defsystem-depends-on. So: move you code
to some lisp file, create a foo.asd file that covers that asdf extension,
and use :defsystem-depends-on (:foo). It will then be compiled AND
more compatible with a future ASDF 3.

> [BTW, I just filled the bug reports that you requested on cll the other day.]
Thanks a whole lot!

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The man who will use his skill and constructive imagination to see how much he
can give for a dollar, instead of how little he can give for a dollar, is bound
to succeed. — Henry Ford

[Sbcl-help] Build problems on SnowLeopard 10.6.4 newest xcode, posted to launchpad

From: Thomas Porter <tom.porter@gm...> - 2010-09-24 15:36

Looks like my tool chain is borked somehow, as versions that
previously built are no longer building.  Any suggestions/places to
look would be very welcome.


See https://bugs.launchpad.net/bugs/646398


Bug description:
newest git pull 1.0.42.52, newest xcode 3.2.4

Environment stuff:
tporter@...:~ > uname -a
Darwin xxxxx.xxx.org 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23
18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386

Error occurs at end of build process, in testing of initial core file

[building initial core file in "output/cold-sbcl.core":
writing 8192 bytes [2 pages] from #<SB!FASL::GSPACE :READ-ONLY>
writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC>
writing 44056576 bytes [10756 pages] from #<SB!FASL::GSPACE :DYNAMIC>
/(DESCRIPTOR-BITS INITIAL-FUN)=#X10028853E9
done]
* //testing for consistency of first and second GENESIS passes
//header files match between first and second GENESIS -- good

real    4m27.004s
user    3m24.219s
sys     0m43.557s
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 1.0.42.52, 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.
internal error #34 (invalid array index)
   SC: 21, Offset: 2   $1=       0x10004673af: other pointer
   SC: 20, Offset: 12            0x000000a0: even fixnum: 40
   SC: 20, Offset: 14            0x000035c0: even fixnum: 3440
fatal error encountered in SBCL pid 40499:
internal error too early in init, can't recover


Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>

Anyone have detailed build instructions for SL 10.6.4/xcode 3.2.4??

Thanks!

TomP

[Sbcl-help] building sbcl with unicode disabled fails

From: Alistair Gee <alistair.gee@gm...> - 2010-09-24 12:44

I was curious if SBCL built w/o unicode would be better for
performance and/or memory usage. However, when I modified my
customize-target-features.lisp to disable :sb-unicode and compile, I
get the error trace shown at the end of this message.

This error happens with both sbcl-1.0.42.0 and with the latest sbcl
from git. The platform is x86 Ubuntu 10.04. If I do not disable
:sb-unicode, the build succeeds.

My customize-target-features.lisp has:

(lambda (features)
  (flet ((enable (x)
           (pushnew x features))
         (disable (x)
           (setf features (remove x features))))
    ;; Threading support.
    (enable :sb-thread)
    ;; Disable unicode
    (disable :sb-unicode)))


Error trace:

unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" RUNNING
                                   {A9F5F09}>:
  FAILURE-P was set when creating
"obj/from-xc/src/code/external-formats/enc-basic.lisp-obj".

0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {B9499FD}>)[:EXTERNAL]
1: (SB-DEBUG:BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {90C08F9}>)
2: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<SIMPLE-ERROR "FAILURE-P was set when creating ~S." {B9483F1}>
    #<unavailable argument>)
3: (SB-DEBUG::RUN-HOOK
    SB-EXT:*INVOKE-DEBUGGER-HOOK*
    #<SIMPLE-ERROR "FAILURE-P was set when creating ~S." {B9483F1}>)
4: (INVOKE-DEBUGGER
    #<SIMPLE-ERROR "FAILURE-P was set when creating ~S." {B9483F1}>)
5: (ERROR #<SIMPLE-ERROR "FAILURE-P was set when creating ~S."
{B9483F1}>)[:EXTERNAL]
6: (COMPILE-STEM
    "src/code/external-formats/enc-basic"
    (:NOT-HOST)
    :TARGET-COMPILE)
7: (IN-TARGET-CROSS-COMPILATION-MODE #<CLOSURE (LAMBDA #) {BA8CFD5}>)
8: ((LAMBDA ()))
9: (SB-INT:SIMPLE-EVAL-IN-LEXENV
    (LET ((REVERSED-TARGET-OBJECT-FILE-NAMES NIL))
      (DO-STEMS-AND-FLAGS (STEM FLAGS)
        (UNLESS (POSITION :NOT-TARGET FLAGS)
          (PUSH # REVERSED-TARGET-OBJECT-FILE-NAMES)))
      (SETF *TARGET-OBJECT-FILE-NAMES*
              (NREVERSE REVERSED-TARGET-OBJECT-FILE-NAMES)))
    #<NULL-LEXENV>)
10: (SB-FASL::LOAD-AS-SOURCE
     #<SB-SYS:FD-STREAM
       for "file
/home/ag/downloads/cl/tmp/sbcl-1.0.42/src/cold/compile-cold-sbcl.lisp"
       {BBD9D11}>
     NIL
     NIL)
11: ((FLET SB-FASL::LOAD-STREAM)
     #<SB-SYS:FD-STREAM
       for "file
/home/ag/downloads/cl/tmp/sbcl-1.0.42/src/cold/compile-cold-sbcl.lisp"
       {BBD9D11}>
     NIL)
12: (LOAD "src/cold/compile-cold-sbcl.lisp")[:EXTERNAL]
13: (SB-INT:SIMPLE-EVAL-IN-LEXENV
     (LOAD "src/cold/compile-cold-sbcl.lisp")
     #<NULL-LEXENV>)
14: (SB-EXT:INTERACTIVE-EVAL (LOAD
"src/cold/compile-cold-sbcl.lisp"))[:EXTERNAL]
15: (SB-IMPL::REPL-FUN NIL)
16: ((LAMBDA ()))
17: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {A9F830D}>)
18: (SB-IMPL::TOPLEVEL-REPL NIL)
19: (SB-IMPL::TOPLEVEL-INIT)
20: ((LABELS SB-IMPL::RESTART-LISP))

unhandled condition in --disable-debugger mode, quitting
deleted #P"/home/ag/downloads/cl/tmp/sbcl-1.0.42/obj/from-xc/src/code/external-formats/enc-basic.lisp-obj-tmp"
Command exited with non-zero status 1
114.23user 2.82system 1:57.45elapsed 99%CPU (0avgtext+0avgdata
353744maxresident)k
0inputs+40528outputs (0major+586567minor)pagefaults 0swaps

Re: [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp

From: Petter Gustad <sbcl@gu...> - 2010-09-23 08:27

From: "James Fleming" <lisp@...>
Subject: [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp
Date: Wed, 18 Aug 2010 21:49:32 +1000 (EST)

> The symptom: sb-grovel's def-to-lisp fails to compile at line 244, where
> it tries to evaluate (compile-file tmp-constants :output-file output-file)
> after defining 'tmp-constants in this manner:
> (let ((tmp-constants (merge-pathnames #p"constants.lisp-temp"
>                                          real-output-file)))

I've run into this problem as well:

darcs get http://common-lisp.net/project/clbuild/clbuild
cd clbuild
chmod a+x clbuild
./clbuild update sbcl
./clbuild compile-implementation sbcl
./clbuild lisp --eval "(progn (print (lisp-implementation-version)) (asdf:oos 'asdf:load-op :sb-posix))"

"1.0.42.52" 

debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD
                                                           "initial thread" RUNNING
                                                           {1002AAFEA1}>:
  failed to find the TRUENAME of /home/petter/.fasls/sbcl-1.0.42.52-linux-x86-64/tmp/clbuild-test/clbuild/target/lib/sbcl/sb-posix/constants.lisp-temp:
    No such file or directory


Was this issue resolved somehow?

//Petter

Re: [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp

From: James Fleming <lisp@el...> - 2010-09-23 11:10

> I've run into this problem as well:
...
> Was this issue resolved somehow?

It wasn't resolved, so much as I found a workaround, which was to install
it directly under /usr/local.
I haven't the knowledge of the internals, nor the time (now less than
ever) to wrap my head around the root cause or resolution, unfortunately.


Cheers,
James

Re: [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp

From: Nikodemus Siivola <nikodemus@ra...> - 2010-09-23 11:30

On 23 September 2010 11:27, Petter Gustad <sbcl@...> wrote:

>  failed to find the TRUENAME of /home/petter/.fasls/sbcl-1.0.42.52-linux-x86-64/tmp/clbuild-test/clbuild/target/lib/sbcl/sb-posix/constants.lisp-temp:
>    No such file or directory

> Was this issue resolved somehow?

Not that I am aware -- not that I was actively aware of the entire issue.

It seems to be a bad interaction between the way clbuild
builds/installs SBCL, and the way ASDF2 does things.

Cheers,

 -- Nikodemus

Re: [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp

From: Nikodemus Siivola <nikodemus@ra...> - 2010-09-23 12:57

On 23 September 2010 15:49, Petter Gustad <clbuild@...> wrote:

> Yes, but I'm little uncertain where it should be fixed. I'll check the
> clbuild mailing list and see if there are any new updates available to
> resolve this issue.

Well, if you can reduce it to a semi-standard SBCL installation, along
the lines of

 sh make.sh
 INSTALL_ROOT=/place sh install.sh

 SBCL_HOME=/place/lib/sbcl/ /place/bin/sbcl --no-userinit --no-sysinit
 (require :sb-posix) ; this in the repl

then SBCL or ASDF is almost certainly the right place to fix it.

Cheers,

 -- Nikodemus

[Sbcl-help] problem with structure

From: Giovanni Gigante <giov@ci...> - 2010-09-22 09:20

CL-USER> (defstruct foo (bar #() :type (simple-array t (*))))
FOO
CL-USER> (typep #(1 2) '(simple-array t (*)))
T
CL-USER> (setf *a* #S(foo :bar #(1 2)))

The value ((SB-IMPL::|bqv|) 1 2)
is not of type
   (SIMPLE-ARRAY T (*)).
    [Condition of type TYPE-ERROR]

I've also tried with vector, simple-vector etc. but the result is the same.
what's happening here? and by the way, isn't |bqv| a bit cryptic?

giovanni

Re: [Sbcl-help] problem with structure

From: Stas Boukarev <stassats@gm...> - 2010-09-22 09:34

Giovanni Gigante <giov@...> writes:

> CL-USER> (defstruct foo (bar #() :type (simple-array t (*))))
> FOO
> CL-USER> (typep #(1 2) '(simple-array t (*)))
> T
> CL-USER> (setf *a* #S(foo :bar #(1 2)))
>
> The value ((SB-IMPL::|bqv|) 1 2)
> is not of type
>    (SIMPLE-ARRAY T (*)).
>     [Condition of type TYPE-ERROR]
>
> I've also tried with vector, simple-vector etc. but the result is the same.
> what's happening here? and by the way, isn't |bqv| a bit cryptic?
>
What version of SBCL are you using? I suspect a fairly old one.

-- 
With Best Regards, Stas.

Re: [Sbcl-help] problem with structure

From: Giovanni Gigante <giov@ci...> - 2010-09-22 09:50

Stas Boukarev wrote:

> What version of SBCL are you using? I suspect a fairly old one.

Just six months old, it's 1.0.37 (linux/amd64). Before posting here I've 
browsed the release notes from 1.0.37 to 1.0.42, but I didn't see 
anything related (apparently)...

Re: [Sbcl-help] problem with structure

From: Stas Boukarev <stassats@gm...> - 2010-09-22 09:58

Giovanni Gigante <giov@...> writes:

> Stas Boukarev wrote:
>
>> What version of SBCL are you using? I suspect a fairly old one.
>
> Just six months old, it's 1.0.37 (linux/amd64). Before posting here I've browsed the
> release notes from 1.0.37 to 1.0.42, but I didn't see anything related (apparently)...
The problem is, that's been fixed in 1.0.37.60.

-- 
With Best Regards, Stas.

Re: [Sbcl-help] problem with structure

From: Giovanni Gigante <giov@ci...> - 2010-09-22 10:01

> The problem is, that's been fixed in 1.0.37.60.
>    
Oh. Thanks

[Sbcl-help] SBCL User Survey -- to come

From: Nikodemus Siivola <nikodemus@ra...> - 2010-09-20 14:25

I'm planning an SBCL user survey. What follows is my current list of questions.

Please let me know if you have comments on the form of questions, or
suggestions on additional questions.

* What country do you live in? [free text]

* How old are you? [free text]

* How long have you been using SBCL? [options for <1 y, 1-2y, 2-5y, 5-10y]

* How long have you been using Common Lisp? [options as above, but
with additional 10-20y and >20y options]

* How long have you been programming? [options as above]

* How do you obtain the SBCL you use? [options for CVS/Git, source
tarball, sbcl.org binary, distribution binary, installed by local
sysadmin]

* What version of SBCL are you currently using?
(lisp-implementation-version) [free text]

* How often do you update SBCL to a new version? [options for weekly,
monthly, bimonthly, a few times a year, yearly, less often than once a
year, whenever the distribution binary package is updated]

* What operating systems and architectures do you use SBCL on?
[options for the supported arch/os matrix]

* What do you use SBCL for? [free text]

* What SBCL contribs do you use? [options for contribs]

* How useful do you find the SBCL documentation? [options for
not-at-all, somewhat, quite, extremely]

* Additional comments about documentation? [free text]

* Do you follow sbcl-help? [yes/no]

* Do you follow sbcl-devel? [yes/no]

* Do you visit #lisp@...? [yes/no]

* Do you visit #sbcl@...? [yes/no]

* What is your main source of information about SBCL? Is it sufficient? [yes/no]

* What is your overall impression of SBCL? [free text]

* What are three main things you hope from future SBCL development?
(These can be specific issues or general trends -- whatever you
consider important.) [free text]

Cheers,

 -- Nikodemus

[Sbcl-help] read-from-string

From: Jerry James <loganjerry@gm...> - 2010-09-20 02:26

With SBCL 1.0.38, on an x86_64 Fedora 13 machine:

* (read-from-string "Is it nil or t?" :start 6 :end 9)

IS
3

So READ-FROM-STRING ignores :start.  Also:

* (read-from-string "Nilson" :end 3)

NILSON
6

So READ-FROM-STRING also ignores :end.   From the Hyperspec
description of READ-FROM-STRING:

"Parses the printed representation of an object from the subsequence
of string bounded by start and end, as if read had been called on an
input stream containing those same characters."

I expected that to mean that only the characters between :start and
:end would be examined.  Yet GCL 2.6.8pre, ECL 10.4.1, and Clisp 2.47
all behave the same way on this machine, so ... what am I missing?
-- 
Jerry James
http://www.jamezone.org/

Re: [Sbcl-help] read-from-string

From: Brian Mastenbrook <brian@ma...> - 2010-09-20 03:01

On 09/19/2010 09:25 PM, Jerry James wrote:
> With SBCL 1.0.38, on an x86_64 Fedora 13 machine:
>
> * (read-from-string "Is it nil or t?" :start 6 :end 9)
>
> IS
> 3
>
*snip*
>
> I expected that to mean that only the characters between :start and
> :end would be examined.  Yet GCL 2.6.8pre, ECL 10.4.1, and Clisp 2.47
> all behave the same way on this machine, so ... what am I missing?

You're missing the wonderfully nonintuitive interaction between 
&OPTIONAL and &KEY. In your call, :START is taken as the value of 
ERROR-P, and 6 as the value of EOF-ERROR. Try this instead:

(read-from-string "Is it nil or t?" t nil :start 6 :end 9)
--
Brian Mastenbrook
brian@...
http://brian.mastenbrook.net/

Re: [Sbcl-help] read-from-string

From: Nikodemus Siivola <nikodemus@ra...> - 2010-09-20 07:33

On 20 September 2010 05:36, Brian Mastenbrook <brian@...> wrote:

> You're missing the wonderfully nonintuitive interaction between
> &OPTIONAL and &KEY. In your call, :START is taken as the value of
> ERROR-P, and 6 as the value of EOF-ERROR. Try this instead:
>
> (read-from-string "Is it nil or t?" t nil :start 6 :end 9)

Since pretty much everyone has been bitten by this at one time or
another, I went and added a style-warning about this mistake to SBCL
as of 1.0.42.46.

Cheers,

 -- Nikodemus

Re: [Sbcl-help] read-from-string

From: <pjb@in...> - 2010-09-20 09:15

Nikodemus Siivola <nikodemus@...> writes:

> On 20 September 2010 05:36, Brian Mastenbrook <brian@...> wrote:
>
>> You're missing the wonderfully nonintuitive interaction between
>> &OPTIONAL and &KEY. In your call, :START is taken as the value of
>> ERROR-P, and 6 as the value of EOF-ERROR. Try this instead:
>>
>> (read-from-string "Is it nil or t?" t nil :start 6 :end 9)
>
> Since pretty much everyone has been bitten by this at one time or
> another, I went and added a style-warning about this mistake to SBCL
> as of 1.0.42.46.

Nice.  Thanks.   


By the way, if the user defines a function named like the few CL
functions that take both &optional and &key parameters, could you
disable the warning about them?

(shadow 'read-from-string)
(defun read-from-string (string &optional eof-error-p eof-value &key start end preserve-whitespace)
   ...)

should not give that warning IMO.
 

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: [Sbcl-help] Trouble compiling sbcl on onpensuse-11.2 amd64

From: Josef Wolf <jw@ra...> - 2010-09-17 08:00

On Fri, Sep 17, 2010 at 08:35:16AM +0300, Nikodemus Siivola wrote:
> On 17 September 2010 00:54, Josef Wolf <jw@...> wrote:

Thanks for your quick reply, Nikodemus!

> > I am trying to compile sbcl on opensuse-11.2 running on a dual-core amd64
> > box with 8GB of RAM and 20GB of swap.
> 
> > ::: Running (:UNSYNCHRONIZED-HASH-TABLE)
> > Heap exhausted during allocation: 1016590336 bytes available, 1073741840 requested.
> 
> This is very curious. Is this repeatable? That is, if you run the test
> suite ten times, how many times does this error occur?

It _was_ reproducible with the same build. Unfortunately, instead of keeping
this build, I deleted it and ran my build-script again. This time the tests
are OK. Since I always make me a small shell-script to build my stuff, the
commands that were executed to do the builds were identical in both cases.
When the outcome is different, some sort of race condition has to be suspected
or something.

I might try to run the build over and over again until it happens again. One
build lasts about 1 hour on this machine, so it might take a while until it
happens again (if at all).

> In any case, if after adding #+nil in front of
> 
> (with-test (:name (:unsynchronized-hash-table))
> 
> in tests/threads.impure.lisp nothing else fails. I would not worry:
> the test in question is quite an evil one.

Too late now.. Sorry for not having thought twice before deleting the
build.

> That said, heap-exhaustion from it is definitely not expected, and I
> would be very interested to hear how reproducible this is, and if
> anyone else sees this happening.

I'll go trying to rebuild until it happens again.

Re: [Sbcl-help] Trouble compiling sbcl on onpensuse-11.2 amd64

From: Josef Wolf <jw@ra...> - 2010-09-17 15:20

On Fri, Sep 17, 2010 at 09:59:23AM +0200, Josef Wolf wrote:
> It _was_ reproducible with the same build. Unfortunately, instead of keeping
> this build, I deleted it and ran my build-script again. This time the tests
> are OK. Since I always make me a small shell-script to build my stuff, the
> commands that were executed to do the builds were identical in both cases.
> When the outcome is different, some sort of race condition has to be suspected
> or something.
> 
> I might try to run the build over and over again until it happens again. One
> build lasts about 1 hour on this machine, so it might take a while until it
> happens again (if at all).

While trying to reproduce this error, I got another error. All with the same
command sequence No idea whether it is relevant.


// Running /m/a/tmp/builds/sbcl/sbcl-1.0.42/tests/undefined-classoid-bug.test.sh
; in: LAMBDA NIL
;     (A-STRUCT-SLOT STRUCT)
;
; caught STYLE-WARNING:
;   undefined function: A-STRUCT-SLOT
;
; compilation unit finished
;   Undefined function:
;     A-STRUCT-SLOT
;   caught 1 STYLE-WARNING condition
;
; caught STYLE-WARNING:
;   undefined function: A-STRUCT-SLOT
;
; compilation unit finished
;   Undefined function:
;     A-STRUCT-SLOT
;   caught 1 STYLE-WARNING condition

; compiling file "/m/a/tmp/builds/sbcl/sbcl-1.0.42/tests/undefined-classoid-bug-test-19381/undefined-classoid-bug-1.lisp" (written 17 SEP 2010 03:38:28 PM):
; compiling (IN-PACKAGE "CL-USER")
; compiling (DEFUN A-STRUCT-REFERENCER-1 ...)

; /m/a/tmp/builds/sbcl/sbcl-1.0.42/tests/undefined-classoid-bug-test-19381/undefined-classoid-bug-1.fasl written
; compilation finished in 0:00:00.064
; compiling file "/m/a/tmp/builds/sbcl/sbcl-1.0.42/tests/undefined-classoid-bug-test-19381/undefined-classoid-bug-2.lisp" (written 17 SEP 2010 03:38:28 PM):
; compiling (IN-PACKAGE "CL-USER")
; compiling (DEFUN A-STRUCT-REFERENCER-2 ...)
; compiling (DEFSTRUCT A-STRUCT ...)

; /m/a/tmp/builds/sbcl/sbcl-1.0.42/tests/undefined-classoid-bug-test-19381/undefined-classoid-bug-2.fasl written
; compilation finished in 0:00:00.192
test undefined-classoid-bug ok

Finished running tests.
Status:
 Unexpected success:  dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES)
 Expected failure:    packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
 Expected failure:    packages.impure.lisp / IMPORT-SINGLE-CONFLICT
 Failure:             threads.impure.lisp / (TERMINATE-THREAD-RESTART)
 Failure:             timer.impure.lisp / (TIMER STRESS)
test failed, expected 104 return code, got 1
Sie haben neue Post in /var/spool/mail/jw.

Re: [Sbcl-help] Trouble compiling sbcl on onpensuse-11.2 amd64

From: Josef Wolf <jw@ra...> - 2010-09-17 17:00

On Fri, Sep 17, 2010 at 09:59:23AM +0200, Josef Wolf wrote:
> I might try to run the build over and over again until it happens again. One
> build lasts about 1 hour on this machine, so it might take a while until it
> happens again (if at all).

Seems like every other build gives me a different result. Shouldn't it be a 
little more deterministic? This time I get

  unhandled FLOATING-POINT-INVALID-OPERATION in thread #<SB-THREAD:THREAD
                                                         "initial thread" RUNNING
                                                         {A9ECFA9}>:
    arithmetic error FLOATING-POINT-INVALID-OPERATION signalled


Here is more context of the error:


* //entering make-genesis-2.sh
//loading and running GENESIS to create cold-sbcl.core
This is SBCL 1.0.42, 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.
*
5
* target features *SHEBANG-FEATURES*=(:ANSI-CL :COMMON-LISP :SBCL :SB-DOC
                                      :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS
                                      :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS
                                      :IEEE-FLOATING-POINT :X86-64 :UNIX :ELF
                                      :LINUX :SB-THREAD :LARGEFILE :GENCGC
                                      :STACK-GROWS-DOWNWARD-NOT-UPWARD
                                      :C-STACK-IS-CONTROL-STACK :LINKAGE-TABLE
                                      :COMPARE-AND-SWAP-VOPS
                                      :UNWIND-TO-FRAME-AND-CALL-VOP
                                      :RAW-INSTANCE-INIT-VOPS
                                      :STACK-ALLOCATABLE-CLOSURES
                                      :STACK-ALLOCATABLE-VECTORS
                                      :STACK-ALLOCATABLE-LISTS
                                      :STACK-ALLOCATABLE-FIXED-OBJECTS
                                      :ALIEN-CALLBACKS :CYCLE-COUNTER
                                      :COMPLEX-FLOAT-VOPS :FLOAT-EQL-VOPS
                                      :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS
                                      :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC
                                      :OS-PROVIDES-SUSECONDS-T)
target backend-subfeatures *SHEBANG-BACKEND-FEATURES*=NIL
T
*
#<PACKAGE "SB-COLD">
*
"obj/from-xc/"
*
T
*
T
*
; in: LAMBDA NIL
;     (THE SB!SYS:SAP-INT #:NEW-VALUE657)
;
; caught STYLE-WARNING:
;   undefined type: SAP-INT
;
; compilation unit finished
;   Undefined type:
;     SAP-INT
;   caught 1 STYLE-WARNING condition

;     (THE SB!C::CLAMBDA #:NEW-VALUE665)
;
; caught STYLE-WARNING:
;   undefined type: CLAMBDA
;
; compilation unit finished
;   Undefined type:
;     CLAMBDA
;   caught 1 STYLE-WARNING condition

;     (THE SB!C:TN #:NEW-VALUE679)
;
; caught STYLE-WARNING:
;   undefined type: TN
;
; compilation unit finished
;   Undefined type:
;     TN
;   caught 1 STYLE-WARNING condition

;     (SB!INT:BAD-TYPE SB!IMPL::NAME 'SYMBOL "Type name is not a symbol:~%  ~S"
;      SB!KERNEL:FORM)
;
; caught STYLE-WARNING:
;   undefined function: BAD-TYPE
;
; compilation unit finished
;   Undefined function:
;     BAD-TYPE
;   caught 1 STYLE-WARNING condition
STYLE-WARNING: redefining MAKE-MUTEX in DEFUN
STYLE-WARNING: redefining MAKE-SPINLOCK in DEFUN
STYLE-WARNING:
   new FTYPE proclamation for CLASSOID-NAME
     (FUNCTION (CLASSOID) (VALUES SYMBOL &OPTIONAL))
   does not match the old FTYPE proclamation:
     (FUNCTION (CLASSOID) (VALUES T &OPTIONAL))

*
*TARGET-OBJECT-FILE-NAMES*
*
T
*
beginning GENESIS, creating core "output/cold-sbcl.core"
obj/from-xc/src/code/show.lisp-obj
obj/from-xc/src/code/early-source-location.lisp-obj
obj/from-xc/src/code/early-constants.lisp-obj
obj/from-xc/src/code/backq.lisp-obj
obj/from-xc/src/code/globals.lisp-obj
obj/from-xc/src/code/defsetfs.lisp-obj
obj/from-xc/src/code/cold-init-helper-macros.lisp-obj
obj/from-xc/src/code/uncross.lisp-obj
obj/from-xc/src/code/primordial-type.lisp-obj
obj/from-xc/src/code/early-defbangmethod.lisp-obj
obj/from-xc/src/code/defbangtype.lisp-obj
obj/from-xc/src/code/defbangmacro.lisp-obj
obj/from-xc/src/code/defbangconstant.lisp-obj
obj/from-xc/src/code/primordial-extensions.lisp-obj
obj/from-xc/src/code/function-names.lisp-obj
obj/from-xc/src/compiler/generic/parms.lisp-obj
obj/from-xc/src/compiler/x86-64/parms.lisp-obj
obj/from-xc/src/compiler/generic/early-vm.lisp-obj
obj/from-xc/src/compiler/generic/early-objdef.lisp-obj
obj/from-xc/src/code/early-array.lisp-obj
obj/from-xc/src/code/early-extensions.lisp-obj
obj/from-xc/src/code/parse-body.lisp-obj
obj/from-xc/src/code/parse-defmacro.lisp-obj
obj/from-xc/src/compiler/deftype.lisp-obj
obj/from-xc/src/compiler/defconstant.lisp-obj
obj/from-xc/src/code/early-alieneval.lisp-obj
obj/from-xc/src/code/specializable-array.lisp-obj
obj/from-xc/src/code/early-cl.lisp-obj
obj/from-xc/src/code/early-fasl.lisp-obj
obj/from-xc/src/code/debug-var-io.lisp-obj
obj/from-xc/src/code/early-thread.lisp-obj
obj/from-xc/src/code/target-defbangmethod.lisp-obj
obj/from-xc/src/code/early-print.lisp-obj
obj/from-xc/src/code/early-pprint.lisp-obj
obj/from-xc/src/code/early-impl.lisp-obj
obj/from-xc/src/code/target-extensions.lisp-obj
obj/from-xc/src/code/early-package.lisp-obj
obj/from-xc/src/code/early-defstructs.lisp-obj
obj/from-xc/src/code/defbangstruct.lisp-obj
obj/from-xc/src/code/unportable-float.lisp-obj
obj/from-xc/src/code/funutils.lisp-obj
obj/from-xc/src/code/type-class.lisp-obj
obj/from-xc/src/code/ansi-stream.lisp-obj
obj/from-xc/src/code/sysmacs.lisp-obj
obj/from-xc/src/code/target-error.lisp-obj
obj/from-xc/src/compiler/early-backend.lisp-obj
obj/from-xc/output/stuff-groveled-from-headers.lisp-obj
obj/from-xc/src/code/kernel.lisp-obj
obj/from-xc/src/code/toplevel.lisp-obj
obj/from-xc/src/code/cold-error.lisp-obj
obj/from-xc/src/code/fdefinition.lisp-obj
obj/from-xc/src/code/target-type.lisp-obj
obj/from-xc/src/code/pred.lisp-obj
obj/from-xc/src/code/target-alieneval.lisp-obj
obj/from-xc/src/code/target-c-call.lisp-obj
obj/from-xc/src/code/target-allocate.lisp-obj
obj/from-xc/src/code/misc-aliens.lisp-obj
obj/from-xc/src/code/array.lisp-obj
obj/from-xc/src/code/early-float.lisp-obj
obj/from-xc/src/code/target-sxhash.lisp-obj
obj/from-xc/src/code/list.lisp-obj
obj/from-xc/src/code/seq.lisp-obj
obj/from-xc/src/code/coerce.lisp-obj
obj/from-xc/src/code/string.lisp-obj
obj/from-xc/src/code/mipsstrops.lisp-obj
obj/from-xc/src/code/early-time.lisp-obj
obj/from-xc/src/code/unix.lisp-obj
obj/from-xc/src/code/common-os.lisp-obj
obj/from-xc/src/code/linux-os.lisp-obj
obj/from-xc/src/code/sc-offset.lisp-obj
obj/from-xc/src/code/x86-64-vm.lisp-obj
obj/from-xc/src/code/target-signal.lisp-obj
obj/from-xc/src/code/symbol.lisp-obj
obj/from-xc/src/code/bignum.lisp-obj
obj/from-xc/src/code/numbers.lisp-obj
obj/from-xc/src/code/float-trap.lisp-obj
obj/from-xc/src/code/float.lisp-obj
obj/from-xc/src/code/irrat.lisp-obj
obj/from-xc/src/code/char.lisp-obj
obj/from-xc/src/code/huffman.lisp-obj
obj/from-xc/src/code/target-char.lisp-obj
obj/from-xc/src/code/target-misc.lisp-obj
obj/from-xc/src/code/misc.lisp-obj
obj/from-xc/src/code/room.lisp-obj
obj/from-xc/src/code/stream.lisp-obj
obj/from-xc/src/code/print.lisp-obj
obj/from-xc/src/code/pprint.lisp-obj
obj/from-xc/src/code/early-format.lisp-obj
obj/from-xc/src/code/target-format.lisp-obj
obj/from-xc/src/code/defpackage.lisp-obj
obj/from-xc/src/code/pp-backq.lisp-obj
obj/from-xc/src/code/error-error.lisp-obj
obj/from-xc/src/code/deadline.lisp-obj
obj/from-xc/src/code/serve-event.lisp-obj
obj/from-xc/src/code/fd-stream.lisp-obj
obj/from-xc/src/code/module.lisp-obj
obj/from-xc/src/code/interr.lisp-obj
obj/from-xc/src/code/query.lisp-obj
obj/from-xc/src/code/sort.lisp-obj
obj/from-xc/src/code/time.lisp-obj
obj/from-xc/src/code/timer.lisp-obj
obj/from-xc/src/code/weak.lisp-obj
obj/from-xc/src/code/final.lisp-obj
obj/from-xc/src/code/setf-funs.lisp-obj
obj/from-xc/src/code/stubs.lisp-obj
obj/from-xc/src/code/exhaust.lisp-obj
obj/from-xc/src/compiler/early-c.lisp-obj
obj/from-xc/src/compiler/policy.lisp-obj
obj/from-xc/src/compiler/policies.lisp-obj
obj/from-xc/src/code/typedefs.lisp-obj
obj/from-xc/src/compiler/macros.lisp-obj
obj/from-xc/src/compiler/generic/vm-macs.lisp-obj
obj/from-xc/src/compiler/sset.lisp-obj
obj/from-xc/src/compiler/node.lisp-obj
obj/from-xc/src/compiler/vop.lisp-obj
obj/from-xc/src/compiler/backend.lisp-obj
obj/from-xc/src/compiler/vmdef.lisp-obj
obj/from-xc/src/compiler/x86-64/backend-parms.lisp-obj
obj/from-xc/src/compiler/globaldb.lisp-obj
obj/from-xc/src/compiler/info-functions.lisp-obj
obj/from-xc/src/code/force-delayed-defbangconstants.lisp-obj
obj/from-xc/src/code/defmacro.lisp-obj
obj/from-xc/src/code/force-delayed-defbangmacros.lisp-obj
obj/from-xc/src/compiler/late-macros.lisp-obj
obj/from-xc/src/compiler/meta-vmdef.lisp-obj
obj/from-xc/src/compiler/x86-64/vm.lisp-obj
obj/from-xc/src/code/xset.lisp-obj
obj/from-xc/src/code/early-type.lisp-obj
obj/from-xc/src/code/class.lisp-obj
obj/from-xc/src/code/condition.lisp-obj
obj/from-xc/src/compiler/generic/vm-array.lisp-obj
obj/from-xc/src/compiler/generic/primtype.lisp-obj
obj/from-xc/src/compiler/parse-lambda-list.lisp-obj
obj/from-xc/src/code/host-alieneval.lisp-obj
obj/from-xc/src/code/host-c-call.lisp-obj
obj/from-xc/src/compiler/compiler-deftype.lisp-obj
obj/from-xc/src/code/late-type.lisp-obj
obj/from-xc/src/code/deftypes-for-target.lisp-obj
obj/from-xc/src/compiler/knownfun.lisp-obj
obj/from-xc/src/compiler/constantp.lisp-obj
obj/from-xc/src/compiler/fun-info-funs.lisp-obj
obj/from-xc/src/compiler/generic/vm-type.lisp-obj
obj/from-xc/src/compiler/proclaim.lisp-obj
obj/from-xc/src/code/class-init.lisp-obj
obj/from-xc/src/code/typecheckfuns.lisp-obj
obj/from-xc/src/code/defstruct.lisp-obj
obj/from-xc/src/code/target-defstruct.lisp-obj
obj/from-xc/src/code/alien-type.lisp-obj
obj/from-xc/src/code/force-delayed-defbangstructs.lisp-obj
obj/from-xc/src/code/early-full-eval.lisp-obj
obj/from-xc/src/code/typep.lisp-obj
obj/from-xc/src/compiler/compiler-error.lisp-obj
obj/from-xc/src/code/late-deftypes-for-target.lisp-obj
obj/from-xc/src/code/type-init.lisp-obj
obj/from-xc/src/compiler/fixup-type.lisp-obj
obj/from-xc/src/code/package.lisp-obj
obj/from-xc/src/code/random.lisp-obj
obj/from-xc/src/code/hash-table.lisp-obj
obj/from-xc/src/code/readtable.lisp-obj
obj/from-xc/src/code/pathname.lisp-obj
obj/from-xc/src/code/host-pprint.lisp-obj
obj/from-xc/src/compiler/lexenv.lisp-obj
obj/from-xc/src/compiler/fndb.lisp-obj
obj/from-xc/src/compiler/generic/vm-fndb.lisp-obj
obj/from-xc/src/compiler/generic/objdef.lisp-obj
obj/from-xc/src/compiler/generic/interr.lisp-obj
obj/from-xc/src/compiler/bit-util.lisp-obj
obj/from-xc/src/compiler/early-assem.lisp-obj
obj/from-xc/src/code/barrier.lisp-obj
obj/from-xc/src/compiler/generic/core.lisp-obj
obj/from-xc/src/code/thread.lisp-obj
obj/from-xc/src/code/load.lisp-obj
obj/from-xc/src/code/linkage-table.lisp-obj
obj/from-xc/src/code/foreign-load.lisp-obj
unhandled FLOATING-POINT-INVALID-OPERATION in thread #<SB-THREAD:THREAD
                                                       "initial thread" RUNNING
                                                       {A9ECFA9}>:
  arithmetic error FLOATING-POINT-INVALID-OPERATION signalled

0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {B82402D}>)[:EXTERNAL]
1: (SB-DEBUG:BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {90C08F9}>)
2: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<FLOATING-POINT-INVALID-OPERATION {B822BC1}>
    #<unavailable argument>)
3: (SB-DEBUG::RUN-HOOK
    SB-EXT:*INVOKE-DEBUGGER-HOOK*
    #<FLOATING-POINT-INVALID-OPERATION {B822BC1}>)
4: (INVOKE-DEBUGGER #<FLOATING-POINT-INVALID-OPERATION {B822BC1}>)
5: (ERROR FLOATING-POINT-INVALID-OPERATION)[:EXTERNAL]
6: (SB-VM:SIGFPE-HANDLER
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #XF7ACD47C)
    #<unavailable argument>)
7: ((FLET #:WITHOUT-INTERRUPTS-BODY-[WITHOUT-INTERRUPTS-BODY-[INVOKE-INTERRUPTION]11]18))
8: ((FLET #:WITHOUT-INTERRUPTS-BODY-[INVOKE-INTERRUPTION]11))
9: (SB-SYS:INVOKE-INTERRUPTION
    #<CLOSURE (FLET SB-UNIX::INTERRUPTION) {F7ACD24D}>)
10: (SB-SYS:INVOKE-INTERRUPTION
     #<CLOSURE (FLET SB-UNIX::INTERRUPTION) {F7ACD24D}>)[:EXTERNAL]
11: ((FLET SB-UNIX::RUN-HANDLER)
     8
     #.(SB-SYS:INT-SAP #XF7ACD47C)
     #.(SB-SYS:INT-SAP #XF7ACD4FC))
12: ((FLET SB-UNIX::RUN-HANDLER)
     8
     #.(SB-SYS:INT-SAP #XF7ACD47C)
     #.(SB-SYS:INT-SAP #XF7ACD4FC))[:OPTIONAL]
13: ((FLET SB-UNIX::RUN-HANDLER))[:EXTERNAL]
14: ("foreign function: #x806761B")
15: ("foreign function: #x8052E4E")
16: ("foreign function: #x8058E10")
17: ("foreign function: #x80595B5")
18: (SB-IMPL::FD-STREAM-READ-N-BYTES
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>
     #(40 4 1 3 27 ...)
     0
     512
     NIL)
19: (SB-INT:FAST-READ-BYTE-REFILL
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>
     T
     NIL)
20: (READ-BYTE
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>
     T
     NIL)
21: (SB!FASL::READ-STRING-AS-BYTES
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>
     "SYS:SRC;CODE;FOREIGN-LOAD."
     30)
22: (SB!FASL::COLD-FOP-SMALL-BASE-STRING)
23: (SB!FASL::LOAD-FASL-GROUP
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>)
24: (SB!FASL::LOAD-AS-FASL
     #<SB-SYS:FD-STREAM
       for "file /m/a/tmp/builds/sbcl/sbcl-1.0.42/obj/from-xc/src/code/foreign-load.lisp-obj"
       {B817C21}>
     NIL
     #<unavailable argument>)
25: (SB!FASL::COLD-LOAD #P"obj/from-xc/src/code/foreign-load.lisp-obj")
26: (SB!VM:GENESIS)[:EXTERNAL]
27: (SB-INT:SIMPLE-EVAL-IN-LEXENV
     (SB!VM:GENESIS :OBJECT-FILE-NAMES *TARGET-OBJECT-FILE-NAMES*
                    :C-HEADER-DIR-NAME "output/genesis-2" ...)
     #<NULL-LEXENV>)
28: (SB-EXT:INTERACTIVE-EVAL
     (SB!VM:GENESIS :OBJECT-FILE-NAMES *TARGET-OBJECT-FILE-NAMES*
                    :C-HEADER-DIR-NAME "output/genesis-2" ...))[:EXTERNAL]
29: (SB-IMPL::REPL-FUN NIL)
30: ((LAMBDA ()))
31: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {A9EF31D}>)
32: (SB-IMPL::TOPLEVEL-REPL NIL)
33: (SB-IMPL::TOPLEVEL-INIT)
34: ((LABELS SB-IMPL::RESTART-LISP))

unhandled condition in --disable-debugger mode, quitting

Re: [Sbcl-help] Trouble compiling sbcl on onpensuse-11.2 amd64

From: Josef Wolf <jw@ra...> - 2010-09-18 00:10

On Fri, Sep 17, 2010 at 09:59:23AM +0200, Josef Wolf wrote:

> I might try to run the build over and over again until it happens again. One
> build lasts about 1 hour on this machine, so it might take a while until it
> happens again (if at all).

Though it might be annoying, I think I should share what I found up to now.

I am building over and over again with the same build script, and get
seemingly non-deterministic results.

Problem is, that I have not payed attention on the _exact_ environment with
my first compiles. So there's room for uncertainty here.

What I can say for sure is that for the last 7 hours not a single build had
a problem. (a build including tests lasts about 20 minutes on this machine).

Before that, I had arbitrary failures on almost every other build (I posted
two of them onto this list, but there were more failures).

The only difference I can see is:

- the (successful) builds of the last seven hours were run from a kde
  terminal.
- the arbitrarily failing builds were run from a screen session (which is
  actually highly recommended on http://sbcl.sourceforge.net/getting.html)

I can not tell for sure, since I have not payed attention from the very first
builds. But I can tell for sure that since I started pay attention, I had not
a single failure in KDE terminal but lots of failures in screen sessions.

So I think the question has to be rephrased: what is so special about screen
sessions that could provoke broken builds?

Thinking a little about it leads to signals. When a screen session is
de/re-attached from different machines, resize signals are pretty much to be
expected. What happens when the build process receives signals? Could that
be the cause of the problems?

Next Messages