sb-simple-streams and sb-gray:stream-xxxx-sequence

sb-simple-streams assumes a different parameter order for
stream-read-sequence and stream-write-sequence.  The attached patch
changes sb-simple-streams to be in line with sb-gray.  (However, I note
that ACL at least has the parameter order sb-simple-streams used to
assume.)

Index: contrib/sb-simple-streams/cl.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/contrib/sb-simple-streams/cl.lisp,v
retrieving revision 1.3
diff -u -r1.3 cl.lisp
--- contrib/sb-simple-streams/cl.lisp	28 May 2003 11:51:11 -0000	1.3
+++ contrib/sb-simple-streams/cl.lisp	1 Jun 2003 12:03:54 -0000
 <at>  <at>  -669,7 +669,7  <at>  <at> 
       (ansi-stream
        (%ansi-stream-read-sequence seq stream start end))
       (fundamental-stream
-       (sb-gray:stream-read-sequence seq stream start end)))))
+       (sb-gray:stream-read-sequence stream seq start end)))))

 (defun clear-input (&optional (stream *standard-input*) buffer-only)
   "Clears any buffered input associated with the Stream."
 <at>  <at>  -790,7 +790,7  <at>  <at> 
       (ansi-stream
        (%ansi-stream-write-sequence seq stream start end))
       (fundamental-stream
-       (sb-gray:stream-write-sequence seq stream start end)))))
+       (sb-gray:stream-write-sequence stream seq start end)))))

(defmacro nada (()))

Shouldn't that work?

