Hello, I am new to lisp but despite my friends dismay am eager to have it do
everything, but ! I am not sure how to access the serials port or the
paralell port. I am currently trying to build a glue program that will have
access to external hardware connected to the com ports and different
software, calling the software I think is not all to difficult but can I
access the ports? how? ( i am using clips) and how well does this method
work for other platforms? (my environment is FreeBSD 4.3)
Also just a question about prototyping: is it as fast as it can be in
python? one real plus for lisp is the ability to produce executable, but is
the code as fast?
just starting,
Stephane
>>>>> On Thu, 19 Jul 2001 16:24:03 -0700, akhar ("akhar") writes:
akhar> Hello, I am new to lisp but despite my friends dismay am eager to have it do
akhar> everything, but ! I am not sure how to access the serials port or the
akhar> paralell port. I am currently trying to build a glue program that will have
akhar> access to external hardware connected to the com ports and different
akhar> software, calling the software I think is not all to difficult but can I
akhar> access the ports? how? ( i am using clips) and how well does this method
akhar> work for other platforms? (my environment is FreeBSD 4.3)
The way that you access an IO device depends on the operating system,
not on the programming language. In Lisp, you would access a serial
port the same way that you would in any other programming language.
On Unix, this is done by opening a file: so you would use Lisp's
OPEN or WITH-OPEN-FILE, along with functions like READ-BYTE,
WRITE-BYTE, maybe FORCE-OUTPUT. and all the other IO functions,
akhar> Also just a question about prototyping: is it as fast as it can be in
akhar> python? one real plus for lisp is the ability to produce executable,
akhar> but is the code as fast?
Prototyping means being able to have a certain degree of flexibility
when you are designing and implementing your program -- you want to
be able to quickly write your program without having to flesh out
every single part of it, without locking down every tedious detail.
Lisp is excellent for this. You also seem to be asking about the
speed of executable programs. Yes, there are high quality Lisp
compilers that produce very fast code.
In article <·············@spacy.Boston.MA.US>, Christopher Stacy wrote:
>The way that you access an IO device depends on the operating system,
>not on the programming language. In Lisp, you would access a serial
>port the same way that you would in any other programming language.
>On Unix, this is done by opening a file: so you would use Lisp's
>OPEN or WITH-OPEN-FILE, along with functions like READ-BYTE,
>WRITE-BYTE, maybe FORCE-OUTPUT. and all the other IO functions,
In POSIX you also have a portable termios interface which lets C programs
do more with serial devices than just byte I/O.
Are there any standard POSIX bindings for Lisp, or do you pretty
much have to hack your own glue using whatever mechanism is particular
to your Lisp implementation?
>>>>> On Thu, 19 Jul 2001 23:09:19 GMT, Kaz Kylheku ("Kaz") writes:
Kaz> In POSIX you also have a portable termios interface which lets C programs
Kaz> do more with serial devices than just byte I/O.
Kaz> Are there any standard POSIX bindings for Lisp, or do you pretty
Kaz> much have to hack your own glue using whatever mechanism is particular
Kaz> to your Lisp implementation?
No, POSIX has not defined any bindings for Lisp. But most Lisp
implementations provide a way to call C functions, so you can use the
same API that you would use for C. (You may have to write the glue,
but that's just a header definition.)
"akhar" wrote:
> Hello, I am new to lisp but despite my friends dismay am eager to have it do
> everything, but ! I am not sure how to access the serials port or the
> paralell port. I am currently trying to build a glue program that will have
> access to external hardware connected to the com ports and different
> software, calling the software I think is not all to difficult but can I
> access the ports? how? ( i am using clips) and how well does this method
> work for other platforms? (my environment is FreeBSD 4.3)
(When you say "clips", do you mean the Common Lisp system called
CLISP?)
You access the serial and parallel ports via their device files
in /dev . As far as your program is concerned, they are just files
that happen to have special behaviour when read and written.
See "man sio" and "man ppbus" and go from there. (Don't
ask me for more details. I don't know anything much about this
stuff.)
> Also just a question about prototyping: is it as fast as it can be in
> python? one real plus for lisp is the ability to produce executable, but is
> the code as fast?
I'm not sure about CLISP, if that's what you're using, but
other Common Lisp systems can produce code of speed comparable
to C. If you think of Lisp as a rapid prototyping language and
use it that way, paying absolutely no attention to speed, you're
still likely to get within a factor of 10 of C speeds; hence,
about a factor of 10 faster than Python.
However: (1) If you use CLISP then this isn't true, because
CLISP doesn't compile to native code. I would guess that it
still beats Python for most applications, though. (2) Some
programs may spend almost all their time inside library calls
(ones that do a lot of string manipulation, perhaps), and what
matters then will be the relative quality of Python's library
and your Lisp system's.
Can CLISP really produce executables? If it can, then I'm
certain that those executables will include most or all of
CLISP itself; so be aware that you'll have to distribute them
under the terms of the GNU General Public Licence. Depending
on your situation, this may be good news or bad news.
--
Gareth McCaughan ················@pobox.com
.sig under construc
if CLISP is not a compiler which one is? and how much should I have to pay
for a compiler which will give out efficient C-speed code?
"Gareth McCaughan" <················@pobox.com> wrote in message
·····································@g.local...
> "akhar" wrote:
>
> > Hello, I am new to lisp but despite my friends dismay am eager to have
it do
> > everything, but ! I am not sure how to access the serials port or the
> > paralell port. I am currently trying to build a glue program that will
have
> > access to external hardware connected to the com ports and different
> > software, calling the software I think is not all to difficult but can I
> > access the ports? how? ( i am using clips) and how well does this method
> > work for other platforms? (my environment is FreeBSD 4.3)
>
> (When you say "clips", do you mean the Common Lisp system called
> CLISP?)
>
> You access the serial and parallel ports via their device files
> in /dev . As far as your program is concerned, they are just files
> that happen to have special behaviour when read and written.
> See "man sio" and "man ppbus" and go from there. (Don't
> ask me for more details. I don't know anything much about this
> stuff.)
>
> > Also just a question about prototyping: is it as fast as it can be in
> > python? one real plus for lisp is the ability to produce executable, but
is
> > the code as fast?
>
> I'm not sure about CLISP, if that's what you're using, but
> other Common Lisp systems can produce code of speed comparable
> to C. If you think of Lisp as a rapid prototyping language and
> use it that way, paying absolutely no attention to speed, you're
> still likely to get within a factor of 10 of C speeds; hence,
> about a factor of 10 faster than Python.
>
> However: (1) If you use CLISP then this isn't true, because
> CLISP doesn't compile to native code. I would guess that it
> still beats Python for most applications, though. (2) Some
> programs may spend almost all their time inside library calls
> (ones that do a lot of string manipulation, perhaps), and what
> matters then will be the relative quality of Python's library
> and your Lisp system's.
>
> Can CLISP really produce executables? If it can, then I'm
> certain that those executables will include most or all of
> CLISP itself; so be aware that you'll have to distribute them
> under the terms of the GNU General Public Licence. Depending
> on your situation, this may be good news or bad news.
>
> --
> Gareth McCaughan ················@pobox.com
> .sig under construc
From: Tim Bradshaw
Subject: Re: rs232 ports and fast prototyping
Date:
Message-ID: <ey3n160uisw.fsf@cley.com>
* akhar wrote:
> if CLISP is not a compiler which one is? and how much should I have to pay
> for a compiler which will give out efficient C-speed code?
CLISP *is* a compiled system, but it compiles to a virtual machine,
like Java does, rather than to native code. As with Java this gets
you portability at the expense of speed.
CMUCL is a native compiler which can produce code comparable in speed
to C. It's free. Because it's a native compiler it's significantly
harder to port although I believe it will run on FreeBSD.
There are also several commercial systems which also offer very good
performance, and typically somewhat richer features and better support
than the free systems. At least Franz Allegro runs on FreeBSD.
Xanalys LispWorks might but it's not listed in their supported
platforms (Linux is).
--tim
>>>>> On 20 Jul 2001 09:05:35 +0100, Tim Bradshaw ("Tim") writes:
Tim> CMUCL is a native compiler which can produce code comparable in speed
Tim> to C. It's free. Because it's a native compiler it's significantly
Tim> harder to port although I believe it will run on FreeBSD.
Just to make sure there's no misunderstanding by newer folks,
what Tim means here is that the *compiler* itself is harder to port.
Lisp programs are portable.
"akhar" <·····@videotron.ca> writes:
> Hello, I am new to lisp but despite my friends dismay am eager to
> have it do everything, but ! I am not sure how to access the serials
> port or the paralell port. I am currently trying to build a glue
> program that will have access to external hardware connected to the
> com ports and different software, calling the software I think is
> not all to difficult but can I access the ports? how? ( i am using
> clips) and how well does this method work for other platforms? (my
> environment is FreeBSD 4.3)
Last year I did just that the same with CMUCL under Linux. You open
the device node /dev/ttyS0 and program it with tcsetattr and friends.
These functions were actually builtin, although not all necessary
symbols were exported (which doesn't matter much, just use `::').
It was very nice; you could add a hdlc function and interactively, on
the top level, send and receive frames through modems. My usually
Lisp hating coworkers were very impressed :-) If you insist on using
clisp and functions like tcsetattr aren't builtin there, can't you
just make these library functions interface to Lisp somehow? With
CMUCL this would be possible, but I don't know about clisp.
> Also just a question about prototyping: is it as fast as it can be in
> python? one real plus for lisp is the ability to produce executable, but is
> the code as fast?
As fast as Python? Are you joking? CMUCL generates code that can
easily beat gcc for some problems (just this loooong startup time...).
Play around with `compile' and `disassemble' :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
I wrote:
> As fast as Python? Are you joking? CMUCL generates code that can
> easily beat gcc for some problems (just this loooong startup time...).
Forget the part about the startup time. I admit, I hadn't started
CMUCL for about half a year (was playing around with OCaml all the
time :-). The last version I used was 18b. Could it be that 18b was
slower?? I just installed 18c (got an Email asking me what I was
talking about) and it comes up very fast.
I remember the startup time being so long that I did all benchmarks
only with programs that took extremely long to complete (or I just
used #'time), but that problem seems to be completely gone. I had
also formatted my hard disk and replaced SuSE by Slackware, maybe
that's also got something to do with it :-)
Sorry,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Fernando wrote:
> If you're familiar with Python, you'll love Lisp: it's Python on steroids. ;-)
Depends why he likes Python. If it's for the standard library
and the easy-on-the-eyes syntax, he may find Lisp a bit of a
shock. (I like Lisp syntax just fine, but it takes some getting
used to...)
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <······························@g.local>,
················@pobox.com wrote:
>If it's for [...]
>the easy-on-the-eyes syntax, he may find Lisp a bit of a
>shock.
hey, dems fightin' words!
>(I like Lisp syntax just fine, but it takes some getting
>used to...)
whew! you remembered the personal disclaimer.
sashank
akhar wrote:
>is it as fast as it can be in python? one real plus for lisp is the
>ability to produce executable, but is the code as fast?
python is fast?
The fastest (execution speed, not to write) is usually gcc,
then OCAML (also fast to write, usually the winner of the annual ICFP
contests), then the Common Lisps.
python with perl in the middle of the crowd.
There are some comperative benchsuites:
* http://www.bagley.org/~doug/shootout/ is usually the best site and
has some good links.
but there are others also...
* http://www.lib.uchicago.edu/keith/crisis/crisis.html has a overview.
But http://www.lib.uchicago.edu/keith/crisis/benchmarks/invert/ is
totally wrong. (poor users clisp problems)
http://www.lib.uchicago.edu/keith/crisis/benchmarks/tak/ is better.
* http://wwwipd.ira.uka.de/~prechelt/phonecode/ used no functional
language. => http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf
(but some fancy graphics)
* http://www.strout.net/python/pythonvslisp.html is a joke. (i.e. lisp
no points for open source. this guy doesn't know clisp/cmucl, where
cmucl is even pd!) pythin is more extensible than python, ...
* http://www.w3.org/Conferences/WWW4/Papers/165/ uses xlisp in
its comperative benches :) and also mentions guile. whow, how serious.
* http://www.cs.cornell.edu/icfp/
The annual Functional Programming contest. Big fun. The next is
very soon!
There was a python entry last year.
See http://www.crepuscule.com/icfp/ for more insight.
The famous: "We also eliminated one entry that exhausted our patience"
:)
1999 also OCAML won (against 2 haskells)
1998 Cilk clashed all others.
But beware that usually the people behind and the algorithms are/were
more important then the implementation language :)
--
Reini Urban
http://tv.mur.at/film/