[00:00] *** pmurias left [00:02] seems like i'll have to re-run rakudo-moar/2014.07 [00:02] *** raiph joined [00:08] *** rurban joined [00:10] and possibly also nqp-moar/2014-07, that seems to be missing a bunch [00:10] weird. [00:13] *** kurahaupo_ left [00:14] *** rindolf left [00:14] *** kurahaupo_ joined [00:16] *** chenryn left [00:17] *** virtualsue left [00:22] .tell japhb_ if you look at http://t.h8.lv/p6bench/2014-08-01-moar.html ... what could be the reason two implementations are missing in all (?) graphs? [00:22] timotimo: I'll pass your message to japhb_. [00:23] is there a good pattern for delegating to a member object? right now I'm futzing with add_fallback, but it feels a bit like a dead end [00:23] yeah [00:23] you should be using "handles" instead :) [00:23] ah ha [00:23] m: class Foo { has Str $.text handles }; Foo.new(:text("Hi there, how are you")).lc.say [00:23] rakudo-moar 89c8e4: OUTPUT«hi there, how are you␤» [00:24] m: class Foo { has Str $.text handles }; Foo.new(:text("Hi there, how are you")).uc.say [00:24] rakudo-moar 89c8e4: OUTPUT«HI THERE, HOW ARE YOU␤» [00:24] lovely [00:24] I made it here before feeling like there must be a nicer way: ' $object, $name { $object.json.^methods.grep({ $name })[0] }' [00:24] * timotimo blushes [00:24] (the second clause of add_fallback) [00:25] *** chenryn joined [00:27] *** aoseki joined [00:27] *** iarna joined [00:29] *** kshannon joined [00:29] *** cibs joined [00:30] *** akaseki left [00:30] *** rurban left [00:38] *** iarna left [00:41] *** aoseki left [00:42] *** akaseki joined [00:45] *** iarna joined [00:45] *** thou joined [00:46] jnthn: http://t.h8.lv/p6bench/2014-08-01-moar_redone.html - less broken now [00:46] btyler: i'm glad to hear you're progressing :) [00:49] *** thou left [00:50] *** aoseki joined [00:50] *** colomon joined [00:51] jnthn: it seems like we regressed for loop performance [00:51] yep. current thorn: what does it take to implement roles like Associative or Positional? provide a few methods with the right names, a-la python magic methods? [00:51] *** nbrown_ joined [00:51] or is "implement" the wrong way to think about them (given that they're not interfaces) [00:51] thorn as in: can't figure it out or as in: the documentation doesn't say? [00:52] can't find it in the docs, examples in rakudo source seem thin on the ground since it's apparently taken care of in bootstrap [00:52] timotimo: Ah, good to know. Remind me tomorrow, I'll bet the improved sink context stuff knocked the analysis off. [00:52] ah! [00:52] *** akaseki left [00:52] that seems like a good indication [00:53] btyler: not in bootstrap; look at Any.pm [00:55] rakudo/nom: 3618990 | jnthn++ | src/Perl6/Optimizer.nqp: [00:55] rakudo/nom: Make Junction optimization less costly. [00:55] rakudo/nom: [00:55] rakudo/nom: This refactor splits analysis and transform, decreasing the cost of [00:55] rakudo/nom: the common case when we just analyze and realise we're not looking [00:55] rakudo/nom: at a Junction. [00:55] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/361899024e [00:55] rakudo/nom: 9d6c19c | jnthn++ | src/Perl6/Optimizer.nqp: [00:55] rakudo/nom: Refactor visit_op in optimizer. [00:55] rakudo/nom: [00:55] rakudo/nom: This not only makes it a good bit cleaner, but also reduces the cost. [00:55] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9d6c19c8fd [00:55] *** nbrown_ left [00:56] *** iarna left [00:56] aye, the tree looks significantly different now [00:57] it starts with a bind to an inline arg, binds the number that came before the ^ there, then comes a decontrv ... and the inside of the prefix:<^> operator i believe [00:57] *** akaseki joined [00:59] maybe it'd be enough to signalize not to inline the .. operator and its variants %) [00:59] Well, sleep time for me...'night [00:59] good night, jnthn! [00:59] *** aoseki left [01:00] *** aoseki joined [01:02] *** akaseki left [01:11] *** iarna joined [01:12] *** chenryn left [01:18] *** BenGoldberg joined [01:24] *** BenGoldberg left [01:25] *** slavik left [01:25] *** xenoterracide_ joined [01:28] *** PotatoGim left [01:33] *** BenGoldberg joined [01:35] *** silug left [01:36] *** dayangkun joined [01:37] *** slavik joined [01:40] *** silug joined [01:41] *** xenoterracide_ left [01:42] *** klapperl_ joined [01:45] *** klapperl left [01:46] o/ from Newfoundland! [01:47] *** xenoterracide joined [01:48] *** FROGGS_ joined [01:51] roast/S26-WHY: 2eb4bd7 | (Rob Hoelz)++ | S26-documentation/why-leading.t: [01:51] roast/S26-WHY: Use a variable to track POD contents [01:51] roast/S26-WHY: review: https://github.com/perl6/roast/commit/2eb4bd71a9 [01:51] roast/S26-WHY: a370b4f | (Rob Hoelz)++ | S26-TODO.md: [01:51] roast/S26-WHY: More TODOs [01:51] roast/S26-WHY: review: https://github.com/perl6/roast/commit/a370b4f789 [01:51] roast/S26-WHY: 01725c6 | (Rob Hoelz)++ | S26-documentation/why-leading.t: [01:51] roast/S26-WHY: Check WHEREFOREs in leading test [01:51] roast/S26-WHY: review: https://github.com/perl6/roast/commit/01725c604a [01:51] roast/S26-WHY: 503754b | (Rob Hoelz)++ | S26-documentation/why-trailing.t: [01:51] roast/S26-WHY: Check $=pod for trailing comments [01:51] roast/S26-WHY: review: https://github.com/perl6/roast/commit/503754bbdf [01:51] *** FROGGS left [01:54] *** ventica left [01:58] *** kst` joined [01:58] *** colomon left [01:58] *** anocelot_ joined [01:59] *** slavik1 joined [01:59] *** cognominal left [01:59] *** cognominal joined [01:59] *** slavik left [01:59] *** kst left [01:59] *** FROGGS_ left [01:59] *** FROGGS_ joined [02:01] *** anocelot left [02:02] *** aoseki left [02:02] *** xenoterracide left [02:03] *** sftp joined [02:08] *** anaeem1 joined [02:09] *** anaeem1 left [02:09] *** anaeem1 joined [02:11] *** autark left [02:14] *** anaeem1 left [02:14] *** noganex joined [02:18] *** noganex_ left [02:18] *** dwarring left [02:19] *** nbrown joined [02:21] *** chenryn joined [02:28] *** anaeem1__ joined [02:32] *** anaeem1__ left [02:33] botsnack [02:33] 31 Jul 2014 19:54Z japhb: i really ought to pay close attention to the flags for the test runner when i do jvm benchmarks ... i should let it do fewer tests in a row or something ... or could we perhaps have an option that allows us to scale two steps at a time? [02:33] botsnack [02:33] *** thou joined [02:33] 00:22Z japhb_: if you look at http://t.h8.lv/p6bench/2014-08-01-moar.html ... what could be the reason two implementations are missing in all (?) graphs? [02:33] Oy, that's annoying [02:34] *** xenoterracide joined [02:36] *** anaeem1 joined [02:36] .tell timotimo Reason for some implementations to be missing from most graphs: having run a limited test with some of the implementations and not the others. The default behavior is that running a new set of tests for a given compiler checkout will overwrite the timings for that compiler checkout, not combine with previously existing runs. This is because combining could too easily result in nonsense. [02:36] japhb: I'll pass your message to timotimo. [02:38] .tell timotimo So if your most recent run for each of the compared compiler builds did not specify the same tests, you're going to find that some/most of the plots will be missing some lines. You can see this if you do a simple text mode comparison; you'll see a lot of missing data. [02:38] japhb: I'll pass your message to timotimo. [02:38] *** thou left [02:40] *** lustlife joined [02:40] hey japhb [02:40] 02:36Z timotimo: Reason for some implementations to be missing from most graphs: having run a limited test with some of the implementations and not the others. The default behavior is that running a new set of tests for a given compiler checkout will overwrite the timings for that compiler checkout, not combine with previously existing runs. This is because combining could too easily result in nonsense. [02:40] 02:38Z timotimo: So if your most recent run for each of the compared compiler builds did not specify the same tests, you're going to find that some/most of the plots will be missing some lines. You can see this if you do a simple text mode comparison; you'll see a lot of missing data. [02:41] i'm up way past my bedtime [02:41] Ah, I understand your concern with the JVM testing time. Hmmm, I need to think about that. [02:41] *** anaeem1 left [02:41] timotimo: So sleep! :-) [02:41] you "understand my concern"? [02:41] have you actually tried it? [02:41] hold on, let me get my timings [02:41] Yes. I don't test with the JVM backend anymore. I don't have the time for it, NPI. [02:42] It's all death by startup time. [02:42] at almost exactly 1800 i started my benchmarks [02:42] yes, it is [02:42] at 0100 it wasn't finished yet. [02:43] i ran nqp-moar, nqp-parrot, nqp-jvm, rakudo-moar, rakudo-parrot, rakudo-jim [02:43] jvm* [02:43] I've several times tuned bits of timeall to try to get valid data while forcing fewer actual test runs, so that JVM would be less painful. And then we collectively more than made up for it with new tests and the minimum-three-data-points rule. :-( [02:43] well, actually, at about 0000 +/- 0030 i got to rakudo-jvm, which was followed by nqp-jvm, which was the last one [02:43] "It's Rakudo, Jim. But not as we know it ..." [02:44] japhb: have you seen how close we are to the nqp timings with rakudo?! [02:44] Where's your most recent plot data? [02:45] http://t.h8.lv/p6bench/2014-08-01-moar_redone.html [02:45] if you like line soup: http://t.h8.lv/p6bench/2014-08-01-three_backends.html [02:45] i think i should re-gen these graphs, too [02:46] F5 for a few more lines [02:47] jnthn said he'd put a few tricks we learnt on moarvm to good use on rakudo-jvm [02:47] when that happens, i would expect the rakudo-jvm line to approach the nqp-jvm line in a drastic way [02:47] Hmmm, In some tests Rakudo is quite close to NQP, and in a few others still quite a bit behind -- but not nearly as bad as last year. [02:48] yes [02:49] I've noticed the recent bench runs have tended to not include perl 5. time saving measure, too many unimplemented benchmarks, or just not what's being measured atm? [02:49] oh [02:49] i can run a perl5 benchmark, too [02:49] *** nbrown left [02:49] I guess "or just forgot" should have been part of the question :) [02:49] i have to build a perl5 first :) [02:50] *** nbrown joined [02:50] *** nbrown left [02:50] i hope chatting on irc via ssh won't disturb my cpu too much to get acceptable benchmark timings [02:50] timotimo: just keep a perl5 build around. It's not like we need to follow blead. :-) [02:50] perl5 will be too good in all the benchmarks anyway :) [02:51] Wow, as long as you avoid a couple big issues (concat, push), nqp-jvm is wicked fast when it gets going. I mean, DAMN. [02:51] yes [02:51] it doesn't get going during compilation, sadly [02:51] .o( though if we used the evalserver for that ... ) [02:52] *** nbrown joined [02:52] Too much risk of contamination between runs to use the same process space for more than one run. :-( [02:52] for compilation? [02:53] Oh, I thought you mean the startup compile time for each test. [02:53] no [02:53] not for benchmarks [02:53] oh, another thing [02:53] how hard would it be to "transpose" perl6-bench [02:53] Which actually is probably getting better with jnthn++'s general closure and dynlex reduction work [02:53] as in: test different implementations of the same code with the same implementation [02:54] back when i wrote the junction optimization code i wasn't aware of the performance ramifications of nested subs [02:54] I think you're talking about a feature I was thinking of overlaying plots [02:54] that would certainly be useful [02:54] though i'd also imagine you'd have one graph for each implementation, showing all "versions" of the benchmark in one graph [02:55] btw, can we somehow put an installation for Data::Alias into the automatic build process of perl5 in perl6-bench? [02:55] We really need to have a doc that has rules of thumb about what to do or avoid in performance-critical code. Because trawling through commit logs -- or even more verbose, #perl6 -- isn't tenable. [02:56] number one rule really is: measure, measure, measure [02:56] timotimo: yeah, post-build module installation has been on my list for a while. Just haven't had tuits for it. I want to have it for all compilers that have a module ecosystem, so we can e.g. test performance of things from the panda ecosystem. [02:57] *** anaeem1_ joined [02:57] timotimo: well yeah, sure. But I'm talking general things that have unexpectedly large cost, like creating a closure inside an inner loop. [02:57] Things that are only obvious in retrospect. [02:58] .oO( ... in introspect? ) [02:58] *** raiph left [02:59] Oh, and I think I can reasonably claim to be the last person that needs to be told to measure performance. :-) [02:59] hahah :D [02:59] sorry, you're right of course [02:59] *** lustlife left [02:59] *** cognominal left [02:59] *** cooper_ left [02:59] *** avuserow left [02:59] hopefully in the future we'll have some great tooling to get a good look at performance vitals of both user code and compiler internals [03:00] *** tadzik left [03:00] Yeah, quite. I'm salivating over the idea of having profile flame plots in r-m [03:01] *** tadzik joined [03:01] *** ventica joined [03:01] how woud that look? highlight lines with their time cost? [03:01] *** anaeem1_ left [03:01] *** cognominal joined [03:01] http://t.h8.lv/p6bench/2014-08-01-three_backends.html - updated with perl5 - http://t.h8.lv/p6bench/2014-08-01-three_backends.html [03:02] Gah, bus stop. Will have to pick this up later. [03:02] *** avuserow joined [03:02] but ... you just sent me to bed! :P [03:03] I'll .tell you [03:03] afk [03:03] but i enjoy interacting with you :\ [03:03] *** cooper_ joined [03:03] holy cow, thanks timo [03:03] wow. what. in postwhile_nil_native, rakudo-moar is actually faster than nqp-moar? that's gotta be wrong %) [03:05] it could quite possibly be that nqp::list is more expensive than a WVal to grab the Nil that we have in the perl6 code [03:05] this is really cool -- puts 'nqp-jvm is damn fast' into much better perspective [03:05] i wonder why jvm tanks so hard in the concat tests [03:06] yes, the int2str_concat performance puzzles me [03:06] maybe our numification is just ridiculously underperformant? [03:07] it would make a whole lot of sense if perl5 was crazy fast at that [03:07] *** Woodi left [03:08] yeah [03:09] when we get the for optimization back into rakudo, we should see much better results for the "for" benchmarks, too [03:09] like, there was a 3x performance drop on moar; the same problem probably exists on all backends [03:10] it is to be expected that our performance post-regression-fix comes out a bit higher than it was in the 2014.07 release [03:11] *** lustlife joined [03:11] *** iarna left [03:11] *** nbrown left [03:11] *** iarna joined [03:13] I wonder what ruby's performance was like compared to p5 when it was first starting to become popular [03:14] perhaps the most amazing thing about the performance graphs is how strong the difference is between the jvm rakudos on the normal and the native variants of benchmarks [03:14] visit_2d_indices_loop for example [03:14] 106x slower than fastest ← non-native rakudo-jvm [03:14] the general impression I have is "slow", but it'd be interesting to have a more concrete idea. rakudo being within 20x of perl5 for lots of workloads is probably starting to edge into the same mult as ruby originally had vs perl5 [03:14] 30x slower than fastest ← perl5 vs native rakudo-jvm [03:14] yeah, I noticed that as well [03:15] (or 15x if you count that at the same x position) [03:16] it amazes me especially much how good we perform at rational numbers (i think these tests test fatrats) [03:19] anyway, ought to go to bed now :) [03:19] night! [03:19] *** nbrown joined [03:20] .o( perl5.20 is exactly as fast at rc-mandelbrot as the recent rakudo-moar's ) [03:23] *** ventica left [03:24] *** [Sno] left [03:28] *** takesako left [03:32] *** telex left [03:34] *** telex joined [03:35] *** nbrown left [03:43] *** takesako joined [03:46] *** BenGoldberg left [03:48] *** dayangkun left [03:51] *** ilbot3 joined [03:53] *** kurahaupo_ left [03:53] *** cibs left [03:54] *** iarna left [03:54] *** cibs joined [03:55] *** BenGoldberg joined [03:55] *** [Sno] joined [03:56] *** ventica joined [03:59] *** akaseki joined [04:02] *** kaare__ joined [04:03] *** xenoterracide left [04:05] *** dayangkun joined [04:06] *** rurban joined [04:06] *** kaare__ is now known as kaare_ [04:12] lots more to do, but if anyone has a need for speedy JSON parsing (no encoding yet), I'd appreciate feedback: https://github.com/kanatohodets/p6-json-jansson [04:14] also - is there any standard in p6 land for module installation scripts? it'd be nice to check for NativeCall and jansson on install [04:17] heh I think FROGGS_wanted some JSON workers :-) [04:22] *** thou joined [04:26] *** thou left [04:28] *** chenryn left [04:34] m: my %x; %x{1}=[]; say "alpha hash time" if "a" ~~ %x{1} ; [04:34] rakudo-moar 89c8e4: ( no output ) [04:36] this is not Perl 5, and there are no impicit 'any' semantics on smartmatching lists [04:36] m: my %x; %x{1}=[]; say "alpha hash time" if "a" ~~ %x{1}.any [04:36] rakudo-moar 89c8e4: OUTPUT«alpha hash time␤» [04:36] *plicit [04:37] m: my %x; %x{1} = any ; say "alpha hash time" if "a" ~~ %x{1} [04:37] rakudo-moar 89c8e4: OUTPUT«alpha hash time␤» [04:37] though that works [04:38] m: my %x; %x{1} = set ; say "alpha hash time" if "a" ∈ %x{1} [04:38] rakudo-moar 89c8e4: OUTPUT«alpha hash time␤» [04:38] so does that [04:38] btyler: you should be able to depend on NativeCall since it's in the p6 ecosystem [04:39] m: my %x; %x{1} = set ; say "alpha hash time" if x{1} [04:39] rakudo-moar 89c8e4: OUTPUT«===SORRY!=== Error while compiling /tmp/XOOtufo24w␤Undeclared routine:␤ x used at line 1␤␤» [04:39] m: my %x; %x{1} = set ; say "alpha hash time" if %x{1} [04:39] rakudo-moar 89c8e4: OUTPUT«alpha hash time␤» [04:39] btyler: that is, once you make your module installable by panda [04:39] or even that [04:39] gtodd: ^^ [04:40] btyler: not sure how one goes about detecting and gracefully requiring a native library, if that's even possible at present. I'd love to know for my own modules. [04:43] *** gfldex joined [04:47] *** Woodi joined [04:54] *** kaare_ left [04:57] *** rindolf joined [04:59] *** chenryn joined [05:00] *** avuserow left [05:02] avuserow: I was thinking of just running a script with nativecall that tried to call one of the methods, then catching the error it generates if it can't find the lib [05:03] *one of the methods of the native lib [05:07] *** rurban left [05:08] *** thou joined [05:18] *** avuserow joined [05:21] *** kaare_ joined [05:27] *** kaare__ joined [05:28] *** [Sno] left [05:28] *** BenGoldberg left [05:30] *** kaare_ left [05:35] *** bcode joined [05:38] *** gfldex left [05:39] *** avuserow left [05:41] roast/S26-WHY: 623f1f5 | duff++ | S26-documentation/why-leading.t: [05:41] roast/S26-WHY: Add leading tests for role, submethod, grammar, rule, token and regex [05:41] roast/S26-WHY: review: https://github.com/perl6/roast/commit/623f1f557a [05:57] *** avuserow joined [06:00] *** denis_boyun joined [06:04] *** thou left [06:06] *** aoseki joined [06:06] *** akaseki left [06:10] *** darutoko joined [06:12] *** dayangkun left [06:14] *** akaseki joined [06:16] *** aoseki left [06:18] o/ [06:19] *** aoseki joined [06:20] *** Rotwang left [06:22] *** akaseki left [06:24] *** aoseki left [06:25] *** akaseki joined [06:25] *** kivutar joined [06:29] *** kurahaupo_ joined [06:29] *** dayangkun joined [06:30] *** grondilu joined [06:30] * grondilu failed to compile rakudo on moarvm: http://paste.siduction.org/20140801062936 [06:30] Stage optimize : Cannot find method 'orig' [06:34] *** aoseki joined [06:34] * grondilu cleans up his install and nqp directory and retries [06:37] *** akaseki left [06:42] *** virtualsue joined [06:56] *** [Sno] joined [07:02] *** kaleem joined [07:06] *** bjz joined [07:07] * grondilu failed again [07:08] *** fhelmberger joined [07:15] *** ventica left [07:15] *** kaare__ is now known as kaare_ [07:19] *** virtualsue_ joined [07:19] *** ventica joined [07:20] *** virtualsue left [07:20] *** virtualsue_ is now known as virtualsue [07:23] *** cognome left [07:24] *** cognome joined [07:30] *** cognome_ joined [07:32] *** cognome left [07:38] *** ventica left [07:40] *** dmol joined [07:41] *** pecastro left [07:46] *** Woodi left [07:46] *** Woodi joined [07:47] morning, #perl6 [07:50] *** ventica joined [07:52] * moritz idly wonders if any company has a clean solution for aggregating accounting data, matching it with product definitions and generating invoices out of them [07:53] at $work, this is a regular pain point, and my searches for existing solutions only brought up very specialized solutions (like, for telephony) [07:58] *** ventica left [08:00] *** FROGGS_ left [08:01] *** ventica joined [08:07] *** takesako left [08:08] moritz: that smells like ERP, and it's a quicksand trap I refuse to go near while sober [08:11] *** takesako joined [08:13] *** zakharyas joined [08:17] xiaomiao: yes, but not quite ERP [08:18] *** dakkar joined [08:18] *** Ven joined [08:18] *** Ven left [08:19] *** vendethiel left [08:21] *** dayangkun_ joined [08:24] *** ventica left [08:25] *** dayangkun left [08:31] *** virtualsue left [08:41] *** Akagi201 left [08:43] *** cooper_ left [08:44] *** cooper- left [08:44] *** zakharyas left [08:47] *** FROGGS[mobile] joined [08:50] \o [08:55] p6: say DateTime.now ~~ Date.today [08:55] rakudo-{parrot,moar} 89c8e4: OUTPUT«True␤» [08:55] ..niecza v24-109-g48a8de3: OUTPUT«===SORRY!===␤␤Undeclared name:␤ 'Date' used at line 1␤␤Unhandled exception: Check failed␤␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 1502 (die @ 5) ␤ at /home/p6eval/niecza/src/STD.pm6 line 1147 (P6.comp_uni…» [08:55] ..rakudo-jvm 89c8e4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤» [08:55] \o/ [08:56] pm: say DateTime.now ~~ Date.today [08:56] m: say DateTime.now ~~ Date.today [08:56] rakudo-moar 89c8e4: OUTPUT«True␤» [08:56] p: say DateTime.now ~~ Date.today [08:56] rakudo-parrot 89c8e4: OUTPUT«True␤» [08:56] r: say now ~~ Date.today [08:56] rakudo-{parrot,moar} 89c8e4: OUTPUT«False␤» [08:56] ..rakudo-jvm 89c8e4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤» [08:56] I'm wondering if that shouldn't work too... [08:57] any votes for or against? [08:58] +1 for it [09:04] the ones I see making sense (and not always returning False) are DateTime ~~ Date (fixed already, PerlJam++), Instant ~~ Date, Instant ~~ DateTime, and DateTime ~~ Instant. [09:05] *** PotatoGim joined [09:05] I'm not really up to date (sic) wrt datetime and instant [09:05] can those always be round-tripped? [09:06] or does one of the require extra time zone information, for example? [09:06] I'm not sure roundtripping is required for smartmatching to make sense. [09:06] only that a given datetime unambiguously stands for a given instant. [09:07] (and I'm holding my breath instaad of saying "...and vice versa", because it's not 1-to-1, thanks to timezones and other stuff) [09:07] instead* [09:07] but then only one of those smartmatchings makes sense, no? [09:07] ah, no [09:07] never mind [09:07] no, I think both do. [09:08] they both ask sensible questions. [09:08] and instance can be represented as several DateTimes with different time zones [09:08] aye :) [09:08] but you can still query the correspondence [09:08] * moritz feels he understood something [09:08] and there are "illegal" DateTimes which, (if you could create them) don't have a corresponding Instant. [09:09] and there are "double" DateTimes which happily match two Instants. thanks, DST, you jerk. [09:09] (and now you also know why I implemented only Date, and left DateTime to somebody else :-) [09:10] :D [09:10] Temporal, the way it eventually turned out, was a wonderfully successful case of "I'll leave this to someone else" :) [09:10] and we managed to do it without having any Discordian Hexagonal Klingon Swatch time left in the spec :P [09:12] I still think there's room for something like DateTime::Interval. but it can easily be mapped out in module-land first. [09:12] with minimal duck punching. [09:15] m: say $*TZ [09:15] rakudo-moar 89c8e4: OUTPUT«0␤» [09:16] ...isn't camelia running in .nl ? shouldn't that be 7200, then? [09:16] it's 7200 locally. [09:18] *** SamuraiJack joined [09:23] *** pecastro joined [09:23] *** dayangkun_ left [09:25] camelia isn't running on feather anymore [09:25] is it running in a 0-offset timezone? [09:26] it's running on the internet :-) [09:26] moritz@host07:~$ date [09:26] Fri Aug 1 09:26:17 UTC 2014 [09:26] it's timezone is configured to be UTC [09:26] oki [09:26] that explains it. [09:26] moritz++ [09:30] *** spider-mario joined [09:33] *** colomon joined [09:36] *** dayangkun_ joined [09:38] *** virtualsue joined [09:40] *** bjz_ joined [09:41] *** bjz left [09:41] *** anaeem1 joined [09:49] good *, #perl6! [09:50] hmmm... I can't get rakudo to build on Moar atm [09:51] Stage optimize : Cannot find method 'orig' [09:51] at src/Perl6/Optimizer.nqp:353 (blib/Perl6/Optimizer.moarvm:add_memo:19) [09:51] from src/Perl6/Optimizer.nqp:348 (blib/Perl6/Optimizer.moarvm:add_worry:19) [09:52] looks like it is jnthn's last commit [09:52] wtf [09:52] Works here [09:52] want me to give you the full stacktrace ? [09:53] oh [09:53] Maybe I shoulda bumped NQP_REVISION... [09:55] oh, and MOAR_REVISION even more so given there's bug fixes. [09:55] nqp: 4c90808 | jnthn++ | tools/build/MOAR_REVISION: [09:55] nqp: Get various MoarVM improvements. [09:55] nqp: review: https://github.com/perl6/nqp/commit/4c90808f07 [09:56] rakudo/nom: 4024362 | jnthn++ | tools/build/NQP_REVISION: [09:56] rakudo/nom: Bump NQP_REVISION. [09:56] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4024362c60 [09:56] jnthn: we really need to fix parrot :/ [09:57] FROGGS[mobile]: I can't actually build nqp-p at the moment due to link errors. :/ [09:57] rebuilding and spectesting... [09:57] will also do parrot and jvm this time [09:58] *** fhelmberger left [09:58] FROGGS[mobile]: Is it just the inexplicable fallout of the junctions related patch I did that's at issue? [09:59] r: my @a = "a\n\n\nb\n \nc".split: /[\h*\n]{2..Inf}/; say @a.perl [09:59] jnthn: seems like, aye [09:59] rakudo-{parrot,moar} 89c8e4: OUTPUT«Array.new("a", "", "", "b", "", "c")␤» [09:59] ..rakudo-jvm 89c8e4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤» [10:00] oops [10:00] r: my @a = "a\n\n\nb\n \nc".split: /[\h*\n]**{2..Inf}/; say @a.perl [10:00] rakudo-{parrot,moar} 89c8e4: OUTPUT«Array.new("a", "b", "c")␤» [10:00] ..rakudo-jvm 89c8e4: OUTPUT«Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp'␤ in (gen/jvm/main.nqp)␤␤» [10:00] that's better [10:08] moritz: speaking of time zones: http://www.commitstrip.com/en/page/20/ [10:09] roast: 2073365 | (Elizabeth Mattijsen)++ | S06-routine-modifiers/lvalue-subroutines.t: [10:09] roast: Another fudge for (probably) #122448 [10:09] roast: review: https://github.com/perl6/roast/commit/20733650e7 [10:09] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122448 [10:18] on Moar: All tests successful. [10:18] Files=908, Tests=31977, 226 wallclock secs ( 9.09 usr 4.02 sys + 1420.95 cusr 173.06 csys = 1607.12 CPU) [10:19] * jnthn can't remember the last lizmat measurement [10:19] well, it was about the same, but with fewer tests [10:28] *** akaseki joined [10:28] *** chenryn left [10:32] *** aoseki left [10:38] masak: :-) [10:42] *** xragnar_ joined [10:42] *** xragnar left [10:42] *** xragnar_ is now known as xragnar [10:44] *** anaeem1 left [10:45] *** anaeem1 joined [10:49] hmmm... quite severe breakage on parrot indeed [10:49] *** anaeem1 left [10:50] https://gist.github.com/lizmat/72dc142c2aac6b402b64 # failures on parrot [10:51] has anyone bisected it? is there a likely culprit commit? [10:51] Yes, we know which commit did it. [10:51] ah. [10:51] Well, provided that one is the only issue [10:52] *** kurahaupo_ left [10:52] is it possible to revert it and see if everything rebuilds fine? [10:52] But (a) it makes no sense it should cause this kind of failure, and (b) latest nqp-p doesn't build on Windows, meaning it's a yak shave for me to go hunt it [10:52] *nod* [10:52] http://imgur.com/86npB1j # wonder what Perl 6 will be :-) [10:53] *** chenryn joined [10:54] Perl 6 does the same, but the 2012 version is 10 cm high, and the 2014 version is 50 cm high :) [10:55] *** anaeem1 joined [10:56] the Perl 5 truck is old and ugly, and the snowplough is clearly hacked together and welded onto the front. [10:57] still, it gets things done. [10:57] yes, sorry, forgot that that doesn't go without saying [10:57] it puts food on a lot of people's families every day. [10:58] for some reason it's put too much food on the table here at work today [10:58] (catering oversupply) [10:58] must be Perl's fault. [10:58] well, you saw the utter efficiency of Perl in that gif :P [10:58] no wonder there's a lot of food. [11:00] *** anaeem1 left [11:01] *** carlin left [11:01] *** rindolf left [11:02] *** rindolf joined [11:02] hallo today :) [11:02] *** anaeem1_ joined [11:03] cześć, Woodi [11:05] *** carlin joined [11:09] moritz: I think double accounting is general cure and solid base for such cases. but it's a overkill, it's so solid that ppls don't like it :) [11:10] Woodi: this is not about the actual accounting/bookkeeping [11:10] Woodi: but about collecting your customer's user data, and using that to generate invoices [11:12] it's very interdisciplinary problem :) I like put users personal data into LDAP and have automatic balances from double accounting system :) [11:12] btw. I do not have such system :) [11:13] moritz: your desired system sounds interesting. unfortunately, I don't know about any prior art. [11:14] requirements, details, analysis, specifications, lot's of work :) [11:18] I found http://blog.plover.com/prog/Moonpig.html quite interesting, and it solves part of the problem (the billing), but with quite different constraints than ours [11:21] *** SamuraiJack_ joined [11:22] *** SamuraiJack left [11:23] I think mjd is proud of quality in moonpig project :) but I also got impression it is crafted for theirs needs... [11:24] I [11:24] ... still hope mjd disagree with my impression :) [11:25] wy wouldn't it be craftef for their needs? [11:28] it was internal project for some mail company and lot's of code there is for theirs ways of calculating receivables... it's possible project is written with general case in mind but probably I need some training to see this [11:33] and it have all web interface ! somehow I hate this... keyboard presses lag, all that infrastructure between... when you have, let's say 100 invoices to put into system (per day or week) you realy want curses-like app responsibility [11:35] I have just found that this exists and it it pleases me that it is so: http://www.swearemipsum.com/ [11:37] *** fhelmberger joined [11:40] *** SamuraiJack__ joined [11:43] *** kivutar left [11:44] *** SamuraiJack_ left [11:44] *** chenryn left [11:49] *** mr-foobar joined [11:51] *** kivutar joined [11:54] *** dmol left [11:57] nqp: 6923af7 | jnthn++ | src/vm/moar/QAST/QAST (2 files): [11:57] nqp: Assorted small optimizations to QAST -> MAST. [11:57] nqp: review: https://github.com/perl6/nqp/commit/6923af795c [11:57] nqp: 4b6a4af | jnthn++ | src/how/NQPClassHOW.nqp: [11:57] nqp: Cheapen late-bound method lookup. [11:57] nqp: review: https://github.com/perl6/nqp/commit/4b6a4af919 [11:59] roast/S26-WHY: b6ebef3 | duff++ | S26-TODO.md: [11:59] roast/S26-WHY: Update S26-TODO.md [11:59] roast/S26-WHY: review: https://github.com/perl6/roast/commit/b6ebef3e2c [12:00] *** SamuraiJack__ left [12:01] rakudo/nom: 5f7eaa6 | jnthn++ | src/Perl6/Optimizer.nqp: [12:01] rakudo/nom: Optimize the optimizer somewhat. [12:01] rakudo/nom: [12:01] rakudo/nom: Shaves about a third off its execution time. [12:01] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5f7eaa6b9a [12:01] rakudo/nom: 4d347fd | jnthn++ | src/Perl6/World.nqp: [12:01] rakudo/nom: Cheapen dynamic compilation somewhat. [12:01] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4d347fd0de [12:04] jnthn: I was *joking* about negative parse times in the near future. You weren't supposed to take me seriously :-) [12:06] *** nhayashi left [12:16] *** slavik1 left [12:16] *** kurahaupo_ joined [12:18] It's still a good bit too positive :P [12:19] *** kst`` joined [12:21] *** kst` left [12:21] *** kaare_ left [12:27] *** Ven joined [12:29] jnthn: is this a strange error message? postcircumfix:<{ }> binding not defined for type Hash [12:29] *** slavik joined [12:30] aha, most definitely [12:31] the error goes away with MVM_SPESH_DISABLE=1 [12:31] golfing down [12:31] lizmat: Yeah, that's on my todo list for today; FROGGS ran into it also [12:32] in my case, it comes from a repeated call to $foo := $bar [12:32] where and are varying [12:33] seems to happen on the 22nd iteration on a given $foo [12:38] * Ven is using Perl 6 to parsing some PDF, and it feels good. [12:38] *** kurahaupo_ left [12:38] *** kurahaupo_ joined [12:39] * Ven has no idea what the hell he's doing [12:40] .o( PDF parsing ? ) [12:40] doesn't look like dwarring++'s library uses `is export` anywhere [12:42] well, it's not like there's docs, so I'm trying to read the tests .. [12:42] *** oetiker joined [12:44] *** slavik left [12:44] well, doesn't seem like it'll quite do what I want it to. Too bad. [12:45] *** slavik joined [12:48] *** Alula_ left [12:48] *** Alula_ joined [12:49] `say PDF::Grammar::Content.pdf(slurp($f))` => Any :( [12:52] *** molaf joined [12:54] roast/S26-WHY: fd583ac | (Rob Hoelz)++ | S26-documentation/why-leading.t: [12:54] roast/S26-WHY: Fix WHEREFORE test [12:54] roast/S26-WHY: review: https://github.com/perl6/roast/commit/fd583acd1c [12:54] roast/S26-WHY: fad2530 | (Rob Hoelz)++ | S26-documentation/why-leading.t: [12:54] roast/S26-WHY: Add test names to failing WHEREFORE tests [12:54] roast/S26-WHY: review: https://github.com/perl6/roast/commit/fad2530662 [12:54] *** rurban joined [12:57] *** anaeem1_ left [13:04] why did I even try to parse that pdf ... 3 vim commands and it's done [13:06] * lizmat wonders how much can be done in 3 vim commands [13:07] I could've done it in 1, I just didn't know ":v" [13:07] *** chenryn joined [13:08] lizmat++ (grant manager for the next attempt to betterify ACT) [13:08] PerlJam: thank you [13:08] let's hope this one will go better than the other grants I've been / am grant manager of [13:09] BTW: for which I'm actually quite hopeful :-) [13:11] I didn't get a good vibe from the grant application, but with ribasushi and SawyerX chiming in their support and you as grant manager, I feel better about it. [13:12] in a way, it's the 3rd reboot of Act [13:15] * Ven wonders what the topic is [13:16] wowza, only turning dynamic vars into member vars shaves off a *third* of the execution time [13:16] Ven: What ACT is or what the grant is? [13:16] (of the optimizer) [13:17] PerlJam: both [13:17] * grondilu eventually managed to compile rakudo [13:17] timotimo: No, it's a bit more subtle than that. [13:18] ah? [13:18] timotimo: It also got rid of a lot of non-flattenable scope entries and switched them over to be native ints. [13:18] Ven: http://act.mongueurs.net/ has some links for more info about ACT, and the grant proposal is at http://news.perlfoundation.org/2014/07/grant-proposal-start-act---voy.html [13:18] oh! [13:18] yeah, that does sound nice to have :) [13:18] Together, on very hot paths called tens of thousands of times, it adds up. [13:18] TimToady: thanks re: hashes lists and "any" ... I was following along the smart matching examples from the ORA book "Perl6 Essentails" and they weren't working [13:19] gtodd: how recent is that book? [13:19] pretty old :-) [13:19] I see no mention of .any [13:19] :) [13:19] well not in that section [13:19] that book is 10 years old. [13:19] *** chenryn left [13:19] hehhe [13:19] A great many things have changed since it was published ;) [13:19] back when perl6 was more like perl5 is now [13:20] still looks a lot like perl 6 [13:21] *** chenryn joined [13:21] lizmat: About the ^^ bug, so far looks like the optimizer may not be to blame, but rather a code-gen bug. Which'd explain why it's Moar-specific, when the optimizer's inlining stuff works equally on other backends. [13:21] * gtodd adds .any everywhere and everything starts working [13:21] wheeee!!! [13:22] lizmat: xor code-gen has (at least) a register double-releaes bug... [13:22] yeah, .any is really the panacea for all bugs in perl6 programs [13:22] ok, want me to add this to the ticket ? [13:22] It fixes .any bug :P [13:22] lizmat: No, I'm working on the fix now [13:22] okidoki :-) [13:23] it's still probably wrong-ish but it works :) [13:24] p5 => TIMTOWDI , p6 => TIMTOWDWTDI [13:24] (extra WD for "well designed") [13:25] * nwc10 wonders whether it even matters whether the "next" "PHP" is numbered 6 or 7. In that, if it's not actually compatible with PHP 5, will it matter, because Facebook are already working on making Hack fast. [13:25] Files=908, Tests=31977, 112 wallclock secs (15.05 usr 3.87 sys + 1852.80 cusr 186.22 csys = 2057.94 CPU) [13:25] that's the spectest. [13:25] That's fast [13:26] nwc10: Faster than your last run? :) [13:26] one day Perl6 will have 25 year old "idioms" that will still don't feel crufty/hackish [13:26] *** nhayashi joined [13:27] yes they will :) [13:27] Perl6: More of what Perl 5 made greate... and less of what Perl 5 made grate [13:27] jnthn: well, I might be getting confused, because that was an optimised build, rather than ASAN [13:27] ah, ok :) [13:27] s/greate/greate/ [13:27] lizmat: hah [13:27] *sigh* [13:27] Still...112s :) [13:27] but still, it *is* fast [13:27] Where do I get my 24 core box? :) [13:28] .oO( Would Windows know waht to do with a 24 core box? ) [13:28] windows probably would, but TAP::Harness doesn't [13:28] jnthn: I have worked with a 24 core box on windows :-) [13:28] C:\consulting\rakudo>perl6-m -e "say (0 ^^ ^7).WHAT" [13:28] (Range) [13:28] m: say (0 ^^ ^7).WHAT [13:28] rakudo-moar 4d347f: OUTPUT«Nil␤» [13:29] Yeah. [13:29] i'm looking forward to seeing what that code-gen bug was [13:29] It was a code-gen bug. [13:29] nwc10: the more special semi commercially sponsored versions of languages appear (Hack, Dart?) the better ... it will make everyone will like perl more :-) [13:30] nqp: b733404 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp: [13:30] nqp: Fix multiple reg alloc bugs in xor. [13:30] nqp: [13:30] nqp: Managed to get lifetimes wrong AND double-release in some cases. [13:30] nqp: review: https://github.com/perl6/nqp/commit/b73340485b [13:30] because perl6 is not comercially sponsored, people won't say "facebook/google/microsoft/the NSA/... is evil! i'm not using this language!" [13:31] people don't say that, actually. Just look at go. Terrible language design, thousands of users because "GOOGLE" :) [13:31] nor NASA, these days [13:31] "terrible language design"? [13:31] a friend of mine says it's more pythonic than python [13:31] or "said" [13:31] or something [13:32] nwc10: NASA doesn't have any mony left over to buy soft toilet paper ... [13:32] lizmat: b733404 should deal with RT#122448 [13:32] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122448 [13:32] timotimo: I could repeat all my points here if you want, but basically: language that'd have been considered poor even in the 70s [13:32] I'm not sure that JS->Dart is going to win better than PHP $n+1 > Hack [13:32] because there are several fast JS implementations, only one of which also does Dart [13:33] jnthn: will try in a bit [13:33] but the largest user of PHP seems to be planning a move from PHP to Hack, and providing a VM, and publishing the PHP spec [13:33] lizmat: OK. I seem to recall there was another regression but don't see it in my spectest run? [13:33] nwc10: the largest user of PHP ? [13:33] lizmat: Also I didn't see RT#122448 causing a fail; was it fudged? [13:33] they're like, what, 0.00001% usage of PHP ? [13:33] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=122448 [13:33] timotimo: http://perl5.git.perl.org/perl.git/blobdiff/fd7895cf8ded27bc2c1cddf7c72c17d6bdc95df0..24f4b7da:/pod/perlfunc.pod [13:34] jnthn: S06-routine-modifiers/lvalue-subroutines.t , tests 10 and 11, just fudged [13:34] Ven: OK, 80% of stats are made up. But I suspect by page views, they are largest [13:34] They probably are, yes, considering google is running c++ [13:35] nwc10: oh, interesting! [13:35] lizmat: OK. Turns out they still fail. So, unrelated to that RT after all [13:35] :-( [13:35] timotimo: when Larry was explaining, creased up, because he immediately got the "kybble" pun. [13:36] fingers [13:36] Pm creased up [13:36] ah [13:36] jnthn: fwiw, that pb *also* went away with --optimize < 2 [13:36] so maybe that *is* an optimizer issue [13:36] lizmat: could very well be that it just had something to do with what registers were used by what other stuff at that time [13:37] as the param to the sub, becomes Mu inside the FETCH [13:37] oh, that's for that thing [13:37] lizmat: Yes, maybe ;) [13:37] https://gist.github.com/lizmat/8d04b65573200ec70f08 # for a golf [13:38] *** akaseki left [13:38] *** akaseki joined [13:40] *** fhelmberger left [13:41] oh wtf [13:41] it inlines checklastval [13:41] As in, at Perl 6 level [13:42] That shouldn't even get inline_info set [13:43] How do I reference an individual multi sub right now? [13:43] The docs say I can use &foo:(Int) or so, but that doesn't seem to work. [13:43] &proto.candidates[0] [13:43] ah [13:43] thanks [13:43] I don't think there's syntactic sugar yet [13:43] jnthn: you asked me to remind you that we should do something about for + the .. operators having the operator itself inlined, thus preventing the for->loop optimization [13:44] is .candidates in order of declaration? [13:44] Either just by assigning it to something so you can reference it, or ...what moritz said but that may be fagile given the index reliance... or there's a method on Routine, iirc. Something like cando [13:44] And you give it the args and it gives you back the candidate(s) that would be satisfied by them. [13:44] candodats? [13:45] timotimo: ;-) [13:45] how do you spell that? doodads? [13:46] jnthn: if we actually made the optimizer smart enough to recognize the Range.new stuff after the inline, that'd give us the same optimization for other custom operators and subs that return ranges ... [13:46] not sure if it'd be worth it [13:47] PerlJam: It's called .cando and you pass it a Capture that's an example of the args. [13:48] *** nhayashi left [13:49] *** kurahaupo_ left [13:49] *** iarna joined [13:49] lizmat: Got a fix here for that one too [13:49] *** nhayashi joined [13:50] *** rurban left [13:50] cool! [13:50] The static inliner can actually do better thanks to the sink changes [13:51] However, doing better in this case exposed a missing bit of "can we" analysis :) [13:52] *** rurban joined [13:53] *** iarna left [13:54] *** iarna joined [13:55] can we ever throw away the decontrv from an inlined function? [13:55] the simpler the qast tree, the nicer it is, but what do i know [13:56] Not trivially [13:56] Spesh may be in a better place to throw those away [13:56] rakudo/nom: a8c752b | jnthn++ | src/Perl6/Actions.nqp: [13:56] rakudo/nom: Things with nested blocks are not inlinable. [13:56] rakudo/nom: [13:56] rakudo/nom: There are ways to have nested blocks without a declaration being made; [13:56] rakudo/nom: anonymous subs and thunks are just two examples. This fixes an lvalue [13:56] mhm [13:56] rakudo/nom: subs regression. [13:56] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a8c752b291 [13:57] And I think spesh *does* throw some of them away already. [13:57] *** rurban left [13:57] probably does, yeah [13:57] that's way too late for our for+range optimization to kick in, though ;) [13:57] Oh, I think that's just an example of the classic phase-order problem [14:05] yeah, but at the point when spesh runs, we don't have the qast any more - or at least shouldn't ... would probably waste a lot of memory we can only very rarely benefit from [14:08] rakudo/nom: 69eb2f8 | jnthn++ | src/Perl6/Optimizer.nqp: [14:08] rakudo/nom: Re-order to restore for 1..1000 {} optimization. [14:08] rakudo/nom: [14:08] rakudo/nom: More inlining possibilities led to 1..1000 style things being turned [14:08] rakudo/nom: into code no longer recognized as a loop over a range, so we lost the [14:08] rakudo/nom: optimization. Move it to before any inlining attempts are made. [14:08] rakudo/nom: timotimo++ for spotting this optimization regression. [14:08] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/69eb2f84a5 [14:09] *** chenryn left [14:10] Rakudo, nqp and moar insist on installing into the same directory. [14:10] that is correct. [14:11] It is marginally frustrating. [14:11] you are welcome to make the build system more flexible, but that will also be "marginally" frustrating [14:11] *** thou joined [14:11] Mostly because I already picked what ended up being the wrnog directory name. [14:11] ChoHag: is your frustration because of compiled versions ? [14:12] *** chenryn joined [14:12] *** rurban joined [14:12] because I'm close to finishing the Foo.moarvm -> Foo.pm.moarvm transition [14:13] It's frustrating because my ~/pkg directory is now a tiny bit more disorganised. [14:14] bbi30, err& [14:14] oh, you meant *that* with the phase-order-problem thing! [14:15] *** zakharyas joined [14:15] To be fair, I'm not following anything remotely like a build doc, if one even exists. [14:16] Just running random code with names like 'Configure.pl' and 'Makefile'. [14:18] I see that whatever broke rakudo this morning got fixed. [14:18] *** treehug88 joined [14:19] ChoHag: indeed, it needed an NQP / MOAR version bump [14:19] That was helpfully discovered just as I was packing my laptop up - now without a working executable - ready to commute and enjoy the only period of hacking available. [14:19] Or not. [14:19] the joys of running bleeding edge [14:19] ;( [14:20] using perl6-bench with its extract + build thing is helpful for this kind of deal, because you have different rakudo versions in different folders [14:20] git++ [14:20] all you need to do is supply the absolute path to perl6 or nqp-* [14:20] git reset --hard HEAD^, though my battery took quite a beating. [14:21] Woo! Readline! [14:21] oh! [14:22] the commute/hacking period already happened [14:22] The first of the day. [14:22] The second is less useful as I'm hot and tired. [14:22] ~20 minute walk almost exactly west, into the sun. [14:23] Anyway it prompted me to finally build the rakudo components individually, so there's that. [14:24] Does Panda have any support for keeping modules updated? [14:24] Is there even any way to check? Or is it basically a glorified wget and I'm on my own? [14:24] when you ./rebootstrap, it'll delete and re-install existing modules, that will give you an update, too [14:24] i think you can panda update + panda status or list or something [14:27] if you reinstall an already installed module it will get updated :) [14:27] it would be an LHF to implement something like "update everything" [14:27] Well rebootstrap seems to work fine. [14:28] yeah, that also updated panda itself :) [14:28] in such a wait that things don't blow up [14:28] usually [14:29] With apparent success. [14:29] Which means the debugger works again. [14:29] And is probably still useless due to lacking thread support... :( [14:29] very good [14:30] yeah, that's not terribly easy. though with our gtk binding we could do something there [14:30] *** anaeem1 joined [14:32] *** pmurias joined [14:32] roast/S26-WHY: 9db0738 | duff++ | S26-documentation/why-leading.t: [14:32] roast/S26-WHY: Add leading tests for proto and multi subs [14:32] roast/S26-WHY: review: https://github.com/perl6/roast/commit/9db0738f9a [14:33] if someone has an idea how to write automated tests for the debugger, that would be fantastic ... [14:35] *** kaleem left [14:36] *** kaleem joined [14:37] *** molaf_ joined [14:37] *** iarna left [14:39] *** colomon left [14:39] *** molaf left [14:48] * jnthn back [14:50] * Ven front [14:50] * masak activates the crushing device [14:50] clear! [14:52] so asplodation [14:52] timotimo: idea for writing automated tests for the debugger: make it a "brain in a vat", basically a stateful thing that *thinks* it's hooked up to a CLI and a runtime -- but those two are injected, and can be replaced by whatever for testing purposes. [14:52] masak: you're ready for consequences, then :P ? [14:53] Note that the debugger was written to accept multiple frontends [14:53] i was about to point that out [14:53] even better. [14:53] but testing the frontend would be interesting, too [14:53] You could probably write a frontend that subscribes to all the same hooks and just emits ok [14:54] Well, most of the bugs we saw so far would have been demonstrated by tests that make sure they get the expected hooks called, I think. [14:54] hmm, probably [14:58] *** BenGoldberg joined [15:02] *** kst`` is now known as kst [15:04] *** kaleem left [15:04] *** takesako left [15:05] The Warsaw Uprising started exactly 70 years ago today [15:05] the sirens and car honks went off in the entire city, it gave me goosebumps [15:05] jnthn: nom HEAD expodes spectests [15:06] tadzik: you're more than 70 years old? ;) [15:06] no, I'm not :) [15:06] nom^ happy [15:06] I mean they did today, just now [15:06] Warsaw++ # uprisingest city I know [15:08] *** BenGoldberg left [15:09] nwc10: Yeah, somehow exception reporting got busted [15:09] *** BenGoldberg joined [15:10] *** denis_boyun left [15:12] <[Coke]> when developing perl6.org, is there a faster way to get from editing source to viewing the edit? it takes minutes to run mowyw here. [15:13] is mowyw written in perl6? %) [15:13] <[Coke]> nope. p5. [15:13] that's supposed to be the fast one! [15:15] <[Coke]> can perl6.org support something like a mojo app, or does it have to be static at this point? [15:15] <[Coke]> if I edit index.html, it takes 1m38s to run mowyw before I can see the edit. [15:16] <[Coke]> that makes updating the site a non starter. [15:17] holy yikes. [15:17] *** takesako joined [15:18] [Coke]: Maybe encourage the author to use Devel::NYTProf or something ;) [15:18] *** ventica joined [15:19] rakudo/nom: b1ebf77 | jnthn++ | src/Perl6/Optimizer.nqp: [15:19] rakudo/nom: Forgot to visit children after range opt. [15:19] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b1ebf77994 [15:20] *** kaleem joined [15:21] [Coke]: heh, my blog is faster than that. [15:22] who's duff? duff++ for helping with S26 stuff [15:22] hoelzro: that's me. [15:22] PerlJam++ [15:22] rakudo/nom: 5e3434b | (Elizabeth Mattijsen)++ | tools/build/Makefile- (3 files): [15:22] rakudo/nom: Make sure we precompile core modules with extension [15:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5e3434b85a [15:22] rakudo/nom: 9fd23d0 | (Elizabeth Mattijsen)++ | src/core/CompUnitRepo.pm: [15:22] rakudo/nom: Temp fix supporting loading .pm6 files as source [15:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9fd23d025d [15:22] rakudo/nom: 8bada16 | (Elizabeth Mattijsen)++ | src/core/CompUnit (2 files): [15:22] rakudo/nom: Almost complete refactor CompUnit and CURL::File [15:22] rakudo/nom: [15:22] rakudo/nom: A CompUnit object now has always the source file as its "path", even if the [15:22] rakudo/nom: source file cannot be found. [15:22] rakudo/nom: [15:22] rakudo/nom: CURL::File has been utterly simplified, as it turned to be impossible to [15:22] rakudo/nom: smartmatch finding files. So now it only looks for the existence of the [15:22] rakudo/nom: file, and returns that. Thanks to Scalar[0] indexing, this is compatible [15:22] rakudo/nom: with the API. [15:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8bada1604b [15:23] please note that these changes require a re-running of the Configure.pl [15:23] tadzik: I want to adapt Bailador to work with sergot++'s ned HTTP:: classes. any complaints? I'll PR ya. [15:23] timotimo: Did anyone explain flame charts yet? (Sadly, this is my first chance back at this keyboard.) [15:24] What's the repo for the p6 benchmarks? [15:24] now I'm really glad I switched to that $=pod[$pod_index++] idea! [15:24] If not, here are a couple uses: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html and http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-flame-chart [15:24] found it [15:24] pmurias: not in p6 iirc [15:24] japhb o/ [15:24] pmurias: Are you talking about perl6-bench? [15:24] tadzik: also, I feel like writing some more tests. [15:24] lizmat: o/ :-) [15:24] (I mean not in the perl6 org) [15:24] japhb: does it support nqp? [15:25] pmurias: of course [15:26] Some tests don't apply to NQP, of course, because they test things like general 'for' loops, but yeah, most tests include an NQP version -- and the tools will automatically work around any missing ones by default. [15:26] *** ventica left [15:26] *** iarna joined [15:26] japhb: and how to I specify which nqp backend to build? [15:27] ahh I see [15:28] japhb: the README is outdated as it should be nqp-parrot instead of nqp? [15:28] Yes, that's probably true. Feel free to submit a PR. :-) [15:28] in CHECKOUTS [15:29] *** Ven left [15:30] TBH it's fairly likely there's rot in variants other than *-moar and *-jvm, as those have been tested most recently by multiple people. I think jnthn tested *-parrot last month, but he was already working around some minor Windows incompatibilities. [15:30] *** kaleem left [15:30] * japhb stands with arms akimbo in mock sternness [15:31] ... And where are those patches, jnthn, hmmm? ;-) [15:31] (Of course, I'd rather have the ones that actually make the compiler faster, but you know, one has to give him a hard time about *something*.) [15:32] *** kaleem joined [15:33] *** dayangkun_ left [15:33] japhb: i ran parrot, jvm and moar yesterday [15:33] with both nqp and rakudo [15:33] \o/ [15:34] Oh duh, yes, you sent me a link to the three backends. OK, at least all of the "standard" NQP/Rakudo variants work fine then, plus Perl 5. I doubt anyone's tested niecza or nqp-js or such recently, though. [15:35] that's correct [15:35] and my rakudo-moar-jit and nqp-moar-jit variants don't quite work just yet, i think [15:35] (apart from not providing any benefits to the benchmarked code yet) [15:42] *** dmol joined [15:43] *** kaleem left [15:45] roast: 0122f77 | (Elizabeth Mattijsen)++ | S06-routine-modifiers/lvalue-subroutines.t: [15:45] roast: Unfudge now passing lvalue sub tests [15:45] roast: review: https://github.com/perl6/roast/commit/0122f77bcc [15:47] *** anaeem1 left [15:47] *** anaeem1 joined [15:48] *** [Sno] left [15:49] It's amazing how much faster morning traffic moves on a Friday. [15:50] it's all the googleys doing they're 20% day in bed :) [15:51] *their [15:52] *** anaeem1 left [15:52] I fully support that. [15:53] .oO( For my 20% project, I'm researching the effects of significantly more rest per week on the other 80%.) [15:53] *** denis_boyun_ joined [15:54] +1 [16:04] *** ventica joined [16:05] *** treehug88 left [16:05] *** cooper_ joined [16:09] rakudo/nom: 1130554 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION: [16:09] rakudo/nom: Bump NQP to get short-circuit fix [16:09] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/11305543e5 [16:10] roast: 31c3fd1 | (Elizabeth Mattijsen)++ | S03-operators/short-circuit.t: [16:10] roast: Unfudge now passing test [16:10] roast: review: https://github.com/perl6/roast/commit/31c3fd1f92 [16:13] *** Rotwang joined [16:18] *** cooper- joined [16:19] *** chenryn left [16:21] *** zakharyas left [16:25] rakudo/nom: d40cc63 | (Elizabeth Mattijsen)++ | src/core/CompUnitRepo/Local/File.pm: [16:25] rakudo/nom: Make sure we spot a compiled file if source absent [16:25] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d40cc63f0a [16:26] roast: c0e28b3 | (Elizabeth Mattijsen)++ | S10-packages/precompilation.t: [16:26] roast: Remove removed named parameter :no-precomp [16:26] roast: review: https://github.com/perl6/roast/commit/c0e28b3393 [16:26] roast: 26d1dda | (Elizabeth Mattijsen)++ | S22-package-format/local.t: [16:26] roast: Bring CURL::F tests up-to-date [16:26] roast: review: https://github.com/perl6/roast/commit/26d1ddacc9 [16:37] *** takesako left [16:38] *** cognome_ left [16:38] *** cognominal left [16:39] *** cognome joined [16:39] *** virtualsue left [16:41] *** pecastro left [16:43] *** cognome left [16:45] *** cognominal joined [16:45] *** cognome joined [16:47] *** gfldex joined [16:52] *** takesako joined [17:05] hmm, compiling nom/master/master for all three backends, got: make: *** No rule to make target `lib/Test.pm.pir', needed by `p-all'. Stop. [17:06] * masak .oO( "Need more money. Stop. Send it by your earliest convenience. Stop." ) [17:08] *** FROGGS joined [17:08] *** dakkar left [17:08] o/ [17:24] FROGGS: o/ [17:28] rakudo/nom: 085ab95 | TimToady++ | tools/build/Makefile-Parrot.in: [17:28] rakudo/nom: missing deps: Test.pir -> Test.pm.pir, etc. [17:28] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/085ab95eea [17:31] rakudo-star-daily: 48ae70a | coke++ | log/ (14 files): [17:31] rakudo-star-daily: today (automated commit) [17:31] rakudo-star-daily: review: https://github.com/coke/rakudo-star-daily/commit/48ae70a021 [17:31] perl6-roast-data: 8552de2 | coke++ | / (5 files): [17:31] perl6-roast-data: today (automated commit) [17:31] perl6-roast-data: review: https://github.com/coke/perl6-roast-data/commit/8552de2e50 [17:32] *** [Sno] joined [17:32] *** colomon joined [17:32] FROGGS: up above btyler talked about a JSON module they made ... [17:33] :-) [17:33] will backlog in a bit :o) [17:33] WIP still :) but maybe useful if you need to chew through a great deal of JSON rapidly and pull data out [17:33] just a nativecall binding, nothing fancy [17:45] p6: say 1/2 R** 3 [17:45] rakudo-{parrot,jvm,moar} 69eb2f, niecza v24-109-g48a8de3: OUTPUT«0.111111␤» [17:46] * grondilu thought that meant 3**(1/2) since the R metaoperator reduces precedence [17:46] p6: say 3**(1/2) [17:46] rakudo-jvm 69eb2f, niecza v24-109-g48a8de3: OUTPUT«1.7320508075688772␤» [17:46] ..rakudo-{parrot,moar} 69eb2f: OUTPUT«1.73205080756888␤» [17:51] grondilu: precedence. [17:52] R does not reduce precedence, that I know of [17:52] p6: say 1/(2 R** 3) [17:52] rakudo-{parrot,jvm,moar} 69eb2f, niecza v24-109-g48a8de3: OUTPUT«0.111111␤» [17:53] grondilu: oh, R *reverses* the operands [17:53] p6: say: 1 + 1 R* 3 [17:53] S03:4163 [17:53] Link: http://perlcabal.org/syn/S03.html#line_4163 [17:53] rakudo-{parrot,jvm,moar} 69eb2f, niecza v24-109-g48a8de3: ( no output ) [17:53] p6: say 1 + 1 R* 3 [17:53] rakudo-{parrot,jvm,moar} 69eb2f, niecza v24-109-g48a8de3: OUTPUT«4␤» [17:53] I have a problem bootstrapping panda with my last rakudo-moar build (based on most recent nom rakudo) https://gist.github.com/cognominal/a123a23cdb46d4a2eae4 [17:53] grondilu: only the list infixes reduce precedence [17:54] hypers and scalar metaops do not [17:54] does someone has the same problem? [17:54] I don't know where I got this idea then. Nevermind. [17:55] overgeneralized from X and Z, I suppose [17:55] yeah probably [17:56] assignops also change precedence [17:57] m: my $_ = 40; $_ += 0 && 2; .say [17:57] rakudo-moar 69eb2f: OUTPUT«Potential difficulties:␤ Redeclaration of symbol $_␤ at /tmp/Jv161Z6Sm_:1␤ ------> my $_ ⏏= 40; $_ += 0 && 2; .say␤40␤» [17:58] $_ = 40; $_ += 0 || 2; .say [17:58] m: $_ = 40; $_ += 0 || 2; .say [17:58] rakudo-moar 69eb2f: OUTPUT«42␤» [17:58] m: $_ = 40; $_ = 0 || 2; .say [17:58] rakudo-moar 69eb2f: OUTPUT«2␤» [17:58] ok [18:01] so, assignops are listops? [18:05] not necessarily, see S03:4078 [18:05] Link: http://perlcabal.org/syn/S03.html#line_4078 [18:06] TimToady: ah, yes. makes sense. [18:07] TimToady: how does Z= know it's [Z]= and not Z[=] ? [18:08] it kinda doesn't matter [18:10] <[Coke]> daily failures: n: 1385; j: 47; m: 2; p: 1715 [18:11] but basically Z looks for the = first in infix_prefix_meta_operator:sym [18:12] assignment = is only looked for once we're happy we otherwise have an infix [18:12] it's not quite LTM, but just ordered alternatives at that point [18:13] infixish controls all the action [18:16] well, alternative in the sense that []? gives you '' or '=' at that point, after parsing the base infix [18:24] jnthn, my problem persists with fresh clones of panda and rakudo [18:24] *** denis_boyun_ left [18:25] The error is coming from the ModuleLoader [18:31] *** Rotwang left [18:31] *** Rotwang joined [18:36] *** sqirrel joined [18:43] *** sqirrel left [18:43] *** takesako left [18:45] cognominal: looks like there were changes how precompiled modules are looked up [18:45] cognominal: I have the same problem with v5 :/ [18:46] ok, so I am not hallucinating. [18:47] cognominal: it looks like the files are called now .pm.moarvm for example: https://github.com/rakudo/rakudo/commit/5e3434b85a6544b323a7004450caa66723ca26e7 [18:48] which makes sense but is slightly surprising :o) [18:48] so panda needs a tweak, should be fairly simple though [18:48] that makes sense [18:48] does perl6 have the concept of "baby perl" or does it require at least toddler level babbling [18:53] gtodd, It also supports the concept of senile Perl; meaning old timers can still use sigiless routines shitfing @_ :) May also please people having done to much PostScript of FORTH too. [18:54] s/sigiless/signature-less/ [18:55] more seriously, that means it goes out of its way ro support people who want to convert perl5 code. [18:58] *** takesako joined [19:04] gtodd my experience is like the type system the babyness is progressive [19:04] .oO( progressive babyism? ) [19:08] gtodd: yes, I feel that the concept of baby Perl 6 is there and is relevant. [19:09] I understand baby perl as the fact you can get away by knowing a small subset so you can learn as you go. This is still true of Perl 6. A typical counter example of an otherwise good language is haskell who asks you to learn esoteric concept like monad. [19:09] s/who/that/ [19:09] haskell doesn't ask you to learn about monads right away ... [19:09] just if you want to do "interesting" things :) [19:10] good because I am a baby :-) [19:10] *** eternaleye joined [19:11] e.g. I can't write Grammars :-\ .. but I'm going to try ... [19:11] Util: very good point [19:11] it's "strongly typed" but you have to ask nicely [19:13] *** darutoko left [19:14] cognominal: for a new non backwards compatible language it is pretty helpful ... [19:14] *** ventica left [19:15] anyway it has best IRC channel on the interwebs so ... that is huge :-) [19:15] #perl6 ++ [19:15] thanks for being nice :) [19:15] hugme: hug gtodd [19:15] * hugme hugs gtodd [19:16] <[Coke]> .u ∿ [19:16] U+223F SINE WAVE [Sm] (∿) [19:16] <[Coke]> .u COSINE [19:16] No characters found [19:16] <[Coke]> .u COS [19:16] No characters found [19:16] <[Coke]> aww. [19:16] jnthn: about that commit, I have no idea when to release registers... https://github.com/perl6/nqp/commit/b73340485b8ebdf4f62df872cdf8082bf3d05450 [19:17] FROGGS: as soon as you can be sure that the resulting code is free to write over the register [19:17] with potentially bogus values [19:17] FROGGS: After you've produced all the code that's going to be using them. [19:20] *** aoseki joined [19:21] *** dwarring joined [19:23] *** akaseki left [19:26] *** FROGGS left [19:29] *** ventica joined [19:30] *** Sqirrel joined [19:30] *** gtodd left [19:30] *** gtodd joined [19:30] tnx for the hugs o/ [19:31] have good weekends all [19:31] *** gtodd left [19:32] *** FROGGS joined [19:34] *** rurban left [19:37] <[Coke]> jnthn: did you open a ticket for the "can't build nqp-p" somewhere? I remember seeing it on channel... [19:38] nqp: aa8a615 | jnthn++ | src/QAST/Block.nqp: [19:38] nqp: Small optimizations to .symbol. [19:38] nqp: review: https://github.com/perl6/nqp/commit/aa8a6153f8 [19:38] nqp: c3f29b6 | jnthn++ | t/qast/01-qast.t: [19:38] nqp: Bring test in line with behavior change. [19:38] nqp: review: https://github.com/perl6/nqp/commit/c3f29b6e7e [19:38] [Coke]: No, didn't do so yet [19:39] [Coke]: I should probably try it on my laptop too, to rule out anything weird on this box... [19:41] <[Coke]> jnthn++ [19:44] <[Coke]> Configure.pl's --help points at --git-protocol, but specifying ssh or git doesn't seem to change the "unable to access" error message. [19:46] *** iarna left [19:54] *** akaseki joined [19:54] <[Coke]> ... because I did it without protocol once, and that version got "stuck". arglebargle. [19:55] *** aoseki left [19:55] <[Coke]> moritz++ # adding git-protocol [19:55] *** gtodd joined [19:59] errm .. http://codegolf.stackexchange.com/a/35323/20338 couldn't read learn anymore in time to improve this ... suggestions welcome in the comments [19:59] cheers [20:02] *** rurban joined [20:05] *** eternaleye left [20:10] *** rindolf left [20:10] *** rindolf joined [20:10] *** kurahaupo_ joined [20:12] *** rurban left [20:14] <[Coke]> .tell moritz: fyi, --git-protocol doesn't look like it's passed down to nqp, so nqp tries the default https:// [20:14] [Coke]: What kind of a name is "moritz:"?! [20:14] <[Coke]> .tell moritz fyi, --git-protocol doesn't look like it's passed down to nqp, so nqp tries the default https:// [20:14] [Coke]: I'll pass your message to moritz. [20:14] <[Coke]> yoleaux: urdumb. [20:15] *** eternaleye joined [20:24] *** rurban joined [20:31] hugme: hug yoleaux [20:31] * hugme hugs yoleaux [20:32] yoleaux: what kind of name is 'yoleaux'?! ;) [20:35] .tell yoleaux what kind of name is yoleaux? [20:35] carlin: Thanks for the message. [20:35] oi, that's cheating [20:36] <[Coke]> yoleaux sounds like YOLO [20:36] TimToady++ for fixing my omission [20:37] * carlin pronounces it yoll-awks [20:37] .oO( and it's yellow on my screen... ) [20:39] especially the bit about .comb ulp ... sorry TimToady ;-) ... (oh and the whole thing fails if there's an empty line in the script ...) someone enter their own s [20:39] *** gtodd left [20:53] *** pecastro joined [20:55] *** iarna joined [21:07] *** zakharyas joined [21:07] *** pippo joined [21:09] *** akaseki left [21:09] *** pippo left [21:10] *** pippo joined [21:10] o/ #perl6. [21:10] \o [21:10] I am trying to compile latest perl6-j. But have the following error: [21:10] Error while reading from file: java.nio.charset.MalformedInputException: Input length = 1 [21:11] Anybody could help? [21:13] at what point does that happen? [21:16] *** pmurias left [21:16] maybe gist us a make dump? [21:17] *** zakharyas left [21:17] * lizmat wonders whether it would make sanse to have a "is COMPILE_TIME_ERROR" attribute for Routine [21:17] timotimo: java -Xss1m -Xms500m -Xmx1000m -Xbootclasspath/a:.:/temp/gnomeforge/rakudo/install/languages/nqp/runtime/asm-4.1.jar:/temp/gnomeforge/rakudo/install/languages/nqp/runtime/asm-tree-4.1.jar:/temp/gnomeforge/rakudo/install/languages/nqp/runtime/jline-1.0.jar:/temp/gnomeforge/rakudo/install/languages/nqp/runtime/jna.jar:/temp/gnomeforge/rakudo/install/languages/nqp/runtime/nqp-runtime.jar:/temp/gnomeforge/rakudo/install/languages/nqp/lib/nqp.ja [21:18] pippo: that command got cut off [21:18] any MMD candidate marked that way, would cause the optimizer to throw a compile time error when it finds that that candidate is about to be selected [21:18] lizmat: interesting idea. [21:18] simply by executing that routine [21:18] use case: [21:19] and when it's hit at run time, it also throws that error, but it would be too late :( [21:19] multi sub say () { exception('Unsupported use of bare 'say'; in Perl 6 please use .say if you meant $_, or use an explicit invocant or argument' } [21:19] That one is meant to be syntactic, I think... [21:19] lizmat: but that... what jnthn said. [21:19] I know [21:19] but if it happens at compile time, that wouldn't make too much difference ? [21:20] I worry a bit 'cus there's just a handful of cases when things are compile-time resolved. [21:20] the point is what happens if you pass in an empty list. [21:20] (which should not fail with an error) [21:20] pass an empty list or flatten in an empty list? [21:21] timotimo: https://gist.github.com/anonymous/7d519d9c44939f8bc12b [21:21] timotimo: the latter, I guess. [21:22] r: multi a () { say "none" }; multi a ($a) { say $a }; a; a(); my @a; a(@a) [21:23] *** btyler joined [21:23] rakudo-jvm 085ab9: OUTPUT«(timeout)» [21:23] ..rakudo-{parrot,moar} 085ab9: OUTPUT«none␤none␤␤» [21:23] flattening into an empty list seems to not select the () candidate [21:23] | [21:23] r: multi a () { say "none" }; multi a ($a) { say $a }; my @a; a(|@a) [21:23] rakudo-{parrot,jvm,moar} 085ab9: OUTPUT«none␤» [21:23] pippo: can you check if any of the files it would want to touch are way too small? [21:26] timotimo: do not know which files it wants to touch. Those listed after java -Xss1m -Xms500m -Xmx1000m -Xbootclasspath ?? [21:26] dunno. use "find" to find the smallest files? [21:26] maybe during the build something got corrupted? [21:27] timotimo: I have completely wiped out my git clone. And restarded from scratch. Same error. [21:27] i'm going to try it myself now. [21:27] timotimo: on my 32 bits machine though there is no problem. Strange. [21:28] How big is gen/jvm/CORE.setting ? [21:28] it's weird that the commandline has --ll-exception, but doesn't give a stack trace at all [21:28] kind of seems like it happens before any of our "own" code is hit? [21:29] Yes [21:29] It's at the point where it reads in the source file, iirc [21:29] rakudo/nom: b8e660f | (Elizabeth Mattijsen)++ | src/core/ (2 files): [21:29] rakudo/nom: Disallow @*INC entries to be list of CUR's [21:29] rakudo/nom: [21:29] rakudo/nom: As discussed with FROGGS a few weeks ago already. BTW, this appears to have a [21:29] rakudo/nom: great effect on startup time, judging from CPU usage in spectest. [21:29] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b8e660fe0a [21:29] So it's failing extremely early [21:29] Files=908, Tests=31827, 212 wallclock secs ( 8.95 usr 3.92 sys + 1314.99 cusr 171.08 csys = 1498.94 CPU) [21:29] first time < 1500 CPU seconds for me [21:29] lizmat++ [21:30] \o/ [21:30] Yes, we regressed a bit on startup time in the last months [21:30] Partly due to doing too much work in CORE.setting loading. I guess that's addressed in this patch. [21:30] I'm currently working on trying to address some of the lower level reasons. [21:31] *** dmol left [21:31] jnthn: almost 700k (693019) [21:31] (Basically, a lot of things grow O(setting size) rather than O(stuff used in setting) [21:31] pippo: OK, seems well formed [21:32] perhaps my java installation is broken. I'll try re-installing... [21:33] unlikely if you made it this far? [21:33] Yeah... [21:33] I'm doubting it's busted Java install [21:33] I built JVM a day or two ago and it was OK [21:33] I've built JVM today without any pb [21:34] I mean openJDK [21:35] I mean openJDK installation is broken. Perhaps... [21:35] that's how i understood it [21:36] Oh. Sorry. Then I do not know. Anyway I do not want to make all of you loose too much time on this. I have moar running and it is OK for me. [21:36] btw: thank you all. [21:39] *** rurban left [21:40] *** ventica left [21:43] "I've built JVM today without any pb" [21:44] anyway, my idea for the routine attribute came from reading http://irclog.perlgeek.de/perl6/2014-07-23#i_9068589 [21:44] * hoelzro .oO( peanut butter? ) [21:44] problem [21:44] pointy block. [21:44] tablets: a35cb86 | (Herbert Breunung)++ | docs/appendix- (2 files): [21:44] tablets: terms class and callframe [21:44] tablets: review: https://github.com/perl6/tablets/commit/a35cb86eaa [21:44] S99:762 [21:44] Link: http://perlcabal.org/syn/S99.html#line_762 [21:44] I figured ;) [21:54] I think I found the source of some of the flapping tests: [21:54] multi sub infix:(Any $a, Any $b) { $a.WHICH eq $b.WHICH } [21:54] Grr, yes [21:54] o.O [21:54] * jnthn should really put that on his "stuff to do this month" list... [21:55] (the .WHICH bug) [21:55] reason is flapping in t/spec/S32-list/combinations.t [21:55] *** rurban joined [21:55] which is basically only eqv tests [21:56] jnthn: after you fix it, we can all sing "ding dong, the wicked .WHICH bug is dead!" [21:56] :P [21:56] I'm not sure if that makes me want to fix it more or less :P [21:56] * masak .oO( fewer ) :P [21:56] this is probably horribly naive, but what's wrong with that code (other than the fact that it should probably be using == instead of eq)? [21:57] hoelzro: .WHICH is...uh...a bit special at present. [21:57] hoelzro: On reference types, anyways [21:58] I'm guessing (perhaps wrongfully) that it's implemented as hashCode on the JVM? [21:58] Yeah, and memory address on Moar :) [21:58] And objects move [22:00] ah ha [22:00] that makes sense [22:00] no it doesn't :P [22:01] rakudo/nom: fb05219 | (Elizabeth Mattijsen)++ | src/core/List.pm: [22:01] rakudo/nom: Don't do expensive setup for sort if not needed [22:01] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/fb05219ee0 [22:01] Well, objects moving makes sense. .WHICH being based on a changing memory address, less so :) [22:02] Objects moving is why Moar can throw all your short-lived crap out cheaply :) [22:02] *** telex left [22:02] good night #perl6! [22:02] *** pippo left [22:03] *** eternaleye left [22:03] *** lustlife left [22:04] *** eternaleye joined [22:04] *** telex joined [22:06] 'night, #perl6 [22:07] night masak [22:07] *** gfldex left [22:08] *** eternaleye left [22:09] gnight masak [22:10] timotimo: re http://irclog.perlgeek.de/perl6/2014-07-23#i_9068759 , I'm al for banning of direct access to @*INC [22:10] *all [22:10] but what is your reason ? [22:12] *** eternaleye joined [22:13] because we have "use lib" :) [22:13] regexp.h: regnode program[1]; /* Unwarranted chumminess with compiler. */ [22:13] ah, so no optimization issues / reasno ? [22:14] *reason [22:14] I guess in some senses "use lib" is less flexible [22:14] not that i can think of [22:14] You don't get to meddle with ordering [22:15] And use lib depends on being able to fiddle with @*INC... [22:18] *** kivutar left [22:19] * TimToady doesn't think mutable semantics in prerequisites should be forced on anyone who wants immutble semantics... [22:19] well, there is one *big* problem with use lib at the moment [22:19] it is not lexical [22:19] whereas you can say: [22:20] m: { use Test }; ok 1 # fails because the export was lexical [22:20] rakudo-moar 085ab9: OUTPUT«===SORRY!=== Error while compiling /tmp/4Pe4072erv␤Undeclared routine:␤ ok used at line 1. Did you mean 'on'?␤␤» [22:20] you cannot do that with 'use lib': [22:21] well, that just seems like a bug [22:21] m: BEGIN say @*INC.elems; { use lib "." }; BEGIN say @*INC.elems [22:21] rakudo-moar 085ab9: OUTPUT«2␤3␤» [22:22] *** nbrown joined [22:22] well, there are many tests depending on the current behaviour [22:23] well, those just seem like bugs :) [22:23] and probably darkpan6 code out there [22:23] so we need to fix this sooner rather than later [22:23] however, I have no idea to fix this [22:23] suggestions welcome :-) [22:24] you derive a new language that has those policies, which can callsame into parent language's policies [22:25] but any policy that changes the current language ought be lexically scoped, if at all possible [22:25] including the policy that you'll allow accidental genericity via mutable search paths [22:26] TimToady: are you particularly attached to @*INC ? if we would lose it in favour of just having 'use lib', would that make sense ? [22:26] but that should not be the default [22:26] you will note that I never mentioned @*INC when I wrote the initial bits of S11 [22:27] indeed [22:27] and the reason I mentioned it, was to have a handle to work with [22:27] so I take it you're not attached to @*INC :-) [22:27] nope [22:27] well, neither am I :-) [22:28] I mostly wrote that there has to be an API where official library modules are considered immutable, and local development modules can be considered mutable [22:29] *** spider-mario left [22:30] I've always considered the library end of that to be more of a database query than a path search. [22:31] ok, clear, will sleep on that :-) [22:31] gnight, #perl6! [22:31] o/ [22:33] 'night, lizmat [22:51] *** nbrown left [22:52] m: say 4 * 13 [22:52] rakudo-moar fb0521: OUTPUT«52␤» [22:53] * jnthn fixes his off-by-factor-of-4 bug :) [22:57] *** dmol joined [23:00] *** rindolf left [23:05] *** Vlavv joined [23:05] *** eternaleye left [23:05] Woo, first sub-45s CORE.setting build. [23:06] *** grondilu left [23:06] Another another 4MB off base memory. [23:07] *** akaseki joined [23:07] ohh memory improvements are nice [23:07] it would be great to be able to build rakudo with only 512MB of RAM [23:11] oof, that sounds like a lofty goal still [23:12] what jnthn is doing right now (as far as i understand it) is reducing the memory it takes to run a rakudo that doesn't touch many classes/functions [23:12] yeah, but as long as it's going down and not up [23:12] since pretty much every program is going to neglect ~75% of CORE.setting's subs and methods ... :) [23:13] this specific thread of optimizations is most probably not going to help core setting compilation max memory usage much :( [23:13] *** aoseki joined [23:13] Well, it does [23:13] Because I greatly improved how static lexical handling is done. [23:13] oh! [23:13] well, *that* is good :) [23:13] Which meant I could toss a HUGE hash table and tens of thousands of MAST nodes. [23:14] ooooh [23:14] that sounds very, very nice [23:14] We're under 800MB max setting comp memory on my box now [23:14] 760MB or so was highest I saw it go [23:14] *** eternaleye joined [23:14] so we're still at 150% of what we'd like to be [23:15] *** akaseki left [23:15] Yeah. But there's more wins to be had yet. [23:15] i'm not saying no to that :)) [23:16] Also, though I'm eye-balling the Windows task manager, you can build NQP in under 128MB these days. [23:18] Setting build in under 45s on this box has been one of my small "want to get there" goals for a while. [23:19] A full Rakudo build is now 68.79s. So I guess my next goal is to be able to do a full Rakudo build in under a minute. :) [23:19] And NQP in 30s wouldn't be bad too. [23:22] at some point we're just going to compile rakudo and nqp from source every time we start up [23:22] because it'll be worth the space-time trade-off :P [23:28] nqp: 9268ba7 | jnthn++ | tools/build/MOAR_REVISION: [23:28] nqp: Bump to latest MoarVM, with many improvements. [23:28] nqp: review: https://github.com/perl6/nqp/commit/9268ba7c5c [23:28] nqp: 183e611 | jnthn++ | src/vm/moar/QAST/QAST (2 files): [23:28] nqp: Use new MoarVM static block lexicals support. [23:28] nqp: review: https://github.com/perl6/nqp/commit/183e611a0f [23:29] rakudo/nom: a1a2360 | jnthn++ | tools/build/NQP_REVISION: [23:29] rakudo/nom: Get latest NQP and MoarVM improvements. [23:29] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a1a236067b [23:30] *** nbrown joined [23:41] *** iarna left [23:42] Stage parse : 59.658 [23:42] yay, sub-minute here [23:48] (I wonder how long P5 takes compared to R*...) [23:48] takes for what task? [23:49] the configure/make/make install part :) [23:49] (actually, throw make spectest in there) [23:51] *** xenoterracide joined [23:56] jvm parse just went from 87 seconds to 65 [23:56] "jsut"? :) [23:57] moar from 34 to 31 [23:58] *** xenoterracide left [23:58] TimToady: When was the previous JVM build? [23:58] Glad we're improving across the board, though :) [23:59] oh, like this morning [23:59] or maybe last night [23:59] ah, so today's improvements :) [23:59] Well, nice :)