* (defmacro nada (()))
; in: LAMBDA NIL
;     (LET* ((NIL (CAR #)))
;     )
;
; caught ERROR:
;   The name of the lambda variable NIL is already in use to name a
constant.
; compilation unit finished
;   caught 1 ERROR condition

The attached patch seems to fix it, but emits some funny warning about
unreachable code.

Index: src/code/parse-defmacro.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/parse-defmacro.lisp,v
retrieving revision 1.15
diff -u -r1.15 parse-defmacro.lisp
--- src/code/parse-defmacro.lisp	28 May 2003 14:49:36 -0000	1.15
+++ src/code/parse-defmacro.lisp	1 Jun 2003 17:15:07 -0000
 <at>  <at>  -106,7 +106,7  <at>  <at> 
 	((null rest-of-args))
       (macrolet ((process-sublist (var sublist-name path)
                    (once-only ((var var))
-                     `(if (consp ,var)
+                     `(if (listp ,var)

streams of :element-type (signed-byte 8)

Streams of :element-type (signed-byte 8) are broken in SBCL.  Instead of
signed bytes, the corresponding unsigned bytes are returned. :(

(let ((p "signed-byte-8-test.data"))
  (with-open-file (s p :direction :output :element-type '(unsigned-byte 8))
    (write-byte 255 s))
  (with-open-file (s p :element-type '(signed-byte 8))
    (assert (= (read-byte s) -1))))

Re-adding the following check present in CMUCL seems to fix it:

Index: src/code/fd-stream.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/fd-stream.lisp,v
retrieving revision 1.34
diff -u -r1.34 fd-stream.lisp
--- src/code/fd-stream.lisp	26 May 2003 14:42:24 -0000	1.34
+++ src/code/fd-stream.lisp	1 Jun 2003 18:16:40 -0000
 <at>  <at>  -682,7 +682,13  <at>  <at> 
 		  (fd-stream-bin fd-stream) routine))
 	(when (eql size 1)
 	  (setf (fd-stream-n-bin fd-stream) #'fd-stream-read-n-bytes)
-	  (when buffer-p
+	  (when (and buffer-p
+		     ;; We only create this buffer for streams of type
+		     ;; (unsigned-byte 8).  Because there's no buffer, the
+		     ;; other element-types will dispatch to the appropriate
+		     ;; input (output) routine in fast-read-byte.
+		     (or (eq type 'unsigned-byte)

Re: (defmacro nada (()))

David Lichteblau wrote:
> Shouldn't that work?
> 
> * (defmacro nada (()))
> ; in: LAMBDA NIL
> ;     (LET* ((NIL (CAR #)))
> ;     )
> ;
> ; caught ERROR:
> ;   The name of the lambda variable NIL is already in use to name a
> constant.
> ; compilation unit finished
> ;   caught 1 ERROR condition
> 
> The attached patch seems to fix it, but emits some funny warning about
> unreachable code.

Yes, () should be a valid destructuring lambda list.

This works in Lispworks 4.2 and ACL 6.2, btw.

	Paul

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

mutually recursive functions and warnings

SBCL emits an undefined function style warning for the second of two
mutually recursive functions upon compiling the first.  Is there any way
to silence this without turning off all warnings?  There's no such thing
as a forward function definition in CL, right?

miles

Re: mutually recursive functions and warnings

Miles Egan <miles <at> caddr.com> writes:

> SBCL emits an undefined function style warning for the second of two
> mutually recursive functions upon compiling the first.  Is there any way
> to silence this without turning off all warnings?  There's no such thing
> as a forward function definition in CL, right?

There is, as a matter of fact: it looks like 
  (declaim (ftype function foo)).

That said, if the two mutually recursive functions are in the same
file, and are being processed by COMPILE-FILE (as opposed to loaded as
source), the rules on compilation units should give enough latitude to
defer undefined function warnings until the whole of the file is
processed; I don't know how much work that is, though.

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

[patch] correct sb-posix system dependencies

* interface.lisp depends on designator.lisp, update the asd file to
  make it so.

Regards,

Rudi

--- sb-posix.asd	19 May 2003 14:47:16 -0000	1.2
+++ sb-posix.asd	2 Jun 2003 08:47:00 -0000
 <at>  <at>  -11,7 +11,7  <at>  <at> 
 		 (sb-grovel:grovel-constants-file
 		  "constants"
 		  :package :sb-posix :depends-on  ("defpackage"))
-		 (:file "interface" :depends-on ("constants" "macros"))))
+		 (:file "interface" :depends-on ("constants" "macros" "designator"))))

 (defmethod perform :after ((o test-op) (c (eql (find-system :sb-posix))))
   (provide 'sb-posix))

--

-- 
whois DRS1020334-NICAT                    http://constantly.at/pubkey.gpg.asc
     Key fingerprint = C182 F738 6B9A 83AF 9C25  62D9 EFAE 45A6 9A69 0867

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sb-simple-streams and sb-gray:stream-xxxx-sequence

David Lichteblau <david <at> lichteblau.com> writes:

> sb-simple-streams assumes a different parameter order for
> stream-read-sequence and stream-write-sequence.  The attached patch
> changes sb-simple-streams to be in line with sb-gray.  (However, I note
> that ACL at least has the parameter order sb-simple-streams used to
> assume.)
>

Ah, yes, stream-foo-sequence functions.  They are not in the Gray
streams proposal, and there is a choice between having their argument
order consistent w.r.t. the other stream-xxx functions or w.r.t. ansi
foo-sequence.  cmucl used to do the latter, but switched to the
former, IIRC.

Anyway, your patch looks trivially correct; I've integrated it in my
local source tree so it won't get lost in case none of the committers
get around to merging it in the next few days.

Thanks,

Rudi
--

-- 
whois DRS1020334-NICAT                    http://constantly.at/pubkey.gpg.asc
     Key fingerprint = C182 F738 6B9A 83AF 9C25  62D9 EFAE 45A6 9A69 0867

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: mutually recursive functions and warnings

On Mon, 2003-06-02 at 00:52, Christophe Rhodes wrote:
> Miles Egan <miles <at> caddr.com> writes:
> 
> > SBCL emits an undefined function style warning for the second of two
> > mutually recursive functions upon compiling the first.  Is there any way
> > to silence this without turning off all warnings?  There's no such thing
> > as a forward function definition in CL, right?
> 
> There is, as a matter of fact: it looks like 
>   (declaim (ftype function foo)).

Missed that in the docs somehow. Thanks.

> That said, if the two mutually recursive functions are in the same
> file, and are being processed by COMPILE-FILE (as opposed to loaded as
> source), the rules on compilation units should give enough latitude to
> defer undefined function warnings until the whole of the file is
> processed; I don't know how much work that is, though.

That would be cool, but it's only a very minor annoyance.

--

-- 
Miles Egan <miles <at> caddr.com>

Re: (defmacro nada (()))

David Lichteblau <david <at> lichteblau.com> writes:

> Shouldn't that work?
>
> * (defmacro nada (()))

Yes. :-/

> The attached patch seems to fix it, but emits some funny warning about
> unreachable code.

Thanks, I've merged this (and the patch to sb-simple-streams) into
sbcl-0.8.0.26.  I think the unreachable code note comes from the
following clause in the typecase:

            (list
             (case now-processing
               ((:required)
                (when restp
                  (defmacro-error "required argument after &REST/&BODY"
                      error-kind name))
                (process-sublist var "SUBLIST-" `(car ,path))
                (setq path `(cdr ,path)
                      minimum (1+ minimum)
                      maximum (1+ maximum)))

when VAR is typep LIST, and PROCESS-SUBLIST calls LISTP rather than
CONSP, the compiler can delete one branch of the conditional inside
PROCESS-SUBLIST; the code deletion note heuristics aren't smart enough
to keep silent about that, but all is otherwise well.