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
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
>
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
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/
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
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
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
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
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
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
À 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
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
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
[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
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
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:
> > 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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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: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
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
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
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
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
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
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
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
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.
: >
> 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
> 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
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
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>;
>
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
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: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
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++
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
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
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 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) {
> : ...
> :
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() {
: ...
:
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?
{
> "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
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
> > 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
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 = {
: > :
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
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
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
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
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]
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
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
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
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
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
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
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 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
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 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
>
>
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
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
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
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/...
>
> 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
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
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
---
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
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
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
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
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 Mon, 21 Jan 2002, Nicholas Clark wrote:
> Before:
lots.
> After:
less.
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:
> This eliminates many gcc warnings from pmc code by
Applied, thanks.
Alex Gough
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
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:
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
95 matches
Mail list logo
