github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:20 linkable6 left, 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
Geth MoarVM/CStruct-bind_attribute-inlined-CArray-unaligned-overrun: ee404e164d | (Nicholas Clark)++ | src/6model/reprs/CStruct.c
In CStruct `bind_attribute`, don't `set_ptr_at_offset` for inlined CArray.

  `bind_attribute` had been calling `set_ptr_at_offset` for all `CArray`s,
whether inlined or not. That writes a pointer at the slot offset.
For the corner case of the inlined array being both the last member in the structure and smaller than the size of a pointer ... (23 more lines)		 10:06
MoarVM: nwc10++ created pull request #1369:
CStruct bind_attribute can write beyond malloc'd buffer.		 10:21
MoarVM/master: 4 commits pushed by (Nicholas Clark)++, nwc10++ 10:23
nwc10 .seen froggs 10:30
tellable6 nwc10, I saw froggs 2019-09-15T13:29:14Z in #perl6: <FROGGS> uhhh, that sounds awesome
nwc10 I doubt that he really wanted to be a reviewer. github suggested him 10:31
nine The repetition between CStruct, CPPStruct and CUnion has bitten us countless times 10:53
nwc10 If I go "back" to commit 163ee73f6eafc44c89a7ed5145ad8b99c7907274
at that commit diff between CStruct.c and CPPStruct.c seems to be pretty much s/CPP/C/ and s/cpp/c/ 10:54
(and some whitespace)
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
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
(Since that commit they have diverged a lot, and I'm wondering if most of that divergence is bugs)
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
lizmat: I can't promise that I am correct. This is code that I really don't undestand
I can just see a lot of patterns
and a commit message that suggests that it shouldn't be that different
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
nine I think those 3 can be unified a lot
nwc10 I can see patterns in code I understand too
OK, right now I'm off trying to fix all the big endian test bugs
or, maybe also, AFK 10:58
on "hoilday"
nine Well we've lived with the duplication for years....we can grant you a couple hours off before unifying them ;)
nwc10 it needs at least 1 competant reviewer 10:59
and also I don't think that this stuff has enoguh tests
nine is looking at #1369 right now
nwc10 thanks
given that I don't think that rakudo/rakudo#3687 added any tests 11:00
linkable6 RAKUDO#3687 [closed]: github.com/rakudo/rakudo/issues/3687 Binding to an inlined CStruct does not do what it means
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"
nine Just add the NQP/MoarVM bump to the same commit that adds the tests
nwc10 also, it seems that dyncall is (slightly) architecturally buggy, as it looks like they also have a known failure on ppc32 11:17
(but I have not gone tryign to find out what the Power ABI spec is)
basically, dyncall implements `unsigned short` and `unsigned char` arguments by casting to `short` and `char` respectively and using those functions 11:18
which loses the info about whether the 16 or 8 bit thingy was signed or unsigned
and seems that this matters on ppc32 *too*
looks like libfii doesn't have this problem
but as best I can tell *that* was "more by luck than judgement"
ie - using libffi rather than dyncall on sparc linux gets us one more test passin g 11:19
02-simple-args.t
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] ?
nine AlexDaniel on IRC
nwc10 aha
Geth MoarVM: 4ced726fed | (Nicholas Clark)++ | 4 files
Use MVM_{malloc,realloc,calloc,free} consistency.

