Test failure on freebsd/x86-64 with threads enabled

I decided to try out a build with threads enabled on freebsd 7/x86-64,
with these test results:

Status:
 Expected failure:    callback.impure.lisp / UNDERFLOW-DETECTION
 Invalid exit status: clos-add-remove-method.impure.lisp
 Invalid exit status: clos-cache.impure.lisp
 Invalid exit status: clos-interrupts.impure.lisp
 Invalid exit status: compare-and-swap.impure.lisp
 Invalid exit status: deadline.impure.lisp
 Invalid exit status: debug.impure.lisp
 Expected failure:    external-format.impure.lisp / (CHARACTER-DECODE-LARGE
                                                     FORCE-END-OF-FILE)
 Invalid exit status: gc.impure.lisp
 Invalid exit status: hash.impure.lisp
 Expected failure:    packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
 Expected failure:    packages.impure.lisp / IMPORT-SINGLE-CONFLICT
 Invalid exit status: threads.impure.lisp
 Invalid exit status: timer.impure.lisp
test failed, expected 104 return code, got 1

Now the funny thing is all those "Invalid exit status" ones: In each
case, sbcl was hanging, apparently in I/O wait (ps showed the state
first as I+, then as S+, and ktrace indicated it was hanging in a
nanosleep), and I just did a kill -KILL on it to get on with the next
test.

I'll just keep on using the non-threaded version for now, but thought
I'd report this in case anybody has an inkling as to what is
happening. Let me know if there is anything I can do to obtain more

Duplicate emails from me

I apologize for the seemingly endless spew of duplicate emails from me
to sbcl-devel.

As far as I can tell it is a brokenness of some kind between Gmail and
Sourceforge SMTP. My best guess at the moment is that Sourceforge does
something that Gmail interpets as meaning "didn't make it, need to
resend later" -- when in fact the message was received and delivered
fine the first time.

...but since this interaction is between Gmail and Sourceforge, there
is relatively little I can do about it except file tickets...

Sorry for the inconvenience all around,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

RFC: --script commandline argument

Attached patch implements one of the perpetual wishlist items:
--script commandline argument.

Only one --script can be given. It can be passed either in runtime or
toplevel section.

In runtime section it implies --noinform, and propagates itself to the
toplevel section.

In toplevel section it implies --disable-debugger, and means that SBCL
should LOAD the specified file after userinit, sysinit, --load and
--eval processing (with :VERBOSE NIL, :PRINT NIL), and then exit
without entering the REPL.

The fact that initfiles are processed means that users can stick
(sb-ext:enable-debugger) in .sbclrc to have access to debugger in
scripts.

The patch does not include any documentation, as I didn't want to
start writing it before getting some input...

Cheers,

 -- Nikodemus

From e8a39587f845f70cca0f44f084a094032608b6d2 Mon Sep 17 00:00:00 2001
From: Nikodemus Siivola <nikodemus <at> random-state.net>
Date: Tue, 7 Oct 2008 11:33:57 +0300
Subject: [PATCH] --script commandline argument

define-compiler-macro lambda list parsing

Using sbcl-1.0.20-x86-darwin:

    (define-compiler-macro foo ((x)) nil)

variable #:REQUIRED-977 occurs more than once
  [Condition of type SIMPLE-ERROR]

