Daniel Barlow | 1 Dec 03:46 2003
Picon

Re: MORE CODE LESS TEXT

William Harold Newman <william.newman <at> airmail.net> writes:

> I've made a candidate patch doing much of the specific shortening you
> recommended, which hopefully will suit NS's tastes as well.

Looks good to me.  Go for it.

> +;;; 47: (2003-11-30) Static variables were rearranged in 0.8.6.11.

Ulp.  That one was mine, and it didn't even occur to me it'd break
fasls.  I guess if I were smart I'd have reused the now-deleted
*session-lock* offset for the new function, but it seemed to make more
sense to put it with the other functions.

It's astonishing just how much information there is in a fasl file
that should make it portable to a wide range of places and yet just
how easy it is to break fasl compatibility unthinkingly.  Maybe I
should do some cmucl hacking and hope that facing bootstrapping issues
would lead me to acquire a proper respect for binary compatibility

-dan

--

-- 

 http://web.metacircles.com/ - Open Source software development and support
William Harold Newman | 1 Dec 03:06 2003
Picon

Re: MORE CODE LESS TEXT

On Mon, Dec 01, 2003 at 02:46:22AM +0000, Daniel Barlow wrote:
> William Harold Newman <william.newman <at> airmail.net> writes:
> 
> > I've made a candidate patch doing much of the specific shortening you
> > recommended, which hopefully will suit NS's tastes as well.
> 
> Looks good to me.  Go for it.
> 
> > +;;; 47: (2003-11-30) Static variables were rearranged in 0.8.6.11.
> 
> Ulp.  That one was mine, and it didn't even occur to me it'd break
> fasls.  I guess if I were smart I'd have reused the now-deleted
> *session-lock* offset for the new function, but it seemed to make more
> sense to put it with the other functions.

