weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 15 January 2011.
01:50 dukeleto left, dukeleto joined 10:20 cognominal joined 10:54 dukeleto left, dukeleto joined 14:23 cognominal left, cognominal joined 14:27 cognominal left 14:31 cognominal joined 14:52 dukeleto left 14:53 dukeleto joined 14:54 dukeleto left, dukeleto joined 17:53 masak joined 17:54 pmichaud joined
pmichaud My pre-report: 17:54
* Worked on planning nqp migrations with jnthn++
* Working on draft roadmaps for nqp, rakudo, and R*
* Plan to do R* release later tonight 17:55
* I'm thinking of moving R* releases to be every three months instead of monthly.... any comments?
(we can of course do more often if we have a reason to do one early)
tadzik moving from "every month" to "when we have something interesting" may not be a bad idea, some people look at the changelog and say "...is that is?". Maybe it will get more marketingy to release when there's something to show off 17:57
pmichaud I'm also thinking of removing the comments we have about Rakudo not being production ready or "1.0" release. I'm not going to add comments that say it is production ready -- I just think we're at a point where we don't have to be quite so explicit about being not ready
[Coke] +1 from me on that.
pmichaud tadzik: I absolutely want to continue with timed releases. Going to "when we have something ready" leads back to the p5 release schedule abomination
masak +1 on every three months 17:58
jnthn +1 on every three months with the caveat that if 6model changes are merged sooner than that, it's probably notable enough for a release.
tadzik pmichaud: right
pmichaud jnthn: I somewhat think that three months is going to be about the right time scale for merging 6model 17:59
I'm not sure we'll be done (back to the current level of rakudo) in two
colomon +1 on every three
jnthn accepts that as a challenge :P
pmichaud but yes, if 6 model is ready two months from now, I'm absolutely okay with releasing then
I'm wanting to adopt a stance of "we deliver every three months no matter what, and more often when conditions warrant" 18:00
masak +1 on challenging jnthn to do the 6model merge in three months :P
jnthn masak: :P
PerlJam +1 on both removing the comments and quarterly releases. 18:01
pmichaud [Coke]: your +1 was in reference to the removal of comments? (just confirming)
colomon +1 on challenging jnthn :) 18:02
18:02 diakopter joined
pmichaud afk, lunch and errands. bbi90, I hope. 18:03
jnthn Challenge accepted. :P
diakopter might miss #phasers; nothing to report really
pmichaud oh, and another item
* I think I finally helped diakopter++ to unblock :)
PerlJam So, "normal" releases are Jan, Apr, Jul, Oct ? or some other months?
jnthn (unblocking diakopter) yay! pmichaud++, diakopter++
pmichaud Jan, Apr, Jul, Oct -- same as the parrot supported releases 18:04
[Coke] pmichaud: yes. also +1 on moving to a 3 month schedule for *. 18:08
pmichaud: you might want to lag those a month to kick the tires?
no strong feelings on that, though. 18:09
PerlJam What Coke said (both things) 18:10
masak has that kind of tire-kicking been needed in the past? 18:14
PerlJam I can remember a few times when there has been parrot damage to rakudo that required some hasty tire-kicking. 18:15
Giving a month lag might allow for a more reasoned appraoch. 18:16
masak I thought that was what the two-day lag between Parrot and Rakudo (compiler) releases was for.
my question is really: has anything *more* than those two days ever been needed?
PerlJam I don't think so. 18:17
(thus the second part of Coke's comment: no strong feelings :) 18:18
[Coke] just figured it was a good question to raise. 18:19
PerlJam One could say that because this is for R*, that any parrot weirdness will have already been worked out in Rakudo, so why wait? 18:20
But then later on, if there is some problem the rather immediate looming deadline will be added pressure to "do something quick" rather than "do the right thing" (maybe) 18:21
A month long lag gives breathing room -- thinking time. 18:22
[Coke] eh. could always do a point release, just like parrot does when something explodes. forget I said anything. ;)
[particle] yes, sometimes more than two days was needed 18:29
and parrot has released bugfixes soon after releases (2.5.1?) for rakudo 18:30
moritz_ huh, is it #phasers time already? 18:31
PerlJam #phasers has been phasing in for a a while now
colomon it isn't time for another 27 minutes, but it's been very active anyway. 18:33
masak we just can't contain ourselves! 18:52
moritz_ my #phasers is NonContained 18:53
masak ah, the IRC dialect of Perl 6, where '#' is a sigil :) 18:54
diakopter ahhh... comments as variables
moritz_ anyway, #phasers prereport: 18:55
helped sECuRE debugging the IPv6 patch, and applied the corrected version 18:56
* implemented --ll-backtrace option that forces PIR level backtraces (good for debugging Null PMC accesses)
* now have a toddler at home, so time slots are unpredictable. Well worth it :-) 18:57
EOR
masak my prereport:
* did a bunch of pp6c blogging. stalled on two-pre-p4 posts due to $work being too interesting.
EOR 18:58
s/-/ /
colomon $work being too interesting is a very good problem to have.
Util my prereport: Parrot work only. EOR. 18:59
jnthn Clearly I should get a job where masak works.
diakopter heh
moritz_ :-)
colomon my on time report: Pretty much nothing done since last time, except for try to better understand masak's p2. EOR. 19:00
masak o/
moritz_ \\o 19:01
jnthn o/
colomon o/
Util o/
PerlJam my report: kibitzing on #parrot and #perl6. nothing much else Perl 6 related
:-)
jnthn my report... 19:02
Worked on nqp-rx/nom this week...
* Did initial refactors for natively typed attributes in P6opaque
* Also got down to 2 allocations per object, not 4 like Parrot Objects
* Got grammars switched over to use 6model. Took a while - was tricky.
* Added an optimization to only add return exception handler when return is used
* Made attribute get/set by name a bunch more efficient
* Located and fixed a silly bug in the method cache builder
Over the next week will...
* Purge the old Cursor code left over from the grammars migration
* Get natively typed attributes working
* Switched object body allocation to use fixed size allocator; slight performance win
* Add a simple roles implementation to nqp-rx/nom
* If I get time, support for mix-ins
Blockers
* Branes, time, beer.
EOR
diakopter branes are affected by 1/time/beer 19:03
moritz_ jnthn also blug
jnthn oh, yes. :) 19:05
I tyr to do that at least once a week. :)
*try
moritz_ anybody else wants to report? 19:06
anyway, I've read yesterday's discussion about nqp plans 19:08
I liked it 19:09
jnthn :)
jnthn is looking forward to pmichaud++'s roadmap/blog posts. :)
And lots of hacking. :)
moritz_ (short summary: nqp will give up the no-runtime-required paradigm, and will act as the primary abstraction layer for VMs for rakudo) 19:10
and probably a name change, or maybe not :-)
jnthn That's a decent way to sum it up, though of course all HLLs built with nqp also get the benefits. :) 19:12
moritz_ sure 19:14
PerlJam what will nqp's runtime look like? 19:16
(the required one)
or will it be more like a role where certain routines are required of whatever runtime you happen to use with nqp? 19:17
jnthn PerlJam: Exactly what each VM needs to allow it to do the needed stuff will vary. 19:18
PerlJam: Generally, it'll incorporate the 6model core, a basic implementation of classes and roles built on that, plus multi-dispatch support. Then I guess some built-in types.
pmichaud we'll likely come up with a standard API for nqp
standard built-in types and methods 19:19
nqp's claim will be that it's a very minimal Perl 6
jnthn I suspect it'll be a process of negotiation between what nqpclr/nqpjvm offer and what nqp-rx provides today.
PerlJam it keeps moving closer and closer to Perl 6 over time :)
pmichaud PerlJam: yes, I know; I can even conceive it might disappear entirely
jnthn thinks it's important to factor in optimizability when deciding what goes into NQP or doesn't 19:20
PerlJam jnthn: It's really odd, but your description of the runtime sounds just like SMOP 19:22
jnthn PerlJam: Doesn't sound odd to me. :) 19:23
PerlJam It's just convergent evolution, eh? 19:24
jnthn PerlJam: SMOP was one of many influences on 6model.
Standing on the shoulders of giants and all that. :) 19:25
19:27 mberends joined
moritz_ smop just never had a regex engine 19:29
PerlJam right. 19:31
That's why NQP and SMOP alwasy occupied separate universes to me.
19:31 tylercurtis joined
PerlJam (until now I guess ;) 19:31
jnthn pmichaud: Do you have any thoughts on how we can make iterators cheaper in Rakudo? 19:38
masak jnthn: by switching back to a more problematic iterator model? :P 19:46
jnthn masak: IMHO, the *model* we have now is great. 19:47
I suspect we just need to find ways to cheat at times. :) 19:48
PerlJam jnthn: Why do iterators need to be cheaper exactly? And are these iterators going to be reused often? 19:49
masak PerlJam: "fun" comparison in Rakudo: a for loop against an identical while loop. try it, and you won't be asking. :P 19:50
jnthn PerlJam: What masak said. Also, compare for 1..10000 { } vs my $a; for 1..10000 { $a += $_ } 19:52
colomon jnthn: what's the point of that last comparison? 19:53
jnthn colomon: That the cost of the iteration dominates the cost of what is done inside the loop body if what's done is relatively small. 19:54
colomon jnthn: I don't actually get that result with this example.
jnthn Oh?
colomon I got 2s for the first, 3.4s for the second 19:55
1.5s for a while loop
pmichaud the real way to see the cost is to compare a while versus a for
because the while doesn't use iterators
jnthn Oh, sorry, that wasn't the benchmark.pl case I thought it was...
pmichaud: Yes, true.
pmichaud the cost of iterators at the moment is in the allocating of the iterator objects 19:56
that can absolutely be optimized a lot
colomon I get 1.5s for my $i = 0; while ($i < 10000) { $i++ }
and 2.1s for for 1..10000 { }
pmichaud but I don't want to optimize until the spec is a lot better fleshed out
jnthn colomon: Startup time subtracted?
colomon nope
so make it .9s versus 1.5s 19:57
maybe should bump it to 100000 to get a cleaner comparison
pmichaud at some point what you end up measuring is the cost of GC, too.
jnthn pmichaud: (cost is in allocating iterator objects) you mean a reduction by allocating less of them, or one from making the allocation cheaper? 19:58
pmichaud allocating less
jnthn OK, that's the answer I was hoping for. :)
(Not that the cost of allocating one *won't* get cheaper - it should.)
pmichaud right now rakudo's implementation is (by necessity) a "get something working quickly" implementation, out of necessity of the time constraints we were under when it was implemented 19:59
even so, there are a lot of corner cases that haven't been well fleshed out
and the API is still squishy
jnthn *nod* 20:00
colomon with 100,000 iterations, it's 9.5s for while and 16.7s for for. Clear advantage to while, but it's not a crazy advantage.
pmichaud so, given that we're only 2x slower than an equivalent while at the moment, I'm in favor of solidying the spec (with an eye towards optimizability) rather than figuring out how to optimize what we already have.
*solidifying 20:01
jnthn OK. 20:02
jnthn somehow had the difference down as more extreme than that.
pmichaud if only someone had a grant to work on such thi.... oh, wait, that's me.
jnthn :)
pmichaud given other things going on I'm not likely to get on it this week (other tasks more important), but I'll bump it up a bit in my priority setting 20:03
as far as nqp goes, I'd say we don't want a lazy list model behind its for loops 20:04
that resolves a lot of difficulty, I think.
moritz_ agreed
jnthn +1
Exactly how that model does look is still up for grabs though, I guess. 20:05
pmichaud I'd lean towards something more traditional -- a lightweight iterator
jnthn (We could say "how it works on Parrot" though, and I got put something like that into nqpclr etc)
*can
pmichaud just something that indexes through an array or hash
jnthn *nod*
pmichaud I wouldn't make arrays or lists lazy in nqp either 20:06
keep em eager and efficient (fsvo "efficient")
jnthn No, I wasn't planning on that :)
wasn't planning on lazy, that is. Was planning on efficient. :P
PerlJam sounds like the usual time/space trade-off to me
moritz_ right, I'd expect arrays in nqp to be more RPA like than p6-array like
pmichaud well, there are different definitions of "efficient", some of which apply better to lazy lists
jnthn
.oO( I don't know where in the iteration I am, but I know how fast I'm iterating...oh wait, that's the other trade-off principle... )
 20:07
Anyway, I think this unblocks me a bit 20:08
I'll tidy up array iteration in nqpclr/nqpjvm some and make hash iteration work.
pmichaud afk, errands 20:09
jnthn senses the meeting phasing out 20:16
20:44 masak left 22:07 tylercurtis left 22:25 mberends left 23:25 dukeleto left, dukeleto joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!