[02:20] *** linkable6 left
[02:20] *** evalable6 left
[02:21] *** evalable6 joined
[02:22] *** linkable6 joined
[06:37] *** sena_kun joined
[08:54] *** zakharyas joined
[09:21] *** Altai-man joined
[09:24] *** sena_kun left
[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: ee404e164d | (Nicholas Clark)++ | src/6model/reprs/CStruct.c

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: In CStruct `bind_attribute`, don't `set_ptr_at_offset` for inlined CArray.

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: 

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: `bind_attribute` had been calling `set_ptr_at_offset` for all `CArray`s,

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: whether inlined or not. That writes a pointer at the slot offset.

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: 

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: For the corner case of the inlined array being both the last member in the

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: structure and smaller than the size of a pointer

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: <…commit message has 23 more lines…>

[10:06] <Geth> ¦ MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: review: https://github.com/MoarVM/MoarVM/commit/ee404e164d

[10:21] <Geth> ¦ MoarVM: nwc10++ created pull request #1369: CStruct bind_attribute can write beyond malloc'd buffer.

[10:21] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1369

[10:23] <Geth> ¦ MoarVM/master: 4 commits pushed by (Nicholas Clark)++, nwc10++

[10:23] <Geth> ¦ MoarVM/master: a37cd76332 | The inline `memcpy` replacement can be used on all little-endian platforms.

[10:23] <Geth> ¦ MoarVM/master: cbb92b038b | The inline `memcpy` replacement can be adapted for big-endian platforms.

[10:23] <Geth> ¦ MoarVM/master: dfbdcc9de8 | Add casts to calls to `switch_endian` to avoid compiler warnings.

[10:23] <Geth> ¦ MoarVM/master: d7a2c9feb5 | Merge pull request #1365 from MoarVM/big-endian-deserialisation

[10:23] <Geth> ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/5c791a48106e...d7a2c9feb5f0

[10:30] <nwc10> .seen froggs

[10:30] <tellable6> nwc10, I saw froggs 2019-09-15T13:29:14Z in #perl6: <FROGGS> uhhh, that sounds awesome

[10:31] <nwc10> I doubt that he really wanted to be a reviewer. github suggested him

[10:53] <nine> The repetition between CStruct, CPPStruct and CUnion has bitten us countless times

[10:53] <nwc10> If I go "back" to commit 163ee73f6eafc44c89a7ed5145ad8b99c7907274

[10:54] <nwc10> at that commit diff between CStruct.c and CPPStruct.c seems to be pretty much s/CPP/C/ and s/cpp/c/

[10:54] <nwc10> (and some whitespace)

[10:54] <nwc10> I'm not totally sure why the two need to be distinct, other than having a different repr name in error messages, and a different repr ID

[10:55] <nwc10> if that *is* all that needs to differ, I think I can see how to merge them, and "instantiate" two with #include and 2 macros

[10:55] <nwc10> (Since that commit they have diverged a lot, and I'm wondering if most of that divergence is bugs)

[10:56] <lizmat> nwc10++    # making code DRYer

[10:56] <nwc10> but "AFK" I wodnered if the *union* is also (pretty much) CStruct, just without addign size to offset each time round the loop

[10:56] <nwc10> lizmat: I can't promise that I am correct. This is code that I really don't undestand

[10:56] <nwc10> I can just see a lot of patterns

[10:56] <nwc10> and a commit message that suggests that it shouldn't be that different

[10:57] <lizmat> perhaps because you do not really understand the code, you can see the patterns  :-)

[10:57] <nwc10> and I am guilty of DRY-violations with all the hash stuff. But I can't see how to "Template" that without the result being worse thatn what we have

[10:57] <nine> I think those 3 can be unified a lot

[10:57] <nwc10> I can see patterns in code I understand too

[10:57] <nwc10> OK, right now I'm off trying to fix all the big endian test bugs

[10:58] <nwc10> or, maybe also, AFK

[10:58] <nwc10> on "hoilday"

[10:58] <nine> Well we've lived with the duplication for years....we can grant you a couple hours off before unifying them ;)

[10:59] <nwc10> it needs at least 1 competant reviewer

[10:59] <nwc10> and also I don't think that this stuff has enoguh tests

[10:59] * nine is looking at #1369 right now

[10:59] <nwc10> thanks

[11:00] <nwc10> given that I don't think that rakudo/rakudo#3687 added any tests

[11:00] <linkable6> RAKUDO#3687 [closed]: https://github.com/rakudo/rakudo/issues/3687 Binding to an inlined CStruct does not do what it means

[11:00] <nwc10> also, it's hard to add tests, because I can't see the right way to add them with "this will pass once MoarVM gets to *that* revision, but until then it's TODO"

[11:00] <nine> Just add the NQP/MoarVM bump to the same commit that adds the tests

[11:17] <nwc10> also, it seems that dyncall is (slightly) architecturally buggy, as it looks like they also have a known failure on ppc32

[11:17] <nwc10> (but I have not gone tryign to find out what the Power ABI spec is)

[11:18] <nwc10> basically, dyncall implements `unsigned short` and `unsigned char` arguments by casting to `short` and `char` respectively and using those functions

[11:18] <nwc10> which loses the info about whether the 16 or 8 bit thingy was signed or unsigned

[11:18] <nwc10> and seems that this matters on ppc32 *too*

[11:18] <nwc10> looks like libfii doesn't have this problem

[11:18] <nwc10> but as best I can tell *that* was "more by luck than judgement"

[11:19] <nwc10> ie - using libffi rather than dyncall on sparc linux gets us one more test passin g

[11:19] <nwc10> 02-simple-args.t

[11:20] <nine> Good thing my NativeCall JIT code only works on x86_64 ;) I'm pretty sure I did similar things there

