[06:05] *** sno joined [06:56] nqp: aa60267 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java: [06:56] nqp: Set values for iter for ContextRef [06:56] nqp: [06:56] nqp: fixes NPE with 'CallFrame.new.perl' [06:56] nqp: review: https://github.com/perl6/nqp/commit/aa60267188 [06:56] nqp: 38f2cea | niner++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java: [06:56] nqp: Merge pull request #282 from usev6/iter_ContextRef [06:56] nqp: [06:56] nqp: Set values for iter for ContextRef [06:56] nqp: review: https://github.com/perl6/nqp/commit/38f2cea9f3 [08:01] *** RabidGravy joined [08:35] should the http://design.perl6.org/S22.html#resource and all the corresponding words about %?RESOURCE be altered to reflect the actual implementation? [08:36] i'd prefer proper documentation instead i think [08:36] of course that doesn't mean it can't be altered, just that if someone was writing how it actually works it should probably be for documentation first :) [08:39] yeah I agree but I'm not sure the CUR stuff is actually clear enough in my mind [08:42] S22 was handwavy, documentation would be preferred :-) [08:45] *** brrt joined [08:47] sure but my immediate problem is that S22 says one thing, reality and is different and my module META6 follows S22 (when I first made it resources wasn't implemented so I just did what it said in the spec) [08:52] I did offer to document the CUR months ago but everyone started bike-shedding and generally being unhelpful so I forgot about it [09:35] there is a useful CUR test somewhere [09:35] except I can't find it right now [10:24] *** dalek joined [10:26] *** d4l3k_ joined [10:34] *** dalek joined [10:37] *** JimmyZ joined [10:37] *** lucs joined [10:38] *** sortiz joined [10:40] RabidGravy: yes, please correct the docs where they are wrong. That cannot hurt as we do have the git history, so nothing can be lost. Maybe keep in mind that ugexe++ has a PR that brings us closer to S22 in parts. [10:40] Okay I'll take a look at that first [10:42] got a linky to the PR, I'm only seeing one outstanding one from hoelzro for something completely different [10:42] oh I see, the PR is against rakudo [10:43] never mind :) [10:43] This one: https://github.com/rakudo/rakudo/pull/729 [10:44] %?RESOURCES is definitely going to stay. It just wouldn't be worth the disruption to rename it, even though I actually like lizmat++'s reasoning. [10:45] yeah, I'll do some metrics later, but I would say somewhere in the region of a quarter of all the modules use %?RESOURCES [10:46] fwiw, I'm ok with it being %RESOURCES :-) [10:46] but nothing in there that changes the interface as regards module authors [10:50] I'm literally only going to change the 'resources' part of S22 anyway so it corresponds to reality [10:53] but there's a whole bunch of other speculation in there that doesn't exist [10:53] Whatever you do, it will be a step forward :) [10:53] ++RabidGravy [10:55] it's purely out of self-interest as I need META6 to reflect reality to make it useful and I don't want some pedant taking issue with it differing from the spec ;-) [10:57] please adjust spec to reality [11:00] *** brrt joined [11:01] well for the time being the excludes/supersedes etc stuff stays as speculation until such time as they get implemented or ruled-out :) [11:03] I've also removed the v from the version example and made "production" a proper JSON bool [11:04] afaik, zef, panda and META6 warn about the v in the versions [12:10] *** pmurias joined [12:14] nqp: 04df939 | (Pawel Murias)++ | src/vm/js/ (3 files): [12:14] nqp: [js] If the type cache is missing call type_check. [12:14] nqp: review: https://github.com/perl6/nqp/commit/04df93988a [12:14] nqp: 73ebe45 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files): [12:14] nqp: [js] Implement serialization of P6bignum, make boxing of bignums more correct. [12:14] nqp: [12:14] nqp: Needs to be cleaned up together with a flattening cleanup. [12:14] nqp: review: https://github.com/perl6/nqp/commit/73ebe45a44 [12:15] nqp: ddf5935 | (Pawel Murias)++ | t/nqp/60-bigint.t: [12:15] nqp: Test that when boxing bignums the correct thing is in the attribute. [12:15] nqp: review: https://github.com/perl6/nqp/commit/ddf593554a [12:15] nqp: 592a959 | (Pawel Murias)++ | t/serialization/02-types.t: [12:15] nqp: Test serializing a P6bignum repr as well as a object having a P6bignum as a box_target. [12:15] nqp: review: https://github.com/perl6/nqp/commit/592a959dd7 [13:03] <[Tux]> This is Rakudo version 2016.04-74-ga16f0a4 built on MoarVM version 2016.04 [13:03] <[Tux]> test 22.740 [13:03] <[Tux]> test-t 13.655 [13:03] <[Tux]> csv-parser 35.514 [14:11] Meh...seems like I just cannot escape redesigning the repo locking code much longer. [14:15] *** skids joined [15:05] nqp: 31903c6 | (Pawel Murias)++ | t/nqp/28-subclass.t: [15:05] nqp: Change test to use &ok instead of printing TAP. [15:05] nqp: review: https://github.com/perl6/nqp/commit/31903c64da [15:10] nqp: f927c7b | (Pawel Murias)++ | t/nqp/99-getstaticcode.t: [15:10] nqp: Test that nqp::getstaticcode behaves properly. [15:10] nqp: review: https://github.com/perl6/nqp/commit/f927c7bbf4 [15:13] *** Tux__ joined [15:15] *** [Coke]_ joined [15:19] *** Brock joined [15:20] *** hoelzro_ joined [15:24] *** JimmyZ joined [16:17] jnthn: the server camelia runs on is rather bored most of the time. It could run torture tests easily. [16:51] <[Coke]> tadzik: Where do you want to talk about rakudobrew bugs? here, or --toolchain? [17:08] [Coke]: lemmee just join toolchain real quick :) [17:38] *** sno joined [17:44] nine_: could you describe in a few lines what the merge of your branch brings us ? [17:48] *** sno joined [18:05] lizmat: we can now actually use the precomp files generated on installation, so e.g. users no longer have to wait on first use for precompilation of system installed modules. Same is true for developers who no longer have to wait for precomp of installed modules just because they run their code with -Ilib. [18:05] cool :-) [18:06] This also means that we spread around precomp files much less. So lib/.precomp will usually only contain precomp files for the modules we find in lib/ [18:07] The new repo format fixes an issue with packaging modules for Linux distributions. [18:08] wow, nine_++ [18:21] *** cognominal joined [18:30] rakudo/nom: ef3e621 | lizmat++ | src/core/Any-iterable-methods.pm: [18:30] rakudo/nom: Make List.minmax upto 2.2x faster [18:30] rakudo/nom: [18:30] rakudo/nom: - use same approach as with .min/.max [18:30] rakudo/nom: - abstract logic into private methods [18:30] rakudo/nom: - use of ternaries now possible with calling private methods [18:30] rakudo/nom: - direct use of 'cmp' in the default case [18:30] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ef3e621683 [18:33] *** sno joined [18:40] nine++ for those improvements! :) [18:40] And ++nine for the locking cleanup ;) [18:40] nine_: (torture tests) that sounds nice :) [18:44] WRT locking I'm now introducing CompUnit::PrecompilationUnit which contains the precomp file and its dependency information, i.e. what's stored as and .deps. Those two files must are probably the smallest entity that must be in a consistent state. [18:44] So we will have a lock file per precomp file and have CompUnit::PrecompilationUnit do the lock handling. [18:45] Ah, so a fine-grained locking approach. [18:45] Sounds better than contention over the whole set of pre-comps [18:47] Yep. Also I can no longer have a fully consistent view of all precomp files anyway since we now consider all precomp stores and other perl6 processes may use different repo chains. [18:47] And locking all precomp stores individually is a recipie for deadlocks :) [18:48] :) [18:49] Yeah. Guess you already checked to see if there's a lock-free-read + locking write approach? [18:50] * jnthn can quite imagine that being rather tricky for files, alas [18:55] Unfortunately your imagination seems to be quite close to the truth. I'd love lock free reading but fail to come up with a scheme that works cross platform [18:56] oh my, a lot of aborted test files for rakudo-j in todays spectest run. and it was slooow (took more than 10 hours to complete) [18:56] nine_: Yeah, you need something you can atomicly replace, and some way to clean up garbage, really. [18:58] nine_: Essentially, if you view the thing as a tree, then you need an atomic top entry point to replace. And then a way to clean up the leaves that fell out of use. Easy enough if you have a garbage collector or easy safepoints. :) [18:58] And the only way I could have that is to store the dependency information in the precomp file. And I don't know why but right now I don't really fancy implementing that :) [18:59] *nod* [18:59] So I'd stick with the lockfile :) [18:59] Ok, the other way would be to store the new files in a different directory, i.e. the new state would have to be part of the precomp-id. [19:00] Yeah, that's another way to handle the atomicity [19:00] But still leaves the cleanup problem. [19:01] And even if you could rely on unlink of open files working (which I don't think you can on Windows) then there's still a race between replacing the top and deleting the leftovers, and something having read the previous top and then following the reference to an older leaf. [19:01] exactly [19:01] So yeah, horribly horribly fraught. [19:02] (We do use such an approach for NFG synthetics, since you look them up loads and so don't want to have to take a lock. But, we've got easy safepoints and a GC. :)) [19:03] (And of course, it's in memory!) [19:03] It helps when you have total control over your environment :) [19:03] Right :) [19:08] Ouch...I just remembered what I wanted to implement in the first place: the ability to store an updated .deps file in the head repo's precomp store. The precomp file and its dependency information will then no longer be a unit at all. [19:48] rakudo/nom: 224020d | coke++ | README.md: [19:48] rakudo/nom: use github, not RT for patches [19:48] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/224020d630 [19:48] <[Coke]> Hopefully no one disagrees with that. [19:53] nope makes sense [19:54] rakudo/nom: 631a36c | coke++ | README.md: [19:54] rakudo/nom: Don't blindly include [BUG] on rakudobugs [19:54] rakudo/nom: [19:54] rakudo/nom: Give the submitters a few choices. [19:54] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/631a36cbe3 [19:54] <[Coke]> and there's one more. [20:22] *** MadcapJake_ joined [20:32] *** timotimo joined [20:44] *** dalek joined [20:52] <[Coke]> http://perl6.org/documentation/ - docs.perl6.org should be more visible here. [20:53] [Coke]: I completely agree! [20:54] Like maybe it's own block even [20:56] <[Coke]> MadcapJake: opened https://github.com/perl6/perl6.org/issues/48 [20:56] <[Coke]> feel free to add your 2¢ there. [20:59] and another P6W hits the Net: https://p6weekly.wordpress.com/2016/05/02/2016-18-long-awaited-landings/ [20:59] lizmat++ [21:00] yay! [21:00] lizmat++ [21:02] "this seems related to a bug with awaiting a Promise"...heh, I've a local patch in that area :) [21:05] jnthn: yeah, I've suspended looking at that until your Moar fixes have landed [21:07] lizmat: I'll probably get that particular one in earlier than the others. :) [21:07] looking forward to that :-) [21:08] Feels like between the heap analyzer and GC torture tests I've got enough raw data to fuel quite a bit of work. :) [21:09] seems like my headache is slowly calming down [21:09] finally [21:09] timotimo: Hope it continues to do so... [21:09] <[Coke]> RT: 1283; GLR: 6; JVM: 60; LHF: 2; LTA: 66; OSX: 3; PATCH: 3; PERF: 16; POD: 3; PRECOMP: 3; SEGV: 22; STAR: 1; TESTNEEDED: 17; UNI: 5; WEIRD: 2 [21:09] <[Coke]> (now reporting on testneeded custom tag in addition to the textual subject tags) [21:10] as do i [21:18] lizmat++ # interesting qah report [21:23] m: say Inf.Rat [21:23] rakudo-moar 631a36: OUTPUT«Inf␤» [21:24] jnthn: there is code in Num.Rat that will fail with "cannot coerce Inf to a Rat" [21:24] jnthn: however, that code cannot be reached atm because of a check in nqp::isnanorinf [21:24] m: say NaN.Rat [21:24] rakudo-moar 631a36: OUTPUT«NaN␤» [21:25] perhaps that should also fail ? [21:25] m: say Inf.Rat.WHAT [21:25] rakudo-moar 631a36: OUTPUT«(Num)␤» [21:25] m: say NaN.Rat.WHAT [21:25] rakudo-moar 631a36: OUTPUT«(Num)␤» [21:25] m: say Num ~~ Rat [21:25] rakudo-moar 631a36: OUTPUT«False␤» [21:25] OH NO! WE DESTROYED THE UNIVERSE! [21:25] Yeah, I think they should both fail :) [21:26] okidoki [21:26] nqp::isnanorinf is the fastest way to check if it's either of those though [21:26] Then I'd put the "which is it" the slow path [21:26] yeah, I know :-) [21:26] yup [21:26] (In a private method if we want to keep the size down for inlining) [21:27] well, fat chance of inlining Num.Rat [21:27] It's...fat? :D [21:27] yup [21:27] heh, OK [21:27] Guess I can imagine why :) [21:28] btw, is there a reason to get the sign correct by multiplying with -1 instead of just negating ? [21:28] $fat ?? FatRat.new($signum * $b, $d) !! ($signum * $b) / $d; [21:28] seems a ternary there would make more sense ? [21:30] Don't see one, but I suspect I'm too tired to see much right now :) [21:31] ah.. well, I'll run a spectest :-) [21:32] rakudo/nom: 949a7c7 | lizmat++ | src/core/Num.pm: [21:32] rakudo/nom: Make Num.perl about up to 2.4x as fast [21:32] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/949a7c7ab4 [21:37] jnthn: seems spectest expects them not to fail [21:37] m: use Test; is NaN.Rat, NaN, "NaN.Rat == NaN"; [21:37] rakudo-moar 631a36: OUTPUT«ok 1 - NaN.Rat == NaN␤» [21:41] rakudo/nom: e2f1fa7 | lizmat++ | src/core/Num.pm: [21:41] rakudo/nom: We cannot coerce Inf/-Inf/NaN to a Rat [21:41] rakudo/nom: [21:41] rakudo/nom: So fail instead of silently returning Inf/-Inf/NaN [21:41] rakudo/nom: [21:41] rakudo/nom: See http://irclog.perlgeek.de/p6dev/2016-05-02#i_12423404 [21:41] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e2f1fa7351 [21:42] seems related to RT #77820 [21:45] https://rt.perl.org//Public/Bug/Display.html?id=77820 [21:54] lizmat: Hmmm.... May have to get TimToady's input then. But a coercion method returning the wrong type feels rather ungood... [21:54] yeah... in any case, there was dead code there... [21:54] if it should just return itself, then the change will be simple :-) [21:55] return self instead of fail() [21:55] m: Inf.Rat.WHAT.say [21:55] rakudo-moar e2f1fa: OUTPUT«(Failure)␤» [21:56] m: Inf.Int.WHAT.say [21:56] rakudo-moar e2f1fa: OUTPUT«(Failure)␤» [21:56] m: Inf.Int [21:56] rakudo-moar e2f1fa: OUTPUT«Cannot coerce Inf or NaN to an Int␤ in block at /tmp/H_iuI7Zfhk line 1␤␤Actually thrown at:␤ in block at /tmp/H_iuI7Zfhk line 1␤␤» [21:56] m: Inf.Rat [21:56] rakudo-moar e2f1fa: OUTPUT«Cannot coerce Inf to a Rat␤ in block at /tmp/wtYooVsnic line 1␤␤Actually thrown at:␤ in block at /tmp/wtYooVsnic line 1␤␤» [21:56] well, at least now it's consistent with .Int [22:03] rakudo/nom: 86b3234 | lizmat++ | src/core/Num.pm: [22:03] rakudo/nom: Make Num.Rat up to 10% faster [22:03] rakudo/nom: [22:03] rakudo/nom: By not multiplying with -1 to set sign, but using a ternary. [22:03] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/86b323462d [22:04] holy hell, 10%? [22:04] for 42e0.Rat [22:05] so the easy case, which exposed the overhead of multiplying [22:05] oops [22:06] ah, OK [22:06] right, "up to" [22:09] rakudo/nom: 691abd5 | lizmat++ | src/core/Num.pm: [22:09] rakudo/nom: Make Num.Int/Num.Rat give same failure for NaN/Inf [22:09] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/691abd5abd [22:17] rakudo/nom: d065bad | lizmat++ | src/core/Num.pm: [22:17] rakudo/nom: Get fail message type right for FatRat case [22:17] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d065bad3fb [22:21] 'night, #p6dev [22:22] gnite jnthn [22:23] night jnthn [22:30] toodles [22:33] .oO("save up to 15% or more on insurance") [22:34] .oO( wouldn't want to make any promises I can't keep :-) [22:35] *** pmurias joined [22:38] *** sortiz joined [22:43] gnight, #p6dev [22:49] toodles [23:08] *** lizmat joined [23:33] *** lizmat_ joined