06:05 sno joined
dalek p: aa60267 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Set values for iter for ContextRef

fixes NPE with 'CallFrame.new.perl'		 06:56
p: 38f2cea | niner++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Merge pull request #282 from usev6/iter_ContextRef

Set values for iter for ContextRef
08:01 RabidGravy joined
RabidGravy should the design.perl6.org/S22.html#resource and all the corresponding words about %?RESOURCE be altered to reflect the actual implementation? 08:35
psch 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 :)
RabidGravy yeah I agree but I'm not sure the CUR stuff is actually clear enough in my mind 08:39
lizmat S22 was handwavy, documentation would be preferred :-) 08:42
08:45 brrt joined
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:47
I did offer to document the CUR months ago but everyone started bike-shedding and generally being unhelpful so I forgot about it 08:52
stmuk 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, lucs joined 10:38 sortiz joined
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
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
never mind :) 10:43
nine_ This one: github.com/rakudo/rakudo/pull/729
%?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:44
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:45
lizmat fwiw, I'm ok with it being %RESOURCES :-) 10:46
RabidGravy but nothing in there that changes the interface as regards module authors
I'm literally only going to change the 'resources' part of S22 anyway so it corresponds to reality 10:50
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 :)
lizmat ++RabidGravy
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:55
lizmat please adjust spec to reality 10:57
11:00 brrt joined
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:01
I've also removed the v from the version example and made "production" a proper JSON bool 11:03
afaik, zef, panda and META6 warn about the v in the versions 11:04
12:10 pmurias joined
dalek p: 04df939 | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] If the type cache is missing call type_check.
 12:14
p: 73ebe45 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] Implement serialization of P6bignum, make boxing of bignums more correct.

Needs to be cleaned up together with a flattening cleanup.
p: ddf5935 | (Pawel Murias)++ | t/nqp/60-bigint.t:
Test that when boxing bignums the correct thing is in the attribute.
 12:15
p: 592a959 | (Pawel Murias)++ | t/serialization/02-types.t:
Test serializing a P6bignum repr as well as a object having a P6bignum as a box_target.
[Tux] This is Rakudo version 2016.04-74-ga16f0a4 built on MoarVM version 2016.04 13:03
test 22.740
test-t 13.655
csv-parser 35.514
nine_ Meh...seems like I just cannot escape redesigning the repo locking code much longer. 14:11
14:15 skids joined
dalek p: 31903c6 | (Pawel Murias)++ | t/nqp/28-subclass.t:
Change test to use &ok instead of printing TAP.
 15:05
p: f927c7b | (Pawel Murias)++ | t/nqp/99-getstaticcode.t:
Test that nqp::getstaticcode behaves properly.
 15:10
15:13 Tux__ joined 15:15 [Coke]_ joined 15:19 Brock joined 15:20 hoelzro_ joined 15:24 JimmyZ joined
nine_ jnthn: the server camelia runs on is rather bored most of the time. It could run torture tests easily. 16:17
[Coke] tadzik: Where do you want to talk about rakudobrew bugs? here, or --toolchain? 16:51
tadzik [Coke]: lemmee just join toolchain real quick :) 17:08
17:38 sno joined
lizmat nine_: could you describe in a few lines what the merge of your branch brings us ? 17:44
17:48 sno joined
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 :-)
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:06
The new repo format fixes an issue with packaging modules for Linux distributions. 18:07
skids wow, nine_++ 18:08
18:21 cognominal joined
dalek kudo/nom: ef3e621 | lizmat++ | src/core/Any-iterable-methods.pm:
Make List.minmax upto 2.2x faster

  - use same approach as with .min/.max
  - abstract logic into private methods
  - use of ternaries now possible with calling private methods
  - direct use of 'cmp' in the default case		 18:30
18:33 sno joined
jnthn nine++ for those improvements! :) 18:40
And ++nine for the locking cleanup ;)
nine_: (torture tests) that sounds nice :)
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
So we will have a lock file per precomp file and have CompUnit::PrecompilationUnit do the lock handling.
jnthn Ah, so a fine-grained locking approach. 18:45
Sounds better than contention over the whole set of pre-comps
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
And locking all precomp stores individually is a recipie for deadlocks :)
jnthn :) 18:48
Yeah. Guess you already checked to see if there's a lock-free-read + locking write approach? 18:49
jnthn can quite imagine that being rather tricky for files, alas 18:50
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:55
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.
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 :)
jnthn *nod* 18:59
So I'd stick with the lockfile :)
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.
jnthn Yeah, that's another way to handle the atomicity 19:00
But still leaves the cleanup problem.
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
jnthn So yeah, horribly horribly fraught.
(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:02
(And of course, it's in memory!) 19:03
nine_ It helps when you have total control over your environment :)
jnthn Right :)
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:08
dalek kudo/nom: 224020d | coke++ | README.md:
use github, not RT for patches
 19:48
[Coke] Hopefully no one disagrees with that.
RabidGravy nope makes sense 19:53
dalek kudo/nom: 631a36c | coke++ | README.md:
Don't blindly include [BUG] on rakudobugs