All these calls changed to the MVM_* wrappers are on memory blocks where the other calls are MVM_* wrappers.
There are still a few "bare" `malloc`s/`free`s, but these seem to be self-contained, or related to memory allocated by `strdup`/`strndup`, which is using the platform `malloc` internally.		 11:33
11:41 patrickb joined 12:35 zakharyas left 12:54 brrt joined
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*
brrt .tell nwc10 so you've crossed the rubicon 12:56
tellable6 brrt, I'll pass your message to nwc10
nwc10 o/ 13:07
tellable6 2020-10-26T12:56:08Z #moarvm <brrt> nwc10 so you've crossed the rubicon
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/10/26/2020-...-and-star/ 13:18
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
brrt lizmat++ 14:45
14:50 domidumont joined
brrt /query nwc10 16:03
nwc10 x 16:21
16:22 brrt left, sena_kun joined
nwc10 oh. I scared his client :-( 16:22
lizmat didn't know that "boo" was spelled "x" in client speak 16:23
nwc10 I claim that it's the simplest possible explanation 16:25
Geth MoarVM/utf16-swap-bytes-BE-too: 55964708fa | (Nicholas Clark)++ | src/strings/utf16.c
`swap_bytes` in utf16.c needs to also swap bytes on big endian platforms.

The way it had been written worked perfectly on little endian platforms, and was actually a no-op on big endian platforms, because it *read* from memory in fixed (little endian) order, but wrote back using bitwise operations, meaning that the read acted as a second byte swap on big endian platforms. This was somewhat LTA.		 16:26
MoarVM: nwc10++ created pull request #1371:
`swap_bytes` in utf16.c needs to also swap bytes on big endian platforms		 16:27
nwc10 lets see what the automated tests think of that.
16:52 domidumont left
nine That whole interning of parametrics thing is horribly complicated :/ 17:03
nwc10 meanwhile: 17:15
nick@gcc202:~/Perl/rakudo$ ./rakudo-m -e 'my uint8 $var = 255; say $var' 255
nick@gcc202:~/Perl/rakudo$ ./rakudo-m -e 'my uint8 $var = 255; my $x = $var; say $x'
-72057594037927936
that's 0xff00000000000000
I have some idea how to find that cause of that. Let's see how long it takes
nine Our whole uint support is a bit of a mess
nwc10 it's more of a mess on big endian platforms 17:16
I see a bunch of TODOs in the spectest that suggest that uint64 doesn't work too well
timotimo yeah, uint is kind of wild 17:17
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
Op 159 at <unknown>:1 (/home/nick/Perl/rakudo/rakudo.moarvm:<dependencies+deserialize>)
Op 159 at <unknown>:1 (/home/nick/Perl/rakudo/rakudo.moarvm:<entry>)
nine has never used tracing 17:26
nwc10 I thought I had it working from NQP
anyway, I am guessing that the relevant op for this mess is trunc_u8
nine call MVM_dump_bytecode(tc) has been incredibly helpful in gdb
nwc10 actually, sorry, extend_u8 17:27
GET_REG(cur_op, 0).u64 = (MVMuint64)GET_REG(cur_op, 2).u8;
no, it shouldn't
nine that looks quite correct?
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:28
17:56 zakharyas left 18:25 brrt joined
nwc10 x 18:30
brrt: see colabti.org/irclogger/irclogger_lo...-10-26#l99 for context 18:31
It was "none of the above" for the cause of the big endian fail shown. Testing a fix... 18:32
[Coke] nwc10: hey, the extend_u8 and _i8 variants aren't documented. Can you document them? 19:00
(neither are some trunc_...) 19:01
nwc10 not trivially, because I didn't go further than realisign that they weren't the cause 19:03
and right now I have a stack of other things I was trying to get done first
(such as spectest clean on 64 bit big endian systems)
[Coke] was worth a shot. ;) 19:06
19:22 zakharyas joined
Geth MoarVM/NativeRef-uint-too: 62d07f0edb | (Nicholas Clark)++ | src/6model/reprs/NativeRef.c
MVM_nativeref_{read,write}_lex_i should handle uint8, uint16, uint32

Previously these three (and uint64) all took the `default:` path through the case statement, which meant that they were read/written as 64 bits, eg:
   default:
   return var->i64;
... (13 more lines)		 19:59
MoarVM: nwc10++ created pull request #1372:
MVM_nativeref_{read,write}_lex_i should handle uint8, uint16, uint32		 20:02
20:07 Altai-man joined 20:10 sena_kun left
timotimo does there also have to be a _u variant of these functions? 20:15
nwc10 I think not. (I'm guessing here)
the register type can encode unsigned or signed 20:16
yes, the return type is always MVMint64, but we seem to get away with that
20:17 MasterDuke joined
lizmat nwc10: there's a long standing issue with unsigned 64 bit ints (and 32 bit unsigned ints on 32 bit systems) 20:22
MasterDuke not just 64 bit unsigned ints though, all sizes 20:25
lizmat ah? 20:28
20:40 brrt left
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:51
MasterDuke m: my uint8 $a = 2**50; say $a 20:52
camelia 0
MasterDuke m: my uint64 $a = 2**66; say $a
camelia Cannot unbox 67 bit wide bigint into native integer
in block <unit> at <tmp> line 1
MasterDuke shouldn't the first one fail the same way? 20:53
maybe that's expected, but there are a bunch of oddities/stuff NYI around uints so i don't use them 20:55
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:56
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 20:59
21:01 sxmx joined
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 21:01
22:07 vrurg left 22:12 vrurg joined 22:14 zakharyas left 22:43 Altai-man left

Powered by Cro and the Raku® Programming Language.

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

Thank you!