Re: inline mania

2000-08-01 Thread Dan Sugalski
At 05:55 PM 8/1/00 -0400, John Tobey wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Non-inline functions have their place in reducing code size and easing debugging. I just want an i_foo for every foo that callers will have the option of using. Before we make any promises to do

Re: RFC: Implementation of Threads in Perl (v1)

2000-08-02 Thread Dan Sugalski
"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: C# (.NET) has no interpreters

2000-08-02 Thread Dan Sugalski
On Wed, 2 Aug 2000, Kevin Scott wrote: While C might be fine and dandy for getting o.k. native code w/o too much implementation effort, I think that it might be worth the effort to implement a JIT compiler for the perl interpreter's intermediate language. Given the number of OSes and chip

Re: RFC: On-the-fly tainting via $^T

2000-08-01 Thread Dan Sugalski
this is certainly doable (heck, you can do it now with tied variables), I'm not at all comfortable with a magic untainting variables. I think it's a rather bad idea. Dan --"it's like this"------- Da

Re: GC

2000-08-04 Thread Dan Sugalski
! Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: perl6-internals-gc sublist

2000-08-04 Thread Dan Sugalski
At 02:48 PM 8/4/00 -0400, John Tobey wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Yup, and I realized one of my big problems to GCs that move memory (references that are pointers and such) really isn't, if we keep the two-level variable structure that we have now. The 'main' SV structure

Re: kpathsea

2000-08-04 Thread Dan Sugalski
like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: perl6-internals-gc sublist

2000-08-05 Thread Dan Sugalski
At 01:03 PM 8/5/00 -0400, John Tobey wrote: Dan Sugalski [EMAIL PROTECTED] wrote: and it will require jumping through a lot of hoops because of perl's profligate use of dynamic polymorphing. If it's needed, well, we'll do it, but I'd rather put the effort elsewhere to start

Re: Ramblings on base class for SV etc.

2000-08-05 Thread Dan Sugalski
. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 35 / Re: perl6-internals-gc sublist

2000-08-05 Thread Dan Sugalski
nlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan ------"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED]

Re: RFC: Foreign objects in perl

2000-08-05 Thread Dan Sugalski
--if someone's leaking interpreters then, well, they've got bigger problems than the odd foreign object. :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL

Re: RFC: Foreign objects in perl

2000-08-05 Thread Dan Sugalski
At 03:29 AM 8/4/00 -0400, Ken Fox wrote: Dan Sugalski wrote: Your extended way's cool too--RFC it and we can do that as well. I've been wanting to. It would be nice (at least for me) for you to start suggesting more RFC "assignments" like this. Community is not the same as &qu

Re: RFC: Foreign objects in perl

2000-08-06 Thread Dan Sugalski
At 07:54 AM 8/6/00 -0400, John Tobey wrote: On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski wrote: John Tobey wrote: Picture this. A Lisp (or Java, ...) structure holds a Perl interpreter. A Perl variable holds a reference to the Lisp structure. Structure and interpreter

Re: RFC 35 (v1) A proposed internal base format for perl

2000-08-06 Thread Dan Sugalski
y change" parts. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Ramblings on base class for SV etc.

2000-08-06 Thread Dan Sugalski
Okay, Okay, I was sloppy! :) I was using the p5 term, assuming it'd give more context for folks to work with. I agree it should be different and more appropriately named for p6. Dan ------"it

Re: RFC Archive

2000-08-03 Thread Dan Sugalski
like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Language RFC Summary 4th August 2000

2000-08-04 Thread Dan Sugalski
to be designed in. I'm working on it. :) I promised Kirrily that I'd race you in the RFC count... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL

Re: type-checking [Was: What is Perl?]

2000-08-01 Thread Dan Sugalski
example, did a "$foo[2] = 'bar'" I don't see any reason not to make $foo[2] have a value of 0. (With a warning emitted by -w, of course) Dan ------"it's like this"-

Re: Perl6 Prject Plan / Roadmap

2000-08-05 Thread Dan Sugalski
question, given that's almost a year off. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bear

Re: named parameters

2000-08-04 Thread Dan Sugalski
to the non-op functions, it means they don't have to worry about writing code to do localtime however we do it, they can just call our function. Dan --"it's like this"------- Da

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

2000-08-04 Thread Dan Sugalski
At 12:35 PM 8/4/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS The language semantics of tie strongly impact the internals. tie() is DS basically a declaration that the rules are completely different (and DS unknown at compile time) for the tie

Re: Language RFC Summary 4th August 2000

