gmane.lisp.graphics.gd.devel

Re: FFI error (I assume)

Jeffrey Cunningham — 2011-10-23T16:23:47

Have you compiled the glue library? If not, go inside the cl-gd source  
directory and run make. It should produce cl-gd-glue.so.
If it complains, look close - you probably don't have all the dependencies  
built. You need the gd library 2.x and it has requirements of its own.

Jeff


On Sun, 23 Oct 2011 09:23:32 -0700, Leo Zovic <leo.zovic< at >gmail.com> wrote:

> Any ideas?

FFI error (I assume)

Leo Zovic — 2011-10-23T16:23:32

Not sure whether this is a bug, or I don't have a required library set up.
Whenever I try to do

(with-image-from file (img "/my/image/path.jpg")
    (image-size img))

I get an UNDEFINED-ALIEN-FUNCTION-ERROR

trace follows

Attempt to call an undefined alien function.
   [Condition of type SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING
{10032E9BA1}>)

Backtrace:
  0: (SB-KERNEL::UNDEFINED-ALIEN-FUNCTION-ERROR)
  1: ("foreign function: #x422520")
  2: (GD-IMAGE-CREATE-FROM-JPEG-FILE "/my/image.path.jpg"
#<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF37AFFF0 :TYPE (*
(SB-ALIEN:SIGNED 32))>)
  3: (CREATE-IMAGE-FROM-FILE #<unavailable argument> NIL)
  4: ((LAMBDA ()))
  5: (SB-INT:SIMPLE-EVAL-IN-LEXENV ..)
  6: (SWANK::EVAL-REGION "(with-image-from-file (img
\"/my/image.path.jpg\")\n   (image-size img))\n")
  7: ((LAMBDA ()))
  8: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {1004B732C9}>)
  9: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request."
#<CLOSURE (LAMBDA #) {1004B731E9}>)
 10: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<CLOSURE (LAMBDA #) {1004B731B9}>)
 11: (SWANK::REPL-EVAL "(with-image-from-file (img \"/my/image.path.jpg\")\n
(image-size img))\n")
 12: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL
"(with-image-from-file (img \"/my/image.path.jpg\")\n   (image-size
img))\n") #<NULL-LEXENV>)
 13: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(with-image-from-file (img
\"/my/image.path.jpg\")\n   (image-size img))\n") "CL-GD" 172)
 14: (SWANK::PROCESS-REQUESTS NIL)
 15: ((LAMBDA ()))
 16: ((LAMBDA ()))
 17: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10032F3139}>)
 18: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10032F3139}>)
 19: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #) (*STANDARD-INPUT* .
#) (*TRACE-OUTPUT* . #) (*ERROR-OUTPUT* . #) (*DEBUG-IO* . #) (*QUERY-IO* .
#) ...) #<CLOSURE (LAMBDA #) {10032F3159}>)
 20: (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {1002E87B91}> NIL)
 21: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {10032F30F9}>)
 22: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK369]374))
 23: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 24: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300))
 25: (SB-THREAD::CALL-WITH-MUTEX ..)
 26: (SB-THREAD::INITIAL-THREAD-FUNCTION)
 27: ("foreign function: #x422520")
 28: ("foreign function: #x419227")

I've tried it running SBCL 1.0.40 from the Debian repos, as well as 1.0.52
from the official SBCL site. I'm using the copy of cl-gb from the latest
quicklisp release, and I've tried it on both a 32 bit and 64 bit system (the
included stack trace is from the 64-bit SBCL 1.0.40).

Any ideas?

Re: CL-GD on 64-bit Lisp problem

Jeffrey Cunningham — 2011-09-08T18:05:12

Thank you for the help, Hans. That was just an experiment. Normally, I  
load UFFI. But you said something that made me go back and look at my sbcl  
executable. Turns out I somehow built a 32-bit sbcl on this 64-bit  
machine. That explains everything (except why it built sbcl that way).

So it's clearly not a CL-GD issue at all.
Thanks again,

--Jeff



On Thu, 08 Sep 2011 10:29:43 -0700, Hans Hübner <hans.huebner< at >gmail.com>  
wrote:



--

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: CL-GD on 64-bit Lisp problem

Hans Hübner — 2011-09-08T17:29:43

Hi Jeff,

I have just tried :cl-gd on my Ubuntu 64 bit box with CCL.  Things
work as expected.  I have used quicklisp to load it.

The error message that you've pasted indicates that you have loaded
cffi-uffi-compat library.  Don't do that, use UFFI instead.

Anything else we can help with, let us know.
-Hans

On Thu, Sep 8, 2011 at 6:46 PM, Jeffrey Cunningham
<jeffrey< at >jkcunningham.com> wrote:

