[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