Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-02

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

All times shown according to UTC.

Time Nick Message
06:05 sno joined #p6dev
06:56 dalek nqp: aa60267 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
06:56 dalek nqp: Set values for iter for ContextRef
06:56 dalek nqp:
06:56 dalek nqp: fixes NPE with 'CallFrame.new.perl'
06:56 dalek nqp: review: https://github.com/perl6/nqp/commit/aa60267188
06:56 dalek nqp: 38f2cea | niner++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
06:56 dalek nqp: Merge pull request #282 from usev6/iter_ContextRef
06:56 dalek nqp:
06:56 dalek nqp: Set values for iter for ContextRef
06:56 dalek nqp: review: https://github.com/perl6/nqp/commit/38f2cea9f3
08:01 RabidGravy joined #p6dev
08:35 RabidGravy 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 psch i'd prefer proper documentation instead i think
08:36 psch 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 RabidGravy yeah I agree but I'm not sure the CUR stuff is actually clear enough in my mind
08:42 lizmat S22 was handwavy, documentation would be preferred   :-)
08:45 brrt joined #p6dev
08:47 RabidGravy 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 RabidGravy 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 stmuk there is a useful CUR test somewhere
09:35 stmuk except I can't find it right now
10:24 dalek joined #p6dev
10:26 d4l3k_ joined #p6dev
10:34 dalek joined #p6dev
10:37 JimmyZ joined #p6dev
10:37 lucs joined #p6dev
10:38 sortiz joined #p6dev
10:40 nine_ 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 RabidGravy Okay I'll take a look at that first
10:42 RabidGravy got a linky to the PR, I'm only seeing one outstanding one from hoelzro for something completely different
10:42 RabidGravy oh I see, the PR is against rakudo
10:43 RabidGravy never mind :)
10:43 nine_ This one: https://github.com/rakudo/rakudo/pull/729
10:44 nine_ %?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 RabidGravy 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 lizmat fwiw, I'm ok with it being %RESOURCES  :-)
10:46 RabidGravy but nothing in there that changes the interface as regards module authors
10:50 RabidGravy I'm literally only going to change the 'resources' part of S22 anyway so it corresponds to reality
10:53 RabidGravy but there's a whole bunch of other speculation in there that doesn't exist
10:53 nine_ Whatever you do, it will be a step forward :)
10:53 lizmat ++RabidGravy
10:55 RabidGravy 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 lizmat please adjust spec to reality
11:00 brrt joined #p6dev
11:01 RabidGravy 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 RabidGravy I've also removed the v from the version example and made "production" a proper JSON bool
11:04 RabidGravy afaik, zef, panda and META6 warn about the v in the versions
12:10 pmurias joined #p6dev
12:14 dalek nqp: 04df939 | (Pawel Murias)++ | src/vm/js/ (3 files):
12:14 dalek nqp: [js] If the type cache is missing call type_check.
12:14 dalek nqp: review: https://github.com/perl6/nqp/commit/04df93988a
12:14 dalek nqp: 73ebe45 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
12:14 dalek nqp: [js] Implement serialization of P6bignum, make boxing of bignums more correct.
12:14 dalek nqp:
12:14 dalek nqp: Needs to be cleaned up together with a flattening cleanup.
12:14 dalek nqp: review: https://github.com/perl6/nqp/commit/73ebe45a44
12:15 dalek nqp: ddf5935 | (Pawel Murias)++ | t/nqp/60-bigint.t:
12:15 dalek nqp:  Test that when boxing bignums the correct thing is in the attribute.
12:15 dalek nqp: review: https://github.com/perl6/nqp/commit/ddf593554a
12:15 dalek nqp: 592a959 | (Pawel Murias)++ | t/serialization/02-types.t:
12:15 dalek nqp: Test serializing a P6bignum repr as well as a object having a P6bignum as a box_target.
12:15 dalek 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 nine_ Meh...seems like I just cannot escape redesigning the repo locking code much longer.
14:15 skids joined #p6dev
15:05 dalek nqp: 31903c6 | (Pawel Murias)++ | t/nqp/28-subclass.t:
15:05 dalek nqp: Change test to use &ok instead of printing TAP.
15:05 dalek nqp: review: https://github.com/perl6/nqp/commit/31903c64da
15:10 dalek nqp: f927c7b | (Pawel Murias)++ | t/nqp/99-getstaticcode.t:
15:10 dalek nqp: Test that nqp::getstaticcode behaves properly.
15:10 dalek nqp: review: https://github.com/perl6/nqp/commit/f927c7bbf4
15:13 Tux__ joined #p6dev
15:15 [Coke]_ joined #p6dev
15:19 Brock joined #p6dev
15:20 hoelzro_ joined #p6dev
15:24 JimmyZ joined #p6dev
16:17 nine_ 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 tadzik [Coke]: lemmee just join toolchain real quick :)
17:38 sno joined #p6dev
17:44 lizmat nine_: could you describe in a few lines what the merge of your branch brings us ?
17:48 sno joined #p6dev
18:05 nine_ 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 lizmat cool  :-)
18:06 nine_ 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 nine_ The new repo format fixes an issue with packaging modules for Linux distributions.
18:08 skids wow, nine_++
18:21 cognominal joined #p6dev
18:30 dalek rakudo/nom: ef3e621 | lizmat++ | src/core/Any-iterable-methods.pm:
18:30 dalek rakudo/nom: Make List.minmax upto 2.2x faster
18:30 dalek rakudo/nom:
18:30 dalek rakudo/nom: - use same approach as with .min/.max
18:30 dalek rakudo/nom: - abstract logic into private methods
18:30 dalek rakudo/nom: - use of ternaries now possible with calling private methods
18:30 dalek rakudo/nom: - direct use of 'cmp' in the default case
18:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ef3e621683
18:33 sno joined #p6dev
18:40 jnthn nine++ for those improvements! :)
18:40 jnthn And ++nine for the locking cleanup ;)
18:40 jnthn nine_: (torture tests) that sounds nice :)
18:44 nine_ WRT locking I'm now introducing CompUnit::PrecompilationUnit which contains the precomp file and its dependency information, i.e. what's stored as <precomp-id> and <precomp-id>.deps. Those two files must are probably the smallest entity that must be in a consistent state.
18:44 nine_ So we will have a lock file per precomp file and have CompUnit::PrecompilationUnit do the lock handling.
18:45 jnthn Ah, so a fine-grained locking approach.
18:45 jnthn Sounds better than contention over the whole set of pre-comps
18:47 nine_ 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 nine_ And locking all precomp stores individually is a recipie for deadlocks :)
18:48 jnthn :)
18:49 jnthn 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 nine_ 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 bartolin 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 jnthn nine_: Yeah, you need something you can atomicly replace, and some way to clean up garbage, really.
18:58 jnthn 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 nine_ 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 jnthn *nod*
18:59 jnthn So I'd stick with the lockfile :)
18:59 nine_ 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 jnthn Yeah, that's another way to handle the atomicity
19:00 jnthn But still leaves the cleanup problem.
19:01 jnthn 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 nine_ exactly
19:01 jnthn So yeah, horribly horribly fraught.
19:02 jnthn (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 jnthn (And of course, it's in memory!)
19:03 nine_ It helps when you have total control over your environment :)
19:03 jnthn Right :)
19:08 nine_ 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 dalek rakudo/nom: 224020d | coke++ | README.md:
19:48 dalek rakudo/nom: use github, not RT for patches
19:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/224020d630
19:48 [Coke] Hopefully no one disagrees with that.
19:53 RabidGravy nope makes sense
19:54 dalek rakudo/nom: 631a36c | coke++ | README.md:
19:54 dalek rakudo/nom: Don't blindly include [BUG] on rakudobugs
19:54 dalek rakudo/nom:
19:54 dalek rakudo/nom: Give the submitters a few choices.
19:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/631a36cbe3
19:54 [Coke] and there's one more.
20:22 MadcapJake_ joined #p6dev
20:32 timotimo joined #p6dev
20:44 dalek joined #p6dev
20:52 [Coke] http://perl6.org/documentation/ - docs.perl6.org should be more visible here.
20:53 MadcapJake [Coke]: I completely agree!
20:54 MadcapJake 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 lizmat and another P6W hits the Net: https://p6weekly.wordpress.com/2016/05/02/2016-18-long-awaited-landings/
20:59 jnthn lizmat++
21:00 tadzik yay!
21:00 tadzik lizmat++
21:02 jnthn "this seems related to a bug with awaiting a Promise"...heh, I've a local patch in that area :)
21:05 lizmat jnthn: yeah, I've suspended looking at that until your Moar fixes have landed
21:07 jnthn lizmat: I'll probably get that particular one in earlier than the others. :)
21:07 lizmat looking forward to that  :-)
21:08 jnthn 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 timotimo seems like my headache is slowly calming down
21:09 timotimo finally
21:09 jnthn 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 timotimo as do i
21:18 stmuk lizmat++ # interesting  qah report
21:23 lizmat m: say Inf.Rat
21:23 camelia rakudo-moar 631a36: OUTPUT«Inf␤»
21:24 lizmat jnthn: there is code in Num.Rat that will fail with "cannot coerce Inf to a Rat"
21:24 lizmat jnthn: however, that code cannot be reached atm because of a check in nqp::isnanorinf
21:24 lizmat m: say NaN.Rat
21:24 camelia rakudo-moar 631a36: OUTPUT«NaN␤»
21:25 lizmat perhaps that should also fail ?
21:25 jnthn m: say Inf.Rat.WHAT
21:25 camelia rakudo-moar 631a36: OUTPUT«(Num)␤»
21:25 jnthn m: say NaN.Rat.WHAT
21:25 camelia rakudo-moar 631a36: OUTPUT«(Num)␤»
21:25 jnthn m: say Num ~~ Rat
21:25 camelia rakudo-moar 631a36: OUTPUT«False␤»
21:25 jnthn OH NO! WE DESTROYED THE UNIVERSE!
21:25 jnthn Yeah, I think they should both fail :)
21:26 lizmat okidoki
21:26 jnthn nqp::isnanorinf is the fastest way to check if it's either of those though
21:26 jnthn Then I'd put the "which is it" the slow path
21:26 lizmat yeah, I know  :-)
21:26 lizmat yup
21:26 jnthn (In a private method if we want to keep the size down for inlining)
21:27 lizmat well, fat chance of inlining Num.Rat
21:27 jnthn It's...fat? :D
21:27 lizmat yup
21:27 jnthn heh, OK
21:27 jnthn Guess I can imagine why :)
21:28 lizmat btw, is there a reason to get the sign correct by multiplying with -1 instead of just negating ?
21:28 lizmat $fat ?? FatRat.new($signum * $b, $d) !! ($signum * $b) / $d;
21:28 lizmat seems a ternary there would make more sense ?
21:30 jnthn Don't see one, but I suspect I'm too tired to see much right now :)
21:31 lizmat ah.. well, I'll run a spectest  :-)
21:32 dalek rakudo/nom: 949a7c7 | lizmat++ | src/core/Num.pm:
21:32 dalek rakudo/nom: Make Num.perl about up to 2.4x as fast
21:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/949a7c7ab4
21:37 lizmat jnthn: seems spectest expects them not to fail
21:37 lizmat m: use Test; is NaN.Rat, NaN, "NaN.Rat == NaN";
21:37 camelia rakudo-moar 631a36: OUTPUT«ok 1 - NaN.Rat == NaN␤»
21:41 dalek rakudo/nom: e2f1fa7 | lizmat++ | src/core/Num.pm:
21:41 dalek rakudo/nom: We cannot coerce Inf/-Inf/NaN to a Rat
21:41 dalek rakudo/nom:
21:41 dalek rakudo/nom: So fail instead of silently returning Inf/-Inf/NaN
21:41 dalek rakudo/nom:
21:41 dalek rakudo/nom: See http://irclog.perlgeek.de/p6dev/2016-05-02#i_12423404
21:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e2f1fa7351
21:42 lizmat seems related to RT #77820
21:45 lizmat https://rt.perl.org//Public/Bug/Display.html?id=77820
21:54 jnthn lizmat: Hmmm.... May have to get TimToady's input then. But a coercion method returning the wrong type feels rather ungood...
21:54 lizmat yeah... in any case, there was dead code there...
21:54 lizmat if it should just return itself, then the change will be simple  :-)
21:55 lizmat return self instead of fail()
21:55 lizmat m: Inf.Rat.WHAT.say
21:55 camelia rakudo-moar e2f1fa: OUTPUT«(Failure)␤»
21:56 lizmat m: Inf.Int.WHAT.say
21:56 camelia rakudo-moar e2f1fa: OUTPUT«(Failure)␤»
21:56 lizmat m: Inf.Int
21:56 camelia rakudo-moar e2f1fa: OUTPUT«Cannot coerce Inf or NaN to an Int␤  in block <unit> at /tmp/H_iuI7Zfhk line 1␤␤Actually thrown at:␤  in block <unit> at /tmp/H_iuI7Zfhk line 1␤␤»
21:56 lizmat m: Inf.Rat
21:56 camelia rakudo-moar e2f1fa: OUTPUT«Cannot coerce Inf to a Rat␤  in block <unit> at /tmp/wtYooVsnic line 1␤␤Actually thrown at:␤  in block <unit> at /tmp/wtYooVsnic line 1␤␤»
21:56 lizmat well, at least now it's consistent with .Int
22:03 dalek rakudo/nom: 86b3234 | lizmat++ | src/core/Num.pm:
22:03 dalek rakudo/nom: Make Num.Rat up to 10% faster
22:03 dalek rakudo/nom:
22:03 dalek rakudo/nom: By not multiplying with -1 to set sign, but using a ternary.
22:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/86b323462d
22:04 timotimo holy hell, 10%?
22:04 lizmat for 42e0.Rat
22:05 lizmat so the easy case, which exposed the overhead of multiplying
22:05 lizmat so the easy case, which exposed the overhead of multiplying
22:05 lizmat oops
22:06 timotimo ah, OK
22:06 timotimo right, "up to"
22:09 dalek rakudo/nom: 691abd5 | lizmat++ | src/core/Num.pm:
22:09 dalek rakudo/nom: Make Num.Int/Num.Rat give same failure for NaN/Inf
22:09 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/691abd5abd
22:17 dalek rakudo/nom: d065bad | lizmat++ | src/core/Num.pm:
22:17 dalek rakudo/nom: Get fail message type right for FatRat case
22:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d065bad3fb
22:21 jnthn 'night, #p6dev
22:22 timotimo gnite jnthn
22:23 lizmat night jnthn
22:30 RabidGravy toodles
22:33 TimToady .oO("save up to 15% or more on insurance")
22:34 lizmat .oO( wouldn't want to make any promises I can't keep :-)
22:35 pmurias joined #p6dev
22:38 sortiz joined #p6dev
22:43 lizmat gnight, #p6dev
22:49 RabidGravy toodles
23:08 lizmat joined #p6dev
23:33 lizmat_ joined #p6dev

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