gmane.lisp.steel-bank.devel

Re: freeze for sbcl-1.1.8

Nathan, Paul — 2013-05-25T04:48:06

--------
________________________________________
From: Christophe Rhodes [csr21< at >cantab.net]
Sent: Friday, May 24, 2013 11:57 AM
To: sbcl-devel< at >lists.sourceforge.net
Subject: [Sbcl-devel] freeze for sbcl-1.1.8

Hi,

If the version number were going by substantial changes, then this one
might be sbcl-1.2.rc1.  It's been a busy month, with lots of fixes and
new features all over the tree: for the next short period it would be
truly excellent to test those new features against all the code out
there, watching particularly for any regressions on real code.  I aim to
make the release during the second half of next week.

Cheers,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life

Re: SB-GMP status

Gabriel Dos Reis — 2013-05-24T23:16:52

I have not gone through the trouble of duplicating Waldek's work
but if it is made a standard package pf SBCL (which is the default
Lisp for OpenAxiom on many supported platform) it would be
of immense value.

freeze for sbcl-1.1.8

Christophe Rhodes — 2013-05-24T18:57:41

Hi,

If the version number were going by substantial changes, then this one
might be sbcl-1.2.rc1.  It's been a busy month, with lots of fixes and
new features all over the tree: for the next short period it would be
truly excellent to test those new features against all the code out
there, watching particularly for any regressions on real code.  I aim to
make the release during the second half of next week.

Cheers,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

[patch] lp#659173 patch and discussion

Jingyi Hou — 2013-05-24T17:53:46

Hi all,

I've been trying to fix lp#659173 <https://launchpad.net/sbcl/+bug/659173>,
kind of stuck by now.

1) What I've got:
    a) As for (SETF SYMBOL-FUNCTION) and (SETF FDEFINITION), I think we
should definitely generate a warning message whenever defined-ftype
mismatches declared-ftype. I've written a patch for (SETF SYMBOL-FUNCTION),
but I am not quite sure where to fix (SETF FDEFINITION) yet. Please let me
know if this patch is OK.

    b) `(defun quux (x) (list x))' has the same bug as `(setf
(symbol-function 'quux) (lambda (x) (list x)))'. (which is handled in
src/compiler/ir1final.lisp: finalize-xep-definition)

2) My questions:
    a) I tried to reset (info :function :type) to 'defined-ftype' whenever
'defined-ftype' and 'declared-ftype' mistaches, which fixes this particular
bug (but not the right solution, of course), so I am assuming when FOO
generates call to QUUX, it only considered declared-ftype of QUUX, thus
treated its return value as a string, but I am not quite sure where this
piece of

Re: SB-GMP status

2013-05-24T14:41:10

I had played with the idea for some time and Paul's GSoC idea sparked my
interest anew. It uses the same idea as Waldek's approach though doesn't
need a C shim and provides a more comprehensive coverage both wrt. bignum
operations transparently relayed to GMP and interfaced GMP functionality.
Furthermore, I think that I have covered more corner cases which I think
aren't handled by the version in Fricas (I haven't tried but I did look
for solutions there once I discovered the bugs and didn't find anything).
At the moment I am not aware of any bugs in the core functionality (the
one covered in the test suite) and have run a large number of randomly
generated tests on 32 and (primarily) 64 bit Linux.


I will use some of the functionality and am quite certain that Maxima
should see a nice speedup for operations on large bignums and rationals.
There was also interest from another student(?, sorry can't access my mail
archive at the moment) to expand with covering MPFR as well, since there
is quite some overlap

Re: SB-GMP status

Christophe Rhodes — 2013-05-24T13:59:31


I can see the value of including this -- there's clearly a need, given
the Fricas case as well as this (is this independently developed?  Or
does it related in any way to the older work by Waldek Hebisch?)

In terms of what needs doing before merging, for contribs I'm not
inclined to be too fussy -- they are optional, and can afford to be a
bit more experimental than changes to the main body.  Perhaps most
important might be to think about medium-term commitment -- is this
something that you use?

Cheers,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: [patch] search_for_executable() fails to processlast part of PATH environment variable

Christophe Rhodes — 2013-05-23T20:19:53


Thank you; I've pushed these to master.

Best wishes,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: [patch] search_for_executable() fails to process last part of PATH environment variable

Jingyi Hou — 2013-05-23T18:30:28

Hi Christophe,

Thanks for your reply.

I've separated it into two patches. Please let me know if they are OK.

Thanks again.


