- cl-gd-devel@lists.common-lisp.net - mailman3.common-lisp.net

Gain more energy in bed
by Guy Morin 08 Apr '15

08 Apr '15

http://atifural.com/Sir.html The hottest night of pleasure is for you

1 0

cffi changes are generating deprecation warning in cl-gd now
by Jeff Cunningham 08 Apr '15

08 Apr '15

Hi; A short while ago I started noticing this error message showing up ;; STYLE-WARNING: ;; bare references to struct types are deprecated. Please use (:POINTER (:STRUCT CL-GD::GD-IMAGE)) ;; or (:STRUCT CL-GD::GD-IMAGE) instead. It took me awhile to extract a simple demo case, but I've narrowed it down to the WITH-THICKNESS macro call I believe. I'm not sure which list would be best for this question, so I cross-posted it. Here's a test case. (ql:quickload "cl-gd") (use-package :cl-gd) (let* ((x1 -86) (x2 529) (y1 -0.13) (y2 1.16) (xv '(0.0 1.0 2.0 3.0 4.0)) (yv '(0.99 0.12 0.66 0.24 0.075))) (with-image* (500 250) (allocate-color 255 255 255) (let ((c (allocate-color 0 0 255))) (with-transformation (:x1 x1 :x2 x2 :y1 y1 :y2 y2) (with-thickness (1) (mapl #'(lambda (x y) (when (and (cdr x) (cdr y)) (draw-line (car x) (car y) (cadr x) (cadr y) :color c))) xv yv)) (write-image-to-file "test.png" :if-exists :supersede))))) If you take out the with-thickness macro call the message disappears. I played around with that macro but don't really understand enough about the intricacies of cffi to fix it. Does anyone have any ideas? Here's the macro in question: (defmacro with-thickness ((thickness &key (image '*default-image*)) &body body) "Executes BODY with the current line width of IMAGE set to THICKNESS. The image's previous line width is guaranteed to be restored before the macro exits. Note that the line width is measured in pixels and is not affected by WITH-TRANSFORMATION." (cl-gd::with-unique-names (old-thickness) ;; we rebind everything so we have left-to-right evaluation (cl-gd::with-rebinding (thickness image) `(let ((,old-thickness (thickness ,image))) (unwind-protect (progn (setf (thickness ,image) ,thickness)) ,@body) (setf (thickness ,image) ,old-thickness))))) Much obliged. --Jeff Cunningham

2 1

[cl-gd-devel] Tiny patch for create-image-from-file
by Left Right 29 Dec '12

29 Dec '12

Hello list! I've realized that create-image-from-file will not try to expand logical pathnames. So, I wanted to suggest to change the line: (namestring file-name) to (namestring (translate-logical-pathname file-name)) but I also saw that for CMU there is some other function used to read the name, and so long I don't have it installed and never used it - I don't know whether the same will fit there too. This is line 115 in my version of sources (not modified). This shouldn't break older programs because if there are no translation rules, then the original pathname is returned from translate-logical-pathname, but theoretically, it could produce situations when previously some bizarre file name was taken literally instead of being interpreted. Well, that's it. Oh, and this would probably then apply to other functions that call on C functions to do I/O... If this makes sense, I could search for all such functions and export a clean patch for them. Should I? Best. Oleg

2 3

[cl-gd-devel] FFI error (I assume)
by Leo Zovic 23 Oct '11

23 Oct '11

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?

2 1

[cl-gd-devel] CL-GD on 64-bit Lisp problem
by Jeffrey Cunningham 08 Sep '11

08 Sep '11

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 -- --

2 5

[cl-gd-devel] My open source libraries (aka "ediware")
by Edi Weitz 31 Aug '11

31 Aug '11

[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.

1 0

[cl-gd-devel] CL-GD and LispWorks 5.1: Loading images with extended characters in their pathnames?
by Chris Perkins 19 Sep '10

19 Sep '10

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.

2 1

[cl-gd-devel] Loading Images from Pointers
by Christoph Senjak 19 May '10

19 May '10

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_.…

3 7

[cl-gd-devel] [question] change of colors when tiling an image
by colimal＠mails.selgrad.org 11 Mar '10

11 Mar '10

Hello all :) I'm using cl-gd to generate tiles of a larger image. I'm generating a set of tiles of each, e.g. 256x256 pixels, from an input image that is much larger, e.g. 4096x2048. When using "debug-images" (pngs) with few colors and large areas of the same color this works well. However, when I want to tile a png file with higher frequencies and lots of colors the resulting tile images seem to be resampled somehow, with a huge loss of quality. Here is part of my code: (with-image-from-file (src input-name) (let ((width (image-width src)) (height (image-height src))) ;; store a single tile (defun generate-tile (x y) "Generates a single tile. The index of which is given in x and y" (with-image (dest size size) (copy-image src dest (* x size) (* y size) 0 0 size size) (write-image-to-file (concatenate 'string output-base "-" (write-to-string x) "-" (write-to-string y) "." ext) :image dest :if-exists :supersede :compression-level 0))) ;; master's actual code (let ((count-x (ceiling (/ width size))) (count-y (ceiling (/ height size)))) (format t "Slicing up ~s (~d x ~d) into (~d x ~d) tiles of size (~d x ~d).~%" input-name width height count-x count-y size size) (dotimes (x count-x) (dotimes (y count-y) (generate-tile x y)))))) As you can see, I don't compress the image (doesn't change, if I leave the compression key out), and only copy a given section to the output image. The version of cl-gd I'm using is 0.5.7, the version of is libgd 2.0.0. I would appreciate if someone would hint me to what I'm missing :) Thanks in advance, Kai.

2 2

[cl-gd-devel] New release 0.5.7 (Was: cl-gd patch)
by Edi Weitz 23 Nov '09

23 Nov '09

2009/11/15 Jeff Cunningham <j.k.cunningham(a)comcast.net>: > In any event, now that I've seen Hans' request, I slapped my forehead for > not seeing the debug statements, removed them, and here's the remade patch. I've now uploaded release 0.5.7 which contains your patch. Thanks, Edi.

1 0