RFC 167 (v1) Simplify Cdo BLOCK Syntax

2000-08-27 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Simplify Cdo BLOCK Syntax =head1 VERSION Maintainer: Mark Senn [EMAIL PROTECTED] Date: 27 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 167 =head1 ABSTRACT Simpify syntax of Cdo

Re: RFC 155 - Remove geometric functions from core

2000-08-27 Thread Nick Ing-Simmons
Jarkko Hietaniemi [EMAIL PROTECTED] writes: bytes microperl, which has almost nothing os dependent (*) in it 1212416 shared libperl 1277952 bytes + perl 32768 bytes1310720 dynamically linked perl

Re: RFC 155 - Remove geometric functions from core

2000-08-27 Thread Jarkko Hietaniemi
On Sun, Aug 27, 2000 at 08:37:38PM +, Nick Ing-Simmons wrote: Jarkko Hietaniemi [EMAIL PROTECTED] writes: bytes microperl, which has almost nothing os dependent (*) in it 1212416 shared libperl 1277952 bytes + perl 32768

RE: RFC 146 (v1) Remove socket functions from core

2000-08-27 Thread Nick Ing-Simmons
Al Lipscomb [EMAIL PROTECTED] writes: I wonder if you could arrange things so that you could have statically linked and dynamic linked executable. Kind of like what they do with the Linux kernel. When your installation is configured in such a way as to make the dynamic linking a problem, just

Re: RFC 146 (v1) Remove socket functions from core

2000-08-27 Thread Nick Ing-Simmons
Michael G Schwern [EMAIL PROTECTED] writes: Like all other optimizing attempts, the first step is analysis. People have to sit down and systematically go through and find out what parts of perl (and Perl) are eating up space and speed. The results will be very surprising, I'm sure, but it will

Re: RFC 161 (v2) OO Integration/Migration Path

2000-08-27 Thread Nathan Torkington
Dan Sugalski writes: If the vtable stuff goes into the core perl engine (and it probably will, barring performance issues), then what could happen in the I have a lot of questions. Please point me to the appropriate place if they are answered elsewhere. vtables are tables of C functions?

Re: RFC 161 (v2) OO Integration/Migration Path

2000-08-27 Thread Dan Sugalski
On Sun, 27 Aug 2000, Nathan Torkington wrote: Dan Sugalski writes: If the vtable stuff goes into the core perl engine (and it probably will, barring performance issues), then what could happen in the I have a lot of questions. Please point me to the appropriate place if they are

Re: We're all grown-ups on this bus...

2000-08-27 Thread Stephen P. Potter
Lightning flashed, thunder crashed and Dan Sugalski [EMAIL PROTECTED] whispered: | or we can all darned well fake it at the very least. Dan, Larry, and the rest of the members of perl6-internals: I apologize for my behaviour the other evening. It was childish and served no purpose on this

Re: RFC 155 - Remove geometric functions from core

2000-08-27 Thread Stephen P. Potter
Lightning flashed, thunder crashed and Steve Fink [EMAIL PROTECTED] whispered: | Depends on your definition of "module". Many people seem to be assuming | "module" eq "shared library". Yes, exactly. I use module as a generic term for something other than the main perl binary itself, a black

Re: multidim. containers

2000-08-27 Thread Jeremy Howard
X-posted to [EMAIL PROTECTED] David L. Nicol wrote: If arrays as we know them implement by using a key space restricted to integers, I think a reasonable way to get matrices would be to open up their key space to lists of integers. I've been thinking along exactly the same lines. There's a