Re: Natural Language and Perl 6
Not long ago, yary proclaimed... This is getting more and more off topic, but if you want some lojban pasers, start at http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers I have a translation of the Lojban grammar in Perl 6 rules sitting around somewhere, possibly on an old, dead laptop. I've been thinking about reviving that, but haven't been able to find it yet. Maybe I'll just start over. It was quite nice for working with Lojban text. See, not so off-topic after all. :)
Re: Rakduo Logo Proposal
On Wed, 2009-03-18 at 16:43 +0100, Carl Mäsak wrote: Stephen (): Use of the gimel[1] character comes from Justin Simoni's logo design proposal[2] from a while back, and the design is a reference to the anarchist symbol[3]. It also looks like a reference to another programming language. http://en.wikipedia.org/wiki/Haskell_(programming_language) Lambda in a circle. We don't surround our letter with mathematical symbols, but the similarity is still there. // Carl Not anymore. As you can see here: http://www.haskell.org/logos/results.html the new haskell logo is http://haskell.org/logos/logos/logo7000.png , roughly spelled λ=
Rakduo Logo Proposal
I was inspired earlier today and had my girlfriend sketch up a logo proposal for me. http://pleasedieinafire.net/~tene/logo/gimelanarchy.html Use of the gimel[1] character comes from Justin Simoni's logo design proposal[2] from a while back, and the design is a reference to the anarchist symbol[3]. It wasn't designed with a specific reason beyond This would look cool, but there are a variety of associations that come to mind. The main association for me, with the reference to the anarchist symbol, is that we've kept going and produced something good despite the large sentiment of You're taking too long, you'll never succeed, etc. out there. Others include the somewhat chaotic state of Perl 6 development at times, the loose and informal organization in Perl 6 development, etc. Just an idea. Please discuss. [1]: http://en.wikipedia.org/wiki/Gimel#Hebrew_Gimel [2]: http://www.nntp.perl.org/group/perl.perl6.users/2009/01/msg938.html [3]: http://en.wikipedia.org/wiki/Anarchist_symbolism
Re: Rakudo repository -- svn or git?
Not long ago, Patrick R. Michaud proclaimed... Well, we're now at the point where it's time to move the Rakudo repository, and thus we need a decision on continuing to use svn for the repository or switching to git. Obviously staying with svn is very easy to handle. The other repositories that we have to coordinate with (parrot and pugs) are likely to remain in svn for the time being, so we know that things will work out well there. Switching the rakudo repository to git means that it would likely live on github, at least for a short time. We'd also have to provide mechanisms for people to continue to obtain and be able to easily commit to the pugs subversion repository. The existing mechanism (makefile calls svn to check out t/spec) will work fine unmodified with rakudo in git. I will be making a decision (and possibly starting the migration) tomorrow. If anyone has any strong opinions one way or another, please let them be known quickly. I'd also prefer that we not get into long discussions at this time -- there's been plenty of opportunity for that. Just state your preference and possibly a short statement of why you prefer that choice. I prefer to work with git. I feel a lot more confident that I won't screw things up with git. I'm more comfortable working with server-side branches with git. Feel free to weight my preference against my recent inactivity, though.
Re: 12 hackers hacking...
Not long ago, Mark J. Reed proclaimed...
What's the consensus on how to do an idiomatic countdown loop? I used
for [1..$n].reverse...
This: will work eventually:
for $n..1:by(-1) { ... }
This currently works in rakudo:
for (1..$n).reverse { ... }
Re: 12 hackers hacking...
Not long ago, Mark J. Reed proclaimed...
On Thu, Dec 25, 2008 at 1:55 AM, Stephen Weeks t...@allalone.org wrote:
This currently works in rakudo:
for (1..$n).reverse { ... }
No, it doesn't (r34384)
for (1..10).reverse { say $^i }
01 9 8 7 6 5 4 3 2 1
The list is flattened into a string and then reversed by character;
the body of the loop is executed only once. That's why I used the
square brackets in my version.
Looks like you found a regression. This has been fixed since r34393.
[swe...@kweh perl6]$ rakudo
for (1..10).reverse { .say }
10
9
8
7
6
5
4
3
2
1
[perl #61658] X operator behaves like comma
This isn't a bug. That's the correct behavior for the capital X operator, also called the cross operator. S03 defines it as: the X operator returns all possible lists formed by taking one element from each of its list arguments Perl 5's lowercase x operator has split into Perl 6's x and xx, which are 'string replication' and 'list replication'. [swe...@kweh ~]$ rakudo say (2 x 3).perl 222 say (2 xx 3).perl [2, 2, 2]
Resume from exception
do {
die 'some text';
say 'after the exception';
CATCH {
say 'caught the exception';
...; # what goes here?
}
}
My proposal is to call .resume() on the exception object.
Thoughts?
Resume from exception
do {
die 'some text';
say 'after the exception';
CATCH {
say 'caught the exception';
...; # what goes here?
}
}
My proposal is to call .resume() on the exception object.
Thoughts?
[perl #59538] [BUG] imcc freezes (compute_dominance_frontiers) -- Possible fix
Attached is a possible fix of this problem. I'm fairly certain that it's correct, but I'd like review from at least one other person befor eI commit it. 0001--imcc.patch Description: Binary data
[perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though. -- callgrind output
Attached is callgrind output from trying to compile rakudo with this patch. As you can see, the most-called functions by far are: /home/sweeks/src/parrot/compilers/imcc/sets.c:set_add /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominance_frontiers Profile data file 'callgrind.out.10513' (creator: callgrind-3.3.0) I1 cache: D1 cache: L2 cache: Timerange: Basic block 0 - 241100 Trigger: Program termination Profiled target: ../../parrot -o perl6.pbc perl6.pir (PID 10513, part 1) Events recorded: Ir Events shown: Ir Event sort order: Ir Thresholds: 99 Include dirs: User annotated: Auto-annotation: off Ir 25,725,945,395 PROGRAM TOTALS Ir file:function 13,455,028,108 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_add [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 11,209,537,812 /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominance_frontiers [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 135,234,114 /home/sweeks/src/parrot/compilers/imcc/imclexer.c:yylex [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 128,962,606 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_contains [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 88,825,729 /home/sweeks/src/parrot/compilers/imcc/imcparser.c:yyparse [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 70,349,560 /home/sweeks/src/parrot/compilers/imcc/instructions.c:instruction_reads [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 65,814,257 /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominators [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 56,483,518 /home/sweeks/src/parrot/compilers/imcc/instructions.c:instruction_writes [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 48,013,979 ???:_int_malloc [/lib64/libc-2.8.so] 46,419,350 /home/sweeks/src/parrot/compilers/imcc/pbc.c:constant_folding [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 33,201,086 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_intersec_inplace [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 29,624,696 /home/sweeks/src/parrot/compilers/imcc/symreg.c:hash_str [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 20,719,320 ???:calloc [/lib64/ld-2.8.so] 18,291,953 /home/sweeks/src/parrot/compilers/imcc/cfg.c:bb_check_set_addr [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 17,404,418 /home/sweeks/src/parrot/compilers/imcc/reg_alloc.c:compute_one_du_chain [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 13,809,278 /home/sweeks/src/parrot/compilers/imcc/imcc.l:yylex 12,337,246 /home/sweeks/src/parrot/src/ops/core_ops.c:hash_str [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 12,162,840 ???:memcpy [/lib64/ld-2.8.so] 11,450,969 ???:strcmp'2 [/lib64/ld-2.8.so]
Re: throw oddities in pdd23
Not long ago, Stephen Weeks proclaimed... Not long ago, Allison Randal proclaimed... Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. This has been reverted. I'll fix it and commit again sometime soon. Commit 31294 implements this behavior. Can I get confirmation that it's correct?
Re: throw oddities in pdd23
Not long ago, Stephen Weeks proclaimed... Not long ago, Patrick R. Michaud proclaimed... Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Pm This proposal has been implemented in the exceptionmagic branch. Looks like all tests are passing there without problem, although I'm not certain about a couple of the languages. Can I get some confirmation from someone else on the desirability of this proposal? This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree.
Re: throw oddities in pdd23
Not long ago, Allison Randal proclaimed... Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. This has been reverted. I'll fix it and commit again sometime soon.
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Not long ago, Patrick R. Michaud proclaimed... I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) I plan to add support for gather/take to cardinal. While we're discussing it, though, it might be fun to add it to lolcode, for purposes of flashy inter-hll demos.
Re: throw oddities in pdd23
Not long ago, Patrick R. Michaud proclaimed... Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Pm This proposal has been implemented in the exceptionmagic branch. Looks like all tests are passing there without problem, although I'm not certain about a couple of the languages. Can I get some confirmation from someone else on the desirability of this proposal?
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
I don't get a segfault when running the test case without the 'end' opcode. Can anyone else confirm if this still segfaults? cet.pir Description: Binary data
Re: Resumable exceptions
Not long ago, Patrick R. Michaud proclaimed... Here's a simple test for resumable exceptions that I'm trying to get to work. I'm probably coding/understanding something wrong, so any suggestions or pointers would be greatly appreciated. .sub main :main push_eh catcher 'foo'() pop_eh say 'ok 4' .return () catcher: .get_results ($P0, $S0) $P1 = $P0['retcont'] $P1() .end .sub 'foo' say 'ok 1' $P0 = new 'Exception' throw $P0 say 'ok 2' $P0 = new 'Exception' throw $P0 say 'ok 3' .end What I'm trying to do is to test the ability to resume after exceptions thrown by Cfoo. The Cmain sub above sets up a handler to catch exceptions, then calls Cfoo. The handler simply resumes any exception that is caught. The Cfoo sub prints 'ok 1', throws an exception, prints 'ok 2', throws another exception, and prints 'ok 3'. I can resume the first exception but not the second: $ ./parrot x.pir ok 1 ok 2 No exception handler and no message current instr.: 'foo' pc 46 (x.pir:20) called from Sub 'main' pc 29 (x.pir:10) $ Suggestions and corrections to my code welcomed. Check RT #58170 for this. Let me know if you need more detail on what's happening.
Re: language testing on pdd25cx, preparing to merge
Not long ago, Allison Randal proclaimed... After temporarily disabling the graph coloring register allocator, the pdd25cx branch passes all Parrot tests. Please run the tests for your language and report/debug any test failures that are different than the test failures in trunk. The plan is to merge the branch back into trunk on Friday or Saturday. Allison Cardinal passes all tests. Lolcode dies in lolcode;Grammar;Actions;expression with: No exception handler and no message
Re: [perl #53814] Named/Positional dispatch confusion
Not long ago, Patrick R. Michaud via RT proclaimed... There's a somewhat significant mismatch between Perl 6's handling of arguments and Parrot's handling of them; at the moment Rakudo is following the Parrot conventions. My guess at this point is that unless/until Parrot updates its calling conventions, Rakudo will at some point generate most of its subs as .sub 'a' .param pmc positional :slurpy .param pmc named :slurpy :named ... and then generate code to bind positional/named arguments to local lexicals according to P6 conventions. Won't that cause problems with signatures for MMD?
Re: [perl #31980] Factorial example gives incorrect result
Not long ago, Allison Randal via RT proclaimed... On Mon Feb 20 16:23:46 2006, jhoblitt !-- x -- at hawaii.edu wrote: On Tue, Feb 21, 2006 at 01:03:59AM +0100, Leopold Toetsch wrote: On Feb 20, 2006, at 23:44, Joshua Hoblitt via RT wrote: What happened to the factorial PASM example? It seems to have disappeared and it hasn't re-appeared as a PIR example either. It used bogus high numbers beyond int32 range and was just broken. Only because it was using integer registers. Limiting it to low factorial values or using Integer pmcs would resolve the issue. I'm going to add a PIR example using Integer pmcs unless there are any objections. Did you add the examples? I'd like to close the ticket. Allison The examples aren't on the website, but examples/pasm/fact.pasm is fixed as of r26432.
[perl #33962] readline returns one too many lines
This was never actually a bug, afaict.
Re: [perl #50492] AutoReply: [PATCH][lolcode] Allow arguments to functions. Pass parameters to the appropriate functions at runtime.
Not long ago, Stuart Jansen via RT proclaimed... I'm really glad to see you're still working on this, but I don't think this patch is ready to be merged yet. You've raised several points. Attached is a modified patch that addresses most of them. The largest problem with this patch is that it needs more explicit null checking in a few places. This version of this patch has operator support as well, and a pair of tests, one testing the math ops directly, and one also testing some more complicated expressions using the first twenty 'four fours' problems. Doesn't test slurpy functions and MKAY, though. I don't think this is correct behavior. VISIBLE is a statement, but it is not an expression. I can't find a defined return value for VISIBLE, nor can I find any evidence that VISIBLE should set IT. In additon, I can't find any evidence that '!' is a value. It is only a special syntax case for VISIBLE. This patch parses VISIBLE as an expression because that looks like the least awkward way of dispatching arguments to it properly. This patch explicitly checks for 'VISIBLE' in method statement, where the bind-to-IT nodes are emitted to skip emitting a binding to IT on VISIBLE statements. I've moved the ! handing into VISIBLE. As we discussed on IM, the alternative is explicitly emit a call to SMOOSH and duplicate method expression inside of method VISIBLE. I don't like this option much, but at least it avoids the explicit bang rules. I can write a version using an explicit SMOOSH for comparison. Function return values are a bit sketchy, but that's waiting on PAST support for return statements anyway, iirc. They can currently be accomplished using inline PIR. See /languages/ecmascript/src/parser/actions.pm for an example. Yes, but that is outside the scope of this patch. IT is properly returned, as it has been since that was added earlier. Functions can't return null values, as null is currently being used as the 'end of statement' marker in expr_parse. This will have to change. I interpret NOOB to be null. Function can return NOOB using GTFO, for example. This has been fixed. MKAY is currently passed along as a variable, as it's a reserved word anyway, and checked with issame, so nulls can be returned properly. Isn't NOOB more like Undef than null, though? Optional parameters to functions aren't dealt with properly. Auto-assignment to IT is still a bit sketchy. I'm unsure of the proper semantics here, but the test suite passes, so it's good enough for now. IT should only be set by a bare expression. Hence the special case in the grammar. The new handling for IT is not correct because bare expressions can consist of multiple tokens once we have proper support for operators. Is a 'bare expression' any expression which is not a call to VISIBLE? If so, this patch handles that appropriately. That's the meaning that I get out of my reading of the spec. -- Stuart Jansen [EMAIL PROTECTED] Guru Labs Index: languages/lolcode/t/99-four-fours.t === --- languages/lolcode/t/99-four-fours.t (revision 0) +++ languages/lolcode/t/99-four-fours.t (revision 0) @@ -0,0 +1,49 @@ +HAI 1.2 + VISIBLE 1..20 + + BTW 1 + VISIBLE ok SUM OF QUOSHUNT OF 4 AN 4 AN DIFF OF 4 AN 4 + + BTW 2 + VISIBLE ok SUM OF QUOSHUNT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 3 + VISIBLE ok QUOSHUNT OF SUM OF SUM OF 4 AN 4 AN 4 AN 4 + + BTW 4 + VISIBLE ok SUM OF PRODUKT OF DIFF OF 4 AN 4 AN 4 AN 4 + + BTW 5 + VISIBLE ok QUOSHUNT OF SUM OF PRODUKT OF 4 AN 4 AN 4 AN 4 + + BTW 6 + VISIBLE ok SUM OF QUOSHUNT OF SUM OF 4 AN 4 AN 4 AN 4 + + BTW 7 + VISIBLE ok DIFF OF SUM OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 8 + VISIBLE ok DIFF OF SUM OF 4 AN 4.4 AN 0.4 + + BTW 9 + VISIBLE ok SUM OF SUM OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 10 + VISIBLE ok QUOSHUNT OF DIFF OF 44 AN 4 AN 4 + + BTW 11 + VISIBLE ok SUM OF QUOSHUNT OF 4 AN 0.4 AN QUOSHUNT OF 4 AN 4 + + BTW 12 + VISIBLE ok QUOSHUNT OF SUM OF 44 AN 4 AN 4 + + BTW 13 + VISIBLE ok DIFF OF FAKTORIAL OF 4 AN QUOSHUNT OF 44 AN 4 + + BTW 14 + VISIBLE ok DIFF OF PRODUKT OF 4 AN DIFF OF 4 AN 0.4 AN 0.4 + + BTW 15 + VISIBLE ok DIFF OF PRODUKT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 16 + VISIBLE ok QUOSHUNT OF PRODUKT OF PRODUKT OF 4 AN 4 AN 4 AN 4 + + BTW 17 + VISIBLE ok SUM OF PRODUKT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 18 + VISIBLE ok SUM OF PRODUKT OF 44 AN 0.4 AN 0.4 + + BTW 19 + VISIBLE ok DIFF OF DIFF OF FAKTORIAL OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 20 + VISIBLE ok PRODUKT OF 4 AN SUM OF QUOSHUNT OF 4 AN 4 AN 4 + +KTHXBYE Index: languages/lolcode/t/05-math.t === --- languages/lolcode/t/05-math.t (revision 0) +++ languages/lolcode/t/05-math.t (revision 0) @@ -0,0 +1,38 @@ +HAI 1.2 + VISIBLE 1..11 + + BTW 1 + VISIBLE ok SUM OF -2 AN 3 + + BTW 2 +
Re: [perl #50492] AutoReply: [PATCH][lolcode] Allow arguments to functions. Pass parameters to the appropriate functions at runtime.
Okay, this works properly and 'make test' passes, varargs functions work
fine, VISIBLE is no longer special-cased, subs aren't stuffed into
lexicals when they're defined, they're properly looked up with
find_name, a couple of fixes.
Function return values are a bit sketchy, but that's waiting on PAST
support for return statements anyway, iirc.
Functions can't return null values, as null is currently being used as
the 'end of statement' marker in expr_parse.
Optional parameters to functions aren't dealt with properly.
Auto-assignment to IT is still a bit sketchy. I'm unsure of the proper
semantics here, but the test suite passes, so it's good enough for now.
Index: languages/lolcode/config/makefiles/root.in
===
--- languages/lolcode/config/makefiles/root.in (revision 25607)
+++ languages/lolcode/config/makefiles/root.in (working copy)
@@ -41,6 +41,7 @@
BUILTINS_PIR = \
src/builtins/say.pir \
+ src/builtins/expr_parse.pir \
src/builtins/var_or_function.pir
# PMCS = lolcode
Index: languages/lolcode/src/builtins/expr_parse.pir
===
--- languages/lolcode/src/builtins/expr_parse.pir (revision 0)
+++ languages/lolcode/src/builtins/expr_parse.pir (revision 0)
@@ -0,0 +1,146 @@
+=head1
+
+expr_parse.pir - parse an expression and dispatch function calls with their
appropriate arguments.
+
+=cut
+
+.namespace
+
+.sub 'expr_parse'
+.param pmc tokens :slurpy
+
+.local pmc can_has_debug
+can_has_debug = new 'Integer'
+
+.local pmc t_iter
+t_iter = new 'Iterator', tokens
+
+.local pmc sub_stack
+.local pmc val_stack
+.local pmc arity_stack
+
+sub_stack = new 'ResizablePMCArray'
+val_stack = new 'ResizablePMCArray'
+arity_stack = new 'ResizableIntegerArray'
+
+ it_loop:
+unless t_iter goto it_done
+ .local pmc item
+ .local pmc sub_to_call
+ .local pmc args_array
+ item = shift t_iter
+unless_null item, check_type
+ has_slurpy:
+ sub_to_call = pop sub_stack
+ $I0 = shift arity_stack
+ args_array = new 'ResizablePMCArray'
+ getting_varargs:
+$P1 = pop val_stack
+if_null $P1, call_the_sub
+unshift args_array, $P1
+goto getting_varargs
+ got_varargs:
+check_type:
+ $I0 = isa item, 'Sub'
+unless $I0 goto has_val
+ $P0 = inspect item
+ $I2 = $P0['pos_slurpy']
+ unless $I2 goto no_slurpy
+push sub_stack, item
+unshift arity_stack, -1
+$P0 = null
+push val_stack, $P0
+ goto end_fixed
+ no_slurpy:
+$I1 = item.arity()
+push sub_stack, item
+unshift arity_stack, $I1
+ end_fixed:
+ goto skip_val
+has_val:
+ push val_stack, item
+ $I0 = arity_stack[0]
+ $I0 -= 1
+ arity_stack[0] = $I0
+skip_val:
+call_check:
+ $I0 = arity_stack[0]
+ unless $I0 == 0 goto skip_call
+ sub_to_call = pop sub_stack
+ $I1 = sub_to_call.arity()
+ args_array = new 'ResizablePMCArray'
+args_loop:
+ if $I1 == 0 goto args_loop_end
+ $I1 -= 1
+ $P1 = pop val_stack
+ unshift args_array, $P1
+ goto args_loop
+args_loop_end:
+ $I2 = shift arity_stack
+ call_the_sub:
+ $P2 = sub_to_call(args_array :flat)
+ push val_stack, $P2
+ $I0 = arity_stack[0]
+ $I0 -= 1
+ arity_stack[0] = $I0
+ goto call_check
+skip_call:
+goto it_loop
+it_done:
+$I0 = elements sub_stack
+if $I0 == 0 goto no_leftover_function
+sub_to_call = pop sub_stack
+args_array = new 'ResizablePMCArray'
+$P2 = new 'Iterator', val_stack
+getting_more_varargs:
+ $I1 = elements val_stack
+ unless $I1 goto got_more_varargs
+ $P1 = pop val_stack
+ if_null $P1, got_more_varargs
+ unshift args_array, $P1
+ goto getting_more_varargs
+got_more_varargs:
+$P0 = sub_to_call(args_array :flat)
+push val_stack, $P0
+no_leftover_function:
+.local pmc return_val
+return_val = pop val_stack
+unless_null return_val, dont_return_nulls
+return_val = new 'Integer'
+return_val = 0
+dont_return_nulls:
+.return (return_val)
+.end
+# Local Variables:
+# mode: pir
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
+
Index: languages/lolcode/src/builtins/say.pir
===
--- languages/lolcode/src/builtins/say.pir (revision 25607)
+++ languages/lolcode/src/builtins/say.pir (working copy)
@@ -10,14 +10,20 @@
.sub 'VISIBLE'
.param pmc args:slurpy
-.param int no_newline :optional :named('no_newline')
+.local int no_newline
+no_newline = 0
.local pmc iter
iter = new 'Iterator', args
iter_loop:
unless iter goto iter_end
-$P0 = shift iter
-print $P0
+$S0 = shift iter
+
Re: [perl #50492] AutoReply: [PATCH][lolcode] Allow arguments to functions. Pass parameters to the appropriate functions at runtime.
This patch causes test failures due to its lack of support for varargs functions and special handling of VISIBLE. It's probably best not to apply this patch yet.
Re: parsing hangs forever, fixed with custom token ws
Not long ago, Klaas-Jan proclaimed... http://nopaste.snit.ch:8001/pastehas the grammar. this one is empty. You'd think I'd read the links I paste. http://nopaste.snit.ch:8001/11891
