On Wed, Sep 13, 2000 at 11:20:46PM -0700, Nathan Wiger wrote:
[snippity-snip]
> I just think it's a case of "crying wolf", especially when other
> people's CPAN modules start spewing this stuff out from perfectly
> reasonable code, filling up your web error logs with "uninitialized this
> and th
Michael G Schwern wrote:
> On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
> (3)
> > obtain one or more data handles for test input data and validation data, (4)
> > compile 1&2 as perl source code, and (5) launch the tests, which can then
> > used the appropriate data handles.
>
Nathan Wiger wrote:
> I don't know about this. What if someone writes:
>
>print "You owe me $2, $name.\n";
>
> With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
>You owe me $2, Nate.
>
> But without it it won't?
>
>You owe me , Nate.
You turn
On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
> This RFC also seems to be related to RFC 183... using POD for testing. Now
> the model of use apparently envisioned for RFC 183 is to have the tests
> inside the POD, and then use a preprocessor to hack them out and put them in
>
> > This would HAVE to be a very optional feature. I rely on undef
> > converting to a null string in many, many programs.
>
> Surely in those programs you don't have -w turned on, because you wouldn't
> want to see all those warning messages. So here is another idea: -w causes
> string interpol
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's
some to
start it. Please copy me on the discussion. Sorry for cross posting,
but
this is attempting to unify RFCs from different lists; I've bcc'd two of
th
On Wed, Sep 13, 2000 at 11:16:47PM -0400, Barrie Slaymaker wrote:
> Adam Turoff wrote:
> > Well, use CVS, not su.
>
> the su was for when not using the pserver, since I'm not sure whether CVS uses
> your UID, or some environment variable to grab your user name when not using
> the pserver.
Oh, t
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace
Nathan Torkington wrote:
>
> Tee hee! The point of the warning is to tell you that you should be
> checking it and aren't. You're assuming the variable has a value,
> because you are treating it like a string. But the variable doesn't
> have a value. This is probably an error.
For me it's no
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > RFC 203 defines a :bounds attribute that defines the maximum index of
each
> > dimension of an array. RFC 206 provides the syntax @#array which returns
> > these maximum indexes. For consistancy, the arguments to reshape()
should be
> > the maximu
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's some to
start it. Please copy me on the discussion. Sorry for cross posting, but
this is attempting to unify RFCs from different lists; I've bcc'd two of th
I'm not on -io, so copy me on discussion. But this RFC was intriguing, so I
read the discussion on the archive for it, and have the following comments.
Perl6 RFC Librarian wrote:
>format FILE =
> @<: @
> $name, $ssn
> .
> =head2 New Syntax
>
> Under the new syntax, a f
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> One other that might be useful is have strftime() (or something similar)
> built-in without having to use POSIX; and the default should be
> MMDDHHMMSS.fff, (the ISO format)
The more commonly-used ISO format is the extended format rather than t
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Every compile-time check comes at the cost of a run-time freedom,
NT> though. All bets would be off if you modified @ISA, reblessed, or
NT> passed objects through non-strict-types-compliant code. Polymorphic
NT> types also becomes
Damian Conway writes:
> Either you give up interface polymorphism (a grievous loss) or you give
> up static type-checking.
Blech, you're right.
> Actually, it's inheritance polymorphism that proliferates pretend classes
> like Pet.
I meant that. Sorry, you're so in tune with Perl that I'm star
> "AD" == Andy Dougherty <[EMAIL PROTECTED]> writes:
AD> In my humble opinion, I think perl's time() ought to just call the C
AD> library's time() function and not waste time mucking with the return
AD> value. Instead, if the time is to be stored externally for later use by
AD> another progr
Eric Roode wrote:
> >Imagine that you could easily override the conversion of undef() into a
> >string, so that when stringified it returns something like "#UNDEF#"
> >instead of just an empty string. That would make debugging far more
> >easy: take a look at the output, and search for this senti
Ken Fox writes:
> The dogfood theory? One of the design goals for Perl is to make text
> munging easy. Parsing falls into that category and therefore we should
> use it, i.e. eat our own dogfood.
How about this. During design, we try to make the parser a module
with an interface designed so that
> I was hoping Damian would be able to suggest a Perlish way of handling
> typechecking and polymorphism.
If you mean static typechecking, then it is the natural enemy of polymorphism.
Either you give up interface polymorphism (a grievous loss) or you give
up static type-checking.
>
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> I take this oblique comment to mean that it'd bloat the op-tree too
NT> much?
NT> I was thinking of this over lunch. I want to be able to strip the
NT> instruction sequence of line number, package, etc. information, in the
NT> name
Nathan Wiger writes:
> > Polymorphic
> > types also becomes a problem: how to say that it's okay for a variable
> > to hold a Dog *or* a Cat, because we know that both of them have a
> > "pet()" method?
>
> Seems in order to satisfy this you'd have to have a common ancestor,
> Pet, which Dog and
Well I sat down, thought carefully about it, and reorganized
my proposed license along the same lines that I would organize
a config file. Instead of enumerating what is allowed, deny
this, deny that, deny the other, allow everything else. I
think that this is a good way to rewrite it.
It means
Chaim Frenkel writes:
> Somehow I find
> if (40 == ($foo = substr($bar, index($bar, 'xyz' {
> }
I don't understand your hypothetical code. substr() returns the
substring of $bar from the position retutned by index, onward.
When would this be 40, if index is going to return the po
"Randal L. Schwartz" wrote:
>
> I think we need a distinction between "looping" blocks and
> "non-looping" blocks. And further, it still makes sense to
> distinguish "blocks that return values" (like subroutines and map/grep
> blocks) from either of those. But I'll need further time to process
Nathan Wiger writes:
>print "Welcome back, $first $middle $last!\n";
>
> My question: What good is this warning in most contexts, anyways?
> Really. Honestly. If you cared about the value, you would already be
> checking it, right? Probably with something like this:
>
>die "Fatal: Can't
Jeremy Howard wrote:
>
> RFC 203 defines a :bounds attribute that defines the maximum index of each
> dimension of an array. RFC 206 provides the syntax @#array which returns
> these maximum indexes. For consistancy, the arguments to reshape() should be
> the maximum index of each dimension. A ma
Adam Turoff wrote:
>
> On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> > Adam Turoff wrote:
> > > > Feedback welcome.
> > >
> > > I noticed that CVS reports this as part of the version logs:
> > >
> > > date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
> >
Nathan Torkington wrote:
>
> Turning Perl into a nagging harpie means that the really important
> warnings will be ignored.
>
> This line of thinking brought to you by Mark-Jason's excellent talk
> on data typing.
I agree, and just read MJD's paper the other day (nice job, BTW), but
unfortunate
Hugo wrote:
> 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
> the right order [0] we need to check whether there we can match
> 0 characters at offset 0 (
Jeremy Howard wrote:
> the maximum index of each dimension. A maximum index of '0' would mean that
> that dimension is 1 element wide. Therefore '0' can not be special in
> reshape(). Therefore we should use '-1'.
-1 is the maximum index for any size in the usual fashion of perl array
indexing.
On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> Adam Turoff wrote:
> > > Feedback welcome.
> >
> > I noticed that CVS reports this as part of the version logs:
> >
> > date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
>
> Yup: not sure how to orchestrate
> use namespace 'Big::Long::Prefix';
> my ::Class $object = ::Class->new;
Anyone mentioned that this:
$SHORT = 'Some::Huge::Obnoxious::Ridiculous::Term';
$SHORT->member;
$stuff = new $SHORT;
Already works? The only problem is that this:
$SHORT::stuff(@args);
Doesn't, but t
> > rather use a transpose() function for this that can transpose across a
given
> > axis.
>
> You'll be RFC'ing that, I suppose? ;-) (But seriously, it sounds like a
> good idea)
>
Yes, I will.
> > I don't think we need to define the ability to work on multiple lists as
> > special behaviour. Pe
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> Would it be reasonable to ask that passing undef into the offset
>> or start of substr have substr return an undef?
NT> Wouldn't you get a warning anyway, if you were treating undef like
NT> a number?
Aha, but I don't want a warning
On Wed, Sep 13, 2000 at 08:43:43PM -, Perl6 RFC Librarian wrote:
> The behaviour of the syntax should simply be an
> assertion of the invariant:
>
>(!defined($spot) || (ref($spot) && $spot->isa('Dog)))
What about the current behavior of typed pseudohashes?
package Dog;
use fie
Adam Turoff wrote:
>
> > Feedback welcome.
>
> I noticed that CVS reports this as part of the version logs:
>
> date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
Yup: not sure how to orchestrate logging in to the server as different usernames,
or su'ing to be different user
On Wed, Sep 13, 2000 at 08:42:28PM -, Perl6 RFC Librarian wrote:
> Actually, some days I wish "C" meant "print nothing." I was tempted
> to title this RFC "Make C and <> consistent."
Color me stupid, but if you wanted to print nothing, shouldn't you
just delete the print statement? Unless y
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
Perl contains two files which contain the infamous BSD
advertising clause. This means that Perl cannot technically
be distributed under the GPL. The files in question are:
ext/SDBM_File/sdbm/dbm.h
ext/SDBM_File/sdbm/dbm.c
Currently Perl's documentation is *NOT* in compliance with
this clau
Nathan Torkington wrote:
>
> Yes! I mentioned the hypothetical
> use strict 'types';
> which would require all variables assigned to/from an object, and
> all variables upon which method calls are made, to be typed like
> this. Then the compiler can:
> (a) optimize
> (b) check at compile-ti
Jeremy Howard wrote:
>
> That looks good, except that I'd remove the interleaving. Currently, it's
> not clear how to reshape() to more than 2 dimensions, because the third
> argument of the first list ref is the interleave flag. We should be able to
> be able to reshape to any number of dimensio
> Who has time to read all the crap you write, Damian? :-)
Indeed. ;-)
> Sorry I missed that one. Thanks for pointing it out.
I've just submitted an updated version which will probably hit the
archive in the next few hours. For those who can't wait, the latest
versions of all my RFCs are
Damian Conway writes:
> If you'd been studying the holy writings properly, young Torkington,
> instead of those wicked magazines under your bed, you'd be familiar with
> RFC 128, specifically:
>
> http://tmtowtdi.perl.org/rfc/128.html#Context_classes
Who has time to read all the crap you w
>Imagine that you could easily override the conversion of undef() into a
>string, so that when stringified it returns something like "#UNDEF#"
>instead of just an empty string. That would make debugging far more
>easy: take a look at the output, and search for this sentinel string.
This would HAV
> foreach @bigarray {
> sub {
> yield (push @array1, $_);
> yield (push @array2, $_);
> yield (push @array3, $_);
> push @array4, $_;
> }->();
> };
>
> :-)
As I've said before, Randal, you're a bad, bad man.
Of co
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
>> foreach @bigarray {
>> yield (push @array1, $_);
>> yield (push @array2, $_);
>> yield (push @array3, $_);
>> push @array4, $_;
>> };
Damian> Except that C is like C and breaks out of the current
Damian> *subroutine*, not the current
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C<$!>, C<$^E>, C<$@> and C<$?>
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
N
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last-Modified: 13 Sep 2000
Mailing List: [EMAIL PROT
>foreach @bigarray {
>yield (push @array1, $_);
>yield (push @array2, $_);
>yield (push @array3, $_);
>push @array4, $_;
>};
Except that C is like C and breaks out of the current
*subroutine*, not the current block.
Damian
> The only RFC on prototype extensions we have is Andy Wardley's #57.
Except, of course for #128, which already covers it. ;-)
Damian
> > 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
Mark-Jason Dominus wrote:
>
> > 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
Chaim Frenkel writes:
> Removing -1 as a valid result, could be a breakage (if someone is
> doing something weird with a negative result)
I don't care, so long as the perl526 translator can wrap perl6's
index/rindex. And I gave sample code for it to do that.
> Would it be reasonable to ask that
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> In perl5, index() and rindex() return -1 if the
PRL> substring isn't found. This seems out of step with
PRL> the rest of Perl's functions, which return C
PRL> on error. I propose changing index() and rindex()
PRL> to return C i
On Mon, 11 Sep 2000, Mark-Jason Dominus wrote:
>
> perl6-language-regex
>
> Summary report 2911
>
> RFC 164: Replace =~, !~, m//, s///, and tr// with match(), subst(),
> and trade() (Nathan Wiger)
>
> Surprisingly, there was no discussion about this RFC this week.
I only read th
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
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
Dan Sugalski writes:
> No, that's the point. But if someone explicitly strips out the debugging
> info then, well, you don't get much help in debugging, now do you? :)
I buy that. It'd be nice to be able to be one step better than C,
though, and given *something* that you can use to go back to
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
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
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
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
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 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
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
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
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
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
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
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
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
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
=head1 VERSION
Maintainer: Bradley M. Kuhn E[EMAIL PROTECTED]
Date: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 219
Version: 1
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
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:
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
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:
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
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
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
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
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
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 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 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
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
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
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.
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
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
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
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
On Wed, Sep 13, 2000 at 07:24:26AM -0700, Nathan Wiger wrote:
> > print "what's that, $perl?";
> >
> > Use of uninitialized value in concatenation (.) at -e line 1.
>
> > This is misleading and confuses users. When Perl needs to report
> > errors or warnings, it should describe the code the
- Original Message -
From: "Nick Ing-Simmons" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 13, 2000 6:05 PM
Subject: Re: RFC 211 (v1) The Artistic License Must Be Changed
> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >=head3 Bruce
Perl6 RFC Librarian writes:
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I can't yet think of code that this extension would break.
I assume you mean that <> in void context should assign to $_?
Any code that has set $_, the
> "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
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
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
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
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
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.
:
1 - 100 of 202 matches
Mail list logo
