My major gripe about Common Lisp is that the poor standard library
precludes the writing of any real applications.
Once again, I tried to prove myself wrong, but I'm failing...
I'm trying to write an extensible IRC client (as Emacs is an extensible
text editor). First of all, there's no standard socket library, but
that's not a problem in this case, as I use CLISP, which provides a
socket interface. So far, so good...
When it comes time to write the main loop of the application (which is
necessary because event-based programming doesn't seem to be a big thing
in CL), the best I can come up with is kind of like this:
(defun myor (&rest list)
"Like OR, but evaluates all of its arguments."
(some #'identity list))
(loop
(if (myor (poll-identd-server)
(poll-irc-servers)
(handle-user-input))
(update-display)))
But that uses 100% CPU time, which is very unfriendly.
There's a (sleep) in Common Lisp, but it takes a number of seconds to
sleep, and even 1 second is far too great of a delay for an interactive
application.
But, to be honest, I'm fairly new to Common Lisp. Does anybody have any
suggestions? I'd prefer to write code that's as portable as possible,
which is why I don't like using extensions if possible.
CLISP (or the other CL I was looking at, GCL) doesn't seem to provide
extensions that would be useful for providing a means to create a
friendly application, anyway.
Is it possible to do something in Common Lisp? Or will I have to move to
(and bind myself to) CMU CL?
Thanks (and I apologize for the ranting),
Adam M.
> But that uses 100% CPU time, which is very unfriendly. There's a
> (sleep) in Common Lisp, but it takes a number of seconds to sleep,
> and even 1 second is far too great of a delay for an interactive
> application.
Try the following while running "top" or watching your CPU meter:
(dotimes (i 1000) (sleep .0234324123412412))
--
Fred Gilham ······@csl.sri.com
Time is nature's way of making sure everything doesn't happen at once.
Unfortunately, like most things in nature it doesn't always work.
From: Kenny Tilton
Subject: Re: writing a practical application in common lisp
Date:
Message-ID: <3EB32E3B.5010105@nyc.rr.com>
Fred Gilham wrote:
>>But that uses 100% CPU time, which is very unfriendly. There's a
>>(sleep) in Common Lisp, but it takes a number of seconds to sleep,
>>and even 1 second is far too great of a delay for an interactive
>>application.
>
>
> Try the following while running "top" or watching your CPU meter:
>
> (dotimes (i 1000) (sleep .0234324123412412))
Digression: under ACL if I (sleep 0.1) in my Cello->GLUT event polling
loop I can click back on an ACL IDE window and poke around. But if I
sleep only 0.05, no dice.
I get a huge kick out of that, meaning I need to get out more.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Adam M wrote:
> I'm trying to write an extensible IRC client (as Emacs is an extensible
> text editor).
You might want to look at Jochen Schmidt's "Weird IRC" client at
http://www.dataheaven.de/.
> There's a (sleep) in Common Lisp, but it takes a number of seconds to
> sleep, and even 1 second is far too great of a delay for an interactive
> application.
Sleep takes a real as argument, not an integer. For example, try
(sleep 0.1)
Jeremy.
Jeremy Yallop wrote:
> Adam M wrote:
>> I'm trying to write an extensible IRC client (as Emacs is an extensible
>> text editor).
>
> You might want to look at Jochen Schmidt's "Weird IRC" client at
> http://www.dataheaven.de/.
The most current version is available at
http://sourceforge.net/projects/weird-irc/
>> There's a (sleep) in Common Lisp, but it takes a number of seconds to
>> sleep, and even 1 second is far too great of a delay for an interactive
>> application.
>
> Sleep takes a real as argument, not an integer. For example, try
>
> (sleep 0.1)
I remember being a bit astonished when I saw this the first time in the Spec
:-) - I think thats one of those things that are so typical for Common
Lisp..
To the original topic:
One does not really a sleep - An IRC client works by reading line by line
from the socket connection to the IRC server. If there are no messages
coming in the system blocks in the read-* call until there is input.
If one wants to do other things in parallel to this, multithreading is the
right tool for the job.
ciao,
Jochen
From: Gabe Garza
Subject: Re: writing a practical application in common lisp
Date:
Message-ID: <871xzh5qx0.fsf@ix.netcom.com>
Jochen Schmidt <···@dataheaven.de> writes:
>
> If one wants to do other things in parallel to this, multithreading is the
> right tool for the job.
>
Or a readyness notification system like CMUCL's serve event, which is
implemented on Unix's select system call. It's documented in the
CMUCL users manual, and, combined with the the I/O timeout
functionality provided by CMUCL, usually isn't too hard to use.
Gabe Garza
Adam M. wrote:
> My major gripe about Common Lisp is that the poor standard library
> precludes the writing of any real applications.
This is a too general comment - it always depends on the type of
applications.
> But, to be honest, I'm fairly new to Common Lisp. Does anybody have any
> suggestions? I'd prefer to write code that's as portable as possible,
> which is why I don't like using extensions if possible.
You seem to want multithreading. Multithreading is not standardized in
ANSI Common Lisp, so you have to use implementation-specific extensions.
There are some packages that provide a level of portability in this
regard, like ACL-COMPAT.
> CLISP (or the other CL I was looking at, GCL) doesn't seem to provide
> extensions that would be useful for providing a means to create a
> friendly application, anyway.
Again, it depends on what you mean by the very fuzzy term "friendly".
> Is it possible to do something in Common Lisp? Or will I have to move to
> (and bind myself to) CMU CL?
Choosing an implementation that best suits your needs and using it is
not the worst idea.
> Thanks (and I apologize for the ranting),
Could you try to pose such questions without the ranting in the first
place? It's not very constructive, you know.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Adam M. wrote:
> > My major gripe about Common Lisp is that the poor standard library
> > precludes the writing of any real applications.
>
> This is a too general comment - it always depends on the type of
> applications.
Also, the language didn't want to presuppose the operating system.
That was left to layered standards. The reason for this is that
saying "the operating system must work this way" was the same as
saying "you will not be able to have a conforming CL on operating
systems other than a subset of the ones that may exist". We didn't
want to do that. We felt CL should be a useful tool for whatever
operating system.
Indeed, it wouldn't hurt for those libraries that relate to OS
capabilities to be also standardized, but it's not the highest
priority (compared to some other things) since most serious vendors
and implementors implement and document such capabilities. (There
is quite often an MP or PROCESS package that contains the stuff
you want.)
Applications really might be OS-specific. The issue of SLEEP that you
complain about is a good example--if the native scheduler uses a model
of quanta and process wait functions, that leads to a different kind
of interface than if the native scheduler uses semaphors. That's not
to say you can't simulate one in terms of the other, but it's not
necessarily going to lead to well-tuned applications, and then you'll
be right back here complaining. SLEEP is offered just because it's a
simple concept with an easy interface we were sure made abstract sense
for some applications regardless of the OS, but it is not intended as
a way of implementing the wait part of a serious application's inner
event loop. (Even the notion of what kind of 'events' you're waiting
on is quite OS-specific..)
> > Thanks (and I apologize for the ranting),
>
> Could you try to pose such questions without the ranting in the first
> place? It's not very constructive, you know.
Excellent advice.
Starting with "My major gripe is..." is a poor way to request help.
Try maybe "I'm having trouble doing xxx in implementation yyy.
Can someone help me?"
On 02 May 2003 06:08:04 -0400, Kent M Pitman <······@world.std.com>
wrote:
>Pascal Costanza <········@web.de> writes:
>
>> Adam M. wrote:
>> > My major gripe about Common Lisp is that the poor standard library
>> > precludes the writing of any real applications.
>>
>> This is a too general comment - it always depends on the type of
>> applications.
>
>Also, the language didn't want to presuppose the operating system.
>That was left to layered standards. The reason for this is that
>saying "the operating system must work this way" was the same as
>saying "you will not be able to have a conforming CL on operating
>systems other than a subset of the ones that may exist". We didn't
>want to do that. We felt CL should be a useful tool for whatever
>operating system.
>
With all due respect this is a lame excuse. Other programming
languages like Perl, Python, Ruby, Smalltalk, Eiffiel, Java etc.
( have If forget anything? ) have mangaged to produce implementations
with a high degree of portability. Having used VisualWorks ST and
VisualAge ST on both Windows and Linux, I am shocked at the degree
of portability between the two. Even to the point where 'fork' is
provided on Windows.
In the end what you are saying is that the Lisp committee has much
less confidence in the ability of Lisp programmers ( and in particular
implementation/library programmers ) to abstract than other committees
( formal or informal ) had in their programmers.
>Indeed, it wouldn't hurt for those libraries that relate to OS
>capabilities to be also standardized, but it's not the highest
>priority (compared to some other things) since most serious vendors
>and implementors implement and document such capabilities. (There
>is quite often an MP or PROCESS package that contains the stuff
>you want.)
>
I recently surrendered and began to learn the abomination that
pretends to be a programming language written by Larry "Should Be
Lined Up Against a" Wall. I did this because of CPAN. Like it or not I
could no longer justify bowing off the large set of prewritten
components. For this reason the abomination will rule over other
languages for a while. ( Fortunately the language has some defects
which work against it: it is inherently slow, has clucky gui
interfaces, and produces ungly hard to maintain code. )
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
From: Friedrich Dominicus
Subject: Re: writing a practical application in common lisp
Date:
Message-ID: <87n0i4r0mv.fsf@fbigm.here>
Thaddeus L Olczyk <······@interaccess.com> writes:
> With all due respect this is a lame excuse. Other programming
> languages like Perl, Python, Ruby, Smalltalk, Eiffiel, Java etc.
> ( have If forget anything? ) have mangaged to produce implementations
> with a high degree of portability. Having used VisualWorks ST and
> VisualAge ST on both Windows and Linux, I am shocked at the degree
> of portability between the two. Even to the point where 'fork' is
> provided on Windows.
I'm using LispWorks and it runs on Linux, Windows and even on a
AlphaStation, I take my code and let it run on the other platfrom with
and it runs.
>
> In the end what you are saying is that the Lisp committee has much
> less confidence in the ability of Lisp programmers ( and in particular
> implementation/library programmers ) to abstract than other committees
> ( formal or informal ) had in their programmers.
Hardly. I suggest to check out C and you'll see how sparse a standard
library can be.
> >
> I recently surrendered and began to learn the abomination that
> pretends to be a programming language written by Larry "Should Be
> Lined Up Against a" Wall. I did this because of CPAN. Like it or not I
> could no longer justify bowing off the large set of prewritten
> components. For this reason the abomination will rule over other
> languages for a while.
Very good, you have found you favorite language
Regards
Friedrich
Adam M. <·····@san.rr.com> writes:
> But that uses 100% CPU time, which is very unfriendly.
> There's a (sleep) in Common Lisp, but it takes a number of seconds to
> sleep, and even 1 second is far too great of a delay for an interactive
> application.
The "canonical" way (in the Unix universe, at least) of
sleeping in sub-second increments is to use the select() call (which
> belongs to the socket API, which you're already using).
Alternatively, CLISP may have something called "usleep" or
"msleep"; this would probably be an interface to a system call. If
this interface does not exist, you may be able to create it yourself,
using the CLISP's foreign-language interface.
> But, to be honest, I'm fairly new to Common Lisp. Does anybody have
> any suggestions? I'd prefer to write code that's as portable as
> possible, which is why I don't like using extensions if possible.
CLOCC may have something that you can use (http://clocc.sf.net).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Adam M. <·····@san.rr.com> wrote in message news:<···················@adam.adammil.net>...
> My major gripe about Common Lisp is that the poor standard library
> precludes the writing of any real applications.
Real applications are written all the time in languages that have
standard libraries which don't completely support those applications.
For example, C++ has no support for graphical interfaces or
networking, yet people write applications in C++ that have graphical
interfaces and networking.
Those people are real programmers who know how to solve problems, such
as bridging the gap between the language and the platform.
Java defines a platform that has graphical interfaces and networking,
and yet Java programmers still have to drop to the native interface.
No abstraction layer gives you everything on every possible platform,
and what glue is available is sometimes not always efficient or
complete.
> (loop
> (if (myor (poll-identd-server)
> (poll-irc-servers)
> (handle-user-input))
> (update-display)))
>
> But that uses 100% CPU time, which is very unfriendly.
So you have to find out what is the correct way, on your platform, of
monitoring multiple network connections for input in a way that is CPU
friendly and responsive. If the language has no bindings to that
mechanism, then you have to carve them out yourself.
> But, to be honest, I'm fairly new to Common Lisp. Does anybody have any
> suggestions? I'd prefer to write code that's as portable as possible,
> which is why I don't like using extensions if possible.
You are already using CLISP extensions for networking, so it's already
not 100% portable.
You can keep your code quasi-portable by abstracting and isolating the
nonportable parts behind interfaces that can be retargetted to various
platforms without change.
Knowing how to design such interfaces requires experience, and a good
overview of what kinds of platforms are out there.
You have the read-time configuration mechanism in Lisp, which is
morally analogous to the #if and #ifdef directives in C and C++. By
this means, you can write code for multiple Lisps in one source file,
whenever this is necessary and convenient.
Adam M. wrote:
> My major gripe about Common Lisp is that the poor standard library
> precludes the writing of any real applications.
Hm.. I think Common Lisp has one of the greatest standard libraries out
there. Compared to other standard libraries like those of ANSI C++ or ANSI
C, ANSI Common Lisp offers quite alot more useful tools.
What you probably mean is that ANSI Common Lisp does not contain what other
languages (like Java, Python...) offer in a pseudo-standard way.
Take a look at CLiki (http://www.cliki.org) to see that there are indeed
alot of free libraries for alot of kinds of things.
> Once again, I tried to prove myself wrong, but I'm failing...
>
> I'm trying to write an extensible IRC client (as Emacs is an extensible
> text editor). First of all, there's no standard socket library, but
> that's not a problem in this case, as I use CLISP, which provides a
> socket interface. So far, so good...
There are multiple solutions to this problem:
1) Write conditionalized code
This works for many network using applications since the implementation
dependent code will tend to be not much more than 1-2 lines per
impementation.
2) Use a compatibility library like ACL-COMPAT (shameless plug)
which you can get at http://sourceforge.net/projects/portableaserve/
I'm not sure about the state of CLISP support in ACL-COMPAT.
For an IRC client the first approach seems to work quite well.
> When it comes time to write the main loop of the application (which is
> necessary because event-based programming doesn't seem to be a big thing
> in CL), the best I can come up with is kind of like this:
event-based programming in what sense?
There are not many languages with offer events as an integral part.
You can realize event-based programming in alot of different ways in Common
Lisp
> (defun myor (&rest list)
> "Like OR, but evaluates all of its arguments."
> (some #'identity list))
>
> (loop
> (if (myor (poll-identd-server)
> (poll-irc-servers)
> (handle-user-input))
> (update-display)))
Why do you poll the irc servers?
Use multithreading or a select based dispatcher to multiplex the server
connections.
> But that uses 100% CPU time, which is very unfriendly.
> There's a (sleep) in Common Lisp, but it takes a number of seconds to
> sleep, and even 1 second is far too great of a delay for an interactive
> application.
sleep is not the right tool here - but for the sake of completeness - sleep
takes floats as arguments so you can specify values lesser then 1 second.
> But, to be honest, I'm fairly new to Common Lisp. Does anybody have any
> suggestions? I'd prefer to write code that's as portable as possible,
> which is why I don't like using extensions if possible.
Then a compatibility library like ACL-COMPAT might be worth to check out.
> CLISP (or the other CL I was looking at, GCL) doesn't seem to provide
> extensions that would be useful for providing a means to create a
> friendly application, anyway.
I would suggest SBCL or CMUCL.
> Is it possible to do something in Common Lisp? Or will I have to move to
> (and bind myself to) CMU CL?
Whats wrong with CMUCL or SBCL? They are both supported by ACL-COMPAT so you
will not really be locked into using a single implementation.
As is mentioned by other posters I developed an extensible graphical IRC
client called "WeirdIRC" which is known to get running on at least Xanalys
LispWorks, MCL, Genera and CMUCL. In theory it should run on ACL, OpenMCL
and SBCL too.
WeirdIRC is available at http://sourceforge.net/projects/weird-irc/
There are alot of things how WeirdIRC could be enhanced:
- Support for multiple channels (multiple windows? tabs?)
- Support for DCC File transfer
- Channel and User Mode handling
- mIRC color support (I know it's ugly but it I only mean viewing it
properly)
If you are interested drop me a mail
ciao,
Jochen
Adam M. <·····@san.rr.com> writes:
> My major gripe about Common Lisp is that the poor standard library
> precludes the writing of any real applications.
It's important to note that the same thing has been said about C.
It's also true about C++, but since everyone has said it about C,
nobody bothers to mention it about C++. It's probably true about
every ANSI or ISO-standardized language.
These standards try to be as applicable as possible, by carving out a
clear area of portability. It's to be expected that any meaningful
application will need non-portable layers for certain things, but you
know precisely what you can depend upon and can factor the
non-portable bits away from the bulk of your application.
In my experience, the bulk of the initial work and the bulk of the
maintenance of "real" applications happens in the application logic,
not the system interfaces, so you're in portable territory for most of
the application. For the rest, it's a matter of doing it portably if
you can, and build an portable interface (within your application) to
system-specific routines if you need to.
--
Alan Shutko <···@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
And what are cat diapers called? PamPurrs?
> * In message <···················@adam.adammil.net>
> * On the subject of "writing a practical application in common lisp"
> * Sent on Fri, 02 May 2003 09:26:04 GMT
> * Honorable Adam M. <·····@san.rr.com> writes:
>
> I'm trying to write an extensible IRC client (as Emacs is an
> extensible text editor). First of all, there's no standard socket
> library, but that's not a problem in this case, as I use CLISP, which
> provides a socket interface. So far, so good...
CLOCC/PORT http://clocc.sf.net offers a portable socket layer in net.lisp
> (defun myor (&rest list)
> "Like OR, but evaluates all of its arguments."
> (some #'identity list))
>
> (loop
> (if (myor (poll-identd-server)
> (poll-irc-servers)
> (handle-user-input))
> (update-display)))
CLISP offers SOCKET-STATUS.
See <http://clisp.cons.org/impnotes/socket.html#so-status> or
<http://clisp.cons.org/impnotes.html#so-status> for documentation.
> There's a (sleep) in Common Lisp, but it takes a number of seconds to
> sleep, and even 1 second is far too great of a delay for an
> interactive application.
try (sleep 0.1)
--
Sam Steingold (http://www.podval.org/~sds) running RedHat9 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
MS: our tomorrow's software will run on your tomorrow's HW at today's speed.
First of all, I want to thank everybody for the replies and, after
sleeping, I realize that the ranting was quite reprehensible.
In the future, I won't post to usenet until I've distanced myself from
the problem ;-)
There was a lot of good information in the replies, some
thought-provoking, some humbling.
It's absolutely true that the some problem I mentioned applies to
languages like C and C++, yet a huge number of genuinely
useful applications are written in them.
I really like the Lisp as a language (the standard library aside). I
just think the fragmentation in the community, the dialects, and the
libraries is what is preventing Lisp from becoming widely useful.
While C/C++ does not contain a networking library either, there is
definitely a standardized library available for almost any C/C++
development system -- the berkely socket API. Similarly, there's OpenGL
for graphics, or with slightly lesser availability, libSDL, which
provides all manner of multimedia interfacing.
With CL, I need to have multiple runtimes installed because of the lack
of standardized APIs. Some need CLISP, others need CMU CL, etc.
Well, fire away with the "Quit whining and do something about the
problem." replies :-)
To that end, I'm going to implement as many of CLISP's extensions in
CMUCL as I can. At least for the applications I run, that should help
bridge the gap between the two implementations.
Thanks again to all.
Cheers,
Adam
Adam M. wrote:
> While C/C++ does not contain a networking library either, there is
> definitely a standardized library available for almost any C/C++
> development system -- the berkely socket API. Similarly, there's OpenGL
> for graphics...
Omigod! I am doing OpenGL from Common Lisp now. Thanks for letting know
I cannot be, I better stop!
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
On Fri, 02 May 2003 21:52:19 GMT, "Adam M." <····@adam.adammil.net> wrote:
> I really like the Lisp as a language (the standard library aside). I
> just think the fragmentation in the community, the dialects, and the
> libraries is what is preventing Lisp from becoming widely useful.
Could you elaborate on what you exactly mean by community fragmentation?
Also, what is the problem with Lisp dialects? Are they too many? If so, can
you name the ones you specifically refer to?
Paolo
--
Paolo Amoroso <·······@mclink.it>