weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 19 October 2010.
00:55 ash_ joined 03:14 eternaleye_ left, eternaleye_ joined, eternaleye left, eternaleye joined 03:21 eternaleye_ left 05:43 _ilbot2 joined
moderator weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
06:21 colomon left 07:21 colomon joined
sorear there's a chance I'll miss #phasers tomorrow: 09:56
DID:
* Resolved a tuit supply crisis
* Very little coding (see above)
* New list design is pretty much solid 09:57
* Discussed with cotto++ in #parrot about the nature of Lorito
* Decided that the backend of Niecza is a Lorito prototype in all but name and a few minor details 09:58
PLANS:
* Complete list/iterator refactor
* New design for contextualizers
* Try to get a couple more features in tryfile.exe working 09:59
* Retool the Niecza backend into a true Lorito prototype and present it to #parrot
* "Look here, a Lorito prototype that already runs a real-ish compiler!"
* Work on the documentation and do a proper p6l announcement with any tuits left over ;) 10:00
BLOCKERS:
* None known.
EOR
14:13 ash_ left 16:36 sorear left, sorear joined
Util Will miss #phasers, or at least be late. 18:52
Done: rosettacode.org/wiki/Simple_Quatern...ons#Perl_6
EOR
colomon Util: ooooo, I think we need to work with that code! exciting stuff... 18:56
Util++ 18:58
pmichaud Here for phasers (for 30 mins) 19:00
sorear hi
pmichaud Still trying to work out scheduling issues locally and with $otherjob :-(
jnthn here
o/ pmichaud
pmichaud and lost most of the day yesterday dealing with internet service changes
colomon \\o
pmichaud I guess I can report that the 2010.10 R* release went out last week. And the FLOSS Weekly interview was posted. 19:01
colomon pmichaud++
jnthn pmichaud: The interview sounded good. 19:02
(listened to it on Friday while hacking)
pmichaud good, I'm glad the interview came across okay. I was definitely not feeling well at the time of the interview. :-/ 19:04
colomon I wouldn't have guessed from listening.
jnthn No, that didn't come accross. The answers were familiar in one sense, but well delivered. 19:05
pmichaud good :-)
jnthn If anyone else wants to report, go ahead - I'm still scribbling mine. :-)
colomon Talked to Damian++ about getting his modules into the module system. 19:07
He will ship them over once he is happy with them, no idea how long that will be.
Did a bunch of work on the ABC module, whined until pmichaud++ fixed the not predeclared variable error message. 19:08
.EOR
jnthn has a report ready :) 19:11
Last 2 weeks (missed phasers last week)
* Loads of work on the .Net implementation of NQP and 6model
* Perhaps most critical is that I got an implementation of the latest multi-dispatch spec together
* Very happy with how well the implementation came together
* Multi-methods are in too; was also very neat
* Expect I can share a lot of the multi-methods code and the actions changes with nqp-rx on Parrot, just needs a few ops...oh, and the dispatcher writing. :-)
* Also have classes written (NQPClassHOW written in NQP) with methods, attributes, single inheritance
* &foo.leave works, does stack unwinding, leaves with a value.
* Did much exception infrastructure, including prep for resumable ones. Continuationless. Does lexical throw too. Like it. Want it on Parrot.
* Got return exceptions in place; they use .leave to unwind the stack 19:12
* Also, seem to have working closures, .defined, and other bits
* Wrote a Low Hanging Fruit task list, and diakopter++ eated most of it :-)
This week
* $dayjob will be quite busy, but hope to find some tuits
* Want to nudge NQP on .Net along a bit further. Will just follow the ROADMAP, I expect.
* Try and write documentation, more LHF tasks
Blockers
* Need to get the PCT::HLLCompiler blocker dealt with to make progress on Parrot
* The .Net runtime is far too -Ofun that getting energy to go port stuff to nqp-rx on Parrot is hard. :/
.EOR
pmichaud I'll work on clearing the PCT::HLLCompiler blocker... but given my track record, if someone else wants to jump on it, I won't be perturbed by that. 19:14
jnthn pmichaud: OK. 19:15
pmichaud: Any thoughts on the for loop thingy I asked yesterday?
colomon can you guys quickly describe the blocking issue?
pmichaud I think jnthn++ just needs a version of PCT::HLLCompiler that is written (mostly?) in NQP instead of PIR 19:16
jnthn pmichaud: Well, and that is in nqp-rx.
pmichaud: Since it needs to use the new meta-model.
pmichaud right
colomon thanks.
jnthn pmichaud: Alternatively, the most urgent methods could be ported from PCT::HLLCompiler and put into HLL::Compiler.
e.g. the ones taht actually block stuff.
pmichaud right, that's what I'd prefer to have happen
jnthn I dunno how much of it that is.
(Don't know if you have a feel for how much that is, off hand?) 19:17
pmichaud it's always been my intent that HLL::Compiler would be a complete replacement for PCT::HLLCompiler -- just haven't gotten to it yet
jnthn OK.
pmichaud there's a lot of "extra junk" that is in PCT::HLLCompiler that I think ought to go away for something more elegant
it got a lot of creeping featurism
anyway, ultimately I expect PCT::HLLCompiler to go the way of PGE -- i.e., it gets supplanted by something that is primarily nqp-based 19:18
and people start using HLL::Compiler instead
(as most things already do)
jnthn OK, sounds good. 19:19
colomon jnthn: could you maybe make a list of the blocking methods?
19:19 takadonet joined
jnthn colomon: To the degree I can work that out just by looking at it, yes. :-) 19:19
colomon :) 19:20
jnthn pmichaud: My other question was about PAST nodes.
19:20 masak joined
jnthn pmichaud: It'd be kinda nice to have those done in NQP. 19:20
pmichaud: At the moment, it seems they are all captures underneath.
masak is late, but has nothing to report
jnthn pmichaud: Is there a deep reason for this approach vs having attributes? 19:21
pmichaud the primary reason is that it makes it easy for others to hang custom attributes on them without having to declare new classes
jnthn pmichaud: The $foo<bar> syntax?
pmichaud yes
which we take *huge* advantage of in rakudo
s/advantage of/liberties with/ 19:22
jnthn pmichaud: Yes, I'd thought about that. I pondered that we could lazily allocate a hash attribute in PAST::Node for those.
pmichaud I also feel that it makes more sense for past nodes to act like match objects
since we'll want to be doing very similar sorts of tree-matching things, eventually.
jnthn pmichaud: Right, but I fear that having all the attributes for every single node be in a hash table means we get huge duplication on the keys.
e.g. storage for 'em 19:23
Whereas a plain old object could be much lighter weight.
pmichaud at this point I'd strongly prefer to stay closer to the match object model than anything else
jnthn OK, I was strongly wanting to move away from it for performance/memory use reasons.
pmichaud or, to put it another way, if the hash table approach is a problem for past nodes, it's a problem for match objects also and we should fix the two simultaneously
I haven't found past nodes to be a significant source of performance pain, in my limited benchmarks 19:24
Tene jnthn: you could create attributes for common items, and override get_*_keyed_str to use attributes if it's in a given list, and forward to a lazily-allocated hash for anything else
if you really wanted to go that way
Then you keep the match interface, and you can be lighter-weight for the common case. 19:25
jnthn pmichaud: Yes, but attribute lookups and storage in Parrot today aren't particularly optimal vs what things should be in the new meta-model.
pmichaud at this stage I'd really prefer simplicity, elegance, and consistency
otherwise it feels like a premature optimization to me
jnthn Tene: Oh, I'm not proposing a change of interface for PAST nodes. Just a change of underlying implementation.
pmichaud: I'm not sure I buy the analogy with Match objects. For those we could have any arbitrary set of keys and creating a backing class of some kind for all of them would be a lot of work/overhead. For PAST nodes we have roughly 10 distinct node types. 19:26
pmichaud at this point I have a pretty strong hunch that turning past nodes into attributed objects is going to end up being a source of pain and/or a false optimization
I admit I could be wrong about that -- but that's my strong leaning
anyway, the point of the api is that we can ultimately make that change... I'm just thinking we shouldn't make it just yet. 19:27
jnthn OK, I can live with that design call, but I think it's the wrong one. 19:28
pmichaud noted
I'll consider the other side as well. I just haven't seen a huge performance issue in processing PAST nodes yet. 19:29
so efficiency/optimalness doesn't rank high for me on that one just yet.
jnthn OK. My hunch is it's part of the reason (though certainly not all of the reason) that core.pm compilation is so memory hungry. 19:30
But I've got no numbers to back that. 19:31
As you say though, it's an API, and the underneath is changeable.
pmichaud I think that core.pm is memory hungry due to the parse, not due to the past. Although there's obviously a correlation between the two. 19:33
jnthn It's a hard one to call. Sometimes many parse nodes lead to one past node. Some times one parse node leads to many past nodes. 19:36
jnthn wonders if anyone else has a report - I wanted to get my questions in before pmichaud++ had to leave. :-) 19:38
masak I've a tiny report, but it's business as usual, really: submitted 5 reakudobugs this week, and did a monthly release of Yapsi. Tardis is back on-line. November blogging commenced. eor 19:49
jnthn: when do you think 6model might start to trickle back into Rakudo? (and how bad do you think it'll shake the perl 6 applications?) 19:50
jnthn masak: There's a couple of choices there. In one approach, I get the new meta-model and multi-dispatch working in nqp-rx, then as soon as I'm happy with that, set about getting Rakudo running on top of the new NQP, and then do the whole serialization context stuff in a second phase. Alternatively, I can do both steps at once. The first sees the model land in Rakudo earlier. However, a bunch of the optimizations want the serialization context stuff doing. 19:54
masak given either alternative, what's an approximate date? are we talking December, or more like April? 19:55
jnthn Applications wise, I expect (compared to ng) relatively minor fallout.
masak \\o/
if there is little fallout, I look forward to the one we do get.
jnthn Applications that play with meta-objects may have a few things to do.
masak not many of those yet, AFAIK. 19:56
jnthn But in many senses, I'm replacing a load of stuff behind an API.
So even in that case, it'll not be so traumatic.
I think the main issue will be the odd weird little issue here and there, not big regressions. 19:57
Oh, though...I expect the multi-dispatch changes to also land in with this.
masak just as well.
jnthn That could well cause more upheavel than the objct changes in general. 19:58
Because it's going to bring some notable semantic changes.
masak I'm actually not using multi-dispatch a great deal.
oh well. tests to the rescue :)
jnthn Anywhere you rely on a proto to have today's semantics in Rakudo, you'll have a problem.
masak I don't rely on protos anywhere that I recall. 19:59
19:59 diakopter joined
jnthn Timing wise, I expect to land something in mainline Rakudo by early 2011. 20:00
masak so, by Q2 2011? 20:01
jnthn I expect to have to solve various issues along the way. e.g. the multi one that had to be dealt with recently.
I really want to have something land in Q1. So yes, by Q2.
masak nice. 20:02
jnthn I was initially leaning towards doing the new meta-model and the serialization context stuff all in one big jump.
masak do you have any indications yet that this might give us a generally faster Rakudo?
sorear I'm back
jnthn But now I'm thinking it might be better to do that it two stages.
sorear So I didn't *miss* #phasers....
jnthn masak: Nothing concrete to point at numbers wise, but even without the SC stuff - which will enable various optimizations - I think well have a win in various ways. 20:03
masak jnthn: ok. 20:04
jnthn masak: Int/Num/Rat should get a bunch cheaper and cause less GC pressure, for example, due to allocating less objects.
masak that sounds great. also, it sounds architecturally sane.
jnthn We also lose having the current situation where we have a Perl 6 layer atop of Parrot's object model. 20:05
Instead we'll just be working directly with something built with Perl 6 in mind.
masak ossum.
sorear Anyways, I have my tuit supply back 20:06
So Niecza will see a lot of fun stuff next two weeks
masak you mean so far you've been going *slow*? :)
sorear FSVO so far 20:07
count the number of commits made by me since last #phasers
masak oh; haven't been paying much attention to Niecza since last week.
sorear: by the way, jnthn has seen the band live, and he found out that they're not singing "we don't have time" but "we have time": "my mĆ”me čas". so the name "niecza" is founded on extremely shaky ground. :/ 20:09
still a cute name though.
but if you'd feel the need to rename it due to these new findings -- which I doubt you do -- "mycah" was the closest one I got. 20:10
jnthn apologises for not czeching the lyrics more carefully 20:11
sorear it is a pronouncable 6 letter string with no prior google hits
although, I did double-take when I saw a political candidate named Nicieza
masak :D
Tene Until earlier this week, I had been reading it as "Niezca". When I noticed someone saying "Niecza" in the channel, I was convinced they had made a typo until I checked for myself. 20:12
sorear cz. like czech. 20:15
diakopter I heard 'nee-ezz-kuh' in my brain 20:16
I mean
'nee-ehk-zuh'
masak has it as "nee-etch-kah"
er. "nee-etch-ah" 20:17
sorear one of these days I need to learn IPA so I can properly compare notes.
the only phonetic system I know currently is the kana :)
in which, I currently say niekka 20:18
masak sorear: does the README contain any suggestions for pronunciation? 20:19
sorear or sometimes nieccha / niettya
no
masak that last one looks like it could be same as mine. 20:20
jnthn masak: I has it the same as you, fwiw.
well
nee-yetch-ah
masak close enough.
jnthn
.oO( Š½ŠµŃ‡Š° )
 20:21
