|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:32
frost-lab joined
01:30
lucasb left
01:37
klapperl_ joined
01:39
klapperl left
01:40
MasterDuke left
03:07
evalable6 left,
linkable6 left,
tellable6 left,
tellable6 joined
03:10
linkable6 joined,
evalable6 joined
03:28
leont left
05:29
evalable6 left,
linkable6 left
05:31
linkable6 joined
05:32
evalable6 joined
05:34
leedo left,
leedo joined
|
|||
| nwc10 | good *, #moarvm | 06:36 | |
|
07:40
patrickb joined
07:52
sena_kun joined
07:54
domidumont joined
09:03
zakharyas joined
09:07
Altai-man joined
09:10
sena_kun left
09:50
lizmat_ joined
09:53
lizmat left
|
|||
| jnthn | o/ | 10:26 | |
| nwc10 | \o | 10:27 | |
|
10:49
lizmat_ is now known as lizmat
11:06
zakharyas left
11:10
zakharyas joined
11:13
squashable6 left
11:14
squashable6 joined
11:59
leont joined
12:26
Altai-man left,
Altai-man joined
12:27
squashable6 left
12:30
squashable6 joined
12:52
frost-lab left
13:08
sena_kun joined
13:10
Altai-man left
14:30
zakharyas left
|
|||
| 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 | ||
|
17:07
Altai-man joined
17:10
sena_kun left,
MasterDuke joined
17:14
zakharyas joined
17:36
domidumont left
|
|||
| 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 | |
|
18:57
zakharyas left
19:09
zakharyas joined
|
|||
| MasterDuke | timotimo: there are some questions/comments on github.com/MoarVM/MoarVM/pull/1399 that i think you could help out with | 19:59 | |
|
20:39
Kaiepi left,
Kaiepi joined
|
|||
| tib | timotimo : I can’t check at the moment. | 20:45 | |
|
21:08
sena_kun joined
21:09
Altai-man left
21:29
zakharyas left
21:51
MasterDuke left
22:10
sena_kun left
22:26
patrickb left,
Geth left,
Geth joined
|
|||