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

Powered by Cro and the Raku® Programming Language.

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

Thank you!