Steel Bank Common Lisp

Mirko Vukovic <mirko.vukovic@...> writes:

> On Wed, Aug 15, 2012 at 8:59 AM, Giovanni Gigante <giov@...> wrote:
>>
>> Il giorno 15/ago/2012, alle ore 14:35, Mirko Vukovic <mirko.vukovic@...> ha scritto:
>>
>>> The current version of sbcl 1.059 requires glibc2.14, but glibc on
>>> RedHat EL 6 is 2.12, and will remain so forever.
>>> How shall I deal with this restriction?
>>> - Compile necessary version of glibc and place it in /usr/local
>>> - Someone on the redhat mailing list pointed me to chroot.  That would
>>> be uncharted territory for me.
>>
>> I had a similar problem with an old Debian machine. Solution:
>> 1. grab an older binary of sbcl which does not require a shiny new glibc and install it.
>> 2. download the latest source of sbcl and compile it (the compiler is the old sbcl you've just installed).
>> 3. when compiled, install it, replacing the older one.
>> It may sound complicated but it's actually very easy to do.
>>
>> gg
>>
>
> I finished compiling 1.059 and the regression tests on 64-bit AMD.
>
> The message at the end of regression tests is:
>
> Finished running tests.
> Status:
>  Invalid exit status: packages.impure.lisp
>  (3 tests skipped for this combination of platform and features)
> test failed, expected 104 return code, got 1
>
> What am I to make of this message?
Can you post the output of the tests?

-- 
With best regards, Stas.

On Wed, Aug 15, 2012 at 11:07 AM, Stas Boukarev <stassats@...> wrote:
> Mirko Vukovic <mirko.vukovic@...> writes:
>
>> On Wed, Aug 15, 2012 at 8:59 AM, Giovanni Gigante <giov@...> wrote:
>>>
>>> Il giorno 15/ago/2012, alle ore 14:35, Mirko Vukovic <mirko.vukovic@...> ha scritto:
>>>
>>>> The current version of sbcl 1.059 requires glibc2.14, but glibc on
>>>> RedHat EL 6 is 2.12, and will remain so forever.
>>>> How shall I deal with this restriction?
>>>> - Compile necessary version of glibc and place it in /usr/local
>>>> - Someone on the redhat mailing list pointed me to chroot.  That would
>>>> be uncharted territory for me.
>>>
>>> I had a similar problem with an old Debian machine. Solution:
>>> 1. grab an older binary of sbcl which does not require a shiny new glibc and install it.
>>> 2. download the latest source of sbcl and compile it (the compiler is the old sbcl you've just installed).
>>> 3. when compiled, install it, replacing the older one.
>>> It may sound complicated but it's actually very easy to do.
>>>
>>> gg
>>>
>>
>> I finished compiling 1.059 and the regression tests on 64-bit AMD.
>>
>> The message at the end of regression tests is:
>>
>> Finished running tests.
>> Status:
>>  Invalid exit status: packages.impure.lisp
>>  (3 tests skipped for this combination of platform and features)
>> test failed, expected 104 return code, got 1
>>
>> What am I to make of this message?
> Can you post the output of the tests?
>
> --
> With best regards, Stas.

Um, what output? Some specific files (or directory content) or
captured screen output?

Mirko

Mirko Vukovic <mirko.vukovic@...> writes:

> On Wed, Aug 15, 2012 at 11:07 AM, Stas Boukarev <stassats@...> wrote:
>> Mirko Vukovic <mirko.vukovic@...> writes:
>>
>>> On Wed, Aug 15, 2012 at 8:59 AM, Giovanni Gigante <giov@...> wrote:
>>>>
>>>> Il giorno 15/ago/2012, alle ore 14:35, Mirko Vukovic <mirko.vukovic@...> ha scritto:
>>>>
>>>>> The current version of sbcl 1.059 requires glibc2.14, but glibc on
>>>>> RedHat EL 6 is 2.12, and will remain so forever.
>>>>> How shall I deal with this restriction?
>>>>> - Compile necessary version of glibc and place it in /usr/local
>>>>> - Someone on the redhat mailing list pointed me to chroot.  That would
>>>>> be uncharted territory for me.
>>>>
>>>> I had a similar problem with an old Debian machine. Solution:
>>>> 1. grab an older binary of sbcl which does not require a shiny new glibc and install it.
>>>> 2. download the latest source of sbcl and compile it (the compiler is the old sbcl you've just installed).
>>>> 3. when compiled, install it, replacing the older one.
>>>> It may sound complicated but it's actually very easy to do.
>>>>
>>>> gg
>>>>
>>>
>>> I finished compiling 1.059 and the regression tests on 64-bit AMD.
>>>
>>> The message at the end of regression tests is:
>>>
>>> Finished running tests.
>>> Status:
>>>  Invalid exit status: packages.impure.lisp
>>>  (3 tests skipped for this combination of platform and features)
>>> test failed, expected 104 return code, got 1
>>>
>>> What am I to make of this message?
>> Can you post the output of the tests?
>>
>> --
>> With best regards, Stas.
>
> Um, what output? Some specific files (or directory content) or
> captured screen output?
The output of running run-tests.sh.

-- 
With best regards, Stas.

Mirko Vukovic <mirko.vukovic@...> writes:
> I am attaching output of
> sh run-tests.sh 2>&1 > tests.out
>
> That command did not capture all of the messages (such as stack
> restart options and backtraces).  I don't know how to capture that.
It contains everything I needed.
So, the following test fails, as in the test itself fails 

(with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
  (let* ((p (make-package :bug-511072))
         (sem (sb-thread:make-semaphore))
         (t2 (sb-thread:make-thread (lambda ()
                                      (handler-bind ((error (lambda (c)
                                                              (sb-thread:signal-semaphore sem)
                                                              (signal c))))
                                        (make-package :bug-511072))))))
    (sb-thread:wait-on-semaphore sem)
    (assert (eq 'cons (read-from-string "CL:CONS")))))

It seems that the handler-bind takes no effect. I can't reproduce this.
Can you run that form (sans with-test part) in a regular REPL?


-- 
With best regards, Stas.

On Wed, Aug 15, 2012 at 1:48 PM, Stas Boukarev <stassats@...> wrote:
> Mirko Vukovic <mirko.vukovic@...> writes:
>> I am attaching output of
>> sh run-tests.sh 2>&1 > tests.out
>>
>> That command did not capture all of the messages (such as stack
>> restart options and backtraces).  I don't know how to capture that.
> It contains everything I needed.
> So, the following test fails, as in the test itself fails
>
> (with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
>   (let* ((p (make-package :bug-511072))
>          (sem (sb-thread:make-semaphore))
>          (t2 (sb-thread:make-thread (lambda ()
>                                       (handler-bind ((error (lambda (c)
>                                                               (sb-thread:signal-semaphore sem)
>                                                               (signal c))))
>                                         (make-package :bug-511072))))))
>     (sb-thread:wait-on-semaphore sem)
>     (assert (eq 'cons (read-from-string "CL:CONS")))))
>
> It seems that the handler-bind takes no effect. I can't reproduce this.
> Can you run that form (sans with-test part) in a regular REPL?
>
>
> --
> With best regards, Stas.

>From the repl:

*********************************************************************
(let* ((p (make-package :bug-511072))
(sem (sb-thread:make-semaphore))
(t2 (sb-thread:make-thread (lambda ()
(handler-bind ((error (lambda (c)
(sb-thread:signal-semaphore sem)
(signal c))))
(make-package :bug-511072))))))
(sb-thread:wait-on-semaphore sem)
(assert (eq 'cons (read-from-string "CL:CONS"))))
; in:
;      LET* ((P (MAKE-PACKAGE :BUG-511072)) (SEM (SB-THREAD:MAKE-SEMAPHORE))
;        (T2
;         (SB-THREAD:MAKE-THREAD
;          (LAMBDA ()
;            (HANDLER-BIND #
;              #)))))
;     (LET* ((P (MAKE-PACKAGE :BUG-511072))
;            (SEM (SB-THREAD:MAKE-SEMAPHORE))
;            (T2 (SB-THREAD:MAKE-THREAD (LAMBDA # #))))
;       (SB-THREAD:WAIT-ON-SEMAPHORE SEM)
;       (ASSERT (EQ 'CONS (READ-FROM-STRING "CL:CONS"))))
;
; caught STYLE-WARNING:
;   The variable P is defined but never used.
;
; caught STYLE-WARNING:
;   The variable T2 is defined but never used.
;
; compilation unit finished
;   caught 2 STYLE-WARNING conditions

NIL
*
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD RUNNING {1002A0EC23}>:
  A package named :BUG-511072 already exists

********************************************************************

I get the same error when I execute in 1.054 (which I installed as a
downloaded binary)

Mirko

Stas Boukarev <stassats@...> writes:

> Mirko Vukovic <mirko.vukovic@...> writes:
>> I am attaching output of
>> sh run-tests.sh 2>&1 > tests.out
>>
>> That command did not capture all of the messages (such as stack
>> restart options and backtraces).  I don't know how to capture that.
> It contains everything I needed.
> So, the following test fails, as in the test itself fails 
>
> (with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
>   (let* ((p (make-package :bug-511072))
>          (sem (sb-thread:make-semaphore))
>          (t2 (sb-thread:make-thread (lambda ()
>                                       (handler-bind ((error (lambda (c)
>                                                               (sb-thread:signal-semaphore sem)
>                                                               (signal c))))
>                                         (make-package :bug-511072))))))
>     (sb-thread:wait-on-semaphore sem)
>     (assert (eq 'cons (read-from-string "CL:CONS")))))
Ok, I got why it fails and why it doesn't. The handler-bind doesn't
prevent the error from invoking the debugger, but, my SBCL exits faster
than it can complain about it. Adding (sleep 5) at the end of the file
lets me reproduce it.

Committed a fix, thanks for the report.

-- 
With best regards, Stas.

On Wed, Aug 15, 2012 at 2:10 PM, Stas Boukarev <stassats@...> wrote:
> Stas Boukarev <stassats@...> writes:
>
>> Mirko Vukovic <mirko.vukovic@...> writes:
>>> I am attaching output of
>>> sh run-tests.sh 2>&1 > tests.out
>>>
>>> That command did not capture all of the messages (such as stack
>>> restart options and backtraces).  I don't know how to capture that.
>> It contains everything I needed.
>> So, the following test fails, as in the test itself fails
>>
>> (with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
>>   (let* ((p (make-package :bug-511072))
>>          (sem (sb-thread:make-semaphore))
>>          (t2 (sb-thread:make-thread (lambda ()
>>                                       (handler-bind ((error (lambda (c)
>>                                                               (sb-thread:signal-semaphore sem)
>>                                                               (signal c))))
>>                                         (make-package :bug-511072))))))
>>     (sb-thread:wait-on-semaphore sem)
>>     (assert (eq 'cons (read-from-string "CL:CONS")))))
> Ok, I got why it fails and why it doesn't. The handler-bind doesn't
> prevent the error from invoking the debugger, but, my SBCL exits faster
> than it can complain about it. Adding (sleep 5) at the end of the file
> lets me reproduce it.
>
> Committed a fix, thanks for the report.
>
> --
> With best regards, Stas.

I'm glad that you found the error and the fix.

Going back to my test harness run,  is my sbcl ok?

Mirko

Mirko Vukovic <mirko.vukovic@...> writes:

> On Wed, Aug 15, 2012 at 2:10 PM, Stas Boukarev <stassats@...> wrote:
>> Stas Boukarev <stassats@...> writes:
>>
>>> Mirko Vukovic <mirko.vukovic@...> writes:
>>>> I am attaching output of
>>>> sh run-tests.sh 2>&1 > tests.out
>>>>
>>>> That command did not capture all of the messages (such as stack
>>>> restart options and backtraces).  I don't know how to capture that.
>>> It contains everything I needed.
>>> So, the following test fails, as in the test itself fails
>>>
>>> (with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
>>>   (let* ((p (make-package :bug-511072))
>>>          (sem (sb-thread:make-semaphore))
>>>          (t2 (sb-thread:make-thread (lambda ()
>>>                                       (handler-bind ((error (lambda (c)
>>>                                                               (sb-thread:signal-semaphore sem)
>>>                                                               (signal c))))
>>>                                         (make-package :bug-511072))))))
>>>     (sb-thread:wait-on-semaphore sem)
>>>     (assert (eq 'cons (read-from-string "CL:CONS")))))
>> Ok, I got why it fails and why it doesn't. The handler-bind doesn't
>> prevent the error from invoking the debugger, but, my SBCL exits faster
>> than it can complain about it. Adding (sleep 5) at the end of the file
>> lets me reproduce it.
>>
>> Committed a fix, thanks for the report.
>>
>> --
>> With best regards, Stas.
>
> I'm glad that you found the error and the fix.
>
> Going back to my test harness run,  is my sbcl ok?
Yes, it was just a faulty test.

-- 
With best regards, Stas.

On Wed, Aug 15, 2012 at 2:17 PM, Stas Boukarev <stassats@...> wrote:
> Mirko Vukovic <mirko.vukovic@...> writes:
>
>> On Wed, Aug 15, 2012 at 2:10 PM, Stas Boukarev <stassats@...> wrote:
>>> Stas Boukarev <stassats@...> writes:
>>>
>>>> Mirko Vukovic <mirko.vukovic@...> writes:
>>>>> I am attaching output of
>>>>> sh run-tests.sh 2>&1 > tests.out
>>>>>
>>>>> That command did not capture all of the messages (such as stack
>>>>> restart options and backtraces).  I don't know how to capture that.
>>>> It contains everything I needed.
>>>> So, the following test fails, as in the test itself fails
>>>>
>>>> (with-test (:name :bug-511072 :skipped-on '(not :sb-thread))
>>>>   (let* ((p (make-package :bug-511072))
>>>>          (sem (sb-thread:make-semaphore))
>>>>          (t2 (sb-thread:make-thread (lambda ()
>>>>                                       (handler-bind ((error (lambda (c)
>>>>                                                               (sb-thread:signal-semaphore sem)
>>>>                                                               (signal c))))
>>>>                                         (make-package :bug-511072))))))
>>>>     (sb-thread:wait-on-semaphore sem)
>>>>     (assert (eq 'cons (read-from-string "CL:CONS")))))
>>> Ok, I got why it fails and why it doesn't. The handler-bind doesn't
>>> prevent the error from invoking the debugger, but, my SBCL exits faster
>>> than it can complain about it. Adding (sleep 5) at the end of the file
>>> lets me reproduce it.
>>>
>>> Committed a fix, thanks for the report.
>>>
>>> --
>>> With best regards, Stas.
>>
>> I'm glad that you found the error and the fix.
>>
>> Going back to my test harness run,  is my sbcl ok?
> Yes, it was just a faulty test.
>
> --
> With best regards, Stas.

Thanks :-)