[cl-gd-devel] images from binary data

[Ryszard Szopa]

On Mon, Apr 28, 2008 at 3:15 PM, Hans Hübner <hans at huebner.org> wrote:
> On Mon, Apr 28, 2008 at 2:08 PM, Ryszard Szopa <ryszard.szopa at gmail.com> wrote:
>  >  CL-GD makes it very easy to output images as bytes to streams.
>  >  However, I haven't noticed any solutions for doing the opposite, that
>  >  is to create a picture from binary data (all the macros want either
>  >  strings or pathnames). How would I do it? Is it going to be very
>  >  difficult? What are the caveats?
>
>  It would not be difficult, but only a little tedious as you would need
>  to add new stub functions to cl-gd-glue.c that call the right
>  gdImageCreateFrom*Ptr function (available in GD2) for the file format
>  in question.  Also, memory handling would be an issue, but you're
>  certainly aware of that.
>
>  I'm not sure how many cl-gd users there are, but I'm certainly one of
>  them.  So please, if you add this, do it in an additive fashion :)

Huh, the problem is that I have no C experience whatsoever and UFFI is
like black magic for me...

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?

Anyway, if I manage to figure this stuff out I will definitely share
it (at least for the sake of code review:-))

My three cents for the load-gd-glue issue:

I understand that a #-lispworks thingie is too much of a kludge for
you? :) Lispworks users would have to call load-cl-glue explicitly,
and all the thousands of SBCL happy hamsters (me among them) would
just keep using cl-gd as before, without noticing anything...OTOH...
yeah, that sounded very sbcl-centric and selfish...

Let's admit, having to explicitly call load-gd-glue is (at least for
me) bothering from the aesthetic point of view. To make things worse,
I know of at least one case of CL-GD being broken with SBCL on a Mac,
and it was an issue related to not being able to find libraries (I
haven't investigated that thing thoroughly, but now my suspect is
load-gd-glue). So, I would go for some ASDF magic. For what I know,
Elephant has quite a complex loading scheme, with delayed loading:
maybe taking a look on what they do would be a good point to start?

As for "going wild with cl-gd's code" thing: I have the feeling that
as a guy who is clueless about C and UFFI I would be a rather poor
choice for a maintainer of a library that's a wrapper over a C
library. I hope that you guys agree. :) But, I can rewrite my macro to
use with-gensyms, and I can try to help with the loading issue.

Cheers,

    -- Richard

-- 
http://szopa.tasak.gda.pl/