github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 06:36
jnthn o/ 10:26
nwc10 \o 10:27
lizmat looks like nqp::splce needs some love: github.com/rakudo/rakudo/issues/40...-743239062 15:01
re: github.com/rakudo/rakudo/issues/4102 15:36
looking at src/strings/windows1251.c 15:37
it looks like it is just missing some conversion tables / mappers to get support for all of the other windowsxxxx encodings, right ?
which could almost be automated, given a good data source ?
jnthn For the windows ones? Not sure, it really depends if they are all 8-bit width, which I don't know off hand 16:11
The policy question is if we want to ship them all in core
lizmat afaik they're all 8-bit 16:18
so relatively simple
or would you rather have it in HLL ?
jnthn Well, for the Windows ones, each one will add probably something like half a kb 16:20
And it seems like there's a dozen or so, not hundreds
So it's not really a big issue
Assuming we maybe refactor things so that they mostly just re-use code and have a different table 16:21
But some, especially the Chinese/Japanese ones, will be far more data and far more involved, I expect
I guess it's nice if these things Just Work out of the box 16:23
And it's not like we are minimal about much else :)
lizmat indeed :-) 16:38
I was also wondering about the: 16:39
switch (codepoint) {
case 160: return 160;
structure: I guess that's the optimal way of doing that rather then indexing into an array ?
jnthn Depends if there's ranges that overlap 16:40
Well, and also, hard to know without profiling :)
lizmat could be compilers do that for you, but looks like 160 .. 255 just return self
leont Encodings vary greatly in difficulty of implementing, but the 8 bit ones should be trivial
jnthn But it's possible it's a little more cache friendly and code size friendly if there's a lot of overlap
I wonder also if the code in there is genreated 16:41
*generated
lizmat would be nice then if the generator left a clue :-)
leont Encode.pm in perl generates most of it's conversion tables AFAIK, it may be possible to re-use those tables
lizmat
.oO( interesting module to port to raku )
16:42
leont github.com/Perl/perl5/tree/blead/c...Encode/ucm 16:43
It's probably mainly a matter of replacing enc2xs with a enc2nqp 16:47
Apparently UCM files are a unicode consortium thingie, even better 16:54
There's also a competing xml format, because of course -_- 16:56
Geth MoarVM: 70cefcfffc | (Nicholas Clark)++ | src/math/bigintops.c
Minimally exact bigint/bigint => num conversion, including rounding.

Given that Rakudo parses decimal constants such as 0.01 as `Rat`s (ie represents them internally as (1 / 100), and persists with this exact representation as long as possible), this effectively means that the MoarVM operator that converts `Rat`s to `Num`s implements Rakudo's decimal => binary floating point conversion. ... (161 more lines)
17:36
MoarVM: 82a34e25a8 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/math/bigintops.c
Merge pull request #1384 from MoarVM/bigint_div_num-IEEE-rounding

Minimally exact bigint/bigint => num conversion, including rounding.
timotimo tib: can you check if there's a big difference between .starts-with($n) with $n being 123 and .starts-with($s) with $s being "123"? i.e. not coercing to string for every check 17:46
MasterDuke timotimo: there are some questions/comments on github.com/MoarVM/MoarVM/pull/1399 that i think you could help out with 19:59
tib timotimo : I can’t check at the moment. 20:45