On Fri, May 24, 2013 at 1:13 AM, Christophe Rhodes <csr21< at >cantab.net> wrote:

Re: [patch] search_for_executable() fails to processlast part of PATH environment variable

Christophe Rhodes — 2013-05-23T17:13:21


Great!  Thank you for your contribution.  I think to make it most
straightforward, I would prefer it as two patches, each doing one thing
(I know they are both fairly trivial, but even so).  If you could
separate them out, you could also delete the whole of the comment (not
just the "FIXME" text) above the definition of block-delete-p, since
your patch fixes the whole issue.

Best wishes,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: Non-Unicode build broken since 1.1.7.57-db01104

Christophe Rhodes — 2013-05-23T17:06:59


Well, here's one example: there's a case I think for SBCL itself to
provide external formats with normalization -- ignoring for the moment
the fact that we don't even provide external formats with newline
handling :-(  I would like to be able to write something like
  :external-format '(:utf-8 :normalization :nfc)
and have that work even in non-SB-UNICODE builds, provided that the
input to that stream is in the first 256 codepoints.

Now, this is theoretical.  But also I don't see the harm in providing
the function definition, particularly when it's easy...

Cheers,

Christophe

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

[patch] search_for_executable() fails to process last part of PATH environment variable

Jingyi Hou — 2013-05-23T16:32:09

Hi SBCL hackers,

This trivial patch contains two parts:

1) search_for_executable() in src/runtime/runtime.c fails to process last
part of PATH if PATH does not end with `:'.

2) FIXME tweak in src/compiler/node.lisp so that BLOCK-DELETE-P is
findable by grep for `def.*block-delete-p'. I came across this `FIXME' when
trying to understand the IR1 phase of Python.

