From tpapp at Princeton.EDU  Sat May  3 15:43:13 2008
From: tpapp at Princeton.EDU (Tamas K Papp)
Date: Sat, 3 May 2008 11:43:13 -0400
Subject: [cl-cairo2-devel] issues with cl-cairo2 from asdf-install
In-Reply-To: <7758b2680804290857q7c4d933ftd3fe41f7c92ff7c5@mail.gmail.com>
References: <7758b2680804290857q7c4d933ftd3fe41f7c92ff7c5@mail.gmail.com>
Message-ID: <20080503154313.GA1111@pu100877.student.princeton.edu>

On Tue, Apr 29, 2008 at 05:57:41PM +0200, Peter Hildebrandt wrote:

Hi Peter,

Sorry, I didn't have time to investigate this until now.

> I just tried to pull in a current version of cl-cairo2 via
> asdf-install, and I ran into the following:
> 
> There is no class named CL-CAIRO2::MY-DOUBLE-TYPE.
> 
> (in cl-cairo2-swig)
> 
> For me, the failing define-foreign-type expands into:
> 
> (PROGN
>  (CFFI::DEFINE-TYPE-SPEC-PARSER MY-DOUBLE-TYPE NIL
>                                 (MAKE-INSTANCE 'CFFI::FOREIGN-TYPEDEF :NAME
>                                                'MY-DOUBLE-TYPE :ACTUAL-TYPE
>                                                (CFFI::PARSE-TYPE
>                                                 (PROGN
>                                                  NIL
>                                                  (:ACTUAL-TYPE :DOUBLE)
>                                                  (:SIMPLE-PARSER MY-DOUBLE)))))
>  'MY-DOUBLE-TYPE)
> 
> Note that parse-type is a function, thus (:actual-type ...) will be
> interpreted as a function call.
> 
> This could be due a cffi mismatch:  I have cffi 0.9.2 (the latest
> release).  Do you use the one from darcs?

There has been a change in CFFI, AFAIK cl-cairo2 uses the new
interface.  My cffi version is 20080217-1, which does not appear to be
in Ubuntu, so you should do a manual install from the repository.
BTW, my version is from the latest (unstable) Debian package, so maybe
it would help to nudge the Ubuntu maintainers to package the latest version.

> Also, all three library names don't work in Ubuntu 8.04.  I added the
> alternatives:
> 
> cairo.lisp:
> (load-foreign-library '(:or "libcairo" "libcairo.so.2"))
> 
> gtk-context.lisp:
> (define-foreign-library :gdk
>   (cffi-features:unix (:or "libgdk-x11-2.0.so" "libgdk-x11-2.0.so.0"))
>   (cffi-features:windows "libgdk-win32-2.0-0.dll")
>   (cffi-features:darwin "libgdk-win32-2.0-0.dylib"))
> 
> xlib.lisp:
> (load-foreign-library '(:or "libX11.so" "libX11.so.6"))

Please try the new version of CFFI with the original code, and tell me
if the error persists.

Tamas


From peter.hildebrandt at gmail.com  Sat May  3 17:49:37 2008
From: peter.hildebrandt at gmail.com (Peter Hildebrandt)
Date: Sat, 3 May 2008 19:49:37 +0200
Subject: [cl-cairo2-devel] issues with cl-cairo2 from asdf-install
In-Reply-To: <20080503154313.GA1111@pu100877.student.princeton.edu>
References: <7758b2680804290857q7c4d933ftd3fe41f7c92ff7c5@mail.gmail.com>
	<20080503154313.GA1111@pu100877.student.princeton.edu>
Message-ID: <7758b2680805031049j28c124ccr4b56b931459eef2d@mail.gmail.com>

Tamas,

thanks for getting back to me.  I had postponed the cffi upgrade,
because it breaks cells-gtk.  I guess the time has come and I have to
figure out how to change those typedefs.

Anyway, asdf-install failed around the my-double-type form.  I created
a quick fix with #+sbcl features.  The attached patch also contains
additions for the library names on ubuntu 8.04 (name.so.X instead of
name.so).

Thanks again,
Peter


On Sat, May 3, 2008 at 5:43 PM, Tamas K Papp <tpapp at princeton.edu> wrote:
> On Tue, Apr 29, 2008 at 05:57:41PM +0200, Peter Hildebrandt wrote:
>
>  Hi Peter,
>
>  Sorry, I didn't have time to investigate this until now.
>
>
>  > I just tried to pull in a current version of cl-cairo2 via
>  > asdf-install, and I ran into the following:
>  >
>  > There is no class named CL-CAIRO2::MY-DOUBLE-TYPE.
>  >
>  > (in cl-cairo2-swig)
>  >
>  > For me, the failing define-foreign-type expands into:
>  >
>  > (PROGN
>  >  (CFFI::DEFINE-TYPE-SPEC-PARSER MY-DOUBLE-TYPE NIL
>  >                                 (MAKE-INSTANCE 'CFFI::FOREIGN-TYPEDEF :NAME
>  >                                                'MY-DOUBLE-TYPE :ACTUAL-TYPE
>  >                                                (CFFI::PARSE-TYPE
>  >                                                 (PROGN
>  >                                                  NIL
>  >                                                  (:ACTUAL-TYPE :DOUBLE)
>  >                                                  (:SIMPLE-PARSER MY-DOUBLE)))))
>  >  'MY-DOUBLE-TYPE)
>  >
>  > Note that parse-type is a function, thus (:actual-type ...) will be
>  > interpreted as a function call.
>  >
>  > This could be due a cffi mismatch:  I have cffi 0.9.2 (the latest
>  > release).  Do you use the one from darcs?
>
>  There has been a change in CFFI, AFAIK cl-cairo2 uses the new
>  interface.  My cffi version is 20080217-1, which does not appear to be
>  in Ubuntu, so you should do a manual install from the repository.
>  BTW, my version is from the latest (unstable) Debian package, so maybe
>  it would help to nudge the Ubuntu maintainers to package the latest version.
>
>
>  > Also, all three library names don't work in Ubuntu 8.04.  I added the
>  > alternatives:
>  >
>  > cairo.lisp:
>  > (load-foreign-library '(:or "libcairo" "libcairo.so.2"))
>  >
>  > gtk-context.lisp:
>  > (define-foreign-library :gdk
>  >   (cffi-features:unix (:or "libgdk-x11-2.0.so" "libgdk-x11-2.0.so.0"))
>  >   (cffi-features:windows "libgdk-win32-2.0-0.dll")
>  >   (cffi-features:darwin "libgdk-win32-2.0-0.dylib"))
>  >
>  > xlib.lisp:
>  > (load-foreign-library '(:or "libX11.so" "libX11.so.6"))
>
>  Please try the new version of CFFI with the original code, and tell me
>  if the error persists.
>
>  Tamas
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-cairo2-sbcl.patch
Type: application/octet-stream
Size: 2488 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-cairo2-devel/attachments/20080503/d3350bec/attachment.obj>

From cupe-cl-cairo2 at erleuchtet.org  Tue May 27 23:58:55 2008
From: cupe-cl-cairo2 at erleuchtet.org (Johann Korndoerfer)
Date: Wed, 28 May 2008 01:58:55 +0200
Subject: [cl-cairo2-devel] patch for image-surface-get-data
Message-ID: <483CA03F.10402@erleuchtet.org>

hello

included is a diff for extending cl-cairo2 to support extracting pixel
data (as a 1d array) from image surfaces via image-surface-get-data. it
also fixes a minor glitch concerning error messages thrown when a symbol
was not found in a table.

i also noticed something like
(cl-cairo2:create-image-surface 'format-argb32 23 42))
will not work (complaining about not finding the symbol) since the
symbol cl-user:format-argb32 obviously is not the same as
cl:cairo2:format-argb32.

i therefore suggest using keyword symbols for the right halves of the
tables as well if there is no reason to do otherwise.

johann
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: image-surface-get-data.diff
URL: <https://mailman.common-lisp.net/pipermail/cl-cairo2-devel/attachments/20080528/31ec180c/attachment.ksh>

From tpapp at Princeton.EDU  Wed May 28 01:36:23 2008
From: tpapp at Princeton.EDU (Tamas K Papp)
Date: Tue, 27 May 2008 21:36:23 -0400
Subject: [cl-cairo2-devel] patch for image-surface-get-data
In-Reply-To: <483CA03F.10402@erleuchtet.org>
References: <483CA03F.10402@erleuchtet.org>
Message-ID: <20080528013623.GA25551@pu100877.student.princeton.edu>

Hi Johann,

Thanks, I applied your patch.  It is now committed to the repository.

I think that the change to keywords you suggested is very sensible,
and I will do it as soon as I have the time.  I will be travelling
until Tuesday though, so that is the earliest I can do it.  In the
meantime, if you feel you would like to do it and submit a patch, that
would be very welcome.

Best,

Tamas



On Wed, May 28, 2008 at 01:58:55AM +0200, Johann Korndoerfer wrote:
> hello
> 
> included is a diff for extending cl-cairo2 to support extracting pixel
> data (as a 1d array) from image surfaces via image-surface-get-data. it
> also fixes a minor glitch concerning error messages thrown when a symbol
> was not found in a table.
> 
> i also noticed something like
> (cl-cairo2:create-image-surface 'format-argb32 23 42))
> will not work (complaining about not finding the symbol) since the
> symbol cl-user:format-argb32 obviously is not the same as
> cl:cairo2:format-argb32.
> 
> i therefore suggest using keyword symbols for the right halves of the
> tables as well if there is no reason to do otherwise.
> 
> johann

> Index: tables.lisp
> ===================================================================
> --- tables.lisp	(revision 19)
> +++ tables.lisp	(working copy)
> @@ -112,5 +112,5 @@
>  (defun lookup-enum (enum table)
>    (let ((cairo-enum (car (rassoc enum table))))
>      (unless cairo-enum
> -      (error "Could not find ~a in ~a." cairo-enum table))
> +      (error "Could not find ~a in ~a." enum table))
>      cairo-enum))
> Index: surface.lisp
> ===================================================================
> --- surface.lisp	(revision 19)
> +++ surface.lisp	(working copy)
> @@ -113,6 +113,25 @@
>  			       width height)
>     width height t))
>  
> +(defun get-bytes-per-pixel (format)
> +  (case format
> +    (format-argb32 4)
> +    (format-rgb24 3)
> +    (format-a8 1)
> +    (otherwise (error (format nil "unknown format: ~a" format))))) ;todo: how does format-a1 fit in here?
> +
> +(defun image-surface-get-data (surface)
> +  (with-surface (surface pointer)
> +    (let* ((width (image-surface-get-width surface))
> +           (height (image-surface-get-height surface))
> +           (bytes-per-pixel (get-bytes-per-pixel (image-surface-get-format surface)))
> +           (buffer (make-array (* width height bytes-per-pixel) :element-type '(unsigned-byte 8) :fill-pointer 0))
> +           (data (cairo_image_surface_get_data pointer)))
> +      (loop for i from 0 below (* width height bytes-per-pixel) do
> +         (vector-push-extend (cffi:mem-ref data :uint8 i) buffer))
> +      buffer)))
> +
> +
>  (defun image-surface-get-format (surface)
>    (with-surface (surface pointer)
>      (lookup-cairo-enum (cairo_image_surface_get_format pointer) table-format)))
> Index: package.lisp
> ===================================================================
> --- package.lisp	(revision 19)
> +++ package.lisp	(working copy)
> @@ -14,6 +14,7 @@
>     destroy create-ps-surface create-pdf-surface create-svg-surface
>     create-image-surface image-surface-get-format
>     image-surface-get-width image-surface-get-height
> +   image-surface-get-data
>     image-surface-create-from-png surface-write-to-png
>      
>     ;; context

> _______________________________________________
> cl-cairo2-devel mailing list
> cl-cairo2-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-cairo2-devel



From cupe-cl-cairo2 at erleuchtet.org  Sat May 31 23:00:00 2008
From: cupe-cl-cairo2 at erleuchtet.org (Johann Korndoerfer)
Date: Sun, 01 Jun 2008 01:00:00 +0200
Subject: [cl-cairo2-devel] modifying cl-cairo2-swig.lisp
In-Reply-To: <20080528013623.GA25551@pu100877.student.princeton.edu>
References: <483CA03F.10402@erleuchtet.org>
	<20080528013623.GA25551@pu100877.student.princeton.edu>
Message-ID: <4841D870.2030000@erleuchtet.org>

hi

Tamas K Papp wrote:
> I think that the change to keywords you suggested is very sensible [...]
> if you feel you would like to do it and submit a patch

After poking around i found the table mechanism quite unnecessary
because the cenums could just be renamed to something prettier. I did
that (completely emptying the tables.lisp) and also changed the naming
scheme of the cfuns from cairo_foo_bar to cairo-foo-bar to make them
more pleasing to the eye (mine at least), so now the only file
containing underscores is cl-cairo2-swig.lisp. changing this file means
that it will no longer be possible to generate cl-cairo2-swig.lisp with
swig, leading to the obvious disadvantage that catching cairo api
changes will not be as easy as before. i still think it is worth it
since the code has become much more simple and readable in my opinion
and we can always easily extend the file when cairo's api is extended,
which should not be that often. this is of course very debatable :)


This patch also constitutes an api change: instead of

(cl-cairo2:create-image-surface 'cl-cairo2:format-argb32 23 42))

the user will have to write

(cairo:create-image-surface :argb32 23 42))

and similarly for font weight etc. The examples and the tutorial have
been updated to reflect this change. I also added :cairo as a nickname
for the package and fixed some minor bugs i stumbled upon.

Since i will be needing patterns, i have started a pattern.lisp which i
will submit as soon as it is complete.

greetings
johann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tables-removed.tar.gz
Type: application/x-gzip
Size: 15898 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-cairo2-devel/attachments/20080601/443b6e3f/attachment.bin>