From: A.J. R. <bli...@gm...> - 2009-07-11 06:31:26
|
Dear all - Working through the examples for CL-PDF (trying to put together a quick substitute for R's Sweave literate programming tool) is giving me some weird errors, for example, evaluation of the EXAMPLE1 function (error from SLIME below). In general, PDF:WRITE-DOCUMENT function seems to be unable to take a string or pathname, but throws the following error (which I tried to resolve by OPENing the proper handle and passing it): #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}> is not a binary output stream. [Condition of type SIMPLE-TYPE-ERROR] Restarts: 0: [RETRY] Retry SLIME interactive evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" RUNNING {C0EA1A9}>) Backtrace: 0: (SB-KERNEL:ILL-BOUT #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}>)[:EXTERNAL] 1: (SB-IMPL::ANSI-STREAM-WRITE-SEQUENCE #(8 153 115 10 225 210 ...) #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}> 0 NIL) 2: (WRITE-SEQUENCE #(8 153 115 10 225 210 ...) #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}>)[:EXTERNAL] This is with SBCL from Debian Unstable: SBCL 1.0.29.11.debian Now, looking through the code, I'm thinking this might be an SBCL issue and should be reported there? Or is this a bug with recent CL-PDF's? Or perhaps I'm mixing and matching packages which shouldn't be mixed and matched? Insight appreciated, including a clue-stick if I need one. best, -tony bli...@gm... Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). Drink Coffee: Do stupid things faster with more energy! |
From: James F. <li...@el...> - 2009-07-11 07:06:43
|
> PDF:WRITE-DOCUMENT function > seems to be unable to take a string or pathname, but throws the > following error (which I tried to resolve by OPENing the proper handle > and passing it): > > #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}> is not a binary > output stream. Tony, I've recently run into this myself. After a bit of experimentation, I've had consistent success with passing it a filehandle opened for writing with :element-type :default, like so: (with-open-file (outstream #p"/path/to/outfile.pdf" :direction :output :if-exists :rename :element-type :default) (pdf:with-document <PDF stuff goes here...> (pdf:write-document outstream))) I first tried passing it a filehandle opened with :element-type '(unsigned-byte 8) but it them complained that it didn't have a stream of type character. I've no idea why you have to explicitly tell it to use the default element-type, but also don't have the time to dig around and figure that out. HTH, James |
From: A.J. R. <bli...@gm...> - 2009-07-11 07:15:41
|
James - That does the trick, THANKS! On Sat, Jul 11, 2009 at 8:48 AM, James Fleming<li...@el...> wrote: >> PDF:WRITE-DOCUMENT function >> seems to be unable to take a string or pathname, but throws the >> following error (which I tried to resolve by OPENing the proper handle >> and passing it): >> >> #<SB-SYS:FD-STREAM for "file /tmp/ex1.pdf" {BEC30D1}> is not a binary >> output stream. > > > Tony, > > I've recently run into this myself. > After a bit of experimentation, I've had consistent success with passing > it a filehandle opened for writing with :element-type :default, like so: > > (with-open-file (outstream #p"/path/to/outfile.pdf" > :direction :output > :if-exists :rename > :element-type :default) > (pdf:with-document > <PDF stuff goes here...> > (pdf:write-document outstream))) > > I first tried passing it a filehandle opened with :element-type > '(unsigned-byte 8) but it them complained that it didn't have a stream of > type character. I've no idea why you have to explicitly tell it to use the > default element-type, but also don't have the time to dig around and > figure that out. > > > HTH, > James > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > -- best, -tony bli...@gm... Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). Drink Coffee: Do stupid things faster with more energy! |
From: Leslie P. P. <sk...@vi...> - 2009-07-11 08:25:29
|
James Fleming wrote: > I first tried passing it a filehandle opened with :element-type > '(unsigned-byte 8) but it them complained that it didn't have a stream of > type character. I've no idea why you have to explicitly tell it to use the > default element-type, but also don't have the time to dig around and > figure that out. http://www.sbcl.org/manual/Bivalent-Streams.html is likely to apply here. Leslie -- http://www.linkedin.com/in/polzer |
From: James F. <li...@el...> - 2009-07-11 08:56:29
|
> James Fleming wrote: > >> I've no idea why you have to explicitly tell it to use >> the >> default element-type, but also don't have the time to dig around and >> figure that out. > > http://www.sbcl.org/manual/Bivalent-Streams.html is likely to apply here. > > Leslie Thanks, Leslie - that explains it nicely. My apologies for sounding a bit terse in my previous mail; it really wasn't the tone I was aiming for. "Need more hours in the day!" is my perennial plaint. I must admit that I'm still confused as to why the relevant argument value is :default, as :bivalent would be more intuitive. Is there a historical reason for this? While I'm complaining like an ungrateful sod, would it be feasible to add :bivalent as a synonymous value here in some future version? Cheers, James |
From: Leslie P. P. <sk...@vi...> - 2009-07-11 09:46:57
|
James Fleming wrote: > I must admit that I'm still confused as to why the relevant argument value > is :default, as :bivalent would be more intuitive. Is there a historical > reason for this? While I'm complaining like an ungrateful sod, would it be > feasible to add :bivalent as a synonymous value here in some future > version? Unfortunately the spec does not allow arbitrary arguments here: 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. http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_open.html The only option to make this possible would be a (deftype bivalent () '(or unsigned-byte character)) I'm not sure whether that would be an acceptable solution, but I definitely concur with your rationale. Leslie -- http://www.linkedin.com/in/polzer |
From: James F. <li...@el...> - 2009-07-11 10:30:31
|
> James Fleming wrote: > >> I must admit that I'm still confused as to why the relevant argument >> value >> is :default, as :bivalent would be more intuitive. Is there a historical >> reason for this? While I'm complaining like an ungrateful sod, would it >> be >> feasible to add :bivalent as a synonymous value here in some future >> version? > > Unfortunately the spec does not allow arbitrary arguments here: > > 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. > > http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_open.html > > The only option to make this possible would be a > > (deftype bivalent () > '(or unsigned-byte character)) > > I'm not sure whether that would be an acceptable solution, > but I definitely concur with your rationale. > > Leslie That sounds like it would work nicely, actually. I'll get off my butt and actually check the spec in future, too. Sorry, I'm normally better at doing that. Cheers, James |
From: Kevin R. <kp...@ma...> - 2009-07-11 11:56:28
|
[Reply-To sbcl-devel, because further discussion won't be relevant to - help] On Jul 11, 2009, at 5:46, Leslie P. Polzer wrote: > James Fleming wrote: >> While I'm complaining like an ungrateful sod, would it be feasible >> to add :bivalent as a synonymous value here in some future version? > > Unfortunately the spec does not allow arbitrary arguments here: > > 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. > > http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_open.html > > The only option to make this possible would be a > > (deftype bivalent () > '(or unsigned-byte character)) Technically invalid by your interpretation, because it is neither a subtype of character nor a subtype of integer. However, is there a practical reason an extension to accept some other value (such as your bivalent, or :bivalent) is not permitted? It's not like there is an existing interpretation of "any other value" which would be contradicted by this definition, and any program using bivalent streams is by definition unportable (a nonconforming program per CLHS). (Well, :bivalent would be invalid, because in principle it could be DEFTYPEd, but that's not sensible for analogous reasons to CLHS 11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs, though there is no *specified* constraint on package KEYWORD.) http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm -- Kevin Reid <http://switchb.org/kpreid/> |