Re: Some random design notes
--- We need private methods for objects. --- just a comment on how this is done for ruby: code #initially objects are created with a given class #say aFoo is an instance of class Foo aFoo = Foo.new #then we can add methods to aFoo def aFoo.bar() puts 'invoked bar' end #this actually created an anonymous class (called a singleton #class in ruby speak) which derives from Foo and was set as aFoo's #actual class. #the exact same thing could have been done more explicitly by doing this class aFoo#creates (or retrieve) the singleton class for a Foo and open its def def bar() puts 'invoked bar' end end /code what all this means is that having objects method only requires to be able to change an object class at runtime and at that only to change it to a subclass of its original class. Benoit
The dreaded regex patch
Okay, here it is. Attached is the regular expression patch. It
currently segfaults on Windows because of a combination of two factors:
1) There are some bounds-checking issues in key.c
2) Windows's malloc() isn't as robust as Unix's
This is only a problem on native Windows, not on Cygwin; I've confirmed
this myself.
Besides what you'd expect it to do, this patch makes a (very) minor
change to string.c. Basically, it makes it so that you can take a
zero-length substring with an index equal to the size of the string.
This is done so that the equivalent to $`$$' doesn't need a
special case in the bytecode when $ reaches all the way to the end of
the string.
Copious documentation is included in rx.ops, and twenty tests are
included in t/op/rx.t. This patch is reliant on the ParrotPointer patch
I sent in earlier.
I can't quite guarantee that the patch will apply cleanly--I had to
manually change some things in it--but the things that may not apply
well should be easy to put in manually.
UNIMPLEMENTED OPCODES:
rx_compile - compile a regex
rx_cloneinfo - clone the info structure (used for look(ahead|behind)s)
UNTESTED OPCODES:
rx_forwards - tell the regex to increment the current index when moving
rx_backwards - tell the regex to decrement the current index when
moving
Share and enjoy.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
obra . hawt sysadmin chx0rs
lathos This is sad. I know of *a* hawt sysamin chx0r.
obra I know more than a few.
lathos obra: There are two? Are you sure it's not the same one?
--- parrot-cvs/Makefile.in Wed Jan 9 02:51:00 2002
+++ parrot/Makefile.in Wed Jan 9 02:50:24 2002
@@ -63,7 +63,7 @@
$(INC)/global_setup.h $(INC)/vtable.h $(INC)/oplib/core_ops.h
$(INC)/oplib/core_ops_prederef.h \
$(INC)/runops_cores.h $(INC)/trace.h \
$(INC)/pmc.h $(INC)/key.h $(INC)/resources.h $(INC)/platform.h \
-$(INC)/interp_guts.h ${jit_h} ${jit_struct_h}
+$(INC)/interp_guts.h ${jit_h} ${jit_struct_h} $(INC)/rx.h
CLASS_O_FILES = classes/default$(O) classes/perlint$(O) classes/perlstring$(O) \
classes/perlnum$(O) classes/perlarray$(O) classes/perlundef$(O) \
@@ -79,7 +79,7 @@
INTERP_O_FILES = global_setup$(O) interpreter$(O) parrot$(O) register$(O) \
core_ops$(O) core_ops_prederef$(O) memory$(O) packfile$(O) stacks$(O) \
string$(O) encoding$(O) chartype$(O) runops_cores$(O) trace$(O) pmc$(O) key$(O) \
-platform$(O) ${jit_o} resources$(O)
+platform$(O) ${jit_o} resources$(O) rx$(O)
O_FILES = $(INTERP_O_FILES) $(IO_O_FILES) $(CLASS_O_FILES) $(ENCODING_O_FILES)
$(CHARTYPE_O_FILES)
@@ -292,6 +292,8 @@
register$(O): $(H_FILES)
+rx$(O): $(H_FILES)
+
stacks$(O): $(H_FILES)
core_ops$(O): $(H_FILES) core_ops.c
@@ -396,4 +398,3 @@
lint: ${test_prog}
$(LINT) ${cc_inc} -Iclasses $(LINTFLAGS) `echo $(O_FILES) | sed 's/\.o/\.c/g'`
$(LINT) ${cc_inc} $(LINTFLAGS) test_main.c
-
--- parrot-cvs/MANIFEST Wed Jan 9 02:25:54 2002
+++ parrot/MANIFEST Tue Jan 8 16:32:58 2002
@@ -109,6 +110,7 @@
include/parrot/pmc.h
include/parrot/register.h
include/parrot/resources.h
+include/parrot/rx.h
include/parrot/runops_cores.h
include/parrot/stacks.h
include/parrot/string.h
@@ -185,6 +187,8 @@
pmc_pm.pl
register.c
resources.c
+rx.c
+rx.ops
runops_cores.c
stacks.c
string.c
@@ -198,8 +202,8 @@
t/op/macro.t
t/op/number.t
t/op/pmc.t
t/op/pmc_perlhash.t
t/op/pmc_perlstring.t
+t/op/rx.t
t/op/stacks.t
t/op/string.t
t/op/time.t
--- /dev/null Wed Jan 9 03:01:05 2002
+++ /parrot/include/parrot/rx.h Tue Jan 8 15:20:58 2002
@@ -0,0 +1,92 @@
+/* rx.h
+ * Copyright: (When this is determined...it will go here)
+ * CVS Info
+ * $Id$
+ * Overview:
+ * Supporting file for the regular expression engine
+ * Data Structure and Algorithms:
+ *rxinfo is the main structure involved in regular expressions; it's stuffed
+ * into a Handle PMC and passed to all regular expression opcodes.
+ * History:
+ * Notes:
+ * References:
+ */
+
+#if !defined(PARROT_RX_H_GUARD)
+#define PARROT_RX_H_GUARD
+
+#include parrot/parrot.h
+
+typedef enum rxflags {
+ enum_rxflags_none=0,
+ enum_rxflags_case_insensitive=1,
+ enum_rxflags_single_line=2,
+ enum_rxflags_multiline=4,
+ enum_rxflags_reverse=8
+} rxflags;
+
+typedef enum rxdirection {
+ enum_rxdirection_forwards=1,
+ enum_rxdirection_backwards=-1
+} rxdirection;
+
+extern const INTVAL RX_MARK;
+
+typedef struct rxinfo {
+ STRING *string;
+ INTVAL index;
+ INTVAL startindex;
+ BOOLVAL success;
+
+ rxflags flags;
+ INTVAL minlength;
+ rxdirection whichway;
+
+ PMC *groupstart;
+ PMC *groupend;
+
+ opcode_t *substfunc;
+
+ struct Stack_Entry *stack_top;
+ struct StackChunk *stack_base;
+} rxinfo;
+
+rxinfo * rx_allocate_info(struct Parrot_Interp *, STRING *);
+
+BOOLVAL rx_is_word_character(char ch);
+BOOLVAL rx_is_number_character(char ch);
HP-UX state report
HP-UX is very unwilling at this stage, including two show-stoppers 1. The LDFLAGS is extended with flags from config that are meant to be passed to cc, not to ld 2. Undefined symbols inhibit the basic build a5:/pro/3gl/CPAN/parrot-current 101 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 have a complete Parrot kit... Okay, we found everything. Next you'll need to answer a few questions about your system. Defaults are in square brackets, and you can hit enter to accept them. If you don't want the default, type a new value in. If that new value starts with a '+', it will be concatenated to the default value. Determining if your C compiler is actually gcc (this could take a while): Your C compiler is not gcc. Probing Perl 5's configuration to determine which headers you have (this could take a while on slow machines)... Determining C data type sizes by compiling and running a small C program (this could take a while): Building ./test.c from test_c.in... Figuring out the formats to pass to pack() for the various Parrot internal types... Figuring out what integer type we can mix with pointers... We'll use 'unsigned int'. Building a preliminary version of include/parrot/config.h, your Makefiles, and other files: Building include/parrot/config.hfrom config_h.in... Building ./Makefile from Makefile.in... Building ./classes/Makefile from classes/Makefile.in... Building ./docs/Makefilefrom docs/Makefile.in... Building ./languages/Makefile from languages/Makefile.in... Building ./languages/jako/Makefile from languages/jako/Makefile.in... Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in... Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in... Building Parrot/Types.pmfrom Types_pm.in... Building Parrot/Config.pm from Config_pm.in... Checking some things by compiling and running another small C program (this could take a while): Building ./testparrotsizes.cfrom testparrotsizes_c.in... Updating include/parrot/config.h: Building include/parrot/config.hfrom config_h.in... Okay, we're done! You can now use `make' (or your platform's equivalent to `make') to build your Parrot. After that, you can use `make test' to run the test suite. Happy Hacking, The Parrot Team a5:/pro/3gl/CPAN/parrot-current 102 make perl vtable_h.pl perl make_vtable_ops.pl vtable.ops perl ops2c.pl C core.ops vtable.ops perl ops2c.pl CPrederef core.ops vtable.ops cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o test_main.o -c test_main.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o global_setup.o -c global_setup.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o interpreter.o -c interpreter.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o parrot.o -c parrot.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o register.o -c register.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o core_ops.o -c core_ops.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o core_ops_prederef.o -c core_ops_prederef.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o memory.o -c memory.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o packfile.o -c packfile.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o stacks.o -c stacks.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o string.o -c string.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o encoding.o -c encoding.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o chartype.o -c chartype.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o runops_cores.o -c runops_cores.c cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o
Re: The dreaded regex patch
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote: 2) Windows's malloc() isn't as robust as Unix's In what way? Windows malloc() is getting upset with buggy allocations that a Unix malloc() will typically stomach? [ie perl6 bugs] or Windows malloc() is getting upset with legal but awkward allocations we're asking it for? [ie its bugs that we're going to have to work around] Nicholas Clark
Re: The dreaded regex patch
At 01:49 PM 1/9/2002 +, Nicholas Clark wrote: On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote: 2) Windows's malloc() isn't as robust as Unix's In what way? Windows malloc() is getting upset with buggy allocations that a Unix malloc() will typically stomach? [ie perl6 bugs] or Windows malloc() is getting upset with legal but awkward allocations we're asking it for? [ie its bugs that we're going to have to work around] Looks like the former at the moment. Hard to say for sure without more investigation. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: HP-UX state report
On Wed, 9 Jan 2002, H . Merijn Brand wrote:
HP-UX is very unwilling at this stage, including two show-stoppers
1. The LDFLAGS is extended with flags from config that are meant to be passed
to cc, not to ld
Odd. On most Unix systems, $Config{ld} = 'cc'. Calling ld directly is
usually tricky and usually results in missing things (such as crt0).
However, sometimes, on some systems, one needs to call ld directly (such
as building a shared library).
For perl5, the main makefile calls (essentially)
$(CC) -o perl
while the parrot Makefile calls
$(LD) -o test_main
I tend to think parrot's wrong here, but there might have been a good
reason for doing that way that I am unaware of.
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Some random design notes
On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote: # Attributes are done as a hash of hashes. Each interpreter has a # pointer to an attribute hash, whose keys are the attribute names. The # values will be hash pointers. Those hashes will each have a key which # is a PMC pointer (hashed up somehow) and the value is the attribute # value. If you're talking about 'is'-style attributes, why not have them be attached to the PMCs themselves? D'you want an attribute pointer for each PMC? (I've considered it, but for the moment I think it'll be too expensive. Might be wrong) On the other hand when a variable is garbage collected you have to walk the hash of hashes to clear out the attributes. Also what happens when you move the PMC during garbage collection, will the key in the hash change ? A PMC may have a flag to show if it has any entries in the global table, but it is probably just a trade off between space and performance. Graham.
Re: HP-UX state report
At 10:56 AM 1/9/2002 -0500, Andy Dougherty wrote:
On Wed, 9 Jan 2002, H . Merijn Brand wrote:
HP-UX is very unwilling at this stage, including two show-stoppers
1. The LDFLAGS is extended with flags from config that are meant to be
passed
to cc, not to ld
Odd. On most Unix systems, $Config{ld} = 'cc'. Calling ld directly is
usually tricky and usually results in missing things (such as crt0).
However, sometimes, on some systems, one needs to call ld directly (such
as building a shared library).
For perl5, the main makefile calls (essentially)
$(CC) -o perl
while the parrot Makefile calls
$(LD) -o test_main
I tend to think parrot's wrong here, but there might have been a good
reason for doing that way that I am unaware of.
It's a platform-independence issue. Non-Unix platforms need to call the
linker, unix ones don't. Which means we've either got the makefile wrong,
or have got the switches set in incorrect ways. Or both. Probably both--let
me think about this some.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [PATCH] Add printf templates to configure process [APPLIED]
At 08:32 AM 1/9/2002 -0600, David M. Lloyd wrote: This patch adds macros to the config.h file for INTVAL and NUMVAL printf formats; I called them INTVAL_FMT and NUMVAL_FMT, although if those names are not appropriate I won't sweat it. Applied, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: lcc blowing up for no good reason [APPLIED]
At 02:22 AM 1/9/2002 -0500, Josh Wilmes wrote: I'll see what I can do as far as upgrading my lcc installation or reporting this as a bug to the lcc people. But for now, here is a workaround for this error, just to get the tinderbox going again: Applied, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: HP-UX state report
On Wed, 9 Jan 2002, Dan Sugalski wrote:
At 10:56 AM 1/9/2002 -0500, Andy Dougherty wrote:
For perl5, the main makefile calls (essentially)
$(CC) -o perl
while the parrot Makefile calls
$(LD) -o test_main
I tend to think parrot's wrong here, but there might have been a good
reason for doing that way that I am unaware of.
It's a platform-independence issue. Non-Unix platforms need to call the
linker, unix ones don't. Which means we've either got the makefile wrong,
or have got the switches set in incorrect ways. Or both. Probably both--let
me think about this some.
I think we've got lots of things mixed up on all ends. Perl5's
Unix-centric Configure is showing up again.
Specifically, Perl5's $Config{ld} is documented as follows:
ld: This variable indicates the program to be used to link
libraries for dynamic loading. On some systems, it is 'ld'.
On ELF systems, it should be $cc. Mostly, we'll try to respect
the hint file setting.
The problem is that we really need at least *three* variables, something
like the following:
Variabledescription
cc Compiler -- used to turn .c files into object files.
(Usually cc or cl, or something like that.)
linkLinker, used to link object files (plus libraries) into
an executable. (Usually $cc on Unix-ish systems. VMS and
Win32 might use Link.
lib_ld Tool used to build dynamically loadable libraries. Often
$cc on Unix-ish systems, but apparently sometimes it's ld.
For perl5, $Config{ld} is what I labeled lib_ld in the little table above.
Perl5's Configure/Makefile.SH build system incorrectly _assumes_ that
linker=$cc.
One possible fix for now is to introduce these *three* variables into
parrot's Configure, and letting $c{linker} default to $c{cc} for now,
unless overridden by a hints file. The parrot Makefile would then call
(essentially)
$(LINK) -o test_main
and HP/UX would work again.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
[PATCH] Fix warning in memory.c
fromsize and tosize are both UINTVALs, so copysize should be one too.
Simon
--- memory.c.oldWed Jan 9 17:36:41 2002
+++ memory.cWed Jan 9 17:37:44 2002
@@ -81,7 +81,7 @@
void *
mem_realloc(void *from, UINTVAL fromsize, UINTVAL tosize) {
-INTVAL copysize = (fromsize tosize ? tosize : fromsize);
+UINTVAL copysize = (fromsize tosize ? tosize : fromsize);
void *mem;
mem = mem_sys_allocate(copysize);
if (!mem) {
[PATCH] Fix index checking in key.c
Two separate bugs:
1. The index checks should use and not ||, or else they'll always be
true.
2. The check in key_inc has an off-by-one error.
Simon
--- key.c.old Wed Jan 9 17:58:59 2002
+++ key.c Wed Jan 9 18:01:33 2002
@@ -225,7 +225,7 @@
INTVAL key_element_type(struct Parrot_Interp *interpreter, KEY* key,
INTVAL idx) {
if(key != NULL) {
-if((idx = 0) || (idx key-size)) {
+if((idx = 0) (idx key-size)) {
KEY_PAIR* pair = key-keys[idx];
return pair-type;
}
@@ -248,7 +248,7 @@
KEY_PAIR* key_element_value_i(struct Parrot_Interp *interpreter, KEY* key,
INTVAL idx) {
if(key != NULL) {
-if((idx = 0) || (idx key-size)) {
+if((idx = 0) (idx key-size)) {
KEY_PAIR* pair = key-keys[idx];
if(pair != NULL) {
return pair;
@@ -297,7 +297,7 @@
void key_set_element_value_i(struct Parrot_Interp *interpreter, KEY* key,
INTVAL idx, KEY_PAIR* value) {
if(key != NULL) {
-if((idx = 0) || (idx key-size)) {
+if((idx = 0) (idx key-size)) {
memcpy(key-keys[idx],value,sizeof(KEY_PAIR));
}
else {
@@ -393,7 +393,7 @@
void key_inc(struct Parrot_Interp *interpreter, KEY* key, INTVAL idx) {
if(key != NULL) {
-if(idx 0 idx = key-size) {
+if((idx = 0) (idx key-size)) {
KEY_PAIR* pair = key-keys[idx];
pair-type++;
}
Re: [PATCH] Fix index checking in key.c
On Wed, 9 Jan 2002, Simon Glover wrote: Two separate bugs: 1. The index checks should use and not ||, or else they'll always be true. 2. The check in key_inc has an off-by-one error. Simon Better hold off on applying this patch; it makes test 5 in perlhash.t fail (and yes, I know I should have checked this _before_ sending the patch off). Simon
Re: [PATCH] Fix index checking in key.c
At 06:39 PM 1/9/2002 +, Simon Glover wrote: On Wed, 9 Jan 2002, Simon Glover wrote: Two separate bugs: 1. The index checks should use and not ||, or else they'll always be true. 2. The check in key_inc has an off-by-one error. Simon Better hold off on applying this patch; it makes test 5 in perlhash.t fail (and yes, I know I should have checked this _before_ sending the patch off). Will do. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Fix index checking in key.c
On Wed, 9 Jan 2002, Dan Sugalski wrote:
At 06:39 PM 1/9/2002 +, Simon Glover wrote:
On Wed, 9 Jan 2002, Simon Glover wrote:
Two separate bugs:
1. The index checks should use and not ||, or else they'll always be
true.
2. The check in key_inc has an off-by-one error.
Simon
Better hold off on applying this patch; it makes test 5 in perlhash.t
fail (and yes, I know I should have checked this _before_ sending the
patch off).
Will do.
OK, I think I've got it this time. The previous patch uncovered a bug in
perlhash.pmc; index is actually the offset of a particular key pair
within the perlhash structure, so we need to ensure that key-size is
bigger than index.
This also threw up a bug in the test: since the index is an offset,
assigning to index 1 will create a hash with a size of 2.
Patches below; and this time all tests pass!
Simon
--- perlhash.pmc.oldWed Jan 9 18:51:59 2002
+++ perlhash.pmcWed Jan 9 18:52:03 2002
@@ -135,7 +135,7 @@
KEY* key = SELF-cache.struct_val;
KEY_PAIR key_pair;
if(index = key_size(INTERP,key)) {
- key_set_size(INTERP,key,index);
+ key_set_size(INTERP,key,index+1);
}
key_pair.type = enum_key_int;
key_pair.cache.int_val = value;
--- pmc_perlhash.t.old Wed Jan 9 18:57:03 2002
+++ pmc_perlhash.t Wed Jan 9 18:57:10 2002
@@ -91,17 +91,17 @@
output_is('CODE', OUTPUT, size of the hash);
new P0, PerlHash
- set P0, 1, 1
+ set P0, 1, 0
set I0, P0
print I0
print \n
- set P0, 1, 2
+ set P0, 1, 1
set I0, P0
print I0
print \n
- set P0, 1, 1
+ set P0, 1, 0
set I0, P0
print I0
print \n
Re: [PATCH] Fix index checking in key.c
At 07:15 PM 1/9/2002 +, Simon Glover wrote: OK, I think I've got it this time. The previous patch uncovered a bug in perlhash.pmc; index is actually the offset of a particular key pair within the perlhash structure, so we need to ensure that key-size is bigger than index. This patch instead of, or in addition to, the previous? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Fix index checking in key.c
On Wed, 9 Jan 2002, Dan Sugalski wrote: At 07:15 PM 1/9/2002 +, Simon Glover wrote: OK, I think I've got it this time. The previous patch uncovered a bug in perlhash.pmc; index is actually the offset of a particular key pair within the perlhash structure, so we need to ensure that key-size is bigger than index. This patch instead of, or in addition to, the previous? Dan In addition to. Simon
Re: [PATCH] Fix index checking in key.c [APPLIED]
At 07:19 PM 1/9/2002 +, Simon Glover wrote: On Wed, 9 Jan 2002, Dan Sugalski wrote: At 07:15 PM 1/9/2002 +, Simon Glover wrote: OK, I think I've got it this time. The previous patch uncovered a bug in perlhash.pmc; index is actually the offset of a particular key pair within the perlhash structure, so we need to ensure that key-size is bigger than index. This patch instead of, or in addition to, the previous? In addition to. Cool. Both applied and building--they'll go in as soon as the tests finish. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Problem with MANIFEST (missing io/io_unix.c)
Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies becuase the file isn't there... - D [EMAIL PROTECTED]
Re: Problem with MANIFEST (missing io/io_unix.c)
Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 (Embedded image moved to David M. Lloyd [EMAIL PROTECTED] file: 01/09/2002 02:27 PM pic22062.pcx) To: Parrot Internals [EMAIL PROTECTED] cc: Subject: Problem with MANIFEST (missing io/io_unix.c) Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies becuase the file isn't there... - D [EMAIL PROTECTED] pic22062.pcx Description: Binary data
Re: Problem with MANIFEST (missing io/io_unix.c)
At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote: Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. Weird. It's in my local MANIFEST from the patch, and CVS is convinced that it's up to date. Resync? To: Parrot Internals [EMAIL PROTECTED] cc: Subject: Problem with MANIFEST (missing io/io_unix.c) Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies becuase the file isn't there... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Problem with MANIFEST (missing io/io_unix.c)
Just resynced, still missing io/io_unix.c, interestingly the other new file in the patch (io_win32.c) made it in. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 (Embedded image moved to Dan Sugalski [EMAIL PROTECTED] file: 01/09/2002 02:45 PM pic16180.pcx) To: Melvin Smith/ATLANTA/Contr/IBM@IBMUS, David M. Lloyd [EMAIL PROTECTED] cc: Parrot Internals [EMAIL PROTECTED] Subject: Re: Problem with MANIFEST (missing io/io_unix.c) At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote: Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. Weird. It's in my local MANIFEST from the patch, and CVS is convinced that it's up to date. Resync? To: Parrot Internals [EMAIL PROTECTED] cc: Subject: Problem with MANIFEST (missing io/io_unix.c) Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies becuase the file isn't there... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk pic16180.pcx Description: Binary data
Re: Problem with MANIFEST (missing io/io_unix.c)
On Wed, 9 Jan 2002, Dan Sugalski wrote: At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote: Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. Weird. It's in my local MANIFEST from the patch, and CVS is convinced that it's up to date. Resync? After fresh resync: [usrodl@ohno io]$ ls -l total 31 drwxr-xr-x 2 usrodl other 512 Jan 9 13:26 CVS/ -rw-r--r-- 1 usrodl other 444 Jan 3 21:57 TODO -rw-r--r-- 1 usrodl other 13850 Jan 9 12:23 io.c -rw-r--r-- 1 usrodl other8000 Jan 9 12:23 io_stdio.c -rw-r--r-- 1 usrodl other7051 Jan 9 12:23 io_win32.c No io_unix.c *or* io_os.c for that matter. - D [EMAIL PROTECTED]
Re: Problem with MANIFEST (missing io/io_unix.c)
At 01:50 PM 1/9/2002 -0600, David M. Lloyd wrote: On Wed, 9 Jan 2002, Dan Sugalski wrote: At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote: Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. Weird. It's in my local MANIFEST from the patch, and CVS is convinced that it's up to date. Resync? After fresh resync: [usrodl@ohno io]$ ls -l total 31 drwxr-xr-x 2 usrodl other 512 Jan 9 13:26 CVS/ -rw-r--r-- 1 usrodl other 444 Jan 3 21:57 TODO -rw-r--r-- 1 usrodl other 13850 Jan 9 12:23 io.c -rw-r--r-- 1 usrodl other8000 Jan 9 12:23 io_stdio.c -rw-r--r-- 1 usrodl other7051 Jan 9 12:23 io_win32.c No io_unix.c *or* io_os.c for that matter. Found my error, and io_unix.c is now there for fetching. io_os.c went away. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Problem with MANIFEST (missing io/io_unix.c)
I suspect its the diff flags I use when I send to Dan. I use -urN (or --newfile) which should create the new file if it doesn't exist but this happened last time I made a new file as well. That always worked when I used to send patches to linux-kernel but I guess I could get with the program and learn CVS. :( Dan what flags to you give patch when applying a recursive diff? -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 (Embedded image moved to David M. Lloyd [EMAIL PROTECTED] file: 01/09/2002 02:50 PM pic05149.pcx) To: Dan Sugalski [EMAIL PROTECTED] cc: Melvin Smith/ATLANTA/Contr/IBM@IBMUS, Parrot Internals [EMAIL PROTECTED] Subject: Re: Problem with MANIFEST (missing io/io_unix.c) On Wed, 9 Jan 2002, Dan Sugalski wrote: At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote: Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but probably it got lost in the shuffle. Weird. It's in my local MANIFEST from the patch, and CVS is convinced that it's up to date. Resync? After fresh resync: [usrodl@ohno io]$ ls -l total 31 drwxr-xr-x 2 usrodl other 512 Jan 9 13:26 CVS/ -rw-r--r-- 1 usrodl other 444 Jan 3 21:57 TODO -rw-r--r-- 1 usrodl other 13850 Jan 9 12:23 io.c -rw-r--r-- 1 usrodl other8000 Jan 9 12:23 io_stdio.c -rw-r--r-- 1 usrodl other7051 Jan 9 12:23 io_win32.c No io_unix.c *or* io_os.c for that matter. - D [EMAIL PROTECTED] pic05149.pcx Description: Binary data
Re: Problem with MANIFEST (missing io/io_unix.c)
At 02:55 PM 1/9/2002 -0500, Melvin Smith wrote: I suspect its the diff flags I use when I send to Dan. I use -urN (or --newfile) which should create the new file if it doesn't exist but this happened last time I made a new file as well. That always worked when I used to send patches to linux-kernel but I guess I could get with the program and learn CVS. :( Dan what flags to you give patch when applying a recursive diff? Nope, that's not it. The file gets created just fine. For new, renamed, or deleted files I need to issue a CVS add, delete and add, or delete command, respectively. Forgot with that one. Driving CVS isn't something I'm great at, but I'm getting better with a lot of practice. Simon generally takes care of this, but he's a bit tied up at the moment. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] More index bugs
This time in perlarray.pmc; they're both simple off-by-one errors.
Patch below fixes.
I've also added a regression test to guard against the reoccurence of
the bug. I've put this, plus the existing PerlArray tests, in a separate
file, pmc_perlarray.t, in line with what we've done for hashes and
strings.
Simon
--- perlarray.pmc.old Wed Jan 9 20:00:42 2002
+++ perlarray.pmc Wed Jan 9 20:01:01 2002
@@ -156,7 +156,7 @@
KEY* key = SELF-cache.struct_val;
KEY_PAIR key_pair;
if(index = key_size(INTERP,key)) {
- key_set_size(INTERP,key,index);
+ key_set_size(INTERP,key,index+1);
}
key_pair.type = enum_key_num;
key_pair.cache.num_val = value;
@@ -182,7 +182,7 @@
KEY* key = SELF-cache.struct_val;
KEY_PAIR key_pair;
if(index = key_size(INTERP,key)) {
- key_set_size(INTERP,key,index);
+ key_set_size(INTERP,key,index+1);
}
key_pair.type = enum_key_string;
key_pair.cache.struct_val = value;
--- pmc.t.old Wed Jan 9 19:30:32 2002
+++ pmc.t Wed Jan 9 19:31:34 2002
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests = 58;
+use Parrot::Test tests = 57;
my $fp_equality_macro = 'ENDOFMACRO';
fp_eq macro J,K,L
@@ -814,36 +814,7 @@
foo
OUTPUT
-output_is('CODE', 'OUTPUT', array test);
- new P0,PerlArray
- set P0,1
- set I0,P0
- print I0
- print \n
-
- set P0,3,0
- set I1,P0,0
- print I1
- print \n
-
- set P0,2
- set P0,3.7,1
- set N1,P0,1
- print N1
- print \n
- set P0,3
- set P0,hey,2
- set S1,P0,2
- print S1
- print \n
-end
-CODE
-1
-3
-3.70
-hey
-OUTPUT
output_is(CODE, OUTPUT, if (P) - Int);
new P0, PerlInt
--- /dev/null Sat Mar 24 04:37:44 2001
+++ pmc_perlarray.t Wed Jan 9 19:54:39 2002
@@ -0,0 +1,80 @@
+#! perl -w
+
+use Parrot::Test tests = 3;
+
+output_is('CODE', 'OUTPUT', size of the array);
+ new P0,PerlArray
+set P0,0
+set I0,P0
+print I0
+print \n
+
+ set P0,1
+ set I0,P0
+ print I0
+ print \n
+
+set P0,5
+set I0,P0
+print I0
+print \n
+
+end
+CODE
+0
+1
+5
+OUTPUT
+
+output_is('CODE', 'OUTPUT', set/get by index);
+new P0,PerlArray
+ set P0,3,0
+ set I1,P0,0
+ print I1
+ print \n
+
+ set P0,2
+ set P0,3.7,1
+ set N1,P0,1
+ print N1
+ print \n
+
+ set P0,3
+ set P0,hey,2
+ set S1,P0,2
+ print S1
+ print \n
+
+end
+CODE
+3
+3.70
+hey
+OUTPUT
+
+output_is('CODE', 'OUTPUT', same, but with implicit resizing);
+new P0,PerlArray
+ set P0,3,0
+ set I1,P0,0
+ print I1
+ print \n
+
+ set P0,3.7,1
+ set N1,P0,1
+ print N1
+ print \n
+
+ set P0,hey,2
+ set S1,P0,2
+ print S1
+ print \n
+
+end
+CODE
+3
+3.70
+hey
+OUTPUT
+
+
+1;
--- MANIFEST.oldWed Jan 9 20:12:04 2002
+++ MANIFESTWed Jan 9 19:41:14 2002
@@ -199,6 +199,7 @@
t/op/macro.t
t/op/number.t
t/op/pmc.t
+t/op/pmc_perlarray.t
t/op/pmc_perlhash.t
t/op/pmc_perlstring.t
t/op/stacks.t
RE: The dreaded regex patch
Steve Fink: # On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote: # Okay, here it is. Attached is the regular expression patch. It # # Is rx_advance necessary? What's the difference between # # /R/ # # and # # /^(.*?R)/ # # if you count the parens $ $1 $2 ... instead of $1 $2 $3 ...? Er, that would combine $` and $. I assume you meant /^.*?(R)/ Well, here are my reasons: 1. Intuitiveness Start and end indices for the match are different psychologically from group start and end. 2. Indirections Start and end indices are stored in PerlArrays. Best to keep their use down to a minimum. 3. Understandability What's all this extra crap at the beginning of my regex? Why are we looking up group 0? 4. Right matching vs. backwards matching See the definition of the /r flag in the docs for rx_setprops. # Speed, I guess? # # (Okay, I really meant /\A([\w\W]*?R)/ ) # # Also, why specific opcodes for \w etc.? I would think you'd do those # as constants. (Constant bitmaps for 8-bit, or constant # MultiLevelFunkyThings for Unicode.) Optimization, m'boy. I can just do a bunch of less-than/greater-than tests. (Besides, rx_oneof currently doesn't use bitmaps because I was in a rush and couldn't figure out how to generate them more efficiently than just doing a binary search on text.) # I have a barely begun parrot RE implementation of my own, and a much # further along RE opcode generator optimizer, but no time to work on # either. Maybe I should dust off the optimizer. Go ahead. # The main thrust of the optimizer is to try to find portions of the RE # to collapse into a DFA (or DFA-like thing). For example, # /(?:foo|bar)d/ is matched identically with a DFA or NFA, while # /(?:need|needle)le(ss)?/ is not. But this quickly makes me wonder: are # optimizations like finding a fixed abc substring within the input # really any faster than walking through a lookup table-based state # machine? I don't buy the Boyer-Moore argument that it's faster because # you can advance by more than one character at a time -- you're # stuffing the input into the cache either way, you may as well look at # all of it. I suppose if you're doing funky backwards matching for # a+bc+ it cuts out some backtracking, but that seems tricky to ensure # you're matching the right stuff. /a+bc+/ works well, but # /grand(ma|mother)a+bc+/ had better be darn sure it doesn't bite off # grandma's toe. That was an *example*. Since I haven't run benchmarks, I cna't say if it would be faster or not--I'm just making the point that sometimes there are faster ways TDI than the literal translation. By the way, I welcome seeing other regex implementations. New approaches can only improve the final design. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 obra . hawt sysadmin chx0rs lathos This is sad. I know of *a* hawt sysamin chx0r. obra I know more than a few. lathos obra: There are two? Are you sure it's not the same one?
Re: CVS Diff Options Suggestion
Thanks Gregor, I think I'm the only one in the dark, Dan just has to handle what I send him since I don't have commit privs, so, heretofore, I've been unsure of how CVS worked with the remote repository when I can't commit my own changes. Basically what I've been doing is just checking out a CVS snapshot every day or so, and to keep it up to sync with my private tree I manually diff it, then apply my changes to the new tree, sometimes fixing conflics, re-diffing against the new up-to-date version, and submitting the patch. Yes its sad but I developed on linux-kernel over the years and survived. This is a lot of work sometimes but I've just not gotten used to using CVS nor am I sure how it would work if I used CVS locally, not having commit privs for the master, then resyncing from the master. I'm used to SourceSafe or similar where I can checkout and lock files, but not distributed control systems like CVS. Maybe some CVS gurus could enlighten me. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984 (Embedded image moved to Gregor N. Purdy [EMAIL PROTECTED] file: 01/09/2002 03:23 PM pic17700.pcx) To: Dan Sugalski [EMAIL PROTECTED] cc: Melvin Smith/ATLANTA/Contr/IBM@IBMUS, David M. Lloyd [EMAIL PROTECTED], Parrot Internals [EMAIL PROTECTED] Subject: CVS Diff Options Suggestion [was: Re: Problem with MANIFEST (missing io/io_unix.c)] Dan, Melvin and Co. -- I find that if I've used cvs add and cvs remove for any added or removed files, I can create a patch quite nicely from the root directory thusly: $ cvs -q diff -NauR ../foo.patch YMMV. Regards, -- gregor /Inspiration Innovation Excellence (TM)\ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \/ [[EMAIL PROTECTED]]$ ping osama.taliban.af PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data. From 85.83.77.67: Time to live exceeded pic17700.pcx Description: Binary data
Re: The dreaded regex patch
On Wed, Jan 09, 2002 at 12:44:45PM -0800, Brent Dax wrote: Steve Fink: # On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote: # # Also, why specific opcodes for \w etc.? I would think you'd do those # as constants. (Constant bitmaps for 8-bit, or constant # MultiLevelFunkyThings for Unicode.) Optimization, m'boy. I can just do a bunch of less-than/greater-than tests. (Besides, rx_oneof currently doesn't use bitmaps because I was in a rush and couldn't figure out how to generate them more efficiently than just doing a binary search on text.) I wonder if the optimization opcodes should be kept separate, so if you wanted to port regular expressions to a totally different type of input, it would be clear what the bare minimum are that need to be implemented. rxo_*? # The main thrust of the optimizer is to try to find portions of the RE # to collapse into a DFA (or DFA-like thing). For example, # /(?:foo|bar)d/ is matched identically with a DFA or NFA, while # /(?:need|needle)le(ss)?/ is not. But this quickly makes me wonder: are # optimizations like finding a fixed abc substring within the input # really any faster than walking through a lookup table-based state # machine? I don't buy the Boyer-Moore argument that it's faster because # you can advance by more than one character at a time -- you're # stuffing the input into the cache either way, you may as well look at # all of it. I suppose if you're doing funky backwards matching for # a+bc+ it cuts out some backtracking, but that seems tricky to ensure # you're matching the right stuff. /a+bc+/ works well, but # /grand(ma|mother)a+bc+/ had better be darn sure it doesn't bite off # grandma's toe. That was an *example*. Since I haven't run benchmarks, I cna't say if it would be faster or not--I'm just making the point that sometimes there are faster ways TDI than the literal translation. Oh, sorry. I wasn't responding to anything in your patch. Just general ramblings, mostly thinking about perl5's engine. I am very much in the nonliteral translation camp. (?:need|needle) - need(?:|le) - need(?:le)?? (?:needle|need) - need(?:le|) - need(?:le)? By the way, I welcome seeing other regex implementations. New approaches can only improve the final design. Naw, I'll probably just retarget the optimizer to your opcodes to avoid redundant work. Yours are extremely similar to mine, unsurprisingly. I just organized the internals a little differently.
[PATCH] (was Re: [PATCH] index shadow warning)
On Mon, Jan 07, 2002 at 09:34:05PM +, Nicholas Clark wrote: I believe that this patch gets all of these: Yes, right: --- ./include/parrot/vtable.h~Mon Jan 7 20:38:08 2002 +++ ./include/parrot/vtable.h Mon Jan 7 20:42:43 2002 What's an RCS header doing in an auto-generated file? I fell for it - I didn't spot that the ID was for vtable_h.pl not include/parrot/vtable.h This patch cures this, and changes index to idx to remove shadow warnings. Nicholas Clark --- vtable_h.pl~Mon Dec 31 16:15:23 2001 +++ vtable_h.pl Wed Jan 9 20:15:11 2002 @@ -1,3 +1,7 @@ +#!/usr/bin/perl + +# $Id: vtable_h.pl,v 1.8 2001/12/31 15:58:28 simon Exp $ + use Parrot::Vtable; my %vtable = parse_vtable(); @@ -5,17 +9,11 @@ open OUT, include/parrot/vtable.h or die $!; print OUT 'EOF'; -/* vtable.h - * Copyright: (When this is determined...it will go here) - * CVS Info - * $Id: vtable_h.pl,v 1.8 2001/12/31 15:58:28 simon Exp $ - * Overview: - * Defines the base PMC vtable structure - * Data Structure and Algorithms: - * History: - * Notes: - * References: - */ +/* +** !!! DO NOT EDIT THIS FILE !!! +** +** This file is generated automatically from 'vtable.tbl' by vtable_h.pl +*/ #if !defined(PARROT_VTABLE_H_GUARD) #define PARROT_VTABLE_H_GUARD --- vtable.tbl~ Sat Jan 5 12:49:16 2002 +++ vtable.tbl Wed Jan 9 20:14:57 2002 @@ -1,3 +1,4 @@ +# $Id: $ # This is the main vtable data # Lines have the following format: # method type \tab return type name \tab type arg1 \tab type arg2 @@ -24,26 +25,26 @@ unique INTVAL real_size unique void destroy unique INTVAL get_integer -unique INTVAL get_integer_indexINTVAL index -unique INTVAL get_integer_index_s STRING* index +unique INTVAL get_integer_indexINTVAL idx +unique INTVAL get_integer_index_s STRING* idx unique FLOATVAL get_number -unique FLOATVAL get_number_index INTVAL index -unique FLOATVAL get_number_index_s STRING* index +unique FLOATVAL get_number_index INTVAL idx +unique FLOATVAL get_number_index_s STRING* idx unique STRING* get_string -unique STRING* get_string_indexINTVAL index -unique STRING* get_string_index_s STRING* index +unique STRING* get_string_indexINTVAL idx +unique STRING* get_string_index_s STRING* idx unique BOOLVAL get_bool unique void* get_value unique BOOLVAL is_same PMC* pmc2 intvoid set_integerINTVAL value -unique void set_integer_index INTVAL valueINTVAL index -unique void set_integer_index_sINTVAL valueSTRING* index +unique void set_integer_index INTVAL valueINTVAL idx +unique void set_integer_index_sINTVAL valueSTRING* idx float void set_number FLOATVAL value -unique void set_number_index FLOATVAL value INTVAL index -unique void set_number_index_s FLOATVAL value STRING* index +unique void set_number_index FLOATVAL value INTVAL idx +unique void set_number_index_s FLOATVAL value STRING* idx strvoid set_string STRING* value -unique void set_string_index STRING* value INTVAL index -unique void set_string_index_s STRING* value STRING* index +unique void set_string_index STRING* value INTVAL idx +unique void set_string_index_s STRING* value STRING* idx unique void set_value void* value numvoid addPMC* value PMC* dest numvoid subtract PMC* value PMC* dest
Re: The dreaded regex patch [APPLIED]
At 03:16 AM 1/9/2002 -0800, Brent Dax wrote: Okay, here it is. Attached is the regular expression patch. It currently segfaults on Windows because of a combination of two factors: 1) There are some bounds-checking issues in key.c 2) Windows's malloc() isn't as robust as Unix's I've applied this, but all the tests fail. It's in anyway so folks can work with it, both to fix it and to see if it's the way we want to go. (Not being deep into the guts of the RE engine I'm not best to judge, I think) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Whups--regex stuff does work
If I apply the global_setup change it works a touch better... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some random design notes
On Wed, Jan 09, 2002 at 04:42:51PM +, Graham Barr wrote: On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote: # Attributes are done as a hash of hashes. Each interpreter has a # pointer to an attribute hash, whose keys are the attribute names. The # values will be hash pointers. Those hashes will each have a key which # is a PMC pointer (hashed up somehow) and the value is the attribute # value. If you're talking about 'is'-style attributes, why not have them be attached to the PMCs themselves? D'you want an attribute pointer for each PMC? (I've considered it, but for the moment I think it'll be too expensive. Might be wrong) This sounds rather like perl5's optional list of arbitrary 'magic'. Can't PMC's be 'upgraded' so only carry the overhead if needed? On the other hand when a variable is garbage collected you have to walk the hash of hashes to clear out the attributes. Also what happens when you move the PMC during garbage collection, will the key in the hash change ? Good points. A PMC may have a flag to show if it has any entries in the global table, but it is probably just a trade off between space and performance. Tim [who's not really been paying attention, so ignore me if I'm being daft].
