% Ademan has joined #parrot r29183 | cotto++ | trunk: : [pmc] added test for get_bool, freeze/thaw and is_equal : All except freeze/thaw pass. RT #56718 has more details. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29183 % purl has left purl!~purl@florence.kuiki.net Did you TODO the failing ones? % purl has joined #parrot % Ademan has left Ademan!~dan@h-68-164-170-45.snfccasy.dynamic.covad.net r29184 | fperrad++ | trunk: : [Lua] : - fix #56694 (segfault in closure.pmc) diff: http://www.parrotvm.org/svn/parrot/revision?rev=29184 I did now. r29185 | cotto++ | trunk: : [pmc] TODO'd failing test diff: http://www.parrotvm.org/svn/parrot/revision?rev=29185 Perfect. La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever purl: bien dit. GeJ: excuse me? whoever added that banner to the public RT pages is awesome % Ademan has joined #parrot % clunker3 has left clunker3!~IRC@procura.xs4all.nl % barney has joined #parrot % iblechbot has joined #parrot % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net % cotto_home has left cotto_home!~cotto@96-26-202-243.sea.clearwire-dns.net % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au r29186 | bernhard++ | trunk: : [codingstd] remove trailing whitespace diff: http://www.parrotvm.org/svn/parrot/revision?rev=29186 % clunker3 has joined #parrot % desertmax has joined #parrot % kj has joined #parrot % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % clunker3 has left clunker3!~IRC@procura.xs4all.nl % kj has left kj!~IceChat7@193.1.104.7 r29187 | bernhard++ | trunk: : [Pipp PCT] Simplify rule 'concat_expression'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29187 % particle1 has left particle1!~particle@c-98-232-28-49.hsd1.wa.comcast.net % clunker3 has joined #parrot % pancake has left pancake!~pancake@core.fluendo.com r29188 | bernhard++ | trunk: : [Pipp PCT] Add test script t/php/concat.t. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29188 % kj has joined #parrot r29189 | bernhard++ | trunk: : [Pipp PCT] Add concatenation to optok parsing diff: http://www.parrotvm.org/svn/parrot/revision?rev=29189 % iblechbot has left iblechbot!~iblechbot@194.16-dial.augustakom.net % kj has left kj!~IceChat7@193.1.104.7 r29190 | bernhard++ | trunk: : [Pipp PCT] Try to simplify the grammar. : Move some productions from 'expression' to 'term'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29190 bernhard.schmalhofer@gmx.de | Pipp: link: http://www.perlfoundation.org/parrot/index.cgi?pipp % jan has joined #parrot r29191 | fperrad++ | trunk: : [build] on MinGW32 : fix the following linking error : : undefined reference to `CONST_STR' diff: http://www.parrotvm.org/svn/parrot/revision?rev=29191 % kid51 has joined #parrot r29192 | bernhard++ | trunk: : [Pipp PCT] are not needed in PAST generation. : Also put the delimiters at end of the respective statements. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29192 r29193 | bernhard++ | trunk: : [Pipp PCT] Fiddle with operator precedence table. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29193 r29194 | bernhard++ | trunk: : [Pipp PCT] Add relational ops to optok parsing. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29194 % kid51 has left kid51!~jkeen@pool-71-247-44-247.nycmny.east.verizon.net % cotto_home has joined #parrot r29195 | bernhard++ | trunk: : [Pipp PCT] Neater layout of the grammar declaration. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29195 % Whiteknight has joined #parrot r29196 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] updating to trunk r29195 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29196 % contingencyplan has joined #parrot % integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk r29197 | bernhard++ | trunk: : [Pipp PCT] more fiddling with grammar layout. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29197 % particle has joined #parrot % gryphon has joined #parrot r29198 | bernhard++ | trunk: : [Pipp PCT] Replace rule 'array_key' with rule 'expression'. : More layout-only changes. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29198 % iblechbot has joined #parrot % sjansen has joined #parrot % integral has joined #parrot % jhorwitz has joined #parrot % TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au % AndyAway has left AndyAway!~AndyL@host3130.follett.com % uniejo has left uniejo!~uniejo@193.88.64.250 % apeiron has joined #parrot % rdice has joined #parrot r29199 | bernhard++ | trunk: : [Pipp PCT] Add initial support for $this. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29199 % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net bernhard.schmalhofer@gmx.de | Parrot: link: http://www.perlfoundation.org/parrot/index.cgi?parrot % sjansen has left sjansen!~sjansen@206.83.88.66.ptr.us.xo.net % sjansen has joined #parrot r29200 | bernhard++ | trunk: : [Pipp] Try to make 'make test-php' work again. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29200 % jcm has joined #parrot bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers % gryphon has joined #parrot bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers barney++ #"the PHP desert" Although dessert is the food. Desert is the place. Christoph Otto | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers A silly way to remember is that dessert is fancy because it has two S's. just as many S's as "fancy" - oh, wait ;-) you want more dessert than you want desert well, that's true ;-) I'd rather be stuck on a dessert island than a desert island. as long as it's not solvable in water ;) *soluble Desserts is stressed backwards. r29201 | julianalbo++ | trunk: : Allow null arguments in split opcode, RT#54384 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29201 % kj has joined #parrot % desertmax_ has joined #parrot % desertmax has left desertmax!~markus@62-47-166-58.adsl.highway.telekom.at r29202 | bernhard++ | trunk: : [Pipp PCT] Use rule 'block' instead of ''. : Some more simplifications. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29202 jonathan: ping % desertmax_ has left desertmax_!~markus@62-47-173-157.adsl.highway.telekom.at r29203 | bernhard++ | trunk: : [Pipp PCT] use the rule 'param_list', with the parentheses. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29203 pmichaud: pong I'm wondering if signature binding is just a form of sub call for us. except that the "lexicals" refer to the outer scope. ...time to add that min parameter to the lexical search sub... Binding a signature will, as far as I had it laid out in my head, just do stuff to the lexicals in the caller's scope, yes. except I'm thinking it's actually a Parrot sub call i.e., we invoke the signature itself, and it does the bindings in the outer scope And generate every sub to just get a slurpy list and hash? And pass them flat? no And the signature worries about the binding? OK. I hadn't wanted to go that far, even if it's tempting in some ways. we _can_ do it that way, yes, and may have to, but that's not what I'm thinking Oooh he is soooo fine!!! My thought was compromise. We generate .param declarations that do about the right thing. I'm thinking that :($x) := foo() actually generates the :($x) part as a subroutine call But then pass it onto the signature object, to do the binding, and do any unpacking that is too complex for Parrot's calling conventions. sorry, actualy generates the :($x) part as a Sub definition I was going to construct a signature, and then := would become an invocation of a method on the signature objects. yes, but I'm not sure that's exactly what we want We need :(...) generally to make a signature object. my $x = :(...); sure, but can that signature object be a Sub ? I'm trying to avoid duplicating the binding code between Signature and normal routines I guess we could subclass sub...you just mean can it be invokable, right? i.e., the :named, :optional, :slurpy, etc. logic yes, I mean it can be invokable, we pass it whatever it's being bound to, and then it bind lexicals in the outer scope there's more. in the general multi-sub case, the dispatcher invokes a (multi) sub, but if there's an error in binding it throws an exception that tells the dispatcher to try the next candidate sub I suspect that signatures don't have a clue whether their variables exist in an outer scope it's the declarator that embeds them that worries about that, generally TimToady: yes, this would accommodate that, I think. so, :(my $x) would be illegal particle: yes, but my ($x) is legal. now I'm wondering about my $sig := my ($a,$b,$c); \(1,2,3) ~~ $sig and whether it binds the $a that my declares as opposed to $sig := :($a,$b,$c), which wouldn't does ~~ ever bind or assign? i always thought of it as compare/match never changing the lvalue or rvalue but i should look again at the table to be sure .ACCEPTS can have side effects matching a Signature returns true if it can bind r29204 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] diagnostically remove List_chunks from memory management. But doesn't actually bind it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29204 use when * -> ... { } for that, IIRC. I think it binds the variables blindly, and it doesn't know or care whether the variables exist outside the sig it depends on what kind of declaration the sig is part of Though trying to bind to something that doesn't exist, will be an error? the variables exist in the sig, but aren't aliased into any outer lexical scope I'm thinking of the case :($x) = foo() what $x are we referring to there? itself sorry, := :($x) := foo(); the name is a singleton :($) := foo() has the same effect with a null name r29205 | bernhard++ | trunk: : [Pipp PCT] Add rule 'literal' for use in rule 'member_definition'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29205 so the 'x' part is really a form of commentary, unless the sig is embedded in a larger declarator how about is is is a space alien So when we do the bind, we look up $x at binding time, rather than at signature declaration time? :(:who($name), :why($reason)) := (why => $because, who => "me"); I don't think that can work, the way I'm thinking of signatures currently I also don't think it's any great loss oh. I took that directly from S06. :-( Right. hee note that my (:who($name), :why($reason)) := (why => $because, who => "me"); still works because of the "my" and my declares $name and $reason? and, in fact, can reuse the same "my $name" declared earlier by the current rules Right. Because what is parsed between the (...) in a my is a signature. OH? It doesn't declare a new $name always? so then, if I'm understanding this correctly.... my $a; my ($a, $b); # not a redeclaration of $a? jonathan: nope, there can only be one $name in a lexical scope correct :($x) := foo(); simply tests that the binding occurs, but doesn't actually modify any $x That feels so wrong. or is otherwise not legal if you're looking up the dynamic stack for lexical scopes (say, to find a context var), you don't have to track the line number to know which $name I understand how my (:who($name)) := ... can work, no problem. TimToady: My comment about it being "so wrong" was in response to what pmichaud said about it not modifying $x it can warn you unless you declare $a as proto okay I mean, :($x) := foo(); just looks like something that should have some effect on $x. thus I think we have TimToady's comment "I don't think that can work..." ? t/syntax/signature.t needs to be converted and extended to spec tests these examples should be put there OK, but I don't get why it shouldn't be allowed to work. well, I suppose we could go the other way, and require $x to refer to something existing, but then you can't write a signature with vars as commentary And why "my (:($x)) := foo();" should work. and are forced to write :($,$,$,*@) and such ick. Hmmm. I see what you're getting at now, and I dislike that even more. in any case, we need to be consistent I think "my (:($x)) := foo();" isn't exactly right -- it's just my ($x) := foo(); Ah, OK. Yes, mis-read. well, it's a degenerate case of (:foo($x)) s/foo/othername/ well, wouldn't (:othername($x)) be a named-only param? except it's also sig syntax I'm just a little uncofortable that the only way to do unpack things with a signature requires a my, when the varialbes in it have already been declared. but if sigs are allowed to look outside for existing variables, we'll get people wanting things like sub foo ($*x) {...} i.e., my ($x) := foo(); and my (:othername($x)) := foo() are really different in terms of what foo() returns currently submethod BUILD ($!x) is kind of an exception, not a general policy Hmmm...true. Well, they can already have method foo($.x) Aha, OK. I figure "has ($.x, $.y)" is another case where you'd want to parse a signature with that in. and ($x) is really just the null twigil :) it's probably not really a syntactic decision, but something that either succeeds or fails in semantic analysis so you can parse sub foo ($*x) and get a syntax tree, but something downstream carps about it Sure, we already have various "can't use that twigil here" stuff in the actions. OK, so we're basically saying, the names in signatures only have the meaning that is provided by the declarator? but none of the twigil meanings in signatures currently imply lexical scope scanning, other than what the declaration context supplies one problem with this interpretion my ($a,$b,$c) is kinda defined as my :($a,$b,$c) with an optional : right. Right. that's what prompted this. :-) maybe we need a singleton sigil :) s/sigil/twigil But it's the "my" there that means, "the names in this signature are varialbes that we should declare" (if they aren't already declared in this scope) ah true now I'm confusing me own self so that's okay still and in the case of sub foo($a, $b) { ... } it's the fact that they appear in the sub declaration that gives them the "these are parameters to bind" meaning ('sub' is just another declarator) yes, it's implicitly a "my" context inside likewise for -> sort of a rewrite to my ($a,$b) := @_, as it were We could just have another declarator, which makes the meaning be "look up the names in the current scope and bind to them". 'sig' jonathan: that's called "my" :) what if the variables aren't 'my' variables, though? our $a; my $b; my ($a, $b) := ... There's that, and I'm also thinking of a way to do this without making it look like a redeclaration. or, if we want to bind to things with twigils so, perhaps 'sig' is the commentary varnames, leaving :(...) to do binding? or vice-versa? outside of the "our", $a looks like it was a my jonathan++. Seeing a visually rendundant 'my', just to get the variable binding semantic, will be confusing to me -- or at least cause a mental stutter. sig (my $a, our $b) ?? in any case, you can get a warning on the redeclaration unless you say proto our $a; proto my $b; above my $s = sig ($a, $b) ---> same as sig ($, $) so we have a way currently, but it's up at the top okay you mark the reusable name, not the re-use spot TimToady: but being forced to say 'my' at the reuse spot is jarring. { our $a; { my $b; my $s = sig ($a, $b); } } what, you never say "my dog Fido" twice in the same conversation? heh *in fact* { our $a; { my $b; my ($a, $b) := ...; } } one can test signature bindings using a null routine sub foo($x, $y) { ... } # foo is effectively :($,$) % Theory has joined #parrot % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com sorry, eliminate my ... there sub foo($x, $y) { } "barney" at 84.154.13.62 pasted "Should that work with Rakudo?" (40 lines) at http://nopaste.snit.ch/13538 yes, in terms of constraint checking, it's :($,$).ACCEPTS($capture) particle: In that case, since $a is in an outer scope, I guess even the "not declared with proto" thing wouldn't get you a warning you weren't declaring a new lexical. right yes, $a would be different, and $b would be the same TimToady: I get that, sure, but there aren't any computer languages I use where 'my dog Fido' or the moral equivalent can mean declaration the first time, and something very different (like, say, signature binding) in the second. (that == 'my dog Fido' joke) that's not what i'd want to happen barney: I don't know if initializers work on has declarators yet YOU GET A DIRE WARNING unless you say "proto" TimToady: Even in particle's example, where the variable name being "re-used" is declared in an outer scope? no, you get the warning on $b, not on $a { our $a; { proto my $b; my ($a, $b) := ...; } } Aha, OK, makes sense. But it still doesn't give us a way, to bind to the outer $a. { our $a; { proto my $b; my ($a, $b) := ...; #{$a is defined} } #{$a is undef} } does { proto our $a; { multi my $a; } } allow you to bind the outer $a? OK, perhaps this will help my confusion -- what is the recommended syntax to do this concept: 'sub foo($baz) { my ($a, $b); if $baz { :($a, $b) := bar() } else { :($a, $b) := quux() } say "a: $a, b: $b"; }' r29206 | cotto++ | trunk: : [pmc] added a test to exercise FixedPMCArray's is_equals. The test exposes a : bug, so it's TODO'd until a fix is found. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29206 fwiw, I think that the syntax japhb just get ought to be the recommended syntax (more) and that signature w/commentary variables is simply "sub ($a, $b) { ... }" or w/o the ... or with a special declarator 'sig' that doesn't require a body: "sig ($a, $b);" pmichaud: This makes sense to me. (or a semi, in that mis-typed example) perhaps that huffman-codes the wrong way -- I haven't thought about it much. I'm just going off-the-top-of-my-head well, there's always OUTER:: and MY:: TimToady: so how would you write my example? :(OUTER::<$a>)= 1 might work := rather hrmm and the limit on sub foo ($*x) is not imposed by the sig, but by the sub of course, then you need to know how many OUTER:: scopes above $a was declared so :(GLOBAL::<$x>) := 1 probably even works but that tends to point toward :($x) also doing the normal thing and looking in MY:: I don't quite understand "the limit on sub foo ($*x)" comment. (I don't necessarily need to understand it, but...) well, it's not really an impossible thing for a sub to bind to a global parameter, but it's just kind of one of those policies that you probably want to enforce for sanity or not... TimToady: It feels strange to use a pseudo-package there, when to someone writing { my $a; ...stuff...; :([$a, @]) := foo() } style things wouldn't really thing of $a is being in anything other than the current scope visually (as in, where the curlies are). s/thing/think/ s:2nd/thing/think/ :-) yes, and we do have the bare $ syntax to mean the other thing I wasn't recommending that 'sub foo ($*x)' be allowed to bind to a global param. (I.e., I still don't understand.) so the sane thing is probably to treat :($a,$b) := consistently with ($a,$b) = if :($a,$b) := 1,2; works on existing vars, then so does :($*a,$*b) := 1,2; ahhhhh and if that works, then so does sub foo ($*a,$*b) okay, I get it now. thanks. and if there's a policy, it's enforced by the decl But the sub declarator could choose to forbid it. or just issue a DIRE WARNING :) I agree w/jonathan -- the sub declaration can forbid it, just as we expect to forbid things in has, our, my, etc. Apparently all of our dire warnings should be capitalized. :-) I didn't hear the words between "our" and "should"... heh % cognominal has left cognominal!~cognomina@82.67.232.89 I think our warnings ought to begin with "Larry says" :-) "Larry says you shouldn't use a global variable here." OK, so have we now returned to the state that my example is actually correct syntax? pmichaud: nice! Larry says take three giant steps forward or, even better, "TimToady says you shouldn't use a global variable here. There are many other (better) ways to do it." minor disaster here-- bbiab Larry says lose a turn, install python. "I didn't say 'Larry says'! Segmentation fault (core dumped)" TimToady: OK, so ":($a, $b) := foo()" is the same as "($a, $b) := foo()". But you can use the Full Power of signatures on the LHS. yes, you have the declarative syntax rather than the rvalue list syntax, fwiw What about now: my $sig = :($a, $b); ...later, in a galaxy far, far away... $sig := foo() er, you mean foo() ~~ $sig ? % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net $sig := foo() would do something else btw, rakudo's make -j fulltest has some funky display issues, but runs without error Ah, of course. OK, so in :(...) := ..., we syntactically know what := is going to do. that's where I'm saying that sig matching doesn't know or care whether or where the $a and $b are actually aliased to or however you say that... it has a variable, and it binds it, and that might have effects elsewhere or it might now *not OK, so :($a, $undeclared_thingy) := foo() will not be an error? yes, it's an lvalue signature I think we have to make it an error OK, that's what I was hoping. :($a, my $b) := ... that last statement will work, and throw away $b? no, declares it in the current scope no {...} around it ah, ok so it propagates outward I don't look forward to implementing that, but I think it's the Right Thing. :-) seems to follow least surprise Right. Which is what I'm aiming for here. i don't know what to be surprised about anymore does handle declarators inside the parens? not currently * jonathan throws a badger at particle. I think I'd rather not have :($a, my $b) then * particle always tries to anticipate chaos my $b; :($a, $b) := seems easiers bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers pmichaud: nodnod (minor disaster continues, expands... bbiab) ah, kids. on a different but related topic, in perl 5 (undef, $x) = foo() allows you to throw away a result... or ($a, my $b) = works too can you throw away all named results in perl 6? *% % cognominal has joined #parrot At a guess. what he said wasn't sure if that'd work, but that'd be my guess fab. bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers: link: http://www.perlfoundation.org/parrot/index.cgi?php_oo_for_perl_6_programmers .oO( we just have to implement it ;-) moritz: Ssshhh... :-P OK, seems we have signatures straightened out somewhat. TimToady++ # thanks TimToady: While you're about, one other thing occurred to be: at the moment for parametric roles, we parse it as something like '[' ']' s/be/me/ # wish I could type today For the role declaration, parsing a signature there would make more sense to me - am I missing something? moritz: think you could look at t/syntax/signature.t conversion to spec tests? jonathan: agree so, back to my original comment, I'm thinking that Parrot's implementation of signature binding is perhaps just a sub that bounds to lexicals in its outer scope? OK, thanks.