r29280 | cotto++ | trunk: : [codingstd] wrap macro args in src/jit/amd64/jit_emit.h diff: http://www.parrotvm.org/svn/parrot/revision?rev=29280 bacek: now I'm around good morning ;) moritz: I already started my friday night beer :) moritz: I actually want to ask for apache rewrite rules for ilbot. bacek: aren't they in the repo? http://svn.pugscode.org/pugs/misc/irclog/cgi/.htaccess r29281 | cotto++ | trunk: : [codingstd] wrap macro args in src/jit/alpha/jit_emit.h diff: http://www.parrotvm.org/svn/parrot/revision?rev=29281 moritz: OSHI... perhaps I should have named it just htacess in there ;) moritz: good idea :) I didn't realize that it already here... % mire has joined #parrot % mire has left mire!~Frodo@8-168-222-85.adsl.verat.net r29282 | cotto++ | trunk: : [codingstd] wrap macro args in various files diff: http://www.parrotvm.org/svn/parrot/revision?rev=29282 % jq has left jq!~jquelin@merlin.mongueurs.net r29283 | chromatic++ | trunk: : [OO] Made get_class and typeof return the same PMCProxy PMC. See RT #56816. : There may be a further performance improvement available by caching the : PMCProxy as needed for each built-in PMC, but it's only useful if you extend a : built-in PMC from PIR. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29283 hi, 29277, 2008-07-11 06:00:54, cotto - breaks trunk? .... http://tt.ro.vutbr.cz/report/pr-Parrot/diff?trun-1665=on&trun-1663=on&Submit=Compare+selected or anything odd with TapTinder? % iblechbot has joined #parrot % jq has joined #parrot mj41, I'll look into it. Thanks for noticing. "mj41" at 147.229.5.124 pasted "to cotto, make error" (30 lines) at http://nopaste.snit.ch/13557 how did you run Configure.pl? "mj41" at 147.229.5.124 pasted "configure output" (88 lines) at http://nopaste.snit.ch/13558 $make_cmd = 'make'; $conf_cmd = 'perl Configure.pl'; I'm not getting that failure. I'll look through the diff for something obviously broken I missed the first time. * moritz gets and error in t/tools/dump_pbc.t Something tells me my karma's not going to look very good in the morning. imho it's ok, many commits, but only one broken and probably only for one/my machine configuration :-) found something suspicious try lowercasing sTI on line 1141 of src/jit/i386/jit_emit.h and see if that fixes the break or just svn up r29284 | cotto++ | trunk: : [jit] fix a capitalization bug diff: http://www.parrotvm.org/svn/parrot/revision?rev=29284 you still there? mj41++ #for finding and reporting the break captilization bug => captital punishment? ;-) It's almost 2:00 here and I need sleep. If it's still broken msg me via purl and I'll take care of it in the morning. moritz, is your t/tools/dump_pbc.t failure related to mj41's? cotto_home: don't know, but don't think so cotto, good night, see http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk at the morning cotto_home: go get some sleep ;-) sleep & "mj41" at 147.229.5.124 pasted "r29284 - make error (broken in 29277)" (74 lines) at http://nopaste.snit.ch/13559 % contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com r29285 | bernhard++ | trunk: : [Rekudo] Some tidbits in docs/compiler_overview.pod and README diff: http://www.parrotvm.org/svn/parrot/revision?rev=29285 % iblechbot has left iblechbot!~iblechbot@48.16-dial.augustakom.net r29286 | bernhard++ | trunk: : [Pipp] Steal the quote-parsing code from Rakudo. : But don't use it yet. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29286 % ruoso has left ruoso!~ruoso@201009120124.user.veloxzone.com.br % Whiteknight has joined #parrot % bacek has left bacek!~bacek@mcas-151.usr.optusnet.com.au % Auzon has left Auzon!~ak9@24-171-76-148.dhcp.mtvr.il.charter.com % donaldh has joined #parrot % Auzon has joined #parrot % skv_ has joined #parrot % skv has left skv!~skv@87.242.97.68 % skv_ is now known as skv % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net r29287 | bernhard++ | trunk: : [Pipp] Use 'quote_expression' for single and double quoted strings. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29287 % idemal has joined #parrot r29288 | bernhard++ | trunk: : [Pipp PCT] Merge the rules 'array_assign' and 'scalar_assign' into 'var_assign'. : Support interpolation of keyed variables in a string. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29288 % uniejo has left uniejo!~uniejo@193.88.64.250 % ruoso has joined #parrot % uniejo has joined #parrot % Whiteknight has joined #parrot r29289 | julianalbo++ | trunk: : Fix a typo in i386 jit_emit.h diff: http://www.parrotvm.org/svn/parrot/revision?rev=29289 % Infinoid has left Infinoid!~infinoid@quack.glines.org % Infinoid has joined #parrot % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % iblechbot has joined #parrot % rurban has joined #parrot % Ademan has left Ademan!~dan@h-67-101-103-141.snfccasy.dynamic.covad.net r29290 | pmichaud++ | trunk: : [rakudo]: spectest-progress.csv update: 95 files, 1691 passing tests diff: http://www.parrotvm.org/svn/parrot/revision?rev=29290 % Ademan has joined #parrot r29291 | kjs++ | trunk: : [docs] update pct docs a bit. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29291 % ruoso has left ruoso!~ruoso@201.45.49.162 r29292 | kjs++ | trunk: : [pdd19] add :lexid, but description not complete yet (not sure about details). diff: http://www.parrotvm.org/svn/parrot/revision?rev=29292 r29293 | kjs++ | trunk: : [chitchat] add more action methods. : * made some assumptions/guesses from memory about semantics because lack of internet access and thus no access to reference. : * grammar might need some tweaks. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29293 % gryphon_ has joined #parrot % rdice has joined #parrot r29294 | bernhard++ | trunk: : [Pipp PCT] Try to add support for complex string interpolation with curlies. : But on input like : echo "{}"; : an infinnite loop may happen. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29294 % Whiteknight has joined #parrot % barney has left barney!~bernhard@p549A01D1.dip0.t-ipconnect.de % NotFound has joined #parrot Hello hello salut, Whiteknight. hello hola, pmichaud. hello hola, NotFound. Doesn't like caps? too lazy to shift this morning ;-0 *groan* r29295 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] updating to trunk r29294 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29295 jonathan: how hard would it be to get an outer Sub PMC to maintain a list of all of the (inner) Closure PMCs that reference it via :outer ? % ron has joined #parrot % uniejo has left uniejo!~uniejo@193.88.64.250 pmichaud: To maintain it, or to build it at compile time? (phone) well, primarily build at compile time, but I suppose it's also possible for a Closure PMC to be GCed (still on phone -- bbiab) Hmmm...which could be a problem, because if it's on a list that we scan, it'll never get GC'd. in my branch, it's not really possible for anything to get GC'd yet % ron has left ron!~ron@c-98-203-6-135.hsd1.fl.comcast.net % jhorwitz has joined #parrot Does parrot support weak references? tewk, you don't need them weak references is are kludge because reference counting has problem with structures that contains loops. * Infinoid volunteers to port weaken() to rakudo % particle1 is now known as particle that would be a noop? :) yep! we could implement it in lolcode hmm. since we have pluggable GCs, is a refcounting GC an option? so far it sounds like the API prevents that (an answer of "there's no way you would ever want to do that" is also acceptable.) in our communauty, we want to do whatever we want % Andy has joined #parrot Infinoid, I suspect that true reference counting is not currently possible, no at least, not without major modifications thought so, thanks % rurban has left rurban!~chatzilla@212-183-83-222.adsl.highway.telekom.at it occurs to me that there's a huge amount of code that simply drops a pointer and expects things to be cleaned up automatically. that does keep the code a *lot* cleaner. community! # I always trip on that one % rdice_ has joined #parrot (off phone) % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com I was thinking that we wouldn't need to follow the inner_sub list to mark its members as live just that when a Closure PMC was destroyed, it removed itself from it's outer_sub's list *its pmichaud: I haven't had chance to read your mails to the list yet, which probably give some context to this discussion. :-) I think only the last one is worth reading :-) That aside - we statically know within a compilation unit what references a sub as being one of its outers. So it's possible. but essentially the bottom line is that we need to make sure that every inner sub has a newclosure performed on it at the time the outer sub is invoked Can we not turn it around and lazily newclosure it if the outer sub has been invoked since we last were? apparently newclosure on invoke is a real problem for one, we can't always know that we're invoking the inner directly from its outer % barney has joined #parrot the sub might be invoked several levels deep, which means we have to chase up the call stack to hopefully find the sub that this was intended to be newclosured in s:1st/the sub/the closure/; Ah, you're saying newclosure is transitive? % jjore has left jjore!~jjore@c-24-19-49-60.hsd1.mn.comcast.net from what I gather from what I think rgrjr is saying, newclosure at the point of invoke is an issue. OK. I'm not certain he's absolutely right about that or that it's unfixable, but I'm looking for other options. :-) So, to answer your question - it's messy, but possible, particularly handling it from a GC perspective. As far as I can see, anyway. okay, that's good enough for me. But I'm answering without reading this in any kind of context. yes, no problem. I just wanted to know if I was overlooking anything obvious before I investigated it further. After my last attempt at trying to fix closure stuff up for you, and the fallout of it, I kinda got fed up of it and wanted to do something else for a while... again, I think my latest post summarizes the issues fairly well and concisely describes how I think we can solve it Parrot guts, at times, can be highly frustrating. and yes, I agree with the frustration, which is why I was looking into possibly doing this myself instead of shoving the frustration off to you :-) agreed! (Parrot guts can be highly frustrating)++ your latest changes for lexid and closures gave me enough "oh, here's how it works" details that I think I could make the changes myself if necessary, or at least do an experimental branch with them. OK, that's something at least. And lexid is something we needed anyway and I guess is here to stay. oh, definitely -- it was very informative and helpful for me. on another topic (Bool versus bool) -- very interesting conversation with TimToady on #perl6 last night http://irclog.perlgeek.de/perl6/2008-07-11 I don't things are entirely resolved yet, but it did help me to understand .Bool, .true, prefix:, etc., or at least the way the spec is leaning at this point Ah, I saw his commit and not the discussion; the commit didn't to me look to address all of the issues. yes, the discussion is exactly because to me the commit didn't look to address all of the issues :-) In fact, it confused me more - I'll read the conversation log though. i.e., the conversation was a result of the commit, not vice-versa Oh, OK. What came first... :-) % donaldh has left donaldh!~chatzilla@proxy-sjc-2.cisco.com (commit was at 2:03, conversation started at 3:00 :-) r29296 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] rearrange marking for child objects to account for pointer dependencies. Add a few break statements where GC and DOD blocking might need to be tested. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29296 pmichaud: Too distracted with $otherjob to read it properly now, but will look later; thanks. no problem, just wanted to make sure you were aware of it % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % Theory has joined #parrot r29297 | cotto++ | trunk: : [codingstd] fix macro args test, making it catch all token concatenations diff: http://www.parrotvm.org/svn/parrot/revision?rev=29297 % sjansen has joined #parrot % AndyA has left AndyA!~andy@ca93nt.hexten.net % AndyA has joined #parrot % gryphon_ has left gryphon_!~gryphon@dsl-209-221-185-54.zipcon.net % gryphon_ has joined #parrot r29298 | cotto++ | trunk: : [codingstd] whitespace fix and line length fix diff: http://www.parrotvm.org/svn/parrot/revision?rev=29298 r29299 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] fixed bad ordering in sweep code. hdrs swept front-to-back, corresponding to cards from back-to-front. Fixed premature freeing of some PMCs, but now exposes random segfault in hash code. % uniejo has joined #parrot diff: http://www.parrotvm.org/svn/parrot/revision?rev=29299 can anyone see http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk ? cotto_home: no timeout thanks. work & % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk cotto_home: I see it pmichaud: Just read the discussion and not feeling like it really answers much. :| it doesn't yet, other than to say that it's not answered yet :-) Think it's worth me mailing p6l? Larry's aware of it, I suspect we'll see an update soon. OK. % rurban has joined #parrot I'm looking at namespace interpolations for jhorwitz -- unfortunately we've got a lot of changes to make to existing code in actions.pm I can imagine that classes in some places ain't handling namespaces the Right Way. And likely the same for roles too. it's not just namespaces, but also method names and routine declarators and enums We need to be able to stick namespaces on these too? $foo.XYZ::method(...) sub foo::bar::baz() { ... } * jonathan wonders how $foo.XYZ::Mehotd() parses takes a which takes a which can contain namespaces is anything with colons as opposed to Ah quite a bit of existing code wants to treat like ident Yes Aye I'm not worried about sub foo::bar::baz() as much as I am sub foo::($bar)::baz() --- if such a thing is even legal. Ah, longname includes colo pairs. *colon well, for now it's sufficient to get to work pmichaud: fyi, that namespace interpolation patch is now broken ($past.name(undef) no longer works for call nodes). i'll update the ticket with a working patch. morename?! jhorwitz: don't worry about it too much jhorwitz: since STD.pm now says how interpolations get parsed, we'll want to go that way what, me worry? ;-) I just have to figure out how to represent run-time namespace interpolations in the PAST nodes ok, if it's getting the proper treatment, i'll leave it to you guys :) pmichaud: Another thing to handle that I am pretty sure will be wrong now, is nested classes. I did some work in that direction. oh, I know nested classes are likely wrong. I'd like to get basic namespaces working first, though. (Making sure attributes and methods ended up in the right class, or role, etc) But the namespace side of them is almost certainly wrong. It was on my "we'll worry about that later" things. r29300 | bernhard++ | trunk: : [Pipp PCT] Rename token 'circumfix' to 'curly_interpolation'. : Remove support for Q:w, Q:ww, and Q:regex in quote_expression(), : as these aren't PHP features. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29300 I think that it'd be good to review namespace stuff in general though. % ruoso has joined #parrot There are times when I've been writing stuff that I've thought, "hmmm...might have to re-visit that for namespace issues later". I'm thinking that the namespace attribute in PAST nodes will need to be updated as well as name, for that matter. To be able to take a PAST tree rather than just a list? yes, to take a PAST tree. OK that either returns an array or a namespace (haven't decided) namespace may give more flexibility, but array may be easier to code-gen. (As in, easier for compilers to generate) (Not easier for PCT) well, given an array, one can always do PAST::Op.new('get_namespace', $array_past) er :pirop('get_namespace') Yes, i probably need PAST nodes for 'name', for supporting ${ $name_of_var } in PHP We can probably do MY:: with them too. For Rakudo. So yes, name as PAST tree in PAST::Var sounds good. MY:: ? I figured that was going to have to return the LexPad Perhaps. yes, there is always the option of always treating namespaces as hashes I meant a lookup within that. instead of using the get_*_global opcodes We still have to use one of them to get at the namespace in the first place, I guess. I'm pretty sure that the get_*_global opcodes require a NameSpace PMC anyway, I figured that MY:: would have to be special cased to return a Hash and we use a :keyed PAST::Var node for it I don't know that we can do pseudo-namespaces using the get_*_global opcodes. we could always do namespace lookups with get_*_namespace, and then use those as the base for :keyed nodes % rurban has left rurban!~chatzilla@212-183-83-222.adsl.highway.telekom.at nod Yeah, I think you're right. which one? ;-) That we probably have to have MY:: returning a hash and keyed index into it. same for OUTER::, CALLER::, etc. Aye. CALLER:: may be a little more fun. :-) Becuase it'll have stuff in from many lexical scopes (all those in the caller) NotFound++ #cleaning up the build On the upside, at least we now have a way to know what is a Routine and what is a Block. :-) What's your kinda "work plan" / priorities at the moment? I'm increasingly concerned that we're putting in too many 'advanced' features before the basics are in yet lexicals are still broken closure support is broken namespaces are broken parameter passing is broken pmichaud: me also. HLL support is broken pmichaud: unicode is broken % sjansen has left sjansen!~sjansen@206.83.88.66.ptr.us.xo.net actually, unicode I can deal with. It's relatively isolated and pluggable Well, it's not unicode, is the encoding system in general. still, it's quite pluggable. it's not as if a change to Parrot's string handling system is going to force huge code changes in the HLL stuff we're doing Of those, a bunch of them appear to be as much Parrot level issues as high level ones. Which gives resolving them that extra bit of difficulty. yes, they are Parrot level issues also. That's the problem I see, a fail in a HLL can come from a variety of sources and is difficult to diagnose. but I've had too much experience (e.g., S05/PGE) where changes to the underlying model has caused huge rewrites in the code that depends on it parameter passing - because the Parrot model doesn't give the Perl 6 semantics? and is broken on its own, as well. And not especialy fast. jonathan: because is broken, there are a lot of unresolved tickets about it. allison has already approved the design for a new param passing model that supports Perl 6 semantics better we just need an implementation :-) A not broken one, preferably ;) "just" :-( pmichaud: What about the return values? I've not read the details of what Allison suggested, but I'm fearful of putting any more features into the current implementation. Not to mention trying to understand it in the first place. I don't think it is (or should be) "adding features" as much as "rethinking the implementation altogether" the syntax and basic semantics are backwards-compatible with what we have now I dived in there last night for a while and saw things like structs in structs in structs... (with one minor exception that I don't believe anyone can possibly be using) yes, the new approach is likely much simpler I completely fail to understand the current implementation when looking at some of the related tickets. I think the existing code suffered from a bit of premature optimization (that really wasn't) branch and re-write would appear to be one option I think branch and re-write is likely the only viable option. NotFound: return values are handled basically the same as subroutine invocation -- i.e., it's the same code The other "fun" in it is handling NCI and arguments from C. pmichaud: there is a problem with the return values when doing a tailcall, as a recent ticket exposed. NotFound: I think that's an implementation bug more than a design problem and if we re-implement the parameter passing altogether, we can likely solve that bug The problem seems to be that the C level call depends that the return values are exactly that it expects to be, and the tail call broke that assumption. anyway, as to my priorities: they are (in no specific order) HLL support, namespaces, lexicals, list assignment But I'm not completely sure. As I say, I don't understand well the implementation. next tier would be signatures, parameter passing oh, first tier also includes pre-compiled modules OK. % Zaba has joined #parrot HLL support, lexicals, parameter passing are blocked on fixes or updates to Parrot My (small) issue is that my MMD grant is for July/August. And explicitly non-extendable. yes, I know. that's why I'm a bit frustrated and concerned that we can't get Parrot issues resolved quickly enough. I don't want to distract from important things; equally, I don't want to let a donor down by not delivering. By the way, will be nice if the pir or pbc generated by rakudo will be capable of autoloading the required libs and autostart himself. NotFound: this is explicitly planned. In order for that to work I have to resolve the :load/:init issues which is yet another Parrot bug. % cotto-work has joined #parrot (:load/:init doesn't play well with lexicals.) pmichaud: Isn't that fixed in Allison's branch? yes, but when will that branch merge? I'm back! Heck knows, but I have a hard time believing that this particular fix is related to the concurrency things that are the subject of the branch. actually, I think it is related (more) Has Allison said it would be hard to port it back into trunk? because the problem has to do with the separate runloops that occur for :init/:load versus the mainline code Oh. and in the branch we don't have those runloop issues (if I understand what Allison has said about it) it shouldn't be hard to port back into trunk. The problem is that Allison is the primary one doing it, and she's overloaded with non-Parrot work until at least the 25th (OSCON) % cotto_work has left cotto_work!~cotto@tide503.microsoft.com Right, I was about to say, progress on that branch will be slow for a while. I've also seen a runloops related problem in the way pdb step code. so, unless/until everything starts magically working in the branch, the merge likely won't occur until the 25th Someone is actually using pdb? anyway, as far as your MMD grant goes, I think we can go ahead and plan to reserve hacking days at YAPC::NA for you and I to focus on it intensely, if need be sorry, YAPC::EU Yes, there is that option too. In terms of Parrot stuff i.e., if we haven't made progress on signatures by then, then that's what we're doing in August to the exclusion of all else :-) signatures/MMD, I mean How serious are the various issues as blockers? lexicals: serious HLL: not too serious, we can continue to live in the 'parrot' namespace for a while and get incorrect types back from time to time using precompiled modules: not serious, but profoundly beneficial in numerous respects -- most notably, the time needed to run 'make spectest_regression' we can cut approx 6 minutes out of the time needed to run spectest_regression if we get precompiled modules working also it allows us to start writing builtins in perl 6 but precompiled modules depends on load/init depends on lexicals so I'm looking at a workaround for that parameter passing: livable for now, but we need signatures resolved soon for mmd issues and because I don't like the way they're current factored in actions.pm namespaces: increasing in importance, because we need to make sure that PCT supports all of the funky ways in which we deal with namespaces (and because a lot of actions.pl depends on being able to grab names) You have Parrot bugs relating to namespaces filed too, or that's mostly PCT work? it's PCT work OK mostly design, since I first started thinking about it in depth in the context of jhorwitz' patch Just trying to get a sense of, if I'm going to throw some time at Parrot guts, where is it best spent. lexicals continue to be -- by far -- the biggest headache. Nothing works without them. well, very little works right without them. It's all a bunch of workarounds. I don't want to do anything more on those from a code point of view until something that works for us, bob and others is worked out design wise, though. agreed. I don't know who needs to bless a design, though. I need to throw a lot more brain cycles at the thing to realy understand what both of you are saying. Well, Allison, I'd think. At least, that the code matches the design documents. I don't really feel like I should be saying "yes we can change the design", even if I think we should, without her OKing it. NotFound: I believe the design documents are incorrect here. NotFound: there's no point in implementing a defective design. Or even, that the code matches his own comments and pods. % jq has left jq!~jquelin@merlin.mongueurs.net jonathan: I don't think it would be you saying "yes we can change the design". I think it would be more of "Pm, jonathan, Bob, and chromatic all agree that this is a workable design for now (where the existing one is broken), so we're going to implement it and if Allison wants to change it later then we'll revisit it later) pmichaud: yes, but in that case the document must be changed. pmichaud: If we can get that kind of consensus on it, then I think that's OK. I just know that every time I go to fix something relatively fundamental, lexical bugs keep getting in the way As NotFound says, we should fix the design doc and patch that, and I think ahead of the code changes, so there's a clear spec. I'm not sure we can a-priori know that a particular design works, given our collective experience levels. I'd rather tinker with an implementation until we get one that works, and then document that. :lexid being a prime example (because pdd20 makes absolutely _no_ mention or inkling that something like :lexid is needed) OK, but let's at least try and get a consensus on what we can work out. Maybe a good solution is: cd docs/pdds ; mv *.pod draft ; ;) right now I have a consensus of one that I like what I just proposed. :-) I'll read your and bob's mailing list posts at the weekend and try and feed into this. I'm eagerly waiting to see what rgrjr has to offer Yes, I think he has a good understanding of these things. the first part of my proposal doesn't seem radical at all Certainly, he's done stuff in that area of the code. the second part is more radical (where outer subs maintain lists of their inner closures), but I can completely live without it if we just do the first part % Ivatar has joined #parrot if we try to stick with the existing newclosure design, either as implemented or as documented in pdd20, then we have a _lot_ of other design changes we have to start making. Most notably we have to completely re-think multisubs also, after I wrote what I did last night, it occurred to me that it seems to match very closely many of the statements about closures in S04 even down to the notion of "cloning closures" Which part? The first part? the whole design the whole design is sketchy as fuck. purl, what the hell do you know?!? i don't know, pmichaud the basic concept is that inner closures have to capture their lexical environment at the time the outer sub is invoked the first part provides us with an explicit way to do that the second part provides a way to have Parrot do that automatically pmichaud: "So, I propose that we add a "capture" method to Closure PMCs to set the outer_ctx for that PMC." So basically, it sets the outer_ctx of that closure to the current context? as well as checks that the current context is in fact the outer_sub i.e., you can only capture from the outer sub itself. (the check is optional, but probably useful) % jq has joined #parrot invoking a closure then *never* performs a capture because that capture must have been already done Yes, we should do the check, for sanity and to prevent weird hard to find bugs! i.e., the invoke vtable for captures becomes trivial. it checks for an outer context, throws an exception if one hasn't been set, otherwise it proceeds to do the sub Right. Hmm. Things could work. *this if parrot doesn't implicitly set the outer context for all of its inner subs, then compilers (i.e., PCT) will have to generate code at the beginning of each sub to do it explicitly I'd prefer not to generate that code, but will do it if need be what I really like is that we can potentially eliminate 'newclosure' altogether because we just clone the Closure after its outer context has been set (whether implicit or explicit) Yes, I get that bit. and that matches exactly what is written in S04 Can you explain your statement starting "if parrot doesn't implicitly set the outer context" a bit more to me? ideally (assuming it works), when I invoke an outer_sub I'd like it to automatically do a capture for all of its inner closures i.e., it iterates through all closures that have the sub listed as :outer, and sets the outer context directly Ah, and *that* is why you want to know what all of the inner ones are... yes. if we don't have that then the code generator needs to do a lot of $P0 = get_hll_global 'inner' $P0.'capture'() $P0 = get_hll_global 'inner2' $P0.'capture'() at the beginning of each outer sub the code generator can fairly easily generate this, though, since it knows all of the inner subs will this clobber existing closures of those inner subs? spinclad: uncloned ones, yes. spinclad: but this is what rgrjr has been indicating needs to happen % slightlyoff has joined #parrot % slightlyoff has left #parrot note that this approach means that the example in http://dev.perl.org/perl6/doc/design/syn/S04.html#When_is_a_clsoure_not_a_closure works naturally because assignment makes a copy (clone) % uniejo has joined #parrot ok, need to read the thread. (rereading S04 section now) correct url is http://dev.perl.org/perl6/doc/design/syn/S04.html#When_is_a_closure_not_a_closure pmichaud: I suggest wait for feedback on what Bob says. I agree. :-) If he agrees it's a good idea, maybe we create a branch and try this out. but if it works, this proposal seems much simpler and more straightforward than the existing implementation The first part of the mail looks like it may well be easily workable. The keeping a list of inners bit worries me. I agree And this may not play too wonderfully with MMD right off. oh? But I can likely fix that up. Well, the problem is that what are you invoking .capture() on? oh. You're doing a get_.*global Which looks in the namespace, ands hands you make a MultiSub Which you then will call .capture on. in the mail I actually did a .const 'Sub' Hmm, OK. But does that distinguish different multis? but yes, we'd need a way to get the explicit cub er, sub I'd be more inclined (hmm...maybe, this may not make sense...) To have .capture on a MultiSub go through the options, and any closures with an outer sub that matches that currently being executed get the outer context set. Hmm...or would that break things... ooh, I think that would work wonderfully. Yeah, but what if you update the outer of multiple variants? that's okay OK because it would mean that all of those multiple variants are inner closures of the outer sub I haven't convinced myself of that yet, but you've thought this through a lot more than I. OK, that reasoning makes some sense to me. and so they all need to have captures taken that's far better than what I was thinking jonathan++ It's also the most natural. yes, very natural. As in, the most natural from an implementation point of view. that's also what convinces me that this approach is pretty good -- things fall out naturally without a lot of funky stack or context manipulation (other than possibly the need to identify the inner closures) OK, if Bob isn't disagreeable, let's try and get the first part of this implemented in a branch soon. I'm still not convinced the second part will fly. Certainly, holding a list of GC-able items without making sure they are marked, feels scary to me. .oO { 'inner closures of outer sub' or '.. of outer closure (ie, call?)'? } But if we need to do that, we can maybe work out another way. I may decide that I prefer having a method on outer subs that takes a list of inner closures and performs captures on each i.e., outer.'make_captures'(inner1, inner2, inner3, ...) r29301 | julianalbo++ | trunk: : Allow concat of utf8 and iso-8859-1 without icu diff: http://www.parrotvm.org/svn/parrot/revision?rev=29301 but either way works for me if inner.'capture'() is implemented, it's trivially simple to create outer.'make_captures'(...) :-) or even just '!make_captures'() since we can infer outer If you know what outer's inners are... I'd still have to do the inner lookups, yes I don't see a way around that, unless outer somehow has a way of automatically getting the list itself OK, so you're saying if the first part of your proposal is implemented, then you've got enough to work with and it will unblock things? yes. assuming it works. :-) OK. That gives me some hope we might be able to resolve this soon. the only thing I'm not sure of is the :load/:init issue with lexicals, but I think I can work around that. at least far enough to keep progress moving until the branch comes in. OK. So we have a plan from here to try and get lexicals/closures sorted out. For HLL - are there tickets for the current issues you have with it? % jjore has joined #parrot % julian_ has joined #parrot % julian_ has left julian_!~jjore@mail0.w3data.com % jjore has left jjore!~jjore@mail0.w3data.com (have to run for about 15-20 mins... bbiab) yes, there are hll tickets. There's even a meta ticket. OK, good. I need to go for a bit too, to eat...back later meta ticket is #49812. current outstanding bug is #56650 Whiteknight++ was working on #56650, and there's information in the irc logs about how I proposed to fix it r29302 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] Remove some unnecessary garbage and cruft that I added for debugging, for problems which have since been resolved. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29302 Yeah, I'm probably not going to be able to get a solid patch up and running for that until sunday night I may go ahead and do it if I do any work on p6object, then. I'm knee-deep in this damned GC. I fix one segfault and expose two more! are there any blessed GCs? or are all GCs inherently the spawn of the underworld? % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk i'm starting to wonder % uniejo has joined #parrot pmichaud: after my last commit related to #39930 I'm testing to delete the workaround mentioned in #50092 and all looks good. Wan't to look at it? if it works and tests pass, feel free to commit a fix for #50092. I'll review the commit and if I see anything wrong I'll fix/revert. Ok, I go to commit when some more test finish. % purl has left purl!~purl@florence.kuiki.net % purl has joined #parrot r29303 | bernhard++ | trunk: : [Pipp PCT] Avoid infinite loop for curly string interpolation, : but break some tests. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29303 ICFP contest just announced. % barney has left barney!~bernhard@p549A01D1.dip0.t-ipconnect.de r29304 | julianalbo++ | trunk: : Deleted PCT grammar workaround, RT#50092 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29304 * jonathan returns icfp? icfp is probably international conference on functional programming or at http://pauillac.inria.fr/pli/icfp/ or sponsoring a programming contest at http://www.cs.virginia.edu/~jks6b/icfp/ or (see:icfp2007) % davidfetter has joined #parrot % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk Jeff Horwitz | mod_parrot: link: http://www.perlfoundation.org/parrot/index.cgi?mod_parrot % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % uniejo has joined #parrot % uniejo has left uniejo!~uniejo@0x573f51e2.vbrnqu2.static.dsl.tele.dk % shamu has left shamu!~krishna@c-67-161-28-111.hsd1.ca.comcast.net Whiteknight: ping icfp2008? r29305 | coke++ | trunk: : [punie] resolve RT#56670 with an explanatory comment diff: http://www.parrotvm.org/svn/parrot/revision?rev=29305 NotFound, is there any reason to keep RT#50092 open? cotto-work: waiting for pmichaud take a look on it. it looks fine to me. I think the ticket can be closed. NotFound++ I will close both tickets, then. % Z2Z has joined #parrot tickets-- NotFound++ just include 'Closes: #56670' in the changelog, it will autoclose. oh, wait. this isn't debian, is it? never mind. ++ for who added the blue box on the public interface karma tickets tickets has neutral karma I'm wondering why the const_cstring_hash is not marked, and supposing there is no reason why it does not brokes horribly. NotFound: I don't think constants can get collected. opes *can't* get collected jonathan: but the headers are, it isn't? Ah, no, I was confused. pmichaud: Read Bob's message? yes. I'm confused. Or he is. I need to think it over more. I'm writing a response now. OK. I think he misinterpreted what I wrote.jA And the hash itself is not an object, I see now. I'm writing a crappy evil ASP.NET output filter to translate .png to .gif to work around IE6 being unable to handle alphas transparency in PNGs. For a site that's meant to go production at the weekend. *sigh* yes, IE is horrible. jonathan: have you looked at pngfix? a solution in javascript? http://homepage.ntlworld.com/bobosola/ % rdice_ has left rdice_!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com % ruoso has left ruoso!~ruoso@201.45.49.162 although, I'm a little tired of Bob writing things like "I would remove all use of autoclose from PCT and Rakudo, replacing it with a general solution" when he doesn't even tell me what the "general solution" is. Tene: I looked at SuperSleight, which is a JavaScript solution also. It didn't help so much. And looking at pngfix, it's trying the same trick. % pac1 has joined #parrot that's all I'm asking for -- "what's the damn general solution?" the gloves are off! the texan is mad! Tene: But thanks the suggesting. :-) quick... where's the dr pepper and doritos? pmichaud: sorry i haven't paid close enough attention to help you more with that closure problem All I have been doing from the beginning is trying to get PCT and Rakudo to work with a general solution. I have no idea if I'm using autoclose or not -- that word means next-to-nothing to me. I'm just trying to follow the stupid documentation (which is wrong) or ask folks to tell me what the compiler is supposed to be generating so that things will work. I'm just writing to write standard PIR code that makes lexicals work, and nothing I try works. and the solution he offers also doesn't work. (for multisubs) mmd is yet to be redesigned % Z2Z has left Z2Z!~user@77.as-24.nienschanz.ru 'course that doesn't help you today particle: Huh? The spec isn't marked draft any more. or this month. or likely this summer at the rate things are being done. % donaldh has joined #parrot jonathan: but the implementation isn't done best line of code EVAR #include * Tene laughs. editor autocompletion gone wrong? cotto-work: where's that from? http://forums.thedailywtf.com/forums/p/9243/172728.aspx#172728 particle: Last time I read the PDD, I found it vague enough that it seemed too incomplete to implement. And I posted some issues I had with the draft on the mailing list, and I don't think any of them were addressed in the final. The useful bit in there is that you can subclass the MultiSub PMC to get your language's semantics. Which is what I will do for Rakudo. But it doesn't state the standard multiple dispatch algorithm for Parrot, etc. ...let alone does it mention anything about closures and multis... and based on what Bob Rogers is saying in his thread, the idea that we can have a single symbol pointing to a MultiSub PMC is itself a problem. because there's not a way to replace that symbol with the result of a newclosure so, we have to have a MultiSub PMC that allows us to replace a specific entry with a newclosured one which means we need a way to *locate* that specific entry so that it can be replaced % donaldh has left donaldh!~chatzilla@host213-123-171-12.in-addr.btopenworld.com all of which says (to me) that for a vm that is supposed to make dynamic languages easier to implement, Parrot spectacularly fails at this aspect of it. if Parrot's defaults can't handle standard closures and lexicals without HLL compilers having to go through a lot of hoops and symbol table manipulations to make it work, then it's really b0rken. I fail to understand why a closure has to be treated like a stand-alone function. Is not an already binded thing? pmichaud: If we make newclosure a method, then it can be implemented on MultiSub, just the way I specified for Capture (which maybe from what Bob says won't work), but replacing the entries that match. Or the newclosure op changes to recognize multis. "replacing the entries that match" sounds very tricky. I suppose one could determine "match" from lexid That match = that have an outer that is the current sub. Just as for newclosure on one closure. (If we want to forbid calling newclosure when not in the outer) I don't think the problem that bob is referring to has to do with calling newclosure when not in outer No. * jonathan thinks Bob's recommended solution to the closure issue is to do .const 'Sub' inner_sub = 'inner_sub' $P0 = new_closure inner_sub set_global 'inner', $P0 ....and then later 'inner'() # invoke inner sub ....so, each time the outer sub is invoked, we do a newclosure of inner_sub and store that in the namespace as 'inner' (of course, if the inner_sub happens to be a method, then we need to replace a method) pmichaud: What is the problem with that approach? Too much code? % iblechbot has left iblechbot!~iblechbot@233.16-dial.augustakom.net (and if the inner_sub happens to be a :multi, we have to make sure that 'inner' refers to a MultiSub and then replace whatever MultiSub (if any) was there from the previous invocation of outersub with the newly created closure) Replacing a method would imply replacing it in the class vtable! That *can't* be the right thing to do. I totally agree. But since methods are lexical as well, I can certainly come up with an example that uses methods instead of strict sub calls. and so whatever we do for subs we'd have to do for methods and thus my frustration that he keeps saying "use a general solution" but doesn't give one that is at all workable in Parrot. What is the reason to have to store the closure in a global named var? NotFound: I'll no paste an example % jan has joined #parrot "pmichaud" at 76.183.97.54 pasted "example of global symbol table" (7 lines) at http://nopaste.snit.ch/13562 pmichaud: I think S04 is helpful where it says, "In particular, named subroutines in any scope do not consider themselves closures unless you take a reference to them." I pointed that out to Bob in an earlier message, yes. I have no clue what that exactly means. And in that case, newclosure - the clone - is what the reference becomes. yes, that's what I had been thinking, but apparently Bob disagrees. Ah, OK. I *think* I understand it...let me just make sure, before I confuse things more... NotFound: in my example, foo() is a global sub (actually, global to the namespace -- a package-scoped sub) pmichaud: Is global, or is scoped in the enclosing block? NotFound: the symbol itself is global % Ivatar has left Ivatar!~graham@tu055.demon.co.uk 'sub foo' is equivalent to 'our sub foo' if we wanted to limit it to the enclosing block, it would be 'my sub foo' pmichaud: ok, but that applies to the sub, not the closure taken, it isn't? if we take a closure and expect 'foo()' to find it, then that closure has to be stored in the symbol table under 'foo' pmichaud: I think what S04 is saying is that the only type a named sub needs to be newclosure'd, is if a reference is made to it. only *time* jonathan: that's what I thought S04 was saying as well. let me rephrase when I read S04, that's what I think it's saying as well. And that means that the result of the clone is _not_ replacing anything in the symbol table. Instead, it's what you get if you write &sub. agreed That looks the reasonable thing to me. Now, if it's an immediate block *that you're taking a reference to*, it always needs to be newclosure'd. and that's why I think I shouldn't have to be doing newclosure at all for the Perl 6 examples I've been doing Note: taking a reference to. *not* invoking. I wonder if that is the confusion here. But that reference has to be taken inside the block, to have a correct context, I suppose. Now it's just considering what happens under recursion. btw, I think that the existing implementation of newclosure is suspect, also. I was very surprised to see how it's implemented r29306 | fperrad++ | trunk: : [Pipp] doc : - fix some links to PHP reference manual diff: http://www.parrotvm.org/svn/parrot/revision?rev=29306 .sub 'foo' $P0 = whocares() .lex '$a', $P0 bar() .end .sub 'bar' :outer('foo') find_lex '$a' bar() .endGrr ...wow, no newlines hint: nopaste :-) Yeah, I wanted to have it in front of me while I talked about it! .endGrr ? Nice way to end rant comments X-) "jonathan" at 85.216.151.226 pasted "example" (9 lines) at http://nopaste.snit.ch/13563 r29307 | fperrad++ | trunk: : [install] : - fix lolcode test diff: http://www.parrotvm.org/svn/parrot/revision?rev=29307 In this case, when we invoke bar the first time, from foo, we want bar to capture (have it's outer set to) foo's current outer context. I guess a call on bar.capture() inside bar would then want to be a no-op, since the outer hasn't changed Or would you have not been emitting a capture there? we would never call bar.capture there we call capture from the _outer_ sub. Right. So we'd just never emit it. So that recursive example works with your scheme. all invocations of bar would end up using the same foo as an outer context Right. Which is, I believe, correct. "pmichaud" at 76.183.97.54 pasted "lexicals and recursion" (5 lines) at http://nopaste.snit.ch/13564 % shamu has joined #parrot 13564 is a more interesting recursive example (that I gave in the mail thread) I think the key thing in Bob's example is here my $recur = sub { Note - he takes a reference to an (anonymous) sub pmichaud: but following the rule of taken a reference, it's still not a closure. That captures the current outer - the clone of the way things are now. And that's the point of the newclosure. so, you're saying his example actually works under my proposal? or...? I don't immediately understand his example. I'm saying that if we are doing what you suggest *and* we are doing newclosure when a reference is taken to a block/sub (anything that compiles down to a .sub in Parrot), then yes. Or at least, I think so. I already mentioned that 'newclosure' is effectively a clone. nod and that assignment takes a clone I don't know perl6 rules, but looks logical to me. (since assignment copies its rhs anyway) pmichaud: it takes a sub and returns a closure, it isn't? % paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net pmichaud: At this point, since we both think this may work, I wonder if it's worth us just making a branch, implementing your suggestion, along with making sure we put newclosure in the right place (when a sub/block gets referenced), then translating Bob's example to Perl 6 to actually try it... % pac1 has left #parrot I'd rather see it translated to PIR, personally. even a hand translation But if is as you say in the thread just a synonym to call capture on the sub, the only reason for his existence is as optimization, I think. if you're correct, then my guess is that Bob doesn't recognize that my $recur = sub { ... } results in a newclosure (or a clone) pmichaud: working on it (hand translation) pmichaud: at pir level the anonymous is still anonymous, or must have a name assigned? NotFound: it has an internal name but that name doesn't really mean anything, and we can even keep it from appearing in the symbol table pmichaud: then I think it must be the same than a named one. That is, taken a new closure on it at usage. jonathan: if you really need to be doing your $otherjob stuff, this can wait. Maybe the problem is that Bob thinks that the sub is already a closure, not a sub. Meh, $otherjob already got over 8 hours of me today And I'll be doing stuff for them at the weekend. notfound: in Parrot, any sub that accesses its outer lexical context is a Closure PMC in effect, all nested subs are Closure PMCs er, all nested blocks are Closure PMCs If I wasn't doing this I'd only be drinking beer and looking at lolcats... % gryphon_ has left gryphon_!~gryphon@dsl-209-221-185-54.zipcon.net jonathan: okay, just wanted to let you know my sense of priority/urgency. pmichaud: but that is at execution, not at declaration, I suppose. NotFound: no, it's at declaration in PIR a nested block in PIR has an :outer(...) flag. That causes it to be created as a Closure PMC instead of a Sub PMC of course, when the Closure PMC is created this way it doesn't have an outer context -- i.e., it hasn't captured its lexical environment yet Mmmmm.... So a declared and an active one are the same type of object? so the discussion centers around "when does the inner closure captures its lexical environment?" Closure PMC and Sub PMC really differ only in type (and the implementation of invoke/freeze/thaw/etc.) and the fact that a Closure PMC has a value for outer_sub (outer_sub is NULL in a Sub PMC) % paco has joined #parrot % paco has left #parrot I'm really glad we have compilers, because translating HLL code to PIR gets really tedious... well, I don't think it needs to be a literal translation -- just enough to show the same thread of execution I'm going ahead and sending a message pointing out the my $recur = sub point, and then I'm done for the evening (dinner here and need to spend time with kids) OK, 2 mins and I have a translation. Feel free to add it as a response to my previous message. :-) Looks to me, according that explanation, that the problem is to distinguish between the static closure and the dinamic one. I'll look at the translation a bit later tonight gotta run If you don't make the newclosure thing, you don't have the dynamic context stored on it. % paco has joined #parrot % teknomunk has joined #parrot % kid51 has joined #parrot * jonathan has got Bob's example to work in PIR by just taking newclosure whenever a reference is taken to a block. I think I'm starting to understand... When calling directly, the context is taken directly by the current one. When taking the reference, is captured by the newclosure operation for later usage. If that is correct, maybe having two different types will make things clearer. r29308 | jkeenan++ | parallel: : P::C::Base, P::C::Parallel: YAGNI. No need for parallel object at this time, : as two wrappers around Storable functions will suffice. Eliminate one test : file whose tests have been moved to another file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29308 r29309 | julianalbo++ | trunk: : Reanme disassemble to pbc_disassemble by Reini Urban, RT#56542 diff: http://www.parrotvm.org/svn/parrot/revision?rev=29309 Nice typo. Nah...nice typos are the ones that accidentally lead to rude words. :-) NotFound: See my post to the list, which I hope helps clear things up a bit. r29310 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29310 % Andy has left Andy!~AndyL@host3130.follett.com jonathan: yes, that confirms whay I was starting to understand. $P0 = find_global 'anon_1' | $P1 = newclosure $P0 Maybe a help from the parrot side to the hll writers can be to make an operation that combines those two. I'd rather leave it as two. You might not be doing find_global. find_hll_global and all manner of other things are possible. We can just expect to see what the more frequent usage will be, an then maybe add an operation to shorten it. * tewk is up over his eyebrows in parrot calling convention innards (src/inter_call.c) I used to know this stuff by heart, two years later and I can't remember a thing. tewk: I looked in there just a couple of days ago and...hate. I'm sure I saw stuff like src.sig.sig->c[0].... tewk: that's a clear sign of too complex code. Well, not, the sign is clear when is just two monts X-) tewk: You are working on the GSoC project doing NCI things, right? Well I think I got enough of it back in my head now. Yeah I'm getting ready to jit nci calls, it really isn't going to be that bad. I just have to call a bunch of functions in assembly (src/jit_emit.h:build_call) The jit is also a less than ideal example of clean code X-) okay, NotFound. jit? jit is a Just In Time compiler. Or just more Java hype. or new Parrot hype! or a less than ideal example of clean code X-) the current Parrot_jit_build_call_func is at least 2 or 3 refactors out of date. tewk: pmichaud and I were pondering changes to inter_call.c - I guess touching it now would be disruptive to what you are doing? NotFound: inter_call.c makes all the cool calling convention stuff work. tewk: for some values of 'all' You should have seen inter_call.c two years ago. I did a major refactor to get it to look as good as it does. Chromatic has cleaned it up quite a bit more too. jonathan: I'm not changing anything, just remembering how it works. There are a lot of helper functions, and I'm just going to use those. tewk: I don't say that is all bad, but is very hard to diagnose the known bugs. I know what you mean, I always say to my self that it doesn't need to be that complex. But once I remember all the things it does, its hard to reduce the complexity. % Ademan has left Ademan!~dan@h-67-101-47-131.snfccasy.dynamic.covad.net It does boxing, unboxing, INSP conversion, slurpy, named, flat, NCI, PCCMETHOD, I just need a few more acronyms :) jonathan: what were you goint to change, the optional vs named stuff? % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net Apparently there are some changes too. Or maybe they are optional vs named related. I'm not completely sure. I haven't been thinking about it much, pmichaud just mentioned it was something that needed doing. And both of us find that chunk of the codebase more than a little hard to get into. % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 r29311 | jkeenan++ | parallel: : [configure] Refactor code from within runstep() into _handle_exec_protect(), : then test it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29311 Oooh, that last commit message was wrong. r29312 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29312 % kid51 is now known as kid51_at_dinner the thread that talks about PCC changes is at http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/fce44e38aa856be9 see also the May 28 Perl 6 Design meeting notes % AndyA has left AndyA!~andy@ca93nt.hexten.net % Zaba has joined #parrot jonathan: still around? nope. % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % AndyA has joined #parrot pmichaud: Are there tests written, If you write the tests I'll make the changes. afk, I'll reread the above. % Ademan has joined #parrot % buildbot has joined #parrot no tests written yet. % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % kid51_at_dinner is now known as kid51 % contingencyplan has joined #parrot pmichaud: Sort of. :-) About to head to bed in a moment. % Theory has joined #parrot % paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net % paco has joined #parrot pmichaud: Guess now you're gone - sorry I missed the message earlier. Wanted to get off the computer for a bit before sleeping...trying to sleep + head full of closures/lexicals is probably a bad combination. If you're about tomorrow, I should be about a fair bit too... * jonathan afk % confound has left confound!hdp@floe.aq literal still around? r29313 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29313 r29314 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29314 r29315 | jkeenan++ | parallel: : Update MANIFEST. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29315 r29316 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29316 % silug has joined #parrot pmichaud: (backlogging some) re http://nopaste.snit.ch/13564: i don't understand why on the second call of bar you don't get a redeclaration of &foo error. given this, is there a case of replacing one closure with another? % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net r29317 | cotto++ | trunk: : [codingstd] wrapping more macro args, this time without breaking the build diff: http://www.parrotvm.org/svn/parrot/revision?rev=29317 spinclad: perhaps this should result in a redeclaration of &foo -- I don't know. I haven't seen anything in the spec that indicates it would be an error. istr that, without multi or proto, redecl is an error. will look for it. well, I don't know if that technically counts as a redecl yes, without multi or 'is instead', redeclaration is an error. (S06) question would be, does a dynamic redecl count, or only static? (dynamic: same code text, different bindings.) i don't recall it coming up in spec or discussion before. I don't know. r29318 | cotto++ | trunk: : [codingstd] allow stringification in macros diff: http://www.parrotvm.org/svn/parrot/revision?rev=29318 r29319 | jkeenan++ | parallel: : Consolidate multiple test files per configuration step into a single file. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29319 r29320 | jkeenan++ | parallel: : Renumber t/steps/inter_lex-03.t to -02.t to maintain sequence pending further refactoring. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29320 % peepsalot has joined #parrot r29321 | jkeenan++ | parallel: : Renumber test. Consolidate two files into one. Two tests not yet passing, probably due to difficulty of testing interactive configuration steps. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29321 r29322 | cotto++ | trunk: : [codingstd] wrap more macro args. now down to 192 c_macro_arg failures. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29322 % confound has joined #parrot r29323 | jkeenan++ | trunk: : For consistency, call: $conf->steps->[-1]. diff: http://www.parrotvm.org/svn/parrot/revision?rev=29323 % kid51 has left kid51!~jkeen@pool-71-247-57-178.nycmny.east.verizon.net % tjh has joined #parrot % cotto_home has left cotto_home!~cotto@96-26-202-243.sea.clearwire-dns.net % cotto_home has joined #parrot % silug has joined #parrot % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net % cotto_work has joined #parrot % cotto-work has left cotto-work!~cotto@tide502.microsoft.com % Ademan has left Ademan!~dan@h-68-164-170-194.snfccasy.dynamic.covad.net % Andy has joined #parrot 1.625-1.558 0.0669999999999999 (1.625-1.558)/1.558 0.0430038510911425 (1.625-1.5)/1.5 0.0833333333333333 % buildbot has left buildbot!~buildbot@smtp.matisse.net r29324 | cotto++ | trunk: : [codingstd] refactor some macros to make coding standards easier to test diff: http://www.parrotvm.org/svn/parrot/revision?rev=29324 sigh, there are already too many things named "capture" without using that to mean "closing over" as well... % peepsalot has left peepsalot!~peepsalot@24.174.8.249 % Andy has left Andy!~Andy@64.81.227.163 % Psyche^ has joined #parrot % bgeron_ has joined #parrot % bgeron has left bgeron!bgeron@toad.stack.nl % Patterner has left Patterner!~Psyche@e177237207.adsl.alicedsl.de % Psyche^ is now known as Patterner % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net % tjh has left tjh!~chatzilla@user-0cdfo61.cable.mindspring.com captcha? captcha is probably an acronym for "completely automated public Turing test to tell computers and humans apart", it is a type of challenge-response test http://en.wikipedia.org/wiki/Captcha and we only barely get away with the Capture type by capitalizing it... but there's also regex captures % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net I wonder what did I miss in rakudo I was absent for 2 weeks % silug has joined #parrot % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net some good stuff -- lexical variables are in good shape, many more tests pass, some very busy days. TimToady's STD grammar parses itself now too. that sounds quite good :> check pmichaud's and jonathan's weblogs for highlights, i don't remember it all % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru bad movies and coding go surprisingly well together r29325 | cotto++ | trunk: : [codingstd] wrap more macro args (weeeeee!!!!!) diff: http://www.parrotvm.org/svn/parrot/revision?rev=29325 spectest_regressing seemingly still takes a lot of time to run is there any reason not to delete a macro that's defined but never used in the code? in this case, VOIDPTR_ASSIGN in include/parrot/parrot.h hum what's &?BLOCK? The object for your current block. You can use it for recursion on anonymous subs in P6 aha