scsh-hackers
[Top] [All Lists]

[Scsh-hackers] Re: Progress

To: scsh-hackers <scsh-hackers@lists.sourceforge.net>
Subject: [Scsh-hackers] Re: Progress
From: Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de>
Date: 11 Mar 2001 18:13:43 +0100
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
>>>>> "Olin" == shivers  <shivers@cc.gatech.edu> writes:

Olin> [Interesting -- *your* mail to scsh-hackers goes through. If *my* mail
Olin>  is going through, you'll get two copies of this msg.]

I got only one copy. But none of the mails I sent got ever lost..

Olin> I'd like to try and convince you that multiline, nested comments of the 
Common
Olin> Lisp #|...|# are just a bad idea. But I say: don't touch the source, even 
to
Olin> remove this feature, until we've had that discussion. Then we either kill 
the
Olin> source or add the manual doc.

Okay boss ;-)


[snip]
Olin> There will inevitably be an experimental phase to 0.6 development; it will
Olin> be handy, I think, to be able to tell people they can use a reasonable
Olin> 0.5 system if 0.6 flux bites them for a little while. So I want to get
Olin> 0.5 into a reasonable state, which it is not.

If you want so release 0.5.4 after 0.6(-beta?) that's fine with me,
but I don't want to delay 0.6 just because you're stuck with
0.5.4. And speaking of your limited time, I think 0.6 is more
important than 0.5.4.

Olin>    Put 0.5.3 out NOW. After that we fix the API for 0.6. I'll implement
Olin>    it and you can proceed with the above list in the 0.6 tree. 

Olin> Where are we on the 0.6 API? Have you written up a (plain text, non-LaTeX)
Olin> spec for it? We need to start with that, before we get to messing with the
Olin> code.

I was talking about my proposal. Syslog is not the only thing 
open. Or for what else do you want to see a spec? The thread system
itself is adopted from Scheme 48, though I'll have to write some
documentation.


Olin> On a related note, we *do* need to continue to provide the SELECT procs --
Olin> people will have code written that uses SELECT from 0.5, and we want that 
code
Olin> to run in 0.6. We can deprecate the whole programming model, but some 
folks
Olin> prefer event loops to threads. But remember the motivating vision:
Olin> you should be able to run *your* code given a thread with a repl, and
Olin> I shold be able to run *my* code given a thread with a repl in the same
Olin> process, and we should not interfere with each other -- select's and 
thread
Olin> forking and current working directories and everything.

In general you're right of course, but I don't know how hard it is to
fake *select*. I'll give it a try tomorrow.


-- 
Martin


<Prev in Thread] Current Thread [Next in Thread>