I have seen several comments to the effect that a SRFI-style process would be
beneficial for Common Lisp as well.
Unless the ball is already rolling behind the curtains, what can I as an
individual user and a relative newcomer do to facilitate the birth of such a
process?
Nag here? Write a process proposal? Email prominent lispers and try to get
something happening behind the curtains? Shut up and hope for the best?
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> I have seen several comments to the effect that a SRFI-style process would be
> beneficial for Common Lisp as well.
>
> Unless the ball is already rolling behind the curtains, what can I as an
> individual user and a relative newcomer do to facilitate the birth of such a
> process?
I think a "librarian" role is one thing that's currently missing.
Identify existing proposals which you would like to see as part of
your Lisp implementation, or which solve problems that "everyone
knows" are needed. Keep a list of pointers to same, on a web page, or
the ALU cliki, or posted weekly to comp.lang.lisp. Set up some
mechanism that people can use to comment on the proposals (e.g. create
a mailing list, or save google groups urls from comp.lang.lisp
discussion)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote:
> Identify existing proposals which you would like to see as part of
> your Lisp implementation, or which solve problems that "everyone
> knows" are needed. Keep a list of pointers to same, on a web page, or
Well, call me an easy bait. I did:
http://alu.cliki.net/Specifications-Wanted
It is somewhat redundant considering the
http://alu.cliki.net/Standard
pages, but I'll weather the flames.
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Well, call me an easy bait. I did:
>
> http://alu.cliki.net/Specifications-Wanted
Well, OK, but. The only specifications you've linked to there are
simple streams and Gray streams. The other links are to code, and no,
it's not "better than nothing"
We don't need a shopping list full of "nice to have"s. We need (for
whatever value of "need") specifications or proposals which are
concrete enough that people can read them, review them, revise them
and implement them. Have a look at
<http://www.cliki.net/Common%20Lisp%20Utilities> for some ideas. I'm
not suggesting that any or all of them should be standardized on, but
this is the level of detail that I think is needed.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote:
> We don't need a shopping list full of "nice to have"s. We need (for
> whatever value of "need") specifications or proposals which are
> concrete enough that people can read them, review them, revise them
> and implement them.
Quite true. The page is now in a somewhat better shape, I hope. The
fundamental issue still remains though: there are far more implementations
then specifications out there, it seems.
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Well, call me an easy bait. I did:
>
> http://alu.cliki.net/Specifications-Wanted
To demonstrate my point a little more concretely, I thought I'd post a
quick review of the clocc multiprocessing stuff referenced from that
page. Note that I'm assessing this as a candidate for
standardisation, which is afaict not what its authors intended it for
- as a portability layer for a bunch of Lisps that support a similar
threading model, it seems to do a reasonable job. If I sound
over-critical, it's not of clocc/proc itself, it's of the idea that it
should be used as a specification for Lisps built on a different
threading model.
make-process : what does it do with special variable bindings? Does
the new thread get its own? Does it start with a 'standard' set, or
do they inherit from the parent thread?
process-wait : this is going to suck somewhat on any Lisp where the OS
is doing the scheduling, because the only way of pausing until some
Lisp predicate returns true is going to be by having the process wake
up periodically to test the predicate. OK, if the user actually needs
to do this then that's what must happen, but more likely is that
people will see this is the interface and write their own process
queuing code on top of it, ignoring whatever far more efficient queue
implementation that Lisp provides
process-wait-with-timeout ditto
with-timeout : a reasonable interface (although I wonder if it
wouldn't be more flexible if it merely signalled a condition on
timeout, that some appropriate handler could deal with). The
implementation is a bit weird, though: not only does it start a new
thread expressly to interrupt the current one, but requires
interrupt-process. IIRC this is a bad thing to require on OpenMCL
0.14, and I can say with absolute certainty it's a bad thing to
require in SBCL, because it's not implemented at all there. But we
have a perfectly good with-timeout macro of our own that doesn't
involve starting a new thread.
without-scheduling : paging Tim Bradshaw :-) This is just a bad idea
to export; any possible implementation on a OS-scheduled system is
going to be messy, probably race-prone, and slow. Most people who
think they need without-scheduling actually just need some kind of
mutex, or atomic operation, and unless the implementation is either
(a) woefully impoverished, or (b) using a scheduler written in Lisp,
it will provide better, faster, versions of these more specific
constructs than you could write yourself by disabling multitasking for
the duration. The same comments apply, really, as to process-wait,
but even more so.
process-yield : ok, I can think of nothing bad to say about this one.
I do wonder what happens if you call it inside a without-scheduling
section, though ...
kill-process, restart-process : does the victim get a chance to run
cleanup forms first?
interrupt-process : hoping it's not holding any locks you ever wanted
to use again ...
process-active-p : described as "T if PROCESS is doing something.".
Doing what? Is "sitting at the repl" doing something? What about
"waiting for a network connection"? "waiting for a file block to be
fetched from disk"? ""waiting for a lock"? "evaluating a predicate to
decide whether it's runnable"?
There's no documentation desdcribing what a process-state is, nor a
process-whostate. This may be obvious if you're a Lispm user.
Locking primitives don't describe whether the locks are recursive: if
we attempt to seize a lock, and the current thread already owns it,
what happens?
I hope that gives you some idea
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> process-yield : ok, I can think of nothing bad to say about this one.
> I do wonder what happens if you call it inside a without-scheduling
> section, though ...
>
For some systems that lets you yield to a specific process, an optional
argument saying which thread you prefer to yield to makes it possible to
avoid a lot of wakeups when you have just figured out that process X owns
your lock, and you can't progress until it releases it.
astor
--
"almost all programming can be viewed as an exercise in caching"
-Terje Mathisen
In article <··············@midnight.cs.hut.fi>,
Nikodemus Siivola <········@kekkonen.cs.hut.fi> wrote:
> Daniel Barlow <···@telent.net> wrote:
>
> > Identify existing proposals which you would like to see as part of
> > your Lisp implementation, or which solve problems that "everyone
> > knows" are needed. Keep a list of pointers to same, on a web page, or
>
> Well, call me an easy bait. I did:
>
> http://alu.cliki.net/Specifications-Wanted
>
> It is somewhat redundant considering the
>
> http://alu.cliki.net/Standard
Here is an important note that might help to explain why such pages
don't seem to work: Communities don't just happen! Someone has to invest
a lot of time and energy in order bring a community into existence and
make it roll.
There are a lot of community sites on the web that seem to just work
magically - they have lots of volunteers, lots of people are
contributing, you gain a lot by participating, and so forth. It seems as
if these things have fallen from the sky. http://c2.com/cgi/wiki? is one of the most impressive examples of such a communtiy.
However, it's really hard to make these communities work. Until a
critical mass of participants is reached, someone has to regularly
contribute substantial material, and this requires a lot of hard work. A
community just doesn't come into existence by setting up a website and
asking someone to contribute.
Note that I don't mean this as a negative criticism of the efforts of
the people that have set up http://alu.cliki.net - something like this needs to start to roll. But it's just a bad idea
to set up a community website and leave it blank in the first version.
Think about your own reactions when you see website that says that it is
going to be updated soon and has actually been updated last in 1998. You
create a similar reaction by setting up an empty website, or by setting
up a website without committing yourself to contributing to it by
yourself during a considerable time span.
To rephrase an insightful quote by Jamie Zawinski [1]: You can divide
our world into two kinds of people: those who want to contribute to a
community to make it successful, and those who want to contribute to a
successful community.
My expression is that there are a lot more people of the second kind. [2]
Pascal
[1] The original quote is: "you can divide our industry into two kinds
of people: those who want to go work for a company to make it
successful, and those who want to go work for a successful company." -
see http://www.jwz.org/gruntle/nomo.html
[2] When you understand that this is totally ok, you have reached
enlightenment. ;)
Pascal Costanza <········@web.de> wrote:
> Note that I don't mean this as a negative criticism of the efforts of
> the people that have set up http://alu.cliki.net - something like this
What seems wierd to me is the way the alu.cliki is kind of hidden: I can't
see any links there on the main ALU site. This may be intentional, since
the alu.cliki front page states that "This is an experimental CLiki
instance that we're using to help co-ordinate work on the new ALU web
site."
Doen't exatly invite you to contribute, does it? Ah, subversion of
intent...
> To rephrase an insightful quote by Jamie Zawinski [1]: You can divide
> our world into two kinds of people: those who want to contribute to a
> community to make it successful, and those who want to contribute to a
> successful community.
,)= I can't express in words how funny I find this! Kind of like, there
are two kinds of people: those who want to eat good food, and those who
want to see good food eaten.
Unfortunately, I believe you intent is closer to reality then the way you
phrased ir strikes me.
Cheers,
-- Nikodemus
> > To rephrase an insightful quote by Jamie Zawinski [1]: You can
> > divide our world into two kinds of people: those who want to
> > contribute to a community to make it successful, and those who
> > want to contribute to a successful community.
>
> ,)= I can't express in words how funny I find this! Kind of like,
> there are two kinds of people: those who want to eat good food, and
> those who want to see good food eaten.
You're not thinking like a programmer!
The first one can be expressed (partially) as
(until (successful-p community)
(contribute-to community))
The second one can be expressed as
(when (successful-p community)
(contribute-to community))
Of course, the second fragment may never execute
(contribute-to community)
at all.
--
Fred Gilham ······@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> Of course, the second fragment may never execute
> (contribute-to community)
> at all.
Indeed. And where is the fun in that?
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Pascal Costanza <········@web.de> wrote:
>
> > Note that I don't mean this as a negative criticism of the efforts of
> > the people that have set up http://alu.cliki.net - something like this
>
> What seems wierd to me is the way the alu.cliki is kind of hidden: I can't
> see any links there on the main ALU site. This may be intentional, since
> the alu.cliki front page states that "This is an experimental CLiki
> instance that we're using to help co-ordinate work on the new ALU web
> site."
>
> Doen't exatly invite you to contribute, does it? Ah, subversion of
> intent...
>
> > To rephrase an insightful quote by Jamie Zawinski [1]: You can divide
> > our world into two kinds of people: those who want to contribute to a
> > community to make it successful, and those who want to contribute to a
> > successful community.
>
> ,)= I can't express in words how funny I find this! Kind of like, there
> are two kinds of people: those who want to eat good food, and those who
> want to see good food eaten.
[hmm .. more like "cook and eat good food" for the first one]
> Unfortunately, I believe you intent is closer to reality then the way you
> phrased ir strikes me.
I don't think it's unfortunate -- for example, would you rather create
a technologically advanced society, or live in one? Civilization
needs both types, but a *lot* more of the second type, or we'd all
still be fighting over which shape of weel to use.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 9 May 2003 01:45:43 GMT, Nikodemus Siivola <········@kekkonen.cs.hut.fi>
wrote:
> What seems wierd to me is the way the alu.cliki is kind of hidden: I can't
> see any links there on the main ALU site. This may be intentional, since
> the alu.cliki front page states that "This is an experimental CLiki
> instance that we're using to help co-ordinate work on the new ALU web
> site."
Someone is working on that.
> Doen't exatly invite you to contribute, does it? Ah, subversion of
Hmmm... isn't unrestricted write access to alu.cliki.net enough?
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> wrote:
>> Doen't exatly invite you to contribute, does it? Ah, subversion of
> Hmmm... isn't unrestricted write access to alu.cliki.net enough?
I didn't mean to complain: it was more of an observation as to why and how
contributions happen / don't happen.
Polite people try not to mess with other peoples sandcastles unless
they've been asked to play, and to me the front page of the ALU CLiki
leaves the intent rather unclear. But now that the intent has been
clarified... ,)=
Cheers,
-- Nikodemus