Hello colleagues;
I'm sponsoring an undergraduate research project tnis summer
that adds a learning component to a rule-based expert system
(to play Hold 'Em Poker). The learning is done via a Genetic
ALgorithm. I would like to have each "player" (rule-based
expert system) reside on a separate machine, and to spawn
a process to run the genetic algorithm in the background.
My question is twofold, then:
1. Is there a language construct in Common Lisp that supports
spawning a process---like a "fork" in Unix?
2. Is there a language construct in Common Lisp that supports
InterProcess Communication---like a "pipe" in Unix?
If these language constructs do exist, where can I get more
information?
Thanks,
--
Dr. Ronald E. Bartlett
Mathematical Sciences
Denison University
Granville, Ohio 43023 USA
In article <·············@sunshine.mathsci.denison.edu> "Dr. Ronald
E. Bartlett" <········@sunshine.mathsci.denison.edu> writes:
>
> Hello colleagues;
>
> I'm sponsoring an undergraduate research project tnis summer
> that adds a learning component to a rule-based expert system
> (to play Hold 'Em Poker). The learning is done via a Genetic
> ALgorithm. I would like to have each "player" (rule-based
> expert system) reside on a separate machine, and to spawn
> a process to run the genetic algorithm in the background.
>
> My question is twofold, then:
>
> 1. Is there a language construct in Common Lisp that supports
> spawning a process---like a "fork" in Unix?
>
> 2. Is there a language construct in Common Lisp that supports
> InterProcess Communication---like a "pipe" in Unix?
>
> If these language constructs do exist, where can I get more
> information?
>
> Thanks,
>
Common Lisp intentionally does not define a process model. This is left as
an add on for Common Lisp implementations. Franz's Allegro Common Lisp for
example has a light weight process model that will do what you need. I can
recommend it. This model does not need pipes, processes can communicate
through common store.
--
William P. Vrotney - ·······@netcom.com
In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
From: ·······@netcom.com (William Paul Vrotney)
Newsgroups: comp.lang.lisp
Date: Sun, 25 May 1997 23:50:41 GMT
Organization: Netcom On-Line Services
References: <·············@sunshine.mathsci.denison.edu>
Lines: 36
Sender: ·······@netcom2.netcom.com
In article <·············@sunshine.mathsci.denison.edu> "Dr. Ronald
E. Bartlett" <········@sunshine.mathsci.denison.edu> writes:
>
> Hello colleagues;
>
>
> Thanks,
>
Common Lisp intentionally does not define a process model. This is left as
an add on for Common Lisp implementations.
....
The above is obviously listed as "one of the big mistakes" of CL. :{
Sadly yours
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
> Common Lisp intentionally does not define a process model. This is left as
> an add on for Common Lisp implementations.
>
>The above is obviously listed as "one of the big mistakes" of CL. :{
Why is this a mistake? There's a de facto standard, and lots of room
for improvement.
The de facto standard is the Lisp Machine thread API, to use current
terminology. This is not perfect, but the majority of commercial CL
implementations support it. Unfortunately each implementation of this
"de facto standard" is just a little bit different, but not so different
that macrology can't paper over the differences.
However, the Lisp Machine thread API has some drawbacks. Its primary
drawback is that it is not event-driven; instead it determines which
processes are ready to run by polling each process's wait function.
This means time is wasted every tick running each waiting process's wait
functions, and in virtual memory environments this can also cause
needless page faults.
Symbolics had introduced a new event-driven scheduler in the late '80s,
as I recall, but I doubt that it ever got enough use to become a
standard.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled)
This space for rent... NOT.
······@best.com (Chuck Fry) writes:
>However, the Lisp Machine thread API has some drawbacks. Its primary
>drawback is that it is not event-driven; instead it determines which
>processes are ready to run by polling each process's wait function.
>This means time is wasted every tick running each waiting process's wait
>functions, and in virtual memory environments this can also cause
>needless page faults.
The Genera Threads API is very rich and some of its functionality is
hard to implement otherwise. If you need some advanced features, I'm
not sure the overhead is not worth it, especially if you take modern
hardware into account.
I have an overview of Lisp threads APIs at
http://www.cons.org/cracauer/lisp-threads.html
Happy Lisping
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <············@shell5.ba.best.com> ······@best.com (Chuck Fry) writes:
From: ······@best.com (Chuck Fry)
Newsgroups: comp.lang.lisp
Date: 3 Jun 1997 09:52:18 -0700
Organization: Federation Of Road Demons
Lines: 33
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
> Common Lisp intentionally does not define a process model. This is left as
> an add on for Common Lisp implementations.
>
>The above is obviously listed as "one of the big mistakes" of CL. :{
Why is this a mistake? There's a de facto standard, and lots of room
for improvement.
The de facto standard is the Lisp Machine thread API, to use current
terminology. This is not perfect, but the majority of commercial CL
implementations support it. Unfortunately each implementation of this
"de facto standard" is just a little bit different, but not so different
that macrology can't paper over the differences.
Kent Pitman wrote a draft for multiprocessing. With the power that is
ascribed to historians (even the amateur ones), i.e. that of
hindsight, this should have been incorporated into the standard.
As far as the SCL de facto standard goes, It seems to me that the
differences between Allegro and Harlequin (and Harlequin Liquid, nee`
Lucid) are big enough to make life very hard.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
From: David Gadbois
Subject: Re: Threads in CL (was: networking in lisp)
Date:
Message-ID: <5n4r4v$eej$1@news3.texas.net>
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>As far as the SCL de facto standard goes, It seems to me that the
>differences between Allegro and Harlequin (and Harlequin Liquid, nee`
>Lucid) are big enough to make life very hard.
Eh? For the non-scheduling related stuff, it is mostly a matter of
name changes. See http://www.cyc.com/users/gadbois/processes.lisp for
thread wrappers for Genera, Lucid, LispWorks, Allegro, and Macintosh
CL.
--David Gadbois
In article <············@news3.texas.net> ·······@cyc.com (David Gadbois) writes:
From: ·······@cyc.com (David Gadbois)
Newsgroups: comp.lang.lisp
Date: 4 Jun 1997 22:44:47 GMT
Organization: Cycorp, Inc. (Austin, TX)
Lines: 11
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>As far as the SCL de facto standard goes, It seems to me that the
>differences between Allegro and Harlequin (and Harlequin Liquid, nee`
>Lucid) are big enough to make life very hard.
Eh? For the non-scheduling related stuff, it is mostly a matter of
name changes. See http://www.cyc.com/users/gadbois/processes.lisp for
thread wrappers for Genera, Lucid, LispWorks, Allegro, and Macintosh
CL.
Thanks for the pointer. I was unaware of it.
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <···············@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
>In article <············@shell5.ba.best.com> ······@best.com (Chuck Fry) writes:
> In article <···············@infiniti.PATH.Berkeley.EDU>,
> Marco Antoniotti <·······@infiniti.PATH.Berkeley.EDU> wrote:
> >In article <·················@netcom.com> ·······@netcom.com (William Paul Vrotney) writes:
> > Common Lisp intentionally does not define a process model. This is left as
> > an add on for Common Lisp implementations.
> >
> >The above is obviously listed as "one of the big mistakes" of CL. :{
>
> Why is this a mistake? There's a de facto standard, and lots of room
> for improvement.
[...]
>Kent Pitman wrote a draft for multiprocessing. With the power that is
>ascribed to historians (even the amateur ones), i.e. that of
>hindsight, this should have been incorporated into the standard.
I was unaware of this draft (no surprise). Is (was) there a prototype
implementation of this proposed standard?
My point, which I should have stated explicitly, was that even the de
facto standard was known to be less than ideal at the time, and IMHO it
was premature to standardize when more exploratory work was needed.
In that sense I think X3J13 made the right decision.
>As far as the SCL de facto standard goes, It seems to me that the
>differences between Allegro and Harlequin (and Harlequin Liquid, nee`
>Lucid) are big enough to make life very hard.
It hasn't been an issue in my work (Allegro and Lispworks), but then I
don't ask much of multiprocessing. A more sophisticated user probably
has good reason to complain.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please), ········@home.com (MIME enabled)
This space for rent... NOT.
·······@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) writes:
>Kent Pitman wrote a draft for multiprocessing.
No he didn't (he told me).
The ALU website lists two papers as proposals, one of Lucid and one of
the ILU team at PARC (which is a small API, suitable as a common
subset). Links are on my homepage.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <····················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
From: ········@wavehh.hanse.de (Martin Cracauer)
Newsgroups: comp.lang.lisp
Date: Thu, 5 Jun 97 11:23:24 GMT
Organization: '(a (cons tructive organization))
Reply-To: ········@wavehh.hanse.de
Lines: 16
·······@infiniti.PATH.Berkeley.EDU (Marco Antoniotti) writes:
>Kent Pitman wrote a draft for multiprocessing.
No he didn't (he told me).
I was sure that he did. I guess I was mistaken.
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472