I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl 5)?
From a Perl (6) perspective, it makes more sense to me:
# This:
$a =~ /$regex/;
#
Okay, I've added some flags to pmc.h. They are:
PMC_active_destroy_FLAG= 2 8,
PMC_is_container_FLAG = 2 9,
PMC_is_buffer_ptr_FLAG = 2 10,
PMC_is_PMC_ptr_FLAG= 2 11,
PMC_private_GC_FLAG= 2 12
active_destroy must be set if
At 05:22 PM 1/11/2002 -0600, David M. Lloyd wrote:
This patch fixes a warning and also changes an 'int' to an 'INTVAL'. All
tests should pass on Solaris.
Applied, thanks.
Dan
--it's like this---
Dan
Subject says it all...
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.77
diff -a -u -r1.77 Configure.pl
--- Configure.pl9 Jan 2002 17:24:11 - 1.77
+++ Configure.pl
Dan Sugalski:
# At 10:23 AM 1/12/2002 -0600, David M. Lloyd wrote:
# On Sat, 12 Jan 2002, Dan Sugalski wrote:
#
# At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
# I have a design question here. Why did we take the
# approach of having a
# match method on every single vtable, instead
On Fri, 11 Jan 2002, Gopal Rajaraman wrote:
There seems to be a typo in either pmc.h or parrotpointer.pmc
pmc.h has:
PMC_private_GC_FLAG = 2 12
but parrotpointer.pmc has
void init () {
SELF-data=NULL;
SELF-flags=PMC_private_gc_FLAG; ## you get a compile error at
On Sat, Jan 12, 2002 at 10:26:37AM -0500, Dan Sugalski wrote:
[on prederef going SEGV with the bsr opcode]
I'm not going to worry too much about it for the moment, as I'm not sure
what the ultimate fate of the prederef stuff will be. If the JIT works out
well on most of our platforms, we
At 12:02 AM 1/12/2002 +, Nicholas Clark wrote:
On Fri, Jan 11, 2002 at 12:54:08PM -0500, Dan Sugalski wrote:
At 06:01 PM 1/10/2002 -0500, Jason Gloudon wrote:
Here is a patch that makes pbc2c generated code work with the bsr
opcode. It
creates a new opcode 'enternative', and uses
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl 5)?
So we could do:
@results = @foo ^=~
Attached is a build of a just rsync'd parrot on Linux/PowerPC machine.
Stock configure using Debian's perl (so nothing fancy like 64bit
integers).
There's a lot of warnings.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL
Dan Sugalski:
# At 10:02 PM 1/11/2002 -0600, David M. Lloyd wrote:
# Just out of curiosity, is the regex compiler going to be
# written in Parrot
# or C?
#
# Probably either perl or C. It'll be considered just another
# language by the
# parser.
You sure about that? I've got an rx_compile op
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 10:23 AM 1/12/2002 -0600, David M. Lloyd wrote:
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every
At 10:23 AM 1/12/2002 -0600, David M. Lloyd wrote:
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl
Here is a patch that fixes prederef with respect to bsr.
--
Jason
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.57
diff -u -r1.57 interpreter.c
--- interpreter.c 12 Jan 2002
On Fri, Jan 11, 2002 at 05:43:28PM -0500, Dan Sugalski wrote:
Okay, I've added some flags to pmc.h. They are:
PMC_active_destroy_FLAG = 2 8,
PMC_is_container_FLAG = 2 9,
PMC_is_buffer_ptr_FLAG= 2 10,
PMC_is_PMC_ptr_FLAG = 2 11,
Here's a patch to eliminate the EvilSubWrapper from Parrot::Test.
This should make Parrot::Test much easier to maintain.
Update to Test::More 0.41 which adds Test::Builder
Delete the vestigal Test::Utils
Change Parrot::Test so it uses Test::Builder instead of Evil Wrappers
At 11:03 PM 1/7/2002 +, Nicholas Clark wrote:
If I've got this right, then this patch silences all warnings about unused
variables, except for those from the ops files.
Applied. Thanks. (And sorry for the delay)
Dan
What's the point of having a policy of turning gcc's warnings to painful
levels when it appears that commit policy will accept new code that increases
the number of compiler warnings?
eg, why is there need to patch this?
--- global_setup.c.orig Thu Jan 10 18:01:51 2002
+++ global_setup.c
On Fri, Jan 11, 2002 at 09:14:37PM -0600, Gopal Rajaraman wrote:
There seems to be a typo in either pmc.h or parrotpointer.pmc
Yes, it's in parrotpointer.pmc. Thanks, fixed.
And minus several points to those checking in code that doesn't compile. :)
--
DESPAIR:
It's Always Darkest Just
The latest version of jit2h.pl is taking a very long time to run on my
machine - upwards of two minutes, which is longer than the rest of the
build put together! It doesn't appear to be broken, as Parrot still
builds fine, but it is rather annoying. Any idea what's causing this
21 matches
Mail list logo