2000-08-04 Thread Dan Sugalski
needs has to be designed in. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

2000-08-04 Thread Dan Sugalski
s to data with known behaviours. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even

Re: RFC 27 (v1) Coroutines for Perl

2000-08-04 Thread Dan Sugalski
t be unreasonable. This would necessitate the expansion of select to check for pending events/coroutine writes/data, but that's likely to happen anyway, so... Dan --"it's like this"--- Dan Sugalski

Re: RFC 27 (v1) Coroutines for Perl

2000-08-04 Thread Dan Sugalski
creation/attachment methods for conceptually distinct things. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bear

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing throughtie.)

2000-08-05 Thread Dan Sugalski
be perfectly happy to do so, though, if the resulting code is frozen to disk so I didn't pay it the next time. Dan --"it's like this"--- Dan Sugalski

Re: RFC 27 (v1) Coroutines for Perl

2000-08-04 Thread Dan Sugalski
ent-based perl runtime, the select loop would be hidden from the programmer. All I/O calls would be non-blocking and context switching. I meant select the perl construct, not select the low-level construct. Dan ------

Re: RFC: On-the-fly tainting via $^T

2000-08-02 Thread Dan Sugalski
At 12:51 PM 8/2/00 +0100, Graham Barr wrote: On Tue, Aug 01, 2000 at 11:56:48AM -0400, Dan Sugalski wrote: What I was thinking of was something along the lines of a lexically scoped pragma--"use taint"/"no taint". (We could do this by sticking in an opcode to set/unset

Re: RFC 38 (v1) Standardise Handling Of Abnormal Numbers

2000-08-07 Thread Dan Sugalski
) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Perl6 Prject Plan / Roadmap

2000-08-07 Thread Dan Sugalski
At 09:38 AM 8/7/00 +0200, H.Merijn Brand wrote: On Sat, 05 Aug 2000 12:54:52 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: At 06:04 PM 8/5/00 +0200, H.Merijn Brand wrote: In the roadmap, there's lot of actions and shamelines as spoken of in the camel herders association meeting. What

Re: pramgas as compile-time-only

2000-08-07 Thread Dan Sugalski
At 05:42 PM 8/7/00 +0100, Graham Barr wrote: On Mon, Aug 07, 2000 at 12:03:36PM -0400, Dan Sugalski wrote: I've been thinking we could have a "state change" op that would selectively and lexically alter the appropriate state variable (warnings, stricture, shell, taint checking

Re: RFC: Foreign objects in perl

2000-08-07 Thread Dan Sugalski
we may need some sort of "refered to by" field to track variables that have had references to them taken, so we know when the last referent goes out of scope) Dan --"it's like this"----

Re: vtables (was Re: Ramblings on base class for SV etc.)

2000-08-07 Thread Dan Sugalski
On Mon, 7 Aug 2000, Uri Guttman wrote: can someone write up a short description (or rfc is you prefer) on vtables. i gather that they are a per value (for some definition of value) dispatch table which handles the ways a value can be accessed. everyone is using that term and i haven't seen

Re: pramgas as compile-time-only

2000-08-08 Thread Dan Sugalski
ibly handy, that. :) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 61 (v2) Interfaces for linking C objects into pe

2000-08-08 Thread Dan Sugalski
programmer. Is that it, in a nutshell, or am I missing something? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have t

Re: pramgas as compile-time-only

2000-08-08 Thread Dan Sugalski
like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: pramgas as compile-time-only

2000-08-08 Thread Dan Sugalski
On Tue, 8 Aug 2000, Bart Lateur wrote: On Tue, 08 Aug 2000 11:33:06 -0400, Dan Sugalski wrote: The problem perl will always run into is that our executable code counts as data to CPUs, and lives in the D cache, along with all the data we work on. Ripping through a few 100K strings'll

Re: RFC 61 (v2) Interfaces for linking C objects into pe

2000-08-08 Thread Dan Sugalski
On Tue, 8 Aug 2000, Nick Ing-Simmons wrote: Perl6 Rfc Librarian [EMAIL PROTECTED] writes: This document is not precisely concerned with the details of the implementation of the interfaces it specifies, beyond a general attempt to restric itself to the possible. But this list is _only_

Re: Ramblings on base class for SV etc.

2000-08-08 Thread Dan Sugalski
On Tue, 8 Aug 2000, Ken Fox wrote: Chaim Frenkel wrote: Have every Package generate a vtbl for each subroutine in the package. Then when something is blessed into the package ... I wasn't discussing the core. Rather a possible optimization of method lookup. At any time only for

