|
07:40
sena_kun joined
08:11
sena_kun left
13:36
MasterDuke joined
|
|||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/09/02/2024-36-on-top/ | 14:47 | |
|
15:34
camelia left,
jjatria left
15:35
camelia joined,
jjatria joined
|
|||
| timo | works on ppc64, but not on ppc32, and also doesn't work on i386 | 17:03 | |
| now what i'm wondering is why did it succeed on nine's i586 open build system worker? | 17:06 | ||
| because it was 2024.04 :) | |||
| Geth | MoarVM/main: 6ed6986be6 | (Timo Paulssen)++ | build/probe.pm When -latomic is needed, don't lose the libs entry We re-write $config->{ldlibs} soon after this is called and only use the contents of usrlibs and syslibs, so putting something in the ldlibs config entry is a bad idea™. |
17:09 | |
| MoarVM/main: f14712b6b9 | (Timo Paulssen)++ | 3 files Split string's "any" union field into "any" and "any_ptr" In some spots we were using "any" to be able to copy over the contents of a string no matter what storage type it was, in others we wanted to refer to any of the pointers in it without having to specify which (even though it doesn't actually matter). However, on 32bit systems, the old any field (void *) was only half as long as the in_situ_8 and in_situ_32 fields, which causes us to miss up to half of the graphemes, for example when reaching a string in a grapheme iterator. |
17:18 | ||
| timo | ^- the other option would have been to reduce the length of in situ strings on 32bit platforms to 4 8bit graphemes or 1 32bit grapheme, but since MVMString is a collectable and therefore already relatively big, the extra 4 bytes we use only for in situ storage probably gives a stronger benefit than reducing the size | 17:36 | |
| and i'd actually kind of like to look into whether making the in situ storage a tiny bit larger would be beneficial. if so, we can move strand_count right after the storage and make it part of the union, since it's only valid when we use strand storage type | 17:38 | ||
|
18:01
sena_kun joined
20:19
lizmat_ joined
20:21
notable6__ joined
20:22
evalable6__ joined,
unicodable6__ joined,
bloatable6__ joined,
greppable6__ joined
20:25
notable6 left,
evalable6 left,
unicodable6 left,
bloatable6 left,
greppable6 left,
lizmat left
|
|||
| MasterDuke | timo: nice. i'd been thinking similarly, after i read an article comparing gcc vs clang vs msvc on their c++ string implementations | 20:31 | |
|
21:19
MasterDuke left
21:33
sena_kun left
21:49
lizmat_ left,
lizmat joined
|
|||