| IRC logs at
Set by AlexDaniel on 12 June 2018.
02:09 MasterDuke left 02:40 lucasb left 06:53 Altai-man joined
Geth MoarVM: 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.
07:28 brrt joined 07:37 MasterDuke joined 08:08 sena_kun joined 08:10 Altai-man left
Geth MoarVM: 2a98b8f3aa | (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:
   return var->i64;
... (13 more lines)
08:38 domidumont joined 08:40 zakharyas joined 10:09 brrt left 10:22 brrt joined 10:24 brrt left 10:27 brrt joined 10:54 brrt left 12:07 Altai-man joined 12:10 sena_kun left 12:21 zakharyas left 13:17 Altai-man left, Altai-man joined 14:11 zakharyas joined
nwc10 nine: in CStruct.c at line 520 we have MVMROOT(tc, root, { ... 15:48
within that block, we have at line 519 MVMROOT2(tc, typeobj, root, {
does that make sense?
nine no 15:52
nwc10 :-)
OK, thanks. I assume that that's a cumlative error from refactorign
oh, probably commit b7151da7d7016c0713bc1da3cb1760ea9c302aeb 15:54
linkable6 (2019-09-11) Fix possible memory corruption in CStruct's and CPPStruct's get_attribute
16:08 sena_kun joined 16:10 Altai-man left 17:20 domidumont left
Geth MoarVM: 608b90eb19 | (Nicholas Clark)++ | src/6model/reprs/CStruct.c
No need to MVMROOT `root` twice in `get_attribute`.

This inefficiency was introduced 6 weeks ago as a side effect of commit b7151da7d7016c07:
   Fix possible memory corruption in CStruct's and CPPStruct's get_attribute
   An untimely GC run may move *root before we get to assign the newly created
... (24 more lines)
nine Is it me or are MVM_serialization_demand_object and MVM_serialization_demand_stable actually racey? Both create stubs first and add them to the SC's root_objects or root_stables respectively and then enter the work_loop to load the actual data. A different thread may come along, request the same object or stable and get one of these stubs 18:16
Oh, it is me. We're protected against that by the sr->working flag that gets set before the stub is created and only cleared after the work loop is finished. So MVM_sc_get_object will enter MVM_serialization_demand_object (and try to acquire the lock) instead of fetching something from root_objects directly 18:18
18:28 zakharyas left 20:07 Altai-man joined 20:10 sena_kun left 20:30 Altai-man left 20:40 Altai-man joined 20:43 lucasb joined 20:44 Geth left 20:48 Altai-man left 20:58 chansen_ left, hoelzro left, Altreus left, hoelzro joined, chansen_ joined 20:59 Altreus joined 21:23 zakharyas joined 21:27 zakharyas left 23:17 nebuchadnezzar left