Sam Tregar [EMAIL PROTECTED] wrote:
On Tue, 1 Aug 2000, John Tobey wrote:
The people here are rightly skeptical about the effectiveness of using
the 5.6 code base as a starting point for v6, but I have a pretty
clear vision of how to do it, and I am committed to giving it a try,
even
Bryan C. Warnock writes:
The librarian bounced, so sending this internals way.
Sorry about that bounce. It's set up now. I'm still setting
up the repository (should have done that *before* publishing the RFC
format, I guess :-). Optimistic ETA: tomorrow. If it's not up by
then, I'll fall
On Tue, Aug 01, 2000 at 06:10:53PM -0400, John Tobey wrote:
Nick Ing-Simmons [EMAIL PROTECTED] wrote:
By all means have a go at Topaz-II
But it won't be 'Perl 6' unless it implements what perl-language
decides that _is_.
Agreed. It won't even remotely resemble 'Perl 6' (as opposed
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 all up
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
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
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 location
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, destination)
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 what xemacs does"
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
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
impact
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 decide. What,
[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 affected by
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
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.
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
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):
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
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?
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.html
=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
=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
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
right
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
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 reading for
hi,
As the news that the Perl will be rewriten comes... me and I think many
others non core coders decided that they can help with something but
most of the people like me doesn't have the knowledge of the current
PERL5.6, why we may need this ?! 'cause Perl6 is 2 years from "here" and we
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
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 fact,
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
On Tue, Aug 01, 2000 at 09:25:33PM +, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
No, I disagree. Perl gains a lot of its expressive power from being lax
about typing. I suspect it will also impose an unacceptable overhed for
the vast majority who don't want it -
On Tue, Aug 01, 2000 at 10:47:24PM +0100, Alan Burlison wrote:
I suspect reorganising the data structures to be cache
friendly would gain more benefit than avoiding a few inline bit
twiddles.
We should do both.
Tim.
"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
http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
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 status,
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 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 fact,
36 matches
Mail list logo
