github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:16 patrickb left 01:11 MasterDuke joined 01:12 MasterDuke left, MasterDuke joined
MasterDuke samcv, timotimo: if we get here github.com/MoarVM/MoarVM/blob/mast...f8.c#L437, would it be possible to include any of the buffer (last couple bytes maybe) in the error message? 02:01
timotimo it is possible. would you like to include the "wrong" bytes? 02:04
MasterDuke probably, and maybe a couple before it goes "wrong" so one can easily find where that is 02:05
timotimo you can try MVM_exception_throw_adhoc_free(tc, "Malformed UTF-8 - near bytes %02x %02x %02x", { buffer, NULL }, buffer[pos - 2], buffer[pos - 1], buffer[pos]); or something similar
can also output the pos, though if that's the streaming decoder, the number may not correspond to something the user could use 02:06
MasterDuke cool 02:08
02:10 lizmat left
MasterDuke i'm on a random kick to add context to any moarvm exceptions where it would make sense 02:10
timotimo cool 02:11
you know
MasterDuke oh, any possibility the buffer could be less than three bytes big?
timotimo yeah, possible
there's a whole lot of exceptions (including checks) like "is this object's REPRID the right one? if not throw an exception" and I think they could be turned into a function - maybe an inline one, though the error path shouldn't be taken often, so maybe it should be a function or actually a macro and a function?! with an MVM_UNLIKELY for the check 02:13
optional, of course 02:14
MasterDuke i haven't seen any of those yet (just started working my way up from the bottom of my git grep results), but i'll give that a shot when i see them 02:15
timotimo many of them in interp.c
MasterDuke what's the difference between PRId64 and PRIi64? 02:34
timotimo #define PRId64 "lld" 02:36
#define PRIi64 "lli"
the man page for sprintf doesn't explain a/the difference 02:37
MasterDuke we only have 12 uses of PRIi64, but 43 of PRId64 02:38
related question, what should i use for size_t? 02:39
timotimo good question :o 02:40
stackoverflow says "cast to unsigned long and use the macro for that" 02:42
MasterDuke do we keep to C89 or C99? 02:43
timotimo C89 aka "what msvc definitely can do"
MasterDuke right, ugh 02:44
timotimo even though possibly everything else we have has more C99 in it than msvc does
MasterDuke a comment on that answer says it can break for 64-bit windows 02:52
timotimo oh my god 02:53
well then
cast to uint64_t i guess?!
MasterDuke that's the next comment, and then the one after *that* says uint64_t is C99 02:54
final comment says "It [cast to unsigned long] will only fail if the numerical value being printed exceeds ulong_max. [...]" 02:56
i'm going to go with cast to unsigned long and will accept suggestions on the PR 02:58
timotimo OK, OK, use MVMuint64 :) 03:04
MasterDuke serious suggestion? 03:08
timotimo well, it ought to at least work 03:29
MasterDuke oh, btw, i don't think you can inline the thing you pass to MVM_exception_throw_adhoc_free like that 03:35
timotimo oh 03:45
in that case i'll just have to pretend i meant it to be pseudocode all along!
found another way to break things with nativecall, the JIT, and "is rw" arguments. this time an int64 argument was coming back 0 even though it should have had a value 03:47
MasterDuke sounds related to the other thing 03:49
timotimo it's probably the same thing, yeah 03:52
06:33 nebuchadnezzar joined 07:48 lizmat joined
nine Considering that there are numerous options to compile C99 code on Windows nowadays, including options to do so in Visual Studio, I seriously wonder if sticking to C89 is worth the pain and developer time. 08:09
08:38 Kaiepi left 10:50 Kaiepi joined
dogbert2_ hello, is everyone still suffering from cold/flu ? 11:04
lizmat sorta recovered from that, only to bust up her knee again 12:19
which is just very tiring 12:20
12:33 lucasb joined
dogbert2_ lizmat: sorry about that. Is it a bicycle related injury? 12:56
lizmat well, the original source of the problem is indeed a bicycle accident in 1981 12:57
that made my left knee damaged and ~30 years "older" than my right knee
which makes my left knee 92 years old now, so you get the picture... :-) 12:58
last Saturday I went cycling and did something wrong with my knee after about 7km
instead of calling it a day, I stubbornly decided it wasn't all that bad and continued cycling for another 18km 12:59
:-(
it's slowly getting better again... needs rest 13:00
dogbert2_ perhaps some relaxing hacking :) 13:08
lizmat yup 13:11
dogbert2_ opts or bugfixes? 13:12
lizmat alas, not a lot of time for Perl 6 atm, having to update ~24 year Perl 5 old code from mod_perl to psgi
it's *really* weird to look at your own code that originated about 24 years ago 13:13
those were different days :-) 13:15
meanwhile if there is a blocker that I could help fix, please let me know
afaik, all current blockers are above my level of capabilities 13:16
dogbert2_ it would seem as if everyone capable of fixing the blockers are down with either a cold or the flu atm 13:27
lizmat yeah, life sucks :-)
dogbert2_ indeed :) 13:28
15:17 lizmat left 17:15 leedo left 17:41 leedo joined
nine r23 from the spesh log should be tc->cur_frame->work[23] shouldn't it? 19:42
timotimo i believe so 19:45
nine I may have a piece of the #2706 puzzle 19:48
We may have an issue with rw args to native calls, when the JIT fails to compile the call graph the nativeinvoke_o is in. 19:53
Happens for example because we're missing the case for MVM_OP_getlexref_u8. 19:54
optimize_getarg works on the assumption that the JIT compiler will not emit any code for the corresponding arg_* ops for a nativeinvoke and instead the values will be taken from the WORK register. 19:55
But in our case, the JIT bails and the arg_i is still there. So the address of the arg buffer is passed to the native function and this is where the set value ends up in. 19:56
But optimize_getarg has turned the getarg_i op into a set from the WORK register, ignoring the value in the arg buffer. 19:57
In other words: we handle the interpreted version and the speshed + JIT compiled version but not the only speshed version 19:58
So the obvious solution is to just improve the JITs coverage of our ops to 100 % 20:05
timotimo oh damn, that's a good analysis 20:37
20:46 lizmat joined 20:48 Kaiepi left 20:58 lizmat left 21:01 lizmat joined 21:12 lizmat left 21:32 lucasb left 22:42 MasterDuke left 22:43 Kaiepi joined 23:57 Kaiepi left 23:59 lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!