01:17
unicodable6 joined,
quotable6 joined
01:31
leont joined
01:36
klapperl joined
02:57
ilbot3 joined
03:39
leont joined
03:57
bloatable6 joined
04:14
leont joined
05:50
leont joined
06:50
domidumont joined
07:00
domidumont1 joined
07:05
domidumont joined
07:06
brrt joined
07:12
domidumont joined
08:30
brrt joined
08:40
leont joined
08:53
zakharyas joined
09:33
brrt joined
|
|||
brrt | good * #moarvm | 09:34 | |
lizmat | brrt o/ | 09:36 | |
brrt | \o lizmat | 09:41 | |
09:43
leont joined
|
|||
lizmat | afk& | 09:51 | |
10:34
brrt joined
10:53
zakharyas joined
11:03
brrt joined
11:35
scovit joined
11:46
committable6 joined
14:11
squashable6 joined
14:14
bisectable6 joined
14:23
Kaiepi joined
14:39
releasable6 joined,
greppable6 joined,
statisfiable6 joined
14:59
zakharyas joined
15:42
geospeck joined
16:00
Kaiepi joined
16:11
brrt joined
16:23
brrt joined
17:23
coverable6 joined,
benchable6 joined
18:17
Ven`` joined
18:41
reportable6 joined,
nativecallable6 joined
18:47
Kaiepi joined
19:35
leont joined
|
|||
Geth | MoarVM: 27dc010db5 | (Stefan Seifert)++ | src/core/exceptions.c Refactor search_frame_handlers_lex for readability Keeps the JIT and non-JIT code paths closer together so the actual differences are easier to find. |
19:50 | |
19:56
Ven`` joined
19:57
Ven`` joined
20:35
zakharyas joined
20:51
evalable6 joined
|
|||
nine | Turns out it's the removal of a goto in a single inlined function (as_mast_clear_bindval, BB 1519) which causes the breakage | 20:52 | |
lizmat | nine++ # persistent**2 | 20:56 | |
jnthn | This is very good for the bus number of this code :-) | 21:02 | |
yoleaux | 15:31Z <Zoffix> jnthn: You wanted golf for R#1410 : github.com/rakudo/rakudo/issues/14...-357997752 | ||
synopsebot | R#1410 [open]: github.com/rakudo/rakudo/issues/1410 [regression][⚠ blocker ⚠] supply/react “already vowed” regression | ||
jnthn | nine++ | ||
nine | I guess adding a little if (strcmp(sf_name, "compile_var") == 0 && strcmp(in_name, "as_mast_clear_bindval") == 0) to the goto removal code won't be accepted into master? | 21:23 | |
Because with that all tests and spectests pass. | 21:24 | ||
Really it's just that 1 of 20 inlines in that one function | |||
Removal turns this: gist.github.com/niner/e3ff518af247...13b35a7e4c into this: gist.github.com/niner/d91728334651...3e17d649f0 | 21:28 | ||
Err...the other way round of course | |||
leont | I've been looking at merging stdout and stderr on a file-descriptor level (I think that merge is currently happening in moar instead, which is too late for my purposes), but the code was confusing me a bit. | 21:37 | |
either spawn_async is leaking data, or uv_spawn takes ownership of the handles without documenting it, or I'm not understanding the code | |||
Anyone got any pointers? | |||
jnthn | leont: I've banged my had against that problem before (merging at descriptor level, that is), and eventually gave up and left it for somebody more clueful about I/O | 21:45 | |
*my head | |||
The results were mostly SEGVs :/ | |||
Or just not getting the expected data | 21:46 | ||
It's possible that there's a leak on that path | |||
leont | That is not very encouraging to hear :-p | 21:48 | |
If using the same handle twice doesn't work, I suppose I could try to pass the second one as a file descriptor. Not sure that's useful on Windows though. | 21:49 | ||
jnthn | My understanding is that github.com/MoarVM/MoarVM/blob/mast...ops.c#L580 closes the handle at the end of the read | ||
And the one below should there be an error | 21:50 | ||
22:29
Ven`` joined
22:38
Ven`` joined
|