Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-11-02

| Channels | #phasers index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:55 ash_ joined #phasers
03:14 eternaleye_ left #phasers
03:14 eternaleye_ joined #phasers
03:14 eternaleye left #phasers
03:14 eternaleye joined #phasers
03:21 eternaleye_ left #phasers
05:43 _ilbot2 joined #phasers
05:43 Topic for #phasers is now weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at http://irclog.perlgeek.de/phasers/today
06:21 colomon left #phasers
07:21 colomon joined #phasers
09:56 sorear there's a chance I'll miss #phasers tomorrow:
09:56 sorear DID:
09:56 sorear * Resolved a tuit supply crisis
09:56 sorear * Very little coding (see above)
09:57 sorear * New list design is pretty much solid
09:57 sorear * Discussed with cotto++ in #parrot about the nature of Lorito
09:58 sorear * Decided that the backend of Niecza is a Lorito prototype in all but name and a few minor details
09:58 sorear PLANS:
09:58 sorear * Complete list/iterator refactor
09:58 sorear * New design for contextualizers
09:59 sorear * Try to get a couple more features in tryfile.exe working
09:59 sorear * Retool the Niecza backend into a true Lorito prototype and present it to #parrot
09:59 sorear * "Look here, a Lorito prototype that already runs a real-ish compiler!"
10:00 sorear * Work on the documentation and do a proper p6l announcement with any tuits left over ;)
10:00 sorear BLOCKERS:
10:00 sorear * None known.
10:00 sorear EOR
14:13 ash_ left #phasers
16:36 sorear left #phasers
16:36 sorear joined #phasers
18:52 Util Will miss #phasers, or at least be late.
18:52 Util Done: http://rosettacode.org/wiki/Simple_Quaternion_type_and_operations#Perl_6
18:52 Util EOR
18:56 colomon Util: ooooo, I think we need to work with that code!  exciting stuff...
18:58 colomon Util++
19:00 pmichaud Here for phasers (for 30 mins)
19:00 sorear hi
19:00 pmichaud Still trying to work out scheduling issues locally and with $otherjob :-(
19:00 * jnthn here
19:00 jnthn o/ pmichaud
19:00 pmichaud and lost most of the day yesterday dealing with internet service changes
19:00 colomon \o
19:01 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++
19:02 jnthn pmichaud: The interview sounded good.
19:02 jnthn (listened to it on Friday while hacking)
19:04 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.
19:05 jnthn No, that didn't come accross. The answers were familiar in one sense, but well delivered.
19:05 pmichaud good :-)
19:05 jnthn If anyone else wants to report, go ahead - I'm still scribbling mine. :-)
19:07 colomon Talked to Damian++ about getting his modules into the module system.
19:07 colomon He will ship them over once he is happy with them, no idea how long that will be.
19:08 colomon Did a bunch of work on the ABC module, whined until pmichaud++ fixed the not predeclared variable error message.
19:08 colomon .EOR
19:11 * jnthn has a report ready :)
19:11 jnthn Last 2 weeks (missed phasers last week)
19:11 jnthn * Loads of work on the .Net implementation of NQP and 6model
19:11 jnthn * Perhaps most critical is that I got an implementation of the latest multi-dispatch spec together
19:11 jnthn * Very happy with how well the implementation came together
19:11 jnthn * Multi-methods are in too; was also very neat
19:11 jnthn * 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. :-)
19:11 jnthn * Also have classes written (NQPClassHOW written in NQP) with methods, attributes, single inheritance
19:11 jnthn * &foo.leave works, does stack unwinding, leaves with a value.
19:11 jnthn * Did much exception infrastructure, including prep for resumable ones. Continuationless. Does lexical throw too. Like it. Want it on Parrot.
19:12 jnthn * Got return exceptions in place; they use .leave to unwind the stack
19:12 jnthn * Also, seem to have working closures, .defined, and other bits
19:12 jnthn * Wrote a Low Hanging Fruit task list, and diakopter++ eated most of it :-)
19:12 jnthn This week
19:12 jnthn * $dayjob will be quite busy, but hope to find some tuits
19:12 jnthn * Want to nudge NQP on .Net along a bit further. Will just follow the ROADMAP, I expect.
19:12 jnthn * Try and write documentation, more LHF tasks
19:12 jnthn Blockers
19:12 jnthn * Need to get the PCT::HLLCompiler blocker dealt with to make progress on Parrot
19:12 jnthn * The .Net runtime is far too -Ofun that getting energy to go port stuff to nqp-rx on Parrot is hard. :/
19:12 jnthn .EOR
19:14 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:15 jnthn pmichaud: OK.
19:15 jnthn pmichaud: Any thoughts on the for loop thingy I asked yesterday?
19:15 colomon can you guys quickly describe the blocking issue?
19:16 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.
19:16 jnthn pmichaud: Since it needs to use the new meta-model.
19:16 pmichaud right
19:16 colomon thanks.
19:16 jnthn pmichaud: Alternatively, the most urgent methods could be ported from PCT::HLLCompiler and put into HLL::Compiler.
19:16 jnthn e.g. the ones taht actually block stuff.
19:16 pmichaud right, that's what I'd prefer to have happen
19:16 jnthn I dunno how much of it that is.
19:17 jnthn (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
19:17 jnthn OK.
19:17 pmichaud there's a lot of "extra junk" that is in PCT::HLLCompiler that I think ought to go away for something more elegant
19:17 pmichaud it got a lot of creeping featurism
19:18 pmichaud 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 pmichaud and people start using HLL::Compiler instead
19:18 pmichaud (as most things already do)
19:19 jnthn OK, sounds good.
19:19 colomon jnthn: could you maybe make a list of the blocking methods?
19:19 takadonet joined #phasers
19:19 jnthn colomon: To the degree I can work that out just by looking at it, yes. :-)
19:20 colomon :)
19:20 jnthn pmichaud: My other question was about PAST nodes.
19:20 masak joined #phasers
19:20 jnthn pmichaud: It'd be kinda nice to have those done in NQP.
19:20 jnthn pmichaud: At the moment, it seems they are all captures underneath.
19:20 * masak is late, but has nothing to report
19:21 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
19:21 jnthn pmichaud: The $foo<bar> syntax?
19:21 pmichaud yes
19:21 pmichaud which we take *huge* advantage of in rakudo
19:22 pmichaud 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.
19:22 pmichaud I also feel that it makes more sense for past nodes to act like match objects
19:22 pmichaud since we'll want to be doing very similar sorts of tree-matching things, eventually.
19:22 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.
19:23 jnthn e.g. storage for 'em
19:23 jnthn Whereas a plain old object could be much lighter weight.
19:23 pmichaud at this point I'd strongly prefer to stay closer to the match object model than anything else
19:23 jnthn OK, I was strongly wanting to move away from it for performance/memory use reasons.
19:23 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
19:24 pmichaud 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
19:24 Tene if you really wanted to go that way
19:25 Tene 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.
19:25 pmichaud at this stage I'd really prefer simplicity, elegance, and consistency
19:25 pmichaud otherwise it feels like a premature optimization to me
19:25 jnthn Tene: Oh, I'm not proposing a change of interface for PAST nodes. Just a change of underlying implementation.
19:26 jnthn 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
19:26 pmichaud I admit I could be wrong about that -- but that's my strong leaning
19:27 pmichaud 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:28 jnthn OK, I can live with that design call, but I think it's the wrong one.
19:28 pmichaud noted
19:29 pmichaud I'll consider the other side as well.  I just haven't seen a huge performance issue in processing PAST nodes yet.
19:29 pmichaud so efficiency/optimalness doesn't rank high for me on that one just yet.
19:30 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:31 jnthn But I've got no numbers to back that.
19:31 jnthn As you say though, it's an API, and the underneath is changeable.
19:33 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:36 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:38 * jnthn wonders if anyone else has a report - I wanted to get my questions in before pmichaud++ had to leave. :-)
19:49 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:50 masak 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:54 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:55 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.
19:55 masak \o/
19:55 masak if there is little fallout, I look forward to the one we do get.
19:55 jnthn Applications that play with meta-objects may have a few things to do.
19:56 masak not many of those yet, AFAIK.
19:56 jnthn But in many senses, I'm replacing a load of stuff behind an API.
19:56 jnthn So even in that case, it'll not be so traumatic.
19:57 jnthn I think the main issue will be the odd weird little issue here and there, not big regressions.
19:57 jnthn Oh, though...I expect the multi-dispatch changes to also land in with this.
19:57 masak just as well.
19:58 jnthn That could well cause more upheavel than the objct changes in general.
19:58 jnthn Because it's going to bring some notable semantic changes.
19:58 masak I'm actually not using multi-dispatch a great deal.
19:58 masak oh well. tests to the rescue :)
19:58 jnthn Anywhere you rely on a proto to have today's semantics in Rakudo, you'll have a problem.
19:59 masak I don't rely on protos anywhere that I recall.
19:59 diakopter joined #phasers
20:00 jnthn Timing wise, I expect to land something in mainline Rakudo by early 2011.
20:01 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.
20:01 jnthn I really want to have something land in Q1. So yes, by Q2.
20:02 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.
20:02 masak do you have any indications yet that this might give us a generally faster Rakudo?
20:02 sorear I'm back
20:02 jnthn But now I'm thinking it might be better to do that it two stages.
20:02 sorear So I didn't *miss* #phasers....
20:03 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:04 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.
20:04 masak that sounds great. also, it sounds architecturally sane.
20:05 jnthn We also lose having the current situation where we have a Perl 6 layer atop of Parrot's object model.
20:05 jnthn Instead we'll just be working directly with something built with Perl 6 in mind.
20:05 masak ossum.
20:06 sorear Anyways, I have my tuit supply back
20:06 sorear So Niecza will see a lot of fun stuff next two weeks
20:06 masak you mean so far you've been going *slow*? :)
20:07 sorear FSVO so far
20:07 sorear count the number of commits made by me since last #phasers
20:07 masak oh; haven't been paying much attention to Niecza since last week.
20:09 masak 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 masak still a cute name though.
20:10 masak 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:11 * jnthn apologises for not czeching the lyrics more carefully
20:11 sorear it is a pronouncable 6 letter string with no prior google hits
20:11 sorear although, I did double-take when I saw a political candidate named Nicieza
20:11 masak :D
20:12 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:15 sorear cz.  like czech.
20:16 diakopter I heard 'nee-ezz-kuh' in my brain
20:16 diakopter I mean
20:16 diakopter 'nee-ehk-zuh'
20:16 * masak has it as "nee-etch-kah"
20:17 masak er. "nee-etch-ah"
20:17 sorear one of these days I need to learn IPA so I can properly compare notes.
20:17 sorear the only phonetic system I know currently is the kana :)
20:18 sorear in which, I currently say niekka
20:19 masak sorear: does the README contain any suggestions for pronunciation?
20:19 sorear or sometimes nieccha / niettya
20:19 sorear no
20:20 masak that last one looks like it could be same as mine.
20:20 jnthn masak: I has it the same as you, fwiw.
20:20 jnthn well
20:20 jnthn nee-yetch-ah
20:20 masak close enough.
20:21 jnthn .oO( неча )
20:22 masak whoa! yes!
20:22 masak why didn't I think of using the phonetic spelling? :P
20:22 sorear I'll take your word for it; my Slavic is limited to "da" and "nyet"
20:24 jnthn sorear: oh, good start! The next two you need are "пиво" and "Ты красывая!"
20:25 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 ч.
20:25 jnthn gah! "красивая"
20:25 * jnthn can't spell...
20:26 masak I'm sure she'd have understood...
20:26 jnthn masak: Oh, I'm quite well practiced on how to pronounce it. :P
21:03 moritz_ oh hai
21:03 masak \o
21:03 moritz_ I notice I missed most of #phasers
21:03 diakopter something about time changes
21:03 moritz_ but I wanted to propose to give Nick Wellenhofer a commit bit
21:03 moritz_ diakopter: no, guests
21:03 masak what's the nick of Nick?
21:04 moritz_ nwellnhof
21:04 moritz_ in #parrot
21:04 masak oh, ok. +1
21:04 moritz_ he committed several good patches, often related to parrot changes
21:04 masak do people still have to sign a form before getting a commit bit?
21:04 moritz_ yes
21:05 masak oh wait; he's already with Parrot.
21:05 masak so that's not an issue.
21:16 jnthn Maybe - wasn't the Parrot one signed with PaFo, not TPF?
21:21 moritz_ jnthn is right
21:22 masak what's the preferred order between giving someone a commit bit and that someone having signed the TPF thingie?
21:23 moritz_ 1) agreement from rakudo devs
21:23 moritz_ 2) CLA
21:23 moritz_ 3) commit bit
21:23 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.)
21:24 moritz_ yes, there's some wriggle room possible
21:25 moritz_ so, any more opinions, beside mine and masak's?
21:26 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.
21:27 moritz_ all applied, non reverted later on
22:32 masak left #phasers
22:38 diakopter left #phasers

| Channels | #phasers index | Today | | Search | Google Search | Plain-Text | summary