Re: Method call optimization.

2000-08-09 Thread Dan Sugalski
be backwards. ;-) True, quite true. I should throw together a reasonable test program (with, say, LWP and Net::FTP) in perl 5 and see what the symbol tables look like. Dan --"it's like this"-----

Re: Hooks for array notation (was Re: Ramblings on base class for SV etc.)

2000-08-09 Thread Dan Sugalski
At 05:41 PM 8/9/00 +0200, Bart Lateur wrote: On Wed, 09 Aug 2000 10:04:15 -0400, Dan Sugalski wrote: 5- Compact array storage: RFC still coming I hope this RFC will be "Arrays should be sparse when possible, and compact" and just about nothing else. :) You mean, something l

Re: PDL-P: Re: Hooks for array notation (was Re: Ramblings on baseclass for SV etc.)

2000-08-09 Thread Dan Sugalski
At 07:07 PM 8/9/00 -0400, Karl Glazebrook wrote: Dan Sugalski wrote: At 11:27 PM 8/9/00 +1000, Jeremy Howard wrote: 5- Compact array storage: RFC still coming I hope this RFC will be "Arrays should be sparse when possible, and compact" and just about nothing else. :) Why

Re: PDL-P: Re: Hooks for array notation (was Re: Ramblings on baseclass for SV etc.)

2000-08-10 Thread Dan Sugalski
On Thu, 10 Aug 2000, Jeremy Howard wrote: At 07:07 PM 8/9/00 -0400, Karl Glazebrook wrote: Dan Sugalski wrote: At 11:27 PM 8/9/00 +1000, Jeremy Howard wrote: 5- Compact array storage: RFC still coming I hope this RFC will be "Arrays should be sparse when pos

Re: Program lifecycle

2000-08-10 Thread Dan Sugalski
--"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Program lifecycle

2000-08-10 Thread Dan Sugalski
if it was saving the byte stream to disk...) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bear

Re: Program lifecycle

2000-08-10 Thread Dan Sugalski
gging more compartmentalized. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even

Re: Method call optimization.

2000-08-10 Thread Dan Sugalski
"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Program lifecycle

2000-08-11 Thread Dan Sugalski
ne backend for a whole bunch of language front-ends. If they can front-end fortran, C++, and cobol, we ought to be able to do it with perl...) Dan --"it's like this"------- Dan Sugalski

Re: sorted sparse containers (was Re: PDL-P: Re: Hooks for array notation (was Re: Ramblings on baseclass for SV etc.)

2000-08-12 Thread Dan Sugalski
At 12:14 PM 8/12/00 -0400, Bryan C. Warnock wrote: On Fri, 11 Aug 2000, David L. Nicol wrote: Dan Sugalski wrote: Strong typing and sparse arrays are orthogonal--no reason we shouldn't use them if someone does: $foo[time] or something of the sort. (People like huge

Re: Ramblings on base class for SV etc.

2000-08-12 Thread Dan Sugalski
At 10:47 PM 8/12/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: Er, you still have to think about whether something could be tied and tainted at the same time. DS Yeah, that's an issue. We need to hammer out how much is the responsibility DS of

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

2000-08-12 Thread Dan Sugalski
o. Whether it's too specialized to be worth it's a separate issue, of course. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED]

A plea to RFC authors

2000-08-07 Thread Dan Sugalski
t "most CS educated folks" ought to know (a category a number of us don't necessarily fall into), it's handy to know where to look to brush up on the details of the thing in question. Dan --"it's like th

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

2000-08-12 Thread Dan Sugalski
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote: Dan Sugalski writes: I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less

Re: RFC 35 (v1) A proposed internal base format for perl

2000-08-14 Thread Dan Sugalski
On Mon, 14 Aug 2000, Larry Wall wrote: Nick Ing-Simmons writes: : It's not clear to me whether the intrinsic types should have a different : solution to this than the extrinsic types. : : _This_ thread is about using vtables for intrinsic types. If we cannot : make them work there then

Re: RFC 35 (v1) A proposed internal base format for perl

2000-08-14 Thread Dan Sugalski
On Mon, 14 Aug 2000, Larry Wall wrote: Dan Sugalski writes: : The big problem here is the large number of operators that need to : be supported in every vtable. On the other hand, it means we whittle : ourselves down to only one operator opcode. ;-) I don't care if the program is half

Re: RFC 35 (v1) A proposed internal base format for perl

