| IRC logs at
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/
Add "use 5.020" to

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: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>
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, 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 - 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 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 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
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: 20:31
20:32 lizmat left
MasterDuke lizmat++ 20:39
jnthn: question here for you (timotimo, nine, etc might also be able to answer) 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: 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: - 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