I'm writing a sun rasterfile (just 8-bit RGB at the moment) output and I
would like to be able to switch :element-types without closing and
re-opening. This is what I have (with the header mostly removed).
(defun write-sunras (raster-filename ras)
(with-open-file (file-stream raster-filename
:direction :output
:element-type '(unsigned-byte 32))
(write-byte (reverse-bytes
(sunras-magic ras)) file-stream)
<snip rest of 32-bit header elements>
(with-open-file (file-stream raster-filename
:direction :output
:element-type '(unsigned-byte 24))
(write-sequence (flatten-2d-array (sunras-pixels ras))
file-stream)))
Thanks
Charlie.
"Charlie" <········@zoom.co.uk> writes:
> I'm writing a sun rasterfile (just 8-bit RGB at the moment) output and I
> would like to be able to switch :element-types without closing and
> re-opening. This is what I have (with the header mostly removed).
>
> (defun write-sunras (raster-filename ras)
> (with-open-file (file-stream raster-filename
> :direction :output
> :element-type '(unsigned-byte 32))
> (write-byte (reverse-bytes
> (sunras-magic ras)) file-stream)
> <snip rest of 32-bit header elements>
> (with-open-file (file-stream raster-filename
> :direction :output
> :element-type '(unsigned-byte 24))
> (write-sequence (flatten-2d-array (sunras-pixels ras))
> file-stream)))
I'd used (unsigned-byte 8) throughout.
I'd do this not only because it saves you the open/close, but also because
(unsigned-byte 24) is not on the list of required types that the
implementation is required to support. An implementation MIGHT substitute
(unsigned-byte 32) and just tolerate an 8bit-byte full of zero's on every
supposedly-24bit-byte; the only requirement is that the same implementation
upon opening in the other direction do the inverse thing. That is, CL has
few constraints that make its odd (i.e., unusual) byte encodings suitable
for interchange with the outside world in some reliable way.
Thanks will do. The "upon opening in the other direction do the inverse
thing" sounds very scary indeed. I can see how it wouldn't be a problem on a
"one-lisp-pony" but in any case sun rasterfiles are a standard so unless I
was lucky enough to have the lisp fill in the alpha channel with zeros it
would all go horribly wrong (the header would be wrong in this case
anyway!).
Thank-you
Charlie.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> I'd used (unsigned-byte 8) throughout.
>
> I'd do this not only because it saves you the open/close, but also because
> (unsigned-byte 24) is not on the list of required types that the
> implementation is required to support. An implementation MIGHT substitute
> (unsigned-byte 32) and just tolerate an 8bit-byte full of zero's on every
> supposedly-24bit-byte; the only requirement is that the same
implementation
> upon opening in the other direction do the inverse thing. That is, CL has
> few constraints that make its odd (i.e., unusual) byte encodings suitable
> for interchange with the outside world in some reliable way.
>
From: Lars Brinkhoff
Subject: Re: Changing open :element-type without re-opening.
Date:
Message-ID: <85y97fjpho.fsf@junk.nocrew.org>
Kent M Pitman <······@world.std.com> writes:
> (unsigned-byte 24) is not on the list of required [:element-type]
> types that the implementation is required to support.
Is there such a list? I couldn't find any when searching the HyperSpec.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Lars Brinkhoff <·········@nocrew.org> wrote:
+---------------
| Kent M Pitman <······@world.std.com> writes:
| > (unsigned-byte 24) is not on the list of required [:element-type]
| > types that the implementation is required to support.
|
| Is there such a list? I couldn't find any when searching the HyperSpec.
+---------------
Hmmm... How about this [emphasis added]:
<URL:http://www.lispworks.com/reference/HyperSpec/Body/f_open.htm>
...
element-type---a type specifier for recognizable subtype of
character; OR A TYPE SPECIFIER FOR A FINITE RECOGNIZABLE SUBTYPE
OF INTEGER; or one of the symbols signed-byte, unsigned-byte,
or :default. The default is character.
By following the glossary reference to "recognizable subtype" and
thence to SUBTYPEP, I interpreted that to mean that "(unsigned-byte 24)"
should be supported in in OPEN by some given implementation iff
(subtypep '(unsigned-byte 24) 'integer) => t, t in that implementation.
I say "should", because I couldn't get the following:
(with-open-file (s "foo" :element-type '(unsigned-byte 4))
(loop for x = #1=(read-byte s nil nil) then #1#
while x
do (format t "~d~%" x)))
to work with either CMUCL or CLISP, even though both say that
(subtypep '(unsigned-byte 4) 'integer) => t, t
CMUCL treats (unsigned-byte 4) as (unsigned-byte 8), printing the
following for the above ["foo" contains "hello\n"]:
104
101
108
108
111
10
NIL
And though '(unsigned-byte 16) works as expected, CMUCL unfortunately
treats '(unsigned-byte 24) as '(unsigned-byte 32):
1819043176
NIL
On the other hand, CLISP simply refuses to play at all when given
(unsigned-byte 4):
*** - file #P"/u/rpw3/foo" is not an integer file
1. Break [2]>
But it handles (unsigned-byte 24) just fine:
7103848
683884
NIL
Go figure.
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Lars Brinkhoff <·········@nocrew.org> wrote:
> +---------------
> | Kent M Pitman <······@world.std.com> writes:
> | > (unsigned-byte 24) is not on the list of required [:element-type]
> | > types that the implementation is required to support.
> |
> | Is there such a list? I couldn't find any when searching the HyperSpec.
> +---------------
>
> Hmmm... How about this [emphasis added]:
>
> <URL:http://www.lispworks.com/reference/HyperSpec/Body/f_open.htm>
> ...
> element-type---a type specifier for recognizable subtype of
> character; OR A TYPE SPECIFIER FOR A FINITE RECOGNIZABLE SUBTYPE
> OF INTEGER; or one of the symbols signed-byte, unsigned-byte,
> or :default. The default is character.
>
> By following the glossary reference to "recognizable subtype" and
> thence to SUBTYPEP, I interpreted that to mean that "(unsigned-byte 24)"
> should be supported in in OPEN by some given implementation iff
> (subtypep '(unsigned-byte 24) 'integer) => t, t in that implementation.
Only if you don't read on into the definition. You can give these values
as arguments but it doesn't mean they're treated as you expect. See farther
down in the description of OPEN where it says:
With regard to the :element-type option, if a type is requested that
is not supported by the file system, a substitution of types such as
that which goes on in upgrading is permissible. As a minimum
requirement, it should be the case that opening an output stream to a
file in a given element type and later opening an input stream to the
same file in the same element type should work compatibly.
I guess I have always assumed, though indeed "upgrading" is not an italic
term so it's not a sure thing, that this vaguely implies that the supported
types for array element type upgrading are reliably available, and hence
1bit, 8bit, etc. are available but that 24bit might not be.
15.1.2.2 seems to require 1bit arrays but I'm surprised not to find a
requirement of 8bit arrays, which I seem to recall people fussing about
when they first found out about the upgrading issue. Maybe it's elsewhere
or maybe the spec editor (me) stupidly left it out... I don't have more
time this morning to track this down...
Kent M Pitman <······@world.std.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > By following the glossary reference to "recognizable subtype" and
| > thence to SUBTYPEP, I interpreted that to mean that "(unsigned-byte 24)"
| > should be supported in in OPEN by some given implementation iff
| > (subtypep '(unsigned-byte 24) 'integer) => t, t in that implementation.
...
| See farther down in the description of OPEN where it says:
|
| With regard to the :element-type option, if a type is requested that
| is not supported by the file system, a substitution of types such as
| that which goes on in upgrading is permissible.
+---------------
Ah, o.k., missed that. Thanks,
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607