2000-08-14 Thread Dan Sugalski
On Mon, 14 Aug 2000, Larry Wall wrote: Dan Sugalski writes: : On Mon, 14 Aug 2000, Larry Wall wrote: : : Dan Sugalski writes: : : The big problem here is the large number of operators that need to : : be supported in every vtable. On the other hand, it means we whittle : : ourselves

Re: RFC 35 (v1) A proposed internal base format for perl

2000-08-14 Thread Dan Sugalski
On 14 Aug 2000, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS How much of the current base of target ports are you willing to give up in DS the first cut for fast? The TIL suggestion, amongst others, has the DS potential to speed things up rather a lot,

Re: Welcome to Perl Vtbls

2000-08-15 Thread Dan Sugalski
functions to be capable of being written in perl. Even if we don't want to write the floating point division routines ourselves, I'd like to be able to) Dan --"it's like this"----

Re: Threaded In-Line Code (was Re: Typed Intermediate Language)

2000-08-15 Thread Dan Sugalski
function for variable @b, and pass it a pointer to @c, and let it Do The Right Thing. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED]

Internals WG, through August 15th

2000-08-16 Thread Dan Sugalski
collection, but it's not really gone anywhere, besides to the bookstore. The current reference-count GC scheme will probably go, though. Dan --"it's like this"------- Dan Sugalski ev

Re: Internals WG, through August 15th

2000-08-16 Thread Dan Sugalski
At 04:43 PM 8/16/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS * There was some discussion about garbage collection, but it's not really DS gone anywhere, besides to the bookstore. The current reference-count GC DS scheme will probably go, though.

Off for a week

2000-08-16 Thread Dan Sugalski
--"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)

2000-08-17 Thread Dan Sugalski
Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

2000-08-15 Thread Dan Sugalski
date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations. Dan --"it's like this"------- Da

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

2000-08-15 Thread Dan Sugalski
-1858 00:00:00.00, for some astronomical reason IIRC. It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all time in Unix epoch seconds. Dan --"it's like this"------- Da

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 12:23 AM 8/23/00 +, David L. Nicol wrote: Dan Sugalski wrote: Any variable that has a 'per-thread' component should be self-contained. We don't know how many instances of iteration happening in the program there will be, or how many there can be. If each instance of hash iteration

Re: .NET IL

2000-08-23 Thread Dan Sugalski
hings that munch the bytecode. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 11:30 AM 8/23/00 -0700, Larry Wall wrote: Dan Sugalski writes: : I have had the "Well, Duh!" flash, though, and now do realize that having : multiple iterators over a hash or array simultaneously could be rather handy. You can also have the opposite "Well, Duh!" flash a

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-23 Thread Dan Sugalski
At 11:26 AM 8/23/00 -0700, Larry Wall wrote: Dan Sugalski writes: : The core will already know. Especially if we add return types. Sure. Can't hurt to add code to optimize 'old-style' perl 5 code either, though. : Whether this justifies exposing the information's for someone else to : judge

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-23 Thread Dan Sugalski
At 01:49 PM 8/23/00 -0700, Larry Wall wrote: Dan Sugalski writes: : At 11:30 AM 8/23/00 -0700, Larry Wall wrote: : Dan Sugalski writes: : : I have had the "Well, Duh!" flash, though, and now do realize that having : : multiple iterators over a hash or array simultaneously could be rath

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

2000-08-24 Thread Dan Sugalski
re or less. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

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

2000-08-25 Thread Dan Sugalski
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: Dan Sugalski writes: One of the current plans is for the parser to have access to a list of functions that trigger autoloading modules. Isn't dynamic loading really slow? Not particularly, at least not as far as I know. There's some extra

Re: RFC 155 - Remove geometric functions from core

2000-08-25 Thread Dan Sugalski
of the functions under discussion. (They're generally trivial wrappers around library calls, with very little code involved) Dan --"it's like this"------- Dan Sugalski ev

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

2000-08-25 Thread Dan Sugalski
At 06:27 AM 8/25/00 -0700, Benjamin Stuhl wrote: At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: Dan Sugalski writes: One of the current plans is for the parser to have access to a list of functions that trigger autoloading modules. Isn't dynamic loading really slow

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

2000-08-25 Thread Dan Sugalski
... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy

Re: RFC 155 - Remove geometric functions from core

2000-08-25 Thread Dan Sugalski
still continue to work unaltered, then I suppose not--assuming no seriously grave performance issues. That's one of the working goals... Dan --"it's like this"------- Dan Sugalski

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

2000-08-25 Thread Dan Sugalski
that details what I'm thinking about for this... Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bear

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

2000-08-25 Thread Dan Sugalski
on into a shareable image so we don't even need to parse a text file--it's already predigested and available) Dan --"it's like this"--- Dan Sugalski

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

