[cl-gd-devel] images from binary data

Hans Hübner hans at huebner.org
Tue Apr 29 12:09:30 UTC 2008


2008/4/29 Ryszard Szopa <ryszard.szopa at gmail.com>:
>  I looked at the documentation of both UFFI (cannot say it is really
>  helpful) and libgd and I actually found the functions I should be
>  calling. Moreover, I think I have quite a clear mental image of what I
>  should be doing (ie. something like in create-image-from-file from the
>  moment it gets an image pointer). My problem (lame as it may be) is
>  that I don't have a clue on how to pass a CL array (exactly, the
>  pointer to a lisp array) to the C function, and I didn't find any
>  examples of code doing such thing.
>
>  Also, why do I have to create a stub function in cl-gd-glue.c? Isn't
>  it enough if I declared the gdImageCreateFrom*Ptr functions with
>  def-function?

It may be possible to call the functions directly, but I'm not sure -
I don't currently have the time to look into this myself, and for my
database system, I am using files for blobs and don't have the need to
keep raw image data in RAM.

About the load-gd-glue issue:  Ideally, one would want to be able to
dump an image of a Lisp with cl-gd loaded and be able to restart it
without having to call load-gd-glue.  I have spent some time with
this, but I think I am not yet there yet.  If there are other things
that make a release of cl-gd worthwhile, I would spend another few
hours on this in order to make it work.  At the moment, it is not
pressuring me.

>From what I remember, SBCL and CCL try to re-load all those shared
libraries that have been loaded at image dump time.  Ideally, they
would not use any absolute path names for that and instead use
LD_LIBRARY_PATH.  And, if I further remember right, the problem with
cl-gd-glue.so is that it is loaded with an absolute path name or some
such.

Sorry that this is a little sketchy.
-Hans



More information about the Cl-gd-devel mailing list