I wrote:
>
> Nick Ing-Simmons wrote:
> >
> >
> > I see no reason why the perforce changes cannot be 'checked in' to CVS
> > one-by-one so that CVS builds its own representation of the change history.
>
> I've got this working now in a program called 'vcp', I need to test
> p4->cvs updates using
> POD should tolerate white space where it now requires empty lines
[...]
> =head1 IMPLEMENTATION
>
> Seems like it should be just a regexp stuck in somewhere
I think this is a specific problem calling for a more general solution.
I can think of two possible ones:
1. A standard library func
On 13 Sep 2000, Piers Cawley wrote:
> Hildo Biersma <[EMAIL PROTECTED]> writes:
>
> > Piers Cawley wrote:
> > I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
> > same time.
>
> Well you can't. The patch that I pinched this RFC from is a lexically
How about if w
On Tue, Sep 12, 2000 at 05:16:17AM +0100, Hugo wrote:
> :Simply put, I want variable-length lookbehind.
>
> The difficulty with variable-length lookbehind (let's call it
> VLLB) is this: suppose that we want to match "abcdef...xyz" =~
> /(?<=x+)y/. In theory, to check the possible /x+/ matches in
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standardize ALL Perl platforms on UNIX epoch
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last-Modified: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 99
V
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Handlers and Pseudo-classes
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 101
Version: 2
Piers Cawley wrote:
> =head1 ABSTRACT
>
> The behaviour of the syntax should simply be an
> assertion of the invariant:
>
>(!defined($spot) || (ref($spot) $spot->isa('Dog)))
Apart from the buglet that Damian pointed out, agree.
Instead of an implementation based on tie, I'd rather define
Piers Cawley wrote:
> =head1 ABSTRACT
>
> Cnew>
> is a pain in the bum to type. We should replace this with
>
> use namespace 'Big::Long::Prefix';
> my ::Class $object = ::Class->new;
This is a bit dangerous, since we can get into ambiguities again.
If I have A::B::C::Foo, A::B::C::Bar
On Wed, 13 Sep 2000 08:37:57 +0100, Hildo Biersma wrote:
>> Make length(@array) work
>
>Counter-proposal: make length(@array) a syntax error. I don't feel like
>rewarding stupidity, I'd rather teach people how to do things properly.
Indeed. What about lists?
print length(qw(a b c));
Sh
Ken Fox <[EMAIL PROTECTED]> writes:
>Dan Sugalski wrote:
>> For something like:
>>
>>@foo = @bar || @baz;
>>
>> I have no problem with the call sequence looking like (pseudo-codish here):
>>
>> set_context(ARRAY, ASSIGN);
>> foo->store(bar->log_or(bar, baz));
>
>But log_or must shor
2000-09-13-03:29:16 Hildo Biersma:
> Some would argue that a better design is required. Apache 2.0 will
> use a mixed thread/process model, and mod_perl 2.0 will run
> selected threads within one process, precisely to alleviate these
> problems. So it's not necessarily perl's fault...
Some would
To cut down on traffic, I merged all my responses to Russ together. If you
don't like it, well, tough. :-)
At 20:29 -0700 2000.09.12, Russ Allbery wrote:
>What if you make your changes available only if someone signs a
>non-disclosure agreement?
That would be pretty silly, since the recipient
Russ Allbery writes:
>The entire point and *purpose* of a lawyer specializing in contract law is
>to write clearly. They're not writing clearly for the average reader,
>necessarily; that requires a whole different type of phrasing. They're
>writing clearly for the interpretation of the contract
Ben Tilly wrote:
>
>OK, IANAL, nor do I pretend to any amazing expertise. Should
>this hold up legally, I will probably be the most astounded here.
>(I have not even reviewed for typos!) But at least it gives people
>something specific to argue over.
I would have been astounded with good reason.
Go through a few versions of Perl and read the copy of the
Artistic License you see. It changes. There is simply no
way that Larry OKed each change with the copyright holders,
and so there is simply no way that he actually had the
authority to make those changes.
I noticed this when an old Debi
OK, IANAL, nor do I pretend to any amazing expertise. Should
this hold up legally, I will probably be the most astounded here.
(I have not even reviewed for typos!) But at least it gives people
something specific to argue over.
I will annotate it later if I get time and energy. For now let
me n
> On Tue, 12 Sep 2000 19:01:35 -0400, Mark-Jason Dominus wrote:
>
> >I don't know what you mean, but you're mistaken, because it means to
> >interpolate @foo as in a double-quoted string.
>
> Which is precisely the meaning he wants for it, with $" set to '|'.
"Which is precisely the meaning he
Bart Lateur writes:
> Indeed. What about lists?
>
> print length(qw(a b c));
>
> Should this return 3?
It prints what this would print:
$x = qw(a b c);
print length $x;
The parser will check the first character of length's argument. If
it's an @ sign, then it calculates the length
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> Make length(@array) work
Perl6> I propose to make length() return the number of elements in the array
Perl6> it is passed, if its first argument begins with @.
This proposal makes length() an un-prototypable (and therefore
[added -io cross-post]
John Porter wrote:
>
> Just MHO, but I don't think this is the kind of thing that should
> go in the core. Just MHO.
I think I agree. Just to clarify, the only reason it's an RFC and not
just a Perl 5 module is because RFC 14 (the one on a new open()) relies
on a handler
Piers Cawley wrote:
>
> > This is a bit dangerous, since we can get into ambiguities again.
> > If I have A::B::C::Foo, A::B::C::Bar, X::Y::Z::Foo and X::Y::Z::Bar,
> > I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
> > same time.
>
> Well you can't. The patch that I pinc
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers wrote:
>
>> The behaviour of the syntax should simply be an
>> assertion of the invariant:
>>
>>(!defined($spot) || (ref($spot) $spot->isa('Dog)))
>
> (!defined($spot) || (ref($spot) && $spot->isa('Dog')))
>
>
>
> A module may remain the best implementation for this, the only problems
> are with speed (since the Perl 5 version requires AUTOLOAD) and also
> using this mechanism for core methods (like the new C from RFC 14).
Just MHO, but I don't think this is the kind of thing that should
go in the core.
Hildo Biersma <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> > =head1 ABSTRACT
> >
> > Cnew>
> > is a pain in the bum to type. We should replace this with
> >
> > use namespace 'Big::Long::Prefix';
> > my ::Class $object = ::Class->new;
>
> This is a bit dangerous, since we can ge
Jeremy Howard wrote:
>
> 148: Change to Numeric Python semantics of reshape(), or write counter-RFC
> specifying these semantics (preferably renaming this RFC's 'reshape' to
> something else)
> I'm happy to work on 204, 82, 90/91, and 148 (Nate--I don't think we've
> resolved this one yet...).
Note that I am not necessarily asking for any specific rebuttal; I am
noting what I think are problems with the RFC here. So where I ask
questions, we can discuss them here, but I am primarily asking that the
clarifications be made for the RFC, not to me.
At 7:04 + 2000.09.13, Perl6 RFC Lib
Bradley M. Kuhn wrote:
>
>Ben Tilly wrote:
> > 4. The names of the contributers to this package may not be used to
> > endorse or promote products derived from this software without specific
> > prior written permission.
>
>Lawyers typically point out that this issue is not covered by copyright
>
Nick Ing-Simmons wrote:
>
>Ben Tilly <[EMAIL PROTECTED]> writes:
> >
> >You were claiming that you don't care what people do as
> >long as they were not calling it Perl. My point above
> >is that the only situation I am interested in involves
> >people distributing what they call Perl.
> >
> >You
Russ Allbery wrote:
> Chris Nandor <[EMAIL PROTECTED]> writes:
>
> > The Package must ALWAYS be distributed under the same licensing terms as
> > the original. Unless it is public domain or you are the copyright
> > holder, you cannot change the licensing terms.
>
> Not true, as far as I know.
Chris Nandor wrote:
> Remember, we are trying to break the AL here, and I don't see this as
> significant brokenness. I said from the beginning that the AL could be
> cleaned up, but I am interested here in trying to break the existing one.
RFC 211, which was published after Chris wrote this,
Bradley M. Kuhn wrote:
>
>Russ Allbery wrote:
> > Chris Nandor <[EMAIL PROTECTED]> writes:
> >
> > > The Package must ALWAYS be distributed under the same licensing terms
>as
> > > the original. Unless it is public domain or you are the copyright
> > > holder, you cannot change the licensing ter
Ben Tilly wrote:
> 4. The names of the contributers to this package may not be used to
> endorse or promote products derived from this software without specific
> prior written permission.
Lawyers typically point out that this issue is not covered by copyright law,
and it isn't worth putting stat
Nick Ing-Simmons wrote:
>
>Ben Tilly <[EMAIL PROTECTED]> writes:
> >> >3. The current AL probably does not convey the above in terms
> >> > acceptable to lawyers and it is worth making it do so.
> >> >Can we all agree on these points?
> >>
> >>No. I disagree with #3.
> >
> >May I ask what part
From: Hugo <[EMAIL PROTECTED]>
Sent: Tuesday, September 12, 2000 2:54 PM
> 3. The regexp is matched left to right: first the lookbehind, then 'X',
> then '[yz]'.
Thanks for the insight - I was stuck in my bad assumption that the optimized
behavior was the only behavior.
What I am not sure of is
>Thinking about the comparision between the two RFCs there is some common
>ground, but cases where people will want your hash and cases where
>people will want explicit variables. Using RFC 112, you can do
>hash assignment, but it would not clear the hash beforehand whereas
>your hash assignment
On Wed, 13 Sep 2000, Hildo Biersma wrote:
> > =head1 TITLE
> >
> > Make length(@array) work
>
> Counter-proposal: make length(@array) a syntax error. I don't feel like
> rewarding stupidity, I'd rather teach people how to do things properly.
As a general rule, I agree with Hildo tha
Today around 9:38am, Dave Storrs hammered out this masterpiece:
: On Wed, 13 Sep 2000, Hildo Biersma wrote:
:
: > > =head1 TITLE
: > >
: > > Make length(@array) work
: >
: > Counter-proposal: make length(@array) a syntax error. I don't feel like
: > rewarding stupidity, I'd rather teach people
Casey R. Tweten writes:
> Leave length() the way it is now and, if one so desires, they may
> override it on there own to use length for getting:
Not that helpful a suggestion for beginners. They don't know how to
override, or often even how to load a module. The point is not that
there's alrea
Nathan Torkington wrote:
>
> I think we're going to have to see prototypes extended to cope with
> functions like this, anyway. I'll mention this requirement in the
> next version of the RFC.
Brainstorming off the top of my head:
sub length (($|@)) {
}
That is, use a regex-like "(x|y)"
Nathan Wiger writes:
> Brainstorming off the top of my head:
>
>sub length (($|@)) {
>
>}
>
> That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
> context coercions.
The only RFC on prototype extensions we have is Andy Wardley's #57.
I suggest you ask him to add th
Randal L. Schwartz writes:
> Perl6> I propose to make length() return the number of elements in the array
> Perl6> it is passed, if its first argument begins with @.
>
> This proposal makes length() an un-prototypable (and therefore
> unoverridable). Do you have a proposal for how to handle that
Today around 12:01pm, Nathan Torkington hammered out this masterpiece:
: Casey R. Tweten writes:
: > Leave length() the way it is now and, if one so desires, they may
: > override it on there own to use length for getting:
:
: Not that helpful a suggestion for beginners. They don't know how to
Casey R. Tweten writes:
> Ok, consider allowing:
>
> $a = length @b;
>
> to DWIM, however, when running with warnings, warn the user that C is
> what they really want.
>
> Just thowing that out there.
Good idea, but I think it's a bad move to turn warnings into style
guides. Warnings should
Today around 12:19pm, Nathan Torkington hammered out this masterpiece:
: Casey R. Tweten writes:
: > Ok, consider allowing:
: >
: > $a = length @b;
: >
: > to DWIM, however, when running with warnings, warn the user that C is
: > what they really want.
: >
: > Just thowing that out there.
:
Randal L. Schwartz writes:
> This proposal makes length() an un-prototypable (and therefore
> unoverridable). Do you have a proposal for how to handle that?
Do we really want everything in Perl to be overridable? What
use is an overridden length()?
Nat
Today around 11:18am, Nathan Torkington hammered out this masterpiece:
: Randal L. Schwartz writes:
: > This proposal makes length() an un-prototypable (and therefore
: > unoverridable). Do you have a proposal for how to handle that?
:
: Do we really want everything in Perl to be overridable?
On Wed, Sep 13, 2000 at 08:32:08AM -0700, Randal L. Schwartz wrote:
> > "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
>
> Perl6> Make length(@array) work
>
> Perl6> I propose to make length() return the number of elements in the array
> Perl6> it is passed, if its first argument
one of the purposes of perl6-meta is to keep us crazies out of the way of
the developers hope so anyway
mike
Mike Lacey writes:
> one of the purposes of perl6-meta is to keep us crazies out of the way of
> the developers hope so anyway
Oh no, I'm busted! :-)
Nat
Ben Tilly <[EMAIL PROTECTED]> writes:
>
>You were claiming that you don't care what people do as
>long as they were not calling it Perl. My point above
>is that the only situation I am interested in involves
>people distributing what they call Perl.
>
>You are clearly not even trying to respond t
Russ Allbery <[EMAIL PROTECTED]> writes:
>
>The entire point and *purpose* of a lawyer specializing in contract law is
>to write clearly. They're not writing clearly for the average reader,
>necessarily; that requires a whole different type of phrasing. They're
>writing clearly for the interpret
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>=head3 Bruce Perens
>
>Bruce Perens, while a member of Open Source Initiative (OSI), stated:
>
>Section 5 of the Artistic License prohibits sale of the software,
>yet allows
>an aggregate software distribution of more than one program to be sold.
Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>
>I don't think this is completely out the question, either. I was actually
>planning on writing an RFC that proposes that all contributions to the core
>be copyright assigned to Larry.
Well if that becomes a requirement I will have to stop contribu
The Perl6 RFC Librarian quoth:
>
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>The Artistic License Must Be Changed
[...]
Please add some reference to the fact that over the course of
Perl's history it was changed, and therefore there is now some
Ben Tilly <[EMAIL PROTECTED]> writes:
>> >3. The current AL probably does not convey the above in terms
>> > acceptable to lawyers and it is worth making it do so.
>> >Can we all agree on these points?
>>
>>No. I disagree with #3.
>
>May I ask what part you disagree with?
>
>That it is probably
Chris Nandor <[EMAIL PROTECTED]> writes:
>>Perhaps; it depends on how clear the AL already is. :) If it's already
>>quite clear in English, if not in legal terms, then a lawyer starting from
>>it should come up with something pretty close to what everyone wants.
>
>But my point is that I don't w
Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>
>(Think of it as writing a Last Will and Testament---you can do it on your
> own in a pinch, but it's always better to write a draft and then have a
> lawyer help you rewrite it so it's more legally sound, because it is more
> likely to DWYM when it g
At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
>2. (RFC 99 way): If you store the time from within a perl program and
>then read it with a C program on the SAME OS, then you might have a
>problem.
That is what Time::Epoch should address, I hope.
If we standardize on the Unix epoch (although
On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
> Currently, internal time in Perl is maintained via C, which is
> highly system-dependent. On some systems, this is relative to the UNIX
> epoch, while others use their own epochs (MacPerl uses 1904, for
> example).
>
> All ver
At 5:34 -0400 2000.09.13, Michael G Schwern wrote:
>On Wed, Sep 13, 2000 at 07:10:30AM -, Perl6 RFC Librarian wrote:
>> Currently, internal time in Perl is maintained via C, which is
>> highly system-dependent. On some systems, this is relative to the UNIX
>> epoch, while others use their own
On Wed, 13 Sep 2000, Michael G Schwern wrote:
> > All versions of Perl on all platforms should maintain time both
> > internally and externally as seconds since the UNIX epoch (00:00:00 01
> > Jan 1970 UTC).
> Color me obvious, but could you discuss some of the practical
> situations where this
John Porter wrote:
> Mark Dominus <[EMAIL PROTECTED]>:
> >
> > This behavior should be changed. If the PATTERN is empty, Perl should
> > look for the empty string. (That is, if the PATTERN is empty, it
> > should always match.)
>
> Except perhaps for undef loperands? (matchees? bindees?)
Wh
On Wed 13 Sep, Bart Lateur wrote:
> On Tue, 12 Sep 2000 19:01:35 -0400, Mark-Jason Dominus wrote:
>
> >I don't know what you mean, but you're mistaken, because it means to
> >interpolate @foo as in a double-quoted string.
>
> Which is precisely the meaning he wants for it, with $" set to '|'.
>
On Wed, Sep 13, 2000 at 07:41:01AM -0400, Barrie Slaymaker wrote:
> Some progress. Below is the cvs log from perl.c for the first 800 and some
> changes. There's a few bugs to work out yet (including the one in VCP::Dest::cvs
> that crapped out at change 871, but you get the idea. It's also not
> "Casey" == Casey R Tweten <[EMAIL PROTECTED]> writes:
Casey> I agree with this line of thinking, however, I suppose I don't
Casey> agree with implementing length in this way since we already
Casey> have C.
Casey> In that light, if C is to replace scalar for, we'll
Casey> say, LISTs, then l
Simon Cozens wrote:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really* like
> > to see the parser/front-end in Perl. There are dozens of RFCs that require
> > some non-trivial extensions to the parser. It would be nice
At 07:09 AM 9/13/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Emit warnings and errors based on unoptimized code
Yay! I'd add, in V2, that:
"Perl should report the *real* line an error took place in for those
statements that span multiple lines"
So if you do:
#! perl -w
my $foo
At 09:50 PM 9/12/00 +0100, Simon Cozens wrote:
>On Tue, Sep 12, 2000 at 04:55:02PM -0400, Dan Sugalski wrote:
> > > Are there any better reasons than "It would be nice?"
> > It'd make things easier? (I'd rather write a parser in perl than C...)
>
>You're going to have to do it some time, for boots
At 03:02 PM 9/12/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > For something like:
> >
> >@foo = @bar || @baz;
> >
> > I have no problem with the call sequence looking like (pseudo-codish here):
> >
> > set_context(ARRAY, ASSIGN);
> > foo->store(bar->log_or(bar, baz));
>
>But log_o
At 03:49 PM 9/13/00 +, John van V wrote:
>I'm really entranced by the prospect of sending frozen structures
>including anonymous subs to to remote devices like out on Mars or Pittsburgh.
With full lexical scope along with it? You're not alone... :)
Da
Simon Cozens writes:
> > Nice!
> Efficient!
> Practical!
>
> Choose two.
I take this oblique comment to mean that it'd bloat the op-tree too
much?
I was thinking of this over lunch. I want to be able to strip the
instruction sequence of line number, package, etc. information, in the
name of a
At 10:07 AM 9/13/00 -0400, Bennett Todd wrote:
>2000-09-13-03:29:16 Hildo Biersma:
> > Some would argue that a better design is required. Apache 2.0 will
> > use a mixed thread/process model, and mod_perl 2.0 will run
> > selected threads within one process, precisely to alleviate these
> > proble
Dan Sugalski writes:
> It's possible, for example, for a tied/overloaded/really-darned-strange
> variable to look true but still be false. If you do:
>
>$foo = $bar || $baz;
>
> and both $bar and $baz are objects, the 'naive' way is to make $foo be
> $bar. But it's distinctly possible that
At 02:20 PM 9/13/00 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I wouldn't worry about this too much. If it's all keyed off an opcode of
> > some sort ("Current line info"), we could easily just strip those opcodes
> > out. They won't take up that much space relative to the rest of t
At 03:56 PM 9/13/00 -0400, Ken Fox wrote:
>Nick Ing-Simmons wrote:
> > Ken Fox <[EMAIL PROTECTED]> writes:
> > >Dan Sugalski wrote:
> > >> For something like:
> > >>
> > >>@foo = @bar || @baz;
> > >>
> > >> I have no problem with the call sequence looking like (pseudo-codish
> here):
> > >>
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 130
Vers
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
>
> I was thinking of this over lunch. I want to be able to strip the
> instructio
Nick Ing-Simmons wrote:
> Ken Fox <[EMAIL PROTECTED]> writes:
> >Dan Sugalski wrote:
> >> For something like:
> >>
> >>@foo = @bar || @baz;
> >>
> >> I have no problem with the call sequence looking like (pseudo-codish here):
> >>
> >> set_context(ARRAY, ASSIGN);
> >> foo->store(bar->l
Dan Sugalski writes:
> I wouldn't worry about this too much. If it's all keyed off an opcode of
> some sort ("Current line info"), we could easily just strip those opcodes
> out. They won't take up that much space relative to the rest of the
> program, but I can see some sort of runtime overhead i
On Wed, 13 Sep 2000, Chris Nandor wrote:
> At 14:30 -0400 2000.09.13, Andy Dougherty wrote:
> >2. (RFC 99 way): If you store the time from within a perl program and
> >then read it with a C program on the SAME OS, then you might have a
> >problem.
>
> That is what Time::Epoch should address, I
At 16:04 -0400 2000.09.13, Andy Dougherty wrote:
>> If we standardize on the Unix epoch (although possibly with 64 bits), this
>> won't be an issue for the overwhelming majority of users.
>
>Are you sure? Won't this affect Windows as well as Mac users? There are
>an awful lot of Windows users.
Michael G Schwern <[EMAIL PROTECTED]> writes:
> And if we're going to standardize on something, let's squeeze as much
> out of this as possible. signed 64 bit integer and microseconds. (I
> think that's another RFC)
I think it should be specified that the return value is seconds since Unix
epo
At 09:49 AM 9/13/00 +1200, Christian Soeller wrote:
>It's probably just me but I thought (1) just creating an object leaves
>me handing around scalars
That's likely not to be the case in p6. You should be able to overload the
operations for arrays and hashes, and ought to be able to do objectish
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > 148: Change to Numeric Python semantics of reshape(), or write
counter-RFC
> > specifying these semantics (preferably renaming this RFC's 'reshape' to
> > something else)
>
> There are a couple things that the NumPy one lacks that RFC 148
> curr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More defaulting to $_
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 10 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 215
Version:
On Wed, 13 Sep 2000, Michael G Schwern wrote:
...many good points, all of which I should have known. :-(
I will modify the RFC to reflect that /\bshell\b/i is a poor name, due
to the current Shell module.
Personally, I don't particularly care what it's called - after all, I
don't name things ve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
POD needs a reorder command.
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 217
Version: 2
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
wait() and waitpid() should return false on failure
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 13 2000
Mailing List: [EMAIL PROTECTED]
Number: 220
Version: 1
Sta
Damian Conway wrote:
>
> What you want is:
>
> %newhash = map {yield $_; transform($_)} %oldhash;
>
> This flattens the %oldhash to a sequence of key/value pairs. Then the
> first time the map block is called (i.e. on a key) it immediately
> returns the key. The second time, it resumes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
system() should return useful values
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 13 2000
Mailing List: [EMAIL PROTECTED]
Number: 221
Version: 1
Status: Developing
Imagine the following scenario: your script contains a doiuble-quotish
40 line here-doc, with a bunch of variables in it. Unforetunately, you
forgot to set one, and you get the not so helpful complaint:
use of unitialized value at line xxx
where xxx is the line number for the line that c
On Wed, Sep 13, 2000 at 10:49:41PM +0200, Bart Lateur wrote:
> Imagine the following scenario: your script contains a doiuble-quotish
> 40 line here-doc, with a bunch of variables in it. Unforetunately, you
> forgot to set one, and you get the not so helpful complaint:
>
> use of unitialize
At 10:49 PM 9/13/00 +0200, Bart Lateur wrote:
>Imagine the following scenario: your script contains a doiuble-quotish
>40 line here-doc, with a bunch of variables in it. Unforetunately, you
>forgot to set one, and you get the not so helpful complaint:
>
> use of unitialized value at line x
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq().
I have wanted that also, although I don't remember why ju
On Wed, 13 Sep 2000 13:56:53 -0700, Peter Scott wrote:
>I would rather solve this by requiring that Perl identify the thing that
>was undef than what you propose below. Surely it can't be that hard.
Fine by me.
Only, AFAIK, Perl is only aware of "values", not of "variables".
--
Bart
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 11 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 2
Status: Dev
Perl6 RFC Librarian writes:
> I therefore propose that C comes to mean that C<$spot>
> is restricted to being either undefined or a reference to a C
> object (or any subclasses of Dog). Simply having this implicit
> assertion can be useful to the programmer, but I would argue that its
> main advan
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C is just an assertion
=head1 VERSION
Maintainer: Piers Cawley <[EMAIL PROTECTED]>
Date: 13th September 2000
Mailing List: [EMAIL PROTECTED]
Number: 218
Version: 1
Status: Developing
=head1 ABS
The Perl6 RFC Librarian quoth:
>
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>Perl6's License Should Be a Minor Bugfix of Perl5's License
[...]
This resolves very few of the IMHO rather serious issues I
have found with the current license. The
> > This proposal makes length() an un-prototypable (and therefore
> > unoverridable). Do you have a proposal for how to handle that?
>
> Pray to Damian for a prototype that supports this? :-)
If you'd been studying the holy writings properly, young Torkington,
instead of those wick
1 - 100 of 202 matches
Mail list logo
