github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo good question :\ 00:01
could just set it to 0 if it goes below 0
MasterDuke then that is the right place? no other place(s) i should be doing anything? 00:07
timotimo i think that ought to be the only place 00:08
MasterDuke ugh, i don't know how to detect overflow in c. let's just try a hack for now... 00:09
timotimo just compare the values before subtracting :) 00:10
MasterDuke that's what i'm doing, but what if `pcn->total_entries * tcpds->tc->instance->profiling_overhead` is so big it wraps around and then is less that exclusive_time? 00:11
timotimo oh 00:13
maybe it would be best to google that, there's surely a few gotchas that i wouldn't think of immediately
MasterDuke ohhh! 00:19
that made have made a real difference 00:20
*may have
btw, completely unrelated, but i found it amusing. before lunch on this first day of the intro to python class i'm taking this week i already had a PR in to cpython 00:22
timotimo nice
MasterDuke just some whitespace fixes to a couple docstrings and the output of `pydoc3 --help`, but it was fun 00:25
so a fresh profile without my changes has identity in 12th place, with 1514399 entries and 77.64ms exclusive 00:26
after my most recent change, it's really far down, same number of entries, 0.0ms exclusive
timotimo: this is what the patch looks like now gist.github.com/MasterDuke17/2dac1...b58151f8b0 00:46
timotimo you could debug-print how much the overhead is larger than the exclusive time 00:47
that's perhaps interesting
MasterDuke gist.github.com/MasterDuke17/ab710...13033ea3f8 00:53
timotimo i don't see a " = 0" 00:55
MasterDuke those are only printed in the `if (exclusive_time - overhead > exclusive_time)` branch 00:56
timotimo oh 00:57
MasterDuke some of the differences are pretty close to 0, but some are pretty big 01:00
01:06 AlexDaniel left
timotimo bedtime, gnite! 01:38
(actually far past)
MasterDuke later...
02:39 discord6 left 02:42 discord6 joined, discord6 left, discord6 joined 02:47 discord63 joined 02:48 discord63 left 02:49 synopsebot_ joined, synopsebot left, Geth_ joined 02:55 discord6 left 02:58 discord6 joined 02:59 discord6 left 03:00 squashable6 left 03:05 squashable6 joined 03:23 discord6 joined 03:24 Voldenet left 03:28 discord6 left 03:29 Voldenet joined, Voldenet left, Voldenet joined 03:49 Geth left, synopsebot_ left 03:50 Geth_ left 03:54 Geth joined, synopsebot joined 03:58 Geth left, synopsebot left 04:08 Geth joined
MasterDuke looks like geth was missing when i created github.com/MoarVM/MoarVM/pull/1111 04:08
04:15 synopsebot joined 04:34 Geth left, synopsebot left 04:39 Geth joined, synopsebot joined 04:46 Geth left 04:47 Geth joined 04:57 robertle left 05:05 synopsebot left 05:12 Geth left 05:14 synopsebot joined 05:18 synopsebot left 05:21 synopsebot joined, Geth joined 05:32 Geth left, synopsebot left 05:39 patrickb joined 05:40 Geth joined 05:42 synopsebot joined 05:49 synopsebot left 05:50 Geth left 05:52 synopsebot joined 05:53 discord6 joined 05:54 Geth joined 05:57 discord6 left 05:58 discord6 joined 05:59 discord6 left 06:02 discord6 joined 06:04 discord6 left, Geth_ joined, discord6 joined, discord6 left, discord6 joined 06:05 Geth left 06:06 discord6 left, discord6 joined, discord6 left, discord6 joined 06:07 discord6 left 06:08 synopsebot_ joined, synopsebot left 06:12 discord6 joined, discord6 left, discord6 joined 06:19 domidumont joined 07:11 TimToady left 07:19 TimToady joined
nwc10 good *, #moarvm 08:41
08:51 lizmat left 09:11 lizmat joined
jnthn o/ 09:17
nwc10 \o 09:22
I was about to typo that as o\
lizmat ohoh 09:23
09:34 zakharyas joined 10:08 domidumont left
Guest12727 jnthn: should I report the error, when running t/spec/S04-phasers/in-loop.t, uncovered by github.com/MoarVM/MoarVM/commit/9e...fe62bf366e 10:26
jnthn Guest12727: Yes, please 10:29
That's odd, I wonder if it's scribbling on an object header flag somewhere...
10:30 lizmat left
nwc10 pyfound.blogspot.com/2019/06/python...on+News%29 -- The asyncio philosophy is to avoid mixture by converting all blocking code to asynchronous coroutines, but converting a huge codebase all at once is intractable. “It's a harder problem than moving 10:35
from Python 2 to 3,” he said, “because at least I can go gradually from Python 2 to 3.”
"fixed in six" ? 10:36
timotimo Guest12727: could it be rakudo's extops aren't using the up-to-date flags?
nwc10 (I can't remember who coined that phrase, but rgs used it a lot)
timotimo hm. i think it should be possible to use valgrind client requests to lock object headers except for operations that are explicitly allowed to change them 10:37
jnthn nwc10: It's not just a huge codebase problem, if they mean the problem I think they mean
Hm, or maybe not, but... 10:38
It reminds me of when using Node.js and needing to do something that would take time, e.g. be async, but the library I was using didn't provide for doing anything async at that point, and there's no escape hatch really. 10:39
But since they mention "coroutines" then in theory you can yield anywhere
But in practice, I dunno :)
nwc10 is this like "it said Win95 or better, so I used a Mac" -- "so I used Cro" ? 10:40
jnthn :)
nwc10 I admit that I'm possibly missing details on any of this stuff. I'm finding it interesting partly from the bigguer picture perspective - the problems that Python is facing, and what solutions they are finding 10:41
the problems seem to map reasonably closely
hence my desire to steal solutions
Guest12727 timotimo: nqp and MoarVM were bumped yesterday so I guess that the extops should be ok 10:43
it crashes every other run, with assertion error, if MoarVM is compiled with --no-optimize. If it is compiled with opts it crashes, SEGV, one times in 100 10:45
timotimo does turning jit or spesh off make a difference? 10:46
Guest12727 MVM_SPESH_INLINE_DISABLE=1 makes the problem vanish
timotimo: here's the assertion crash, gist.github.com/dogbert17/ebfd1ff0...18f4d9b208 10:47
timotimo no inlining also probably means much less escape analysis
11:01 zakharyas left 11:02 AlexDaniel joined 11:46 ggoebel joined 12:06 pamplemousse joined 12:08 zakharyas joined 12:16 zakharyas left 12:21 zakharyas joined 12:22 domidumont joined 13:28 brrt joined 13:53 zakharyas left
brrt \o 13:56
pamplemousse o/
14:00 brrt left
Geth_ MoarVM/more-pea: 47 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/2...5910cf9cb4		 14:11
jnthn (rebase)
nwc10 no new things to tempt ASAN with (yet?) 14:13
jnthn :) 14:14
Well, some Rakudo spectests run with MVM_SPESH_BLOCKING=1 errupt with SEGV :)
And a couple seem to hang
So certainly some work to do yet :)
nwc10 "have fun' (but not *too* much fun) 14:15
japhb
.oO( rebass: When the DJ drops it twice )
jnthn Darn, every crash I've found so far happens in concurrent code 14:18
I was really hoping for a case that might be easier to debug :)
14:19 brrt joined
jnthn Hm, many start with a backtrace like 14:20
(gdb) p MVM_dump_backtrace(tc)
at SETTING::src/core/Promise.pm6:44 (/home/jnthn/dev/rakudo/CORE.setting.moarvm:BUILD)
from SETTING::src/core/Promise.pm6:38 (/home/jnthn/dev/rakudo/CORE.setting.moarvm:new)
from SETTING::src/core/Promise.pm6:249 (/home/jnthn/dev/rakudo/CORE.setting.moarvm:start)
So yeah, if Promise starting blows, that'll blow up many things :)
14:47 lizmat joined 14:58 brrt left
pamplemousse Progress update blog post is out! yakshavingcream.blogspot.com/2019/...erl-6.html 15:11
jnthn grmbl, after a wild goose chase I realized it's because it's not nulling non-auto-viv registers out 15:18
Which is annoying because I was planning to re-work object creation some also, and now I might go and do that first :) 15:21
Since what I had in mind would solve this problem without having to write any more code 15:22
15:36 patrickb left 15:52 sena_kun joined 15:54 domidumont left
nwc10 tries to imagine how to play Jenga by stacking yaks 15:56
it's unclear if it would work
16:02 brrt joined
dogbert17 jnthn: M#1112 16:35
synopsebot_ M#1112 [open]: github.com/MoarVM/MoarVM/issues/1112 Assertion error or SEGV when running t/spec/S04-phasers/in-loop.t
nwc10 Oh I'd missed that 16:36
moar: src/gc/collect.c:589: MVM_gc_collect_free_nursery_uncopied: Assertion `item->sc_forward_u.forwarder != ((void *)0)' failed.
Aborted
ASAN considers this problem boring and says nothing
jnthn vm_code->header.flags |= RAKUDO_FIRST_FLAG; 16:37
It's because RAKUDO_FIRST_FLAG needs to be a bit that doesn't mean something to the GC :)
dogbert17 so the value of that constant has to change ? 16:39
jnthn Yes 16:40
16384 is probably safest 16:41
dogbert17 it's 128 atm 16:42
jnthn MVM_CF_FORWARDER_VALID = 128,
haha
that'll go very badly
dogbert17 :)
the file defining this is in the Rakudo repo it seems 16:44
16:44 robertle joined
jnthn Yes, it should just be a change there 16:45
dogbert17 me, you or nwc10 :)
dogbert17 tries it out
jnthn I'm in a branch trying to put Rakudo back together after some MoarVM changes :)
dogbert17 a few days ago 128 meant MVM_CF_GEN2_LIVE = 128 16:49
jnthn That'd be less likely to break, but still in theory could 16:50
dogbert17 is it enough to rebuild rakudo? 16:51
jnthn brrt: Yes 16:52
dogbert17 it seems to be working a lot better now :) 16:54
Geth_ MoarVM/p6o-setup: 504835a7dd | (Jonathan Worthington)++ | 3 files
Prepare for more general P6opaque setup

This will initially just be about initial setup of VMNull so we need not check for it on every read, but will then get exposed as part of the REPR interface in order to allow non-lazy (that is, without the auto-viv) object setup to be specified too.		 16:55
MoarVM/p6o-setup: 9638d3a71c | (Jonathan Worthington)++ | 4 files
Null non-auto-viv P6opaque object slots at init

And when we specialize the `create`, then spit out instructions to initialize the slots to VMNull. This in turn means we can get rid of the NULL checks on attribute access, so it can JIT into something far simpler.
jnthn oops, I meant to aim at dogbert17 above :) 16:56
brrt: You'll probably be glad to see the p6o-setup branch though :-)
brrt: I've realized that in Rakudo we only need lazy attr init in the case that an attribute has a default AND appears in a class that ha a BUILD. In all other cases, we don't actually need it. 16:57
brrt: And so can eliminate the laziness :) 16:58
We'll then spesh that into a sequence of normal object setup instructions
Which in turn will work out much better for the escape analyzer than trying to figure out the auto-viv stuff :)
brrt oh, hey 17:06
that is pretty cool
jnthn Yeah, should be far tighter JIT output in a load of cases
brrt \o/
jnthn dinner & 17:18
dogbert17 jnthn: have sent a PR 17:27
brrt should have dinner as well 17:43
17:43 brrt left 18:59 lizmat left 19:00 lizmat joined
timotimo hum. i'm rebasing my confprog changes on latest origin/master and it's giving me such odd conflicts 19:02
why are there add/add conflicts? 19:10
nwc10 I don't know. I don't think that I've met these before. Is git helpful enough to tell you which commit it thinks added the files on each "side"? 19:13
did it get the rebase start point wrong? (ie the same commit is on both "sides" - the real master, and the string of commits it wants to rebase)? 19:14
I am awake, but I hope someone else with a better idea is also awake
timotimo it does give me one commit message as well as "HEAD" for the other side 19:23
nwc10 er, not sure what to do. 19:24
HEAD (I think) is the detached head that is your "in progress" rebase
timotimo that makes sense
nwc10 I don't know if there's a way to get the planned list of things it was giong to do
ie, what you would get in your editor at the start if you do --interactive 19:25
if you're not going to loose anything by --abort
then I suggest trying to figure out which commit it's talking about with the commit message you see currently
then --abort
then try again with --interactive
and see if commits with that message are *both* in the list of things it intends to rebase
and also the thing it intends to rebase onto 19:26
"the thing it intends to rebase onto" being master?
timotimo gist.github.com/timo/18fab69687fbe...d9d3687126 here's some deets
nwc10 also, I can't totally be helpful right now as I'm trying to untangle the cazy history of the work code that got the better of me this morning 19:27
timotimo oh you're also in commit history hell :)
nwc10 yes, ish. this is (literally) a line in this 10 year old thing with # wtf 19:28
that is now
timotimo :D
nwc10 if (0) # wtf
but I think was
if (1) # wtf
earlier
there's an else block
I missed that this morning when everythign on the time tracking system was titsup
19:29 lizmat left
timotimo i *think* i have rerere turned on 19:29
hum.
no, i don't think i do
nwc10 I'm sort of aware of what rerere is.
OK. had you said "and I have it enabled' then I know this problem is "above my paygrade" 19:30
I've never used it
timotimo it'll remember how you resolved a given conflict "the last time" and allows you to just let it do the same thing you did before again
nwc10 oh, erk, a Yak 19:31
(mine, not yours)
timotimo: that summary is about as much as I know about it
timotimo right
um 19:32
it does look like it's trying to put the same commits on top of each other
nwc10 aha. yes, had that happen
I can't remember why
timotimo check "start on a parser/compiler" appearing twice 19:33
what the flying spaghetti monster?
nwc10 "I don't know" and I think I need to concentate ony my small yak's nest
(sorry)
I hope a refereshed jnthn reappears soon 19:34
unlike Flash, he might "saveeveryoneofus"
(yes, the Yak is "I guess this would be easier if I first deleted the code to serve the Flash policy-file-request XML")
timotimo flash, as in Macromedia Flash? 19:35
nwc10 yes
there is a lot of cruft
timotimo could be worse. could be shockwave3d
nwc10 the flash implementation was deleted years ago
timotimo anyway, i'm quite glad to see that none of these conflicts were actually something i need to be worried about 19:36
it seems like i recently merged one version of origin/configurable-subsystems into my local configurable-subsystems 19:43
that's where the duplication seems to come from, both had copies of the same changes but based on different other commits
resetting before that merge commit and rebasing gives me a clean rebase run 19:44
nwc10 That seems to make sense (the "why rebase might be confused") 19:46
Geth_ MoarVM/configurable-subsystems: 17 commits pushed by (Timo Paulssen)++
review: github.com/MoarVM/MoarVM/compare/7...1732de6645		 20:13
20:13 pamplemousse left 20:28 Kaiepi joined 21:01 lizmat joined 21:51 lizmat left 22:05 robertle left 23:00 Altai-man_ joined 23:02 sena_kun left 23:03 lizmat joined 23:05 sena_kun joined 23:07 Altai-man_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!