github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:24
pamplemousse joined
01:32
zakharyas joined
01:49
Kaiepi joined
01:59
pamplemousse left
03:04
Kaiepi left
|
|||
moritz | m: say 'working?' | 04:41 | |
camelia | sudo: /home/camelia/rakudo-m-inst/bin/perl6-m: command not found | ||
moritz | *sigh* | ||
04:41
camelia left
05:22
Kaiepi joined
|
|||
Geth | MoarVM: 1a8988c099 | (Moritz Lenz)++ | tools/expr-template-compiler.pl Add "use 5.020" to expr-template-compiler.pl the List::Util usage corresponds to a perl of at least 5.20, and I hope this gives a better error message in case of an older perl. |
05:38 | |
05:55
robertle left
06:15
lizmat joined,
lizmat left
|
|||
moritz | according to Travis CI, some of the MoarVM build jobs were broken by this commit, and the majority worked, and all on Perl 5.10. "Sure". | 06:52 | |
07:07
domidumont joined
|
|||
nwc10 | I share your concerns about its accuracy here - if it thinks that *that* commit broke things, how many other times does it get causes of breakage wrong? | 07:08 | |
(don't get me wrong - "it's broken" is a useful thing to know, but confidently then stating "and this is why" and getting that part wrong, not so useful) | 07:09 | ||
also, I had been wondering, is it better to bump the version requirement (and manybe placate travis by also stating what version of perl 5 it needs to install first) | |||
or simply re-writing the code using constructions that are available in whatever prehistoric perl Centos 6/Solaris 10/you name it ships with | 07:10 | ||
07:54
patrickb joined
07:55
robertle joined
08:23
sena_kun joined
09:41
domidumont left
|
|||
Guest71418 wonders when nine is back from his vacation | 10:08 | ||
10:27
zakharyas left
12:02
robertle left
12:04
robertle joined
12:54
domidumont joined
13:00
discord61 joined,
discord61 left,
discord61 joined
13:01
discord61 left
13:19
robertle left
|
|||
Guest71418 | hmm, 'Type check failed in binding to parameter '<anon>'; expected Any but got VMNull (?) at t/spec/S17-lowlevel/cas.t line 106' | 13:20 | |
that's what you get when you set the nursery size to 512 bytes :) | 13:22 | ||
13:33
lucasb joined
|
|||
Guest71418 | .seen timotimo | 13:39 | |
tellable6 | Guest71418, I saw timotimo 2019-08-25T22:09:48Z in #moarvm: <timotimo> scan.coverity.com/projects/paultco...b=overview | ||
Guest71418 | .seen tellable6 | ||
tellable6 | Guest71418, I haven't seen tellable6 around, did you mean evalable6? | ||
tadzik | :D | 13:40 | |
no self-awareness | |||
Guest71418 | indeed :) | 13:42 | |
13:46
committable6 left,
evalable6 left,
bisectable6 left
13:48
evalable6 joined
13:49
bisectable6 joined
13:50
committable6 joined
|
|||
timotimo | ohai | 13:57 | |
MasterDuke | timotimo: don't know if you've been following github.com/libtom/libtommath/pull/330, but i just re-wrote it to assume it's passed an appropriately sized buffer (i.e., it doesn't realloc). makes it a bit faster, now the crossover between the original mp_toradix and mine is at ~2**1k instead of ~2**2k | 14:09 | |
timotimo | how big does the "appropriately sized buffer" have to be? basically log10 of the input number? | 14:12 | |
MasterDuke | yeah | ||
timotimo | so you'd rely on the caller to either already know or be able to quickly figure that out for you? | 14:13 | |
and if the caller gets it wrong it'll segfault :D | |||
MasterDuke | calculating that has also been really slow, which is why i was doing the reallocing. but since that's about to get fast, we can keep the same api for my version | ||
timotimo | or more likely buffer overflow | ||
MasterDuke | yep | ||
timotimo | ah, there'll be that API that can estimate the log10 of a number quickly, right? | ||
MasterDuke | that's about to be introduced (or maybe was in their most recent release) | 14:14 | |
timotimo | good to know | ||
Guest71418 | timotimo: can we trick you run MoarVM through Coverity? | 14:18 | |
*trick you to run | |||
timotimo | no, but you can trick me to upload a coverity scan result to the website | ||
Guest71418 | yes please :) | ||
timotimo | there'll have to be a scan result file that i can take | 14:19 | |
Guest71418 | do the scans run automatically? | ||
14:20
robertle joined
|
|||
timotimo | scan.coverity.com/download - you just have to "cov-build --dir cov-int make -j4" and you'll have the file | 14:25 | |
MasterDuke | "Admin access to at least one project is required to download the Coverity Build Tool." | 14:27 | |
Guest71418 | there are three admins, timotimo, jnthn and P. Cochrane | 14:29 | |
timotimo | m( | 14:35 | |
www.sharedrop.io/rooms/de9c79a5-17...0813f8c9f5 | 14:36 | ||
it's a big file | |||
but i have decent upstream bandwidth | |||
i'm trying to recompress it with zstd to get it smaller | 14:39 | ||
Guest71418 | so you're uploading it now? | ||
timotimo | that link is a p2p thing | 14:42 | |
251401348 715M -rw-r--r--. 1 timo timo 715M Aug 26 16:36 cov-analysis-linux64-2019.03.tar.gz | |||
251401349 518M -rw-r--r--. 1 timo timo 518M Aug 26 16:39 cov-analysis-linux64-2019.03.tar.zst | |||
you'll have to connect before i can send | |||
Guest71418 | I thought you were uploading it to the coverity website | 14:43 | |
timotimo | no | ||
i was hoping someone would run the scan for me | |||
MasterDuke | i see an intelligent cat connected? | ||
timotimo | yep that's me | 14:44 | |
Guest71418 | aha, but don't we have to be admins in order to do that? | ||
timotimo | no, only to download the tools apparently | ||
Guest71418 | perhaps MasterDuke given that he has a monster machine :) | 14:45 | |
timotimo | the scan takes like two minutes | ||
MasterDuke | it's downloading | ||
Guest71418 | cooool | 14:46 | |
I got a 'An error occurred during a connection to www.sharedrop.io. PR_CONNECT_RESET_ERROR ' | |||
'Report errors like this to help Mozilla identify and block malicious sites' :) | |||
timotimo | i'm rerunning zstd with -19 as well, it's compressing a little better still | 14:47 | |
MasterDuke: is it still doing anything? the transfer progress doesn't seem to move? | 14:53 | ||
251401350 461M -rw-r--r--. 1 timo timo 461M Aug 26 16:48 cov-analysis-linux64-2019.03.aggressive.tar.zst | |||
MasterDuke | hard to tell, wasn't moving very fast | 14:54 | |
huh, how do you cancel? | 14:56 | ||
timotimo | there isn't much outgoing traffic on my network interface | ||
doesn't seem to have UI for that, so i guess you'd just F5 the tab | |||
MasterDuke | now i'm a zebra | ||
timotimo | here comes the file | ||
japhb | timotimo: Was the gzip version with -9? I'm curious just how far zstd has outpaced gzip these days. | 14:57 | |
timotimo | cov-analysis-linux64-2019.03.tar.gz: gzip compressed data, last modified: Fri May 17 01:30:49 2019, from Unix, original size 1545594880 | 14:58 | |
how do i find out what number was used? | |||
MasterDuke | timotimo: would it offend you if i offered to pay for you to get an upgrade to a 56k modem over whatever you have now? | 15:01 | |
timotimo | lol wtf | 15:05 | |
why is it slow i don't understand | |||
this tool used to be able to saturate my connection | |||
MasterDuke | yeah, i think we've used it before and it was fast | 15:06 | |
i'm on a different isp now, maybe that's it | |||
of course i'm also a couple thousand miles closer... | 15:07 | ||
japhb | If you (and by "you" I mean everyone at your access point) are doing heavy downloading and uploading at the same time on an asymmetric network uplink, you may be getting ack starved. It's been a while since I've seen that personally, but I remember it used to drive me nuts when it happened. | 15:13 | |
timotimo | not the case on this network, as far as i know | 15:14 | |
15:30
robertle left
|
|||
timotimo | it's possible that somewhere along the path there's an API in the browser that has a size limit or something | 15:36 | |
i ran the scan myself now | 15:44 | ||
so yeah | |||
you *can* trick me into running that | |||
Last Build Status: In-queue. Your build is in the queue to be analyzed. There are 102 builds ahead of it. | 15:46 | ||
it seems like it'll show up soon | 15:52 | ||
something seems wrong though?! | 15:53 | ||
it has code that i just recently committed, but it shows the version as 2018-something | 15:55 | ||
anyway, have at it in the defect viewer | 16:02 | ||
16:04
patrickb left
16:09
domidumont left
|
|||
dogbert17 | timotimo++ | 16:24 | |
timotimo | aha the front page of the project has updated | ||
dogbert17 | there are defects related to src/profiler/configuration.c | 16:25 | |
timotimo | yup | 16:26 | |
it me | |||
i made a bad code | |||
dogbert17 | nah, you forgot a line | ||
16:31
Kaiepi left
|
|||
dogbert17 | there's some interesting stuff in here | 16:32 | |
Geth | MoarVM: dogbert17++ created pull request #1164: Fix incorrect return type in get_effective_size |
16:49 | |
17:13
robertle joined
17:15
patrickb joined
17:41
sena_kun left
18:28
Kaiepi joined
18:29
chloekek joined
18:34
chloekek left
19:35
Ven`` joined
19:37
Ven`` is now known as Ven_de_Thiel
19:47
chloekek joined
20:02
pamplemousse_ joined
20:31
lizmat joined
|
|||
lizmat | and yet another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/08/26/...-atlantic/ | 20:31 | |
20:32
lizmat left
|
|||
MasterDuke | lizmat++ | 20:39 | |
jnthn: question here for you (timotimo, nine, etc might also be able to answer) www.reddit.com/r/perl6/comments/cv...r%C4%ABga/ | 20:40 | ||
20:46
MasterDuke left
|
|||
pamplemousse_ | lizmat++ | 20:51 | |
21:00
lizmat joined
21:18
Ven_de_Thiel left
21:20
pamplemousse_ left
|
|||
dogbert17 | looking at the coverity scan defects there are plenty of 'missing break in switch' problems reported | 21:20 | |
is it common to let things fall through or is it indeed a sign of a mistake | 21:21 | ||
here's an example from the report: github.com/MoarVM/MoarVM/blob/mast...ads.c#L269 | 21:22 | ||
lizmat | . | 21:24 | |
tellable6 | 2019-08-26T20:37:33Z #perl6 <AlexDaniel> lizmat: re āFWIW, only these people are allowed to vote, after which Jonathan Worthington will decide.ā, it's other way around | ||
2019-08-26T20:38:47Z #perl6 <AlexDaniel> lizmat: so jnthn will be giving feedback so that we get a PR that is aligned with his view, then everyone votes (technically jnthn too) | |||
jnthn | Right, that's how I understood it too :) | 21:29 | |
If I really want to veto something, I just don't vote for it and let the need for consensus take care of things | 21:30 | ||
timotimo | i wrote a little response about putting a better GC into moar | 21:31 | |
jnthn: www.reddit.com/r/perl6/comments/cv...r%C4%ABga/ - i'd love to hear a short sentence on whether i've gotten it right | |||
jnthn | timotimo: I'd say it's about right; read barriers would indeed be challenging. But having good PEA can save a lot of things from needing collection, which will give us a lot more out of the collector we have. | 21:38 | |
It's already relatively unusual for GC to be the bottleneck today. | 21:40 | ||
timotimo | i've had a workload recently that was pretty high on GC, but of course i already forgot what it was | ||
21:41
patrickb left
|
|||
japhb | jnthn: I *think* the GC pauses still cause hiccups in animations/games though. When I graph frame times for some of my animation times, I see periodic frames that take an extra 10-20 ms to complete, and the more work each frame has done, the closer together these are. So I'm suspecting GC pause, but since I can't detect the GC's (no event I can watch for this, or metric I can check each frame, that I know | 21:44 | |
of at least), I can't be sure. | |||
lizmat | japhb: do you know of nqp::forcegc ? | 21:45 | |
timotimo | force_gc iirc | 21:46 | |
lizmat | oops, yes, that | 21:47 | |
timotimo | put force_gc in a spot where the stack is small and most lexical variables and locals and such have been nulled out, that'll get you the best results i believe | ||
but yeah, incremental GC would be pretty darn spiffy to have | |||
not quite as spiffy to build | |||
21:48
lizmat left
|
|||
timotimo | japhb: did you already see that moarperf shows you what types get deallocated by GC? | 21:52 | |
it'll give you the number of instances deallocated during each of the GC runs, so you'll get an "over time" view, too | 21:53 | ||
japhb | lizmat: I have not been using forcegc; frankly I'd just like to detect that a GC *happened*, and get an idea of which parts of a complicated test run are causing GC churn and which ones are relatively "GC quiet" | ||
tellable6 | japhb, I'll pass your message to lizmat | ||
japhb | timotimo: I haven't been using moarperf. Last time I looked at it (admittedly, a while ago), it was still experimental (and it gave partially incorrect info at the time). | 21:55 | |
1. What state do you feel like it's in now? | |||
2. Where is there a getting started guide for it? | |||
timotimo | it's honestly in a terrible state when it comes to people trying it out; you need to run frickin NPM to get the javascript turned into the files that the html uses and such | 21:56 | |
japhb | lizmat: Although I do understand the point about trying to flatten the spikiness, I'd prefer not to do that by making each frame much slower. If it really does a good job of amortizing the GC cost across e.g. 30 frames, that's one thing, but if it only drops the GC cost by half and now does it every frame, it's worse. | 21:57 | |
tellable6 | japhb, I'll pass your message to lizmat | ||
timotimo | there's a desire to get a way to get moarvm-internal events delivered to user code, that would include things like "gc happened" | ||
japhb | timotimo: BLEAH. npm on my corp machine is in a very sad state, and last I checked on my home machine was really out of date unless you wanted to build it yourself. So I ended up having to run docker just to deal with npm's rapid turnover. | 21:58 | |
timotimo | Telemetry would also like to have a "number of times the GC ran so far" value to track | ||
japhb | timotimo: Yeah, I'd love that. | ||
timotimo | i don't yet have a good idea how best to distribute the javascript build results | ||
i also don't want to commit them every time i change JS, then the git repo will grow to gigabytes in no time | 21:59 | ||
japhb | timotimo: Yeah, I get that. | ||
Actually, maybe you should just put a dockerfile in your repo that will let people fetch the pieces and build a docker image that contains all the stuff they need to use it. | 22:00 | ||
22:01
chloekek left
|
|||
timotimo | i haven't yet gotten to docker because i wanted it to be possible to run code right out of the web interface | 22:06 | |
unfortunately, i have no good idea how to make the user's installed rakudo available to the docker in question | 22:07 | ||
i know AppVeyor has a relatively simple "make the file that the code created available as download" feature, whet do i look for to get the same on travis? | 22:08 | ||
OTOH, there's not really a need for the build to run on travis | 22:14 | ||
jnthn | japhb: That sounds like you're getting full GC runs. In terms of detecting them: I plan to integrate Log::Timeline support for GC so you could then log frame rendering start/end and be able to see it against GC runs. | 22:38 | |
japhb: But beyond that, I'd guess such could has an amount of short-lived allocations (that the EA will be able to help with) and potentially use of natives (where we wastefully make a lot of nativerefs today); ideally it'd be possible to only end up with nursery collects. | 22:39 | ||
timotimo | jnthn: got any design wishes for the mechanism that'll notify userspace of mvm-internal events? | 22:40 | |
jnthn | Drop 'em into a CBQ | 22:41 | |
timotimo | i imagine pushing a little hash with info whenever a GC run happened will be extra fun when you're running GC torture with a 512 byte nursery and every gc run causes another gc run when the info gets published :D | ||
jnthn: should the data pushed into the CBQ from moarvm's side already look exactly like the Log::Timeline format? | 22:43 | ||
jnthn | timotimo: No; my idea was to provide some Rakudo-specific API for getting such things and then Log::Timeline can consume that | 22:50 | |
Probably exposed as a supply | |||
timotimo | i mean, if you give me a guideline for how the data that comes out of the queue in question should look like, maybe it'll just materialize over night | 22:52 | |
*hint hint* | |||
jnthn | I guess a cheap way is just an integer array with the values in (start time, end time, 0/1 for nursery/full, bytes promoted) | 22:53 | |
timotimo | so would there be one queue for GC stuff, another queue for, dunno, socket-related stuff maybe? one queue for spesh-related stuff? | 22:54 | |
and maybe an nqp::mvmeventsubscribe($my-queue-object, $number-of-event-kind) with $number-of-event-kind being maybe 0 for GC, 1 for spesh, etc etc? | 22:55 | ||
jnthn | Something liek that, yeah | ||
No, I think one queue will do | |||
Though if we do it as you suggest, then the consumer gets to decide. :) | |||
timotimo | could still have a bitfield for the decision part | 22:56 | |
jnthn | I think integer array works for GC, but for spesh I guess we might want something else | ||
timotimo | fortunately the CBQ isn't typed ;) | ||
jnthn | ;) | ||
timotimo | so perhaps the first entry in whatever gets pushed into the CBQ will be a type identifier for the kind of event, and after that can come whatever. maybe have a little trapdoor where if it's a hash instead of an array, then the key "eventtype" will be used for that instead of the first entry of the array | 22:57 | |
or some such | |||
so we don't have to put an array with the number at the start just to put a hash next to it | 23:00 | ||
jnthn | oh, hmm...yeah, the type is an issue | 23:01 | |
Oh, or | |||
We could, you know, use types :P | |||
class GCEvent is array[int] { } or whatever | 23:02 | ||
timotimo | t... t... types!?! | 23:04 | |
ah, the subscribe op could take a "config" hash much like repr config works perhaps | 23:06 | ||
and then, if "gceventtype" is present, the queue will be getting gc events | 23:07 | ||
(of that type) | |||
and different kinds of events would perhaps like different REPRs, so "class ComplicatedEvent is repr<MVMHash> { } | 23:09 | ||
if we want to have anything like that at all, that is | |||
jnthn | timotimo: Well, I want to be able to turn on/off monitoring of a given event type dynamically also | 23:13 | |
timotimo | but it'd be fine to have a single queue for the entire instance? | 23:14 | |
passing nqp::null for the queue argument could be useful for "reconfigure the event delivery" | 23:15 | ||
then turning off a kind of event could be done by supplying nqp::null in the configuration hash where normally the type would go | |||
23:17
Kaiepi left
|
|||
jnthn | Could work; I guess that means you can set up a bunch of them at once | 23:18 | |
timotimo | yeah, that's how i envision it | ||
instead of a bitfield where you gotta know what bit means what, keys in a hash would be used, and at the same time supply the type that the queue will spit out | |||
jnthn | Happy hacking. I've got meetings tomorrow, and should be resting well still... 'night o/ | 23:24 | |
timotimo | o/ | ||
23:28
evalable6 left,
bisectable6 left,
committable6 left
23:30
committable6 joined
23:31
tellable6 left,
notable6 left
23:32
evalable6 joined
23:33
bisectable6 joined,
notable6 joined
23:35
tellable6 joined
23:52
releasable6 left
23:53
releasable6 joined
|