[11:20] <nwc10> who is Aleks-Daniel Jakimenko-Aleksejev [email@hidden.address] ?

[11:20] <nine> AlexDaniel on IRC

[11:20] <nwc10> aha

[11:33] <Geth> ¦ MoarVM: 4ced726fed | (Nicholas Clark)++ | 4 files

[11:33] <Geth> ¦ MoarVM: Use MVM_{malloc,realloc,calloc,free} consistency.

[11:33] <Geth> ¦ MoarVM: 

[11:33] <Geth> ¦ MoarVM: All these calls changed to the MVM_* wrappers are on memory blocks where the

[11:33] <Geth> ¦ MoarVM: other calls are MVM_* wrappers.

[11:33] <Geth> ¦ MoarVM: 

[11:33] <Geth> ¦ MoarVM: There are still a few "bare" `malloc`s/`free`s, but these seem to be

[11:33] <Geth> ¦ MoarVM: self-contained, or related to memory allocated by `strdup`/`strndup`, which

[11:33] <Geth> ¦ MoarVM: is using the platform `malloc` internally.

[11:33] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ced726fed

[11:41] *** patrickb joined
[12:35] *** zakharyas left
[12:54] *** brrt joined
[12:55] <brrt> \o

[12:55] <tellable6> 2020-10-24T19:43:42Z #moarvm <nwc10> brrt it's getting worse. Now I'm looking at assembler output from *gdb*

[12:56] <brrt> .tell nwc10 so you've crossed the rubicon

[12:56] <tellable6> brrt, I'll pass your message to nwc10

[13:07] <nwc10> o/

[13:07] <tellable6> 2020-10-26T12:56:08Z #moarvm <brrt> nwc10 so you've crossed the rubicon

[13:18] <lizmat> And yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/10/26/2020-43-release-and-star/

[13:22] *** sena_kun joined
[13:24] *** Altai-man left
[13:40] *** zakharyas joined
[13:41] *** patrickb left
[13:46] *** sena_kun left
[13:57] *** lucasb joined
[14:45] <brrt> lizmat++

[14:50] *** domidumont joined
[16:03] <brrt> /query nwc10

[16:03] <brrt>  

[16:21] <nwc10> x

[16:22] *** brrt left
[16:22] *** sena_kun joined
[16:22] <nwc10> oh. I scared his client :-(

[16:23] * lizmat didn't know that "boo" was spelled "x" in client speak

[16:25] <nwc10> I claim that it's the simplest possible explanation

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: 55964708fa | (Nicholas Clark)++ | src/strings/utf16.c

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: `swap_bytes` in utf16.c needs to also swap bytes on big endian platforms.

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: 

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: The way it had been written worked perfectly on little endian platforms, and

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: was actually a no-op on big endian platforms, because it *read* from memory

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: in fixed (little endian) order, but wrote back using bitwise operations,

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: meaning that the read acted as a second byte swap on big endian platforms.

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: This was somewhat LTA.

[16:26] <Geth> ¦ MoarVM/utf16-swap-bytes-BE-too: review: https://github.com/MoarVM/MoarVM/commit/55964708fa

[16:27] <Geth> ¦ MoarVM: nwc10++ created pull request #1371: `swap_bytes` in utf16.c needs to also swap bytes on big endian platforms

[16:27] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1371

[16:27] <nwc10> lets see what the automated tests think of that.

[16:52] *** domidumont left
[17:03] <nine> That whole interning of parametrics thing is horribly complicated :/

[17:15] <nwc10> meanwhile:

[17:15] <nwc10> nick@gcc202:~/Perl/rakudo$ ./rakudo-m -e 'my uint8 $var = 255; say $var'        255

[17:15] <nwc10> nick@gcc202:~/Perl/rakudo$ ./rakudo-m -e 'my uint8 $var = 255; my $x = $var; say $x'

[17:15] <nwc10> -72057594037927936

[17:15] <nwc10> that's 0xff00000000000000

[17:15] <nwc10> I have some idea how to find that cause of that. Let's see how long it takes

[17:15] <nine> Our whole uint support is a bit of a mess

[17:16] <nwc10> it's more of a mess on big endian platforms

[17:16] <nwc10> I see a bunch of TODOs in the spectest that suggest that uint64 doesn't work too well

[17:17] <timotimo> yeah, uint is kind of wild

[17:24] <nwc10> OK, what am I doing wrong. How am I meant to get lots of trace output with --tracing. I've rebuild with the flag enabled, yet all I get is two lineS:

[17:24] <nwc10> Op 159   at <unknown>:1  (/home/nick/Perl/rakudo/rakudo.moarvm:<dependencies+deserialize>)

[17:24] <nwc10> Op 159   at <unknown>:1  (/home/nick/Perl/rakudo/rakudo.moarvm:<entry>)

[17:26] * nine has never used tracing

[17:26] <nwc10> I thought I had it working from NQP

[17:26] <nwc10> anyway, I am guessing that the relevant op for this mess is trunc_u8

[17:26] <nine> call MVM_dump_bytecode(tc) has been incredibly helpful in gdb

[17:27] <nwc10> actually, sorry, extend_u8

[17:27] <nwc10>                 GET_REG(cur_op, 0).u64 = (MVMuint64)GET_REG(cur_op, 2).u8;

[17:27] <nwc10> no, it shouldn't

[17:27] <nine> that looks quite correct?

[17:28] <nwc10> yes, I more meant - if it's assuming memory layout from the union  (and not just sizes) it's going to go wrong. But I think I'm wrong on makign that assumption

[17:56] *** zakharyas left
[18:25] *** brrt joined
[18:30] <nwc10> x

[18:31] <nwc10> brrt: see https://colabti.org/irclogger/irclogger_log/moarvm?date=2020-10-26#l99 for context

[18:32] <nwc10> It was "none of the above" for the cause of the big endian fail shown. Testing a fix...

[19:00] <[Coke]> nwc10: hey, the extend_u8 and _i8 variants aren't documented. Can you document them?

[19:01] <[Coke]> (neither are some trunc_...)

[19:03] <nwc10> not trivially, because I didn't go further than realisign that they weren't the cause

[19:03] <nwc10> and right now I have a stack of other things I was trying to get done first

[19:03] <nwc10> (such as spectest clean on 64 bit big endian systems)

[19:06] <[Coke]> was worth a shot. ;)

