weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 3 September 2010.
03:10 tylercurtis joined 03:28 [Coke] left 08:13 tylercurtis left 13:17 masak joined
dukeleto What I did: reported some rakudo bugs (NaN.Rat and coredumping spectests due to parrot bugs). Hacked on PL/Parrot and PL/Perl6. Pre-pasting in case I am busy (at jury duty) 16:24
18:32 colomon joined 18:59 mberends joined
masak o/ 19:01
mberends \\o/
colomon o/
pmichaud good afternoon, #phasers 19:02
masak phases 19:03
mberends good pm, pm
PerlJam greetings.
PerlJam lucks into being on IRC at the right time for once
mberends report: I made lots of progress on the java/runtime part of 6model. At the end of this, I might even like Java :) 19:05
.eor
pmichaud mberends: .... because you won't have to program in it? ;-) 19:06
mberends heh
masak report: since last time, I've been fiddling a bit with Set. been wanting to apply the enums patch for a long time now, but haven't gotten around to it. maybe tonight is the night. .eor
colomon report: few very minor tweaks to Rakudo. Tweaks to List::Utils and added binary search to it (from the old Vector module). Now working on trying to make ABC.pm do something useful. .eor 19:08
dukeleto hola 19:09
19:10 Tene joined, whiteknight joined 19:11 PacoLinux joined
pmichaud my report: 19:12
Rakudo:
* Fixed infix:<:=> to use list_assignment precedence
* Fixed Buf.decode to work with recent Parrot
* Rewrote List.reverse to be much more efficient
* Cleaned up some vtables and other dead code
* Eliminated .succ and .pred from Cool
* Spent a lot of time tracking down and fixing Rakudo build failures with recent Parrots
NQP:
* Created json.nqp, a JSON compiler written entirely in NQP
* Added trait parsing and handling to subs/methods
* Added ability to add :main and :vtable flags to NQP-defined subs
* Refactored code to avoid deprecated CodeString PMC
* Added :sub<...> precedence to operator precedence parser (to support switching infix:<:=> to list_assignment in Rakudo)
Other:
* Trying to prod Parrot team to focus on GC, profiling
Planned:
* Rakudo: Fix Stringy definition
* Rakudo: Fix Hash to no longer be a role
* Rakudo: more core code review, refactoring, and optimization
* book: Try to get book to a publishable state
* nqp: Write up json compiler example as a tutorial
* nqp: Start creating nqp::* pseudo-functions to replace pir::* . 19:13
EOR
masak pmichaud++
moritz_ resurfaces
pmichaud++
colomon pmichaud: one thing that has me mildly worried -- it seems like a lot of our optimization efforts at the moment involve translating things to PIR. While I'm all in favor of the optimization, it seems like we are making matters harder for anyone who comes along later with a different core. 19:14
moritz_ can't think of anything worthwhile to report
colomon it's like the optimizations are at war with the nqp::* replacing pir::* effort.
pmichaud colomon: I don't entirely agree with the characterization (more) 19:15
in the case of List.reverse, I rewrote it in PIR because there is not really an optimal p6 way of describing reverse 19:16
more to the point, List really wants to be as efficient as possible. So the other part of the refactoring was to move .reverse out of Any-list and into List, so that at least the PIR is in one place.
I suspect that when jnthn++'s new object implementation lands, we'll be able to eliminate a lot of pir:: and nqp:: because we'll have nice methods underneath our primitive objects. 19:17
anyway, optimization is not entirely "translate things to PIR", but rather "figure out which things are low-level and which ones are not" 19:18
PerlJam "figure out which things beed to be primitives in nqp::" ? 19:19
s/beed/need/
dukeleto wonders if #phasers has some kind of protocol or if it is the usual strangely consistent chaos 19:20
pmichaud PerlJam: hopefully, yes.
dukeleto: chaos.
dukeleto pmichaud: awesome!
masak anarchy++
PerlJam entropy++ :-)
pmichaud any other reports coming?
masak I'm getting lots of spectest failures. I compared with moritz_ and he's getting a clean spectest run. 19:21
I don't know why that is.
moritz_ not anymore
masak ok.
anyway, there's quite a lot.
I have a gist somewhere.
moritz_ seems like recent parrot changes really broken some stuff in rakudo
masak oh, good.
then that's it.
guess I had a forwards Parrot, then.
pmichaud I tried rakudo with Parrot last night and had only one spectest failure (known)
dukeleto I would just like to say that Parrot devs very much care about Rakudo's needs, and I plan to improve the communication between parrot devs and rakudo devs
pmichaud (Parrot head)
masak hugs dukeleto 19:22
dukeleto feels loved
masak dukeleto: that's great news!
moritz_ pmichaud: I got a .reverse related failure in one of the integration tests, but lots of non-zero return statuses
pmichaud moritz_: 41-to-50?
moritz_ the problem is that if the summary report is longer than a screen page, it gets really hard to figure out what's actually happening
masak yes, lots of non-zero return statuses.
moritz_ pmichaud: think so, yes 19:23
pmichaud non-zero return status.... one time I noted that removing t/spec and starting over somehow seemed to resolve those.
but maybe something else was happening.
masak haven't experienced that this time.
they consistently fail.
dukeleto i am concerned that "make spectest" does a "git pull" on roast. what if you want to run spectests with your current version of roasts.git? what if you are on a branch? git pull will commit a merge to that branch 19:24
pmichaud are the non-zero return status actually denoting failing tests, or just a test script returning non-zero for some reason?
moritz_ the latter
dukeleto thinks git pull --rebase might be friendlier
pmichaud I'm fine with whatever git-related changes we need to make to the "make spectest" target (as long as it ultimately works, fsvo "works") 19:25
PerlJam dukeleto++
moritz_ dukeleto: doing a rebase over a branch merge can do much more harm
masak just make it not pull if it's on a branch. 19:26
dukeleto i can submit a patch, if peeps tell me what they want
shall i make a patch that does not pull if not on master? is that wanted? 19:27
moritz_ works for me
pmichaud I'd like "make spectest" to continue to mean "test this Rakudo against the current latest spectests"
it can halt or warn if there are uncommitted changes or t/spec is really a branch 19:28
(halt is probably better)
masak +1
moritz_ NOOO
that means I can't do a spectest run before committing
dukeleto moritz_: i agree
pmichaud then we should have a different target.
I'm fine with letting uncommitted changes go through. 19:29
PerlJam make dirty-spectest
moritz_ wfk
*wfm
pmichaud I don't really expect there to be much branching in roast, so I don't see it as a big issue.
dukeleto pmichaud: it is mostly for local branches, but I hear what you are saying 19:30
pmichaud: if i want to hack on 2 different roast-related things, i would create local branches for them
pmichaud: which is when I run into "git pull" being a pain
pmichaud dukeleto: I'm open to suggested fixes :) 19:31
moritz_ +1 to a spectest target that doesn't pull or fetch at all
dukeleto moritz_: yeah, i think we should leave "spectest" target the same, and add another that doesn't pull
colomon has been using tools/test_summary.pl almost exclusively for months now... it never updates t/spec before running. 19:32
dukeleto didn't know about test_summary.pl
19:32 whiteknight left
moritz_ colomon: my problem with test_summary.pl is that it does not parallelize 19:33
colomon moritz_: you could think of it as encouraging you to make rakudo faster... ;) 19:34
pmichaud I wonder how hard it would be to parallelize test_summary.pl . Or if it's worth the effort. 19:35
moritz_ we have a perfectly fine parallel test target already. 19:36
pmichaud except it reports bizarre "non-zero return code" errors
and its summary isn't always useful
s/isn't always/is often not/
dukeleto Parallel::Iterator could be useful for that
colomon which is why I've been using test_summary.pl -- no false errors for me on OS X. 19:37
pmichaud afk, kid pickup
masak trac.parrot.org/parrot/ticket/1749 is now fixed -- maybe we should revert github.com/rakudo/rakudo/commit/77a...65342df17a ? 19:48
anyone for or against that?
PerlJam wow 19:51
mberends +1 to revert
moritz_ masak: maybe test the speed difference between reverted and non-reverted first? :-)
PerlJam Is there a benchmark test for it?
moritz_ we don't benchmark in tests. 19:52
at least not in spectests
PerlJam s/test// then
masak if someone's willing to benchmark, I can push a revert :)
shouldn't be so hard to discover a 25x performance degradation... :) 19:53
moritz_ one more thing
I'd like to ask for a commit bit for patrickas
colomon I think bench-scripts / pick-works.pl should test for it nicely.
moritz_ he's contributed several good patches so far, most notably series refactor and MAIN sub 19:54
PerlJam +1 from me
colomon +1 19:55
moritz_ so we just need +1 from jnthn&pmichaud and a CLA :-) 19:56
bed time for me, TTFN folks
masak +1 from me too 19:57
patrickas++ 19:58
PerlJam patrickas can pursue the CLA independent of anything else. 20:04
pmichaud +1 from me 20:06
just let me know when the CLA has been sent
masak pmichaud: can you easily benchmark the above #1749 thingie? 20:08
pmichaud masak: sure
masak \\o/
pmichaud 1.007s versus 1.036 (reverted) 20:12
+1 to revert
PerlJam I think it was Alias that had the idea to include benchmarks just like we include tests. The more I think about it, the more I like that idea.
pmichaud we have benchmarks; we just need a harness/driver 20:13
PerlJam and a database I think (with a way to choose whether to save to it) 20:16
(where "database" could mean a CSV) 20:17
masak reverts 20:18
dukeleto has been thinking about a benchmark framework suitable for parrot+rakudo for a while 20:22
i have all the pieces, but the glue keeps sticking to my hands 20:23
21:54 masak left
dukeleto 3 22:03
Tene ³ 22:15