2000-08-25 Thread Dan Sugalski
. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Dan Sugalski
that be $baz = 3, since the middle list would be taken in scalar context? Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED]

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

2000-08-25 Thread Dan Sugalski
into perl 6. Whether (or how) that happens depends mainly on the speed penalty the overriding costs. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL

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

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

2000-08-28 Thread Dan Sugalski
attributes. You folks are all going to make my head explode before this is all over, aren't you? (Not that it's a *bad* thing, mind... :) Dan --"it's like this"------- Dan Sugalski

Re: multidim. containers

2000-08-28 Thread Dan Sugalski
like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: multidim. containers

2000-08-28 Thread Dan Sugalski
At 08:18 AM 8/29/00 +1200, Christian Soeller wrote: Dan Sugalski wrote: That doesn't mean that n-dimensional arrays won't be just sugar over the standard list-o-list structure to start, but they won't have to stay that way. That seems to be a possible route. Get multi-dim syntax for arrays

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread Dan Sugalski
of the way now, rather than after spending a month or more of wasted time. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED]

Removing stuff to shareable thingies

2000-08-29 Thread Dan Sugalski
be nice to statically link in code that would otherwise be dynamically loaded I've got part of an RFC done--I'll finish it and send it off. Dan --"it's like this"------- Da

Re: Optional Separate Programs for Interpreter Passes

2000-08-29 Thread Dan Sugalski
. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread Dan Sugalski
lved calls into the routines in the newly loaded library get resolved. Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have

Re: Removing stuff to shareable thingies

2000-08-29 Thread Dan Sugalski
On 29 Aug 2000, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: 2) Having a mechanism to automagically load in chunks of executable code only when needed would be nice It's not clear to me how useful this really is from an internals speed standpoint on modern systems. It's

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread Dan Sugalski
On 29 Aug 2000, Russ Allbery wrote: I'm not sure I'm completely following what you're arguing for here, but be careful not to go too far down the road of duplicating what the dynamic loader already knows how to do. There be dragons; that stuff is seriously baroque. You really don't want to

Re: RFC 172 (v1) Precompiled Perl scripts.

2000-08-30 Thread Dan Sugalski
because we hand someone a gun doesn't mean we need to load it and point it somewhere as well) Dan --"it's like this"------- Dan Sugalski even samurai [EMAIL

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)

2000-08-30 Thread Dan Sugalski
--"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

Re: Removing stuff to shareable thingies

2000-08-30 Thread Dan Sugalski
At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote: Dan Sugalski wrote: 2) Having a mechanism to automagically load in chunks of executable code only when needed would be nice I would take this one a bit further: 2a) It should be possible, at compile-time, to detect what chunks

Re: RFC 155 - Remove geometric functions from core

2000-08-30 Thread Dan Sugalski
At 07:37 PM 8/29/00 -0700, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: On 29 Aug 2000, Russ Allbery wrote: I'd love to see Perl aggressively take advantage of new capabilities in dynamic loaders, though. Among other things, I'll point out that symbol versioning is the way

Re: a garbage collection book

2000-08-30 Thread Dan Sugalski
for biggish things), I wonder how much perl 5's performance could be boosted with some relatively minor changes to GC list handling. Dan --"it's like this"------- Dan Sugalski

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

2000-08-30 Thread Dan Sugalski
"it's like this"------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk

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

2000-08-30 Thread Dan Sugalski
At 01:26 PM 8/30/00 -0500, David L. Nicol wrote: Dan Sugalski wrote: Oh, and then they will be unloaded if we need the space for something else. I understand now, thanks. Well, probably not, though that could be reasonable for a particular platform. It's only relevant

Re: RFC 155 - Remove geometric functions from core

2000-08-30 Thread Dan Sugalski
On Wed, 30 Aug 2000, Andy Dougherty wrote: On Tue, 29 Aug 2000, Russ Allbery wrote: Not a big deal, and that's certainly doable. But it's possible to do more than that if you really want to. The glibc folks have decided to comment to nearly full binary compatibility for essentially

Re: Removing stuff to shareable thingies

2000-08-30 Thread Dan Sugalski
On Wed, 30 Aug 2000, Bradley M. Kuhn wrote: Dan Sugalski wrote: At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote: 2) Having a mechanism to automagically load in chunks of executable code only when needed would be nice I would take this one a bit further: 2a) It should

  1   2   3   4   5   6   7   8   9   10   >