Re: Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
HaloO,
David Green wrote:
On 2008-Oct-22, at 10:03 am, TSa wrote:
Note that types have a fundamentally different task in a signature
than name and position have. The latter are for binding arguments to
parameters. The types however are for selection of dispatch target.
Names do that too; I think both names and types should be available for
both binding and dispatching, depending on what's more natural in a
given context. Sometimes we think in terms of names (I'm going to
Fred's place), sometimes in terms of types (I'm going to the grocery
store). (And some types are names (Dad)!)
I meant that only types are checked for specificity. In the first
stage of the dispatch when applicability is checked the named params
play a role, of course. But I've no idea how a named binding compares
to a typed positional one.
multi sub action (Hammer $hammer, Nail $nail) {...}
multi sub action (SledgeHammer $hammer;; Any :$object) {...}
How would these compare if we assume that SledgeHammer is more specific
than Hammer? Would the named param of the second sub be silently
promoted to positional?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Precompilation to PIR
Chris (): How safe is it today to pre-compile Rakudo code to PIR and expect that to behave identically to as if I compiled from .pm at runtime? I believe PCT is just generating PIR anyway, so my initial guess is that there should be no differences. Are there any gotchas, like compile-time dependency checks, that I should look out for? Precompilation to PIR currently doesn't work in the November project -- the difficulties occur when trying to call methods in the precompiled module. Right now our Makefile protests if someone tries to compile the modules to PIR. I think there is an rt ticket for this, but my attempts to dig it up fail. Maybe someone else is more lucky. // Carl
[perl #60164] [PATCH] make Test.pm methods return a boolean, like Test::More
# New Ticket Created by Chris Dolan # Please include the string: [perl #60164] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60164 The attached one-line patch makes Rakudo's Test.pm methods (ok(), is (), etc) return a boolean like their Test::More counterparts do. test-pm-return-value.patch Description: Binary data
[perl #60168] [PATCH] Refactor Junction.
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #60168]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60168
Hello.
I've (slightly) refactor Junction.pir.
1. Get rid of junction_comparision_helper. Use infix_junction_helper
instead.
2. In infix and unary junction helpers store original value in
ResultHash to avoid stringification of results.
--
Bacek
diff --git a/languages/perl6/src/classes/Junction.pir b/languages/perl6/src/classes/Junction.pir
index 9e5baca..bdbf01d 100644
--- a/languages/perl6/src/classes/Junction.pir
+++ b/languages/perl6/src/classes/Junction.pir
@@ -153,6 +153,10 @@ Clone v-table method.
.return(junc)
.end
+.sub 'VTABLE_get_string' :method :vtable('get_string')
+$S0 = self.'perl'()
+.return ($S0)
+.end
=item perl()
@@ -1080,21 +1084,21 @@ Override numerical equality for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:==
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:==' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:==
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:==' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:==
-.return junction_comparrison_helper($P0, j, x, 1)
+.return infix_junction_helper($P0, j, x, 1)
.end
@@ -1108,21 +1112,21 @@ Override numerical inequality for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:!=
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:!=' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:!=
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:!=' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:!=
-.return junction_comparrison_helper($P0, j, x, 1)
+.return infix_junction_helper($P0, j, x, 1)
.end
@@ -1136,21 +1140,21 @@ Override numerical greater than for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j, x, 1)
+.return infix_junction_helper($P0, j, x, 1)
.end
@@ -1164,21 +1168,21 @@ Override numerical less than for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:
-.return junction_comparrison_helper($P0, j, x, 1)
+.return infix_junction_helper($P0, j, x, 1)
.end
@@ -1192,21 +1196,21 @@ Override numerical greater than or equal to for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:=' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:=' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j, x, 1)
+.return infix_junction_helper($P0, j, x, 1)
.end
@@ -1220,21 +1224,21 @@ Override numerical less than or equal to for junctions.
.param pmc j1
.param pmc j2
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j1, j2, 0)
+.return infix_junction_helper($P0, j1, j2, 0)
.end
.sub 'infix:=' :multi('Junction',_)
.param pmc j
.param pmc x
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j, x, 0)
+.return infix_junction_helper($P0, j, x, 0)
.end
.sub 'infix:=' :multi(_,'Junction')
.param pmc x
.param pmc j
$P0 = find_global infix:=
-.return junction_comparrison_helper($P0, j, x, 1)
+.return
Re: Precompilation to PIR
On Oct 27, 2008, at 3:07 AM, Carl Mäsak wrote: Chris (): How safe is it today to pre-compile Rakudo code to PIR and expect that to behave identically to as if I compiled from .pm at runtime? I believe PCT is just generating PIR anyway, so my initial guess is that there should be no differences. Are there any gotchas, like compile-time dependency checks, that I should look out for? Precompilation to PIR currently doesn't work in the November project -- the difficulties occur when trying to call methods in the precompiled module. Right now our Makefile protests if someone tries to compile the modules to PIR. I think there is an rt ticket for this, but my attempts to dig it up fail. Maybe someone else is more lucky. // Carl Good to know. My tests were passing as PIR-compiled, but I only tested my grammar so far before I got roadblocked. I'll keep testing with and without PIR as time permits. Thanks! Chris
[perl #60160] [BUG] [PATCH] recursive use causes infinite loop.
# New Ticket Created by Chris Dolan # Please include the string: [perl #60160] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60160 The following simple test involves two .pm files that depend on each other. In revision 32120, this causes an infinite loop. The attached trivial patch prevents the loop by making Rakudo mark the modules as loaded before parsing them. This is how Perl5 behaves. === File lib/One.pm === use v6; use Two; === File lib/Two.pm === use v6; use One; === File test.pl === use v6; use One; % env PERL6LIB=./lib perl6 test.pl maximum recursion depth exceeded current instr.: 'parrot;PGE;Match;new' pc 25 (compilers/pge/PGE/ Match.pir:54) called from Sub 'parrot;Perl6;Grammar;pod_comment' pc 20852 (src/ gen_grammar.pir:981) called from Sub 'parrot;Perl6;Grammar;unv' pc 20526 (src/ gen_grammar.pir:850) called from Sub 'parrot;Perl6;Grammar;ws' pc 19642 (src/ gen_grammar.pir:487) called from Sub 'parrot;Perl6;Grammar;MARK_STATEMENT_END' pc 26706 (src/gen_grammar.pir:3276) called from Sub 'parrot;Perl6;Grammar;TOP' pc 1 (src/ gen_grammar.pir:204) called from Sub 'parrot;PCT;HLLCompiler;parse' pc 630 (src/PCT/ HLLCompiler.pir:384) called from Sub 'parrot;PCT;HLLCompiler;compile' pc 433 (src/PCT/ HLLCompiler.pir:302) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 834 (src/PCT/ HLLCompiler.pir:490) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1138 (src/PCT/ HLLCompiler.pir:627) called from Sub 'require' pc 13575 (src/gen_builtins.pir:8446) called from Sub 'use' pc 13601 (src/gen_builtins.pir:8459) called from Sub 'anon' pc 8 (EVAL_74:4) called from Sub 'parrot;Perl6;Grammar;Actions;_block555' pc 104287 (src/gen_actions.pir:1687) called from Sub 'parrot;Perl6;Grammar;Actions;use_statement' pc 104140 (src/gen_actions.pir:1639) called from Sub 'parrot;Perl6;Grammar;use_statement' pc 43456 (src/ gen_grammar.pir:9625) called from Sub 'parrot;Perl6;Grammar;statement_control' pc 32015 (src/gen_grammar.pir:5227) called from Sub 'parrot;Perl6;Grammar;statement' pc 26968 (src/ gen_grammar.pir:3386) called from Sub 'parrot;Perl6;Grammar;statementlist' pc 25021 (src/ gen_grammar.pir:2618) called from Sub 'parrot;Perl6;Grammar;statement_block' pc 23060 (src/ gen_grammar.pir:1846) called from Sub 'parrot;Perl6;Grammar;TOP' pc 18954 (src/ gen_grammar.pir:228) called from Sub 'parrot;PCT;HLLCompiler;parse' pc 630 (src/PCT/ HLLCompiler.pir:384) called from Sub 'parrot;PCT;HLLCompiler;compile' pc 433 (src/PCT/ HLLCompiler.pir:302) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 834 (src/PCT/ HLLCompiler.pir:490) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1138 (src/PCT/ HLLCompiler.pir:627) called from Sub 'require' pc 13575 (src/gen_builtins.pir:8446) called from Sub 'use' pc 13601 (src/gen_builtins.pir:8459) called from Sub 'anon' pc 8 (EVAL_73:4) [ ... 942 lines deleted ... ] called from Sub 'require' pc 13575 (src/gen_builtins.pir:8446) called from Sub 'use' pc 13601 (src/gen_builtins.pir:8459) called from Sub 'anon' pc 8 (EVAL_10:4) called from Sub 'parrot;Perl6;Grammar;Actions;_block555' pc 104287 (src/gen_actions.pir:1687) called from Sub 'parrot;Perl6;Grammar;Actions;use_statement' pc 104140 (src/gen_actions.pir:1639) called from Sub 'parrot;Perl6;Grammar;use_statement' pc 43456 (src/ gen_grammar.pir:9625) called from Sub 'parrot;Perl6;Grammar;statement_control' pc 32015 (src/gen_grammar.pir:5227) called from Sub 'parrot;Perl6;Grammar;statement' pc 26968 (src/ gen_grammar.pir:3386) called from Sub 'parrot;Perl6;Grammar;statementlist' pc 25021 (src/ gen_grammar.pir:2618) called from Sub 'parrot;Perl6;Grammar;statement_block' pc 23060 (src/ gen_grammar.pir:1846) called from Sub 'parrot;Perl6;Grammar;TOP' pc 18954 (src/ gen_grammar.pir:228) called from Sub 'parrot;PCT;HLLCompiler;parse' pc 630 (src/PCT/ HLLCompiler.pir:384) called from Sub 'parrot;PCT;HLLCompiler;compile' pc 433 (src/PCT/ HLLCompiler.pir:302) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 834 (src/PCT/ HLLCompiler.pir:490) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1138 (src/PCT/ HLLCompiler.pir:627) called from Sub 'require' pc 13575 (src/gen_builtins.pir:8446) called from Sub 'use' pc 13601 (src/gen_builtins.pir:8459) called from Sub 'anon' pc 8 (EVAL_9:4) called from Sub 'parrot;Perl6;Grammar;Actions;_block555' pc 104287 (src/gen_actions.pir:1687) called from Sub 'parrot;Perl6;Grammar;Actions;use_statement' pc 104140 (src/gen_actions.pir:1639) called from Sub 'parrot;Perl6;Grammar;use_statement' pc 43456 (src/ gen_grammar.pir:9625) called from Sub 'parrot;Perl6;Grammar;statement_control' pc 32015 (src/gen_grammar.pir:5227) called from Sub 'parrot;Perl6;Grammar;statement' pc 26968 (src/ gen_grammar.pir:3386) called from Sub 'parrot;Perl6;Grammar;statementlist' pc 25021 (src/ gen_grammar.pir:2618) called from Sub 'parrot;Perl6;Grammar;statement_block' pc 23060
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Oct 27 13:00:01 2008 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 43 new + 615 open = 658 Created this week: 18 Closed this week: 17 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 59984 [PATCH] languages/dotnet unsigned char bug 59980 [CAGE] 'make' warnings 59978 [TODO] Add SVN revision number of reports to Smolder front page 59968 [BUG] Calling Test::More sub after catching a div by zero exception segfaults 59926 [TODO][IMCC] Remove n_ code 59918 Re: building parrot 2 - 3 weeks old 59810 [PATCH] store hash seed in parrot_string_t struct 59720 [BUG] Parrot doesn't allow two HLLs to have a class of the same name 59696 [TODO] Unimplemented Unicode Functions 3 - 4 weeks old 4 - 5 weeks old 5 - 6 weeks old 58990 [TODO] Design new spec coverage mechanism 58980 [TODO][IMCC] .return in a .begin/end_return will be replaced by .set_return 58978 [TODO][IMCC] replace .result by .get_result 58976 [TODO][IMCC] .arg will be replaced by .set_arg 6 - 7 weeks old 58740 [CAGE] t/configure/*.t and t/steps/*.t: Cleanup test setup/teardown code 7 - 8 weeks old 58672 [TODO] implement method lookup iterators 58670 Parrot_print_backtrace() depends on __USE_GNU 58668 src/exceptions.c exposes brokenness in make cover 58590 [PATCH] dotnet make 58488 crashing parrot when calling create_lexinfo 8 - 9 weeks old 9 - 10 weeks old 58250 [TODO] Generate callgrind output 58188 [TODO] Parrot_find_encoding_converter 58108 [BUILD] languages/Makefile 'test' target has too many deps 58070 [RFC] Disallow .local declarations in long-style call statement 10 - 11 weeks old 58050 Segfault in make testr for t/compilers/imcc/syn/hll.t:2 11 - 12 weeks old 57680 [CAGE] Problems in find_write_record 57678 [CAGE] Poor Man's Deadlock Detection 57676 [CAGE] Check for shared status of STM handle 12 - 13 weeks old 57432 [DEPRECATED] [PDD19] .HLL_map with comma 57426 [TODO] [PDD19] Implement new .HLL directive 13 - 14 weeks old 57236 [TODO] pbc_to_exe --install pbc1 [pbc2...] 14 - 15 weeks old 57088 Tcl's [lsort] failure (aka inferior runloop problem) 15 - 16 weeks old 56782 [TODO] question in getNameForKey in Getopt::Obj 16 - 17 weeks old 56634 [RFC] future direction for config 17 - 18 weeks old 56458 Failure to promote RetContinuation objects 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues Platform Severity Tag Lang aix 1abandoned 05005threads 0 Amber 0 All 1fatal 1bounce0 BASIC 0 bsdos 0High 0Bug 108 bc 0 cygwin2low 1compiler 0 befunge 0 cygwin_nt 0medium2configure 3 bf 0 darwin8none 1core 2 cola0 dec_osf 0Normal1dailybuild0 forth 0 dgux 0unknown 0docs 3 jako0 dos 0Wishlist 3duplicate 0 Lisp0 dynixptx 0 install 2 lolcode 0 freebsd 5 library 0 m4 0 generic 0 notabug 0 ook 0 gnu 0 notok 0 perl6 2 HPUX 2 ok0 plot0 irix 0 Patch33 punie 0 irix640 regex 2 pynie 0 Linux 2 sendToCPAN0 python 0 lynxos0 Todo282 ruby0 mac 0 unknown 0 scheme 0 machten 0 utilities 0 tcl 0 macos 0 wontfix 0 urm 0 MacOS X 8Zcode 0 mswin32 2 netbsd1 next 0 openbsd 2 os2 0 os390 0 other 0 powerux 0 qnx 0 riscos0 sco 0 Solaris 7 sunos 1 svr4 0 svr5 0 sysv 0 unicos0 unicosmk 0 unix 0 unknown 0 uts 0 vms 0 VOS 0 Win32 8 --- Ticket Status By Version New or Open
Re: Why {{}} for regexp closures instead of just {}?
On Sun, Oct 26, 2008 at 10:45 PM, Chris Dolan [EMAIL PROTECTED] wrote:
S05 always uses single curlies for closures, but throughout Parrot, code
seems to use double curlies in PGE regexps. Why is that?
That is, why this:
m/ foo {{ say found foo }} /
and not this:
m/ foo { say found foo } /
The latter complains about Statement not terminated properly.
this is old PGE syntax that hasn't yet been updated to match S05. it's a bug.
or maybe, you can say that closures inside regexes aren't supported
yet, but rakudo has a feature that allows {{PIR}}} to work.
~jerry
Re: [perl #60128] [BUG] GC STRING segfault.
On Sun, Oct 26, 2008 at 11:17 AM, Will Coleda [EMAIL PROTECTED] wrote:
Turns out setting the conditional breakpoint never fired; left this
running overnight, and it eventually came back with the segfault
directly. Back to the drawing board.
Here is a very small snippet of tcl (with a single line of inline PIR)
that reproduces the problem for me (using feather, r32150 of parrot
and r124 of partcl)
proc a {} {info vars}
a
inline PIR {
.sub 'foo'
collect
.end
}
a
If run with parrot -G, the segfault goes away. gdb shows that the
location of the segfault hasn't changed even with the much smaller
test, it's still in ascii_compute_hash working on a STRING.
--
Will Coke Coleda
[perl #60166] [BUG] Exception handling in parrot doesn't unwind stack.
# New Ticket Created by Vasily Chekalkin # Please include the string: [perl #60166] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60166 Hello. Exception handling in parrot doesn't unwind used stack frames. Simple example: .sub 'main' .local pmc i i = new 'Integer' do_loop: say i push_eh do_inc $P0 = find_method i, succ i.$P0() pop_eh do_inc: inc i goto do_loop .end $ ./parrot ex.pir 1 2 ... 16353 16354 16355 Segmentation fault $ -- Bacek
[perl #60170] Segfault in verify_signature
# New Ticket Created by Will Coleda # Please include the string: [perl #60170] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60170 While trying to duplicate the tcl segfault in PIR, I was able to generate PIR that reliably segfaulted; except it turned out it was segfaulting a different way: .sub '__onload' :immediate load_bytecode 'TGE.pbc' push_eh class_loaded $P1 = subclass [ 'TGE'; 'Grammar' ], ['what'] pop_eh class_loaded: .end #0 0xb7e74958 in verify_signature (interp=0x804f040, ins=0x81ce4a8, pc=0x81ce590) at compilers/imcc/pbc.c:1734 #1 0xb7e752d2 in e_pbc_emit (interp=0x804f040, param_unused=0x0, unit=0x81cdf08, ins=0x81ce4a8) at compilers/imcc/pbc.c:1998 #2 0xb7e69726 in emit_flush (interp=0x804f040, param=0x0, unit=0x81cdf08) at compilers/imcc/instructions.c:879 ... This segfault doesn't is still present with -G -- Will Coke Coleda
Re: [perl #60170] Segfault in verify_signature
On Mon, Oct 27, 2008 at 12:14 PM, via RT Will Coleda [EMAIL PROTECTED] wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #60170] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60170 While trying to duplicate the tcl segfault in PIR, I was able to generate PIR that reliably segfaulted; except it turned out it was segfaulting a different way: .sub '__onload' :immediate load_bytecode 'TGE.pbc' push_eh class_loaded $P1 = subclass [ 'TGE'; 'Grammar' ], ['what'] pop_eh class_loaded: .end #0 0xb7e74958 in verify_signature (interp=0x804f040, ins=0x81ce4a8, pc=0x81ce590) at compilers/imcc/pbc.c:1734 #1 0xb7e752d2 in e_pbc_emit (interp=0x804f040, param_unused=0x0, unit=0x81cdf08, ins=0x81ce4a8) at compilers/imcc/pbc.c:1998 #2 0xb7e69726 in emit_flush (interp=0x804f040, param=0x0, unit=0x81cdf08) at compilers/imcc/instructions.c:879 ... This segfault doesn't is still present with -G -- Will Coke Coleda FYI, this appears in trunk in r32194. -- Will Coke Coleda
[perl #60172] segfault in expand_pcc_sub_call
# New Ticket Created by Will Coleda
# Please include the string: [perl #60172]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60172
.sub _main
($S0) = 'blah'(:pir_only=1)
.end
segfaults with:
0xb7e4fe84 in expand_pcc_sub_call (interp=0x804f040, unit=0x8116688,
ins=0x8120318) at compilers/imcc/pcc.c:706
706 if (!meth_call (the_sub-type VTADDRESS)) {
(gdb) bt
#0 0xb7e4fe84 in expand_pcc_sub_call (interp=0x804f040, unit=0x8116688,
ins=0x8120318) at compilers/imcc/pcc.c:706
#1 0xb7e40a93 in find_basic_blocks (interp=0x804f040, unit=0x8116688, first=1)
at compilers/imcc/cfg.c:261
--
Will Coke Coleda
Re: globs and rules and trees, oh my!
HaloO, Jon Lang wrote: This can already be done, for the most part: / (.does(ro)) / Mind you, this only searches a list; to make it search a tree, you'd need a drill-down subrule such as I outline above: / [* (.does(ro)) ]* / Isn't it the case that ~~ has very special dispatch semantics? First it is singly dispatched on the lhs, then the rhs determines the type of match. Now what if the lhs is a Tree? In general ~~ requires the lhs to provide some kind of iteration interface that the rhs uses when it e.g. backtracks. For a Tree there will be one default traversal mode and others can be requested by named arguments. That being said the interesting question is how much of the rule syntax can be generalized from string iteration to generic iteration. Another interesting case is a type as rhs. Here we need to combine signature matching with quantification. BTW, IIRC there are signatures in rules but I can't find it in S05. Where is it? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: globs and rules and trees, oh my!
On Mon, Oct 27, 2008 at 06:20:51PM +0100, TSa wrote: HaloO, Jon Lang wrote: This can already be done, for the most part: / (.does(ro)) / Mind you, this only searches a list; to make it search a tree, you'd need a drill-down subrule such as I outline above: / [* (.does(ro)) ]* / Isn't it the case that ~~ has very special dispatch semantics? First it is singly dispatched on the lhs, then the rhs determines the type of match. No. From S03: ... smart matches are dispatched first on the basis of the pattern's form or type (the [rhs]), and then that pattern itself decides whether and how to pay attention to the type of the topic [lhs]. Pm
Re: [perl #60152] if(something) is not treated as a sub call in Rakudo
On Sun, Oct 26, 2008 at 02:47:12PM -0700, Carl Mäsak wrote:
moritz_ rakudo: if(3 5) { say yes } # that should fail
Early experimentation indicates that this goes for unless, while,
until and given as well, and probably others I can't think of now.
Just for the record (since the ticket doesn't explicitly mention it),
this should result in a syntax error because the block is a term
in operator position (two terms in a row).
Pm
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
On Sun, Oct 26, 2008 at 09:37:36PM -0400, Bob Rogers wrote:
.sub 'main' :main
foo('Hello')
.end
.sub foo :multi(String)
.param pmc s
say s
.end
[...]
Which brings us to an interesting question: How can you decide what
type to use for autoboxing before you've determined the actual sub
you're going to call? And how can you find the sub without having the
correct dispatch types up front?
According to t/pmc/multidispatch.t, :multi can specify 'string',
'int', and 'num' to match the native (non-PMC) types:
.sub p :multi(string)
.param string s
print s
.end
.sub p :multi(string, string)
.param string opt
.param string s
if opt != '-twice' goto no_twice
print s
print s
.return()
no_twice:
print s
.end
Based on this, I would expect foo('hello') to dispatch to
a sub via :multi(string) and not dispatch to :multi(String).
As far as I can tell, this hasn't been deprecated anywhere, and
is explicitly recognized in pdd27 (line 43):
=item - Dispatch considers both low-level (register) types
and high-level (PMC) types, as well as inherited and composed types.
Returning to chromatic's original post, no applicable methods is
actually what I would expect from the code given, since there are
no methods defined taking the 'string' or 'int' type as the first
argument. If there's a version that does work using String and
Integer :multi's, then perhaps that's the one with the bug.
It's also possible that I'm completely misinterpreting the
:multi semantics, but that's the way things have tended to work
up to now, and I haven't seen any documentation or messages
that contradict it.
Pm
Re: [perl #60168] [PATCH] Refactor Junction.
On Mon, Oct 27, 2008 at 03:47:50AM -0700, Vasily Chekalkin wrote: I've (slightly) refactor Junction.pir. 1. Get rid of junction_comparision_helper. Use infix_junction_helper instead. 2. In infix and unary junction helpers store original value in ResultHash to avoid stringification of results. Okay to apply patch as long as spectest_regression still passes. I would prefer to eliminate the 'ResultHash' altogether -- elimination of any duplicate values should be done in the Junction constructor itself, not in the helper. Please don't close this ticket until that has been done. Note that all of this effectively disappears when we have the dispatcher handling Junctions properly -- i.e., the specialized operator functions defined in Junction really should not exist. Pm
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
On Sat, Oct 25, 2008 at 06:50:29AM -0700, François PERRAD via RT wrote: In fact, perl6.exe contains some dependencies on build tree. Just after a build, perl6.exe works : This is a known item -- see line 32 of languages/perl6/README: This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. We're not likely to do anything about this until Parrot installation is handled properly. I couldn't find a unique ticket for that issue -- when we find or create such a ticket we should probably list this ticket as a dependency on that. In the meantime, I'm marking this ticket as stalled. Thanks! Pm
Re: Argument scoping error or bug?
On Sat, Oct 25, 2008 at 10:52:13AM +0200, Moritz Lenz wrote: Chris Dolan wrote: I stumbled across this issue while descending into a recursive Match structure. Consider the following reentrant subroutine: You have just experienced this bug: http://rt.perl.org/rt3/Ticket/Display.html?id=58392 Recursion and for loops interact badly in Rakudo. Patrick is working on it. That said, I'm also looking for others to help work on it. But it's not a pretty bug, and it's deeply embedded in Parrot internals. :-) Pm
Re: [perl #60148] Degenerate unspace does not work in Rakudo
On Sun, Oct 26, 2008 at 01:00:03PM -0700, Carl Mäsak wrote:
Rakudo r32141 can understand unspaces consisting of a backslash
followed by whitespace, but not unspace consisting of only a
backslash.
$ ./perl6 -e 'my %h; %h{key} = value; say %h\ {key}' # works fine
value
$ ./perl6 -e 'my %h; %h{key} = value; say %h\{key}' # fails
Statement not terminated properly at line 1, near \\{\key\}
[...]
Same result for e.g. $a\++;
S02 says that both of the above should work and be eqivalent.
STD.pm r22787 says it's a parse failure, and we're following that.
19:13 pmichaud std: my %h; %h{key} = value; say %h\{key};
19:13 p6eval std 22787: OUTPUT[parse failure]
So I suspect it's a bug in STD.pm, also.
Pm
Re: [perl #60144] undef cannot be assigned to typed variables in Rakudo
On Sun, Oct 26, 2008 at 12:33:21PM -0700, Carl Mäsak wrote: Rakudo r32141 fails to accept undef as a value to typed variables. $ ./perl6 -e 'my Int $a = undef' Type check failed [...] Should work according to S02. Yes, this is a bug in Rakudo. We're likely to be revising all of assignment and container semantics soon, so this should be done as part of that. In general, any container can contain an undefined type (S02), and per a conversation on #perl6 assigning a Failure object causes its associated exception to be marked as unhandled [1]. In fact, I suspect this is true for any cloning of a Failure object. 1. http://irclog.perlgeek.de/perl6/2008-10-27#i_650223 Thanks, Pm
Re: [perl #60128] [BUG] GC STRING segfault.
On Mon, Oct 27, 2008 at 9:31 AM, Will Coleda [EMAIL PROTECTED] wrote: On Sun, Oct 26, 2008 at 11:17 AM, Will Coleda [EMAIL PROTECTED] wrote: Here is a very small snippet of tcl SNIP Attached is a PIR-only file (no tcl required) that triggers the same GC-related segfault (tested in r32210) -- Will Coke Coleda boom2.pir Description: Binary data
Re: [perl #60044] [BUG?] rethrow just throwing?
Patrick R. Michaud wrote: On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote: (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) backtrace Exactly the word I was looking for. Allison
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
From: Patrick R. Michaud [EMAIL PROTECTED]
Date: Mon, 27 Oct 2008 13:32:02 -0500
On Sun, Oct 26, 2008 at 09:37:36PM -0400, Bob Rogers wrote:
.sub 'main' :main
foo('Hello')
.end
.sub foo :multi(String)
.param pmc s
say s
.end
[...]
Which brings us to an interesting question: How can you decide what
type to use for autoboxing before you've determined the actual sub
you're going to call? And how can you find the sub without having the
correct dispatch types up front?
According to t/pmc/multidispatch.t, :multi can specify 'string',
'int', and 'num' to match the native (non-PMC) types . . .
Returning to chromatic's original post, no applicable methods is
actually what I would expect from the code given, since there are
no methods defined taking the 'string' or 'int' type as the first
argument.
All true. But it's unfortunate that the Parrot type system considers
int and Integer unrelated. As a result, MMD prevents autoboxing
(when chromatic and I had expected otherwise).
Which brings up another interesting (to me) question: Does anyone
know of an HLL in which the type system makes a formal distinction
between boxed vs. unboxed values? I am acquainted with only a few
languages that support boxing/unboxing, and all consider an int an int,
boxed or not.
-- Bob
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
On Monday 27 October 2008 19:26:31 Bob Rogers wrote: All true. But it's unfortunate that the Parrot type system considers int and Integer unrelated. As a result, MMD prevents autoboxing (when chromatic and I had expected otherwise). I'm not sure it's the type system as much as it is Parrot's Manhattan distance algorithm. I think I know how to promote primitive registers to their autoboxed PMCs in that function; Parrot's calling conventions should take care of the rest. Which brings up another interesting (to me) question: Does anyone know of an HLL in which the type system makes a formal distinction between boxed vs. unboxed values? I am acquainted with only a few languages that support boxing/unboxing, and all consider an int an int, boxed or not. Same here, though I note that Parrot's single-dispatch system considers an int an int. -- c
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
On Monday 27 October 2008 19:36:58 chromatic wrote: I think I know how to promote primitive registers to their autoboxed PMCs in that function; Parrot's calling conventions should take care of the rest. Fixed in r32211. All tests pass (including the TODO test I added for this). -- c
Re: [perl #60124] MMD Fails to Resolve with Autoboxing and :optional Parameters
From: chromatic [EMAIL PROTECTED] Date: Mon, 27 Oct 2008 20:00:50 -0700 On Monday 27 October 2008 19:36:58 chromatic wrote: I think I know how to promote primitive registers to their autoboxed PMCs in that function; Parrot's calling conventions should take care of the rest. Fixed in r32211. All tests pass (including the TODO test I added for this). -- c Cool; much less of a problem than I had expected. -- Bob
