Thiemo Seufer | 1 May 01:04 2005
Picon

Re: More MIPS-related patches

Christophe Rhodes wrote:
[snip]
> > Ignore tests which currently fail on mips. foreign.test.sh is the
> > odd one out, mips falls in the debugger, I haven't had a closer look
> > yet.
> 
> ... tests which fail.  I don't like this, because the tests lose their
> documenting and nagging nature in this case.  On the other hand, if
> this is what is required for Peter's debian package, that's fine, and
> he can track mainline but with tests deactivated.

Since the tests stop at the first bad one, the alternative would be
to disable them completely for mips/mipsel. That's clearly worse than
disabling only some of them.

> > The stat-related test failures in contrib/posix are most likely
> > caused by a inconsistent structure definition which doesn't match
> > the one used by linux/mips. There's probably a way to automatically
> > extract it from /usr/include/bits/stat.h, but that's not done in the
> > current implementation.
> 
> It is meant to be done: contrib/sb-posix/constants.lisp is processed
> by sb-grovel, emitting contrib/sb-posix/constants.lisp-tmp which is
> then processed as a lisp file.  sb-grovel is meant to use the C
> compiler to grovel a machine-specific structure, and stat is one such
> that we ask for: see alien-stat in contrib/sb-posix/constants.lisp.

Ah, I see. sb-grovel misses -D_FILE_OFFSET_BITS=64, which is default
on mips linux. (The proper value for the glibc in use can be looked up
via `getconf LFS_CFLAGS`.)
(Continue reading)

Friedrich Dominicus | 1 May 07:00 2005
Picon

SBCL on AMD64

My further tries have give new information
I downloaded the newest binary verson 0.9.0 and tried to compile the
CVS sources with it. It bails out at:
; compiling (DEFUN WALK-IF ...)