Re: CL-GD on 64-bit Lisp problem

Jeffrey Cunningham — 2011-09-08T16:46:05

I just tried coming at it a different way and get a different error  
message:

(require 'cffi-uffi-compat)
(require 'cl-gd)
ASDF could not load cl-gd because
UFFI is a nickname for the package CFFI-UFFI-COMPAT.

UFFI is a nickname for the package CFFI-UFFI-COMPAT
    [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]

Restarts:
  0: [TRY-RECOMPILING] Recompile package and try loading it again
  1: [RETRY] Retry loading FASL for #<CL-SOURCE-FILE "uffi" "src"  
"package">.
  2: [ACCEPT] Continue, treating loading FASL for #<CL-SOURCE-FILE "uffi"  
"src" "package"> as having been successful.
  3: [*ABORT] Return to SLIME's top level.
  4: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"  
RUNNING {B113561}>)

Backtrace:
   0: (SB-IMPL::UPDATE-PACKAGE-WITH-VARIANCE ..)

So it seems that if cl-gd gets loaded first, it sees the 32/64-bit glue  
problem. But if cffi-uffi-compat is loaded first, cl-gd isn't compatible  
with my unaltered cffi / uffi installation.

--Jeff




On Thu, 08 Sep 2011 09:16:07 -0700, Hans Hübner <hans.huebner< at >gmail.com>  
wrote:



--

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: CL-GD on 64-bit Lisp problem

Jeffrey Cunningham — 2011-09-08T16:34:00

Hi Hans,

Yes, that was the first thing I did. If I'm reading that error message  
correctly, it saying that ELFCLASS64 is the wrong ELF class, which would  
imply it is looking for 32-bit glue.

On Thu, 08 Sep 2011 09:16:07 -0700, Hans Hübner <hans.huebner< at >gmail.com>  
wrote:



--

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: CL-GD on 64-bit Lisp problem

Hans Hübner — 2011-09-08T16:16:07

Hi Jeff,

I am using CL-GD on 64 bit systems without problems.  Did you
recompile the glue?  The 32 bit .so will not work.

-Hans

On Thu, Sep 8, 2011 at 6:05 PM, Jeffrey Cunningham
<jeffrey< at >jkcunningham.com> wrote:

CL-GD on 64-bit Lisp problem

Jeffrey Cunningham — 2011-09-08T16:05:01

Hi,

I've been using CL-GD on 32-bit systems for years without difficulties.  
Now I'm trying to set a Lisp environment up on a fresh 64-bit Debian  
machine and I can't get CL-GD to work. When I try to load it I get this  
error:

Error opening shared object  
"/home/jcunningham/src/lisp/cl-gd-0.5.7/cl-gd-glue.so":
/home/jcunningham/src/lisp/cl-gd-0.5.7/cl-gd-glue.so: wrong ELF class:  
ELFCLASS64..

I remember their being an issue with CL-GD on 64-bit machines a couple  
years ago that involved having to use CFFI-UFFI-COMPAT instead of CFFI. I  
also vaguely remember that there was a problem at the time trying to have  
both CFFI and UFFI working, as the former used the same asd file name as  
the latter or something like that. Quite a number of other libraries I use  
depend on CFFI so I don't want to do anything that would break it. But I  
also need to get CL-GD working again if this machine is to be useful.

My gd lib is 64-bit - actually, everything I can think of is 64-bit. Is  
this still an issue? Is anyone using CL-GD on a 64-bit machine?

If so, mind sharing what it takes to get it working?

Much obliged.

--Jeff Cunningham


--
--

My open source libraries (aka "ediware")

Edi Weitz — 2011-08-31T15:11:30

[My apologies if you receive multiple copies of this email.]


Hi everybody!

As some of you will know, I'll start on a new job tomorrow.  This new
job won't involve much hacking, if at all, and thus it doesn't look
like I'll have a lot of time to maintain my open source libraries in
the near future.  I have no plans to suddenly disappear from the CL
world, but don't expect new releases of any of my libs any time soon.
(At least none published by me or on my server.)

Luckily, Hans Hübner - who already did most of the maintenance and
development work for Hunchentoot in the last two years or so - offered
to coordinate further development via github.  See his full
announcement at
<http://netzhansa.blogspot.com/2011/08/ediware-moving-to-github.html>.

I'll continue to read the mailing lists for my libs and I'm still
interested in fixing bugs you might find in the release tarballs
available on my web server.  However, I will likely not bother to
discuss or work on new features or compatibility code for
implementations other than LispWorks (which happens to be the one I'm
using).

Lastly, I hope to see a lot of you in Amsterdam
<http://weitz.de/eclm2011/> in October.  The number of registrations
so far has been pretty disappointing, but you still have three weeks
left to change your mind... :)

