Steve Fink:
# On Mon, Jan 14, 2002 at 01:49:44AM -0800, Brent Dax wrote:
# > I wrote a _very_ simple benchmark program to compare Perl 5
# and Parrot.
# > Here's the result of a test run on my machine:
# >
# > C:\brent\Visual Studio Projects\Perl 6\parrot\parrot>..\benchmark
# > Benchmarking "bbcd
In Apocalypse 4, Larry Wall wrote:
|
| In fact, a C of the form:
|
| CATCH {
| when xxx { ... } # 1st case
| when yyy { ... } # 2nd case
| ... # other cases, maybe a default
| }
|
|means something vaguely like:
While a few people active, can someone "re-clue" me in on intentions
of string handling. I'd like to stick a couple of calls in the string lib
to:
1) Terminate a string's current buffer if there is room
2) Create a local or alloced buffer with a null terminated string.
These calls
On Mon, 21 Jan 2002, Nicholas Clark wrote:
> This eliminates many gcc warnings from pmc code by
Applied, thanks.
Alex Gough
At 09:41 PM 1/21/2002 +, Nicholas Clark wrote:
>I am of the opinion that they are UINTVAL, not INTVAL. (and EOF being a
>negative value such as -1 is only needed for C stdio, and I seem to remember
>that Dan has strong opinions on C stdio, and what C can do with it)
Specifically Dan has decla
On Mon, 21 Jan 2002, Nicholas Clark wrote:
> Before:
lots.
> After:
less.
Applied, thanks.
Alex Gough
On Mon, 21 Jan 2002, Nicholas Clark wrote:
> I thought that it should be this
>
> INTVAL (*get_digit)(UINTVAL c);
>
> not this
>
> UINTVAL (*get_digit)(UINTVAL c);
>
It seems you thought both, I've made a small modification and applied
the patch, thanks.
Alex Gough
On Monday 21 January 2002 19:06, Dan Sugalski wrote:
> Commits in areas you (the generic you, here)
> have some responsibility for (Brent with the RE code, Jeff Goff for
> PMC stuff, Melvin for IO, for example) can also go in if you're
> comfortable with them.
That should probably be amended wit
At 11:10 PM + 1/21/02, Nicholas Clark wrote:
>We do mandate an ANSI conformant C compiler, don't we?
>
>Appended patch cures these warnings:
Oh, and applied. Thanks.
--
Dan
--"it's like this"---
Dan
At 3:56 PM -0800 1/21/02, Steve Fink wrote:
>All of your last several patches look good to me. Didn't Dan give you
>commit rights yet? I'm pretty sure he intended to. Dan was also going
>to have a discussion of commit policy -- when should we just commit,
>and when should we discuss first -- as so
Graham Barr wrote:
> On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
Case 1:
> > do {
> > if my $foo = bar() {
> > ...
> > }
> > }
Case 2:
> if ((my $foo = bar()) eq 'foo') {
> ...
> }
>
> if ($foo eq 'bar') {
> ...
> }
Des
At 11:10 PM + 1/21/02, Nicholas Clark wrote:
>We do mandate an ANSI conformant C compiler, don't we?
Yep. If we haven't given you commit rights, go over to dev.perl.org
and get an account. Then mail me the account name and we'll fix that.
--
Dan
---
All of your last several patches look good to me. Didn't Dan give you
commit rights yet? I'm pretty sure he intended to. Dan was also going
to have a discussion of commit policy -- when should we just commit,
and when should we discuss first -- as soon as he gets more settled,
but my vote would be
> Hmm. A hyperdwim operator. So that means that
>
> @result = @a ^=~ @b
>
> is the same as
>
> @result = map -> $a; $b { $a =~ $b } (@a; @b)
>
> Or something resembling that that actually works...
>
> Hmm. I suppose it could be argued that a C in list context:
>
> @result = fo
On Mon, Jan 14, 2002 at 01:49:44AM -0800, Brent Dax wrote:
> I wrote a _very_ simple benchmark program to compare Perl 5 and Parrot.
> Here's the result of a test run on my machine:
>
> C:\brent\Visual Studio Projects\Perl 6\parrot\parrot>..\benchmark
> Benchmarking "bbcdefg" =~ /b[cde]*.f/...
>
Something Jarkko has just sent to p5p reminded me of a comment I thought of
but failed to include in the e-mail
On Mon, Jan 21, 2002 at 10:47:20PM +, Nicholas Clark wrote:
> + # No, include yourself to check your headers match your bodies
There must be a decent Baron Munchausen quote to
Nicholas Clark writes:
: On Fri, Nov 09, 2001 at 09:14:10AM -0800, Larry Wall wrote:
: > NaN is merely the floating-point representation of undef when your
: > variable is stored in a bare num. And if you declare a variable as
: > int, there may well be no representation for undef at all! Simila
We do mandate an ANSI conformant C compiler, don't we?
Appended patch cures these warnings:
key.c: In function `debug_key':
key.c:29: warning: int format, INTVAL arg (arg 3)
key.c:33: warning: int format, INTVAL arg (arg 3)
key.c:33: warning: int format, INTVAL arg (arg 4)
key.c:36: warning: int
On Mon, Jan 21, 2002 at 09:00:48PM +, Nicholas Clark wrote:
> I'm not certain that putting the test in Configure.pl is the right place
> for it, but I do believe that having an accurate MANIFEST.SKIP and the
> ability to run
>
> perl -MExtUtils::Manifest -e ExtUtils::Manifest::fullcheck
>
>
This eliminates many gcc warnings from pmc code by
1: changing index to idx
2: including the pmc's own header file so as to give declarations for its
functions
3: moving the declarations of the global init functions to global_setup.h so
that the pmc files see a declaration for their own init
On Monday 21 January 2002 17:11, Russ Allbery wrote:
> No, pretty much all of the time. There are differences between proper
> nouns and common nouns, but those are differences routinely quashed as a
> typesetting decision; if you write both proper nouns and common nouns in
> all caps as part of
On Mon, Jan 21, 2002 at 01:38:39PM -0800, Larry Wall wrote:
> Graham Barr writes:
> : On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
> : > Graham Barr writes:
> : > : But are we not at risk of introducing another form of
> : > :
> : > : my $x if 0;
> : > :
> : > : with
> : > :
>
On Mon, Jan 21, 2002 at 05:52:52PM +, Nicholas Clark wrote:
> I think that this is a good idea, but there may be arguments against it.
If it's a good idea it needs this correction
Nicholas Clark
--
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html
--- Configure.pl~ Mon Jan 21 17:44:03 2
Before:
cc -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W
-Wsign-compare -Wno-unused -I./include -DHAS_JIT -DI386 -o test_main.o -c
test_main.c
test_main.c: In function `ma
This patch (context diffs mean that it's atop the Term::ReadLine patch)
adds a check for unexpected files not in the MANIFEST to Configure.pl
I'm not certain that putting the test in Configure.pl is the right place
for it, but I do believe that having an accurate MANIFEST.SKIP and the
ability to
This warning:
string.c: In function `string_transcode':
string.c:194: warning: passing arg 2 of pointer to function as unsigned due to
prototype
represents a can of worms. The summary is "are characters signed or unsigned?"
I am of the opinion that they are UINTVAL, not INTVAL. (and EOF being
Bryan C Warnock <[EMAIL PROTECTED]> writes:
> On Monday 21 January 2002 16:43, Russ Allbery wrote:
>> Changing the capitalization of C does not change the word.
> Er, most of the time.
No, pretty much all of the time. There are differences between proper
nouns and common nouns, but those are
On Monday 21 January 2002 11:27, Larry Wall wrote:
> Compound statements in Perl 5 do have an implicit {} around the entire
> statement, but that has nothing to do with the required parentheses
> around the expressions, other than the fact that we're doing away with
> both of those special rules i
On Monday 21 January 2002 11:14, Larry Wall wrote:
> So I'm not terribly interested in going out of my way to make statement
> blocks parse exactly like terms in an ordinary expressions. If it
> happens, it'll probably be by accident.
That's fine. (And I agree.) All I really cared about was ma
Not to get modifier-happy, but it seems like a user-oriented solution would be to let
the user specify a modifier:
"caseinsensitive" =~ m/CaseInsensitive/i
"resume" =~ m/re`sume`/d (diacritic modifier?)
-Stephen
-Original Message-
From: Hong Zhang [mailto:[EMAIL PROTECTED]]
Sent: Mo
On Monday 21 January 2002 16:43, Russ Allbery wrote:
> Changing the capitalization of C does not change the word.
Er, most of the time.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Michael G Schwern wrote:
>
> In this case I'll take long-term simplicity over short-term
> easy-to-explain rules. Otherwise we'll be writing this all over the
> place til Kingdom come.
>
> do {
> if my $foo = bar() {
> ...
> }
> }
I'm surprised no one else h
Hong Zhang <[EMAIL PROTECTED]> writes:
> I disagree. The difference between 'e' and 'e`' is similar to 'c'
> and 'C'.
No, it's not.
In many languages, an accented character is a completely different letter.
It's alphabetized separately, it's pronounced differently, and there are
many words that
Graham Barr writes:
: On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
: > Graham Barr writes:
: > : But are we not at risk of introducing another form of
: > :
: > : my $x if 0;
: > :
: > : with
: > :
: > : if my $one = {
: > : ...
: > : }
: > : elsif my $two = {
: > :
At 04:12 PM 1/21/2002 -0500, Uri Guttman wrote:
> MS> "lives on", ... "creeping lexical", I feel the same way, we must
> find some
> MS> way to kill these... :)
>
>well, larry looks at it differently and what he said on the cruise makes
Well we had a go, but our kung fu powers were no match
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
>> On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
>> > : while( my $line = ) {
>> > : ...
>> > : }
>> >
>> > That still works fine--it's jus
Graham Barr wrote:
> But I have lost count of the number
> of times I have wanted to do
>
> if ((my $foo = bar()) eq 'foo') {
> ...
> }
>
> if ($foo eq 'bar') {
> ...
> }
>
To be contrasted with:
while (my($k, $v) = each %h1)
{
...
}
while (my($k, $v) = each %h2) # error?
{
> > But e` and e are different letters man. And re`sume` and resume are
> > different words come to that. If the user wants something that'll
> > match 'em both then the pattern should surely be:
> >
> >/r[ee`]sum[ee`]/
>
> I disagree. The difference between 'e' and 'e`' is similar to 'c
Michael G Schwern writes:
: In this case I'll take long-term simplicity over short-term
: easy-to-explain rules.
I fail to see what's simpler about it.
: Otherwise we'll be writing this all over the
: place til Kingdom come.
:
: do {
: if my $foo = bar() {
: ...
:
On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
> Graham Barr writes:
> : But are we not at risk of introducing another form of
> :
> : my $x if 0;
> :
> : with
> :
> : if my $one = {
> : ...
> : }
> : elsif my $two = {
> : }
> :
> : if ($two) {
> : ...
> :
From: Hong Zhang [mailto:[EMAIL PROTECTED]]
>
> > But e` and e are different letters man. And re`sume` and resume are
> > different words come to that. If the user wants something that'll
> > match 'em both then the pattern should surely be:
> >
> >/r[ee`]sum[ee`]/
>
> I disagree. The diffe
Graham Barr writes:
: But are we not at risk of introducing another form of
:
: my $x if 0;
:
: with
:
: if my $one = {
: ...
: }
: elsif my $two = {
: }
:
: if ($two) {
: ...
: }
Then it's just undefined. It's no different from how &&, ||, or ??::
work when you put a
On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
> On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
> > Casey wrote:
> >
> > > So you're suggesting that we fake lexical scoping? That sounds more
> > > icky than sticking to true lexical scoping. A block dictates s
Michael G Schwern writes:
: On Mon, Jan 21, 2002 at 03:27:29PM -0500, Casey West wrote:
: > So you're suggesting that we fake lexical scoping? That sounds more
: > icky than sticking to true lexical scoping. A block dictates scope,
: > not before and not after. I don't see ickyness about making
At 12:50 PM 1/21/2002 -0800, Larry Wall wrote:
>In most other languages, you wouldn't even have the opportunity to put
>a declaration into the conditional. You'd have to say something like:
I grudgingly agree here. Where did this shorthand come from anyway?
The first time I ever used it was C++
On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
> Casey wrote:
>
> > So you're suggesting that we fake lexical scoping? That sounds more
> > icky than sticking to true lexical scoping. A block dictates scope,
> > not before and not after. I don't see ickyness about making that s
David Whipp writes:
: Casey West wrote:
: > So you're suggesting that we fake lexical scoping? That sounds more
: > icky than sticking to true lexical scoping. A block dictates scope,
: > not before and not after. I don't see ickyness about making that so.
:
: Perl is well known for its non-or
On Mon, Jan 21, 2002 at 03:27:29PM -0500, Casey West wrote:
> So you're suggesting that we fake lexical scoping? That sounds more
> icky than sticking to true lexical scoping. A block dictates scope,
> not before and not after. I don't see ickyness about making that
> so.
Perl5 already fakes l
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
> : What's the chance that it could be considered so?
>
> In most other languages, you wouldn't even have the opportunity to put
> a declaration into the conditional. You'd have to say something like:
>
> my $line = <$in>;
>
Ted Ashton writes:
: Thus it was written in the epistle of Michael G Schwern,
: > On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
: > > : while( my $line = ) {
: > > : ...
: > > : }
: > >
: > > That still works fine--it's just that $line lives on after the while.
: >
> Yes, that's somewhat problematic. Making up "a byte CEF" would be
> Wrong, though, because there is, by definition, no CCS to map, and
> we would be dangerously close to conflating in CES, too...
> ACR-CCS-CEF-CES. Read the character model. Understand the character
> model. Embrace the chara
Casey West wrote:
> So you're suggesting that we fake lexical scoping? That sounds more
> icky than sticking to true lexical scoping. A block dictates scope,
> not before and not after. I don't see ickyness about making that so.
Perl is well known for its non-orthogonality. To say that "A bloc
Casey wrote:
> So you're suggesting that we fake lexical scoping? That sounds more
> icky than sticking to true lexical scoping. A block dictates scope,
> not before and not after. I don't see ickyness about making that so.
Exactly!
What we're cleaning up is the ickiness of having things dec
On 2002.01.21 18:32 Michael G Schwern wrote:
> On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> > : while( my $line = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
> This creeping lexical leakage bothers me. W
Melvin Smith writes:
: At 03:16 PM 1/21/2002 -0500, Tzadik Vanderhoof wrote:
: >It's not the condition you would want to check, it's the variable (e.g.
: >$line).
:
: Right, I gotcha. I guess I would rather see it cater to the typical use,
: not the atypical. Of course my opinion of typical might
> But e` and e are different letters man. And re`sume` and resume are
> different words come to that. If the user wants something that'll
> match 'em both then the pattern should surely be:
>
>/r[ee`]sum[ee`]/
I disagree. The difference between 'e' and 'e`' is similar to 'c'
and 'C'. The Uni
On Mon, Jan 21, 2002 at 03:26:30PM -0500, Ted Ashton wrote:
:
:Thus it was written in the epistle of Michael G Schwern,
:> On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
:> > : while( my $line = ) {
:> > : ...
:> > : }
:> >
:> > That still works fine--it's just that
Thus it was written in the epistle of Michael G Schwern,
> On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> > : while( my $line = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
> This creeping lexical leakage bo
At 03:16 PM 1/21/2002 -0500, Tzadik Vanderhoof wrote:
>It's not the condition you would want to check, it's the variable (e.g.
>$line).
Right, I gotcha. I guess I would rather see it cater to the typical use,
not the atypical. Of course my opinion of typical might differ from yours.
I do feel th
At 03:14 PM 1/21/2002 -0500, Melvin Smith wrote:
>At 03:02 PM 1/21/2002 -0500, you wrote:
>>Why all the fuss? Often, you would *want* to access that lexical after the
>>loop terminates, for instance to check how it terminated.
>
>Why would you want to check it when the condition is typically bool
It's not the condition you would want to check, it's the variable (e.g.
$line).
-Original Message-
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 21, 2002 3:15 PM
To: Tzadik Vanderhoof
Cc: [EMAIL PROTECTED]
Subject: RE: Night of the Living Lexical (sequel to Apoc4: Th
At 03:02 PM 1/21/2002 -0500, you wrote:
>Why all the fuss? Often, you would *want* to access that lexical after the
>loop terminates, for instance to check how it terminated.
Why would you want to check it when the condition is typically boolean?
while( my $line = ) {
I think many pe
On Mon, Jan 21, 2002 at 03:02:06PM -0500, Tzadik Vanderhoof wrote:
> Why all the fuss? Often, you would *want* to access that lexical after the
> loop terminates, for instance to check how it terminated.
In most cases you don't want that to happen, usually the life of the
lexical is only the blo
Why all the fuss? Often, you would *want* to access that lexical after the
loop terminates, for instance to check how it terminated.
-Original Message-
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 21, 2002 2:59 PM
To: Melvin Smith
Cc: Larry Wall; Damian Conway
On Mon, Jan 21, 2002 at 02:44:40PM -0500, Melvin Smith wrote:
> At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
> >On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> >> : while( my $line = ) {
> >> : ...
> >> : }
> >>
> >> That still works fine--it's just that $li
At 12:32 PM 1/21/2002 -0500, Michael G Schwern wrote:
>On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> > : while( my $line = ) {
> > : ...
> > : }
> >
> > That still works fine--it's just that $line lives on after the while.
>
>This creeping lexical leakage bothers m
On Mon, 21 Jan 2002, Brent Dax wrote:
>
> If the problem is backtracking, can't you just use the (?>)
> no-backtracking syntax?
>
Didn't think of that. I'm a bit concerned at the large warning
signs attached to it in perlre.pod, though.
Simon
In light of Apo4, I thought I'd re-ask this question. Is the following still
the approved idiom, or will we have a nice little /[A-Z]+/ thingie:
sub foo
{
temp $SIG{__WARN__} = sub {
warn "$(timestamp) $@\n"
}
warn "hello"
}
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip
Simon Glover:
# Right: the real cause of the second bug is similar to what I
# thought it
# was - when it sees a float, the regex engine first checks to
# see if it
# is an integer by trying the substitution:
#
# s/^(-?\d+)(?!\.)//
#
# The problem is that when, say, 1.0 gets fed to thi
Right: the real cause of the second bug is similar to what I thought it
was - when it sees a float, the regex engine first checks to see if it
is an integer by trying the substitution:
s/^(-?\d+)(?!\.)//
The problem is that when, say, 1.0 gets fed to this, and fails
to match, th
On Mon, 21 Jan 2002, Simon Glover wrote:
> The other bug is a misplaced ? in the regex checking for integers.
> This makes the match non-greedy, so 1.0 (for example) gets
> split up into 1000 (which matches the regex) and 0.0 (which matches
> as a float the next time around the loop). T
On Mon, 21 Jan 2002, H.Merijn Brand wrote:
> perl vtable_h.pl
> make: *** No rule to make target `include/parrot/rxstacks.h', needed by
>`test_main.o'. Stop.
This exists (and has done for a couple of days) but isn't in the MANIFEST
at the moment (I've already sent a patch). Could that be c
l1:/pro/3gl/CPAN/parrot-current 114 > perl Configure.pl --default
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you h
I think that this is a good idea, but there may be arguments against it.
The stub Term::ReadLine has been in perl since pre 5.004, so it's quite safe
to use it. However, to actually get line editing one needs to have installed
either Term::ReadLine::Perl or Term::ReadLine::Gnu. Attached patch make
On Mon, Jan 21, 2002 at 05:09:06PM +, Dave Mitchell wrote:
> Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > > In the good ol'days, one could usefully use regexes on 8-bit binary data,
> > > eg
> > >
> > > open G, 'myfile.gif' or die;
> > > read G, $buf, 8192 or die;
> > > if ($buf =~ /^GIF8
Enclosed patch fixes a couple of bugs in the optimizer. The first was
that the parser wasn't correctly recognising register names - it needs
to check for these _before_ checking for labels, or else they're
incorrectly identified as labels. Strangely, this wasn't causing
any problems with t
On Sun, Jan 20, 2002 at 10:58:34PM -0800, Larry Wall wrote:
> : while( my $line = ) {
> : ...
> : }
>
> That still works fine--it's just that $line lives on after the while.
This creeping lexical leakage bothers me. While it might make the
language simpler, the proliferation of
> > Err. Expressions don't have their own scope level, even in Perl 5.
>
> They do in block conditional expressions.
But that's a property of being in a block conditional, not of being an expression.
And, yes, it's going away in Perl 6.
Damian
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > In the good ol'days, one could usefully use regexes on 8-bit binary data,
> > eg
> >
> > open G, 'myfile.gif' or die;
> > read G, $buf, 8192 or die;
> > if ($buf =~ /^GIF89a\x08\x02/) {
> > .
> >
> > where it was clear to everyone that we
On Mon, Jan 21, 2002 at 04:37:46PM +, Dave Mitchell wrote:
> Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > There is no string type built out of native eight-bit bytes.
>
> In the good ol'days, one could usefully use regexes on 8-bit binary data,
> eg
>
> open G, 'myfile.gif' or die;
> rea
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> There is no string type built out of native eight-bit bytes.
In the good ol'days, one could usefully use regexes on 8-bit binary data,
eg
open G, 'myfile.gif' or die;
read G, $buf, 8192 or die;
if ($buf =~ /^GIF89a\x08\x02/) {
.
where it wa
[EMAIL PROTECTED] writes:
: On Sunday 20 January 2002 21:00, Damian Conway wrote:
: > Bryan C. Warnock asked:
: > > Since the parentheses are no longer required, will the expressions
: > > lose or retain their own scope level? (I'm assuming that whatever
: > > rule applies, it will hold true if y
Larry Wall writes:
: This is only slightly less problematic than
:
: NEXT $coderef;
:
: which in turn is only slightly less problematic than
:
: if $condition $coderef;
Actually, that'd probably have to be:
if $condition, $coderef;
Still not sure if that has any possibility of ac
Enclosed patch fixes the POD brokenness in Parrot::Assembler reported
by Steve Fink, and generally makes it more aesthetically pleasing.
I've also supplied the missing documentation for the
constantize_number and constantize_integer functions - could someone
who knows check that I've expla
À la perl 5, it can be useful just to run 1 test script under the harness.
Nicholas Clark
--
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html
--- t/harness.orig Wed Jan 2 19:19:09 2002
+++ t/harness Mon Jan 21 11:46:54 2002
@@ -1,7 +1,9 @@
#! perl -w
+# $Id: $
use strict;
use Test::H
At 12:54 PM 1/21/2002 +, Simon Glover wrote:
> While you're online: now that you've split the io ops into their
> own separate file, their documentation isn't going to core_ops.pod
> any more. The enclosed patch fixes this by autogenerating io_ops.pod
> in the same fashion that core_ops.p
On Sunday 20 January 2002 21:00, Damian Conway wrote:
> Bryan C. Warnock asked:
> > Since the parentheses are no longer required, will the expressions
> > lose or retain their own scope level? (I'm assuming that whatever
> > rule applies, it will hold true if you do elect to use parantheses
> > a
If you decide to apply the last patch, you should probably apply this
one as well, so that people know about the new file. If not, then junk
'em both.
Simon
--- parrot.pod.old Mon Jan 21 12:56:15 2002
+++ parrot.pod Mon Jan 21 12:57:11 2002
@@ -31,6 +31,10 @@
A description of the c
While you're online: now that you've split the io ops into their
own separate file, their documentation isn't going to core_ops.pod
any more. The enclosed patch fixes this by autogenerating io_ops.pod
in the same fashion that core_ops.pod is generated, but I'm not sure
whether this is the r
At 12:21 PM 1/21/2002 +, Simon Glover wrote:
> Please, people, if you create new files, remember to add them to the
> MANIFEST.
>
> Simon
>
>--- MANIFEST.oldMon Jan 21 12:17:34 2002
>+++ MANIFESTMon Jan 21 12:18:47 2002
>@@ -75,6 +75,7 @@
> examples/assembly/call.pasm
> examp
Larry wrote:
> : One way to do that would be to define POST and NEXT to return their
> : own (single, closure) argument. So then you could write:
> :
> : NEXT POST { ... }
>
> As long as everyone realizes that that return happens at compile
> time...
Sorry, yes, I should have been explic
Please, people, if you create new files, remember to add them to the
MANIFEST.
Simon
--- MANIFEST.oldMon Jan 21 12:17:34 2002
+++ MANIFESTMon Jan 21 12:18:47 2002
@@ -75,6 +75,7 @@
examples/assembly/call.pasm
examples/assembly/euclid.pasm
examples/assembly/fact.pasm
+examples/
Piers Cawley <[EMAIL PROTECTED]> writes:
> Larry Wall <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley writes:
>> : Yeah, that's sort of where I got to as well. But I just wanted to make
>> : sure. I confess I'm somewhat wary of the ';' operator, especially
>> : where it's 'unguarded' by brackets, a
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : Yeah, that's sort of where I got to as well. But I just wanted to make
> : sure. I confess I'm somewhat wary of the ';' operator, especially
> : where it's 'unguarded' by brackets, and once I start programming in
> : Perl 6 then
>
Larry Wall <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
[...]
> : How does one enforce the no side-effects rule, and how deeply does it
> : traverse?
>
> Dunno. Could warn or fail on assignment to any non-lexical or
> non-local lexical as a start. Maybe we could warn or fail on
95 matches
Mail list logo