I did regression test on my Ubuntu laptop `i386 GNU/Linux
3.2.0-23-generic-pae', the test result turns out to be same as the newest
git version 1.1.7.105-808d810, which shouldn't be a big surprise, :-)

This is my first patch to SBCL, so if anything went wrong, please let me
know.

Thanks.

Re: Non-Unicode build broken since 1.1.7.57-db01104

Tom Emerson — 2013-05-23T14:39:56


I don't think the argument that code written to use normalize-string could
be compiled and run in a #-sb-unicode scenario holds up: chances are if you
are writing code that uses Unicode normalization other parts of your code
base are going to require features that might otherwise not be available.
IMHO it is confusing to use Unicode-specific functionality in a non-Unicode
build. If someone wants that, they can write their own shim easily enough.

    -tree

Re: Bad effect of FOLD-INDEX-ADDRESSING

Paul Khuong — 2013-05-23T05:54:50

[...]

I played with this for a while, and I think it's actually simpler: all 
the *-with-offset VOPs accept fixnums for the index argument. Moreover, 
any range checking is done before hitting *-with-offset, so if we can 
fold some indices, the original index was statically known to be OK. So, 
AFAICT, the right fix is to adjust the defknowns to allow arbitrary 
fixnum indices, and to only fold-index-addressing when the new index 
argument would still be a fixnum (otherwise we won't be able to 
translate the form). There's another issue in fold-index-addressing: in 
the last argument to sb!vm::foldable-constant-offset-p, the arguments 
for FUNC are flipped... that's probably the reason we don't have more 
reports of failure to translate data-vector-ref-with-offset.

Paul Khuong

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful fu

Re: How to know when to stop spelling "banana"

Douglas Katzman — 2013-05-22T23:58:53

Better way attached.

There is no way to suppress the long NOP filler, but this patch always
stops disassembling good instructions exactly where it should, unlike my
prior patch; and has the potential to chunk the raw bytes more-or-less
correctly. (less, because of SSE problems. If you like this, I'll augment
all the SSE printers to distinguish between {scalar,packed}x{float,double}
and various int sizes to dump in both hex and the correct interpretation of
the bytes - i.e. we can't know that something is a 128-bit complex number
constant as it stands.)

I also added a mode to print the line address in either absolute or
segment-relative. The default is relative since I see no use for absolute
especially since it chops off high-order bytes on machines which put code
at really high addresses.  Doesn't seem worth expanding the address column
width for it.

Sample:
* (disassemble '(lambda (x) (- (logxor (the (unsigned-byte 60) x)
#xbadf00dd003) #xdeadbeef00)))

; disassembly for (LAMBDA (X))
; Size: 115 bytes
;

Re: Non-Unicode build broken since 1.1.7.57-db01104

Christophe Rhodes — 2013-05-22T21:40:03


As full functionality, no -- but on the other hand what it does is
nothing for C forms and error for D forms, so it doesn't hurt to keep it
around (and the benefit of having it is to allow for potential client
code to compile and possibly run in the #-sb-unicode case).

(And, yes, I don't expect the normalization tests to pass in a
non-sb-unicode build.)

Cheers,

Christophe


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: Non-Unicode build broken since 1.1.7.57-db01104

Lutz Euler — 2013-05-22T20:21:46

Hi Christophe,


I just tried the patch. SBCL without :SB-UNICODE can be built with it,
but there are four unexpected failures in the test suite:

Failure: unicode-normalization.impure.lisp / (UNICODE-NORMALIZATION PART0)
Failure: unicode-normalization.impure.lisp / (UNICODE-NORMALIZATION PART1)
Failure: unicode-normalization.impure.lisp / (UNICODE-NORMALIZATION PART2)
Failure: unicode-normalization.impure.lisp / (UNICODE-NORMALIZATION PART3)

The test output looks like this (shortened):

// Running /lisp/sbcl/sbcl-test/tests/unicode-normalization.impure.lisp
::: Running (:UNICODE-NORMALIZATION :PART0)
::: UNEXPECTED-FAILURE (:UNICODE-NORMALIZATION :PART0)
    due to #<TYPE-ERROR expected-type: (UNSIGNED-BYTE 8) datum: 7690>:
        "The value 7690 is not of type (UNSIGNED-BYTE 8)."

Also, SBCL with :SB-UNICODE can be built with the patch and the test
suite passes.

All this is on x86-64 under Linux.

Greetings,

Lutz

------------------------------------------------------------------------------
Try New Re

Re: Non-Unicode build broken since 1.1.7.57-db01104

Tom Emerson — 2013-05-22T20:16:36

Does it make sense for normalize-string to even exist in a non-Unicode
build?


On Wed, May 22, 2013 at 3:32 PM, Christophe Rhodes <csr21< at >cantab.net> wrote:

Re: Non-Unicode build broken since 1.1.7.57-db01104

Christophe Rhodes — 2013-05-22T19:32:54


Fair enough.  The composition structure is implemented as a hash table
mapping pairs of codepoints encoded as a 42-bit integer directly to
characters; of course, most of those characters do not exist on a
non-Unicode build.

Candidate patch attached...


Cheers,

Christophe
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Non-Unicode build broken since 1.1.7.57-db01104

Lutz Euler — 2013-05-22T19:07:53

Hi,

just for fun I tried whether SBCL can still be built without
:SB-UNICODE. Turns out it can't (tested with 1.1.7.102-1e2f526).
I have bisected this to the first bad commit:

SHA: db0110475c0db5dc3cb1bb12de0b0c475880899e
Author: Christophe Rhodes
Subject: implement primary and canonical composition, and hence NFC/NFKC

The error is:

//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 1.1.7.57-db01104, 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 #30 (Object is of the wrong type.)
    SC: 20, Offset: 2  0x00000200: even fixnum: 128
    SC: 21, Offset: 0$1=  0x10004ebb27: list pointer
fatal error encountered in SBCL pid 14166(tid 140737353926432):
internal error too earl

Re: Pessimization of 'ldb-test' despite presence of vm support for fast logtest

Paul Khuong — 2013-05-22T18:31:33

I'd say the most reasonable fix will be to define a %ldb-test
function for general integers (with pre-decoded BYTE specifier), and add
a transform to re-express it as logtest for small integers.


Ah, I'd missed the VOPs for EQ[L] of fixnums. Fixed in 2372ff8
(Specialised VOPs for EQ of fixnum values on x86oids).


LOGTEST is missing a commutative-arg-swap transform. Fixed in ab705ef
(Preserve types when swapping constant arguments and commute LOGTEST).

Christophe Rhodes wrote:

COMBINATION-IMPLEMENTATION-STYLE can now return :maybe to allow
transforms to fire (commit f21e0f5, Enable (type-directed) constant
folding for LOGTEST on x86oids and PPC). Transforms are themselves free
to call C-I-S and give up if it's not :default.

Paul Khuong

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monito

Patch for Initial Move of GC code into package SB-GC

Craig Lanning — 2013-05-22T18:03:45

Attached is a patch which includes all the changes necessary for
SYS:SRC;CODE;GC.LISP to be in the package "SB!GC" instead of "SB!
KERNEL".

It compiles and runs.  The patch is relative to 1.1.7.102.

Craig

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel