Re: Vtable methods
At 12:42 PM 1/4/01 +, Simon Cozens wrote: It's time to design the RTL and API. Can I have suggestions for vtable methods, please? I can go you one better--I've a partial vtable PDD done. I'll patch it up a bit when I get into the office later and send it on. One thing we need to discuss before going too far, though, is whether perl 6 should be primarily stack-based or register based internally. (Well, named temporaries rather than registers since we're rather high-level, but still...) Personally I'd rather go with a register-based system than the current stack based method. I think we can make things a bit faster with good optimization this way. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Anyone want to take a shot at the PerlIO PDD?
On Wed, Jan 03, 2001 at 11:03:08PM +, Nick Ing-Simmons wrote: I am willing to cast bleadperl5's PerlIO into the form of a _draft_ PDD for perl6 - i.e. "this is what it does now", not "this is what it should do". I have a feeling the two are going to be very similar. -- "A word to the wise: a credentials dicksize war is usually a bad idea on the net." (David Parsons in c.o.l.development.system, about coding in C.)
Re: Speaking of signals...
On Wed, 3 Jan 2001, Dan Sugalski wrote: I think one of the things we might want to do is figure out what people use signals for and see if we can abstract out some of that functionality without actually exposing signals. (From an internals standpoint, at least) Well, one thing people use signals for is IPC with non-Perl processes. I think that if you're want to continue to support that then we need an interface to real, broken though they may be, POSIX signals. Maybe the code gets pushed out of the core, but it still needs to be somewhere. -sam
Re: Speaking of signals...
At 10:15 AM 1/4/01 -0500, Sam Tregar wrote:
On Wed, 3 Jan 2001, Dan Sugalski wrote:
I think one of the things we might want to do is figure out what people use
signals for and see if we can abstract out some of that functionality
without actually exposing signals. (From an internals standpoint, at least)
Well, one thing people use signals for is IPC with non-Perl processes. I
think that if you're want to continue to support that then we need an
interface to real, broken though they may be, POSIX signals. Maybe the
code gets pushed out of the core, but it still needs to be somewhere.
Right. I'm not talking about getting rid of signals--I want to make them
work properly in perl 6, %SIG and all. What I'm thinking about is those
things that signals are used for but aren't particularly optimal.
Using alarm and $SIG{ALRM} to abort blocked or long-running things is one
of the biggies (personally I think I'd prefer some sort of eval block with
a timeout attached), since it doesn't work threaded, doesn't work well
outside of Unix/VMS (read: WinXX), and won't let you have multiple one-shot
or periodic timers. Using a signal, in this case, is something of a hack
(though not ours) that can be done better.
I/O events are another area where we'll want to hide signals generally,
since the PerlIO layer will want to be taking care of that itself.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Anyone want to take a shot at the PerlIO PDD?
At 12:50 PM 1/4/01 +, Simon Cozens wrote: On Wed, Jan 03, 2001 at 11:03:08PM +, Nick Ing-Simmons wrote: I am willing to cast bleadperl5's PerlIO into the form of a _draft_ PDD for perl6 - i.e. "this is what it does now", not "this is what it should do". I have a feeling the two are going to be very similar. I'm not entirely sure of that, but I'm not all that familiar with the current state of affairs. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of signals...
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Right. I'm not talking about getting rid of signals--I want to make them
DS work properly in perl 6, %SIG and all. What I'm thinking about is those
DS things that signals are used for but aren't particularly optimal.
DS Using alarm and $SIG{ALRM} to abort blocked or long-running things
DS is one of the biggies (personally I think I'd prefer some sort of
DS eval block with a timeout attached), since it doesn't work
DS threaded, doesn't work well outside of Unix/VMS (read: WinXX), and
DS won't let you have multiple one-shot or periodic timers. Using a
DS signal, in this case, is something of a hack (though not ours)
DS that can be done better.
that is still tricky. the timeout can occur while the interpreter is
inside a perl op. the main reason the eval/alarm/die trick works is that
the signal handler just calls die which unwinds the stack to before the
eval. if the handler did anything with memory, it could crash perl.
a more generic eval with timeout api is not a bad idea. but it will
almost surely use some form of delivery (internal or perl level
callback) that needs to be designed as a whole and not just a special
thing for eval.
so my point which i constantly harp on (sorry), is that the signal
delivery at the perl level (both language and internal) is a critical
design issue.
DS I/O events are another area where we'll want to hide signals
DS generally, since the PerlIO layer will want to be taking care of
DS that itself.
even though the I/O subsystem will probably trap and use SIGIO
(especially for async file i/o on solaris et. al.), the final signal
delivery (i/o completion callback) still needs to be done synchronously
with the perl interpreter.
so please don't talk about these signals usages are important and need a
better api or this signal will only be used this way. the key is always
signal delivery. the rest is easier. :)
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: Speaking of signals...
Sam Tregar [EMAIL PROTECTED] writes: On Wed, 3 Jan 2001, Dan Sugalski wrote: I think one of the things we might want to do is figure out what people use signals for and see if we can abstract out some of that functionality without actually exposing signals. (From an internals standpoint, at least) Well, one thing people use signals for is IPC with non-Perl processes. I think that if you're want to continue to support that then we need an interface to real, broken though they may be, POSIX signals. Maybe the code gets pushed out of the core, but it still needs to be somewhere. POSIX signals cannot be pushed out - essentially that is what has happened in perl1..5 - we need to pull 'em in. -- Nick Ing-Simmons
Re: Speaking of signals...
"IS" == [EMAIL PROTECTED] writes: IS Dan Sugalski [EMAIL PROTECTED] writes: IS I have some sympathy with Uri's position here. Signals and event IS loops are close cousins. What I am less clear about is whether we IS want to go down the Tcl route, or do something even more radical IS like making op despatch and the event loop _the same thing_. (If IS we think of perl's ops as the instructions of our virtual machine, IS then this is like what happens when a hardware processor is IS "interrupted".) that is my concept of inline delivery. in the op dispatch loop, either a counter is used or a special op (which was automatically code generated is called and then all pending events (I/O, signals, timers, etc.) get dispatched synchronously with the perl interpreter. this mode is needed when you don't use an event loop or you manually call the event dispatcher in your own code. the count value or how often or where to insert event check op codes is set with a pragma. this event delivery method is great for basic programs that want some async behaviour and are not concerned about the overhead of 'polling' for pending events. at it guarantees all events are delivered synchronously so you can do any normal perl operations in any event handler. that is the primary goal for the entire subsystem, allowing normal perl in signal handlers. :) the AIO system would support all 3 delivery methods with almost no extra code required. but it does wrap signals tightly with the event loop and almost requires the event loop be in the deep core along with the I/O subsystem. both still should be modular enough that they could be replaced in a palm port. i think the API i proposed (simple attribute based objects) would make it easy to modularize the whole thing. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: standard representations
Andy Dougherty [EMAIL PROTECTED] wrote: (Does the LPGL and the existence of fgmp make it ok to distribute the interface/XS code and rely on the end user to install gmp if they so choose? Ick. I hate licensing problems.) This is actually one of the reasons I'd like to see the licensing working group to continue indefinitely. We need to decide: "Do we want perl6 to depend on libraries with somewhat stricter licenses?" I personally think that the relying on LGPL'ed code is completely reasonable. Some will disagree, so we need to come to a consensus on this as a community. Also, note that as long as our license is compatible with the LGPL (and most licenses are). There are no licensing problems for us, but we might be creating hassles for those who redistribute proprietary software versions of perl. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: standard representations
Dan Sugalski [EMAIL PROTECTED] wrote: I'm beginning to loathe software licenses in a *big* way, and I'm a half step away from saying to hell with it all and going fully public domain. (Or at least pushing for it, as I don't control perl's licensing terms) Public domain has it's own troubles too. To be safe in doing a public domain license, we'll need to get copyright disclaimers from everyone who contributes code (and possibly their employers). Otherwise, someone could come along later and legally claim copyright on some part. Liceses. Bletch. Don't blame the licenses, blame the copyright law that makes them an unfortunate necessity in many cases. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
