[00:04] compiling an older glibc with a newer gcc, a tiny bit of hell [00:06] *** oddp left [00:10] noooooope [00:15] erl6-m: /home/timo/build/glibc-2.27/buildfolder/libc.so.6: version `GLIBC_2.28' not found (required by //home/timo/perl6/install/lib/libmoar.so) [00:15] that's it [00:17] *** wildtrees left [00:24] https://stackoverflow.com/a/10772056/804005 - i don't wanna [00:32] /usr/bin/ld: /usr/lib64/libpthread.so.0: undefined reference to `__open64_nocancel@GLIBC_PRIVATE' [00:33] someone tell the pthread devs not to rely on glibc internals [04:50] *** Xliff joined [04:50] \o [04:50] How can I fix "Missing or wrong version of dependency 'gen/moar/stage2/QAST.nqp' (from 'gen/moar/BOOTSTRAP/v6c.nqp')" [04:51] I shouldn't be getting these kinds of errors! :( [05:08] ^^ jnthn timotimo vrurg AlexDaniel lizmat [05:08] Even nuking nqp/ doesn't fix the issue. [05:49] *** Xliff left [07:11] *** JJMerelo joined [07:47] *** sena_kun joined [08:27] *** vrurg left [08:29] *** vrurg joined [08:32] *** oddp joined [09:12] *** Altai-man_ joined [09:14] *** sena_kun left [09:18] Files=1308, Tests=113043, 217 wallclock secs (29.03 usr 8.23 sys + 3031.14 cusr 291.81 csys = 3360.21 CPU) [09:19] .tell Xliff nuking install fixes it for me, and dogbert17 had another way of dealing with it [09:19] lizmat, I'll pass your message to Xliff [09:23] .tell Xliff https://github.com/rakudo/rakudo/issues/3798 [09:23] lizmat, I'll pass your message to Xliff [09:26] *** JJMerelo left [09:28] raku: class C { }; my \px = C.new; sub postcircumfix:«< >»(C $c is raw) { dd $c; }; px; [09:28] gfldex, rakudo-moar 8543f855b: OUTPUT: «(exit code 1) 04===SORRY!04=== Er…» [09:28] gfldex, Full output: https://gist.github.com/539c79c767e4b7d412873b3bc06c4a19 [09:28] are custom postcircumfix forbidden by Raku? [09:29] so is this LTA, Rakubug or ENODOC? [09:34] *** JJMerelo joined [09:36] *** patrickb joined [09:37] vrurg, Altai-man: I'll probably won't find time today to look into the NQP bump problem. I think I will find some time tomorrow. [09:37] :-( [09:38] *** patrickb left [09:44] *** MasterDuke joined [09:50] Any idea what this " Anchors ^, ^^, $, and $$ are valid in lookarounds" is supposed to mean? [09:50] It does not seem to be literally true [09:51] my regex key { \d+ }; say "333" ~~ &key [09:51] Not that there would be any difference with just using ^^ directly, since they are zero-width [09:52] m: my regex key { \d+ }; say "333" ~~ &key [09:52] rakudo-moar 85320f466: OUTPUT: «Potential difficulties:␤ Repeated character (^) unexpectedly found in character class␤ at :1␤ ------> 3my regex key { \d+ }; say "333" ~~ &key␤Nil␤» [09:52] m: my regex key { \d+ }; say "^333" ~~ &key [09:52] rakudo-moar 85320f466: OUTPUT: «Nil␤» [09:52] m: my regex key { \d+ }; say "333" ~~ &key [09:52] rakudo-moar 85320f466: OUTPUT: «Nil␤» [09:53] m: my regex key { \d+ }; say "^333" ~~ &key [09:53] rakudo-moar 85320f466: OUTPUT: «Nil␤» [09:53] m: my regex key { \d+ }; say "^333" ~~ &key [09:53] rakudo-moar 85320f466: OUTPUT: «Potential difficulties:␤ Quotes are not metacharacters in character classes␤ at :1␤ ------> 3my regex key { \d+ }; say "^333" ~~ &key␤ Repeated character (") unexpectedly found in character class␤ at m: my regex key { \d+ }; say "^333" ~~ &key [09:53] rakudo-moar 85320f466: OUTPUT: «Nil␤» [09:54] m: my regex key {<[^]> \d+ }; say "^333" ~~ &key [09:54] rakudo-moar 85320f466: OUTPUT: «「^333」␤» [09:55] gfldex: feels like worthy of an issue [09:56] commit: releases say '333$' ~~ m/ \d+ / [09:57] JJMerelo, ¦releases (44 commits): «「333」␤» [09:57] commit: releases say '^333' ~~ m/ \d+ / [09:58] JJMerelo, ¦releases (44 commits): «False␤» [09:58] Hum [09:59] lizmat could that be a but? [09:59] s^but^bug^ [10:00] possibly, moritz might understand why [10:01] lizmat: filed as R#3799 [10:01] R#3799 [open]: https://github.com/rakudo/rakudo/issues/3799 custom postcircumfix are neither allowed nor forbidden [10:02] m: say '333$' ~~ m/ \d+ / [10:02] rakudo-moar 85320f466: OUTPUT: «Potential difficulties:␤ Repeated character ($) unexpectedly found in character class␤ at :1␤ ------> 3say '333$' ~~ m/ \d+ /␤「333」␤» [10:06] lizmat: filed too as R#3800 [10:06] R#3800 [open]: https://github.com/rakudo/rakudo/issues/3800 "Anchors valid in lookarounds": what does it mean. Plus: circumflex in lookaround does not work. [10:13] *** JJMerelo left [10:19] *** vrurg left [10:20] *** vrurg joined [10:21] *** sena_kun joined [10:23] *** Altai-man_ left [10:24] *** vrurg left [10:56] *** vrurg joined [10:57] *** vrurg left [10:57] *** vrurg joined [11:11] what even is the syntax? [11:23] timotimo: the json_fast test-suite determines that {"\uDFAA":0} should be invalid, yet any online validator that I use thinks it's valid ? [11:24] ah, i wonder what the idea behind that test was [11:24] well, since the value \uDFAA is higher than \D800, it indicates a high surrogate [11:24] but there's no low surrogate [11:25] ah, ok [11:25] looks like we got it from JSONTestSuite's tests [11:27] "result undefined, parsing succeeded" and "result undefined, parsing failed" are almost all parser's results for this [11:27] only one crashes [11:27] which was an older version of swift's STJSON parser apparently [11:27] we throw an exception? [11:27] it expected to fail, yes [11:27] and my new code it doesn't [11:27] matching the online validators [11:28] looks like we're free to decide whatever result we want [11:28] what does the string that comes out look like? [11:28] basically, if we encounter a \uD800 or higher, we assume its the high surrogate only if it is followed by another \u [11:28] uniname is: "" [11:30] hmm [11:30] "" for DFAA of course [11:30] what if we see only the other surrogate [11:31] the one that's supposed to come behind [11:31] I suspect similar code points, the cutoff is at DC00 for the low part [11:32] if its below that, I assume the "high" part is a code on its own, and the "low" part as well [11:33] fwiw, my code takes the sample I have from 3.2 secs to 1.2 seconds :-) [11:33] *nice* [11:37] rejecting would be a performance hit? [11:37] all tests pass if I comment out these cases [11:37] rejecting which ones [11:37] ? [11:38] rejecting the ones that the test suite says should be rejected [11:38] when surrogates are somehow invalid [11:39] m: say "\u[DFAA]".raku; say "\u[DFAA]" [11:39] then other test break, oddly enough, lemme double check again [11:39] rakudo-moar 85320f466: OUTPUT: «5===SORRY!5=== Error while compiling ␤Unrecognized backslash sequence: '\u'␤at :1␤------> 3say "\7⏏5u[DFAA]".raku; say "\u[DFAA]"␤ expecting any of:␤ argument list␤ double quotes␤ term␤» [11:39] m: say "\x[DFAA]".raku; say "\x[DFAA]" [11:39] rakudo-moar 85320f466: OUTPUT: «Error encoding UTF-8 string: could not encode Unicode Surrogate codepoint 57258 (0xDFAA)␤ in block at line 1␤␤» [11:39] m: say "\x[DFAA]".raku; say "\x[DFAA]".encode("utf8-c8") [11:39] rakudo-moar 85320f466: OUTPUT: «Error encoding UTF-8 string: could not encode Unicode Surrogate codepoint 57258 (0xDFAA)␤ in block at line 1␤␤» [11:39] yeah, that :-) [11:39] hmmmm [11:40] m: my $a = "\x[DFAA]" [11:40] rakudo-moar 85320f466: ( no output ) [11:40] m: my $a = "\x[DFAA]".raku [11:40] rakudo-moar 85320f466: ( no output ) [11:40] m: say "\x[DFAA]".raku [11:40] rakudo-moar 85320f466: OUTPUT: «Error encoding UTF-8 string: could not encode Unicode Surrogate codepoint 57258 (0xDFAA)␤ in block at line 1␤␤» [11:40] well, this is certainly not what we want [11:41] * lizmat goes back to the drawing board [11:46] "\uabcd\uef4A" should that be ok or not? [11:47] I'd say: not, because the first \u is not higher than d800, and the second one is, so high surrogate with a missing low surrogate [11:47] this is not a JSONSuite test [11:48] current JSON::Fast lets that pass [11:48] from-json(Q/"\uabcd\uef4A"/).uninames [11:48] lizmat, rakudo-moar 8543f855b: OUTPUT: «Saw 1 occurrence of deprecated code.␤==========…» [11:48] lizmat, Full output: https://gist.github.com/983f7b0e75740058acdfc019d22cce4e [11:48] m: from-json(Q/"\uabcd\uef4A"/).uninames [11:48] rakudo-moar 85320f466: OUTPUT: «Saw 1 occurrence of deprecated code.␤================================================================================␤Sub from-json (from GLOBAL) seen at:␤ , line 1␤Please use JSON::Fast, JSON::Tiny or JSON::Pretty from https://modules.r…» [11:49] m: dd from-json(Q/"\uabcd\uef4A"/).uninames [11:49] rakudo-moar 85320f466: OUTPUT: «("MEETEI MAYEK LETTER HUK", "").Seq␤Saw 1 occurrence of deprecated code.␤================================================================================␤Sub from-json (from GLOBAL) seen at:␤ , line 1␤Please use JSON:…» [11:52] *** oddp left [11:52] hmm, String.raku could become a *little* more expensive if it is to turn such unencodable stuff into escape sequences [11:53] so it seems I'm missing some logic here [12:20] *** Altai-man_ joined [12:23] *** sena_kun left [12:28] *** wildtrees joined [12:30] *** wildtrees left [12:30] *** wildtrees joined [12:51] *** lucasb joined [12:53] *** oddp joined [13:13] *** vrurg left [13:17] *** vrurg joined [14:10] timotimo: this contained the clue: https://en.wikipedia.org/wiki/UTF-16#Description [14:10] U+0000 to U+D7FF and U+E000 to U+FFFF [14:14] timotimo: from-json now 2.5x as fast :-) [14:14] wow [14:17] removing the check in nom-ws also seems to work out nicely: 1200 -> 900 msecs for my benchmark [14:18] which, without 200 msecs overhead, would make it 1.4x as fast again [14:21] *** sena_kun joined [14:22] *** vrurg left [14:23] *** vrurg joined [14:23] *** Altai-man_ left [14:27] *** vrurg left [14:28] heck yeah [14:34] which makes the total speed increase from the published version to this new version to 4.4x faster in total [14:42] as fast vs faster? [14:42] so 5.4x faster? [14:45] *** vrurg joined [14:55] sorry, as fast [14:55] 4.4x as fast [14:55] still pretty rad, I'd say :-) [14:56] this should probably be notiecable in zef reading of module data [14:56] once it is in the core, of course [14:59] timotimo: I think I'm done with this round of optimizations [14:59] very good. should i merge and release? [14:59] des the code end up rejecting the stuff we talked about? [14:59] eh... now I'm not sure... it's test clean ? [15:00] *without* changes to the tests [15:00] :-) [15:00] so it should act more or less the same as before ? [15:01] OK [16:04] *** Xliff joined [16:04] . [16:04] 2020-07-18T09:19:59Z #raku-dev Xliff nuking install fixes it for me, and dogbert17 had another way of dealing with it [16:04] 2020-07-18T09:23:24Z #raku-dev Xliff https://github.com/rakudo/rakudo/issues/3798 [16:16] lizmat++ [16:20] *** Altai-man_ joined [16:23] *** sena_kun left [16:44] *** vrurg left [16:44] *** vrurg joined [16:48] *** vrurg left [16:49] *** Xliff left [17:16] *** vrurg joined [18:22] *** sena_kun joined [18:22] *** vrurg left [18:23] *** vrurg joined [18:23] *** Altai-man_ left [18:27] *** vrurg left [18:29] *** wildtrees left [18:30] *** wildtrees joined [18:41] *** vrurg joined [19:03] *** sena_kun left [19:05] *** sena_kun joined [19:47] *** wildtrees left [19:49] *** wildtrees joined [19:50] *** wildtrees left [19:51] *** wildtrees joined [19:53] *** wildtrees left [19:55] *** wildtrees joined [19:57] *** wildtrees left [19:58] *** wildtrees joined [20:01] *** wildtrees left [20:03] *** wildtrees joined [20:05] *** wildtrees left [20:06] *** wildtrees joined [20:07] *** wildtrees left [20:08] *** wildtrees joined [20:10] *** wildtrees left [20:11] *** wildtrees joined [20:13] *** wildtrees left [20:13] *** wildtrees joined [20:21] *** Altai-man_ joined [20:23] *** sena_kun left [21:55] *** Altai-man_ left [22:06] *** sena_kun joined [22:21] *** Altai-man_ joined [22:23] *** sena_kun left [22:32] *** vrurg left [23:49] ¦ rakudo/rakuast: a1bd2d2a82 | (Jonathan Worthington)++ | 7 files [23:49] ¦ rakudo/rakuast: RakuAST for `when` and `default` [23:49] ¦ rakudo/rakuast: review: https://github.com/rakudo/rakudo/commit/a1bd2d2a82