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
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
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
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
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 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
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]
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
> > 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
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
> 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
> 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, 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
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
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
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
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
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/
48 matches
Mail list logo
