[00:33] m: dd 13.0R [00:33] rakudo-moar 87fefa: OUTPUT«===SORRY!=== Error while compiling ␤Confused␤at :1␤------> dd 13.0⏏R␤» [00:33] really... [00:35] m: use Test; is 13.0R % 4.0, 1, "infix:<%> with FatRat and Rat"; [00:35] rakudo-moar 87fefa: OUTPUT«===SORRY!=== Error while compiling ␤Confused␤at :1␤------> use Test; is 13.0⏏R % 4.0, 1, "infix:<%> with FatRat and ␤» [00:35] Ah, that roast file has "sub postfix:($x) { $x.FatRat }"... [00:35] I thought it was some syntax I wasn't aware of:P [00:39] u: 🐀 [00:39] notviki, U+1F400 RAT [So] (🐀) [00:48] m: sub postfix: (Rat $r --> FatRat) is tighter(&infix:<==>) { FatRat.new: .numerator, .denominator }; say <0/0>F == <1/0>F [00:48] rakudo-moar 87fefa: OUTPUT«===SORRY!===␤Unknown QAST node type NQPMu␤» [01:09] rakudo/nom: 73182d4 | (Zoffix Znet)++ | src/core/Rat.pm: [01:09] rakudo/nom: Fix &infix:<==> on Rationals with 0-denominator [01:09] rakudo/nom: [01:09] rakudo/nom: The current logic naively cross-multiplies denominator and numerator, [01:09] rakudo/nom: and gives nonsense results such as <42/1> == <0/0>. By extension, [01:09] rakudo/nom: smartmatch agains Rationals has same issue as well as their use as [01:09] rakudo/nom: literals in signatures. [01:09] rakudo/nom: [01:09] rakudo/nom: Fix by checking if at least one parameter has a zero denominator and [01:09] rakudo/nom: using .Num comparison in that case, since at least one param will be [01:09] rakudo/nom: an Inf, -Inf, or NaN [01:09] rakudo/nom: [01:10] roast: d182fdc | (Zoffix Znet)++ | S32-num/fatrat.t: [01:10] roast: Remove trailing whitespace [01:10] roast: review: https://github.com/perl6/roast/commit/d182fdc702 [01:10] gd [01:10] https://github.com/rakudo/rakudo/commit/73182d4e93728943ae50d4104de453011169a355 [01:11] roast: eea0bb0 | (Zoffix Znet)++ | S32-num/ (2 files): [01:11] roast: Test &infix:<==> with 0-denominator Rationals [01:11] roast: [01:11] roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/73182d4e93728943ae50d41 [01:11] roast: review: https://github.com/perl6/roast/commit/eea0bb08e3 [01:11] *such as <42/1> == <0/0> is True [02:29] uhhh... why there are so many fun bugs to fix today! [02:29] I need to finish my HNY bot for the #freenode-newyears party... [03:15] <[Coke]> samcv: can you forward me the email that said they got the CLA? It's still not on the online list. [03:15] ok. can you give me your email [03:21] * [Coke] wonders what this new Inf behavior he saw in scrollback is. [03:32] * notviki doesn't recall any new Inf behaviour in the scrollback :/ [03:34] <[Coke]> https://irclog.perlgeek.de/perl6-dev/2016-12-30#i_13826253 [03:34] <[Coke]> that's jnthn's last comment about it, with some things leading up to it. [03:34] <[Coke]> m: say Inf.Rat; [03:34] rakudo-moar 73182d: OUTPUT«Inf␤» [03:34] Ah. It's not new. I think it's from July or something [03:35] And it's roundtripping Inf.Rat or something like that, with the Rational[Numeric,Int] object [03:35] <[Coke]> b: say Inf.Rat; [03:35] [Coke], On both starting points (old=2015.12 new=73182d4) the exit code is 0 and the output is identical as well [03:35] [Coke], Output on both points: Inf [03:35] <[Coke]> b: say Inf.Rat.WHAT; [03:35] [Coke], Bisecting by output (old=2015.12 new=73182d4) because on both starting points the exit code is 0 [03:35] [Coke], bisect log: https://gist.github.com/0e385a1f9be3aa8c79656cc940a1bb7e [03:35] [Coke], (2016-05-02) https://github.com/rakudo/rakudo/commit/e2f1fa735132b9f43e7aa9390b42f42a17ea815f [03:37] rakudo/nom: 7434a8f | (Zoffix Znet)++ | src/core/Rational.pm: [03:37] rakudo/nom: Implement Rational.isNaN [03:37] rakudo/nom: [03:37] rakudo/nom: Currently we use Real.isNaN that always gives False, however a Rat [03:37] rakudo/nom: can be a NaN when both its numerator and denominator are zeroes. [03:37] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7434a8f73e [03:38] <[Coke]> I thought that was a Failure, not a NaN. (I thought NaN was only a Num) [03:39] roast: fea29a3 | (Zoffix Znet)++ | S32-num/ (2 files): [03:39] roast: Test Rational.isNaN [03:39] roast: [03:39] roast: Implemented in Rakudo in [03:39] roast: https://github.com/rakudo/rakudo/commit/7434a8f73e [03:39] roast: review: https://github.com/perl6/roast/commit/fea29a3902 [03:40] <[Coke]> Was there a ticket for that? [03:43] [Coke]: nope, I always include tickets in commit messages. [03:43] [Coke]: it's still a Failure. [03:43] m: say 0/0 [03:43] rakudo-moar 73182d: OUTPUT«Attempt to divide by zero using div␤ in block at line 1␤␤Actually thrown at:␤ in block at line 1␤␤» [03:44] [Coke]: but in some contexts we use the Num value which is a NaN, per IEEE 754-2008 rules [03:46] [Coke]: I guess it makes sense to think of not what it "is", but what it becomes when we want a particular representation of a result. [03:46] *more sense [04:11] rakudo/nom: cb2476f | (Zoffix Znet)++ | src/core/Rat.pm: [04:11] rakudo/nom: Fix infix:<===> for 0-denominator Rationals [04:11] rakudo/nom: [04:11] rakudo/nom: Before the fix for infix:<==>[^1], the infix:<===> gave True for any [04:11] rakudo/nom: pair of 0-denominator Rationals. Now it no longer does, but there [04:11] rakudo/nom: still 2 edge cases exist in infix:<===> that we need to take care of: [04:11] rakudo/nom: [04:11] rakudo/nom: 1) since <0/0> uses NaN semantics in infix:<==>, we need an extra check [04:11] rakudo/nom: for wether both params are <0/0>. We use newly-added[^2] [04:11] rakudo/nom: Rational.isNaN for that. [04:11] rakudo/nom: [04:11] rakudo/nom: 2) Since <42/0> == <99/0> is True, we need an extra check to ensure the [04:11] rakudo/nom: numerators match as well. We need that only for 0-denominator Rationals, [04:11] rakudo/nom: so we test whether just one parameter's denominator is a zero, since [04:11] https://github.com/rakudo/rakudo/commit/cb2476f9b9ae338e573519ffca8848c6185802bc [04:12] roast: fd7c11b | (Zoffix Znet)++ | S32-num/ (2 files): [04:12] roast: Test &infix:<===> with 0-denominator Rationals [04:12] roast: [04:12] roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/cb2476f9b9ae338e5735 [04:12] roast: review: https://github.com/perl6/roast/commit/fd7c11bfc2 [05:13] rakudo/nom: b3ab375 | (Zoffix Znet)++ | src/core/Rat (2 files): [05:13] rakudo/nom: Fix Rational.Range [05:13] rakudo/nom: [05:13] rakudo/nom: 1) When RT#130427[^1] was fixed, we thought there are no Inf in Rationals, [05:13] rakudo/nom: so we excluded the endpoints in Rat.Range. However, Infs *are* present: [05:13] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=130427 [05:13] rakudo/nom: when the denominator is zero, the value is +Inf with positive numerators [05:13] rakudo/nom: and -Inf with negative numerators. So I'm undoing the original fix for [05:13] rakudo/nom: that ticket and including Inf endpoints in the returned range. [05:13] rakudo/nom: [05:13] rakudo/nom: 2) the .Range is present only on a Rat and is missing from the FatRat. Fix [05:13] rakudo/nom: this by moving Rat.Range into Rational.Range, so it provides .Range for [05:13] rakudo/nom: both types. [05:13] rakudo/nom: [05:13] rakudo/nom: [1] https://rt.perl.org/Ticket/Display.html?id=130427 [05:14] https://github.com/rakudo/rakudo/commit/b3ab375f0cdca4a5c1ed906aa281254bce96f455 [05:16] roast: 96cca2d | (Zoffix Znet)++ | S32-num/ (2 files): [05:16] roast: Redo test for Rational.Range [05:16] roast: [05:16] roast: The test was added[^1] a day ago as part of a fix for a ticket[^2] and [05:16] roast: is not part of 6.c-errata. It's testing incorrect behaviour. [05:16] roast: See Rakudo commit[^2] for rationale. [05:16] roast: [05:16] roast: [1] https://github.com/perl6/roast/commit/99f7d695a6 [05:16] roast: [2] https://rt.perl.org/Ticket/Display.html?id=130427 [05:16] roast: [3] https://github.com/rakudo/rakudo/commit/b3ab375f0cdca4a5c [05:16] roast: review: https://github.com/perl6/roast/commit/96cca2d5bb [05:18] time for last sleep of the year \o/ [05:46] emoji sequences in graphemes coming soon :) [05:46] running spectest now [05:48] m: say "🤷🏻".chars [05:48] rakudo-moar b3ab37: OUTPUT«2␤» [06:48] m: '('.uniprop('Bidi_Matching_Brackets').say [06:48] rakudo-moar b3ab37: OUTPUT«0␤» [06:48] m: '('.uniprop('Bidi_Mirroring_Glyph').say [06:48] oh ok. cool [08:43] star/zef: 46ef87b | (Steve Mynott)++ | patches/panda.patch: [08:43] star/zef: more obvious warning [08:43] star/zef: review: https://github.com/rakudo/star/commit/46ef87b3e1 [09:04] buggable, help [09:04] samcv, tags | tag SOMETAG | eco | eco Some search term | speed [09:05] buggable, prepend [09:06] hmm don't see an RT for lack of supporting prepend unicode glyphs [09:06] should be added [09:06] that's the only NYI thing on unicode 9.0 that my pull that should be landing in MoarVM within the next day or so if jnthn pulls it. [09:07] rakudo/nom: 7bba13a | usev6++ | / (2 files): [09:07] rakudo/nom: [JVM] Make sure $J_LIBPATH is actually set [09:07] rakudo/nom: [09:07] rakudo/nom: For the JVM backend %nqp_config is not passed to fill_template_file, [09:07] rakudo/nom: so we cannot use nqp::libdir directly. [09:07] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7bba13ab3c [09:07] rakudo/nom: adcfb8b | usev6++ | tools/build/Makefile-JVM.in: [09:07] rakudo/nom: [JVM] Fix usage of prefix [09:07] rakudo/nom: [09:07] rakudo/nom: Rakudo was unable to find BOOTSTRAP.jar because [09:07] rakudo/nom: nqp::getcomp('perl6').config was empty [09:07] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/adcfb8bfc8 [09:07] there's some issue there not sure of why it doesn't break for that seems to ignore that. so we pass all unicode grapheme break tests except for ones with Prepend characters :) even the emoji [09:08] oh. tho i forgot the three character code country symbols, only two country codes work now because it parses two codes at a time... so that will require rework of things [11:20] <[Tux]> This is Rakudo version 2016.12-150-g2c2934784 built on MoarVM version 2016.12-35-g293bda71 [11:20] <[Tux]> csv-ip5xs 3.162 [11:20] <[Tux]> test 13.481 [11:20] <[Tux]> test-t 5.234 [11:20] <[Tux]> csv-parser 13.866 [11:20] hi [Tux] [11:21] <[Tux]> o/ [11:21] \o [11:26] \o [11:27] I'm kinda unhappy with our Uni type [11:27] I'd love to be able to do much more with it [11:27] like match regexes etc. [11:27] and I wonder if it would be more sensible to give it a different REPR [11:27] ideally a non-NFG string [11:28] so that things like substr could work [11:28] and regex matches [11:28] does that sound sensible and feasible without too much effort? [11:28] hmm [11:28] non-NFG? [11:28] you want non normalized? [11:29] I don't want normalized on the grapheme level [11:29] (see the JSON issue discussed yesterday if you wonder why) [11:30] i maybe remember seing that a week ago [11:30] I don't care much if it's NF(K)C-composed or not [11:30] so the problem is, it changes the codepoints? [11:30] right [11:30] ah [11:30] hold on let me look at the bug report [11:31] https://github.com/moritz/json/issues/25 [11:31] yeah looking at it now [11:31] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / '"' .+? '"' / [11:31] rakudo-moar 2c2934: OUTPUT«Nil␤» [11:31] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / '"' <-["]> '"' / [11:31] rakudo-moar 2c2934: OUTPUT«Nil␤» [11:32] that's an illustration of the core of the problem [11:32] m: say qq["\c[SPACE]"] ~~ / '"' <-["]> '"' / [11:32] rakudo-moar 2c2934: OUTPUT«「" "」␤» [11:32] ah [11:32] ok i understand the problem [11:32] i should test this on my changes to moarvm but i think it probably will be the same result [11:33] due to how ZWJ works. [11:33] TimToady, jnthn: input on the discussion above would be appreciated [11:33] moritz, is it only an issue near the delimiters? [11:33] it's not just with zero-width joiner; any combining character right after the first " makes it not match [11:33] like quotation marks [11:33] samcv: yes [11:33] ok [11:33] that is good [11:34] that means we can maybe workaround it. i was thinking of implementing at least a awesome error for rakudo [11:34] m: say qq["\c[COMBINING GRAVE ACCENT]"] ~~ / '"' <-["]> '"' / [11:34] rakudo-moar 2c2934: OUTPUT«Nil␤» [11:34] implemented unicode properties searching for matching brakcets and have a warning if it's the incorrect character [11:34] m: say qq["\c[COMBINING GRAVE ACCENT]"] ~~ / :ignoremark '"' <-["]> '"' / [11:34] rakudo-moar 2c2934: OUTPUT«Nil␤» [11:34] IMHO that is a bug [11:34] and then, we don't support this yet, but unicode 9 has prepend property of graphpme cluster break [11:34] m: say qq["\c[COMBINING GRAVE ACCENT]"] ~~ / :ignoremark '"' <-["]>* '"' / [11:34] rakudo-moar 2c2934: OUTPUT«「"̀"」␤» [11:35] wait no that shouldn't be an issue. just the ones that combine with the right [11:35] ah no [11:35] trying to think of the easiest way to do this [11:35] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / :ignoremark '"' <-["]>* '"' / [11:35] rakudo-moar 2c2934: OUTPUT«「"‍"」␤» [11:35] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / :ignoremark '"' (<-["]>*) '"' /; say $1.chars [11:35] rakudo-moar 2c2934: OUTPUT«「"‍"」␤ 0 => 「」␤Use of Nil in string context␤ in block at line 1␤0␤» [11:35] moritz, do you know which part of the code it fails on? [11:36] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / :ignoremark '"' (<-["]>*) '"' /; say $0.chars [11:36] rakudo-moar 2c2934: OUTPUT«「"‍"」␤ 0 => 「」␤0␤» [11:36] also moritz [11:36] json is supposed to be valid utf-8 right [11:36] yes [11:36] ok then you could argue it's not valid json [11:36] but UTF-8 as an encoding makes no assumptions about well-formedness of the codepoint sequence it encodes, no? [11:36] uhm [11:37] ah. so i guess utf-8 not unicode or something hmm [11:37] will have to see the RFC [11:37] but anyway, arguing won't bring us anywhere; loads of existing libraries produce output like that [11:37] if it's literally UTF-8 encoding and nothing else [11:37] yeah exactly [11:37] even if that is the case we still need to do something [11:37] and that it couldn't be parsed as found during a real-world use case [11:38] who has the invalid json needing to be parsed? curious [11:38] m: say qq["\c[ZERO WIDTH JOINER]"] ~~ / :ignoremark ('"') (<-["]>*) '"' /; say $0.Str [11:38] rakudo-moar 2c2934: OUTPUT«「"‍"」␤ 0 => 「"‍」␤ 1 => 「」␤"‍␤» [11:38] samcv: the JSON export of the IRC logger at https://irclog.perlgeek.de/ produced the json under discussion (not sure it's actually invalid), and AlexDaniel tried to use it in Perl 6 [11:38] ah ok [11:39] hmm [11:39] well. i can fix this in moarvm [11:39] if you wish [11:39] unicode doesn't specify how to deal with 'degenerates' [11:39] which is what this problem is caused by [11:39] m: say so qq["\c[ZERO WIDTH JOINER]"] ~~ / :ignoremark ('"') (<-["]>*) '"' /; say ' '.samemark($0.Str).ord [11:39] rakudo-moar 2c2934: OUTPUT«True␤32␤» [11:40] samcv: I don't know if there's actually a problem in MoarVM [11:40] there isn't [11:40] then we shouldn't fix it there [11:40] uhm [11:40] not accurate really [11:40] unicode doesn't specify handling of degenerates [11:40] and that's what this is [11:40] so we are 100% free to basically do anything we want within reason [11:41] since the two characters don't actually make up a sequence [11:41] m: say so qq["\c[COMBINING TILDE]"] ~~ / :ignoremark ('"') (<-["]>*) '"' /; say ' '.samemark($0.Str).ord [11:41] rakudo-moar 2c2934: OUTPUT«True␤32␤» [11:41] m: say so qq["\c[COMBINING TILDE]"] ~~ / :ignoremark ('"') (<-["]>*) '"' /; say $0.Str [11:41] rakudo-moar 2c2934: OUTPUT«True␤\"̃␤» [11:42] err wait on second thought. let me check some more specs [11:42] but. i think we should be fine doing this [11:42] say ' '.samemark(qq["\c[COMBINING TILDE]) [11:42] m: say ' '.samemark(qq["\c[COMBINING TILDE]) [11:42] rakudo-moar 2c2934: OUTPUT«===SORRY!=== Error while compiling ␤Couldn't find terminator ] (corresponding [ was at line 1)␤at :1␤------> ay ' '.samemark(qq["\c[COMBINING TILDE])⏏␤ expecting any of:␤ ]␤» [11:42] as in can't ZWJ quotation marks [11:42] m: say ' '.samemark(qq["\c[COMBINING TILDE]]) [11:42] rakudo-moar 2c2934: OUTPUT« ̃␤» [11:42] m: say ' '.samemark(qq["\c[COMBINING TILDE]]).ord [11:42] rakudo-moar 2c2934: OUTPUT«32␤» [11:43] I wonder if that's a possible workaround for JSON::Tiny [11:43] match with :ignoremark [11:43] what does that ignore [11:44] jsut things with the 'Mark' property? [11:44] then the joiner or combining mark that's next to the " is lost [11:44] that won't solve the problem [11:44] well maybe just for that one [11:44] I don't know exactly [11:44] hmm will have to know what code triggers :ignoremark [11:44] and then I can capture the leading ", and try to extract any combiners from it [11:45] maybe i can add something to be able to do it for other types of things [11:45] git grep ignoremark in the nqp sources gives a good overview of the code paths involved [11:45] i'm assuming :ignoremark only ignores 'Mark' property though. i could be incorrect [11:45] (maybe with -C5 or so) [11:46] i will take a look moritz [11:46] thanks samcv [11:47] hmm so it looks like ignoremark may do what we want [11:49] m: say '\x[200D]t' ~~ m:ignoremark/t/ [11:49] rakudo-moar 2c2934: OUTPUT«「t」␤» [11:49] m: say '\x[200D]t' ~~ m/t/ [11:49] rakudo-moar 2c2934: OUTPUT«「t」␤» [11:50] m: say 't\x[200D]' ~~ m/t/ [11:50] rakudo-moar 2c2934: OUTPUT«「t」␤» [11:50] m: say "t\x[200D]" ~~ m/t/ [11:50] rakudo-moar 2c2934: OUTPUT«False␤» [11:50] m: say '"' ~~ m/'"'/ [11:50] rakudo-moar 2c2934: OUTPUT«「"」␤» [11:50] m: say "t\x[200D]" ~~ /t/ [11:50] rakudo-moar 2c2934: OUTPUT«Nil␤» [11:50] m: say "t\x[200D]" ~~ rx:ignoremark/t/ [11:50] rakudo-moar 2c2934: OUTPUT«「t‍」␤» [11:50] m: say "t\x[200D]" ~~ m/t/ [11:50] rakudo-moar 2c2934: OUTPUT«False␤» [11:51] m: say "t\x[200D]" ~~ m:ignoremark/t/ [11:51] rakudo-moar 2c2934: OUTPUT«「t‍」␤» [11:51] yeah ignoremark is what you want [11:51] kind of badly named ignore mark [11:51] it's still rather ugly [11:51] but yeah [11:51] which part? [11:51] of a fix? [11:52] the part where I have to look at the capture left delimiter to extract the combining characters that have been matched along with the delimiter [11:52] also there could be another problem [11:52] if I had a non-NFG string, I could ignore that whole topic, and the grammar would work as intended [11:52] m: say "\c[DEAD]" [11:52] rakudo-moar 2c2934: OUTPUT«===SORRY!=== Error while compiling ␤Unrecognized character name DEAD␤at :1␤------> say "\c[DEAD⏏]"␤» [11:53] m: say "\x[0xDBFF]" [11:53] rakudo-moar 2c2934: OUTPUT«===SORRY!=== Error while compiling ␤Unrecognized backslash sequence: '\x'␤at :1␤------> say "\x[0⏏xDBFF]"␤ expecting any of:␤ argument list␤ double quotes␤ hex character␤ term␤» [11:53] m: say "\x[DBFF]" [11:53] rakudo-moar 2c2934: OUTPUT«Error encoding UTF-8 string: could not encode codepoint 56319␤ in block at line 1␤␤» [11:53] yep [11:53] that is valid json but it won't parse [11:53] because moarvm rejects it [11:54] just based on its range and not being used in utf-8 [11:54] though since we store them not in utf-8 but as graphemes i don't see why we couldn't have that work. but [11:56] m: Uni.new(0x20, 0x55) ~~ /' '/ [11:56] rakudo-moar 2c2934: ( no output ) [11:56] m: say Uni.new(0x20, 0x55) ~~ /' '/ [11:56] rakudo-moar 2c2934: OUTPUT«「 」␤» [11:56] that works fine [11:56] but it prolly stringifies it [11:57] say Uni.new('a'.chr, 0x200D) ~~ m/t/ [11:57] m: say Uni.new('a'.chr, 0x200D) ~~ m/t/ [11:57] rakudo-moar 2c2934: OUTPUT«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏a' (indicated by ⏏)␤ in block at line 1␤␤Actually thrown at:␤ in block at line 1␤␤» [11:57] huh [11:57] what did i do wrong [11:57] m: say 0x200D [11:57] rakudo-moar 2c2934: OUTPUT«8205␤» [11:57] m: say Uni.new('a'.chr, 0x200D) ~~ m/t/ [11:57] rakudo-moar 2c2934: OUTPUT«Cannot convert string to number: base-10 number must begin with valid digits or '.' in '⏏a' (indicated by ⏏)␤ in block at line 1␤␤Actually thrown at:␤ in block at line 1␤␤» [11:57] wtf [11:58] * samcv cries [12:01] bisectable6, say Uni.new('a'.chr, 0x200D) ~~ m/t/ [12:01] samcv, On both starting points (old=2015.12 new=2c29347) the exit code is 1 and the output is identical as well [12:01] samcv, https://gist.github.com/16050c448f034f33348d0753f11f12ea [12:01] :\ [12:01] bisectable6, say Uni.new(0x200D) ~~ m/t/ [12:01] samcv, Bisecting by output (old=2015.12 new=2c29347) because on both starting points the exit code is 1 [12:01] samcv, bisect log: https://gist.github.com/78ad36dd206848c03a97f0decce7cdc4 [12:01] samcv, (2016-09-27) https://github.com/rakudo/rakudo/commit/222d16b0b94911fdedb06ee6ad817d0f14b9c05c [12:04] m: print "👨🏿‍⚕️" ~~ /"\c[BOY]"/ [12:04] rakudo-moar 2c2934: OUTPUT«Use of Nil in string context␤ in block at line 1␤» [12:05] m: my $var= "\c[BOY]"; say $var [12:05] rakudo-moar 2c2934: OUTPUT«👦␤» [12:05] m: my $var= "\c[BOY]"; print "👨🏿‍⚕️" ~~ /$var/ [12:05] rakudo-moar 2c2934: OUTPUT«Use of Nil in string context␤ in block at line 1␤» [12:05] m: 👨🏿‍⚕️".uninames.say [12:05] rakudo-moar 2c2934: OUTPUT«===SORRY!=== Error while compiling ␤Bogus statement␤at :1␤------> ⏏👨🏿‍⚕️".uninames.say␤ expecting any of:␤ prefix␤ term␤» [12:05] m: "👨🏿‍⚕️".uninames.say [12:05] rakudo-moar 2c2934: OUTPUT«(MAN EMOJI MODIFIER FITZPATRICK TYPE-6 ZERO WIDTH JOINER STAFF OF AESCULAPIUS VARIATION SELECTOR-16)␤» [12:05] oh it's not boy emoji my bad [12:06] m: print "👨🏿‍⚕️" ~~ /"\c[MAN]"/ [12:06] rakudo-moar 2c2934: OUTPUT«👨» [12:06] curious how that performs with my unicode 9 update to moar [12:06] doesn't match [12:06] moritz, ignoremark works fine \o/ [12:36] . [12:43] rakudo/nom: 8fa6d97 | usev6++ | src/core/Regex.pm: [12:43] rakudo/nom: [JVM] Type Uni is not usable on rakudo-j [12:43] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8fa6d97583 [12:43] rakudo/nom: f0c0b07 | lizmat++ | src/core/Regex.pm: [12:43] rakudo/nom: Merge pull request #980 from usev6/jvm_regex_uni [12:43] rakudo/nom: [12:43] rakudo/nom: [JVM] Type Uni is not usable on rakudo-j [12:43] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f0c0b07c71 [12:54] the good news is that the :ignoremark approach seems to work in my examples [12:54] the bad one is that it doesn't seem to work in JSON::Tiny [12:54] and I don't know yet why [13:01] moritz, can you gist it using ignoremark so i can try and investigate? [13:02] samcv: I think I found the culprit [13:03] m: say so qq["\c[COMBINING TILDE]"] ~~ / ^ :ignoremark '"'/ [13:03] rakudo-moar f0c0b0: OUTPUT«True␤» [13:03] m: say so qq["\c[COMBINING TILDE]"] ~~ / ^ :ignoremark \"/ [13:03] rakudo-moar f0c0b0: OUTPUT«False␤» [13:03] * moritz submits bug report [13:22] rakudo/nom: 1dc0c01 | lizmat++ | src/core/Proc/Async.pm: [13:22] rakudo/nom: Simplify Proc::Async.new [13:22] rakudo/nom: [13:22] rakudo/nom: Since we're using all .bless, we might as well use all of its features. [13:22] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1dc0c01522 [13:42] roast: 4cb7c23 | ronaldxs++ | S12-methods/accessors.t: [13:42] roast: fix test description typos in S12-methods/accessors.t [13:42] roast: review: https://github.com/perl6/roast/commit/4cb7c23ad3 [13:42] roast: 23de427 | ronaldxs++ | S12-methods/accessors.t: [13:42] roast: Merge pull request #210 from ronaldxs/fix-S12-methods-accessors-typo [13:42] roast: [13:42] roast: fix test description typos in S12-methods/accessors.t [13:42] roast: review: https://github.com/perl6/roast/commit/23de427f8b [14:08] I wonder if trying to prevent precomp files from depending on repository implementations loaded during precompilation is really worth it. There are probably only one or two of them in use anyway and loading them is quite fast. [14:16] \o [14:23] roast: 7df6625 | ronaldxs++ | S03-operators/precedence.t: [14:23] roast: Superscript exponent precedence tests (#205) [14:23] roast: [14:23] roast: * add precedence and associativity tests for exponentiation by unicode superscript [14:23] roast: [14:23] roast: * add RT# for superscript exponent associativity [14:23] roast: [14:23] roast: * localize some variables and make one test todo instead of skip - implementing requested changes [14:23] roast: review: https://github.com/perl6/roast/commit/7df6625288 [14:28] * bartolin runs a spectest for rakudo-j (it builds on HEAD now) [14:28] \o/ [14:29] \o/ [14:33] lizmat: have you tried https://github.com/rakudo/rakudo/pull/977 again? i just re-built NQP and rakudo and re-ran the spectest. aside from new tests (i didn't rebase the PRs), everything installed cleanly and passed the tests [14:33] bartolin++ [14:35] nine: I observed that I can use rakudo-j only after 'make install'. otherwise rakudo dies because it's unable to find BOOTSTRAP.jar. (you made commit b96bf5bd to avoid that error during 'make'). [14:35] nine: on rakudo-m it seems to work because we have a '--nqp-lib=blib' in the shell script 'perl6' [14:36] nine: do you have an idea how to get the old behaviour for rakudo-j back? [14:38] nqp: 799d160 | (Pawel Murias)++ | src/vm/ (2 files): [14:38] nqp: [js] Fix bug in serialization of NFAs. [14:38] nqp: review: https://github.com/perl6/nqp/commit/799d16047a [14:38] nqp: aa7308c | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [14:38] nqp: [js] Set the name on REPRS. [14:39] how was rakudo-j fixed? [14:42] pmurias: the primary fix was this: https://github.com/perl6/nqp/commit/e73c94f69c (though there were two or three other things broken in rakudo land) [14:42] bartolin: I'd rather we do the same trick in the perl6-j shell script [14:43] nine: ok, thanks. I'll have a look at it -- unless someone beats me at that [14:47] .ask geekosaur what were the problems with just using 1/0, -1/0, 0/0 for roundtripping? https://irclog.perlgeek.de/perl6-dev/2016-12-30#i_13826225 [14:47] notviki: I'll pass your message to geekosaur. [14:47] I don't see not producing a Rat from .Rat is better than that [14:48] m: my Rat $r = Inf.Rat [14:48] rakudo-moar 1dc0c0: OUTPUT«Type check failed in assignment to $r; expected Rat but got Rational[Num,Int] (?)␤ in block at line 1␤␤» [14:51] m: use MONKEY; augment class Num { method Rat2 { self == Inf ?? <1/0> !! self == -Inf ?? <-1/0> !! self.isNaN ?? <0/0> !! self.Rat } }; say Inf.Rat2.Num [14:51] rakudo-moar 1dc0c0: OUTPUT«Inf␤» [14:51] m: use MONKEY; augment class Num { method Rat2 { self == Inf ?? <1/0> !! self == -Inf ?? <-1/0> !! self.isNaN ?? <0/0> !! self.Rat } }; say Inf.Rat2 [14:51] rakudo-moar 1dc0c0: OUTPUT«Attempt to divide 1 by zero using div␤ in block at line 1␤␤Actually thrown at:␤ in block at line 1␤␤» [14:52] And you still have the failures on divide by zero, which this commit message says we wanted to keep? https://github.com/rakudo/rakudo/commit/498d0a4ae4572a84f80c0c572632e12017d779f3 [14:52] bartolin: good job on fixing up rakudo-j [14:52] m: my $v = <42/0>; say $v === $v.Num.Rat [14:52] rakudo-moar 1dc0c0: OUTPUT«False␤» [14:53] And we don't preserve the original form anyway right now, so roundtripping a 1/0 for 42/0 is similar [14:53] * notviki shrugs [14:54] bartolin: this (untested) patch might help getting you started: https://gist.github.com/niner/782c5c908315d72b9e39b9fe6bfb496f [15:02] great, nine++ [15:15] roast: b8bae29 | moritz++ | S05-capture/match-object.t: [15:15] roast: RT #130458: regex-matching against an NFD Uni [15:15] roast: review: https://github.com/perl6/roast/commit/b8bae29670 [15:15] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=130458 [15:20] roast: 1823c69 | moritz++ | S32-str/numeric.t: [15:20] roast: RT #130450: "a".Int returns a Failure [15:20] roast: review: https://github.com/perl6/roast/commit/1823c6908c [15:20] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=130450 [15:25] roast: 3025653 | moritz++ | S03-metaops/reduce.t: [15:25] roast: RT #128758: numeric reduce operators numify the single argument [15:25] roast: review: https://github.com/perl6/roast/commit/3025653675 [15:25] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=128758 [15:32] roast: 79aed59 | moritz++ | S17-supply/head.t: [15:32] roast: RT #126824: Supply.head [15:32] roast: review: https://github.com/perl6/roast/commit/79aed59c84 [15:32] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=126824 [16:31] nqp: 1807377 | MasterDuke17++ | src/QRegex/Cursor.nqp: [16:31] nqp: Make Cursor's $!name a str [16:31] nqp: [16:31] nqp: Hopefully turning into a native will be more efficient. [16:31] nqp: review: https://github.com/perl6/nqp/commit/1807377f6e [16:31] nqp: 0ccfb63 | lizmat++ | src/QRegex/Cursor.nqp: [16:31] nqp: Merge pull request #334 from MasterDuke17/make_Cursor_name_a_str [16:31] nqp: [16:31] nqp: Make Cursor's $!name a str [16:31] nqp: review: https://github.com/perl6/nqp/commit/0ccfb63511 [16:31] rakudo/nom: c0d8a45 | MasterDuke17++ | src/core/Cursor.pm: [16:31] rakudo/nom: Make Cursor's $!name a str [16:31] rakudo/nom: [16:31] rakudo/nom: Hopefully turning into a native will be more efficient. [16:31] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c0d8a4574c [16:31] rakudo/nom: 9eef565 | MasterDuke17++ | src/core/Cursor.pm: [16:31] rakudo/nom: Make Cursor.MATCH about 10-15% faster [16:31] rakudo/nom: [16:31] rakudo/nom: By converting more of it to NQP ops and pulling some initial variable [16:31] rakudo/nom: declarations out of loops (reducing the number of call frames and [16:31] rakudo/nom: garbage collections). [16:31] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9eef565c29 [16:31] rakudo/nom: 8ec578e | lizmat++ | src/core/Cursor.pm: [16:31] rakudo/nom: Merge pull request #977 from MasterDuke17/make_Cursor_name_a_str [16:43] rakudo/nom: d7cd5df | lizmat++ | tools/build/NQP_REVISION: [16:43] rakudo/nom: Bump NQP to get the Cursor fixes [16:43] rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d7cd5dff8c [16:56] roast: e6aa85b | usev6++ | S (7 files): [16:56] roast: Unfudge some passing tests on JVM [16:56] roast: review: https://github.com/perl6/roast/commit/e6aa85be09 [17:10] Rakudo build failed. lizmat 'Merge pull request #977 from MasterDuke17/make_Cursor_name_a_str [17:10] https://travis-ci.org/rakudo/rakudo/builds/187918366 https://github.com/rakudo/rakudo/compare/1dc0c0152272...8ec578e4dbbb [17:11] [travis build above] ☠ Did not recognize some failures. Check results manually. [17:11] * lizmat assumes because travis didn't see the nqp bump yet [17:11] "P6opaque: invalid native access attribute '$!name' in type Cursor for kind str" [17:12] Was there an nqp bump? [17:12] yup that's the one [17:12] yes, about 30 mins ago [17:12] ah, now I see it [19:27] roast: e89914d | usev6++ | S (15 files): [19:27] roast: Fudge for X::Assignment::RO on JVM, RT #130470 [19:27] roast: review: https://github.com/perl6/roast/commit/e89914d71d [19:27] Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=130470 [19:40] hmm. RE the unicmp_s function. it returns an int. i'm thinking of making it return different things [19:40] it returns -1, 0 or 1. i'm thinking if it falls back to comparing by codepoint instead of any collation value it should return +2 or -2 [19:40] thoughts? [19:41] or maybe should be the other way around, -2 and +2 for when the collation is used and -1 and +1 when we fallback to by codepoint [19:48] or maybe have it return based on which collation level it used in the end. so -1 and +1 for primary, if those are the same then collation level 2 is used for diacritics and such, return -2 +2, for tertiary etc etc [19:48] and -4 and +4 if it falls back to codepoint [19:48] for the quaternary level [19:58] roast: 6dad257 | usev6++ | S0 (2 files): [19:58] roast: Fudge some tests for JVM [19:58] roast: review: https://github.com/perl6/roast/commit/6dad257a5b [19:59] and need to see how to handle collation values of zero. because atm characters with _no_ collation value show up as zero. but i need a way to distinguish between 0 and no value [20:06] use nqp; nqp::unicmp_s('a', 'A',7, 0, 0 ) #> -3 [20:06] i like that. can easily tell what decided the collation [20:07] though also need to think, how to denote that one of the characters has no collation value and it's not that it checked all three properties and those were all equal so went to tertiary for codepoint numerical comparison [20:16] samcv: It's an interesting idea, but I have to wonder if it falls under the "you think it's cute now ..." umbrella, because if we canonicalize it as part of the API, it then becomes something we have to support in the future ... even if we find an implementation that e.g. manages to handle all levels of collation at once and thus doesn't *know* which one was the tie-breaker. [20:17] hm [20:17] true [20:17] (This isn't just an idle thought -- if indeed all collation is in terms of numbers, with fixed ranges per Unicode release, we could use big numbers composed of multiplying the most important one by the size of the next most, and adding them, that sort of thing.) [20:17] Just as an example. [20:17] hm [20:18] that is not very helpful though [20:18] to know what level it went to [20:18] could just have -5 +5 mean it doesn't know what it did [20:18] Anyway, the point is mostly ... decide if this is just a useful side effect of *the current implementation* of collation, or if it is something we want to make *required* of all implementations. [20:18] since the only defined levels are primary secondary and tertiary [20:18] or maybe something bigger just in case [20:18] All implementations ever. [20:19] idk some number [20:19] For example, how are you going to do this on jvm and js? Will these be able to easily produce collation information like that. [20:19] ? [20:19] * japhb goes afk for a bit [20:20] so some implementations might only implement the 4th level by codepoint, so could return some value saying they only checked codepoint [20:21] but if they are doing collation they could set it to 7 which means 3 levels, and if it gets back 'equal' to do it by codepoint and return said value [20:23] japhb, in java: [20:23] You can set a Collator's strength property to determine the level of difference considered significant in comparisons. Four strengths are provided: PRIMARY, SECONDARY, TERTIARY, and IDENTICA [20:24] though getting back the info on which it used idk if you can [20:25] well you could do primary then secondary then tertiary but that's more wor [20:25] there _has_ to be some way to tell if it's by codepoint or based on the collation property though [20:26] -10/10 could just be by codepoint, and then return another value. on backends not supporting it just return the value of the collation level requested [20:27] i use a bitmask to choose which levels of collation to do atm. so on moarvm at least you can pick whichever you want even though other ones probably don't support that, like doing level 1 and 3 if you don't want to care about like accent marks or something [21:16] Files=1159, Tests=54478, 188 wallclock secs (11.29 usr 4.72 sys + 1225.64 cusr 127.61 csys = 1369.26 CPU) [21:21] * lizmat goes back to drinking beer and waiting for the end (or the beginning, depending on perspective) [23:20] lizmat: The beginning of the end?