[19:22] *** zakharyas joined
[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: 62d07f0edb | (Nicholas Clark)++ | src/6model/reprs/NativeRef.c

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: MVM_nativeref_{read,write}_lex_i should handle uint8, uint16, uint32

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: 

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: Previously these three (and uint64) all took the `default:` path through

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: the case statement, which meant that they were read/written as 64 bits, eg:

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: 

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too:         default:

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too:             return var->i64;

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: <…commit message has 13 more lines…>

[19:59] <Geth> ¦ MoarVM/NativeRef-uint-too: review: https://github.com/MoarVM/MoarVM/commit/62d07f0edb

[20:02] <Geth> ¦ MoarVM: nwc10++ created pull request #1372: MVM_nativeref_{read,write}_lex_i should handle uint8, uint16, uint32

[20:02] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1372

[20:07] *** Altai-man joined
[20:10] *** sena_kun left
[20:15] <timotimo> does there also have to be a _u variant of these functions?

[20:15] <nwc10> I think not. (I'm guessing here)

[20:16] <nwc10> the register type can encode unsigned or signed

[20:16] <nwc10> yes, the return type is always MVMint64, but we seem to get away with that

[20:17] *** MasterDuke joined
[20:22] <lizmat> nwc10: there's a long standing issue with unsigned 64 bit ints (and 32 bit unsigned ints on 32 bit systems)

[20:25] <MasterDuke> not just 64 bit unsigned ints though, all sizes

[20:28] <lizmat> ah?  

[20:40] *** brrt left
[20:51] <nwc10> I could see a bunch of things marked TODO. I wasn't worrying about them yet. I was trying to get to parity - ie nothing fails on big endian that passes on little endian

[20:52] <MasterDuke> m: my uint8 $a = 2**50; say $a

[20:52] <camelia> rakudo-moar 85847d2f1: OUTPUT: «0␤»

[20:52] <MasterDuke> m: my uint64 $a = 2**66; say $a

[20:52] <camelia> rakudo-moar 85847d2f1: OUTPUT: «Cannot unbox 67 bit wide bigint into native integer␤  in block <unit> at <tmp> line 1␤␤»

[20:53] <MasterDuke> shouldn't the first one fail the same way?

[20:55] <MasterDuke> maybe that's expected, but there are a bunch of oddities/stuff NYI around uints so i don't use them

[20:56] <MasterDuke> a while ago i had a branch trying to add *_u versions of all relevant ops to moarvm, but i got stuck somewhere and left it

[20:59] <MasterDuke> in other news, i have parse_coverage_report.p6 updated to record (and include in the output) the files+lines that were run to cover each line of the setting. however, i don't know html, so haven't tried to make it look at all nice

[21:01] *** sxmx joined
[21:01] <MasterDuke> i'll probably PR it as-is once the code is cleaned up and then let the actual form of the output be bikeshed

[22:07] *** vrurg left
[22:12] *** vrurg joined
[22:14] *** zakharyas left
[22:43] *** Altai-man left