[cl-pdf-devel] CMUCL compatibility fixes and new colorhandlingcode

Klaus Weidner klaus at atsec.com
Tue Apr 13 19:04:51 UTC 2004


On Tue, Apr 13, 2004 at 11:54:57AM -0500, Klaus Weidner wrote:
> On Tue, Apr 13, 2004 at 05:14:43PM +0200, Marc Battyani wrote:
> > "Stephan Frank" <crimsonf at cs.tu-berlin.de> wrote:
> > > The move of (uffi:def-function ("compress" c-compress)...) is still
> > > necessary, otherwise there will be a complaint that "compress" is unknown.
> > 
> > Is it a warning or and error ?
> > Maybe the def-function must be at the top level ?
> 
> It's an error - compiling the init.lisp file works, but loading the
> resulting .x86f file immediately generates an error about the missing
> foreign function "compress".

That reminds me - would there be a clean way to make zlib support a
compile-time feature rather than a run-time selection via the global
variable? The CMUCL build broke when loading, before it got a chance to
look at the variable, so the only way to disable zlib support would have
been to actually rip out the offending code (which is what I did on my
first attempt).

Since the package does work without compression, and getting zlib to work
is apparently a large stumbling block for people who want to try the
package, I'd even suggest keeping compression off by default (or
determine at compile time if it will work), so that people who try the
code don't run into unpleasant portability issues. Of course, those who
use it in production are encouraged to use compression, but they are
presumably willing to invest some time into getting it working.

<rant mode="on">

This kind of thing is IMHO one of the really unpleasant parts of the Lisp
experience - all too often, my attempts to run new code resulted only in
cryptic error messages. I spent hours trying to get simple CLIM programs
to work, and still haven't succeeded in getting gsharp and closure
running properly. That annoys me despite being a fan of the language, and
I hate to think what impression that makes on people who are less
enthusiastic about it...

BTW, I'm not picking specifically on CMUCL here, I've had similar
experiences with other implementations I've tried. To paraphrase
Spiderman, "with great power comes great fragility"?

</rant>

-Klaus




More information about the cl-pdf-devel mailing list