I'd like to do some graphics in Lisp (I'm trying to write a
ray-tracer..hehe), but after lots of grief, I couldn't get any of the
graphics libraries working. I tried CL-GD and CL-MAGICK - both with no
avail.
However, I am running CLISP on cygwin over WinXP - so I'm kinda asking
for trouble.. CL-GD's 'cl-gd-glue.c' refuses to compile, giving me a
buncha link errors:
========================================
ld -shared -lbgd -lz -lpng -ljpeg -lfreetype -liconv -lm -lc
cl-gd-glue.o -o cl-gd-glue.so -L/usr/local/lib
cl-gd-glue.o:cl-gd-glue.c:(.text+0x16): undefined reference to `fopen'
cl-gd-glue.o:cl-gd-glue.c:(.text+0x2a): undefined reference to
`gdImageCreateFromJpeg'
cl-gd-glue.o:cl-gd-glue.c:(.text+0x50): undefined reference to `fclose'
cl-gd-glue.o:cl-gd-glue.c:(.text+0x60): undefined reference to
`__errno'
========================================
There's some more..same idea tho. I have all required libraries
installed..why is it even complaining about 'fopen'?
And when I try loading CL-MAGICK in CLISP, I get:
========================================
[4]> (asdf-load :cl-magick)
; loading system definition from
/cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd into #<PACKAGE
; ASDF3024>
;; Loading file /cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd
...
;; Loaded file /cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd
*** - Condition of type ASDF:MISSING-COMPONENT.
Break 1 [5]> :i
component "cl-magick" not found: standard object
type: ASDF:MISSING-COMPONENT
0 [REQUIRES]: "cl-magick"
1 [VERSION]: NIL
2 [PARENT]: NIL
=========================================
So I'm just wondering, has anyone gotten either gfx library to work on
cygwin+CLISP? And if so..how?
Thanks
Steve
From: Edi Weitz
Subject: Re: cl-gd or cl-magick in cygwin/clisp?
Date:
Message-ID: <upsv61q4x.fsf@agharta.de>
On 31 May 2005 22:54:30 -0700, ········@gmail.com wrote:
> However, I am running CLISP on cygwin over WinXP - so I'm kinda
> asking for trouble.. CL-GD's 'cl-gd-glue.c' refuses to compile,
> giving me a buncha link errors:
You can get the DLL in pre-compiled from from the CL-GD webpage.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Edi Weitz
Subject: Re: cl-gd or cl-magick in cygwin/clisp?
Date:
Message-ID: <ull5u1q2w.fsf@agharta.de>
On Wed, 01 Jun 2005 09:40:30 +0200, Edi Weitz <········@agharta.de> wrote:
> You can get the DLL in pre-compiled from from the CL-GD webpage.
Sorry, I missed the part about Cygwin. The pre-compiled DLL is
intended for usage with native Win32. Dunno if it works with Cygwin.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
········@gmail.com writes:
> I'd like to do some graphics in Lisp (I'm trying to write a
> ray-tracer..hehe), but after lots of grief, I couldn't get any of the
> graphics libraries working. I tried CL-GD and CL-MAGICK - both with no
> avail.
>
> However, I am running CLISP on cygwin over WinXP - so I'm kinda asking
> for trouble.. CL-GD's 'cl-gd-glue.c' refuses to compile, giving me a
> buncha link errors:
>
> ========================================
> ld -shared -lbgd -lz -lpng -ljpeg -lfreetype -liconv -lm -lc
> cl-gd-glue.o -o cl-gd-glue.so -L/usr/local/lib
Maybe you need some more -L/x/y/path??
Unfortunately, while my UFFI macros manage to get the cl-gd tests 1-4,
6-10, 13, 15 and 17 to succeed (and a small patch to get only 12,16
and 17 to fail), cl-gd cannot be considered functional with clisp.
There's an unresolved issue involving uffi:deref-pointer/array and
more precisely the difference between dereferencing primitive
(immediate) vs. structured types.
> And when I try loading CL-MAGICK in CLISP, I get:
> [4]> (asdf-load :cl-magick)
> ; loading system definition from
> /cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd into #<PACKAGE
> ; ASDF3024>
> ;; Loading file /cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd
> ...
> ;; Loaded file /cygdrive/c/_STEVEN/lib/lisp/system-links/cl-magick.asd
> *** - Condition of type ASDF:MISSING-COMPONENT.
> Break 1 [5]> :i
> component "cl-magick" not found: standard object
> type: ASDF:MISSING-COMPONENT
> 0 [REQUIRES]: "cl-magick"
> 1 [VERSION]: NIL
> 2 [PARENT]: NIL
> =========================================
I remember having a similar problem with cl-gd. IIRC,
asdf::*central-registry* was not correctly set and e.g. it could not
find the :uffi package that it depends on, yet the error did not
mention uffi.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Edi Weitz
Subject: Re: cl-gd or cl-magick in cygwin/clisp?
Date:
Message-ID: <uk6lerwtj.fsf@agharta.de>
On 01 Jun 2005 16:03:58 +0200, Joerg Hoehle <······@users.sourceforge.net> wrote:
> Unfortunately, while my UFFI macros manage to get the cl-gd tests
> 1-4, 6-10, 13, 15 and 17 to succeed (and a small patch to get only
> 12,16 and 17 to fail), cl-gd cannot be considered functional with
> clisp.
Note that Carlos Ungil has made available a CLISP version of CL-GD
which is linked from the CL-GD home page (right at the top).
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> Note that Carlos Ungil has made available a CLISP version of CL-GD
> which is linked from the CL-GD home page (right at the top).
I've updated that file, now the patches apply to the latest release of
cl-gd (0.4.8).
It's been tested on Solaris and Windows (native), only one test (17)
reports a failure.
The definition of *cl-gd-glue* in gd-clisp.lisp has to be changed on
Windows, to use the "dll" extention (not "so") (and if the dll is not in
the cl-gd directory this is the place to change the path as well).
I guess it should not be dificult to make it work in cygwin, but I've
not tried.
Carlos
Carlos Ungil wrote:
> Edi Weitz wrote:
>> Note that Carlos Ungil has made available a CLISP version of CL-GD
>> which is linked from the CL-GD home page (right at the top).
>
> I've updated that file, now the patches apply to the latest release of
> cl-gd (0.4.8).
>
> It's been tested on Solaris and Windows (native), only one test (17)
> reports a failure.
>
> The definition of *cl-gd-glue* in gd-clisp.lisp has to be changed on
> Windows, to use the "dll" extention (not "so") (and if the dll is not in
> the cl-gd directory this is the place to change the path as well).
>
> I guess it should not be dificult to make it work in cygwin, but I've
> not tried.
>
> Carlos
Thank you very much for making this available!!!
I was in doubt whether common-lisp was the right decision as a pl since it
seems to lack available libraries...
IMHO
the following libs MUST be ported to make cl a success:
* imagemagick/gd
* sdl/opengl
* ...
More important would be having NATIVE libs, entirely written in cl.
greets
oni
Onay Urfalioglu <·····@gmx.net> writes:
> Carlos Ungil wrote:
>
> IMHO
> the following libs MUST be ported to make cl a success:
Lisp is /already/ successful. I know this because David Lamkins has
written a book titled "Successful Lisp".
Zach
Onay Urfalioglu wrote:
> Carlos Ungil wrote:
>
>
>>Edi Weitz wrote:
>>
>>>Note that Carlos Ungil has made available a CLISP version of CL-GD
>>>which is linked from the CL-GD home page (right at the top).
>>
>>I've updated that file, now the patches apply to the latest release of
>>cl-gd (0.4.8).
>>
>>It's been tested on Solaris and Windows (native), only one test (17)
>>reports a failure.
>>
>>The definition of *cl-gd-glue* in gd-clisp.lisp has to be changed on
>>Windows, to use the "dll" extention (not "so") (and if the dll is not in
>>the cl-gd directory this is the place to change the path as well).
>>
>>I guess it should not be dificult to make it work in cygwin, but I've
>>not tried.
>>
>>Carlos
>
>
> Thank you very much for making this available!!!
> I was in doubt whether common-lisp was the right decision as a pl since it
> seems to lack available libraries...
>
> IMHO
> the following libs MUST be ported to make cl a success:
>
> * imagemagick/gd
> * sdl/opengl
> * ...
Were you trying to list unavailable libraries? Other than GD, I use or
have used them all. Looks like GD is no problem, either.
>
> More important would be having NATIVE libs, entirely written in cl.
If a C library is well designed, it functions as a black box. This is
important whether I am calling it from C or Lisp. So almost nothing is
to be gained by reinventing them in Lisp. At the same time, these are
big libraries, so we are talking about a huge effort to achieve
practically nothing, when we could be writing new functionality.
kenny
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
>
>
> Onay Urfalioglu wrote:
>
>> IMHO
>> the following libs MUST be ported to make cl a success:
>>
>> * imagemagick/gd * sdl/opengl * ...
>
>
> Were you trying to list unavailable libraries? Other than GD, I use or
> have used them all. Looks like GD is no problem, either.
>
>>
>> More important would be having NATIVE libs, entirely written in cl.
>
>
> If a C library is well designed, it functions as a black box. This is
> important whether I am calling it from C or Lisp. So almost nothing is
> to be gained by reinventing them in Lisp. At the same time, these are
> big libraries, so we are talking about a huge effort to achieve
> practically nothing, when we could be writing new functionality.
The truth about black boxes, though, is that once they're working,
virtually nobody looks inside them, well designed or not. For example gd
which, when reading a GIF image, reads codes one ... bit ... at ... a
... time. An inefficient strategy, since codes are often 9-12 bits long.
Sure, you can get this slow implementation practically for free, if you
want to relive the glory days of 8-bit computing. Sometimes reusing a
library is just standing on the same midget's shoulders that everyone
else is standing on.
Cameron MacKinnon wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Onay Urfalioglu wrote:
>>
>>> IMHO
>>> the following libs MUST be ported to make cl a success:
>>>
>>> * imagemagick/gd * sdl/opengl * ...
>>
>>
>>
>> Were you trying to list unavailable libraries? Other than GD, I use or
>> have used them all. Looks like GD is no problem, either.
>>
>>>
>>> More important would be having NATIVE libs, entirely written in cl.
>>
>>
>>
>> If a C library is well designed, it functions as a black box. This is
>> important whether I am calling it from C or Lisp. So almost nothing is
>> to be gained by reinventing them in Lisp. At the same time, these are
>> big libraries, so we are talking about a huge effort to achieve
>> practically nothing, when we could be writing new functionality.
>
>
> The truth about black boxes, though, is that once they're working,
> virtually nobody looks inside them, well designed or not. For example gd
> which, when reading a GIF image, reads codes one ... bit ... at ... a
> ... time. An inefficient strategy, since codes are often 9-12 bits long.
> Sure, you can get this slow implementation practically for free, if you
> want to relive the glory days of 8-bit computing. Sometimes reusing a
> library is just standing on the same midget's shoulders that everyone
> else is standing on.
Nowhere did I say "use a crappy C library". If you are saying there is
no good C library and that new code must be written, well then we are
not talking about /rewriting/ libraries in Lisp. If you are saying the C
library is fine but has a flaw, do what I did with FreeGlut: submit a
patch.
kenny
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd