I'm currently evaluating Common Lisp as a candidate programming
language for a project I'll be working on this year by myself. I would
like to use this opportunity to learn CL so that I can broaden my
horizons and experience some sort of enlightenment, but not at the
expense of choosing the wrong tool for the job.
Briefly, my project involves a GUI, image processing, user-interaction
with the images to identify interesting features, and numerical
computation (preferably through numerical libraries).
Furthermore, I need cross-platform portability across Unix systems,
Mac OS X and MS Windows. I'm quite sure that in terms of CL
implementations, CLISP gives me this, but I'm not so sure about GUI
bindings.
Currently, the most promising candidate is Python + wxPython + NumPy +
(possibly necessary) PyOpenGL. I would still like to properly consider
CL, though.
Ordinarily, I would learn CL just out of interest, regardless of my
final choice, but I'm strapped for time this year and so I don't have
that luxury right now.
Thankyou for any advice.
Andrew.
From: scott determan
Subject: Re: Is Common Lisp suitable for my task?
Date:
Message-ID: <m3el6qn1er.fsf@yahoo.com>
> Briefly, my project involves a GUI, image processing, user-interaction
> with the images to identify interesting features, and numerical
> computation (preferably through numerical libraries).
Hi Andrew,
I am working on a similar system. I wanted an environment I could use
to prototype and debug vision systems. My application is divided into
two parts: a GUI and low-level vision written with wxWindows and C++
and a lisp program that lets me interact with the images and tokensets
in the GUI. The two programs communicate through a socket. This design
decision also lets me embed debugging code into applications and have
them communicate with my vision environment.
I chose lisp because I believe it is a good match for the "exploratory
programming" I tend to do while building vision algorithms. I was also
impressed with its object system and powerful support for
macros. However, I should mention this is my first real application
using lisp so I'll have a better opinion after I work with lisp some
more.
I also considered Python. I believe it is also a good choice -
especially if you want other people to use your environment. I decided
this was my second choice because I though the environment for lisp
programming (ilisp) was much better than anything python offered.
Good luck,
-Scott
scott determan wrote:
> I also considered Python. I believe it is also a good choice -
> especially if you want other people to use your environment.
I played with Python for image processing for a while and found myself
implementing each and every nontrivial algorithm in C as extension to
Python (because pure Python was unbearably slow). After a while I realized
that development cycles where not as short as I had hoped.
However, if you have a small set of well-defined algorithms to use (let's
say the sort the Python Imaging Library offers) and if you use Python
essentially for scriping these together it's probably a good choice:
Support for GUIs is excellent and there is a library for numerical linear
algebra.
On the (un-common, non-standard) Lisp side there is lush
http://lush.sourceforge.net/ which targets image and signal processing
applications. But I haven't really looked at it, yet.
Matthias
scott determan wrote:
>I am working on a similar system. I wanted an environment I could use
>to prototype and debug vision systems. My application is divided into
>two parts: a GUI and low-level vision written with wxWindows and C++
>and a lisp program that lets me interact with the images and tokensets
>in the GUI. The two programs communicate through a socket. This design
>decision also lets me embed debugging code into applications and have
>them communicate with my vision environment.
>
>
I'm also trying to find a simple way of communication between code
written in C/C++ and CL. I considered
using sockets but sending huge amounts of formatted data (images for
example) is much to slow. Sending
the data in binary form is much faster but not straight forward to do in
CL (or am I wrong?). Do you
exchange image data between the C++ part and your Lisp system and if so
could you give some more details
how you are doing this?
>I chose lisp because I believe it is a good match for the "exploratory
>programming" I tend to do while building vision algorithms. I was also
>impressed with its object system and powerful support for
>macros. However, I should mention this is my first real application
>using lisp so I'll have a better opinion after I work with lisp some
>more.
>
>I also considered Python. I believe it is also a good choice -
>especially if you want other people to use your environment. I decided
>this was my second choice because I though the environment for lisp
>programming (ilisp) was much better than anything python offered.
>
>
>
I'm using Python for scripting a wave optics application. Python is not
my favourite choice but
the application is used mostly by others and they prefer Python over
Lisp. Besides this extending
Python with C/C++ is quite simple (using SWIG ).
Rolf
On Mon, Feb 03, 2003 at 04:59:51PM +0100, Rolf Wester wrote:
> Sending the data in binary form is much faster but not straight
> forward to do in CL (or am I wrong?).
Yes, wrong. Investigate READ-BYTE, WRITE-BYTE, READ-SEQUENCE,
WRITE-SEQUENCE. I don't know what socket package you are using, but
they all have a way to exchange binary data.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
>On Mon, Feb 03, 2003 at 04:59:51PM +0100, Rolf Wester wrote:
>
>
>>Sending the data in binary form is much faster but not straight
>>forward to do in CL (or am I wrong?).
>>
>>
>
>Yes, wrong. Investigate READ-BYTE, WRITE-BYTE, READ-SEQUENCE,
>WRITE-SEQUENCE.
>
Does this also hold for floating point numbers?
When I try (CLISP):
(let ((m (make-array 10 :element-type 'single-float :initial-element 1.0)))
(with-open-file (out "bin_test.dat" :direction :output :element-type '(unsigned-byte 32))
(write-byte (aref m 0) out)))
I get:
*** - 1.0 is not an integer, cannot be output onto #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 32) #P"bin_test.dat">
>I don't know what socket package you are using, but
>they all have a way to exchange binary data.
>
>
I tried this with CMUCL and used CMUCL's socket functions.
Rolf
Rolf Wester <······@ilt.fhg.de> writes:
> Matthew Danish wrote:
>
> >On Mon, Feb 03, 2003 at 04:59:51PM +0100, Rolf Wester wrote:
> >
>
> >>Sending the data in binary form is much faster but not straight
> >> forward to do in CL (or am I wrong?).
>
> >
> >Yes, wrong. Investigate READ-BYTE, WRITE-BYTE, READ-SEQUENCE,
> > WRITE-SEQUENCE.
>
> Does this also hold for floating point numbers?
> When I try (CLISP):
>
> (let ((m (make-array 10 :element-type 'single-float :initial-element 1.0)))
> (with-open-file (out "bin_test.dat" :direction :output :element-type '(unsigned-byte 32))
> (write-byte (aref m 0) out)))
>
> I get:
> *** - 1.0 is not an integer, cannot be output onto #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 32) #P"bin_test.dat">
Pure CL streams aren't good with multivalent data (note that
your output object's type doesn't match your stream's element-type).
However, simple-streams will help you here (this happens to
be on a linux box):
CL-USER(1): (let ((m (make-array 10 :element-type 'single-float :initial-element 1.0)))
(with-open-file (out "bin_test.dat" :direction :output :if-exists :supersede)
(excl:write-vector m out)))
40
CL-USER(2): (shell "od -x bin_test.dat")
0000000 0000 3f80 0000 3f80 0000 3f80 0000 3f80
*
0000040 0000 3f80 0000 3f80
0000050
0
CL-USER(3):
If you wish, you can also limit the number of octets written by
write-vector by using start and end arguments.
> >I don't know what socket package you are using, but
> >they all have a way to exchange binary data.
> >
>
> I tried this with CMUCL and used CMUCL's socket functions.
There is the start of a simple-streams implementation for CMUCL
by Paul Foley at his website. I don't have the url handy.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Rolf Wester wrote:
> Matthew Danish wrote:
>
>>On Mon, Feb 03, 2003 at 04:59:51PM +0100, Rolf Wester wrote:
>>
>>
>>>Sending the data in binary form is much faster but not straight
>>>forward to do in CL (or am I wrong?).
>>>
>>>
>>
>>Yes, wrong. Investigate READ-BYTE, WRITE-BYTE, READ-SEQUENCE,
>>WRITE-SEQUENCE.
>>
> Does this also hold for floating point numbers?
> When I try (CLISP):
>
> (let ((m (make-array 10 :element-type 'single-float :initial-element
> 1.0)))
> (with-open-file (out "bin_test.dat" :direction :output :element-type
> '(unsigned-byte 32))
> (write-byte (aref m 0) out)))
>
> I get:
> *** - 1.0 is not an integer, cannot be output onto #<OUTPUT BUFFERED
> FILE-STREAM (UNSIGNED-BYTE 32) #P"bin_test.dat">
>
>>I don't know what socket package you are using, but
>>they all have a way to exchange binary data.
>>
>>
> I tried this with CMUCL and used CMUCL's socket functions.
Take a look at functions like INTEGER-DECODE-FLOAT and SCALE-FLOAT
ciao,
Jochen
Rolf Wester <······@ilt.fhg.de> writes:
> I'm also trying to find a simple way of communication between code
> written in C/C++ and CL. I considered using sockets but sending huge
> amounts of formatted data (images for example) is much to slow. Sending
> the data in binary form is much faster but not straight forward to do
> in CL (or am I wrong?). Do you exchange image data between the C++ part
> and your Lisp system and if so could you give some more details
> how you are doing this?
I never exchange pixel data between C++ and Lisp. However, I think I
understand your problem. For example, you would like to send a float
from C++ through a socket and on the lisp side convert the 4
unsigned-bytes into a float. I tried to figure this out as well, and
could not. The best I could come up with is to use Lisp's foreign
function interface and read the socket in C (on the lisp side) and let
the FFI take care of the conversion. I should point out that if you're
only concerned with exchanging unsigned-bytes (most image data is
unsigned-byte), then you should be able to do this without the FFI.
I may end up doing things that way, but for now just sending text to
through the sockets is very simple and gets the job done.
> I'm using Python for scripting a wave optics application. Python is
> not my favourite choice but the application is used mostly by others
> and they prefer Python over Lisp. Besides this extending
> Python with C/C++ is quite simple (using SWIG ).
Although I am drifting off-topic for comp.lang.lisp, I thought I would
point out boost's Python library. This also allows you to easily
interface C++ and Python (http://www.boost.org).
-Scott
From: Tim Bradshaw
Subject: Re: Is Common Lisp suitable for my task?
Date:
Message-ID: <ey3adhcmhdg.fsf@cley.com>
* scott determan wrote:
> I never exchange pixel data between C++ and Lisp. However, I think I
> understand your problem. For example, you would like to send a float
> from C++ through a socket and on the lisp side convert the 4
> unsigned-bytes into a float. I tried to figure this out as well, and
> could not.
If you want to do this kind of thing you want some kind of data
representation system which will deal with all the fiddly issues for
you. There are a google of these things: the fashionable one is XML +
900 other layered `standards' to make it do this simple thing. One
which actually solves the simple problems without the vast overhead
and complexity of XML is XDR, which is used for things like sunrpc
(which is probably now called something else) and all the things built
on it. CORBA also has a data representation language, and is probably
higher overhead but more featureful than XDR - it's not impossible to
write simple CORBA programs, but it's not trivial either. There are
several others I'm sure, some of which may be better than either of
these. Ideally, if you just want a stream-based system you want
something which is easily separated from an rpc framework, either by
virtue of not being associated with one, or by virtue of being
well-designed.
I have written stuff using sunrpc (and hence XDR) in Lisp, although it
used a commercial library (which ran on Genera), and also CORBA. I've
stared in horror at the XML standards like everyone else, I guess.
--tim
From: Hannah Schroeter
Subject: Re: Is Common Lisp suitable for my task?
Date:
Message-ID: <b1p62f$dgv$3@c3po.schlund.de>
Hello!
Tim Bradshaw <···@cley.com> wrote:
>[...]
>used a commercial library (which ran on Genera), and also CORBA. I've
>stared in horror at the XML standards like everyone else, I guess.
Unfortunately, there are too many who do NOT stare in horror at that
XML stuff. While I don't suffer under that directly, I just shudder
at the thought of how many cow-orkers make their lifes more "interesting"
(as in "may you live in interesting times")...
Kind regards,
Hannah.
Hi there.
> For example, you would like to send a float
> from C++ through a socket and on the lisp side convert the 4
> unsigned-bytes into a float. I tried to figure this out as well, and
> could not.
I believe that the XDR library is designed for this kind of problem.
Cheers
Mike Thomas.
scott determan <········@world.std.com> writes:
> I never exchange pixel data between C++ and Lisp. However, I think I
> understand your problem. For example, you would like to send a float
> from C++ through a socket and on the lisp side convert the 4
> unsigned-bytes into a float. I tried to figure this out as well, and
> could not.
;;; IEEE 754 floating point converting (int32 -> single float)
(defun int->sf (x)
(declare (type (unsigned-byte 32) x))
(let ((sign (if (logbitp 31 x) -1.0 +1.0))
(mantissa (ldb (byte 23 0) x))
(expt (ldb (byte 8 23) x)))
(declare
(type (unsigned-byte 23) mantissa)
(type (unsigned-byte 8) expt))
(case expt
#|(255
(cond
((plusp mantissa)
+NaN+) ; Not-a-Number
((plusp sign) +PlusINF+) ; +INF
(t +MinusINF+)))|# ; -INF
(0
(if (zerop mantissa)
0.0
(* sign
(scale-float
(coerce mantissa 'single-float)
-149)))) ; Denormalized numbers
(otherwise
(* sign
(scale-float
(coerce (logior mantissa #X800000) 'single-float)
(- expt 150)))))))
--
Ivan Boldyrev remove .microsoft.com from my address
Today is the first day of the rest of your life.
On 2 Feb 2003 04:11:35 -0800, ········@optushome.com.au (Andrew Nesbit)
wrote:
> I'm currently evaluating Common Lisp as a candidate programming
> language for a project I'll be working on this year by myself. I would
Is it a research or commercial project?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
> On 2 Feb 2003 04:11:35 -0800, ········@optushome.com.au (Andrew Nesbit)
> wrote:
>
> > I'm currently evaluating Common Lisp as a candidate programming
> > language for a project I'll be working on this year by myself. I would
>
> Is it a research or commercial project?
Research. The system will be used by one of my professors to aid
his own academic research. I doubt that it will see widespread
distribution.
Andrew.
········@optushome.com.au (Andrew Nesbit) writes:
> I'm currently evaluating Common Lisp as a candidate programming
> language for a project I'll be working on this year by myself. I would
> like to use this opportunity to learn CL so that I can broaden my
> horizons and experience some sort of enlightenment, but not at the
> expense of choosing the wrong tool for the job.
>
> Briefly, my project involves a GUI, image processing, user-interaction
> with the images to identify interesting features, and numerical
> computation (preferably through numerical libraries).
>
> Furthermore, I need cross-platform portability across Unix systems,
> Mac OS X and MS Windows. I'm quite sure that in terms of CL
> implementations, CLISP gives me this, but I'm not so sure about GUI
> bindings.
You can probably do everything except the GUI with portable CL. This
means that you don't have to limit yourself to one implementation.
You can use OpenMCL on OS X, CMUCL on Unix, and Corman Lisp on
Windows, and get a no-$$ solution that works on all three systems.
Varying toplevel features can be a little annoying, but all in all,
I've had good experiences working with projects that run on several
implementations, so long as the code stays good and ANSI (which is
easy in Common Lisp).
If you clearly separate the front-end and the back-end code, and
construct a good interface between the two, that should liberate you
on the GUI front. You can write an implementation of the front-end
interface that simply relays the commands across a socket to a Python
or Java front-end; or you can write a front end for each platform. Or
both. The primary advantage of choosing CL for the back-end, over
something like Python, is that if you run into performance
bottlenecks, you can do something about them.
Another alternative is to use CLIM, and you'll have a portable GUI
across the commercial environments. It costs money, but you should be
able to deploy the same code on LispWorks and/or Allegro on Unix and
Windows, and MCL on the Mac.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Hi,
Thomas F. Burdick wrote:
> You can probably do everything except the GUI with portable CL.
A question that is bothering me for a while: Are there any technical reasons
why there aren't CL-bindings for one of the relatively widespread
GUI-libraries (Qt, Gnome, Tk, wxWindows)? Is it that just nobody bothers
because everyone uses commercial CLs for GUI stuff anyway? Or are there
problems to expect with GC or callback functions on the C/C++ side?
Matthias
Matthias Heiler <····@nspm.de> writes:
> Hi,
>
> Thomas F. Burdick wrote:
>
> > You can probably do everything except the GUI with portable CL.
>
> A question that is bothering me for a while: Are there any technical reasons
> why there aren't CL-bindings for one of the relatively widespread
> GUI-libraries
Oh, there are! GUIs aren't hard in CL, they just make maximum
portability (implementation *and* OS at the same time) difficult.
But...
> (Qt, Gnome, Tk, wxWindows)?
... you need to pull your head out of the Linux/FreeBSD sandpit to see
it (I don't mean this deriseively at all, just that they can suck
one's head in). MCL has bindings for the Mac toolkit, which is quite
a GUI library. OpenMCL has an Objective-C bridge, which means you can
use Cocoa from it, which is another amazing GUI toolkit (among other
things). I have been led to believe that Corman Lisp users use
Corman's bindings to the Win32 toolkit to do their GUI work. And
finally, in the Unix world, we have the layerd standard of CLX, which
is (portable!) bindings to X11. If you're looking for a 90's
standard, try CLM, which interfaces to Motif.
Now, as for Qt, Gnome, and Tk ... well, I think it's mostly a matter
of demand, or a lack thereof. Sure, it might be nice ... but a lot of
things would be nice, and it's pretty far down on my list of
priorities, and I suspect the same is true for a lot of people. Add
to this that there are a lot of people who like to take advantage of
the power you can get from a designed-for-Lisp GUI system, and that
should just about answer your question.
> Is it that just nobody bothers because everyone uses commercial CLs
> for GUI stuff anyway? Or are there problems to expect with GC or
> callback functions on the C/C++ side?
I don't think this last one is the root problem. It's a superficial
one, but if people really cared, it's certainly surmountable.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: Is Common Lisp suitable for my task?
Date:
Message-ID: <3E41664E.4030207@nyc.rr.com>
Matthias Heiler wrote:
> Hi,
>
> Thomas F. Burdick wrote:
>
>
>>You can probably do everything except the GUI with portable CL.
>
>
> A question that is bothering me for a while: Are there any technical reasons
> why there aren't CL-bindings for one of the relatively widespread
> GUI-libraries (Qt, Gnome, Tk, wxWindows)? Is it that just nobody bothers
> because everyone uses commercial CLs for GUI stuff anyway?
That's my take. I have worked with MCL and ACL and tho I passed on their
GUIs 'cuz my homegrown one was more fun, they both had fine little GUI
mechanisms built atop native OS widgets/guis. I have never used LW's
CAPI, but I hear great things about that. Corma offers excellent Win32
access to use native stuff.
When I started on my universal CL gui project most folks suggested I
build it atop some C/C++/Tk GUI library. I decided it would be easier to
argue with the GUI if it was written in CL.
Besides, CL is the greatest language on Earth. We don't need no stinkin'
C GUI library. ie, NIH go home. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore