% Ademan has joined #parrot r29326 | cotto++ | trunk: : [codingstd] Wrap more macro args. This leaves 94 test failures (with a : slightly smarter c_macro_args.t), but the rest of the macros will require some : refactoring. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29326 r29327 | cotto++ | trunk: : [codingstd] make c_macro_args.t smarter about some macros whose arguments can't : be wrapped diff: http://www.parrotvm.org/svn/parrot/revision?rev=29327 r29328 | cotto++ | trunk: : [codingstd] fix trailing whitespace in t/codingstd/c_macro_args.t : The irony of this is not lost on me. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29328 % iblechbot has joined #parrot juerd? i heard juerd was root or at http://juerd.nl/ or mailto:juerd@juerd.nl % silug has joined #parrot % barney has joined #parrot % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net r29329 | fperrad++ | trunk: : [docs] : disassemble.c was renamed pbc_disassemble.c since r29309 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29329 % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru I think that rakudo doesn't parse heredocs yet. Is that right? it was lasttime i checked i meant it was parsing heredocs _not_ parsing! r29330 | bernhard++ | trunk: : [Rakudo] Add or update some Copyright or SVN-Id lines diff: http://www.parrotvm.org/svn/parrot/revision?rev=29330 Yes, I see heredocs in STD.pm, but not in languages/perl6/src/parser/grammar.pg BooK: je suis en train de cataloguer tous les bouquins que j'ai .On verra s'il refait surface.. http://icfpcontest.org/ je crois qu'on peut concourir en Perl % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % Whiteknight has joined #parrot % silug has joined #parrot % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net cognominal: Bonne chance pour le conteste ICPF non, je ne participe pas tant que je n'ai pas Perl 6 and wrong channel btw r29331 | bernhard++ | trunk: : [Pipp PCT] Add some notes regarding literal strings in PHP. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29331 % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net r29332 | fperrad++ | trunk: : [Pipp] fix tests on win32 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29332 % Whiteknight has joined #parrot * barney now gets '__bitwise_and' for empty strings barney: In pipp? Yes r29333 | bernhard++ | trunk: : [Pipp PCT] Remove unneeded code, 'peek_brackets'. : Simplify quote_expression.pir by getting rid of some unneeded options : and by knowing that start and stop are either single or double quotes. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29333 barney: I think the problem is caused by the CONST_STRING dependance of __LINE__, because a lot of CONST_STRING "" are used inside init blocks, and those are generated without correct #line NotFound: could you add that hint, or patch, to http://rt.perl.org/rt3//Ticket/Display.html?id=55842 ? In a way it's funny. In r29331 I only added POD and got a different behavior. I'm working now in a variant of a previous attempt to add a function specific for const empty string, it can solve all this issues... but the CONST_STRING general problem remains. NotFound++ barney: and sometimes only by rebuliding with no changes gives different results. Strange, the phase of the moon doesn't change that fast :=) Maye the tides... or gravitational waves That will be great, bulding a gravitational wave detector at no cost X-) barney: RT#56868 r29334 | bernhard++ | trunk: : [Pipp PCT] PHP literals need not tests for whitespace, AFAIK. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29334 % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net NotFound: I get a segfault with ../../parrot ../../languages/pipp/pipp.pbc --variant=pct ../../languages/pipp/t/php/arithmetics_6.php morning^Wafternoon after applying your patch and rebuildign, no 'make realclean' barney: realclean required Or maybe a make clean in pipp directory is enough, don't know. % Whiteknight has joined #parrot All tests successful. for Pipp, after 'make realclean' in Parrot root % ruoso has joined #parrot barney: good :) Rakudo test and spectest_regression also pass. % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net NotFound: When I first saw that problem, I was thinking of a hash collision. barney: me also. % kid51 has joined #parrot Did you look into parrot_hash_put ? I looked and it seems correct. A check in CONST_STRING can be helpful, but it can slow down too much a lot of things. I'm confused by another thing. Does parrot_hash_exists() in hash.c make sense? It only checks whether there is a bucket. ack says that parrot_hash_exists is never used. % silug has joined #parrot And it calls parrot_hash_get_bucket(), which seems to do the right thing % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net You can fill a ticket proposin his deletion, to hear opinions. This code is in default.pmc: return !!parrot_hash_get_bucket(interp, pmc->vtable->isa_hash, Writing such things is a big no-no to me X-) I see very few places where get_bucket is used only to check existence, don't justify a specific function, except maybe for clarity. r29335 | jkeenan++ | parallel: : [t] For consistency, call: ->steps->[-1]. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29335 r29336 | jkeenan++ | trunk: : [t] For consistency, call: ->steps->[-1]. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29336 ascii_compute_hash() seems to return the seed for empty strings, which is fine % rurban has joined #parrot r29337 | bernhard++ | trunk: : [C] Delete obsolete TODO comment. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29337 NotFound: IMHO, replacing !!parrot_hash_get_bucket() with parrot_hash_exists() would be a good thing NotFound: I'll fire up gdb when I see the 'empty String' error again barney: rethinking about that, I think the same. In addition to clarity, it avoids exposing the hash bucket thing when is not required nor useful. % itz has joined #parrot r29338 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29338 r29339 | bernhard++ | trunk: : [codingstd] remove trailing spaces diff: http://www.parrotvm.org/svn/parrot/revision?rev=29339 r29340 | bernhard++ | trunk: : [distro] Let SVN ignore the generated file pbc_disassemble. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29340 NotFound: The naming is also funny. I thought a bucket was the container, containing potentially many key-value pairs okay, barney. ?naming A bucket item or something will be a better name. item, entry or slot % uniejo has joined #parrot r29341 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29341 % Zaba has joined #parrot r29342 | julianalbo++ | trunk: : Replaces parrot_hash_get_bucket with parrot_hash_exists in several places diff: http://www.parrotvm.org/svn/parrot/revision?rev=29342 NotFound++ % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru r29343 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29343 % ruoso has left ruoso!~ruoso@201.45.49.162 % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru r29344 | fperrad++ | trunk: : [Pipp] get_resource_type() diff: http://www.parrotvm.org/svn/parrot/revision?rev=29344 r29345 | bernhard++ | trunk: : [Pipp] Add test for stringification of PhpBoolean. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29345 r29346 | jonathan++ | pdd25cx: : [core] Fix build of pdd25cx branch on Win32. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29346 % jhorwitz has joined #parrot % kid51 has left kid51!~jkeen@70.107.8.78 % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % silug has joined #parrot % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net pmichaud: ping % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot jonathan: pong pmichaud: Which instructions were you using that got replaced by local_branch and local_return? TimToady: (multiple meanings of 'capture') I'm going to switch the conversation to start using 'snapshot' instead. jonathan: bsr/ret OK, I thought so. IMCC handles some branch instructions explicitly. yes I'm having a dig to see if I can coerce it into doing the Right Thing. jonathan++ If nothing else comes out of this, at least I have fixed the branch build on Win32. I did think about the possible register allocation issues with respect to the other parts of PGE that use it but the other parts of PGE already do :unique_reg so I figured it wasn't an issue. However, I didn't realize that :unique_reg doesn't help with $I0 (which sounds like a _huge_ bug to me) and if we can't fix the register allocator for l_b/l_r then it means we'll have to do similar things in all subs that are currently making use of bsr/ret Can you take a look at RT#56868 ? jonathan: can you preview a reply I'm about to send to make sure it's clear? (I'll nopaste it) Damm. The easy attempt to fix IMCC up didn't help things. pmichaud: sure NotFound: Who is "you" referring to in that sentence? "pmichaud" at 76.183.97.54 pasted "explanation of clone and closures" (38 lines) at http://nopaste.snit.ch/13567 jonathan: Those that were alive in the channel at the moment, that is, you and pmichaud Ups, recursive X-) pmichaud: Well the short answer and code that follows make complete sense. Now for the long answer... :-) NotFound: is this change going to make a significant improvement in performance? pmichaud: OK, what you just wrote makes sense to me. jonathan: the long answer I'm writing makes complete sense also (to me). But it's somewhat involved, so I'll have to make sure I'm clearly defining my terms. the long answer I have also resolves chromatic's get_x and set_x example. pmichaud: Right. And the real problem is that there's a lot of cases where it feels to me like different terms for the same thing are being thrown about. not only that, but parrot has conflated too many items together for example, newclosure == snapshot + clone taking a closure (snapshot) is always a part of invoke etc. those are bad conflations -- my new proposal will give separate terms for each action I had snapshot = clone in my mind. okay, well, we should fix that then what should we call the operation whereby an inner closure is bound to the lexicals of its outer sub? 'capture' is probably bad. % Theory has joined #parrot Taking a snapshot of the current lexical environment = taking a closure = what cloning a closure in Parrot does. I'd prefer to call cloning a closure "cloning a closure" :-) pmichaud: maybe, but the main reason is to simplify the code and the preprocessing of CONST_STRING, and avoiding several current bugs related to CONST_STRING. i.e., we already have a name for that: clone Right. Mainly, letting pipp pass test consistently. NotFound: to me it doesn't simplify the code, because I end up with some string constants that say "CONST_STRING" but for some reason empty string is different i.e., I'd be asking myself: Why not just use CONST_STRING(INTERP, "") ? But I think it's good to be clear that the operation of taking a clone is how we implement the semantics of taking a closure, or a snapshot if that word is preferred. r29347 | fperrad++ | trunk: : [Lua] : - introduce a memoize cache in LuaRegex compiler I need a good name for the operation that I've been calling 'capture'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29347 If that makes any sense. Yeah. Associate? hmmm... Associate is developing perl course work, and is having trouble finding something appropriate for beginners. well, it's really a bind of sorts. Associate the inner's lexical scope with that of the outer? The empty string is different, it does not need to care about charset and encoding. Hmm. I agree with you capture isn't the best name. It's too overloaded. NotFound: thus my question -- does this give us a significant performance improvement? NotFound: because if it doesn't, it seems that we're making the code less understandable for no substantial improvement % Zaba_ has joined #parrot pmichaud: Don't know, I will try to make some measurement. one could always treat empty string as a special case in the CONST_STRING function, too. ...but that doesn't seem to be much benefit either pmichaud: A thing I'm curious about in what you're about to propose. % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru But is a macro, and is processed in pmc to c process. my $x = 42; if 1 { if 1 { say $x } } Oh, no...bad example... :- :-) OK, there may be no example...if so, that's a good thing. :-) % Senak1 has joined #parrot % Senak1 has left #parrot ...although what I'm about to propose (to solve the case chromatic gives) _will_ essentially require that every sub have a list of its inner closures % integral has left integral!bsmith@adsl-212-20-244-147.lumison.co.uk so my proposal will have two parts -- what I want to see happen short term, and what we might do long-run to address chromatic's example short term doesn't require maintaining the list of inner closures OK, I'm struggling to construct an example where we have to have a sub knowing its inner closures. in what sense? do you mean deeply nested inner closures, or immediately inner? "barney" at 84.154.20.211 pasted "strings not found in constant table" (19 lines) at http://nopaste.snit.ch/13568 OK, so suppose whenever we are about to (a) take a reference to an inner closure or (b) invoke an inner closure, we always call .capture on that closure (can't think of a better name right now), which sets its outer scope to be the current one. Make sense? I'm just debugging the const string issue with gdb. Right now I'm confused, as the same string seems to be made twice So before we do the clone or the invoke, we do a capture? the problem is that we may be doing those from a context other than the outer? s/\?/./ OK, in that case .capture is a no-op. -> $x { sub foo() { say $x; } if 1 { return &foo; } } OK, so let's take that case. We can't wait for the &foo step to do the capture, because we're not in the outer context. Ah. so, we'd have to chase up the caller chain to find the appropriate context in which to perform the capture. And that's where I think we start to run into difficulties. Yes. here's what I want to do for for chromatic's case Can you explain what you propose for the case you just wrote above first? While I've got that problem in my head. :-) sure as soon as we enter the -> $x { ... } block, we bind all of its inner closures (bind == capture) this would be 'foo' and the immediate block of the if OK, and that can be done by the compiler knowing what the inners are? % integral has joined #parrot Rather than the outer having to know its inners? yes, the compiler knows all of the inners already OK. (by definition of lexical scope) Right. So, understand how this one will work. Go for chromatic's one. okay, chromatic's case is { my $x; sub set_x { $x = shift; } sub get_x { return $x; } } *but* someone can call set_x/get_x without the above outer closure having been invoked first OK, understand the code. currently parrot attempts to handle this by an "autoclosure" -- i.e., when set_x is invoked, it detects that it hasn't had a capture yet so it immediately invokes its outer sub to get a lexical environment and then captures that Bad. Right. I does a "fake" invocation that builds a lexical environment, but doesn't run the code. s/I/It/ part of the problem is that even though we've "solved" the problem for set_x, the get_x sub isn't bound to that same lexical environment Right. Because get_x realizes it has no outer, and goes and does a fake invocation of its own. so, what I want to do is separate "create lexical environment" from "invoke" i.e., make it possible to create a lexical environment without doing an invoke we have this already via the 'fake' invocation but since we don't run the code, we don't get the benefit of doing capture on all of the inner subs sorry, inner closures so, what I want to do is... when we invoke set_x (and perhaps take a reference to it), it detects that it has no outer lexical environment, so it tells its outer sub to create one and the act of creating a lexical environment automatically binds all inner closures to that lexical environment but the "automatically binds" means we have to have a list of the inner closures *nod* Makes sense. * jonathan wonders if Perl 5 handles it the same kinda way although, I wonder.... % Zaba has joined #parrot I wonder if it is actually possible to lazily capture the inner closures right now the autoclosure always invokes its outer sub to build a lexpad shouldn't that be "invoke the outer sub if it doesn't already have a lexpad"? another case: { my $x = 1; sub get_x { return $x; } } # if this block is never entered, but get_x is still seen as defined, what does this mean? # when get_x is called later spinclad: excellent example % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru I think that Perl 5 returns an undefined value The only way to get that to give 1 in Perl 6 that I can think of is to have my $x ::= 1; module Foo { my $x = 1; sub get_x is export { return $x; } } I think that's different? how so? Because when you "use" module, does the body not get executed? I wasn't saying "use module" OK I mean place that wherever we had the { my $x = 1; ... } earlier But by the time we have done so - and this got hold of get_x - the my $x =1 would have run. there's an implied BEGIN on the body of modules and classes Right. But the original example - where we haven't got that - we'd just have get_x returning undef. right. OK, I think we're agreeing here. so, what do you think of 15:18 shouldn't that be "invoke the outer sub if it doesn't already have a lexpad"? I sorta thought that's what the code already did...let me check. oh, I see the "already have a lexpad" part is in the sub's invoke ok no, wait, that can't be right. invoking a sub always gives it a new lexpad Just staring at the code to be sure of what it really does do... I think that right now autoclosures always result in a new lexpad, instead of reusing a previous one oh, no, I see line 103, closure.pmc Right, that's the bit I'm looking at too. That seems to make sure if there is a lexpad from a previous invocation, we get it. So in chromatic's example, get and set end up referring to the same thing. ouch, I think I can come up with an example that screws up even the simple version of what I'm proposing % Ademan_ has joined #parrot % Ademan_ has left Ademan_!~dan@h-67-101-47-64.snfccasy.dynamic.covad.net % kid51 has joined #parrot NotFound: Can you look at line 645 of string.c. Shouldn't the third argument be 'buffer' ? % Ademan has left Ademan!~dan@h-67-101-47-64.snfccasy.dynamic.covad.net (writing) oh, maybe not barney: On the curren version or in my patch? In SVN HEAD no, I think that hash_put requires a STRING argument or something that has a header % uniejo has joined #parrot % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk % chromatic has joined #parrot barney: looks like a bug in src/string.c to me. Good catch. pmichaud: I think maybe best is to collect together all of these various examples that we are tossing around. That demonstrate various things. well, that's what I was going to do in my long message (things = use cases) OK, good. show how the approach would handle each of the use cases (which is why it would take a few hours to develop) OK. (case analysis)++ but when we're done we could potentially use it as a new pdd20 since the existing pdd20 is obviously not what is implemented Yes, if you can't find it with a certain key, put it there with the same key * jonathan remembers doing proofs on lock-free data structure safety using case analysis... Yes, it'll certainly be wanting an update. anyway, do we have a good name for the 'capture' operation yet? ;-) I can explain how Perl 5 handles the situations I posted. that would be helpful pmichaud: Everything I've named in Parrot, Allison has found reason to give a different name. I'm really not a good person to ask for names. :-) jonathan: I just need a name that makes sense to whoever is implementing it. If allison wants to change the name later, that's fine with me. (And she found good reasons to give them different names too - just to be clear...) barney: I'm testing with that change. (I've had the same experience, btw. :-) NotFound, me too. But my cpu is faster :P pmichaud: I wonder who the likely implementers are... ;-) Just a joke, is 5 year old portable. pmichaud: I'd go for a name that has "outer" in it somewhere though. jonathan: I just need a name that makes sense to me, you, chromatic, and rgrjr for purposes of discussion, and that we'd be comfortable living with if it existed long-term coretest pass "set_outer" will be confusing because we use that already right (for dynamically setting the otuer sub) although I don't think anyone is actually using that yet set_outer_context is long but clear. set_outer_ctx ? pmichaud: Yeah, I implemented it to unblock implementation of eval, which now exists but doesn't handle lexicals yet so doesn't use it. set_outer_ctx works for me - and ctx is a common abbreviation in Parrot for context. let's go with that for now. pipp test pass! ok % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru chromatic: are you writing up an explanation of p5 for email or just busy with something else? % Zaba has joined #parrot I don't think I need a super-detailed explanation -- just enough to get the key features I'll write one now. I had to take a few minutes to question the Perl 6 code first. one good result of all of this is that I'm getting a much better picture of lexicals :-) (or, at least I think I am) Same. I think. :-) one question I do have.... with for 1..10 -> $x { sub foo() { ... } } is that a redeclaration error or not? i.e., do we treat 'sub foo' as being a redeclaration for each iteration of the loop? No, I don't think so, because it's not being redeclared. The name foo always is attached to the same body. I think declarations are seen from a static, compile time point of view. fair enough -- was just curious. Don't take me as authoritative, but it's my understanding. :-) although chromatic just asked if it's actually valid Perl 6 on the m/l :-) (I hadn't read that before writing my question on irc) In http://dev.perl.org/perl6/doc/design/syn/S04.html#When_is_a_closure_not_a_closure it uses "my sub" But I thought that just declared the scope of the symbol "bar" oh, the answer's right there "In particular, named subroutines in any scope do not consider themselves closures unless you take a reference to them." Note: in any scope It's the third time this sentence is quote in two days ;) It seems to answer many questions. ;-) and raise many others. % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net like, what about my $foo = { sub bar() { ... } }; is bar() a closure? s/'()'// I tink we can safely say that this would do newclosure on the block since we're taking a reference to it. pmichaud: I think that scope isa 'any' But bar - hmm. newclosure on the block -- sure, no problem. pmichaud: sounds like the name of a pop band. egads, another lightning talk. "Perl Bands" newclosures on the block NotFound: Surely a rap band? :-) OK, I need to go to some other $reallife stuff for a while. okay, thanks jonathan jonathan: that can be a rapture, not a closure. r29348 | bernhard++ | trunk: : #55842: [BUG] empty .const .String broken : The cause was probably a bug in the function const_string(). : If a string can't be found in the constant table, create a STRING : structure and use the lookup key for storing it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29348 barney++ pmichaud: Thanks for all the time/effort you're putting in too. This has turned out to be a lot trickier than I'd expected. well, I don't know if I'm unintentionally making things more difficult by asking questions that aren't really valid I do know that until the patches you and chromatic did, I couldn't get simple lexical blocks to work like at all. Aye. We need something that works "generally" though. ;-) * jonathan quickly disappears for a bit chromatic++ (explanation on mailing list) and not ugly barney, we probably need a const cast on that... I'm testing it now. haven't read it yet, but I'm getting the impression that the fact that we're currently making all :outer flagged subs into Closure PMCs isn't the right thing to do perhaps :outer flagged subs should remain subs, and we convert them to closures when we take a reference or otherwise clone them That sounds better. But we do need some sort of compile-time scope bindings for named subs. chromatic: I tried Parrot_const_cast( char *, buffer ), but got error sure, which is also why I think should be a Sub thing and not a Closure thing