Re: New vtable methods
At 11:29 PM -0700 8/18/02, Brian Ingerson wrote: >On 18/08/02 16:06 -0400, Dan Sugalski wrote: >> Okay, here's two new vtable methods >> >> freeze(PMC) - Responsible for freezing a PMC to the current freeze >> data stream. Throws an exception on error >> >> thaw(PMC) - A class method that thaws a PMC from the current >>thaw data stream >> >> Both of these should use the freeze/thaw API--I'll get that defined >> and out shortly. > >If I want to provide YAML serialization support at the Parrot level, would I >be able to simply override these methods? Nope. What you do instead is override the serialization/deserialization code that abstracts the freezing/thawing, which the PMCs use to serialize/deserialize themselves. :) I don't particularly want to specify a single blessed way of encoding the data, as I'm not sure what the best way to do it is. The only thing I think we will mandate is that the first bit of the data file reads something like: \n (only XML-y) just so we have a fixed string to parse out to make sure we can figure out how to process the data. I'd be OK adding an encoding in there too. The one thing I *don't* want is a proliferation of different encodings--then either we get interoperability problems with installs that lack a decoder, or we build in a zillion different ways to do the same damn thing, and that seems rather a waste. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #16269] [PATCH] COW...Again and Again
Mike Lambert wrote: > Note that the comparison against parrot-grey is not > exactly fair, because it dodn't use system stackwalking. Note that I have only commented out the call to the stackwalk function - for COW benchmarking purposes you could always reinstate it. But that is beside the point now - your COW has been fixed, and the benchmarks confirm that gc_generations is equally unfriendly to all cows. There will always be programs that don't benefit and therefore only get the overhead - but in typical perl usage, I would expect that the majority of programs will benefit significantly, for example regex capture will be able to use COWed substrings. This should finally bring about the demise of grey, as I don't believe there is room for two totally different implementations of COW, and my buffer linked list, which is already expensive, gets absurdly so with the addition of strstart also. -- Peter Gibbs EmKel Systems
[perl #16297] [PATCH] assemble.pl: no more hard coded PMC types
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16297]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16297 >
Hi,
attached patch gets rid of the propably hand crafted PMC types list by
using lib/Parrot/PMC.pm. The %pmc_types where created in lowercase
before, but, as there are no current users of %pmc_types, this should
not be a problem.
Please apply.
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34377/28106/8ee39e/assemble.pl.diff
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/34377/28107/bbf71f/pmc_pm.pl.diff
--- assemble.pl Sun Aug 18 08:54:22 2002
+++ /home/lt/src/parrot-007/assemble.pl Mon Aug 19 08:14:09 2002
@@ -15,7 +15,7 @@
If you would like to view the text after the macro expansion pass, use the C<-E>
flag. This flag simply tells the assembler to quit after the C class
-does it thing.
+does it thing.
The final pass replaces label occurrences with the appropriate PC offset and
accumulates the (finally completely numeric) bytecode onto the output string.
@@ -126,6 +126,9 @@
package Macro;
use Syntax qw($label_re $num_re);
+use FindBin;
+use lib "$FindBin::Bin/lib";
+use Parrot::PMC qw(%pmc_types);
=head2 Macro class
@@ -156,24 +159,9 @@
}
#
- # XXX Must be generated from the enum in include/parrot/pmc.h
#
bless $self,$class;
- $self->{constants}{Array} = 0;
- $self->{constants}{Boolean} = 1;
- $self->{constants}{PerlUndef} = 2;
- $self->{constants}{PerlInt} = 3;
- $self->{constants}{PerlNum} = 4;
- $self->{constants}{PerlString} = 5;
- $self->{constants}{PerlArray} = 6;
- $self->{constants}{PerlHash} = 7;
- $self->{constants}{Pointer} = 8;
- $self->{constants}{IntQueue} = 9;
- $self->{constants}{Sub} = 10;
- $self->{constants}{Coroutine} = 11;
- $self->{constants}{Continuation} = 12;
- $self->{constants}{CSub} = 13;
- $self->{constants}{MultiArray} = 14;
+ @{$self->{constants}}{keys %pmc_types} = values %pmc_types;
$self;
}
@@ -211,7 +199,7 @@
=item preprocess
Preprocesses constants, macros, include statements, and eventually conditional
-compilation.
+compilation.
.constant name {register}
.constant name {signed_integer}
@@ -422,7 +410,7 @@
Create a new Assembler instance.
- To compile a list of files:
+ To compile a list of files:
$compiler = Assembler->new(-files=>[qw(foo.pasm bar.pasm)]);
To compile an array of instructions:
@@ -700,7 +688,7 @@
=item constant_table
-Constant table returns a hash with the length in bytes of the constant table
+Constant table returns a hash with the length in bytes of the constant table
and the constant table packed.
=cut
@@ -708,13 +696,13 @@
sub constant_table {
my $self = shift;
-# $constl = the length in bytes of the constant table
+# $constl = the length in bytes of the constant table
my ($constl, $wordsize);
my $const = "";
$constl = $wordsize = $PConfig{'opcode_t_size'};
my $packtype = $PConfig{'packtype_op'};
-
+
for(@{$self->{constants}}) {
# if it's a string constant.
if ($_->[0] eq 'S') {
@@ -742,7 +730,7 @@
# if it's a float constant.
elsif ($_->[0] eq 'N') {
# The size of the whole constant.
-$constl += 2 * $wordsize + $PConfig{numvalsize};
+$constl += 2 * $wordsize + $PConfig{numvalsize};
# Constant type, N
$const .= pack($packtype,0x6e);
# Sizeof the Parrot floatval.
@@ -758,9 +746,9 @@
=item output_bytecode
-Returns a string with the Packfile.
+Returns a string with the Packfile.
-First process the constants and generate the constant table to be able to make
+First process the constants and generate the constant table to be able to make
the packfile header, then return all.
=cut
@@ -771,7 +759,7 @@
$wordsize = $PConfig{'opcode_t_size'};
my $packtype = $PConfig{'packtype_op'};
-
+
my %const_table = constant_table($self);
my $byteorder = (substr($PConfig{'byteorder'},0,1) == 1) ? 0 : 1;
@@ -1021,7 +1009,7 @@
});
}
-
+
package main;
use strict;
@@ -1101,7 +1089,7 @@
-E Preprocess input files and terminate processing
-h,--help Print this message
--o,--output Write file
+-o,--output Write file
-c,-checksyntax Check syntax only, do not generate bytecode
_EOF_
--- pmc_pm.pl Wed Jan 30 05:20:37 2002
+++ /home/lt/src/parrot-007/pmc_pm.pl Mon Aug 19 08:03:43 2002
@@ -14,12 +14,12 @@
EOF
$num = 0;
-while () {
+while () {
if (/enum_class_(\S+)/) {
my $name = $1;
$name =~ s/,$//;
last if $name eq "max";
-print OUT "\t\L$name => $num,\n";
+print OUT "\t$name => $num,\n";
$num++;
}
}
[perl #16296] [PATCH] warnings in lib/Parrot/Test.pm
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16296]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16296 >
Hi,
this patch removes ugly warnings for perl6's »make test«.
Please apply.
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34376/28103/3ec218/Test.pm.diff
--- Test.pm Thu Aug 15 09:48:18 2002
+++ /home/lt/src/parrot-007/lib/Parrot/Test.pm Mon Aug 19 10:30:23 2002
@@ -84,9 +84,9 @@
}
# Map the Parrot::Test function to a Test::Builder method.
-my %Test_Map = ( output_is => 'is_eq',
- output_isnt => 'isnt_eq',
- output_like => 'like'
+my %Test_Map = ( output_is => 'is_eq',
+ output_isnt => 'isnt_eq',
+ output_like => 'like'
);
my $count = 0;
@@ -138,15 +138,15 @@
}
}
- my %C_Test_Map = ( c_output_is => 'is_eq',
- c_output_isnt => 'isnt_eq',
- c_output_like => 'like'
+ my %C_Test_Map = ( c_output_is => 'is_eq',
+ c_output_isnt => 'isnt_eq',
+ c_output_like => 'like'
);
foreach my $func ( keys %C_Test_Map ) {
no strict 'refs';
-*{'Parrot::Test::'.$func} = sub ($$;$) {
+*{$package.'::'.$func} = sub ($$;$) {
my( $source, $output, $desc ) = @_;
++$count;
[perl #16298] [PATCH] pbc2c.pl startup
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16298]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16298 >
Hi,
attached patch uses now a similar startup code for native compiled
programs like test_main.c.
Please apply,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34380/28110/f984c9/pbc2c.pl.diff
--- pbc2c.plSun Aug 11 08:50:12 2002
+++ /home/lt/src/parrot-007/pbc2c.plMon Aug 19 08:39:15 2002
@@ -53,7 +53,7 @@
=cut
print "# Constants: $count entries\n";
-print "# ID FlagsEncoding Type Size Data\n";
+print "# ID FlagsEncoding Type Size Data\n";
my $constant_num = 0;
@@ -125,11 +125,11 @@
push @{$opcodes{$pc}->{args}}, @args;
$src = $op->full_body();
-
+
# The regexes here correspond to the rewriting rules for the various
# forms of goto recognized by Parrot/OpsFile.pm and Parrot/Op.pm
- # absolute address goto
+ # absolute address goto
while($src =~ /{{=(.*?)}}/g){
my $offset = $1;
$is_branch = 1;
@@ -161,7 +161,7 @@
$leaders{$new_pc} = 1 if $is_branch;
}
-my $enternative;
+my $enternative;
FINDENTERN:
foreach my $cur_op (@$Parrot::OpLib::core::ops) {
@@ -193,9 +193,11 @@
}
}
-print<
Re: [perl #15797] [PATCH] Regex speedup (with docs)
Sunday 18 August 2002 00:38, Simon Cozens wrote: > [EMAIL PROTECTED] (Dan Sugalski) writes: > > Has someone looked at and maybe committed this? > > The reason I asked which pieces of Parrot were prototypes was > because optimizing the hell out of something that's only a > prototype is nothing short of intellectual masturbation, and it > seems nobody actually learnt anything from my YAPC presentation > after all. One possible reason would be to learn if a speed problem is due to the design or the implementation. Sometimes you only know if something can be fast enough until you try it to optimize the hell out of it. Could you share with the ones of us who where not in YAPC what was this presentation about? -angel
[perl #16300] [BUG] hash clone hangs
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #16300] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16300 > Hi, recent changes in hash.c seems to hang[1] hash_clone. This patch works, but I don't know, if it is the correct way to solve the problem. [1] $perl6 -Rt -vwk t/compiler/a_2.p6 .. PC=726; OP=183 (clone_p_p); ... leo -- attachment 1 -- url: http://rt.perl.org/rt2/attach/34388/28119/3fe400/hash.c.diff --- hash.c Mon Aug 19 07:32:43 2002 +++ /home/lt/src/parrot-007/hash.c Mon Aug 19 11:52:21 2002 @@ -443,14 +443,14 @@ valtmp.type = enum_key_string; valtmp.val.string_val = string_copy(interp, b->value.val.string_val); -b = lookupBucket(hash, i); +//b = lookupBucket(hash, i); break; case enum_key_pmc: valtmp.type = enum_key_pmc; valtmp.val.pmc_val = b->value.val.pmc_val->vtable->clone( interp, b->value.val.pmc_val); -b = lookupBucket(hash, i); +//b = lookupBucket(hash, i); break; default:
Re: [perl #16274] [PATCH] Keyed access
On Sun, 18 Aug 2002, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Tom Hughes <[EMAIL PROTECTED]> wrote: > > > What I realised last night however is that there is enough space in > > the private flags on the PMC for the type information and I can then > > attach the data directly to the cache and do away with key atoms > > completely... I shall get on with that now and post a new patch later. > > Here is the new patch - this includes the above change as well as > most of the things Mike raised. > > It is also up to date with respect to the latest commits, including > patching the MultiArray PMC to work with the new scheme. At least I've > made the edits and think it will work, but as there don't seem to be > any tests for it I can't be sure. good job. /Josef > > Tom > > -- > Tom Hughes ([EMAIL PROTECTED]) > http://www.compton.nu/ >
Re: [perl #16038] [PATCH] multidim arrays reworked
On Sun, 18 Aug 2002, Dan Sugalski wrote: > At 3:50 PM -0400 8/17/02, Dan Sugalski wrote: > >At 3:07 PM +0200 8/14/02, Josef Hook wrote: > >>I've moved all code into one file now. > > > >Cool. Would someone commit this, please? > > Nevermind--I did. > -- thanks ! :-) il start improving it :-) > Dan > > --"it's like this"--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk >
GC vs REFCNT and cache
I am still _way_ behind on my perl6 e-mail but there has been a spate of discussion on gcc list about how garbage collector is bad for data-cache locality (particularly temporal locality). At least some of gcc folk are considering a switch to refcounts to try and get gcc-3.* back to nearer gcc-2.* compile-speed. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
Re: [DRAFT PPD] External Data Interfaces
"Brent Dax" <[EMAIL PROTECTED]> writes: Some comments on this > =item C Parrot_Int len, Parrot_String enc)> > > Allocates a Parrot_String and sets it to the first C bytes of > C. C is the name of the encoding to use (e.g. "ASCII", > "UTF-8", "Shift-JIS"); if a case-insensitive match of this name doesn't > result in an encoding name that Parrot knows about, or if NULL is passed > as the encoding, the platform's default encoding is assumed.[1] Values > of NULL and 0 can be passed in for C and C if the user > desires an empty string. > > Note that it is rarely a good idea to not specify the encoding if you're > using C and C. Are you sure you want encoding to be a Parrot_String which is also encoded. I think it would be better if it were a NUL terminated C-String in native encoding. Parrot_string_new (interp, "foobar", 6, "UTF-8") vs. Parrot_string_new (interp, "foobar", 6, Parrot_string_new (interp, "UTF-8", 5, NULL)) or Parrot_string_new (interp, "foobar", 6, Parrot_string_from_cstring (interp, "UTF-8")) Or there have to be predefined Strings like Parrot_encoding_ASCII The C-level API should not be unnessesary hard. [...] > =item C Parrot_String dest, char* bytes, Parrot_Int len, char* enc)> > > Sets C to the first C bytes of C and returns C. > C is taken to be the encoding of C; the Parrot_String will > retain its original encoding. (Call C on the > Parrot_String first if you want to retain C.) Here enc is a native char *. Either way, specifing encoding should be done in one and only one way. > =item C Parrot_String str)> > > Returns the encoding of C as a Parrot_String. If we go the way make encoding a C-String this should also be const char * Parrot_String_encoding (Parrot_Interp, Parrot_String) The life_time of this pointer can be specified as long as the interpreter lives (same as the Parrot_String) [...] > =item C > > Creates a new Parrot_PMC of the type C. If C is not a > case-insensitive match of any type already registered with Parrot, this > function will throw an exception. Ok, I think its a good thing to PMC-types in arbitary encodings. But it would be nice to have a convinience function Parrot_PMC Parrot_pmc_new_from_cstr (Parrot_Interp, const char *) [...] Just my EUR0.02 juergen -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #16300] [BUG] hash clone hangs
> recent changes in hash.c seems to hang[1] hash_clone. > This patch works, but I don't know, if it is the correct way to solve > the problem. Even if it is the correct way to solve the problem (which I don't know), it uses C++-style comments which are a no-no for Parrot's C target. Secondly, can you please turn off strip-trailing-whitespace in your editor? Your patches are reflecting the stripped spaces, which makes it hard to discern intentional changes from accidental ones. Thanks, Mike Lambert
Re: [perl #16300] [BUG] hash clone hangs
On Mon, Aug 19, 2002 at 11:31:23AM +, Leopold Toetsch wrote: > > recent changes in hash.c seems to hang[1] hash_clone. > This patch works, but I don't know, if it is the correct way to solve > the problem. > > [1] > $perl6 -Rt -vwk t/compiler/a_2.p6 > .. > PC=726; OP=183 (clone_p_p); ... Nope. Commenting that line out just re-introduces GC bugs. But you are correct; those two lines were wrong and trigger an infinite loop if your hashtable has more than one entry in any chain. Thanks for the catch. I have committed a fix.
[PATCH] comments in t/pmc/perlarray.t
Not very useful, but will reflect the truth. -- [EMAIL PROTECTED] 345c345 < # Make sure index zero is indeed 7 --- > # Make sure index zero is indeed -15 434c434 <# Make sure index zero is indeed 7 --- ># Make sure index zero is indeed -15 522c522 <# Make sure index zero is indeed 7 --- ># Make sure index zero is indeed -15 611c611 <# Make sure index zero is indeed 7 --- ># Make sure index zero is indeed -15
[PATCH] bug in Befunge interpreter
Sorry guys, I was putting the blame on you when trying to load a file not properly newline-terminated, but it was *all my fault*. Here's the patch. Jerome -- [EMAIL PROTECTED] diff -urbN parrot.orig/languages/Befunge-93/README parrot/languages/Befunge-93/README --- parrot.orig/languages/Befunge-93/README Sat Aug 17 02:18:34 2002 +++ parrot/languages/Befunge-93/README Mon Aug 19 21:18:02 2002 @@ -19,7 +19,7 @@ The -v flag makes the befunge interpreter more verbose. -NOTES +FILES - The files are the following: befunge.pasmthe main loop @@ -36,8 +36,6 @@ BUGS -* The befunge program *should* be properly newline terminated because - of Parrot's I/O... * The "input char" and "input int" instructions are a bit broken since Parrot does not handle I/O very well... @@ -66,8 +64,8 @@ idea. * Leon Brocard (again), because he told me he will help me with the Befunge-98 version :o) -* Dan Sugalski and all the parrot folks for providing such a nice toy - to play with. +* Dan Sugalski and all the parrot folks (you know who you are) for + providing such a nice toy to play with. COPYRIGHT diff -urbN parrot.orig/languages/Befunge-93/load.pasm parrot/languages/Befunge-93/load.pasm --- parrot.orig/languages/Befunge-93/load.pasm Sat Aug 17 02:18:34 2002 +++ parrot/languages/Befunge-93/load.pasm Mon Aug 19 21:16:58 2002 @@ -23,6 +23,7 @@ # Split the buffer around its newlines. LOAD_EOF: close P0 +concat S1, "\n" # Add a trailing newline if needed. length I0, S1 # I0 =length of the buffer set I1, 0 # I1 =ranges from 0 to I0 set I2, 0 # I2 =beginning of current line
[perl #16308] [PATCH] logical right shift
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #16308]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16308 >
This adds logical shift right opcodes. They are essential for bit shifting
negative values without sign extension getting in the way.
--
Jason
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34429/28142/d00f4b/lsr.diff
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.199
diff -u -r1.199 core.ops
--- core.ops18 Aug 2002 23:57:37 - 1.199
+++ core.ops19 Aug 2002 21:12:45 -
@@ -2854,6 +2854,19 @@
+=item B(out INT, in INT, in INT)
+
+Set $1 to the value of $2 logically shifted right by $3 bits.
+
+=cut
+
+inline op lsr(out INT, in INT, in INT) {
+ $1 = (INTVAL)((UINTVAL)$2 >> $3);
+ goto NEXT();
+}
+
+
+
=item B(inout INT, in INT)
=item B(inout PMC, in INT)
Index: t/op/bitwise.t
===
RCS file: /cvs/public/parrot/t/op/bitwise.t,v
retrieving revision 1.5
diff -u -r1.5 bitwise.t
--- t/op/bitwise.t 27 Jul 2002 20:18:12 - 1.5
+++ t/op/bitwise.t 19 Aug 2002 21:12:46 -
@@ -1,6 +1,6 @@
#perl -w
-use Parrot::Test tests => 18;
+use Parrot::Test tests => 20;
output_is(<<'CODE', <<'OUTPUT', "shr_i_i (>>)");
set I0, 0b001100
@@ -70,6 +70,37 @@
CODE
6
5
+OUTPUT
+
+# The crux of this test is that a proper logical right shift
+# will clear the most significant bit, so the shifted value
+# will be a positive value on any 2's or 1's complement CPU
+output_is(<<'CODE', <<'OUTPUT', "lsr_ic_ic (<<)");
+ lsr I2, -40, 1
+ lt I2, 0, BAD
+ print "OK\n"
+ end
+BAD:
+ print "Not OK"
+ print "\n"
+ end
+CODE
+OK
+OUTPUT
+
+output_is(<<'CODE', <<'OUTPUT', "lsr_i_i (<<)");
+ set I0, -40
+ set I1, 1
+ lsr I2, I0, I1
+ lt I2, 0, BAD
+ print "OK\n"
+ end
+BAD:
+ print "Not OK"
+ print "\n"
+ end
+CODE
+OK
OUTPUT
output_is(<<'CODE', <<'OUTPUT', "shl_i_i (<<)");
Re: [perl #16274] [PATCH] Keyed access
Tom Hughes wrote: > > In message <[EMAIL PROTECTED]> > Mike Lambert <[EMAIL PROTECTED]> wrote: > Oops. That only went in yesterday... Now fixed. > > > Overall, tho, the patch looks extemely complete. Tracing support, > > disassemble.pl support, debug.c support, etc. You even reduced macro > > usage. Rather impressive. :) Agreed. > The tracing, disassembly etc was mostly done when I found I needed > it to try and find a problem in the other things I'd done ;-) > > One other outstanding problem that I remembered last night is that > it is allocating memory for the key atom which is attached to the > cache.struct_val member on the PMC but which is never freed. > > Allocating that small piece of memory as a buffer which can be GCed > seems like complete overkill, but short of marking the PMC as having > a private GC so it can cleanup I hadn't managed to come up with a > solution. > > What I realised last night however is that there is enough space in > the private flags on the PMC for the type information and I can then > attach the data directly to the cache and do away with key atoms > completely... I shall get on with that now and post a new patch later. It's not quite applying against the current build, however. classes/default.pmc was easy to fix, assemble.pl not so simple, core.ops and hash.c had other problems. Could I trouble you to fix these so I can commit it tonight? I can send you the rejected hunks if you like... > Tom > > -- > Tom Hughes ([EMAIL PROTECTED]) > http://www.compton.nu/
Re: [perl #16274] [PATCH] Keyed access
Jeff wrote: > > Tom Hughes wrote: > > > > In message <[EMAIL PROTECTED]> > > Mike Lambert <[EMAIL PROTECTED]> wrote: > > Oops. That only went in yesterday... Now fixed. > > > > > Overall, tho, the patch looks extemely complete. Tracing support, > > > disassemble.pl support, debug.c support, etc. You even reduced macro > > > usage. Rather impressive. :) > > Agreed. > > > The tracing, disassembly etc was mostly done when I found I needed > > it to try and find a problem in the other things I'd done ;-) > > > > One other outstanding problem that I remembered last night is that > > it is allocating memory for the key atom which is attached to the > > cache.struct_val member on the PMC but which is never freed. > > > > Allocating that small piece of memory as a buffer which can be GCed > > seems like complete overkill, but short of marking the PMC as having > > a private GC so it can cleanup I hadn't managed to come up with a > > solution. > > > > What I realised last night however is that there is enough space in > > the private flags on the PMC for the type information and I can then > > attach the data directly to the cache and do away with key atoms > > completely... I shall get on with that now and post a new patch later. > > It's not quite applying against the current build, however. > classes/default.pmc was easy to fix, assemble.pl not so simple, core.ops > and hash.c had other problems. Could I trouble you to fix these so I can > commit it tonight? I can send you the rejected hunks if you like... Sorry about the QA comment, I just had someone point out to me that was mail server mangling. Many apologies. It -really- looks like a nice patch, if we can get these few problems ironed out. -- Jeff <[EMAIL PROTECTED]>
Re: [perl #16274] [PATCH] Keyed access
In message <[EMAIL PROTECTED]> Jeff <[EMAIL PROTECTED]> wrote: > Jeff wrote: > > > It's not quite applying against the current build, however. > > classes/default.pmc was easy to fix, assemble.pl not so simple, core.ops > > and hash.c had other problems. Could I trouble you to fix these so I can > > commit it tonight? I can send you the rejected hunks if you like... > > Sorry about the QA comment, I just had someone point out to me that was > mail server mangling. Many apologies. It -really- looks like a nice > patch, if we can get these few problems ironed out. I have a clean version that's up to date, and as everybody seems to be happy with it I'm going to go ahead and commit it now. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: [PATCH] bug in Befunge interpreter
Jerome Quelin wrote: > > Sorry guys, I was putting the blame on you when trying to load a file not > properly newline-terminated, but it was *all my fault*. > Here's the patch. Applied, thanks. -- Jeff <[EMAIL PROTECTED]>
Re: [perl #16274] [PATCH] Keyed access
Tom Hughes wrote: > > In message <[EMAIL PROTECTED]> > Jeff <[EMAIL PROTECTED]> wrote: > > > Jeff wrote: > > > > > It's not quite applying against the current build, however. > > > classes/default.pmc was easy to fix, assemble.pl not so simple, core.ops > > > and hash.c had other problems. Could I trouble you to fix these so I can > > > commit it tonight? I can send you the rejected hunks if you like... > > > > Sorry about the QA comment, I just had someone point out to me that was > > mail server mangling. Many apologies. It -really- looks like a nice > > patch, if we can get these few problems ironed out. > > I have a clean version that's up to date, and as everybody seems to > be happy with it I'm going to go ahead and commit it now. That I am. Thanks, Tom. -- Jeff <[EMAIL PROTECTED]>
[perl #16414] Interpreter PMC
# New Ticket Created by Steve Fink
# Please include the string: [perl #16414]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16414 >
Here's a patch that I have been threatening to implement for a while:
it makes a PMC that serves as a wrapper around the interpreter. So
instead of
interpinfo I0, 2
you would say
new P0, .Interp
set I0, P0["COLLECT_RUNS"]
or, if you really like using mysterious numbers,
new P0, .Interp
set I0, P0[2]
works just fine too. This patch doesn't do anything that interpinfo
can't already do. The fun starts when someone starts implementing the
set_*_keyed functions. Or, even without that, it might be kinda fun
(and maybe even useful) to make
set P1, "USER_STACK"
set I0, P1
print "User stack currently has "
print I0
print " entries.\n"
work (it'll require another wrapper PMC, this time for the stack.) And
then it's just a small step to
print "You hear a rumbling, and look behind you just in\n"
print "time to see the ceiling cave in and completely block\n"
print "the entrance. You notice that another passageway\n"
print "has been revealed.\n"
new P0, .Interp
set P1, P0["CONTROL_STACK"]
set_addr I0, DRAGONCAVE
set P1[-1], I0
ret # Get out the ketchup, boys!
Anyway, what do people think? (And who wants to implement clone?)
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34545/28254/cfe8bf/interp-pmc.patch
? include/parrot/varstacks.h
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.199
diff -p -u -r1.199 MANIFEST
--- MANIFEST19 Aug 2002 23:14:48 - 1.199
+++ MANIFEST20 Aug 2002 01:31:10 -
@@ -22,6 +22,7 @@ classes/coroutine.pmc
classes/csub.pmc
classes/default.pmc
classes/genclass.pl
+classes/interp.pmc
classes/intqueue.pmc
classes/key.pmc
classes/multiarray.pmc
@@ -472,6 +473,7 @@ t/op/time.t
t/op/trans.t
t/pmc/array.t
t/pmc/boolean.t
+t/pmc/interp.t
t/pmc/perlarray.t
t/pmc/perlhash.t
t/pmc/perlstring.t
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.89
diff -p -u -r1.89 assemble.pl
--- assemble.pl 19 Aug 2002 23:14:48 - 1.89
+++ assemble.pl 20 Aug 2002 01:31:13 -
@@ -174,6 +174,8 @@ sub new {
$self->{constants}{Continuation} = 12;
$self->{constants}{CSub} = 13;
$self->{constants}{MultiArray} = 14;
+ $self->{constants}{Key} = 15;
+ $self->{constants}{Interp} = 16;
$self;
}
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.34
diff -p -u -r1.34 global_setup.c
--- global_setup.c 19 Aug 2002 23:14:48 - 1.34
+++ global_setup.c 20 Aug 2002 01:31:13 -
@@ -37,6 +37,7 @@ init_world(void)
Parrot_Continuation_class_init(enum_class_Continuation);
Parrot_MultiArray_class_init(enum_class_MultiArray);
Parrot_Key_class_init(enum_class_Key);
+Parrot_Interp_class_init(enum_class_Interp);
/* Now register the names of the PMCs */
@@ -109,6 +110,10 @@ init_world(void)
key = key_new_string(NULL, Parrot_base_vtables[enum_class_Key].name(NULL, NULL));
Parrot_base_classname_hash->vtable->set_integer_keyed(NULL,
Parrot_base_classname_hash,
key, enum_class_Key);
+
+key = key_new_string(NULL, Parrot_base_vtables[enum_class_Interp].name(NULL,
+NULL));
+Parrot_base_classname_hash->vtable->set_integer_keyed(NULL,
+ Parrot_base_classname_hash,
+key, enum_class_Interp);
}
Index: t/pmc/interp.t
===
RCS file: t/pmc/interp.t
diff -N t/pmc/interp.t
--- /dev/null 1 Jan 1970 00:00:00 -
+++ t/pmc/interp.t 20 Aug 2002 01:31:13 -
@@ -0,0 +1,94 @@
+#! perl -w
+
+use Parrot::Test tests => 2;
+
+output_is(<<'CODE', <<'OUTPUT', "interp info indexed lookup");
+new P1, .Interp
+set I0, P1[0]
+set I0, P1[1]
+set I0, P1[2]
+set I0, P1[3]
+set I0, P1[4]
+set I0, P1[5]
+set I0, P1[6]
+set I0, P1[7]
+set I0, P1[8]
+set I0, P1[9]
+print "Got something, who knows what\n"
+ end
+CODE
+Got something, who knows what
+OUTPUT
+
+output_is(<<'CODE', <<'OUTPUT', "interp info string lookup");
+new P1, .Interp
+set I0, P1["TOTAL_MEM_ALLOC"]
+set I1, P1[0]
+gt I0, I1, mismatch
+print "TOTAL_MEM_ALLOC nondecreasing\n"
+
+set I0, P1["DOD_RUNS"]
+set I1, P1[1]
+gt I0, I1, mismatch
+print "DOD_RUNS nondecreasing\n"
+
+set I0, P1["COLLEC
"Functional" Perl6 compiler doesn't seem to be functioning
Maybe I'm just doing something wrong... I make parrot, which goes smoothly, then make IMCC, which chokes on "long long". Then I "perl pconfig.pl" and "make" and after two or three tries a full Perl6grammar.pm magically shows up. I'm still scratching my head over that one. Then when I try to run perl6, via "perl perl6" to avoid @INC issues, I get: "Code must live with a function" at line 219 in P6C/IMCC.pm. From what I gathered from trying to read that module, it appears that somehow $curfunc is getting undefined, and then never redefined. Trying to compile hw.p6. all I get is hw.warn. For what it's worth, all of this is taking place on Mac OS X 10.1.5. Anyone else run into this problem?
Re: "Functional" Perl6 compiler doesn't seem to be functioning
"Welcome, guests! (ah, fresh victims...)" On Tue, 20 Aug 2002, Chris Dutton wrote: > "Code must live with a function" at line 219 in P6C/IMCC.pm. From what > I gathered from trying to read that module, it appears that somehow > $curfunc is getting undefined, and then never redefined. This is a weird implementation artifact, which should probably be documented. While real Perl gathers up all the statements you put outside of any function into a sort of "main", for the time being you'll need to put all that in a no-argument sub called "main". I don't think this would be too hard to fix, but I haven't gotten around to it. /s
Re: "Functional" Perl6 compiler doesn't seem to be functioning
On Tuesday, August 20, 2002, at 01:11 AM, Sean O'Rourke wrote: > This is a weird implementation artifact, which should probably be > documented. While real Perl gathers up all the statements you put > outside > of any function into a sort of "main", for the time being you'll need to > put all that in a no-argument sub called "main". I don't think this > would > be too hard to fix, but I haven't gotten around to it. You think I'd have picked this up from reading the files in the test directory, but I just thought you'd been writing too much C. :-)
[PATCH PDD07] Document struct naming conventions
Since I'm lying in wait to apply the rules in force within most of the
core to Parrot_Interp, I figured I might as well document them. :^)
--- docs/pdds/pdd07_codingstd.pod 17 Jul 2002 02:57:18 -
1.6
+++ docs/pdds/pdd07_codingstd.pod 20 Aug 2002 07:02:15 -
@@ -371,27 +371,19 @@
=item *
All entities should be prefixed with the name of the subsystem they
appear
-in, eg C, C. They should be further prefixed
-with the word 'perl' if they have external visibility or linkage,
-namely, non-static functions, plus macros and typedefs etc which appear
-in public header files. (Global variables are handled specially; see
below.)
-For example:
-
-perlpmc_foo()
-struct perlio_bar
-typedef struct perlio_bar Perlio_bar
-#define PERLPMC_readonly_TEST ...
-
-In the specific case of the use of global variables and functions
-within a subsystem, convenience macros will be defined (in
-foo_private.h) that allow use of the shortened name in the case of
-functions (ie C instead of C), and hide the
-real representation in the case of global variables.
+in, eg C, C.
+=item *
+
+Functions with external visibility should be of the form C,
+and should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be all lower-case, eg C.
+See L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -400,11 +392,12 @@
=item *
-Typedef names should be lower-case except for the first letter, eg
-C. The exception to this is when the first component is a
-short abbreviation, in which case the whole first component may be made
-uppercase for readability purposes, eg C rather than
-C. Structures should generally be typedefed.
+Typedef names should be lower-case except for the first letter of each
+component, eg C. The exception to this is when the first
+component is a short abbreviation, in which case the whole first
component
+may be made uppercase for readability purposes, eg C rather
than
+C. Structures should generally be typedefed. See
+L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -443,8 +436,7 @@
Macros can be defined to cover common flag combinations, in which case
they
should have C<_SETALL>, C, C<_TESTALL> or <_TESTANY> suffixes
-as appropriate, to indicate aggregate bits, eg
-C
+as appropriate, to indicate aggregate bits, eg
C
=item *
@@ -476,6 +468,29 @@
{ DECL_STACK(sp); x = POPSTACK(sp); ... /* sp may or may not be
auto */
{ DECL_STACK; x = POPSTACK; ... /* anybody's guess */
+
+=back
+
+=item Structures and Typedefs
+
+Structures and typedefs have strict naming conventions designed to make
+it obvious at a glance what sort of thing you're dealing with.
+
+=over 4
+
+=item *
+
+The structure itself must have a name of the form C.
+
+=item *
+
+A typedef for internal use must be defined and be of the form C.
+
+=item *
+
+If the structure has external visibility, a second typedef of the form
+C must be provided; this must be typedefed as a pointer to
+the structure.
=back
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"Java golf. That'd be a laugh. 'Look, I done it in 15!' 'Characters?'
'No, classes!'"
--Ferret, in the Monastery
RE: [PATCH PDD07] Document struct naming conventions
Brent Dax:
# Since I'm lying in wait to apply the rules in force within most of the
# core to Parrot_Interp, I figured I might as well document them. :^)
Gah, got wrapped all funny. Here it's attached and sent to bugs-parrot.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"Java golf. That'd be a laugh. 'Look, I done it in 15!' 'Characters?'
'No, classes!'"
--Ferret, in the Monastery
? pdd7_patch.txt
Index: docs/pdds/pdd07_codingstd.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd07_codingstd.pod,v
retrieving revision 1.6
diff -u -r1.6 pdd07_codingstd.pod
--- docs/pdds/pdd07_codingstd.pod 17 Jul 2002 02:57:18 - 1.6
+++ docs/pdds/pdd07_codingstd.pod 20 Aug 2002 07:09:30 -
@@ -371,27 +371,19 @@
=item *
All entities should be prefixed with the name of the subsystem they appear
-in, eg C, C. They should be further prefixed
-with the word 'perl' if they have external visibility or linkage,
-namely, non-static functions, plus macros and typedefs etc which appear
-in public header files. (Global variables are handled specially; see below.)
-For example:
-
-perlpmc_foo()
-struct perlio_bar
-typedef struct perlio_bar Perlio_bar
-#define PERLPMC_readonly_TEST ...
-
-In the specific case of the use of global variables and functions
-within a subsystem, convenience macros will be defined (in
-foo_private.h) that allow use of the shortened name in the case of
-functions (ie C instead of C), and hide the
-real representation in the case of global variables.
+in, eg C, C.
+=item *
+
+Functions with external visibility should be of the form C,
+and should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be all lower-case, eg C.
+See L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -400,11 +392,12 @@
=item *
-Typedef names should be lower-case except for the first letter, eg
-C. The exception to this is when the first component is a
-short abbreviation, in which case the whole first component may be made
-uppercase for readability purposes, eg C rather than
-C. Structures should generally be typedefed.
+Typedef names should be lower-case except for the first letter of each
+component, eg C. The exception to this is when the first
+component is a short abbreviation, in which case the whole first component
+may be made uppercase for readability purposes, eg C rather than
+C. Structures should generally be typedefed. See
+L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -443,8 +436,7 @@
Macros can be defined to cover common flag combinations, in which case they
should have C<_SETALL>, C, C<_TESTALL> or <_TESTANY> suffixes
-as appropriate, to indicate aggregate bits, eg
-C
+as appropriate, to indicate aggregate bits, eg C
=item *
@@ -476,6 +468,29 @@
{ DECL_STACK(sp); x = POPSTACK(sp); ... /* sp may or may not be auto */
{ DECL_STACK; x = POPSTACK; ... /* anybody's guess */
+
+=back
+
+=item Structures and Typedefs
+
+Structures and typedefs have strict naming conventions designed to make
+it obvious at a glance what sort of thing you're dealing with.
+
+=over 4
+
+=item *
+
+The structure itself must have a name of the form C.
+
+=item *
+
+A typedef for internal use must be defined and be of the form C.
+
+=item *
+
+If the structure has external visibility, a second typedef of the form
+C must be provided; this must be typedefed as a pointer to
+the structure.
=back
[perl #16622] RE: [PATCH PDD07] Document struct naming conventions
# New Ticket Created by Brent Dax
# Please include the string: [perl #16622]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16622 >
Brent Dax:
# Since I'm lying in wait to apply the rules in force within most of the
# core to Parrot_Interp, I figured I might as well document them. :^)
Gah, got wrapped all funny. Here it's attached and sent to bugs-parrot.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"Java golf. That'd be a laugh. 'Look, I done it in 15!' 'Characters?'
'No, classes!'"
--Ferret, in the Monastery
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/34755/28465/494e5f/pdd7_patch.txt
? pdd7_patch.txt
Index: docs/pdds/pdd07_codingstd.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd07_codingstd.pod,v
retrieving revision 1.6
diff -u -r1.6 pdd07_codingstd.pod
--- docs/pdds/pdd07_codingstd.pod 17 Jul 2002 02:57:18 - 1.6
+++ docs/pdds/pdd07_codingstd.pod 20 Aug 2002 07:09:30 -
@@ -371,27 +371,19 @@
=item *
All entities should be prefixed with the name of the subsystem they appear
-in, eg C, C. They should be further prefixed
-with the word 'perl' if they have external visibility or linkage,
-namely, non-static functions, plus macros and typedefs etc which appear
-in public header files. (Global variables are handled specially; see below.)
-For example:
-
-perlpmc_foo()
-struct perlio_bar
-typedef struct perlio_bar Perlio_bar
-#define PERLPMC_readonly_TEST ...
-
-In the specific case of the use of global variables and functions
-within a subsystem, convenience macros will be defined (in
-foo_private.h) that allow use of the shortened name in the case of
-functions (ie C instead of C), and hide the
-real representation in the case of global variables.
+in, eg C, C.
+=item *
+
+Functions with external visibility should be of the form C,
+and should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be all lower-case, eg C.
+See L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -400,11 +392,12 @@
=item *
-Typedef names should be lower-case except for the first letter, eg
-C. The exception to this is when the first component is a
-short abbreviation, in which case the whole first component may be made
-uppercase for readability purposes, eg C rather than
-C. Structures should generally be typedefed.
+Typedef names should be lower-case except for the first letter of each
+component, eg C. The exception to this is when the first
+component is a short abbreviation, in which case the whole first component
+may be made uppercase for readability purposes, eg C rather than
+C. Structures should generally be typedefed. See
+L<"Structures and Typedefs"> for full naming conventions.
=item *
@@ -443,8 +436,7 @@
Macros can be defined to cover common flag combinations, in which case they
should have C<_SETALL>, C, C<_TESTALL> or <_TESTANY> suffixes
-as appropriate, to indicate aggregate bits, eg
-C
+as appropriate, to indicate aggregate bits, eg C
=item *
@@ -476,6 +468,29 @@
{ DECL_STACK(sp); x = POPSTACK(sp); ... /* sp may or may not be auto */
{ DECL_STACK; x = POPSTACK; ... /* anybody's guess */
+
+=back
+
+=item Structures and Typedefs
+
+Structures and typedefs have strict naming conventions designed to make
+it obvious at a glance what sort of thing you're dealing with.
+
+=over 4
+
+=item *
+
+The structure itself must have a name of the form C.
+
+=item *
+
+A typedef for internal use must be defined and be of the form C.
+
+=item *
+
+If the structure has external visibility, a second typedef of the form
+C must be provided; this must be typedefed as a pointer to
+the structure.
=back
