[perl #75594] patch to remove need_ext fossils in pmcs
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75594]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75594
bash-3.2$ git diff
diff --git a/src/pmc/mutablevar.pmc b/src/pmc/mutablevar.pmc
index 1e5d075..0d083ac 100644
--- a/src/pmc/mutablevar.pmc
+++ b/src/pmc/mutablevar.pmc
@@ -19,7 +19,7 @@ needed as scalar containers forward to their contents.
#include parrot/parrot.h
-pmclass MutableVAR need_ext dynpmc group perl6_group auto_attrs {
+pmclass MutableVAR dynpmc group perl6_group auto_attrs {
ATTR PMC *scalar;
VTABLE void init() {
diff --git a/src/pmc/p6invocation.pmc b/src/pmc/p6invocation.pmc
index ccbf1df..f381837 100644
--- a/src/pmc/p6invocation.pmc
+++ b/src/pmc/p6invocation.pmc
@@ -135,7 +135,7 @@ static PMC *get_next_candidate(PARROT_INTERP, PMC
*SELF, int check_only, INTVAL
return current;
}
-pmclass P6Invocation need_ext dynpmc group perl6_group auto_attrs {
+pmclass P6Invocation dynpmc group perl6_group auto_attrs {
ATTR PMC*first_candidate;
ATTR PMC*candidate_list;
ATTR STRING *name;
diff --git a/src/pmc/p6lowlevelsig.pmc b/src/pmc/p6lowlevelsig.pmc
index c247b2e..99ad1e1 100644
--- a/src/pmc/p6lowlevelsig.pmc
+++ b/src/pmc/p6lowlevelsig.pmc
@@ -50,7 +50,7 @@ The number of items we have inside the signature.
*/
-pmclass P6LowLevelSig need_ext dynpmc group perl6_group manual_attrs {
+pmclass P6LowLevelSig dynpmc group perl6_group manual_attrs {
ATTR struct llsig_element **elements;
ATTR INTVAL num_elements;
ATTR PMC *named_to_pos_cache;
diff --git a/src/pmc/p6opaque.pmc b/src/pmc/p6opaque.pmc
index 1b12cf4..957280b 100644
--- a/src/pmc/p6opaque.pmc
+++ b/src/pmc/p6opaque.pmc
@@ -261,7 +261,7 @@ PMC *look_for_method(PARROT_INTERP, PMC
*search_list, INTVAL *start_pos, STRING
}
-pmclass P6opaque extends Object need_ext dynpmc group perl6_group auto_attrs {
+pmclass P6opaque extends Object dynpmc group perl6_group auto_attrs {
void class_init() {
ACCEPTS_str = CONST_STRING(interp, ACCEPTS);
diff --git a/src/pmc/p6role.pmc b/src/pmc/p6role.pmc
index 74602c4..b54a60f 100644
--- a/src/pmc/p6role.pmc
+++ b/src/pmc/p6role.pmc
@@ -19,7 +19,7 @@ like punning.
#include parrot/parrot.h
-pmclass P6role extends Role need_ext dynpmc group perl6_group auto_attrs {
+pmclass P6role extends Role dynpmc group perl6_group auto_attrs {
VTABLE PMC *find_method(STRING *name) {
PMC *ns_key, *ns, *punner, *boxed_name;
STRING *first_char;
diff --git a/src/pmc/perl6multisub.pmc b/src/pmc/perl6multisub.pmc
index d003c19..d302d2d 100644
--- a/src/pmc/perl6multisub.pmc
+++ b/src/pmc/perl6multisub.pmc
@@ -881,7 +881,7 @@ The proto that is in effect.
*/
-pmclass Perl6MultiSub extends MultiSub need_ext dynpmc group
perl6_group manual_attrs {
+pmclass Perl6MultiSub extends MultiSub dynpmc group perl6_group manual_attrs {
ATTR PMC *candidates;
ATTR struct candidate_info **candidates_sorted;
ATTR MMD_Cache *cache_single;
diff --git a/src/pmc/perl6scalar.pmc b/src/pmc/perl6scalar.pmc
index 74ec98e..f609641 100644
--- a/src/pmc/perl6scalar.pmc
+++ b/src/pmc/perl6scalar.pmc
@@ -18,7 +18,7 @@ Subclass of ObjectRef for Perl 6 scalars.
#include parrot/parrot.h
-pmclass Perl6Scalar extends ObjectRef need_ext dynpmc group
perl6_group auto_attrs {
+pmclass Perl6Scalar extends ObjectRef dynpmc group perl6_group auto_attrs {
}
--
cognominal stef
[perl #75600] [BUG] Rakudo doesn't give a warning or error when referring to capture which hasn't been made
# New Ticket Created by Carl Mäsak # Please include the string: [perl #75600] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75600 masak what's the semantics of $2 in a regex with fewer than three parentheses? masak rakudo: say foo ~~ /f(.)$2 o/ p6eval rakudo b258f5: OUTPUT«foo» masak alpha: say foo ~~ /f(.)$2 o/ p6eval alpha 30e0ed: OUTPUT«Null PMC access in get_string() [...] masak I have to confess I like alpha's reaction better in this case. * masak submits rakudobug jnthn Great, we spend all our time removing null PMC accesses... jnthn :P masak :) jnthn masak: I guess what you're saying is you want an error? masak aye. jnthn Or at least a warning. jnthn It's one of those things we should be able to spot and barf over at compile time though, I guess. masak since this is something that we can statically check for... masak right. masak rakudo: say foo ~~ / f $0 (.) / p6eval rakudo b258f5: OUTPUT«fo» jnthn masak: heh masak jnthn: that's why it must be wrong. Note that alpha's error is actually a runtime error. Still, it fortuitously prevents the outright erroneous match shown in the last evaluation.
[perl #75592] Long running unclosed quotes trigger unhelpful message
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75592]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75592
I am probably a lousy programmer but I hit again and again that
unhelpful message.
How to reproduce :
eval {\n\n\n\n\'}
Unable to parse blockoid, couldn't find final '}' at line 1
Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.
In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.
In more complicated cases, the quote rule reduces but it eats way more
characters than the programmer intended
inluding '}' chars that should terminate blockoids. The result is
triggering the same message or some others. I don't know if there is a
way to detect the true problem instead of emitting spurious messages.
Probably we should indicate the
reduced quotes involving many lines as suspicious when failing to
reduce a blockoid. They are bad style anyway because
heredocs are the preferred style for many lines quoted stuff. But
heredocs are not implemented yet.
--
cognominal stef
Re: [perl #75592] Long running unclosed quotes trigger unhelpful message
Am 07.06.2010 23:23, schrieb Stephane Payrard (via RT):
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75592]
# in the subject line of all future correspondence about this issue.
#URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75592
I am probably a lousy programmer but I hit again and again that
unhelpful message.
How to reproduce :
eval {\n\n\n\n\'}
Unable to parse blockoid, couldn't find final '}' at line 1
Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.
In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.
That's not what's happening.
The blockoid is embedded in the quote, so it fails first, and then the
quote rule fails.
If you're interested in fixing this, you might look at how STD.pm does
it. Some of its constructs are easily transferable into rakudo's
grammar, some not as easy (but need to be ported at some point anyway).
Cheers,
Moritz
[perl #75604] [BUG] [mod] doesn't work in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #75604] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75604 masak rakudo: say [mod] 100, 99, 88, 77, 66, 55, 44 p6eval rakudo 34c1ba: OUTPUT«===SORRY!===Could not find sub infix:mod» masak huh?colomon huh. masak rakudo: say 100 mod 99 p6eval rakudo 34c1ba: OUTPUT«1» * masak submits rakudobug colomon rakudo: say [div] 100, 99, 88, 77, 66, 55, 4 p6eval rakudo 34c1ba: OUTPUT«0» colomon something wrong with the ordering of .pm files in the build, maybe? moritz_ colomon: is it 'our' multi infix:mod? colomon maybe it's the our, that's the only difference I see from div
Re: [perl #75592] Long running unclosed quotes trigger unhelpful message
Also implementing :: will help for more precise errors reports. That one is one
pmichaud plate that is already full
On Tue, Jun 8, 2010 at 1:36 PM, Moritz Lenz via RT
perl6-bugs-follo...@perl.org wrote:
Am 07.06.2010 23:23, schrieb Stephane Payrard (via RT):
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #75592]
# in the subject line of all future correspondence about this issue.
#URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75592
I am probably a lousy programmer but I hit again and again that
unhelpful message.
How to reproduce :
eval {\n\n\n\n\'}
Unable to parse blockoid, couldn't find final '}' at line 1
Note that the opening quotes are many lines below the start of the
blockoid and there may be many statements between them.
So the line number in the error is unhelpful.
In the simplest case, the quote rules fails because the end of the
file has been reached. I don't see the need
to backtrack and to fail the blockoid.
That's not what's happening.
The blockoid is embedded in the quote, so it fails first, and then the
quote rule fails.
If you're interested in fixing this, you might look at how STD.pm does
it. Some of its constructs are easily transferable into rakudo's
grammar, some not as easy (but need to be ported at some point anyway).
Cheers,
Moritz
--
cognominal stef
[perl #75620] some exceptions throw you out of the rakudo shell
# New Ticket Created by Stephane Payrard # Please include the string: [perl #75620] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75620 I golfed the problematic statement to : $ perl6 lc ~$_ for Match.^methods lc ~$_ for Match.^methods get_string() not implemented in class 'ArrayIterator' $ say my mac is freaking me out # oops I was thrown out from the rakudo shell -- cognominal stef
[perl #75608] Storing PAST::Block as a rakudo scalar makes it unusable
# New Ticket Created by Aaron Sherman # Please include the string: [perl #75608] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75608 These two examples should behave the same: my $code = PAST::Compiler.compile(PAST::Block.new(PAST::Val.new( :value(1) ))); say $code(); my $block = PAST::Block.new(PAST::Val.new( :value(1) )); my $code = PAST::Compiler.compile($block); say $code(); The first correctly prints 1. The second gives this error: get_iter() not implemented in class 'Capture' The only difference between them is the intermediate storage in the Rakudo variable $block, which implies that either PAST::Compiler.compile cannot handle a rakudofied PAST::Block value or the storage of PAST::Block into $block alters its value irrevocably. Either way, this would appear to be a bug, and prevents any attempt to generate new code from within Rakduo without dropping down to a Q:PIR, and even then I'm not certain. All of this works fine in the bootstrapped compiler, of course, but in that case, NQP aliases these variables rather than letting Rakudo get its grubby little mitts all over them ;-) The relevant conversation from IRC: (10:18:39 AM) ajs: rakudo: my $code = PAST::Compiler.compile(PAST::Block.new(PAST::Val.new( :value(1) ))); say $code(); (10:18:42 AM) p6eval: rakudo 34c1ba: OUTPUT«1» (10:19:31 AM) ajs: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); my $code = PAST::Compiler.compile($block); say $code(); (10:19:33 AM) p6eval: rakudo 34c1ba: OUTPUT«get_iter() not implemented in class 'Capture' in main program body at line 11:/tmp/Gcz_AAWNc_» (10:19:45 AM) ajs: Anyone know why those two aren't the same? (10:20:47 AM) jnthn: rakudo: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); say alive (10:20:49 AM) p6eval: rakudo 34c1ba: OUTPUT«===SORRY!===Confused at line 11, near rakudo: my» (10:21:00 AM) jnthn: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); say alive (10:21:04 AM) p6eval: rakudo 34c1ba: OUTPUT«alive» (10:21:18 AM) pmichaud: PAST compiler might not know what to do with rakudo objectrefs (10:21:18 AM) jnthn: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); my $code = PAST::Compiler.compile($block); (10:21:20 AM) p6eval: rakudo 34c1ba: OUTPUT«get_iter() not implemented in class 'Capture' in main program body at line 11:/tmp/sXHbFObB83» (10:21:42 AM) jnthn: pmichaud: Oh, oddness. I'd have thought they'd be transparent to it. (10:21:59 AM) pmichaud: well, so would I, but normally we're doing binding instead of assignment in NQP (10:22:04 AM) jnthn: True. (10:22:18 AM) ajs: Yeah, and sadly that's not an option in Rakudo (10:22:30 AM) masak: submit a rakudobug? (10:22:32 AM) pmichaud: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); say PARROT($block) (10:22:35 AM) p6eval: rakudo 34c1ba: OUTPUT«Perl6Scalar-PAST;Block» (10:22:49 AM) ajs: Fair enough, just wanted to be sure I wasn't doing something stupid (10:23:17 AM) ajs: Hmmm pmichaud, you might be onto something there, let me try that out (10:23:19 AM) pmichaud: it may also be that PAST::Compiler isn't returning something that rakudo knows how to process (10:23:35 AM) jnthn: pmichaud: That worked in the pervious example though. (10:23:36 AM) ajs: It works fine in the first case (10:23:47 AM) pmichaud: oh, good point. (10:23:54 AM) jnthn: uh, previous :-) (10:23:57 AM) pmichaud: so I fall back to there's something weird about $block (10:24:43 AM) pmichaud: yes, I would expect it to be transparent... but perhaps it isn't for some reason. (10:24:53 AM) ajs: rakudo: my $block = PAST::Block.new(PAST::Val.new( :value(1) )); my $code = PAST::Compiler.compile(PARROT($block)); say $code(); (10:24:55 AM) p6eval: rakudo 34c1ba: OUTPUT«Null PMC access in type() in main program body at line 11:/tmp/cgP_Wd5cmw» (10:25:07 AM) ajs: OK, will go the bug route. Thanks all. (10:25:19 AM) pmichaud: yes, I'd be curious as to what that could possibly be. (10:26:01 AM) pmichaud: I'm also curious as to whether the get_iter is failing on a Parrot Capture or a Rakudo Capture (10:26:44 AM) jnthn: The latter would be very odd. (10:27:00 AM) pmichaud: agreed... but it's all a little odd to begin with (10:27:06 AM) jnthn: (Since we inherit from Parrot Capture...) (10:27:09 AM) jnthn: Troo. :-) -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: Digest module and Q:PIR blocks
On Mon, Jun 7, 2010 at 5:56 AM, Cosimo Streppone cos...@streppone.it wrote:
On Mon, 07 Jun 2010 02:11:05 +0200, Patrick R. Michaud pmich...@pobox.com
wrote:
On Sun, Jun 06, 2010 at 11:06:07PM +0200, Cosimo Streppone wrote:
Hi all,
Just for fun, I'm trying to write a Digest::MD5 module for Rakudo.
Right now I'm stuck with something like:
[...]
The MD5.pbc module loads into a different HLL namespace from
Rakudo ('parrot' instead of 'perl6'). So, you probably want
'get_root_namespace' here.
sub test($text) {
Q:PIR {
load_bytecode 'Digest/MD5.pbc'
$P0 = find_lex '$text'
$P1 = get_root_global ['parrot'], '_md5sum'
$P2 = $P1($P0)
$P1 = get_root_global ['parrot'], '_md5_hex'
$S2 = $P1($P2)
say $S0
}
}
test('hello world');
I guess you meant 'say $S2'.
Running this program for me (with --trace=1) results in a
segmentation fault somewhere in the _md5sum function.
Interesting, because it doesn't segfault for me. I get:
NULL PMC access in find_method('signature')
in 'test' at line 2:test.pl
in main program body at line 15:test.pl
My ignorant guess is that the signature() method is
available in the 'parrot' namespace, but not in my
current namespace.
This makes me think I'd prefer avoiding the globals business
and using the functions in their natural package (Digest?),
but I don't know how to do that.
I tried:
- find_method ['Digest'], '_md5sum'
- get_hll_global ['Digest'], '_md5sum'
- other futile attempts...
with no luck.
--
Cosimo
Here's my best guess:
sub test (Str $test) {
my $result = Q:PIR {
# This loads into the /current/ HLL, but should probably load into
# the /parrot/ HLL.
load_bytecode 'Digest/MD5.pbc'
.local pmc md5sum, md5hex, test
md5sum = get_root_global ['parrot'; 'Digest'], '_md5sum'
md5hex = get_root_global ['parrot'; 'Digest'], '_md5hex'
test = find_lex '$test'
%r = md5sum(test)
%r = md5hex(%r)
};
return $result;
}
test('hi');
... but this also fails with the 'signature' issue - note that Digest
doesn't have anything called 'signature'
I think this is related to the recent dynop issues - recent changes in
parrot moved a lot of opcodes into dynamic opcode libraries - stepping
through this, it dies in the invocation of the 'rot' opcode, which is
recently moved to the dynamic 'bit' ops. I'm guessing that when this
is invoked, it's actually invoking some perl6 opcode and going south.
Once this bug is fixed (it's related to loading opcode libraries in a
different order in the perl6 and Digest PBCs), this should work.
Regards.
--
Will Coke Coleda
Re: Digest module and Q:PIR blocks
On Tue, Jun 8, 2010 at 9:52 PM, Will Coleda w...@coleda.com wrote:
On Mon, Jun 7, 2010 at 5:56 AM, Cosimo Streppone cos...@streppone.it wrote:
On Mon, 07 Jun 2010 02:11:05 +0200, Patrick R. Michaud pmich...@pobox.com
wrote:
On Sun, Jun 06, 2010 at 11:06:07PM +0200, Cosimo Streppone wrote:
Hi all,
Just for fun, I'm trying to write a Digest::MD5 module for Rakudo.
Right now I'm stuck with something like:
[...]
The MD5.pbc module loads into a different HLL namespace from
Rakudo ('parrot' instead of 'perl6'). So, you probably want
'get_root_namespace' here.
sub test($text) {
Q:PIR {
load_bytecode 'Digest/MD5.pbc'
$P0 = find_lex '$text'
$P1 = get_root_global ['parrot'], '_md5sum'
$P2 = $P1($P0)
$P1 = get_root_global ['parrot'], '_md5_hex'
$S2 = $P1($P2)
say $S0
}
}
test('hello world');
I guess you meant 'say $S2'.
Running this program for me (with --trace=1) results in a
segmentation fault somewhere in the _md5sum function.
Interesting, because it doesn't segfault for me. I get:
NULL PMC access in find_method('signature')
in 'test' at line 2:test.pl
in main program body at line 15:test.pl
My ignorant guess is that the signature() method is
available in the 'parrot' namespace, but not in my
current namespace.
This makes me think I'd prefer avoiding the globals business
and using the functions in their natural package (Digest?),
but I don't know how to do that.
I tried:
- find_method ['Digest'], '_md5sum'
- get_hll_global ['Digest'], '_md5sum'
- other futile attempts...
with no luck.
--
Cosimo
Here's my best guess:
sub test (Str $test) {
my $result = Q:PIR {
# This loads into the /current/ HLL, but should probably load into
# the /parrot/ HLL.
Whoops. Leftover, incorrect comment.
load_bytecode 'Digest/MD5.pbc'
.local pmc md5sum, md5hex, test
md5sum = get_root_global ['parrot'; 'Digest'], '_md5sum'
md5hex = get_root_global ['parrot'; 'Digest'], '_md5hex'
test = find_lex '$test'
%r = md5sum(test)
%r = md5hex(%r)
};
return $result;
}
test('hi');
... but this also fails with the 'signature' issue - note that Digest
doesn't have anything called 'signature'
I think this is related to the recent dynop issues - recent changes in
parrot moved a lot of opcodes into dynamic opcode libraries - stepping
through this, it dies in the invocation of the 'rot' opcode, which is
recently moved to the dynamic 'bit' ops. I'm guessing that when this
is invoked, it's actually invoking some perl6 opcode and going south.
Once this bug is fixed (it's related to loading opcode libraries in a
different order in the perl6 and Digest PBCs), this should work.
Regards.
--
Will Coke Coleda
--
Will Coke Coleda
