|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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:16 | |
|
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: default: return var->i64; ... (13 more lines) |
08:28 | |
|
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) github.com/MoarVM/MoarVM/commit/b7151da7d7 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) |
18:13 | |
| 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
|
|||