[00:34] *** softmoth joined [00:43] *** anatofuz joined [00:51] *** anatofuz left [00:57] *** anatofuz joined [01:05] *** anatofuz left [01:18] *** anatofuz joined [01:21] *** anatofuz_ joined [01:23] *** anatofuz left [01:23] *** anatofuz_ left [01:23] *** anatofuz_ joined [01:26] *** anatofuz_ left [01:27] *** Kaiepi joined [01:30] *** anatofuz joined [01:30] *** anatofuz left [01:34] *** anatofuz joined [01:36] *** anatofuz left [01:40] *** anatofuz joined [01:49] *** anatofuz left [01:49] *** anatofuz joined [01:50] *** anatofuz left [01:50] *** anatofuz joined [02:01] *** anatofuz left [02:06] *** anatofuz joined [02:27] *** anatofuz left [03:41] *** [Coke] left [03:43] *** [Coke] joined [03:45] *** anatofuz joined [03:56] *** softmoth left [04:33] *** anatofuz left [04:35] *** anatofuz joined [05:45] *** ZzZombo_ joined [05:48] *** ZzZombo left [05:48] *** ZzZombo_ is now known as ZzZombo [06:32] *** reportable6 left [06:34] *** reportable6 joined [06:38] *** anatofuz left [06:39] *** anatofuz joined [06:44] *** anatofuz left [06:52] *** anatofuz joined [07:50] *** ZzZombo_ joined [07:53] *** ZzZombo left [07:53] *** ZzZombo_ is now known as ZzZombo [08:38] *** leont joined [08:56] *** ZzZombo_ joined [08:59] *** ZzZombo left [08:59] *** ZzZombo_ is now known as ZzZombo [09:39] *** leont left [10:17] *** softmoth joined [10:28] *** anatofuz left [10:58] *** squashable6 left [11:01] *** squashable6 joined [11:01] *** ChanServ sets mode: +v squashable6 [11:05] *** softmoth left [12:00] <|Tux|> Rakudo version 2019.07.1-388-g1fef78388 - MoarVM version 2019.07.1-257-g39f577438 [12:00] <|Tux|> csv-test-xs-20 0.421 - 0.432 [12:00] <|Tux|> csv-ip5xs 0.764 - 0.780 [12:00] <|Tux|> test-t --race 0.773 - 0.798 [12:00] <|Tux|> test-t 1.731 - 1.732 [12:00] <|Tux|> csv-ip5xs-20 6.492 - 6.494 [12:00] <|Tux|> test 6.861 - 7.081 [12:00] <|Tux|> test-t-20 --race 8.723 - 9.048 [12:00] <|Tux|> csv-parser 20.678 - 21.529 [12:00] <|Tux|> test-t-20 29.496 - 29.668 [12:28] *** lucasb joined [13:30] *** cognominal joined [13:32] hi, how come in nqp/moarvm (and perl6) say(0.0) prints 0 instead of 0.0 ? Also where does that happen ? [13:52] Rational.Str [13:57] *** cognomin_ joined [14:00] *** cognominal left [14:01] <[Coke]> m: say 0.0; dd 0.0 [14:01] rakudo-moar 1fef78388: OUTPUT: «0␤0.0␤» [14:11] cognomin_: more specifically https://github.com/rakudo/rakudo/blob/master/src/core.c/Rational.pm6#L127 [14:16] thx. lizmat, right now I am more interested in nqp :). Even if I don't understand that .gist in this particular case does not behave as .perl [14:17] because if a class does not have a gist method, then it will fall back to .Str [14:17] But where does that happen in nqp ? [14:18] Apparently not in P6Num itself [14:19] hmmm... https://github.com/rakudo/rakudo/blob/master/src/core.c/Mu.pm6#L604 looks like it falls back to .perl [14:21] I am writing code in nqp that I want to roundtrip as a sanity test and it does not because 0 is an int not a num [14:24] oh, yeah, the nqp compiler is a bit weird with num vs int [14:24] a few months ago we merged a branch that makes it use int much more often, whereas it used to use num for almost everything [14:24] 00017 getlex_no loc_6_obj, '&say' [14:24] 00018 decont loc_6_obj, loc_6_obj [14:24] 00019 const_n64 loc_7_num, 0.000000 [14:24] 0 [14:24] does that have something to do with it? [14:25] No magic with the compiler [14:25] m: say(my int $ := 0) [14:25] rakudo-moar 1fef78388: OUTPUT: «5===SORRY!5=== Error while compiling ␤Cannot bind to natively typed variable '$ANON_VAR__1'; use assignment instead␤at :1␤------> 3say(my int $ := 07⏏5)␤» [14:25] m: say(my int $ = 0) [14:25] rakudo-moar 1fef78388: OUTPUT: «0␤» [14:26] m: say(0); say(0e0) [14:26] rakudo-moar 1fef78388: OUTPUT: «0␤0␤» [14:26] oh, that's not nqp :) [14:26] nqp: say("test") [14:26] nqp-moarvm: OUTPUT: «test␤» [14:26] nqp: say(0); say(0e0) [14:26] nqp-moarvm: OUTPUT: «0␤0␤» [14:26] nqp: say(my int $ := 0) [14:26] nqp-moarvm: OUTPUT: «Confused at line 2, near "say(my int"␤ at gen/moar/stage2/NQPHLL.nqp:1025 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:panic)␤ from gen/moar/stage2/NQP.nqp:924 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/nqp.moarvm:comp_unit)␤ from gen/m…» [14:28] I can't pinpoint where in nqp the num is converted to an int [14:28] what have you tried? [14:32] I just expected ~0.0 eq '0'. I will work around it [14:33] I am more pissed at not understanding the internals than at them not doing what I expected [14:34] i assume you've checked the output of --target= for optimize as well as ast? [14:34] Yes I pasted the relevant part of a moar dump. [14:41] ok, I guess I got it. using nqp::say I see a coerce_ns op in the dump [14:42] the optimize and ast are rather different from the moar dump [15:01] https://github.com/MoarVM/MoarVM/blob/master/src/math/grisu.c#L342 [15:03] So .perl probably does not use that fast algorithm if it correctly prints 0.0 [15:06] *** vrurg left [15:07] *** vrurg joined [15:08] *** cognominal joined [15:11] *** cognomin_ left [15:27] *** grayrider joined [15:30] *** vrurg left [15:30] *** vrurg joined [15:34] *** Kaiepi left [15:36] *** Guest3346 left [16:09] *** grayrider left [16:18] any reason that couldn't be changed to make it '0.0'? [16:24] well, nqp has a bunch of tests explicitly checking that 0.0 stringifies to '0' [16:26] *** Kaiepi joined [16:27] did what i sent right before dcing actually get sent? [16:27] doesn't seem so [16:28] aight [16:28] i want to make it so IO::Socket::INET only uses the enums defined in IO to represent socket families/types/protocols, which are handled using Int at the moment, since backends will not support using any other values than the ones those will contain. how should i go about this, since this is a breaking change? [16:28] so does rakudo [16:30] but cognominal brings up a good point. should 0.0 really stringify to '0'? [16:32] hm, perl5 does the same: `perl -E 'say 0.0'` prints '0' [16:33] but ruby and python(2|3) both print '0.0' [16:36] perl tends to play fast and loose with type but there is no reason not to please the functional crowd when we can [16:40] nqp -e 'my $i := 0.0; say(nqp::eqaddr($i.WHAT, (+~$i).WHAT))' # should print 1 for any numeric type [16:51] I created a MoarVM pull request but was unable to test. https://github.com/MoarVM/MoarVM/pull/1191 [16:54] literaly much ado about nothing :) [17:01] If someone can read the comment in the pull request so as to test with nqp, I would be thankful [17:08] nqp: say(0e0); say(1e0) [17:08] nqp-moarvm: OUTPUT: «0␤1␤» [17:09] cognominal: Make sure your patch doesn't lead to a discontinuity in the other direction (that 0e0 is the *only* integer-valued float that gets a decimal point). [17:16] *** grayrider joined [17:23] yup, I didn't [17:58] ok, MasterDuke run tests. And the fallout is huge. So better forget about my request. [17:59] cognominal: i think it might make sense to create an issue in the problem-solving repo [18:00] So I close the request and create an issue ? [18:00] m: say 0.0.Str; say 0.0.perl [18:00] rakudo-moar 1fef78388: OUTPUT: «0␤0.0␤» [18:01] cognominal: do I understand correctly that the problem is that 0.0.Str is "0" ? [18:04] yes, even my problem was at the nqp level. 0.0 and 0 are different things typewise so cycling using ~ than + gives an int instead of a num, so it is not a noop [18:04] yeah, but .Str is not guaranteed to roundtrip, nor is .gist [18:04] only .perl is supposed to roundtrip [18:05] so it doesn't feel like an issue to me, but actually a design decision [18:06] made long ago, probably to match Perl 5's behaviour [18:06] $ perl -E 'say 0.0' [18:06] 0 [18:08] ok. I close the pull request (which was incomplete anyway) with your comments and don't open an issue. Thx lizmat. Sorry for the mess [18:10] well, opening a problem-solving issue might make sense, because following Perl 5's behaviour may not be the best in the long run? [18:10] afk& [18:32] <[Coke]> m: print 0.0 [18:32] rakudo-moar 1fef78388: OUTPUT: «0» [18:33] ¦ problem-solving: cognominal assigned to jnthn Issue 0.0.gist returns "0.0" instead of "0" but 0.0.perl works as expected https://github.com/perl6/problem-solving/issues/113 [18:36] I got the subject backward, corrected [20:01] I got a working branch where Inline::Perl5 no longer blocks precompilation of its users! [20:03] I.e. a module that has a "use Foo:from;" in it can now be precompiled. When loaded it will load the Perl 5 interpreter and restore all the modules that were loaded during compilation and fix up all the code references it took when creating wrapper methods. [20:04] wow. how much work was that? [20:05] Depending on how you count a couple of days or years. I've had plans for this for years and made several attempts during that period but only now got the skill to actually pull it off. [20:06] In case you read yesterday's backlog, the "Cannot invoke this object (REPR: Null; VMNull)" issue is something that made it really hard. [20:08] yeah, i don't like running into those [20:09] I hit another hard issue today though that's still unsolved. Some cases won't work with NativeCall exporting that CHECK phaser for creating optimized function bodies at compile time [20:13] This breaks when a script uses Inline::Perl5 and loads a module that also uses Inline::Perl5. Will segfault due to a NULL jitcode in the NativeCallBody [20:15] that seems tricky to fix [20:17] It may help that I wrote the whole damn thing...but even so I only have the faintest idea of what may go wrong [20:29] Wow, nine++ [21:02] impressive [21:16] Yeah, that's some good hacking right there. nine++ [21:44] nine: BTW, I'm wandering the jungles of grammar/action/serialization. So far, my prime suspect is block_closure which clones a code object but neither serializes it itself not proclaims it a clone of the source cuid. [21:45] So, unless the method clone does serialize it, that's most certainly the cause of 'REPR: Null' bug. [21:58] *** MasterDuke left [23:12] vrurg: Hmmm [23:12] Interesting. [23:12] (I thought I had something useful to say, but I don't think it is quite useful, having re-read what you said :)) [23:15] I'd thought the problem was not quite in the cloning, but in the later lexical fixup, fwiw [23:15] jnthn: I'm not sure if I'm right. Would the clone be lost method installed on the class would be VMNill'ed [23:16] And I don't figure out if the fixup is being executed or if it's ever installed. [23:16] s/don't/can't/ [23:17] finish_code_object doesn't install any fixup if in precompilation mode. [23:20] Due to lack of knowledge, I'm not even sure what's to be done in it. Wild guess is it must add the closure to the SC. [23:28] *** camelCaser left [23:30] *** leont joined [23:30] *** b2gills left [23:33] *** camelCaser joined [23:38] I'm lost, but neither compstuff[2] is getting called upon cloning nor fixup code. [23:45] *** b2gills joined