Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-02-19

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 dogbert17 hmm
00:01 dogbert17 could it be that the codepath in question isn't hit that often?
00:05 timotimo not sure, we can put a debug printf in and see
00:05 timotimo of course that'd also hit it in the to-be-tested programs if we don't have something clever
00:10 dogbert17 a quick gdb check show that the code path is hit often
00:11 timotimo ah, gdb is a better idea
00:12 timotimo you can even put a print in with "commands" and make it immediately resume with "c" before the "end"
00:12 timotimo and there's even incantations to prevent it from giving you a pager you have to push return a million times
00:23 timotimo we could output messages for each action of adding bytes and discarding bytes and maybe even allocating and freeing a decode stream
00:24 timotimo with pointers and such
00:24 timotimo they have some pointers that don't move. the object pointer itself is gc-managed probably
00:24 timotimo but we could then analyze the log to see if the decodestream that asplodes gets used for long
00:24 timotimo maybe output a moar-level backtrace on each action and make it managable by putting it behind a simple UI that allows us to toggle visibility
00:24 timotimo AFK, though
00:49 timotimo hm.
00:50 timotimo i seem to have a hanging test right now
00:50 timotimo in one of my runs
00:51 timotimo the bar at the bottom is gone, it doesn't consume any cpu
01:15 dogbert17 joined #moarvm
01:29 agentzh joined #moarvm
03:24 dalek joined #moarvm
03:24 synopsebot6 joined #moarvm
05:08 IRCFrEAK joined #moarvm
05:08 IRCFrEAK left #moarvm
05:41 agentzh joined #moarvm
11:02 nine Is there an easy way to print an MVMString to stderr?
11:06 nine Ah, fprintf(stderr, "handle: %s\n", MVM_string_utf8_encode(tc, handle, &size, 0)); seems to do the trick
11:29 agentzh joined #moarvm
11:33 jnthn nine: There's also a MVM_string_utf8_encode_C_string which gives you NULL-terminated
11:33 jnthn And doesn't ake a size arg
11:46 dogbert17 jnthn: any opinions on https://gist.github.com/dogbert17/eaba7dfc536b7a65114a52b1748fbe23 ?
11:48 nine Ok, I can now confirm that when the source code is equal, the SC handle is equal and therefore we use the same scb for both modules.
11:53 jnthn nine: Yeah, the SC handle is made by sha1 of the source in Rakudo
11:53 jnthn Happens when Perl6::World is constructed, iirc
11:54 nine jnthn: ok, thanks. That just saved me the time for finding out exactly this :)
11:54 nine Of course the open question is, what to actually do about it.
11:55 jnthn Has it become a problem?
11:55 nine Yes: https://gist.github.com/ugexe/b8ac60d26a17d2c256c41f62e9716d96
11:55 jnthn Well, duh, or you'd not be looking at it
11:55 jnthn But why? :)
11:55 nine Use case is someone forking a dist under a different auth and a program using both the fork and the original.
11:56 nine For a large dist the chance is high that some modules will be identical in both dists.
11:56 jnthn At what point does that happen, but we can't just treat it as the same module?
11:57 jnthn Or rather, the same compiled output
11:57 jnthn Oh, 'cus module precomp storage is not just keyed on source code.
11:57 jnthn Hmm
11:58 jnthn I guess one possible solution, if we're precompiling a module, is to factor the dist into the sha-1 hash
11:59 jnthn Since dist identifies should be unique
12:00 nine Ah, yes, I've found the code in Perl6::Grammar
12:00 nine I'll have a look at getting the dist-id into there
12:01 jnthn NQP factors a timestamp in instead iirc, for the sake of bootstrapping
12:01 jnthn (Where the layers of bootstrap have the same source)
12:02 jnthn But that's a bit fragile for general use
12:02 jnthn So yeah, dist-id is probably wiser
12:02 nine Ah, that's where handles like F2C4AFFFA43D84AE3246F1C7874339333BEBBCAA-1487419665.25749 are coming from
12:02 jnthn You noted on #perl6-dev it's MoarVM to blame, but seems it's more Rakudo not making unique enough IDs...is there something MoarVM coulda done different to catch this problem sooner, though?
12:03 * jnthn ain't sure if we get upset if you try to create the same handle twice...
12:03 jnthn Well, create SCs with the same handle...
12:08 jnthn dogbert17: That one is...intersting, and a bit different. Hmm :)
12:09 nine Well I did not intend to assign blame :) For that my understanding is much too limited. I do wonder though if there's a valid case where we'd access an already loaded scb when deserializing just loaded bytecode.
12:10 jnthn nine: Yes, I wasn't worrying so much about blame as if we could tweak something in MoarVM so that your bug hunt mighta been shorter. :)
12:10 dogbert17 timotimo and I had a feeling that we might be zeroing in on the right spot ...
12:12 jnthn nine: ohh...hmm
12:12 jnthn nine: The MVM_sc_create code is a bit interesting :)
12:12 jnthn https://github.com/MoarVM/MoarVM/blob/master/src/6model/sc.c#L3
12:13 jnthn I wonder what the explicit "lost the race to create it" thing is about
12:13 jnthn (No, I can't remember. :))
12:14 nine Well it's diakopter++'s code ;)
12:14 jnthn Oh
12:14 jnthn So *that's* why I don't remember writing it :D
12:15 nine "make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry"
12:16 jnthn That sounds like something that went in very early :)
12:18 nine jnthn: actually including $?FILES in the computed hash seems to fix it. And it may even a valid fix since the hash for the installed source file already contains the $dist-id
12:20 jnthn Aha
12:20 jnthn And I guess -Ilib is immune to these issues
12:27 jnthn lunch; bbiab
13:22 pyrimidine joined #moarvm
13:35 zakharyas joined #moarvm
13:41 geekosaur joined #moarvm
15:32 agentzh joined #moarvm
17:38 pyrimidine joined #moarvm
17:44 dogbert17 jnthn: does that mean that you have a theory as to what's going wrong?
18:14 Util joined #moarvm
18:15 agentzh joined #moarvm
20:33 agentzh joined #moarvm
22:11 geekosaur joined #moarvm
23:16 geekosaur joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary