|
05:15
PerlJam joined,
moritz_ joined
16:21
masak joined
17:57
pmichaud joined
17:58
colomon joined
|
|||
| masak | o/ | 18:59 | |
| moritz_ | \\o | 19:00 | |
| spinclad | o/ | ||
| colomon | \\o | ||
| TimToady | o | ||
| pmichaud | _o_ | ||
.oO( impersonation of a former maverick ) |
19:01 | ||
| moritz_ | so, shall we start? | ||
| masak | let's. | 19:02 | |
| moritz_ | I'll just go ahead... | ||
| I patched NQP-rx to have methods that generate new array and match objects | 19:03 | ||
| and then I started a rakudo branch to use that | |||
| ran into problems overriding the vtable methods in the Match class | |||
| probably need to discuss with pmichaud | |||
| apart from that, applied patches, kept rakudo up to date wrt parrot | 19:04 | ||
| started my contribution challenge | |||
| masak | \\o/ | ||
| colomon | moritz_++ # contribution challenge | ||
| moritz_ | already got one contribution - see proto.perl6.org/ | ||
| more ideas welcome | |||
| that's about it | |||
| blockers: lack of parrot-fu | 19:05 | ||
| TimToady | .oO(parrot-flu?) |
||
| masak | seems the 'things starting with q/Q' bug was fixed the other day. that's a relief. | ||
| moritz_ | does parrot-flu bring parrot-fu to you? | ||
| masak: I fixed it nqp-rx | |||
| masak: the same fix didn't work in rakudo | 19:06 | ||
| masak | ah. :/ | ||
| TimToady | pay no attention to the joker behind the curtain | ||
| masak | the 'closures not cloning' bug is still wreaking havoc for various people. | ||
| and they're all finding the same pir::clone_mumble fix. | |||
| ...thinking it'll be easy to apply to Rakudo. :) | |||
| colomon | sorear wanted to talk to pmichaud about sorear's proposed fix, I know. | 19:07 | |
| something about changing PAST. | |||
| I think we'd all be extremely happy to see the closure bug fixed. | 19:09 | ||
| spinclad .oO(doesn't understand why newclosure (newlexpad?) shouldn't happen just at .() time) | |||
| moritz_ | are we making progress on this issue? | 19:11 | |
| I think I saw some in #parrot | |||
| pmichaud | spinclad: you have to do newclosure at the time the closure is created, not when it's invoked. | ||
| TimToady | there was some pushback in #parrot last night on the subject | ||
| pmichaud | I added some comments in #parrot this morning | ||
|
19:11
sorear joined
|
|||
| colomon | pmichaud: can you give us a super quick summary of what's involved? | 19:12 | |
| moritz_ | irclog.perlgeek.de/parrot/2010-05-04#i_2291929 | ||
| for the discussion | |||
| spinclad | pmichaud: i understand that's the prescription, i just don't follow why. but i don't want to dive into detail here. will review moritz_'s link... | 19:13 | |
.oO( create closure _by_ invoking it... ) |
19:14 | ||
| pmichaud | spinclad: short answer: sub xyz($a) { return -> { say $a } }; my $b = xyz(3); my $c = xyz(4); $b(); | ||
| by the time you get around to invoking $b, you have to have already cloned $a. | 19:15 | ||
| waiting for $b to be invoked to do the cloning is too late. | |||
| TimToady | I thought spinclad was saying use an empty .() at clone time as a sort of strange curry-the-clone-into-existence | 19:16 | |
| spinclad | the calls to xyz create two xyz closures, which the blocks returned are scoped inside. | ||
| so they should see different $a's. | 19:17 | ||
| TimToady | spec currently says that the -> is actually clone on entry to xyz, more or less | ||
| *cloned | |||
| not really for bare lambda like that, but for named functions | |||
| pmichaud | right | 19:18 | |
| spinclad | TimToady: no, i meant .() as the call operator | ||
| TimToady | so if you take a ref to them before the code, you still get the clone | ||
| pmichaud | spinclad: "create closure" is "newclosure" | ||
| spinclad: oh, are you saying that the inner closure should be created on the invocation of xyz? | |||
| TimToady | so in a sense, it is a .() time, just xyz's .() time, not the closure's | ||
| pmichaud | right | ||
| spinclad | no, the outer closure | 19:19 | |
| pmichaud | PCT already does that, but it currently does capture_lex | ||
| spinclad | that's where $a is bound | ||
| pmichaud | we can have it do newclosure instead, but that gets a bit wasteful for immediate blocks | ||
| (and immediate blocks are the larger majority of blocks) | |||
| TimToady | hence the verbiage in the spec about doing it lazily :) | ||
| pmichaud | so what I proposed on #parrot is that PCT return newclosures by default for all non-immediate blocks | ||
| and the more likely option is that it return newclosures for non-immediate blocks being used in non-void contexts, which PCT also knows about already. | 19:20 | ||
| TimToady | not sure how you're using 'immediate' here... | 19:21 | |
| pmichaud | bare blocks | ||
| bare blocks == 'immediate' | |||
| TimToady | I'd think those would be pretty rare | ||
| pmichaud | well, it's also for things like blocks to while/for/if/etc. | ||
| TimToady | except in .t files :) | ||
| but those aren't bare blocks, and have to be cloned | |||
| (conceptually, anyway) | 19:22 | ||
| pmichaud | they need cloning because...? | ||
| exceptions? | |||
| TimToady | outer vars might have been rebound, maybe? | ||
| pmichaud | oh | ||
| spinclad | ( i wonder if we're not currently delaying creating lexpads by one step, so in my view it's the outer lexpad that gets (and should get) created at scope entry, which makes perfect sense to me. difference in terminology? ) | 19:23 | |
| pmichaud | TimToady: so, if an outer var gets rebound, the body of a while shouldn't see that? | ||
| that seems... odd | 19:24 | ||
| TimToady | it should see it on the next iteration | ||
| pmichaud | okay, that's what happens now | ||
| it's still an "immediate block" -- it's just a new invocation instance | |||
| oh wait | |||
| on the next iteration, but not the current one? | |||
| my $a = 'abc'; while $test { $OUTER::a := 'bar'; say $a; } | 19:25 | ||
| TimToady | depends on what we link the inner $a to, the name $a or the container in it | 19:26 | |
| pmichaud | so, which is it, o specmaster? | ||
| TimToady | er... | ||
| spinclad | ( no clone, works great? ) | ||
| TimToady | I just feel a bit uncomfy with starting out by dividing closures into two categories, from the extensibility standpoint | 19:27 | |
| logically, they all clone | |||
| and then we optimize from there | 19:28 | ||
| spinclad | ( clone == create lexpad? ) | ||
| pmichaud | right, no problem. That's what PCT is intended to do. | ||
| spinclad: at the point of the clone the lexpads already exist | |||
| TimToady | and while is not treated diffierently from mywhile, in the abstract | ||
| masak likes that | |||
| pmichaud | anyway, the short-term solution appears to be that non-immediate blocks need 'newclosure' instead of a simple capture_lex . | 19:30 | |
| TimToady | I see cloning as kind of a one-clone-lookahead, in the sense that on entry to xyz we make sure the inner lambda has a callable lexpad by the time we call it | ||
| extra clones are negotiable | |||
| so it's like you always get one clone for free, which you need anyway for immediate blocks, and then the control structure using the lambda tells it whether it needs to reclone | 19:31 | ||
| but maybe that's just me :) | |||
| pmichaud | PCT does that for the most part | 19:33 | |
| it doesn't quite do the "clone every inner lambda" yet, because that gets tricky when dealing with package-scoped subs in non-p6 languages. | |||
| TimToady | yeah, global subs are somewhat immiscible with lambdas, though we tried valiantly in p5 | 19:34 | |
| pmichaud | anyway, the solution for PCT is slightly more than just changing capture_lex to newclosure | 19:35 | |
| and the solution for Rakudo is a lot more complex than that, because Rakudo blocks aren't PAST::Blocks | |||
| spinclad | ( i think of xyz as already running on its lexpad, whose entries happen to be cached in registers, irrelevantly; so xyz needs its lexpad immediately, not just for the sake of subscopes... ) | ||
| pmichaud | spinclad: the point is that the subscopes have to already be bound to the current running xyz | ||
| TimToady | well, a lambda needs its lexpad before it ever starts binding its parameters, since they live there | 19:36 | |
| pmichaud | there's also the difficulty that parrot doesn't really do dynamic outer binding properly | ||
| spinclad | sure, they're bound to xyz's lexpad when they're created == invoked | ||
| pmichaud | not necessarily | 19:37 | |
| TimToady | I suspect we're having two interfering conversations | ||
| pmichaud | the :outer('...') flag in Parrot binds to the static copy of a sub, not to a dynamically executing one | ||
| TimToady | yow | 19:38 | |
| spinclad | how can that work?? | ||
| pmichaud | and parrot assumes that this "static sub" has a pointer to the current executing context. But that's not always the case with recursion or closures. | ||
| masak | this discussion is very interesting. I hate to interrupt it in anyway, but does the fact that you're having it mean that the #rakudosketch is finished for today? | 19:39 | |
| s/anyway/any way/ | |||
| TimToady | it's not the case with any kind of threading | ||
| pmichaud | my #rakudosketch report is that I plan to be back on rakudo development more full-time-ish next week | ||
| spinclad | i apologize for derailing #rs | ||
| pmichaud | TimToady: correct, that too. | ||
| colomon | pmichaud: \\o/ | ||
| masak | spinclad: I must confess to being very interested in what was said. otherwise I'd probably have intervened sooner :P | 19:40 | |
| pmichaud | however, don't get hopes up too far -- Paula's preliminary test results today aren't all that promising. we'll likely know more on Thursday morning. | ||
| moritz_ keeps fingers crossed | 19:41 | ||
| colomon | we'll be keeping you both in our thoughts and prayers. | ||
| spinclad too | |||
| moritz_ | anybody else has anything rakudo related that needs discussing? | 19:42 | |
| colomon | pmichaud: any chance there are bits of the list/seq/array mess that could be shaved off and approached by the rest of us? | ||
| pmichaud | colomon: in my experience it's one of those all-or-none propositions | 19:43 | |
| colomon: you can't solve one small piece without affecting a ton of other bits. | |||
| (as evidenced by how radically parts of the spec have changed when these questions have come up in the past) | 19:44 | ||
| I told Paula this morning that I either have to get back to some significant Perl development next week, or I need to start telling others to just do things without my help | 19:45 | ||
| (she's in total agreement with that, btw) | |||
| s/next week/by next week/ | |||
| we do want to get a release out, and I need to not be a bottleneck. | 19:46 | ||
| spinclad | could a first step be to translate static Seqs into the static part of mixed Seqs (/Lists/Arrays) ? | 19:47 | |
| pmichaud | that doesn't look right at first reading to me | ||
| TimToady | mostly we need to nail down exactly when a user sees an iterator, and hide them the rest of the time | 19:48 | |
| spinclad | build the machinery to draw on the lazy part when one's cursor exhausts the static part | ||
| pmichaud | I suspect that a user sees an iterator in two cases -- when explicitly requested via .iterator, and for filehandles-as-scalars | ||
| spinclad | then start populating the lazy parts | ||
| pmichaud | spinclad: I have that machinery already | ||
| moritz_ | pmichaud: that looks about right | ||
| pmichaud | spinclad: that's not the challenging part | ||
| masak | the iterator shouldn't jump out when the user does .perl, as happens now. | ||
| pmichaud | in general, most list-y things should return instances of List | 19:49 | |
| TimToady | iterators are sort of like naked singularities | ||
| pmichaud | which encapsulates any laziness and iterators | ||
| moritz_ | pmichaud: colomon and I worked on a proposal for a design the other day... should I summarize it in a mail? | ||
| pmichaud | moritz_: that'd be fine | ||
| spinclad | draw a better distinction between a List and a cursor iterating it? | ||
| colomon | moritz_: please cc me | 19:50 | |
| pmichaud | spinclad: that's not really the challenge either | ||
| the tricky part is that List will sometimes have Array-like behaviors, and sometimes it doesn't | |||
| i.e., sometimes you need a List to remember its previously generated elements, and sometimes you want it to forget them as they're generated | |||
| moritz_ | spinclad: please read irclog.perlgeek.de/perl6/2010-05-02#i_2285198 | ||
| colomon: sure | |||
| spinclad | will do | 19:51 | |
| TimToady | as I see it, Lists and Arrays are essentially the same data structure, but with rather different APIs | ||
| pmichaud | and the demarcation seems to be when a List is bound to a container of some sort | ||
| moritz_ thought that was Seq and Array, but I might be wrong | |||
| pmichaud: that's the line between something that remembers its value, and something that doesn't | |||
| colomon | I think we still have terminology problems (or class naming problems) | ||
| pmichaud | colomon: yes, we do. | 19:52 | |
| spinclad | moritz_: yes, i saw that | ||
| (the backlog link) | 19:53 | ||
| TimToady | my gut feeling is that we should first ignore the immutable/mutable distinction in figuring out the API, and then add it back in later | ||
| pmichaud | TimToady: yes, that's the approach I was taking | ||
| TimToady | and since Seq is immutable, it doesn't really figure | ||
| pmichaud | +1 to that | ||
| colomon | +1 | ||
| pmichaud | I was also planning to ignore Seq altogether for the first pass. I think it leads down a blind alley. | ||
| blind alley -- dead-end alley. | 19:54 | ||
| TimToady | however, that is not to say that we shouldn't view the problem from the FP viewpoint occasionally :) | ||
| pmichaud | certainly | ||
| [particle] | even a blind alley finds an acorn occasionally. | 19:55 | |
| TimToady | even a slotted spoon can hold a potato | ||
| spinclad | (List/Seq/Array immutable (from this pov), cursor mutable) | ||
| pmichaud | spinclad: Array has to be mutable | ||
| so you can push/pop/shift/unshift | |||
| spinclad | yes, but not for iterating: that you do with a cursor | 19:56 | |
| pmichaud | spinclad: sure, but what's the type of the cursor? | ||
| spinclad | dunno yet | ||
| pmichaud | the cursor needs to be embedded in a List of some sort | ||
| spinclad | attached to ? | ||
| masak | just wanted to say that I've been going over use.perl.org/~masak/journal/39597 and closing some more tickets that've been fixed. about a third of them are fixed now. | ||
| pmichaud | otherwise we see all of the cursors, which is what we're trying to avoid | 19:57 | |
| colomon | masak++ | ||
| we probably shouldn't rehash the entire list/seq/array thing on rakudosketch, I reckon. | |||
| pmichaud | fairy nuff | 19:58 | |
| colomon | but it would be great to have this conversation asap | ||
| (ie rakudosketch determination is that we need to have this conversation. :) | |||
| moritz_ | I'm writing this email right now - I hope for non-bikesheddy replies | ||
| (which is why I send it to p6c, not p6l :) | 19:59 | ||
| pmichaud | definitely to p6c for now | ||
| anyway, my view is that most list-y type operations should be returning something that ~~ List | |||
| and that List knows how to do things like .[] and can have values shifted off of it | 20:00 | ||
| TimToady | a List is sort of an array that knows its a cursor | ||
| pmichaud | and that .perl on a List doesn't cause any generators to appear | ||
| s/generators/iterators | 20:01 | ||
| spinclad | (does .perl twice on the same List show the same list?) | ||
| pmichaud | .perl on a List produces either the elements or the generators for the elements | ||
| spinclad: depends on how the List is bound | |||
| TimToady | .perl doesn't return a List | ||
| pmichaud | I meant that .perl could return either "5, 6, 7 ,8" or "5..8" | 20:02 | |
| i.e., if the internal iterator had a suitable mechanism for .perl-ing itself, it can do that as opposed to making the list non-lazy | |||
| "reifying the entire list" | 20:03 | ||
| TimToady | I think .perl should certainly be biased in terms of an abstract representation, especially if it's impossible to make entirely concrete | ||
| pmichaud | either way, .perl hides the existence of the internal iterator if it can | ||
| moritz_: does your description exclude Seq ? | 20:04 | ||
| moritz_ | pmichaud: yes. I have no clue what Seq is supposed to be | ||
| pmichaud | moritz_: +1 to that | ||
| leave Seq out for now | |||
| anyway, I will plan to focus on closures and lists over the next few days | 20:07 | ||
| see if we can get those ironed out finally | |||
| colomon | +1 | 20:08 | |
| TimToady refrains from making pun on 'sense of closure' | |||
| moritz_ | +2 | 20:09 | |
| pmichaud | afk for a while | ||
| spinclad echoes moritz_ | 20:10 | ||
| colomon | moritz_: not that it's any surprise after pmichaud's comments, but I finally took a decent look at the lazy seq / array patch, and it's probably not what is needed. | ||
| does look like some clever work, for sure, but I don't think it fits in with pmichaud's plans. | 20:11 | ||
| I'm hoping at making major inroads on the Numeric work this week. | 20:14 | ||
| pmichaud | (my 'plans' being primarily driven by 'what can actually work' :-) | ||
| masak | good plan :) | ||
| colomon | and I might tackle implementing classify if someone doesn't beat me to it. ;) | 20:15 | |
| q | |||
| spinclad | other business? | 20:22 | |
| [particle] | everyone getting ready for gsoc? has the bonding begun? | 20:23 | |
| moritz_ | masak has bonded us, yes | ||
| masak | yep. | 20:24 | |
| moritz_ | he has a commit bit, a blog, knows where the code lives, ... :-) | ||
| masak | ready to rock and roll. | ||
| moritz_ | only his mentor is idling in Iceland | ||
| [particle] | phew, i was worried about him. | ||
| masak | :) | ||
| moritz_ | I think pmurias also got in contact with ruoso :-) | ||
| colomon | masak: when do you intend to start your GSoC work? | 20:25 | |
| masak | colomon: as soon as $work settles down, basically. | ||
| colomon understands that issue all too well... | |||
| masak | I could set an optimistic starting date, but that wouldn't be underpromising and overdelivering :) | ||
| so let's say May 28th, when work is supposed to start :) | 20:26 | ||
| colomon | :) | ||
| I was mostly wondering how much of it might sneak into R* | |||
| masak | I'm hoping a simple Buf type might, at least. | ||
| masak almost typo'ed 'Bug' | 20:27 | ||
| spinclad | :) | ||
| pmichaud | I hope a simple Buf type, but we'll take whatever is available. | ||
| I think masak has already over-delivered on the Bug class :-) | |||
| masak | :) | ||
| would be nice to get reading of binary data to work, too. | 20:28 | ||
| but no promises. | |||
| we'll see. | |||
| moritz_ | masak: somehow I think reading binary data will be easier than writing | ||
| spinclad | it's easy to find them, though; just search for things that ~~ Bug | ||
|
20:28
colomon left,
colomon joined
|
|||
| masak | spinclad: RT gives 658 hits :P | 20:29 | |
| colomon | dang it, one day I'll stop closing the wrong window on my multi-screen setup. | ||
| masak | only 104 of those are new/open, though. | 20:31 | |
| maybe the rakudosketch ended for today? | 20:36 | ||
| pmichaud | probably. I think I hijacked things today -- apologies. I should be in better form next week :) | 20:37 | |
| moritz_ | pmichaud: I think it was great that you did hijack things | ||
| masak | aye. | ||
| spinclad | with my help... | ||
| masak | thanks to everyone for participating. in many ways, we're on track, which feels nice. keep closing those tickets! | ||
| moritz_ | pmichaud: we discussed topics we were in dire need for discussing with you | ||
| pmichaud | moritz_: more to come, too :) | 20:38 | |
| spinclad | i intensely felt the presence of the right people to talk about both the immediate pressing R* and deeper issues, and the conflict between focuses. may it somehow be for the best! | 20:42 | |
| gavel? | 20:52 | ||
| masak | *nod* | ||
| spinclad | <bang!/> | ||
|
20:53
masak left
|
|||
| spinclad | (wishing to amend some words of mine earlier: cursor would also be immutable; an iteration loop would pass itself the next cursor in sequence each time around.) | 23:08 | |