Give the submitters a few choices.		 19:54
[Coke] and there's one more.
20:22 MadcapJake_ joined 20:32 timotimo joined 20:44 dalek joined
[Coke] perl6.org/documentation/ - docs.perl6.org should be more visible here. 20:52
MadcapJake [Coke]: I completely agree! 20:53
Like maybe it's own block even 20:54
[Coke] MadcapJake: opened github.com/perl6/perl6.org/issues/48 20:56
feel free to add your 2¢ there.
lizmat and another P6W hits the Net: p6weekly.wordpress.com/2016/05/02/...-landings/ 20:59
jnthn lizmat++
tadzik yay! 21:00
lizmat++
jnthn "this seems related to a bug with awaiting a Promise"...heh, I've a local patch in that area :) 21:02
lizmat jnthn: yeah, I've suspended looking at that until your Moar fixes have landed 21:05
jnthn lizmat: I'll probably get that particular one in earlier than the others. :) 21:07
lizmat looking forward to that :-)
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:08
timotimo seems like my headache is slowly calming down 21:09
finally
jnthn timotimo: Hope it continues to do so...
[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
(now reporting on testneeded custom tag in addition to the textual subject tags)
timotimo as do i 21:10
stmuk lizmat++ # interesting qah report 21:18
lizmat m: say Inf.Rat 21:23
camelia rakudo-moar 631a36: OUTPUT«Inf␤»
lizmat 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
m: say NaN.Rat
camelia rakudo-moar 631a36: OUTPUT«NaN␤»
lizmat perhaps that should also fail ? 21:25
jnthn m: say Inf.Rat.WHAT
camelia rakudo-moar 631a36: OUTPUT«(Num)␤»
jnthn m: say NaN.Rat.WHAT
camelia rakudo-moar 631a36: OUTPUT«(Num)␤»
jnthn m: say Num ~~ Rat
camelia rakudo-moar 631a36: OUTPUT«False␤»
jnthn OH NO! WE DESTROYED THE UNIVERSE!
Yeah, I think they should both fail :)
lizmat okidoki 21:26
jnthn nqp::isnanorinf is the fastest way to check if it's either of those though
Then I'd put the "which is it" the slow path
lizmat yeah, I know :-)
yup
jnthn (In a private method if we want to keep the size down for inlining)
lizmat well, fat chance of inlining Num.Rat 21:27
jnthn It's...fat? :D
lizmat yup
jnthn heh, OK
Guess I can imagine why :)
lizmat 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;
seems a ternary there would make more sense ?
jnthn Don't see one, but I suspect I'm too tired to see much right now :) 21:30
lizmat ah.. well, I'll run a spectest :-) 21:31
dalek kudo/nom: 949a7c7 | lizmat++ | src/core/Num.pm:
Make Num.perl about up to 2.4x as fast
 21:32
lizmat jnthn: seems spectest expects them not to fail 21:37
m: use Test; is NaN.Rat, NaN, "NaN.Rat == NaN";
camelia rakudo-moar 631a36: OUTPUT«ok 1 - NaN.Rat == NaN␤»
dalek kudo/nom: e2f1fa7 | lizmat++ | src/core/Num.pm:
We cannot coerce Inf/-Inf/NaN to a Rat

So fail instead of silently returning Inf/-Inf/NaN
See irclog.perlgeek.de/p6dev/2016-05-02#i_12423404		 21:41
lizmat seems related to RT #77820 21:42
rt.perl.org//Public/Bug/Display.html?id=77820 21:45
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...
if it should just return itself, then the change will be simple :-)
return self instead of fail() 21:55
m: Inf.Rat.WHAT.say
camelia rakudo-moar e2f1fa: OUTPUT«(Failure)␤»
lizmat m: Inf.Int.WHAT.say 21:56
camelia rakudo-moar e2f1fa: OUTPUT«(Failure)␤»
lizmat m: Inf.Int
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␤␤»
lizmat m: Inf.Rat
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␤␤»
lizmat well, at least now it's consistent with .Int
dalek kudo/nom: 86b3234 | lizmat++ | src/core/Num.pm:
Make Num.Rat up to 10% faster

By not multiplying with -1 to set sign, but using a ternary.		 22:03
timotimo holy hell, 10%? 22:04
lizmat for 42e0.Rat
so the easy case, which exposed the overhead of multiplying 22:05
oops
timotimo ah, OK 22:06
right, "up to"
dalek kudo/nom: 691abd5 | lizmat++ | src/core/Num.pm:
Make Num.Int/Num.Rat give same failure for NaN/Inf
 22:09
kudo/nom: d065bad | lizmat++ | src/core/Num.pm:
Get fail message type right for FatRat case
 22:17
jnthn 'night, #p6dev 22:21
timotimo gnite jnthn 22:22
lizmat night jnthn 22:23
RabidGravy toodles 22:30
TimToady
.oO("save up to 15% or more on insurance")
 22:33
lizmat
.oO( wouldn't want to make any promises I can't keep :-)
 22:34
22:35 pmurias joined 22:38 sortiz joined
lizmat gnight, #p6dev 22:43
RabidGravy toodles 22:49
23:08 lizmat joined 23:33 lizmat_ joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!