; /opt/src/sbcl/obj/from-host/src/pcl/walk.lisp-obj-tmp written
; compilation finished in 0:00:03
[doing purification: roots handlers stack bindings staticunhandled SB-KERNEL::MEMORY-FAULT-ERROR
in thread 6584: memory fault

but with an extra backtrace:
0: (SB-DEBUG:BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {400CE861}>)1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
    #<SB-KERNEL::MEMORY-FAULT-ERROR {1000952D21}>
    #<unavailable argument>)
2: (INVOKE-DEBUGGER #<SB-KERNEL::MEMORY-FAULT-ERROR {1000952D21}>)
3: (ERROR SB-KERNEL::MEMORY-FAULT-ERROR)
4: (SB-KERNEL::MEMORY-FAULT-ERROR)
5: ("foreign function: call_into_lisp")
6: ("foreign function: post_signal_tramp")
7: ("foreign function: tan")
8: ("foreign function: tan")
9: ("foreign function: tan")
10: ("foreign function: tan")
11: ("foreign function: tan")
12: ("foreign function: tan")
13: ("foreign function: tan")
14: ("foreign function: tan")
15: ("foreign function: purify")
16: (SB-KERNEL::%PURIFY 1073741847 1073741847)
17: ("foreign function: #x268EF47A")
(Continue reading)

Christophe Rhodes | 1 May 09:15 2005
Picon
Picon

Re: More MIPS-related patches

Thiemo Seufer <ths <at> networkno.de> writes:

> Christophe Rhodes wrote:
> [snip]
>> > Ignore tests which currently fail on mips. foreign.test.sh is the
>> > odd one out, mips falls in the debugger, I haven't had a closer look
>> > yet.
>> 
>> ... tests which fail.  I don't like this, because the tests lose their
>> documenting and nagging nature in this case.  On the other hand, if
>> this is what is required for Peter's debian package, that's fine, and
>> he can track mainline but with tests deactivated.
>
> Since the tests stop at the first bad one, the alternative would be
> to disable them completely for mips/mipsel. That's clearly worse than
> disabling only some of them.

Sorry, I wasn't clear.  What I'm suggesting is that Peter, for Debian
packaging, maintains as part of the Debian .diff.gz a patch which
disables failing tests on platforms for which a .deb is built: at
least for those tests which really ought not to fail, such as the
foreign test.  The distinction I want to draw is between automatically
running the tests, in which case known failures should not be run, and
manually running the tests, in which case the nag value of having to
delete files and rerun tests is partially worthwhile.  (Though not, I
admit, as worthwhile as having a test suite which has known failure
information, and collates results at the end.)

>> Is the status now that, apart from these failing tests, the mips/linux
>> (and mipsel/linux) builds are expected to work?
(Continue reading)

Christophe Rhodes | 1 May 10:54 2005
Picon
Picon

Re: building sbcl with :sb-show on OS X fails

Alan Ruttenberg <alanr-l <at> mumble.net> writes:

> Should it?

Probably not, though :sb-show isn't intended as a user-visible feature
-- just a developer's debugging aid.

> Glad to provide details, if this is hard to reproduce.

Dunno.  Any other OS X people want to comment?

Cheers,

Christophe

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Christophe Rhodes | 1 May 11:12 2005
Picon
Picon

Re: Obsolete passage in Manual re FFI

Adam Warner <lists <at> consulting.net.nz> writes:

> Characters in SBCL strings are now stored as 32-bit values:

and

>    Once the C code has been compiled, you can start up Lisp and load it
>    in: sbcl Lisp should start up with its normal prompt.

Thanks.  I've tried to clarify these two points in sbcl-0.9.0.13.

Cheers,

Christophe

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Christophe Rhodes | 1 May 11:12 2005
Picon
Picon

Re: typos in the SBCL manual

Peter BARABAS <z0d <at> artifact.hu> writes:

> I've found some typos in the on-line manual of SBCL.

Thanks.  I finally got round to dealing with these in sbcl-0.9.0.13.

Cheers,

Christophe

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Christophe Rhodes | 1 May 11:13 2005
Picon
Picon

Re: Patch to diminish the annoyance of character restarts

Teemu Kalvas <chery <at> s2.org> writes:

> I've added some tests for external format behaviour, including using
> the restarts. There are comments in the tests themselves for what I
> think is being tested.

Thanks.  I've included them in sbcl-0.9.0.13.

Cheers,

Christophe

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
Lutz Euler | 1 May 15:31 2005
Picon

A fix for a FIXME in generic subtraction on x86-64/x86

Hi,

in src/assembly/x86[-64]/arith.lisp in
  (define-generic-arith-routine (- 10) ...)
one finds the following comment:

  ;; FIXME: This is screwed up.
    ;;; I can't figure out the flags on subtract. Overflow never gets
    ;;; set and carry always does. (- 0 most-negative-fixnum) can't be
    ;;; easily detected so just let the upper level stuff do it.

To unupscrew this, a "complement carry" is all that is needed:

  (inst sub res y)
  (inst jmp :no OKAY)
  (inst cmc)           ; carry has correct sign now
  (inst rcr res 1)
  (inst sar res 2)     ; remove type bits

Please find attached a patch that implements this for both x86-64
and x86.

To the one who wrote "I can't figure out the flags on subtract" and
for other curious party here is an explanation of why this works:

A good description of the behaviour of the flags can be found in the
manual "AMD64 Architecture Programmer's Manual Volume 1: Application
Programming" in chapter 3.1.4 "Flags Register". In essence, it says:
The overflow flag (OF) is set if the result of the subtraction doesn't
fit in a signed word, i.e., if it is larger than 2^63-1 or smaller than
(Continue reading)

Nikodemus Siivola | 1 May 09:52 2005
Picon

Re: Re: More MIPS-related patches

On Sun, 1 May 2005, Thiemo Seufer wrote:

>>> Ignore tests which currently fail on mips. foreign.test.sh is the
>>> odd one out, mips falls in the debugger, I haven't had a closer look
>>> yet.

That's probably my fault: IIRC I tried to be too clever for anyone's good 
with *DEBUGGER-HOOK* there. Or maybe I accidentally left it in a state
intended for easy of debugging, not pass-or-die tests.

>> ... tests which fail.  I don't like this, because the tests lose their
>> documenting and nagging nature in this case.  On the other hand, if
>> this is what is required for Peter's debian package, that's fine, and
>> he can track mainline but with tests deactivated.
>
> Since the tests stop at the first bad one, the alternative would be
> to disable them completely for mips/mipsel. That's clearly worse than
> disabling only some of them.

I definitely agree, though I would prefer recording failing tests as BUGS 
before disabling them.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
(Continue reading)

Thiemo Seufer | 1 May 19:44 2005
Picon

Re: Re: More MIPS-related patches

Nikodemus Siivola wrote:
> On Sun, 1 May 2005, Thiemo Seufer wrote:
> 
> >>>Ignore tests which currently fail on mips. foreign.test.sh is the
> >>>odd one out, mips falls in the debugger, I haven't had a closer look
> >>>yet.
> 
> That's probably my fault: IIRC I tried to be too clever for anyone's good 
> with *DEBUGGER-HOOK* there. Or maybe I accidentally left it in a state
> intended for easy of debugging, not pass-or-die tests.

Will it also fail on other architectures when ldb is enabled?

Thiemo

-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

Gmane