Take care,
Edi.

Re: CL-GD and LispWorks 5.1: Loading images with extended characters in their pathnames?

Edi Weitz — 2010-09-19T11:57:51

Hi  Chris,

I don't see which of the characters in the file name would not have an
encoding in Latin1.  Is this really the file name you used?

The problem is, though, that UFFI doesn't allow you to specify an
encoding when converting Lisp strings to C strings.  This could
certainly be done in the LispWorks FLI directly and probably (I
haven't looked) in CFFI as well.  A real solution would be to
re-architect CL-GD to use an alternative to UFFI, but I don't have the
time to do it and I haven't used CL-GD for years anyway.

Cheers,
Edi.


On Fri, Sep 17, 2010 at 10:51 PM, Chris Perkins <cperkins< at >medialab.com> wrote:

CL-GD and LispWorks 5.1: Loading images with extended characters in their pathnames?

Chris Perkins — 2010-09-17T20:51:05

Hello,

If I have a pathnamewith extended characters in its namestring (like
curly quotes, etc), how do I get that image to load with CL-GD?

Maybe I have to go diving into UFFI or the sources for GD itself, but I
thought I'd ask here first, since it seems like this has probably come
up already.

Thanks for any assistance,

Chris



Example:  f => #P"/Users/cperkins/Pictures/image file names
testing/Earth “fatter” copy.gif"

(cl-gd:create-image-from-file f)


Error: External format (:LATIN-1 :EOL-STYLE :LF) got error writing
#<Pointer to type (:UNSIGNED :CHAR) = #x0102B008> at position 55: No
encoding exists for character “.
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

Re: Loading Images from Pointers

Christoph Senjak — 2010-05-19T21:51:56

Hello.


CL-GD works (so far), but the page seems not to be up to date, I have
the package libgd-xpm-dev from ubuntu, and /usr/include/gd.h contains
the line

#define GD_VERSION_STRING "2.0.36"

which is, according to that site, a prerelease, which I cannot really
believe since its in a stable ubuntu release. And it also contains the
line

BGD_DECLARE(gdImagePtr) gdImageCreateFromGifPtr (int size, void *data);

But you are right ... cl-gd is not compatible (I should have done the
tests on the same computer I did the other stuff):

CL-USER> (cl-gd-test:TEST )
Test 1 failed with the following error: Attempt to call an undefined
alien function.
Test 2 failed with the following error: Attempt to call an undefined
alien function.
Test 3 failed with the following error: Attempt to call an undefined
alien function.
(...)

So ... well ... how hard would it be to make it compatible with the
new version? Is it just changing a few naming-strings, or more
complicated? I have lisp-magick working now, its just not very well
maintained, but if cl-gd is outdated, then maybe I will write my own
FFI-Binding for GD directly, or keep working with a patched version of
lisp-magick (or do the image-processing in CL directly).

Regards, Christoph

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: Loading Images from Pointers

Edi Weitz — 2010-05-19T14:25:28

On Wed, May 19, 2010 at 4:18 PM, Christoph Senjak
<christoph.senjak< at >googlemail.com> wrote:


Have you made sure that the version of GD you are using is compatible
with the GD docs you pointed to?  I haven't looked at GD for quite
some time, but judging from the URL in your initial email, current GD
seems to use names which are different from the ones used in CL-GD, so
if CL-GD works for you otherwise, you probably don't have the newest
version of GD.

Edi.

Re: Loading Images from Pointers

Hans Hübner — 2010-05-19T14:26:10

Christoph,

can you please post some code that would allow me to try to reproduce
and diagnose the problem in isolation?  Make it a single lisp file
that assumes cl-gd being loaded, attach it to the message that you
send.

Thanks.
Hans

On Wed, May 19, 2010 at 16:18, Christoph Senjak
<christoph.senjak< at >googlemail.com> wrote:

Re: Loading Images from Pointers

Christoph Senjak — 2010-05-19T14:18:26

cffi:foreign-alloc seems to have an argument :initial-contents,
according to what lispbuilder-sdl does. So there should be no need to
perform this loop by hand.

The main problem I have now is that I get strange error messages about
"unknown alien functions" when trying to use def-function (which I
found in gd-uffi.lisp). The function is definitely there, but seems
like uffi cannot find it or something (I am not familiar with uffi).

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: Loading Images from Pointers

Hans Hübner — 2010-05-19T10:43:14

Hi Christoph,

I now understand what you're trying to do.  Here is my take on it:

- Accessing a byte vector as C vector is compiler specific.  A
portable solution would allocate some memory using UFFI's interface to
malloc, copy the data to that memory buffer using a lisp loop and
memory accessor functions, call the required gdCreate* function and
finally free the malloced buffer.

- When you want to avoid the copying overhead (which in my opinion
should only be done if you're dealing with a lot of data), you'll need
to find out how you can pin the byte vector so that the garbage
collector does not move it while you're in the FFI.  Then, you'll need
to find out how you can get a pointer to the byte vector in a format
that is understood by UFFI.

I would first go for the first option and see how that performs (i.e.
if it produces a noticeable performance problem).  The copies that
you'll make are only temporary, so the memory footprint of your
application will be roughly identical.  GD will make its own private
copy of the data anyway.

Let us know if that helps.

-Hans

On Wed, May 19, 2010 at 12:28, Christoph Senjak
<christoph.senjak< at >googlemail.com> wrote:

Re: Loading Images from Pointers

Christoph Senjak — 2010-05-19T10:28:01

2010/5/19 Hans Hübner <hans.huebner< at >gmail.com>:

Hello.

I am loading the files into an array of (unsigned-byte 8):

(defun si (var val)
  (setf (symbol-value (intern var)) val))
(defun init-file (file)
  "Load a file into a Variable. Access with |filename| (without .png
and path)."
  (si (pathname-name file)
      (with-open-file (in file :element-type '(unsigned-byte 8))
        (let* ((length (file-length in))
               (content (make-array (list length)
                                    :element-type '(unsigned-byte 8)
                                    :adjustable nil)))
          (read-sequence content in)
          content))))

The reason I am doing this is that I dont like to have more external
files than necessary, and want them in my core-dump. SDL can load
these byte-arrays with

(sdl-image:load-image x :image-type :PNG :alpha 1)

what it actually does is

(defmethod load-image ((source VECTOR) &key color-key alpha
(image-type nil) (force nil) (free-rwops $
  "Creates and returns a new surface from the image contained in the
byte VECTOR in `SOURCE`."
  (declare (ignore free-rwops))
  (load-image (sdl::create-RWops-from-byte-array source)
              :color-key color-key
              :color-key-at color-key-at
              :alpha alpha
              :image-type image-type
              :force force :free-rwops t))
where
(defun create-RWops-from-byte-array (array)
  "Creates and returns a new `RWOPS` object from the Lisp array `ARRAY`."
  (let ((mem-array (cffi:foreign-alloc :unsigned-char :initial-contents array)))
    (make-instance 'rwops :fp (sdl-cffi::sdl-rw-from-mem mem-array
(length array)))))

which should be about the same lisp-magick does.

Christoph

_______________________________________________
cl-gd-devel site list
cl-gd-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-gd-devel

Re: Loading Images from Pointers

Hans Hübner — 2010-05-19T06:46:42

Hi Christoph,

implementing an interface to gdImageCreateFrom.*Ptr shouldn't be hard,
but I wonder where you'd get your pointers from?  If you could supply
some sample code and data, we may be able to help you out.

-Hans

On Wed, May 19, 2010 at 04:37, Christoph Senjak
<christoph.senjak< at >googlemail.com> wrote:

Loading Images from Pointers

Christoph Senjak — 2010-05-19T02:37:31

Hello.

I have so far been using Lisp-Magick for two reasons: On the one hand,
I didnt know that GD can stretch images, on the other hand, cl-gd
doesnt support reading images from memory. Well, at least according to
[1] there is a function which can do this in libgd, but seems like
this isnt implemented in cl-gd yet. This is in fact the only thing
keeping me from using CL-GD by now. I would like to use it instead of
lisp-magick, since lisp-magick seems not to be well-maintained by now,
and I already have to use a few of my personal patches to it. Anyway,
I am not very familiar with uffi and stuff, I just tried to use
cl-gd::def-function, but didnt really suffice.

Is there any way of getting this function work with CL-GD?

Regards
Christoph Senjak

[1] http://libgd.org/ImageCreation#gdImageCreateFromPngPtr.28int_size.2C_void_.2Adata.29_.28FUNCTION.29

Re: [question] change of colors when tiling an image

2010-03-11T20:14:54

Thank you!
Should have guessed something like that... :)

Kai.


On 19:02 Thu 11 Mar     , Hans Hübner wrote:

Re: [question] change of colors when tiling an image

Hans Hübner — 2010-03-11T18:02:15

Kai,

I guess your tiles are written in palette mode.  Have a look at the
optional TRUE-COLOR-P argument that WITH-IMAGE provides.

-Hans

On Thu, Mar 11, 2010 at 18:29,  <colimal< at >mails.selgrad.org> wrote: