Subject: [clisp-list] Just point me to the m, and I'll rtfm :)

From: Jason Dagit <[email-masked]>
Date: Thu Feb 7 02:26:02 2002

I had two questions about clisp.  I've been using it for a while
now and I really like it.  But, I still don't see how I can do tcp/ip and
multithreading.  Mostly, I don't know where to begin.  What packages do I
need (using Debian here, so apt is my friend)?  Where can I find
documentation about using them?

	The second question is odd indeed.  I know that clisp is more
efficient (seems faster to me at least) than cmucl (not trying to start a
flame war tho), but why does clisp blow the stack before cmucl?  I'm just
learing about activiation records vs. heap, and so I was just curious why
clisp doesn't use the heap before the stack blows? (maybe it's just really
hard to check for...)

	Oh, I just had another quick question come to mind.  Will the
packages that work for cmucl work for clisp?  If that's a totally newbie
question just let me know.  And again, if there is already a place that
answers my questions just point me to it, and I'll go read it.

Thanks for your time,
Jason

---

From: Eric Marsden <[email-masked]>
Date: Thu Feb 7 02:40:05 2002

>>>>> "jd" == Jason Dagit <[email-masked]> writes:

  jd> now and I really like it. But, I still don't see how I can do
  jd> tcp/ip and multithreading. Mostly, I don't know where to begin.
  jd> What packages do I need (using Debian here, so apt is my
  jd> friend)? Where can I find documentation about using them?

Unfortunately the Debian package for CLISP is rather old; you may be
better off compiling it yourself. Read the implementation notes
(available at <URL:http://clisp.sf.net/>) for information on using
sockets from CLISP.
  
  jd> The second question is odd indeed. I know that clisp is more
  jd> efficient (seems faster to me at least) than cmucl (not trying
  jd> to start a flame war tho)

CLISP is faster on certain types of code (especially involving
bignums), but quite a lot slower on others. Figures at 

   <URL:http://ww.telent.net/cliki/Performance%20Benchmarks>

  jd> Oh, I just had another quick question come to mind. Will the
  jd> packages that work for cmucl work for clisp?

if they use standard Common Lisp, they should work. If they depend on
extensions to the standard (eg networking support, operating system
interface, interface with foreign code), they will require
implementation-specific code. You'll find that many packages work with
both implementations.
      
-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>

---

From: Arseny Slobodjuck <[email-masked]>
Date: Thu Feb 7 04:30:03 2002

Hello Jason,

Thursday, February 07, 2002, 8:24:56 PM, you wrote:

Jason>         I had two questions about clisp.  I've been using it for a while
Jason> now and I really like it.  But, I still don't see how I can do tcp/ip and
Jason> multithreading.  Mostly, I don't know where to begin.  What packages do I
Jason> need (using Debian here, so apt is my friend)?  Where can I find
Jason> documentation about using them?
To learn how to use clisp specific extensions (tcp/ip for example)
read impnotes.html.

I believe that clisp have not multithreading (thank you Lord).

-- 
Best regards,
 Arseny                            mailto:[email-masked]

---

From: Paolo Amoroso <[email-masked]>
Date: Thu Feb 7 08:34:01 2002

> multithreading.  Mostly, I don't know where to begin.  What packages do I

CLISP does not currently support multithreading. As for TCP/IP, Eric has
already mentioned the implementation notes.

> packages that work for cmucl work for clisp?  If that's a totally newbie

CLOCC (Common Lisp Open Code Collection) includes code designed to run on
CLISP, CMU CL and other implementations:

  http://clocc.sourceforge.net

Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

---

From: "Thomas F. Burdick" <[email-masked]>
Date: Thu Feb 7 10:22:09 2002

Jason Dagit writes:
 > multithreading.

Multithreading is for people who don't know how to write state machines ;-)
Or, you know, cmucl users, either one...

 > flame war tho), but why does clisp blow the stack before cmucl?

I'm very surprised that you're finding CLISP more efficient that
CMUCL.  Out of curiosity, are you compiling your code on CMUCL?  CLISP
is faster to start up, but except for bignum math (where it kills all
the competitors, in every language), it's generally significantly
slower than every native-compiling implementation.  It has a good
bytecode interpreter, so it's usually fast enough for most things, but
it's still a bytecode interpreter.

As for blowing the stack, two things: CLISP uses the C calling stack
allocated to it by the kernel -- extend that, and you'll get more
stack space -- while CMUCL uses its own calling stack.  More
importantly, though, why are you blowing the stack?  Are you writing
recursive code where iterative code would do just as well?  If so,
well, you're asking for it, literally.  If your application just has a
really deep stack, use a larger one; if it's going to need potentially
unbounded stack space, change your code.

 > I'm just learing about activiation records vs. heap, and so I was
 > just curious why clisp doesn't use the heap before the stack blows?
 > (maybe it's just really hard to check for...)

I'm guessing because cost/benefit is near infinity.  CLISP uses the C
stack.  Having it heuristically switch to heap-allocating stack frames
would involve horrible pain, and to what end?  If you can't allocate a
sufficiently large normal stack, odds are the app is going to use up
all the heap in the end, if you move its stack there.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'