Re: RFC 326 (v1) Symbols, symbols everywhere

2000-09-27 Thread Dan Sugalski
At 05:37 AM 9/27/00 +, Perl6 RFC Librarian wrote: Perl should adopt scheme-like symbols, both at the language level and at the internals level. The explanation of this isn't that clear for me. (I have no scheme experience at all) It sounds like a sort of dynamically-created version of C's

Re: RFC35 (base format for perl variables) - some comments

2000-09-27 Thread Dan Sugalski
At 02:25 PM 9/25/00 +0100, David Mitchell wrote: Here are a few comments on RFC35 (base format for perl variables). [ NB - I've only just joined this list, and although I've rummaged through the archives, I may have missed bits which make my comments obsolete/absurd etc... :-) ] Revisiting the

Re: RFC 310 (v1) Ordered bytecode

2000-09-27 Thread Dan Sugalski
At 11:53 PM 9/26/00 -0400, Uri Guttman wrote: now what bothers me is that all those calls are in section 3 and are no section 2 system calls. maybe it is faked with threads but i haven't found any support for that notion. if so, i wonder if we can actually use it and not collide with perl

Re: RFC 310 (v1) Ordered bytecode

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote: I don't much care how its faked (if it is) as long as it works. Well, given that line disciplines means we have to write our own IO subsystem, can't we fake it ourselves? -- "They laughed at Columbus, they laughed at Fulton,

Re: RFC 310 (v1) Ordered bytecode

2000-09-27 Thread Tom Hughes
In message [EMAIL PROTECTED] Uri Guttman [EMAIL PROTECTED] wrote: now what bothers me is that all those calls are in section 3 and are no section 2 system calls. maybe it is faked with threads but i haven't found any support for that notion. if so, i wonder if we can actually use it

Re: RFC 310 (v1) Ordered bytecode

2000-09-27 Thread Tom Hughes
In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: I don't much care how its faked (if it is) as long as it works. Might not be as efficient as full kernel support for async I/O, but it'll do. At least there's some overlap. (You can get better device request ordering

async i/o (was Re: RFC 310 (v1) Ordered bytecode)

2000-09-27 Thread Uri Guttman
"TH" == Tom Hughes [EMAIL PROTECTED] writes: TH I can't see any reference to threads in the Solaris manual pages TH either. Certainly Unixware does: TH I thought that using threads was the standard SVR4 implementation TH but maybe Solaris has moved away from that. well, my question

Re: async i/o (was Re: RFC 310 (v1) Ordered bytecode)

2000-09-27 Thread Nicholas Clark
On Wed, Sep 27, 2000 at 04:24:05AM -0400, Uri Guttman wrote: well, my question then is how does solaris do it? it can't be done with user level libs alone. what system calls does it use? undocumented ones perhaps with the libs as the public api? i finally found how solaris does its AIO under

Re: RFC 310 (v1) Ordered bytecode

2000-09-27 Thread Dan Sugalski
At 08:31 AM 9/27/00 +0100, Simon Cozens wrote: On Wed, Sep 27, 2000 at 02:40:27AM -0400, Dan Sugalski wrote: I don't much care how its faked (if it is) as long as it works. Well, given that line disciplines means we have to write our own IO subsystem, can't we fake it ourselves? If we want,

Re: RFC 326 (v1) Symbols, symbols everywhere

2000-09-27 Thread Dave Storrs
On Wed, 27 Sep 2000, Dan Sugalski wrote: At 05:37 AM 9/27/00 +, Perl6 RFC Librarian wrote: Perl should adopt scheme-like symbols, both at the language level and at the internals level. The explanation of this isn't that clear for me. (I have no scheme experience at all) It

Re: RFC 326 (v1) Symbols, symbols everywhere

2000-09-27 Thread Simon Cozens
On Wed, Sep 27, 2000 at 03:07:19PM -0400, Ken Fox wrote: Dan was right to think of this as a C enum equivalent. The only real differences being that you don't have a chance to define the integer mapping and that the printable identity of the symbol is remembered by the run-time. I don't yet

Re: RFC 301 (v1) Cache byte-compiled programs and modules

2000-09-27 Thread Chaim Frenkel
"RA" == Russ Allbery [EMAIL PROTECTED] writes: RA Michael Maraist [EMAIL PROTECTED] writes: I suggested this a while ago, and the response was that automatically writing files is a security risk. You should extend your RFC to describe a caching directory or configuration. RA This will be

Re: RFC 301 (v1) Cache byte-compiled programs and modules

2000-09-27 Thread Russ Allbery
Chaim Frenkel [EMAIL PROTECTED] writes: "RA" == Russ Allbery [EMAIL PROTECTED] writes: RA This will be completely impossible to implement in some installation RA environments, such as AFS or read-only remote NFS mounts. I really RA don't like software that tries to play dynamic compilation