github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
samcv AlexDaniel, so is the release-2019.07.1 branch complete or are there more commits needed? 05:37
05:37 robertle left
AlexDaniel samcv: looks so to me 06:07
samcv: it needs a changelog I think, otherwise it's reahy 06:15
ready* :)
samcv ok cool 06:17
i'll start the release when i get to the office. as there is AC there
06:59 domidumont joined 07:00 domidumont left 07:02 domidumont joined 07:54 robertle joined 09:40 domidumont left 10:21 ilogger2 joined
Geth MoarVM/more-pea: 64 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/4...c5b7f65b56		 10:49
jnthn (Just a rebase) 10:50
Guest37021 jnthn: are you hacking a while before your vacation? 11:01
temperature in Stockholm is 28 degrees centigrade 11:02
jnthn No, I'm just gathering various bits of data for my Perl 6 perf talk at PerlCon :) 11:03
Guest37021 aha 11:04
11:05 zakharyas joined
jnthn 32C outside in Praha 11:07
moritz it was 42 yesterday in western .de 11:18
first time we ever had > 40C, afaict 11:19
lizmat 36.1 outside here now, yesterday 39.8
moritz at least it's predicted more moderatly tomorrow 11:26
and I'll see lizmat tomorrow! \o/
and wendy \o/
lizmat \o/ :-)
should be only 28 max tomorrow, but raining :-( :-) 11:27
11:42 sena_kun joined 11:45 zakharyas left 12:03 domidumont joined
timotimo i can't wait to see the slides, or maybe even a livestream, of jnthn's talks, and others 12:05
sena_kun is `of` return syntax deprecated or? 12:07
timotimo i think maybe?
the most preferred way is to put the --> in the signature
there's also the fourth way to have "my Str sub blah" or something like that 12:08
which i'd claim is more about the variable i guess
sena_kun greppable6, (sub|method) .+? of <[a..z A..Z :]> '{'
greppable6 sena_kun, Found nothing!
sena_kun I wonder if my early morning regexes are worth anything...
timotimo that was incredibly fast
greppable6: my 12:09
sena_kun greppable6, (sub|method) .+? '{'
timotimo like, the answer to the first regex came faster than is reasonable 12:10
sena_kun not so fast anymore, huh, cowboy!
indeed
Guest37021 42 degrees sounds dangerously high
sena_kun I remembered that we have this `returns` and `of` and thinking if we should properly deprecate them and if not, just why. TIMTOWTDI just for the sake of TIMTOWTDI is questionable. 12:11
yay, perl6-examples builds fine now. \o/
timotimo "build"? :) 12:12
jnthn `of` works because it's the typical way to parameterize, and a sub that returns something of type Str will do the Callable[Str] role
sena_kun timotimo, I am about repo, so `builds`. :)
jnthn `returns` I think exists because it's more self-documenting than `of` 12:13
sena_kun m: sub a returns Str {}; &a.^name.say;
camelia Sub+{Callable[Str]}
sena_kun m: sub a(--> Str) {}; &a.^name.say;
camelia Sub+{Callable[Str]}
sena_kun jnthn, am I not getting the difference? 12:14
jnthn There isn't one; I'm just explaining that the `of` form exists quite naturally 12:16
And in some ways is the most basic one
Even if it's not the one we'd maybe prefer people to use :)
sena_kun m: role A[B] { method a { B.say } }; my A of Int $b; $b.a; 12:19
camelia ===SORRY!=== Error while compiling <tmp>
Invalid typename 'B' in parameter declaration.
at <tmp>:1
------> role A[Bā] { method a { B.say } }; my A of Int $b
timotimo i never knew stagestats took an integer argument
sena_kun m: role A of B { method a { B.say } }; my A[Int] $b; $b.a;
camelia ===SORRY!=== Error while compiling <tmp>
Invalid typename 'B'
at <tmp>:1
------> role A of Bā { method a { B.say } }; my A[Int] $b; $
sena_kun somehow my understanding of "`of` works because it's the typical way to parameterize" fails here, is it about general concept of parametrization, not real syntax? 12:20
like in "Basket of apples". 12:21
12:21 greppable6 joined
timotimo m: my %foo of Perl; say %foo.perl 12:21
camelia (my Perl %)
greppable6 timotimo, No! It wasn't me! It was the one-armed man! Backtrace: gist.github.com/476d68478847900a49...0380baf93e
timotimo wow 12:24
jeez what happened there
did it try to go through a binary file?
12:46 brrt joined
brrt \o 12:48
timotimo o/ 12:52
brrt timotimo: hot still. 12:56
?
12:57 lucasb joined
timotimo yeah 12:58
brrt tomorrow we're promised relief.. 12:59
timotimo 36 or 37 or so
it's slightly cool in here. as loang as you sit where the AC points. going only a step away from the beam of cool, it's hot again :| 13:02
turning off the AC makes the temperature rise again pretty much immediately
brrt oh, you *have* AC 13:08
lucky you :-)
timotimo wetterstationen.meteomedia.de/?stat...vorhersage
it should get a lot cooler tomorrow, but still pretty warm 13:09
yeah, i decided another summer like the last one without AC in my home is just not possible
lizmat 38.1 here, but 50/mm of rain expected in 30 minutes for about an hour... so that's going to be a lot of rain 13:13
timotimo good luck with that! 13:14
AlexDaniel here it is just starting to get hotter 13:15
brrt lizmat: finally, I guess
brrt is also looking into an AC unit 13:16
but. I'd also like to use that as my central heating unit, because, screw natural gas
lizmat yeah... only the last time it rained so much for such a period, we had flooding in the basement :-(
brrt ouch
lizmat yeah, interesting times... :-(
timotimo damn it 13:17
AlexDaniel it's interesting, first time I can't complain about the weather in Estonia :)
brrt I guess last summer, I didn't really believe that a summer like that would repeat itself 13:27
(climate change denial :-o)
lizmat pretty sure I won't win a lot of money on betting that next year will have at least one heat-wave again 13:29
13:29 ggoebel joined
timotimo who's looking forwards to decade-long droughts in the north-american southwest? 13:30
brrt what about heat records... we could maybe make a nice betting pool out of that 13:51
Guest37021 timotimo: do you want to apply your expertise by looking at a crash gist? 13:54
13:56 pamplemousse joined 14:14 pamplemousse left 14:16 pamplemousse joined
brrt ohai pamplemousse 14:34
pamplemousse Hi brrt 14:36
yoleaux 09:58Z <nine> pamplemousse: method parse is far, far, far away from the actual source of this output. It's coming from here: github.com/rakudo/rakudo/blob/mast...y.pm6#L310 and is for communicating dependency information from a precompilation process back to its caller
pamplemousse nine: Thanks, that definitely saves me some digging. 14:38
14:42 brrt left 15:01 brrt joined 15:07 pamplemousse left
brrt pamplemousse: I was reviewing your code and there was a call to 'which' that, I think, needn't be there 15:09
15:14 domidumont left
Geth MoarVM/release-2019.07.1: 942dd3e893 | (Samantha McVey)++ | tools/update-changelog.p6
Fix update-changelog to work from HEAD not master

Otherwise it will not work if we are releasing from a branch other than master.		 15:16
MoarVM/release-2019.07.1: 348d1b4d99 | (Samantha McVey)++ | docs/ChangeLog
Update ChangeLog for release
15:20 brrt left 15:26 pamplemousse joined
pamplemousse brrt: Oh, yep, you're right. I'll go ahead and get rid of that 15:33
15:40 brrt joined
brrt I mean to say, you should be able to 'know' the correct interpreter being used from the binary itself 15:41
perl6 should know which executable it is :-)
so you could always pass that as an argument
pamplemousse Originally I was trying to accommodate for if someone didn't have perl6 in their path, so the location of the perl6 executable had to be passed in. And when I got rid of passing it in as a parameter, I was trying to figure out a way to\ still find it on the system, but if I can find it using which, then there's no need to specify the whole path because it'll be able to find it 15:48
It would probably be good to modify it so it 'knows' the correct interpreter based on the binary though, I'll look at seeing how to do that 15:50
ugexe which might not point to the perl6 that is currently being executed 15:57
16:04 brrt left, brrt joined
brrt well, ideally, I think the whole ELF-building might as well be part of the NQP compiler 16:07
it's just stuffing bytes after all :-)
lizmat also: putting it in NQP might benefit any other projects using nqp :-) 16:11
pamplemousse ugexe: The only way I've thought of to get around it potentially not point to the perl6 that should be executed is by having an environment variable that it checks for that would point it to the desired perl6 executable, and if that's not set, default to whichever one which can find. Because I can't have it use the path to the perl6 executable that was used to build it, since the built exe could be run on a different machine 16:12
I agree, I think putting it in NQP would make a lot of sense 16:13
brrt pamplemousse: I think that's actually quite viable 16:23
(more importantly, I find that once we have a given functionality, it's usually easy to change the internals while maintaining the interface, so experimenting is often safe, as long as you keep the interface small) 16:24
17:09 brrt left 17:10 brrt joined 17:16 zakharyas joined
dogbert17 what could cause tc->plugin_guards[i].u.type to contain an MVMCollectable pointing to past fromspace. What should I be looking for in order to track this down? gist.github.com/dogbert17/81c3aa3a...abf6034b78 17:17
17:20 brrt left
timotimo well, i don't want to sound like a b-rr-oken record, but ... :P 17:49
dogbert17 so nothing sticks out then? 17:52
timotimo i haven't looked at it yet, sorry 17:53
dogbert17 np, my problem is that I'm a bit unsure as to what can actually move during a gc. Can tc move or perhaps the plugin_guards array? 17:55
timotimo it could be that the "mark_special_return_data" callable doesn't do things right? 17:56
it does have special_return_data, right? that's what sr_data is?
mark_plugin_sr_data would be the function to look at if that were the case 17:58
in spesh/plugin.c
could it be that perhaps the MVMRegister in the special return data needs rooting inside add_resolution_to_guard_set or something like that? 18:00
18:13 pamplemousse left
dogbert17 timotimo: thx, I'll investigate 18:17
18:33 zakharyas left 19:08 chloekek joined 20:21 Altai-man_ joined 20:24 sena_kun left 20:28 Altai-man_ left
dogbert17 timotimo: the error is very consistent, it always looks the same and it is always the last guard, i.e. when i = tc->num_plugin_guards - 1 20:41
timotimo is this the 8k nursery? reproducing it is kind of stable? any env vars? GC debug set to how much? 20:44
dogbert17 MVM_GC_DEBUG=1 20:45
nursery is in fact 16k
timotimo give me the code for that? i don't want to calculate that in my head lol 20:46
dogbert17 -#define MVM_NURSERY_SIZE 4194304
+#define MVM_NURSERY_SIZE (8192 * 2)
in src/gc/collect.c
nine dogbert17: I guess you know this already, but any MVMCollectable (MVMObject, MVMSTable) can be moved, except for those very few that are allocated in gen2 from the start. MVMThreadContext is defined in src/core/threadcontext.h and does not have the MVMCollectable header and is malloced in MVM_tc_create, so it will not be moved. 20:51
dogbert17 nine: thx and congratulations :) 20:52
timotimo hm, running t/spec/S12-meta/primitives.t, yeah? 20:53
dogbert17 yes
sometimes it runs for a bit before anything happens 20:54
timotimo i may have to get the exact revision of nqp and rakudo that you have? 20:55
nine dogbert17: thanks :)
timotimo just went up to latest master on nqp and rakudo
dogbert17 timotimo: I'm the latest rakudo and on MoarVM master, i.e. 2911ec7e405f91 20:56
timotimo oh, building nqp and rakudo with an 16k nursery and gc debug, eh?
terrible idea, maybe
dogbert17 I tend only to rebuild MoarVM
timotimo yeah, well, i got different commits now :)
dogbert17 ah
timotimo did i not rebuild moarvm? this builds way too fast 20:58
dogbert17 my way of attacking this is probably suboptimal, I'm inserting test code earlier in the call chain where I check that tc->plugin_guards[i].u.type are ok
dogbert17 will now try to add it in remove_one_frame 20:59
timotimo Stage parse : 224.817 21:02
dogbert17 like my RPi 4 :)
timotimo i wonder if rr runs on an rpi 4 :) 21:03
dogbert17 now that's a good question :)
timotimo the problem doesn't reproduce the issue :( 21:06
dogbert17 it doesn't happen all the time, you might have to run for a while
sometimes I even start a spectest run in another terminal in the hope that loading the system will tease out the problem quicker 21:08
timotimo it doesn't want to reproduce at all :( 21:12
dogbert17 I know that the object is busted already when remove_one_frame runs. Guess I'll have to test MVM_frame_try_return now but if that doesn't work I don't know what I should do 21:13
bummer
on the other hand, if it happened all the time it would have been fixed ages ago 21:16
timotimo maybe
dogbert17 I have now inserted tests in MVM_frame_try_return 21:17
so the object is broken there as well, now I'm getting stumped 21:21
timotimo it's the result, yeah?
have you considered outputting the bytecode of the active frame?
dogbert17 I haven't
timotimo it's MVM_dump_bytecode(tc) 21:22
may have to do it early enough in the return thing so that it doesn't pick up the post-returned frame instead
dogbert17 I'm inserting code at different places in the call stack checking tc->plugin_guards[i].u.type if we're dealing with MVM_SPESH_PLUGIN_GUARD_TYPE 21:23
fwiw, it when it crashes it's always before any tests have run 21:24
timotimo oh, interesting
dogbert17 perhaps I'm doing this all wrong :(
timotimo lightning! 21:25
thunder!
dogbert17 ? 21:26
timotimo wait, do i have to put a check somewhere in addition to what moar already has?
so that it crashes?
dogbert17 b MVM_panic
timotimo the weather is happening here
21:28 chloekek left
dogbert17 is it getting any colder? 21:29
timotimo i'd expect so
haven't really stopped the AC to check :P
dogbert17 don't have AC :( 21:30
ok, does this tell you anything? gist.github.com/dogbert17/64cb7868...811d907750 21:32
timotimo what's tc's (or instance's?) gc_seq_number at that point? 21:33
that way we'll be able to tell how often GC runs before we hit that problem point
and we could break at the start of that exact gc run 21:34
dogbert17 should gc_seq_number exist in the tc? 21:36
timotimo maybe it's in the instance
dogbert17 gc_seq_number = 1048 21:38
nine Why don't we poison the fromspace after collection?
timotimo poison how? 21:39
mprotecd?
nine at least zero out
timotimo memprotecd
nine or free the memory block and reallocate it, so valgrind et al will flag any access
timotimo no need for that 21:40
valgrind has "client requests"
you can give a little more info, even
nine So why don't we use those?
timotimo we do use them for some things 21:41
at least if you have --valgrind in your Confiagure.pl
dogbert17 the value changes from run to run
is it run_gc which does in fact run the gc :) ? 21:43
timotimo yeah, but i'd breakpoint gc_enter_from_allocator 21:45
dogbert17 would it be possible for me to to my checks at the start and at the end of gc_enter_from_allocator 21:47
timotimo you'll have to hang on to the pointer value somehow
dogbert17 hmm 21:48
I was thinking of checking the values of tc->plugin_guards[i].u.type at the end and break if a FROMSPACE warning suddenly occurs 21:49
wouldn't that backtrace be of interest 21:50
timotimo this is where a time-travelling debugger would save your butt
dogbert17 just rub it in :-)
timotimo i'd love to help but it just won't happen on my machine 21:51
dogbert17 can I even be certain that it is the correct thread which enters gc_enter_from_allocator? 21:52
dogbert17 there's only one way to find out 21:54
timotimo it's likely that it'd be the code thread, not the spesh thread
dogbert17 so there's hope 21:55
timotimo i don't expect there to be more than one code thread
dogbert17 grr, it doesn't work, my code in gc_enter_from_allocator doesn't trigger but the check in interp.c does, sigh 22:04
timotimo ah, at the beginning of gc, the stuff will of course still be valid
because that'd be before fromspace and tospace are swapped
dogbert17 and at the end of the function ? 22:05
or is the swapping done later
timotimo just search for a line that has fromspace and tospace in it 22:06
that ought to find it
not sure what order
dogbert17 will check
it's present in a function called MVM_gc_global_destruction. That can't be it ? 22:09
timotimo no, that's not the right one 22:10
collect.c:77
dogbert17 MVM_gc_collect 22:11
I guess I should put my tests in that area then 22:12
timotimo well, immediately after switching, the pointer will of course point into the wrong space 22:13
because there will not have been anything to copy it over
or are you looking to see if it's in an even older space?
we don't have those i don't think
dogbert17 around here perhaps github.com/MoarVM/MoarVM/blob/mast...ect.c#L168 22:15
timotimo i'm not sure what the check would actually do 22:17
dogbert17 I'm simply trying to verify the stuff in tc->plugin_guards[i].u.type with the help of MVM_ASSERT_NOT_FROMSPACE 22:18
perhaps it totally the wrong thing to do 22:19
*it's 22:20
timotimo something's causing the entry to not be marked 22:21
whatever's holding on to plugin_guards, which i guess is the tc?
MVM_spesh_plugin_guard_list_mark should be getting it 22:23
dogbert17 aha
timotimo should the "i < num_guards" be "i <= num_guards" under some circumstances perhaps? i.e. does the i get incremented too late when adding more stuff there?
nine Oh, I think another GC issue with ConcBlockingQueue in the unshift method: github.com/MoarVM/MoarVM/blob/mast...eue.c#L200
to_add gets written to add->value, then GC may happen but add->value is not rooted 22:24
push assigns only after GC may happen (with to_add updated already)
timotimo we just had a lightning strike very close by 22:32
dogbert17 any thunder?
timotimo oh yeah 22:33
that's how i figured out that it was close
dogbert17 are your cats scared? 22:35
timotimo one fled under the sofa, i don't know where the other was at that moment
but she came back out soon enough and gave us headbumps on our hands
dogbert17 tough cat 22:36
timotimo tough but also extremely soft 22:37
dogbert17 nice 22:43
timotimo that's the one that starred in the "soft" photo on my blog
dogbert17 cool 22:48
if I put my tests at the end of restore_prev_spesh_plugin_state it will trigger the error 22:50
timotimo oh, does the mark function have to also mark everything with prev_ in it? 22:51
dogbert17 perhaps it should, what do you think? 22:53
timotimo we should give it a try
figure out how to sense if the prev_ stuff should be looked at, then mark it just like the non-prev stuff 22:54
ah, hold up
the prev_ stuff is only in the specialreturn data?
dogbert17 I think so
timotimo gist.github.com/timo/7fb69c74d8ddd...c6a2c584fc 22:55
try this patch
dogbert17 will do 22:56
src/spesh/plugin.c:288:44: error: ā€˜MVMThreadContext {aka struct MVMThreadContext}ā€™ has no member named ā€˜prev_plugin_guardsā€™ 22:57
timotimo ah, of course, must be srd 22:58
dogbert17 will fix
MVM_spesh_plugin_guard_list_mark(tc, srd->prev_plugin_guards, srd->prev_num_plugin_guards, worklist); ? 22:59
timotimo yup
dogbert17 well, it didn't crash immediately :) 23:00
guess I'll have to let it run for a bit 23:01
it would be very cool if that patch fixes the problem 23:02
still running ... 23:04
23:23 evalable6 joined
timotimo even though it's been raining and thundering and we opened up the windows and turned on ventilation and everything 23:28
it's still super warm inside
dogbert17 the patch doesn't seem to help :( 23:38
timotimo damn it 23:39
can you get the BT at the point where the last GC run happens?
dogbert17 does something else has to be done or are we on the wrong track
s/has/have/
BT? 23:40
timotimo backtrace 23:42
c-level
dogbert17 do we have a built in function for that? 23:43
timotimo it's "bt" 23:44
in gdb
dogbert17 yeah, but how am I supposed to get that for the last gc 23:45
timotimo worst case just get it for every single gc 23:46
did we get the sequence_num?
dogbert17 it was over 1000
timotimo d'oh

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!