It'd be fine with me if you never made such an oversight, but I don't
think it really deserves an "ulp". Any reduction in compatibility
mistakes (claiming two releases support them same fasls when in fact
they don't) is good, and if we we could learn to preserve binary
compatibility by 1.0, that'd be great. But it really is a tedious and
tricky chore to get it right, and it seems to be somewhat resistant to
automation, so my hopes aren't that high. It's also just not that high
on my list of bug priorities, and as far as I know not particularly
high on most users' lists either, compared to things like conformance
bugs, performance issues, and interface/documentation quality.

> It's astonishing just how much information there is in a fasl file
> that should make it portable to a wide range of places and yet just
> how easy it is to break fasl compatibility unthinkingly.  Maybe I
> should do some cmucl hacking and hope that facing bootstrapping issues
(Continue reading)

Matthew Schulkind | 1 Dec 08:27 2003

Possible Optimizer Bug

Hi,

I believe I have found a bug in the SBCL optimizer. This has been
verified to occur in both 0.8.5 and 0.8.6

Here is the offending code:

(let ((game-board '((+ + +))))
  (setf (nth 1 (nth 0 game-board)) 'W)

  (format t "~&game-board: ~a~%" game-board)
  (format t "~&(nth 0 game-board: ~a~%"  (nth 0 game-board))
  (format t "~&(nth 1 (nth 0 game-board)): ~a~%" (nth 1 (nth 0
game-board))))

(nth 1 (nth 0 game-board)) should clearly be W and not +

A slight change of adding a copy-tree in the following makes the code
work fine

(let ((game-board (copy-tree '((+ + +)))))
  (setf (nth 1 (nth 0 game-board)) 'W)

  (format t "~&game-board: ~a~%" game-board)
  (format t "~&(nth 0 game-board: ~a~%"  (nth 0 game-board))
  (format t "~&(nth 1 (nth 0 game-board)): ~a~%" (nth 1 (nth 0
game-board))))

If I play with the optimizer settings, after I change them enough times,
this original code snippet starts to work, but I can't come up with a
(Continue reading)

Andreas Fuchs | 1 Dec 08:44 2003
Picon

Re: sb-posix mkdir.error.3 test

On 2003-11-30, Brian Mastenbrook <bmastenb <at> cs.indiana.edu> wrote:
> 'lo all - sb-posix mkdir.error.3 expects to get an error back from
> making a directory "/almost-certainly-does-not-exist"; however, on
> OS X, / is 1775 root:admin, so the mkdir actually completes and
> makes the directory.

Ugh, that's not good.

> I think it's likely that people building on OS X will be
> administrators of their own machines, and so will be able to make
> that directory - not to mention packagers trying to build RPMs as
> root on other architectures. I propose that the test be removed
> until such time as a more portable test can be devised.

How about this:

(deftest mkdir.error.3
    (let* ((top (make-pathname :directory '(:relative "mkdir.denies-perms.1")))
	   (sub (make-pathname :directory '(:relative "perm-denied")))
	   (top-merged (merge-pathnames top *test-directory*))
	   (sub-merged (merge-pathnames sub top)))
	(unwind-protect
	     (progn (sb-posix:mkdir (namestring top-merged)
				    (logior sb-posix::s-irusr sb-posix::s-ixusr))
		    (handler-case
			(sb-posix:mkdir (namestring sub-merged) 0)
		      (sb-posix:syscall-error (c)
			(sb-posix:syscall-errno c))))
	  (ignore-errors (sb-posix:rmdir top-merged))))
  #.sb-posix::eacces)
(Continue reading)

Nikodemus Siivola | 1 Dec 10:40 2003
Picon

Re: MORE CODE LESS TEXT

On Sun, Nov 30, 2003 at 03:20:52PM -0600, William Harold Newman wrote:

> I've made a candidate patch doing much of the specific shortening you
> recommended, which hopefully will suit NS's tastes as well.

Very well, thanks!

> -		   "~2&~ <at> <debugger invoked on condition of type ~S in thread
> +		   "~2&~ <at> <debugger invoked on a ~S in thread ~A: ~

Though this will also lead to "a ERROR-STARTING-WITH-A-VOWEL".

 "... ~A ..." (with-indefinite-article (type-of *debug-condition))

Things like this make me appreciate some features of finnish all the
more, and wish for an extendable FORMAT as well -- of course. ,-)

Cheers,

 -- Nikodemus
Daniel Barlow | 1 Dec 14:27 2003
Picon

Re: Possible Optimizer Bug

Matthew Schulkind <mss2049 <at> columbia.edu> writes:

> Hi,
>
> I believe I have found a bug in the SBCL optimizer. This has been
> verified to occur in both 0.8.5 and 0.8.6
>
> Here is the offending code:
>
> (let ((game-board '((+ + +))))
>   (setf (nth 1 (nth 0 game-board)) 'W)
[...]
> (nth 1 (nth 0 game-board)) should clearly be W and not +

It's not clear to me: you're modifying read-only data, so all bets are
off.  See 3-13 in the Lisp FAQ at
http://www.faqs.org/faqs/lisp-faq/part3/

-dan

--

-- 

 http://web.metacircles.com/Support - SBCL custom development and support
Nikodemus Siivola | 1 Dec 11:19 2003
Picon

Linkage-table (Some Assembly Required)

I've been trying to port linkage-table from CMUCL to SBCL for a while
now, and most of the work is done now (or so I hope, anyways). 

However, since my hacking time may be rather limited for the next few
of months I thought to post it here in case someone else wants to take
a stab at finishing it before that.

Details follow:

 ---

The breakage:

 The linkage-table itself works just fine, but something with the
 integration to the rest of the SBCL is screwed up -- I suspect it's
 interfering with some of the stacks somehow.  Build gets as far as
 make-target-2.sh, where it dies after purify.

 Some things to do to observe the wierdness after loading cold-sbcl.core:

 1. Try (defvar *foo* t) at the repl. See it explode.

 2. Try compiling and loading a file with (defvar *foo* t). Works
    fine.

 3. Enter the debugger, and enter (defvar *foo* t). Works fine.

 As far as I can tell, MAKE-CORE-COMPONENT doesn't quite cut it with
 linkage-table under repl, though FASL-DUMP-COMPONENT works fine. How
 come thngs work under the debugger, still eludes me.
(Continue reading)

Marco Antoniotti | 2 Dec 00:35 2003
Picon

Re: Documentation system?


On Thursday, Nov 27, 2003, at 23:18 America/New_York, Daniel Barlow 
wrote:

> Tiago Maduro-Dias <tcmd <at> rnl.ist.utl.pt> writes:
>
>> I thought it might be a good starting point to write some code that
>> would run through the packages and respective symbols and 
>> automatically
> [...]
>> Maybe someone has already done work on this? Maybe it's not really 
>> that
>> useful or doable for some reason that eludes me? Suggestions? I've 
>> been
>> doing some work for personal use on similar stuff and I wouldn't mind
>> trying to tackle this problem...
>
> Have you looked at Albert? http://albert.sourceforge.net/
>
> I imagine that it will break on SBCL source unless you set up some
> packages and reader macros and so on: src/cold/chill.lisp is probably
> a good place to start

It also breaks on vanilla Lispworks.  Something in the low level 
reading routines.

Cheers

--
Marco Antoniotti
(Continue reading)

Nikodemus Siivola | 2 Dec 13:14 2003
Picon

Bug & patch: pathname should work for all file-streams

In SBCL *standard-output* is a synonym-stream for sb-sys:*stdout*,
which in turn is a file-stream. A file-stream is a valid
file-designator, so PATHNAME & co should work on it.

But they don't:

 * (pathname (symbol-value (synonym-stream-symbol *standard-output*)))

 debugger invoked on condition of type TYPE-ERROR in thread 2089:
   The value NIL is not of type PATHNAME.

The appended patch fixes this by trying ttyname when a file-stream has
no associated pathname. It also attempts to sort out the interface of
FILE-NAME as per the FIXME note, but leaves the name as-is.

With the patch:

 * (pathname (symbol-value (synonym-stream-symbol *standard-output*)))

 #P"/dev/pts/3"

Cheers,

 -- Nikodemus

Index: src/code/fd-stream.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/fd-stream.lisp,v
retrieving revision 1.41
diff -u -r1.41 fd-stream.lisp
(Continue reading)

Eric Moncrieff | 2 Dec 01:40 2003

Build failure (and simple solution).

SBCL from Anonymous CVS doesn't build right now:

beginning GENESIS, creating headers in "src/runtime/genesis"
NIL
* //entering make-target-1.sh
//building runtime system and symbol table file
GNUmakefile:73: depend: No such file or directory
echo '#include "genesis/config.h"' >sbcl.h
echo '#include "genesis/constants.h"' >>sbcl.h
cc -M -g -Wall -O3 -I.  alloc.c backtrace.c breakpoint.c coreparse.c dynbind.c gc-common.c globals.c
interr.c interrupt.c monitor.c parse.c print.c purify.c regnames.c run-program.c runtime.c save.c
search.c thread.c time.c util.c validate.c vars.c wrap.c  > depend.tmp
runtime.c:168:1: missing terminating " character
runtime.c:175:1: missing terminating " character
make: *** [depend] Error 1

I added an extra '\n\' to src/runtime/runtime.c:168, and the problem
went away.  Unfortunately, my patch-fu isn't good enough yet to submit
this as a patch (though, for a one-line change, I think it'd be
overkill anyway).

Thanks for all the great work,
Eric
** 
Eric Moncrieff                                    eric <at> mantis.styx.org
**
                This space intentionally left blank.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
(Continue reading)


Gmane