Jonathan Scott Duff writes:
> > In the future, if you want to submit an RFC mail it to
> > [EMAIL PROTECTED] only.
>
> http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to
> [EMAIL PROTECTED] rather than [EMAIL PROTECTED]
They go to the same place. However, I meant to onl
Tim Bunce said:
> On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
> > <...>
> > That's a good summary of what we've been thinking. Here's another
> > article that talks about a lot of the things we *should* be thinking.
> > In fact, it's possible this article should be required readin
Since no-one has mentioned it yet, I just thought I'd point out that the
Perl Data Language (PDL) has a system for automatically generating XS code
from a "simpler" interface called PDL::PP.
This provides a simplified (currently PDL specific) access to
external libraries but provides all the po
On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote:
> I'm about to push the button that will send my private set of RFCs
> off to the archive and mail them to perl6-announce. Fingers crossed.
Hooray!!
> If I've forgotten your RFC, please send it to [EMAIL PROTECTED]
>
> In the f
=head1 TITLE
Multiline Comments for Perl.
=head1 VERSION
Maintainer: Michael J. Mathews <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 5
=head1 ABSTRACT
Unlike many programming languages Perl does not currently implement true
multiline comme
=head1 TITLE
Implementation of Threads in Perl
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 1
=head1 ABSTRACT
Perl 6 should be built around threads from the beginning.
=head1 DESCRIPTI
I'm about to push the button that will send my private set of RFCs
off to the archive and mail them to perl6-announce. Fingers crossed.
The RFC archive is at http://tmtowtdi.perl.org/rfc/
If I've screwed up your RFC, please let me know.
If I've forgotten your RFC, please send it to [EMAIL PROT
Ask Bjoern Hansen writes:
> http://tmtowtdi.perl.org/rfc/
> (will soon be http://dev.perl.org/rfc/)
I'm working on it right now, so things will appear and disappear.
I'll post when it's stable. Please hold :-)
Nat
On Wed, 2 Aug 2000, Bradley M. Kuhn wrote:
> It appears Dan posted some internals RFCs, and due to some
> trouble with my subscription request, I didn't see them. I
> realize that I can get them out of the archives if I dig, but is
> there a WWW site yet where all RFCs are being kept?
http://tm
> > 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.
Speaking of intermediate languages, is there any more concrete i
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 chi
Ken Fox wrote:
>
> I'd prefer us to tackle native code generation using C as the
> intermediate language instead of a JIT. It's more portable, simpler
> and takes advantage of all the C compiler optimizations. I'm not
> looking for Perl 6 to be a Java/Applet replacement. Is that really
> where we
Dan Sugalski wrote:
> > there is a nice paper "The Structure and Performance
> > of Interpreters" by Romer, Lee, et al. that compares Java, Perl and Tcl.
>
> URL?
Google had a bunch of references when I searched on "structure performance
interpreters", but none of them had the full text. (The AC
Dan Sugalski wrote:
> TheObj *foo;
> SV *new_sv;
> foo = new TheObj("A parameter");
> sv = perl_new_sv();
> perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
> &destroy_routine);
>
> perl_return(perl_make_ref(sv));
Are yo
>On Wed, Aug 02, 2000 at 04:38:12PM -0400, John Tobey wrote:
>> Can I safely assume that we will be counting references for garbage
>> collection?
>Ref counting isn't garbage collection.
>http://www.jwz.org/doc/gc.html
That's one opinion--it's not the Word of God.
Ref counting *is* automatic me
On Wed, Aug 02, 2000 at 04:38:12PM -0400, John Tobey wrote:
> Can I safely assume that we will be counting references for garbage
> collection?
Ref counting isn't garbage collection.
http://www.jwz.org/doc/gc.html
--
Life would be so much easier if we could just look at the source code.
Joshua N Pritikin wrote:
> Of course perl6 can retain both execution models (op-tree & native
> code), but perhaps the emphasis should be on optimized native code.
The Kaffe java VM uses a native code JIT and they've had trouble
getting decent performance. From their own web page (www.kaffe.org):
It appears Dan posted some internals RFCs, and due to some trouble with my
subscription request, I didn't see them. I realize that I can get them out
of the archives if I dig, but is there a WWW site yet where all RFCs are
being kept?
I looked around http://www.perl.org/perl6, but didn't see the
Dan Sugalski wrote:
> At 01:52 PM 8/2/00 -0400, Ken Fox wrote:
> >Dan Sugalski wrote:
> > > I wanted to do this not so much to reduce the size of the core (They're not
> > > *that* much code) as to reduce the number of opcodes being used. I really,
> > > *really* want to trim down the opcode list.
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
> raptor writes:
> : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
>
> That's a good summary of what we've been thinking. Here's another
> article that talks about a lot of the things we *should* be thinking.
> In fa
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > A scalar is made an object via a call into the perl library. The
> > > scalar is marked as an object and stuck into a package. Attached to
> > > the scalar is a pointer to the native object, a pointer to a
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]>
> wrote the following on Wed, 02 Aug 2000 16:13:50 -0400
Dan> I'd also like to teach PI (or whatever it becomes) to produce joined
Dan> opcodes. Ilya did some profiling of perl 5 code, and there were a
Dan> bunch of common op pairs. Joinin
>> cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
>> Date: Wed, 02 Aug 2000 13:58:49 -0600
>> From: Tom Christiansen <[EMAIL PROTECTED]>
>> X-UIDL: ab65e2a94d9487f65465be74c21fe152
>>
>> >> Insofar as you can pretend to make a good guess at that--perhaps.
>>
>> >On Linux: /proc/self
>> Insofar as you can pretend to make a good guess at that--perhaps.
>On Linux: /proc/self/exe
What good does that do you? You can't go ../foo with that. It doesn't
tell you the real name, just the dev,ino. And it's a nonportable answer
that cannot be reproduced everywhere that Perl runs.
--
>Yes, but that seems a bit more tractable - surely we could fiddle with
>@INC based on the location of the perl interpreter?
Insofar as you can pretend to make a good guess at that--perhaps.
--tom
On Wed, Aug 02, 2000 at 03:09:19PM -0400, John Tobey wrote:
> > Solaris 7 onwards has a nice linker feature called $ORIGIN. This allows
> > the location of run-time linker dependencies to be specified relative to
> > the location of the executable.
>
> Both Windows and Linux can swing this, too.
At 05:39 PM 8/2/00 -0400, John Tobey wrote:
>[un-CC'ed to librarian - is this correct procedure?]
I'd say so, yep. Take that as official for the moment.
> > A scalar is made an object via a call into the perl library. The
> > scalar is marked as an object and stuck into a package. Attached to
>
[un-CC'ed to librarian - is this correct procedure?]
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> =head1 TITLE
>
> A method of allowing foreign objects in perl
I like it.
> =head1 VERSION
>
> Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
> Date: August 02, 2000
> Version: 1
> Mailing L
=head1 TITLE
A method of allowing foreign objects in perl
=head1 VERSION
Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
Date: August 02, 2000
Version: 1
Mailing List: perl6-internals
Number: XXX
=head1 ABSTRACT
Currently it's a darned pain to deal with objects created in other
languag
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:38 PM 8/2/00 -0400, John Tobey wrote:
> >Can I safely assume that we will be counting references for garbage
> >collection?
>
> No.
>
> In fact, you can safely assume that GC will be handled by some non-refcount
> method, and that GC and end-of-sc
At 04:38 PM 8/2/00 -0400, John Tobey wrote:
>Can I safely assume that we will be counting references for garbage
>collection?
No.
In fact, you can safely assume that GC will be handled by some non-refcount
method, and that GC and end-of-scope action will be decoupled. (Whether
that *happens* i
On Wed, Aug 02, 2000 at 04:38:12PM -0400, [EMAIL PROTECTED] wrote:
> Can I safely assume that we will be counting references for garbage
> collection?
Well, for starters. However, I'd like to see a distinction made between
destructors that must run at the end of a scope, and those lacking an
urg
Can I safely assume that we will be counting references for garbage
collection?
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
///
On Wed, Aug 02, 2000 at 04:13:50PM -0400, [EMAIL PROTECTED] wrote:
> I'd also like to teach PI (or whatever it becomes) to produce joined
> opcodes. Ilya did some profiling of perl 5 code, and there were a bunch of
> common op pairs. Joining them together (thus saving both dispatch time
> *and*
On Wed, Aug 02, 2000 at 09:01:18PM +0100, [EMAIL PROTECTED] wrote:
> On Wed, Aug 02, 2000 at 12:20:00PM -0600, Nathan Torkington wrote:
> > Ken Fox writes:
> > > pipeline stalls, cache misses and a whole bunch of interesting things. One
> > > of the reasons Perl performed well is that it spent a l
At 11:52 AM 8/2/00 -0600, Nathan Torkington wrote:
>Graham Barr writes:
> > Why would the fuzzy regex not be done this way ?
>
>I have some small objections:
>
>I think one regexp syntax with potentially wildly variable
>interpretations is a dangerous thing. If we want fuzzy
>regexp matching, eit
At 05:39 PM 8/2/00 +0100, Tim Bunce wrote:
>On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
> >
> > Reference counting is going to be a fun one, that's for sure.
> >
> > I'd like the interface to be something like:
> >
> >stat = perl_get_value(sv *, int what, &destination)
>
>And
At 01:52 PM 8/2/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > I wanted to do this not so much to reduce the size of the core (They're not
> > *that* much code) as to reduce the number of opcodes being used. I really,
> > *really* want to trim down the opcode list.
>
>If we reduce the number of
On Wed, Aug 02, 2000 at 12:20:00PM -0600, Nathan Torkington wrote:
> Ken Fox writes:
> > pipeline stalls, cache misses and a whole bunch of interesting things. One
> > of the reasons Perl performed well is that it spent a lot of time in what
> > they called native code, i.e. not decoding and dispa
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Date: Wed, 02 Aug 2000 13:58:49 -0600
> From: Tom Christiansen <[EMAIL PROTECTED]>
> X-UIDL: ab65e2a94d9487f65465be74c21fe152
>
> >> Insofar as you can pretend to make a good guess at that--perhaps.
>
> >On Linux: /proc/self/exe
>
Tom! Good to see you.
Tom Christiansen <[EMAIL PROTECTED]> wrote:
> >Yes, but that seems a bit more tractable - surely we could fiddle with
> >@INC based on the location of the perl interpreter?
>
> Insofar as you can pretend to make a good guess at that--perhaps.
On Linux: /proc/self/exe
--
Nick Ing-Simmons wrote:
> Explain what Tcl did (and which version of Tcl).
>
> I am aware of how Jan added TIFF support to Tcl/Tk:
> ...
> This is horrible - the names are replicated all over the place
> It still requires a compiler and seems to have all the worst features
> of all the schemes ..
John Tobey wrote:
> Both Windows and Linux can swing this, too. I believe linux (GNU
> Libc, to be precise) uses $ORIGIN in a Solaris-compatible way.
So I've just been told by our linker expert. Nice to have it confirmed
though.
--
Alan Burlison
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> I don't think so - it is a question which way we code the source:
> >>
> >> A. Use 'inline' every where and trust compiler not to do what we told it
> >>if it knows better.
> >> B. No inline hints in th
Graham Barr wrote:
> It is not just libraries, but also the perl @INC that needs to
> be dynamic
Yes, but that seems a bit more tractable - surely we could fiddle with
@INC based on the location of the perl interpreter?
--
Alan Burlison
Solaris Kernel Development, Sun Microsystems
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> That sounds like a pre-judgement that inline form is prefered ;-)
> >> But actually most places (I looked when doing TIEARAY) perl itself calls
> >> nether it uses AvFILL() macro instead.
> >
> >As I understa
John Tobey <[EMAIL PROTECTED]> writes:
>> I don't think so - it is a question which way we code the source:
>>
>> A. Use 'inline' every where and trust compiler not to do what we told it
>>if it knows better.
>> B. No inline hints in the source and trust the compiler to be able to
>>do
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Tim Bunce <[EMAIL PROTECTED]> writes:
> >
> >Perl5 XS/GUTS is the way it is largely because it was designed with
> >performance in mind.
>
> Hmm, maybe in some areas but not others:
> On the one hand the whole PUTBACK/SPAGAIN mess is by overly clev
From: Larry Wall [mailto:[EMAIL PROTECTED]]
>
> Here's another article that talks about a lot of the things we
> *should* be thinking. In fact, it's possible this article should
> be required reading for anyone who aspires to be a Perl designer.
>
> http://windows.oreilly.com/news/hejlsberg_0800.
John Tobey <[EMAIL PROTECTED]> writes:
>> That sounds like a pre-judgement that inline form is prefered ;-)
>> But actually most places (I looked when doing TIEARAY) perl itself calls
>> nether it uses AvFILL() macro instead.
>
>As I understand myself, AvFILL == i_av_fill, so thank you for
>confir
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Brent Fulgham <[EMAIL PROTECTED]> writes:
> >The 'inline' keyword is just a hint to the compiler. If optimization
> >is turned off, no inlining is done. If optimization is on, the
> >compiler may or may not decide to inline. Performance on different
Tim Bunce <[EMAIL PROTECTED]> writes:
>
>Perl5 XS/GUTS is the way it is largely because it was designed with
>performance in mind.
Hmm, maybe in some areas but not others:
On the one hand the whole PUTBACK/SPAGAIN mess is by overly clever
attempt to optimize access to "global" variables whic
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Bad assumption. How often is av_fill called?
> >
> >Only once in av_fill.c (generated by allfuncs.pl). In most other
> >places, it's called as i_av_fill().
>
> Tha
[EMAIL PROTECTED] wrote:
> Graham Barr wrote:
>
> > Well I think it is worth an RFC (not that I have time to write one just now)
> > If only to suggest some sample implementations. Do other languages do it ?
> > If so how ?
>
> Ok, Ok, I'll do a RFC then... :-)
>
> Actually the only thing aff
Brent Fulgham <[EMAIL PROTECTED]> writes:
>> > Having thought about it a bunch more (because of this) I'm
>> > proposing we let the compiler decide. The caller doesn't
>> > know enough to make that decision.
>>
>> Read carefully. I said we *let* the caller decide, not *make* the
>> caller dec
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'll point out here that I, for one, don't mind people deciding to head out
> and do a port/reimplement/rewrite on their own. I won't promise that your
> work (whoever you are in that sentence) will go into the 'official' perl
Thanks, that's all I ask.
Johan Vromans writes:
: Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
:
: > perl.exe + perl.dll or .../bin/perl + libperl.so
:
: RFC: Should the perl program be called differently (e.g., perl6) to
: allow sites to run 5 and 6 in parallel until their migration is
: completed (if ever)?
We will
John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Bad assumption. How often is av_fill called?
>
>Only once in av_fill.c (generated by allfuncs.pl). In most other
>places, it's called as i_av_fill().
That sounds like a pre-judgement that inline form is prefered ;
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
> raptor writes:
> : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
>
> That's a good summary of what we've been thinking. Here's another
> article that talks about a lot of the things we *should* be thinking.
> In fa
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I don't think Larry's weighed in on this one way or another lately.
DS> My bet is thread-shared data will get a shared attribute:
DS> my $foo : shared;
DS> possibly with some sort of dynamic sharing allowed. (i.e. you stuff a ref
Ken Fox writes:
> pipeline stalls, cache misses and a whole bunch of interesting things. One
> of the reasons Perl performed well is that it spent a lot of time in what
> they called native code, i.e. not decoding and dispatching ops.
One thing we could do is look at the op paths produced by perl
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> If this article is going to inspire multiple threads, let's try to
LW> give them unique subject names. Thanks.
and in general, we need better message subjects. already i have
seen threads fall into the one-subject-fits-all abyss of
al
Jonathan Scott Duff writes:
: On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
: > raptor writes:
: > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
: >
: > That's a good summary of what we've been thinking. Here's another
: > article that talks about a lot of the
Graham Barr wrote:
> Well I think it is worth an RFC (not that I have time to write one just now)
> If only to suggest some sample implementations. Do other languages do it ?
> If so how ?
Ok, Ok, I'll do a RFC then... :-)
Actually the only thing affected by LD_LIBRARY_PATH is libperl.so, as
raptor writes:
: http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
That's a good summary of what we've been thinking. Here's another
article that talks about a lot of the things we *should* be thinking.
In fact, it's possible this article should be required reading for
anyone who
Dan Sugalski wrote:
> I wanted to do this not so much to reduce the size of the core (They're not
> *that* much code) as to reduce the number of opcodes being used. I really,
> *really* want to trim down the opcode list.
If we reduce the number of opcodes, we need to consider the performance
impa
Graham Barr writes:
> Why would the fuzzy regex not be done this way ?
I have some small objections:
I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing. If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module tha
On Wed, 2 Aug 2000, Ken Fox wrote:
> Tim Bunce wrote:
> > > Alan Burlison wrote:
> > > > the ability to relocate or install perl in some place other than the
> > > > initial install location without everything breaking.
>
> > Volunteers?
>
> XEmacs does this very well. Can an RFC just say "do w
Tim Bunce wrote:
> > Alan Burlison wrote:
> > > the ability to relocate or install perl in some place other than the
> > > initial install location without everything breaking.
> Volunteers?
XEmacs does this very well. Can an RFC just say "do what xemacs does" or
does it have to be standalone?
On Wed, Aug 02, 2000 at 05:39:19PM +0100, Tim Bunce wrote:
> On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
> >
> > Reference counting is going to be a fun one, that's for sure.
> >
> > I'd like the interface to be something like:
> >
> >stat = perl_get_value(sv *, int what,
On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
>
> Reference counting is going to be a fun one, that's for sure.
>
> I'd like the interface to be something like:
>
>stat = perl_get_value(sv *, int what, &destination)
And what type is perl_get_value declared as returning?
I c
On Wed, Aug 02, 2000 at 05:03:34PM +0100, Tim Bunce wrote:
> Where we differ, I think, is that you expressed a desire for things like
> the SystemV IPC functions to be 'known' by perl in advance. I'm saying
> that we shouldn't have many, if any, pre-defined hooks to extensions.
>
> Let the 'use'
On Wed, Aug 02, 2000 at 02:58:37PM +0100, Graham Barr wrote:
> On Wed, Aug 02, 2000 at 02:56:54PM +0100, Alan Burlison wrote:
> > I don't think it is worth generating a RFE for this, but I'd like to see
> > the ability to relocate or install perl in some place other than the
> > initial install lo
On Wed, Aug 02, 2000 at 11:17:56AM -0400, Dan Sugalski wrote:
> At 12:11 PM 8/2/00 +0100, Tim Bunce wrote:
> >Thinking about that some more, I can imagine that...
> >
> >a) The 'use' of an 'interface definition' could optionally just define
> >stubs that will trigger the 'use' of a module to i
At 12:01 PM 8/2/00 +0100, Andy Wardley wrote:
>Nick:
> > PUSHMARK;
> > XPUSHs(sv_2mortal(newSVpv('DeepThought'));
> > XPUSHs(sv_2mortal(newSViv(42));
> > PUTBACK;
> > count = perl_call_method("Consider",G_EVAL);
> > SPAGAIN;
> > if (count >= 1) {
> > answer = SvIV(POPs));
> > }
> >
> >You _want_
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:11 PM 8/2/00 +0100, Tim Bunce wrote:
> >Thinking about that some more, I can imagine that...
> >
> >a) The 'use' of an 'interface definition' could
> optionally just define
> >stubs that will trigger the 'use' of a module to
> implement it wh
(Migrated from bootstrap)
2000-07-24-10:17:54 Dan Sugalski:
> Perl 6 will most *definitely* be an embedded perl. Easy and clean
> embedding is one of my primary goals. A small core with extended
> functionality provided by non-core things is a secondary one. (And
> one very much dependent on the
On Wed, Aug 02, 2000 at 11:11:32AM -0400, Andy Dougherty wrote:
> On Wed, 2 Aug 2000, Tim Bunce wrote:
>
> > Perl5 XS/GUTS is the way it is largely because it was designed with
> > performance in mind. I think Larry did a very good job. My only big
> > worry for perl6 is that, without great care
On Wed, Aug 02, 2000 at 11:29:40AM -0400, Dan Sugalski wrote:
> I was figuring the taint/notaint pragma would control taint checking, while
> -T would control taint setting. Probably not the best way--might be worth
> unconditionally setting the taint status so a use/no taint would do the
> rig
At 02:58 PM 8/2/00 +0100, Graham Barr wrote:
>On Wed, Aug 02, 2000 at 02:56:54PM +0100, Alan Burlison wrote:
> > I don't think it is worth generating a RFE for this, but I'd like to see
> > the ability to relocate or install perl in some place other than the
> > initial install location without ev
At 02:18 PM 8/2/00 +0100, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > From a language perspective, I have a scheme to allow us to yank all the
> > cruft (sockets, shm, messages, localtime...) out into separate libraries,
> > yet pull them in on demand without needing a use.
At 08:48 AM 8/2/00 -0400, Joshua N Pritikin wrote:
>On Wed, Aug 02, 2000 at 09:42:16PM +0900, [EMAIL PROTECTED] wrote:
> > On Wed, Aug 02, 2000 at 08:39:05AM -0400, Joshua N Pritikin wrote:
> > > Ah! PI is a great idea. Why not dump as much intelligence as possible
> > > into PI?
> >
> > Because
At 10:59 AM 8/2/00 -0400, Chaim Frenkel wrote:
>I wont comment on the rest.
>
>But Larry has already assigned/blessed 'our' for this usage. (vs. my for
>pure thread local lexical.)
I don't think Larry's weighed in on this one way or another lately.
My bet is thread-shared data will get a shared
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 the tainting st
At 12:11 PM 8/2/00 +0100, Tim Bunce wrote:
>Thinking about that some more, I can imagine that...
>
>a) The 'use' of an 'interface definition' could optionally just define
>stubs that will trigger the 'use' of a module to implement it when
>first called.
>
>b) An 'interface definition' coul
At 04:22 PM 8/2/00 +0900, Simon Cozens wrote:
>But even on purely selfish grounds,
>that's a very dumb idea - walking away from a community and forking its
>project is a really good way to get yourself hated, fast. (Ask Theo DeRaadt
>some time...)
I'll point out here that I, for one, don't mind p
Tim Bunce wrote:
>
> How does "use My::New:Regex;" differ from "use Foo::Bar;"?
>
> If a module is written to require "more crap that someone would have to
> install" then that's the way it's been written. That fact that that crap
> includes a new regex module is no different from that crap incl
On Wed, 2 Aug 2000, Tim Bunce wrote:
> Perl5 XS/GUTS is the way it is largely because it was designed with
> performance in mind. I think Larry did a very good job. My only big
> worry for perl6 is that, without great care, we'll loose that
> performance edge in the name of a 'clean API'.
Anoth
I wont comment on the rest.
But Larry has already assigned/blessed 'our' for this usage. (vs. my for
pure thread local lexical.)
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> =item *
BCW> The Thread module should add a C keyword or function that explicitly
BCW> access a va
http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
Dan Sugalski <[EMAIL PROTECTED]> writes:
> From a language perspective, I have a scheme to allow us to yank all the
> cruft (sockets, shm, messages, localtime...) out into separate libraries,
> yet pull them in on demand without needing a use.
a la dbmopen in perl5?
--
Piers
On Wed, Aug 02, 2000 at 02:56:54PM +0100, Alan Burlison wrote:
> I don't think it is worth generating a RFE for this, but I'd like to see
> the ability to relocate or install perl in some place other than the
> initial install location without everything breaking. This will require
> cleverness i
I don't think it is worth generating a RFE for this, but I'd like to see
the ability to relocate or install perl in some place other than the
initial install location without everything breaking. This will require
cleverness in the manipulation of the search paths for both perl modules
and shared
On Wed, Aug 02, 2000 at 09:42:16PM +0900, [EMAIL PROTECTED] wrote:
> On Wed, Aug 02, 2000 at 08:39:05AM -0400, Joshua N Pritikin wrote:
> > Ah! PI is a great idea. Why not dump as much intelligence as possible
> > into PI?
>
> Because it'll make using a source level debugger even more hell
> th
On Wed, Aug 02, 2000 at 08:39:05AM -0400, Joshua N Pritikin wrote:
> Ah! PI is a great idea. Why not dump as much intelligence as possible
> into PI?
Because it'll make using a source level debugger even more hell that it
is now.
--
!07/11 PDP a ni deppart m'I !pleH
On Wed, Aug 02, 2000 at 12:47:25PM +0100, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin <[EMAIL PROTECTED]> writes:
> >I've heard rumors about PI -- Perl Implementation language. What is it?
>
> Well PI is what Chip was calling his OO-in-C pre-processor before Topaz
> went C++. _I_ am using it as
Joshua N Pritikin <[EMAIL PROTECTED]> writes:
>I've heard rumors about PI -- Perl Implementation language. What is it?
Well PI is what Chip was calling his OO-in-C pre-processor before Topaz
went C++. _I_ am using it as a placeholder for whatever we end up using
as the source form.
I want to a
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 the tainting status, as well as the warning status, and so on)
>
On Wed, Aug 02, 2000 at 12:33:05AM -0600, Nathan Torkington wrote:
> Tim Bunce writes:
> > If people *want* to say "use My::New:Regex;" and have that install a
> > new regex implementation for that lexical scope then we should allow
> > that.
>
> I don't hear a good reason for why we'd want this.
Tim Bunce <[EMAIL PROTECTED]> wrote:
> So please, follow Chips wise lead, don't call your work Perl 6.
It's called Pickle.
"Andy Wardley" <[EMAIL PROTECTED]> wrote:
> Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful
> kinda way), but there's nothing to stop you from wrapping it
1 - 100 of 114 matches
Mail list logo