Backtrace:
 0: (SB-KERNEL::CHECK-DEFMACRO-ARG #:REQUIRED-977)
 1: (SB-KERNEL::PUSH-LET-BINDING #:REQUIRED-977 #:REQUIRED-977)[:EXTERNAL]
 2: (SB-KERNEL::PARSE-DEFMACRO-LAMBDA-LIST (X) #:REQUIRED-977 FOO
DEFINE-COMPILER-MACRO)[:EXTERNAL]
 3: (SB-KERNEL::PARSE-DEFMACRO-LAMBDA-LIST ((X)) #:WHOLE974 FOO
DEFINE-COMPILER-MACRO)[:EXTERNAL]
 4: (SB-KERNEL:PARSE-DEFMACRO ((X)) #:WHOLE974 (NIL) FOO
DEFINE-COMPILER-MACRO)[:EXTERNAL]
 5: ((LAMBDA (#:WHOLE120 #:ENVIRONMENT121)) (DEFINE-COMPILER-MACRO
FOO ((X)) NIL) #<unavailable argument..
 6: (MACROEXPAND-1 (DEFINE-COMPILER-MACRO FOO ((X)) NIL) #<NULL-LEXENV>)
 7: (MACROEXPAND (DEFINE-COMPILER-MACRO FOO ((X)) NIL) #<NULL-LEXENV>)
 8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DEFINE-COMPILER-MACRO FOO ((X))
NIL) #<NULL-LEXENV>)
 --more--

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Fwd: broken semaphores or broken test?

Hmph, this didn't make the through the first time, it seems. (Fix went
in as 1.0.20.10)

 -- Nikodemus

---------- Forwarded message ----------
From: Nikodemus Siivola <nikodemus <at> random-state.net>
Date: Fri, Sep 19, 2008 at 3:40 PM
Subject: Re: [Sbcl-devel] broken semaphores or broken test?
To: Kalyanov Dmitry <kalyanov.dmitry <at> gmail.com>
Cc: sbcl-devel <at> lists.sourceforge.net

On Thu, Sep 18, 2008 at 3:39 PM, Kalyanov Dmitry
<kalyanov.dmitry <at> gmail.com> wrote:

My problem is a bug in our semaphore implementation after all.

Wakeups happen if the semaphore was at 0 prior to signal-semaphore.
Consider the case where you have multiple waiters on a semaphore, and
another thread doing signal-semaphore with increment of 1.

T1 waiting
T2 waiting
T3 signal-semaphore, wakes up 1 thread
T1 wakes up, but doesn't manage to decrement the counter during its timeslice
T3 signal-semaphore -- counter already 1, no wakeup
T1 decrements, returns from wait

...T2 is never woken up even though the semaphore is at 1. Eugh. We
need to keep track of sleepers -- I have a fix which I'm committing

A bug in SBCL 1.0.20?

Hi everybody,

Every once in a while(every 1-3 days?) I get the following error popping 
up in SLIME.
I'm running SBCL 1.0.20 on Fedora 9, x86_64,
Linux 2.6.26.3-29.fc9.x86_64
This doesn't seem to be tied to any usage pattern.
This is the full backtrace, please let me know if I can give you any 
more information.

NIL have bad file descriptors.
    [Condition of type SIMPLE-ERROR]

Restarts:
  0: [REMOVE-THEM] Remove bogus handlers.
  1: [RETRY-THEM] Retry bogus handlers.
  2: [CONTINUE] Go on, leaving handlers marked as bogus.
  3: [ABORT] Exit debugger, returning to top level.

Backtrace:
   0: (SB-IMPL::HANDLER-DESCRIPTORS-ERROR)
   1: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL)
   2: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL)
   3: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)
   4: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard 
input" {100240DE91}>)
   5: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" 
{100240DE91}> NIL #:EOF-OBJECT)
   6: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {100240DE91}> 
NIL #:EOF-OBJECT #<unused argument>..

test, please ignore

EOM

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Reading single floats bug

There is a problem with the reader for a structure containing a single-float:

(defstruct foo
   (x 0.0 :type single-float))

(read-from-string "((#1=#S(foo :x 2.7158911)))")

On SBCL 1.0.14, Ubuntu AMD64, with (optimize debug safety), this
causes a Memory Fault. The system punts in the circularity treatment.
If I remove the #1=, the example runs fine (though if I remember
correctly, something *still* got corrupted in my larger program,
leading to the death of SBCL without any warning)

The problem is dependent on this particular floating-point value. It
appears to be a valid single-float. If I print readably (make-foo :x
2.7158911), I get the string above, minus the #1= and some
parentheses...

Thanks.

Cédric

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

[PATCH] WHO-SPECIALIZES

The following patch adds, and exports, WHO-SPECIALIZES to the
SB-INTROSPECT contrib. I'll commit support for it into SBCL's SWANK
backend in a few minutes, too.

  -T.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Issue with my SBCL setup... Still

On Fri, Oct 3, 2008 at 11:58 PM, Olivier Drolet <trimtab <at> mac.com> wrote:
> Greetings,
>
> I'm running the latest Slime, Aquamacs 1.5, and SBCL 1.0.21 on Mac OS
> X 10.5.5. for PPC, on an iMac G5 1.8.
>
> Although SBCL compiles correctly, when I "M-x slime" it in Aquamacs, I
> get the following message:
>
> "error in process filter: Symbol's function definition is void:
> defpackage"
>
> Plus, the appearance of the REPL (prompt) in Aquamacs is all weird.
> The compiler works, but the code colouring is gone and spaces between
> the prompt and result is off (the result is grouped witn the follwing
> prompt). When I try "M-x slime" anew, and select option "n", the
> appearance of the repl pops back to its normal state, but the new SBCL
> process runs wild and consumes 100% cpu. After I kill all SBCL process
> and "M-x slime" again, the REPL appearance remains normal and the
> compiler seems to work.
>
> But, unfortunately, all slime key-chords seem broken. E.g., loading a
> file, when I do C-c C-k, the system complains that that key-chord is
> "undefined". 
>
> Any ideas? Is this rather strictly a slime issue?

Almost certainly a Slime / Aquaemacs issue, yes. slime-devel may want
to know, forwarded. (No followups to sbcl-devel, please.)

function type not updated on redefinition

;; Hit C-c C-c on this
(defun foo (x)
  x)

;; Then on this
(defun foo (x &optional y)
  (or x y))

;; Then on this, note the bogus STYLE-WARNING
(defun bar (x y)
  (foo x y))

What happens is that redefining a function that previously had only required
arguments with optional ones does not update the type signature correctly. I
have not verified it, but I believe this is an ancient bug -- just one that
used to be invisible until the recentish stricter call type checking.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/