Geth rakudo: 6a89d716be | (Perry Thompson)++ | src/core.c/Process.pm6
Force "id" command to use POSIX locale

This is a temporary workaround to ensure that $*USER and $*GROUP don't return Nil on non-English locales.
Resolves #3927.
09:32
rakudo: 62a22d0fe4 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/Process.pm6
Merge pull request #3940 from rypervenche/user-group

Force "id" command to use POSIX locale
linkable6 RAKUDO#3927 [closed]: github.com/rakudo/rakudo/issues/3927 $*USER and $*GROUP gives Nil output with different locales
tbrowder hi, was there any consenus on adding a $*UNICODE or similar to give unicode version being used? 11:27
[Coke] tbrowder: probably worth creating a problem-solving ticket. (which I thought I had done years ago, but cannot find one. 12:26
tbrowder ok 12:27
lizmat since I don't think we can actually switch Unicode versions during execution, that should probably be a $?UNICODE variable 12:40
timotimo not during execution, but you could feasibly switch moarvm versions without it forcing a rebuild of the precompiled data 12:41
[Coke] I imagine that's a feature people would want, but I don't think any of our uni infrastructure would support that. 12:42
timotimo or do we have something that does that?
[Coke] timotimo: but the rakudo unicode version would still be 'constant' over a runtime of raku 12:43
lizmat timotimo: afaik, precomps are tied to the version of the backen
d
so I don't think you could share precomps between different MoarVM versions ?
jdv79 would there be a var for every dep? if its tied to moarvm isn't that a sufficient surrogate?
lizmat if I'm right, I guess we should expose that value, with possble other constants, in an NQP op, and let codegen handle $?UNICODE to that nqp op 12:45
timotimo we may be able to just get it as an hll sym
or inside the backendconfig
lizmat yup, that would work :-) 12:46
timotimo we need a place to put the unicode version, possibly in the ucd2c.pl script, because that's what we're already running when we update to a new unicode version 13:40
after that, it's pretty easy to get it into the backendconfig, i think we literally just generate a header or .c file that sets up the values
[Coke] speaking of unicode, what's the current version supported by rakudo/moarvm? 13:52
12?
lizmat think so, we're lagging :-(
[Coke] 12.1, looks like 13:53
[Coke] I was claiming 9 a few years ago so at least we're moving in the right direction. :) 13:53
[Coke] updates a few p6- labeled modules. 13:56
found the roast test data file we used to keep back in the day when we had multiple backends. 13:57
might be nice to resurrect that for moarvm/jvm/JS backends, but we don't have any other non rakudo backends to test at this point.
github.com/coke/perl6-roast-data (last updated pre-christmas, I think) 13:58
github.com/coke/raku-lingua-en-syl...e.rakumod, showing you can still write perl 5 code in Raku. :| 14:00
ugexe github.com/ugexe/Acme--Polyglot--L...n--Damerau — I once wrote an entire raku module in perl 5 17:01
tellable6 2020-09-21T15:50:59Z #raku <[Coke]> ugexe results are submitted, congratulations (RSC)
bartolin hurls github.com/usev6/perl6-roast-data (an old fork of [Coke]++'s repo -- as not been updated daily but from time to time) 18:17
timotimo liz has been outputting her summaries into the channel 18:31
[Coke] wonders what github.com/perl6/book/pull/90 was 18:52
bartolin++
We should probably get that going into ... whatever the cool kids are using 18:53
ugexe [Coke]: if you are testing your library by passing -I. or -Ilib, then it should be getting chosen over installed versions since those repos (the default repos) come after the additional repo (-I.) 23:36
Geth rakudo: thundergnat++ created pull request #3942:
Update tests for Unicode 13.0, 13.1
23:56