masak whoa! yes! 20:22
why didn't I think of using the phonetic spelling? :P
sorear I'll take your word for it; my Slavic is limited to "da" and "nyet"
jnthn sorear: oh, good start! The next two you need are "ŠæŠøŠ²Š¾" and "Š¢Ń‹ ŠŗрŠ°ŃŃ‹Š²Š°Ń!" 20:24
sorear jnthn: Cyrillic is a priority. 20:25
masak sorear: you'll note though, from the above, 'n' is Š½, 'ie' becomes just Šµ, and 'cz' becomes ч.
jnthn gah! "ŠŗрŠ°ŃŠøŠ²Š°Ń"
jnthn can't spell...
masak I'm sure she'd have understood... 20:26
jnthn masak: Oh, I'm quite well practiced on how to pronounce it. :P
moritz_ oh hai 21:03
masak \\o
moritz_ I notice I missed most of #phasers
diakopter something about time changes
moritz_ but I wanted to propose to give Nick Wellenhofer a commit bit
diakopter: no, guests
masak what's the nick of Nick?
moritz_ nwellnhof 21:04
in #parrot
masak oh, ok. +1
moritz_ he committed several good patches, often related to parrot changes
masak do people still have to sign a form before getting a commit bit?
moritz_ yes
masak oh wait; he's already with Parrot. 21:05
so that's not an issue.
jnthn Maybe - wasn't the Parrot one signed with PaFo, not TPF? 21:16
moritz_ jnthn is right 21:21
masak what's the preferred order between giving someone a commit bit and that someone having signed the TPF thingie? 21:22
moritz_ 1) agreement from rakudo devs 21:23
2) CLA
3) commit bit
colomon I seem to recall that I told them I was sending in the TPF thingee, and they gave me a commit bit at that point, probably about a week before the TPF actually got it. (It bounced the first time because of a bad address.)
moritz_ yes, there's some wriggle room possible 21:24
so, any more opinions, beside mine and masak's? 21:25
colomon I don't see any reason why not. Dunno much about him, 'cept his last patch was over my head. :) 21:26
jnthn moritz_: No objections if the patches so far have been good.
moritz_ all applied, non reverted later on 21:27
22:32 masak left 22:38 diakopter left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!