Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-05

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

All times shown according to UTC.

Time Nick Message
00:18 Geth ¦ MoarVM: samcv++ created pull request #717: Disable tests on Appveyor until we can fix the build
00:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/717
00:22 AlexDaniel what a coincidence
00:24 AlexDaniel oh, not so much of a coincidence, it's just that I didn't backlog here…
00:24 AlexDaniel .tell brrt fwiw a ticket for that: https://github.com/MoarVM/MoarVM/issues/718
00:24 yoleaux AlexDaniel: I'll pass your message to brrt.
00:25 samcv AlexDaniel, we can disable the testing which has always had issues. so hopefully we can fix the build then someone can make sure it doesn't freeze during make test with nqp
00:26 samcv and it seems like it's turning "/" into "\". but i can see the code that does it for the Makefile and one other file. but maybe i just can't find where we possibly do it for other files. though that emit.c is created partly by dynasm i think
00:26 AlexDaniel samcv: all I know is that we've just noticed a real failure because appveyor was doing it's job
00:27 AlexDaniel so I'd much rather have it red than not have it at all
00:27 samcv you mean on the rakudo appveyor or the moarvm one
00:27 AlexDaniel on moar
00:27 samcv well it's not helpful if it's red when the biggest case that happens is the build is broken for windows, but the testing is unchanged
00:28 samcv that's the most common thing that happens RE windows builds
00:29 samcv and the test results are not useful if the testing doesn't even complete because of some unknown thing
00:31 * AlexDaniel shrugs
00:43 committable6 joined #moarvm
00:44 samcv because of that we didn't notice the build actually breaking with the recent JIT merge
00:53 bisectable6 joined #moarvm
01:08 AlexDaniel samcv:  oooh, I understand your point now
01:09 AlexDaniel samcv: yeah, alright. Sorry
01:10 samcv np AlexDaniel :) don't apologize.
01:11 AlexDaniel well, I should've thought about it a little bit more :)
01:11 AlexDaniel it's kinda not OK that we'll have tests running on travis but not appveyor, but yeah, that'll probably be more useful
01:12 AlexDaniel samcv:  why not merge it?
01:12 samcv your view was perfectly understandible without more information. so it's fine. i hope soon we'll figure out the issue. i may eventually make a windows VM or something
01:12 samcv AlexDaniel, was trying to see what appveyor would come back with
01:13 samcv i'm less familiar with appveyor compared to Travis, and have had to do many more trials than i'd expect to get it right
01:14 samcv though i did that before i knew that appveyor was always failing. so i'll merge now :P
01:14 AlexDaniel OK I renamed https://github.com/MoarVM/MoarVM/issues/697 accordingly
01:14 Geth ¦ MoarVM: f6548703f0 | (Samantha McVey)++ | .appveyor.yml
01:14 Geth ¦ MoarVM: Disable tests on Appveyor until we can fix the build
01:14 Geth ¦ MoarVM:
01:14 Geth ¦ MoarVM: If it stalls during testing, we get no feedback on when the build itself
01:14 Geth ¦ MoarVM: has broken.
01:14 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f6548703f0
01:14 Geth ¦ MoarVM: e264bfa884 | (Samantha McVey)++ (committed using GitHub Web editor) | .appveyor.yml
01:15 Geth ¦ MoarVM: Merge pull request #717 from samcv/ap
01:15 Geth ¦ MoarVM:
01:15 Geth ¦ MoarVM: Disable tests on Appveyor until we can fix the build
01:15 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e264bfa884
01:15 samcv AlexDaniel++
01:15 AlexDaniel samcv++ :)
01:22 releasable6 joined #moarvm
01:33 bisectable6 joined #moarvm
01:33 squashable6 joined #moarvm
01:33 statisfiable6 joined #moarvm
01:55 ilbot3 joined #moarvm
01:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:57 zakharyas joined #moarvm
02:03 arnsholt joined #moarvm
02:24 AlexDaniel b: help
02:24 bisectable6 AlexDaniel, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: https://github.com/perl6/whateverable/wiki/Bisectable
03:05 Ven`` joined #moarvm
03:07 TimToady joined #moarvm
03:21 Util joined #moarvm
05:16 evalable6 joined #moarvm
06:09 domidumont joined #moarvm
06:17 domidumont joined #moarvm
07:12 domidumont joined #moarvm
07:15 hoffentlichja joined #moarvm
07:29 patrickz joined #moarvm
07:30 patrickz joined #moarvm
08:36 domidumont joined #moarvm
10:02 robertle joined #moarvm
10:10 Geth ¦ MoarVM: a9f4770110 | (Jonathan Worthington)++ | 6 files
10:10 Geth ¦ MoarVM: Make thread GC nurseries scale to need
10:10 Geth ¦ MoarVM:
10:10 Geth ¦ MoarVM: Many threads (such as the specialization worker and the Rakudo GC
10:10 Geth ¦ MoarVM: supervisor) run and allocate relatively little. Thus they will never
10:10 Geth ¦ MoarVM: fill a nursery, and so there's no point them having a sizable one.
10:10 Geth ¦ MoarVM:
10:10 Geth ¦ MoarVM: This change starts all but the main thread off with a smaller nursery.
10:10 Geth ¦ MoarVM: <…commit message has 10 more lines…>
10:10 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a9f4770110
10:13 nwc10 good *, jnthn.
10:14 nwc10 will there be bloggage about that commit, with some numbers for the win?
10:15 jnthn Dunno, given I'm so behind with blogposts I have to write for funded stuff...
10:16 nwc10 you've now run out of funds?
10:16 jnthn Yeah
10:16 nwc10 :-(
10:17 nwc10 that's a bother
10:17 jnthn True, but at least it means work ain't adding to my blogging backlog :P
10:18 jnthn The ticket I was looking at is https://rt.perl.org/Ticket/Display.html?id=131915 fwiw
10:18 jnthn Which complained about memory use after just doing one run(...)
10:18 jnthn Which is implemented in terms of Proc::Async
10:18 jnthn And so starts some background threads or so
10:19 jnthn Most of the improvement came from the new scheduler
10:19 jnthn Which starts a bunch less threads
10:19 jnthn But the specializer worker is a "normal" thread too (I don't want "two kinds of threads")
10:19 jnthn And the supervisor in the scheduler is another one
10:21 jnthn So giving them smaller nurseries is a win
10:21 jnthn Base memory according to the measurement technique used in the ticket is now 90% of what it was before the run and 83% of what it was after
10:22 jnthn m: say 114948 / 76896
10:22 camelia rakudo-moar a28c00: OUTPUT: «1.494850␤»
10:22 nwc10 ah OK cool thanks
10:22 nwc10 I hadn't realise that this was driven by a particular ticket
10:22 nwc10 and had assumed that it was a more general "this optimisation is a big win"
10:22 jnthn m: say 139220 / 85104
10:22 camelia rakudo-moar a28c00: OUTPUT: «1.635881␤»
10:22 jnthn Phew :)
10:23 jnthn I was worried for a moment that I'd made the base case sufficiently better that it would cancel out my actual win :P :P
10:23 jnthn m: say 56568 R/ 215976
10:23 camelia rakudo-moar a28c00: OUTPUT: «3.817989␤»
10:23 jnthn OK. So I've improved that ratio from 3.8 to 1.5
10:25 evalable6 joined #moarvm
10:28 jnthn I'm curious what the number that process is using is though, as /usr/bin/time shows a rather lower maxresident
10:28 jnthn And massif shows lower still, but I bet that doesn't count the mmap'd bytecode files
10:29 ilmari virtual vs. resident size?
10:29 lizmat jnthn: re attribute default initialization: what is the reason for the "will build" trait, why not just call set_build on the attribute in Actions ?
10:29 jnthn Presumably something like that
10:31 jnthn lizmat: Probably because `will build` was in the design docs, and it was preferable to have all those things go through one codepath, so folks could override the trait if they had reason to
10:31 lizmat ok
10:31 jnthn Though it's been that way for so many years, I honestly don't remember exactly the thinking :)
10:32 lizmat also: I see a "WANTED" in the attr init code, whereas at least atm, the method is only called internally
10:32 lizmat not sure about the runtime ramifications of WANTED
10:33 jnthn Isn't WANTED just a compile-time tracking annotation?
10:33 lizmat yeah, probably is...
10:33 jnthn So no impact
10:33 lizmat still, how would that work with a method ?
10:33 jnthn It's just saying the return value is wanted
10:33 jnthn Which they always are
10:34 jnthn At a guess, anyway
10:34 lizmat ok, so it's more a comment than anything else.  :-)
10:37 jnthn Hmm, the spesh worker thread gets a spesh log allocated, which is a bit pointless 'cus it never runs any user code
10:38 lizmat jnthn: looking at https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Actions.nqp#L9165
10:38 lizmat isn't line 9168 then superfluous ?
10:39 lizmat as it's already marked scope<lexical> in 9165 ?
10:39 lizmat also: why lexical, why not local ?
10:40 jnthn That is a bit odd
10:40 jnthn Because an attribute initializer may have nested blocks
10:40 jnthn has $.foo = do { ... }
10:40 jnthn Could try removing line 9168
10:40 lizmat ok, will do
10:46 evalable6 joined #moarvm
10:49 Geth ¦ MoarVM: 2553a0e5a6 | (Jonathan Worthington)++ | src/core/threads.c
10:49 Geth ¦ MoarVM: Don't give internal workers a spesh log
10:49 Geth ¦ MoarVM:
10:49 Geth ¦ MoarVM: Saves a tiny bit of work, and avoids an allocation, although it will
10:49 Geth ¦ MoarVM: barely register as an actual saving thanks to OS cleverness around
10:49 Geth ¦ MoarVM: memory that is allocated but then never touched.
10:49 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2553a0e5a6
10:50 jnthn oops
10:50 jnthn oh, phew
10:50 jnthn Thought I'd gone and committed debug output. Just hadn't done a make install again after deleting it :)
10:56 lizmat jnthn: fwiw, I'm seeing flappers in make spectest that I haven't seen flapping before
10:56 lizmat so I suspect we still have some gremlins in the new spesh/JIT code
10:57 jnthn That or the scheduler rewrite, or the complete re-working of supply concurrency management :P
10:57 jnthn There's also the occasional SEGV that shows up in CORE.setting compile
10:57 jnthn The paste with the backtrace on it expired, alas
10:57 lizmat example: dieing in test 4 of integration/advent2011-day10.t
10:59 jnthn Seems fine here
10:59 lizmat yeah... not reproducible
10:59 lizmat which was my point  :-)
11:01 nwc10 oooh, I just got
11:01 nwc10 moar: src/6model/sc.c:383: MVM_SC_WB_OBJ: Assertion `!(obj->header.flags & MVM_CF_FORWARDER_VALID)' failed.
11:02 nwc10 I think from target perl6-gdb-m
11:02 nwc10 sadly can't reproduce
11:11 timotimo jnthn: should there be any consideration for nursery size reductions from strings and such when the nursery could still grow in size?
11:13 jnthn Think I'd prefer those two not to interact
11:17 domidumont joined #moarvm
11:20 jnthn GC stressed CORE.setting build set off while I go for lunch
11:20 jnthn bbiab
11:21 dogbert17 jnthn: btw, t/spec/S17-promise/lock-async.t takes 1m40s on my 4 core $work machine. Do you want me to RT yesterdays findings wrt worker threads
11:21 lizmat jnthn: fwiw, I cannot find a reference to "will build" in the specs, only that the Attribute object has a "build" method
11:22 lizmat abbiab
11:59 domidumont1 joined #moarvm
12:03 jnthn Dammit, it did trip a GC fromspace access assert but I was apparently so hungry I forgot to set a breakpoint on MVM_panic
12:04 nwc10 bother
12:04 nwc10 do it again while ilmari goes to lunch...
12:04 timotimo get used to using rr, perhaps :)
12:04 jnthn ah, it hits pretty early on
12:07 ZofBot joined #moarvm
12:07 jnthn haha
12:07 jnthn When I wrote this code...
12:07 jnthn ParameterizeReturnData *prd = (ParameterizeReturnData *)sr_data;
12:08 jnthn I hadn't yet learned that "prd" is Czech for "fart" :D
12:09 jnthn Think I found the problem, anyways
12:09 nwc10 with a rolled R? seems quite
12:09 nwc10 alliterative
12:09 nwc10 no, that wasn't the word I meant
12:10 nwc10 I slack. I'll go back to "breaking things"
12:10 jnthn Yeah :)
12:10 jnthn I think onomatopoeia is the one :)
12:10 nwc10 that was the one
12:11 jnthn Seems it's surviving longer, anyways
12:11 jnthn ah, it means I fix https://github.com/MoarVM/MoarVM/issues/707 also
12:13 [Coke] (broke the windows build) worked fine here (failed about as many spectests as windows has been)
12:13 jnthn Yeah, got through the build. Nice :)
12:14 jnthn Wowser, make test ain't happy under GC stress
12:35 domidumont joined #moarvm
12:43 domidumont1 joined #moarvm
12:49 jnthn spectest neither for that matter
13:04 Geth ¦ MoarVM: 99bc69a2f4 | (Jonathan Worthington)++ | src/6model/parametric.c
13:04 Geth ¦ MoarVM: Missing MVMROOTs in type parameterization handling
13:04 Geth ¦ MoarVM:
13:04 Geth ¦ MoarVM: The callback data in `prd` is no longer being marked by this point, so
13:04 Geth ¦ MoarVM: need to grab it and root it before using it. Fixes #707, and together
13:04 Geth ¦ MoarVM: with it the occasional crash while building CORE.setting.
13:04 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/99bc69a2f4
13:07 hoelzro joined #moarvm
13:16 Geth ¦ MoarVM: 716f6fcfaf | (Jonathan Worthington)++ | 2 files
13:16 Geth ¦ MoarVM: Missing rooting/barriering in C[PP]Struct
13:16 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/716f6fcfaf
13:25 weabot joined #moarvm
13:30 cog_ joined #moarvm
13:35 Geth ¦ MoarVM: 953c38423c | (Jonathan Worthington)++ | src/core/frame.c
13:35 Geth ¦ MoarVM: Set frame->static_info in allocate_frame
13:35 Geth ¦ MoarVM:
13:35 Geth ¦ MoarVM: So it's there right from the start. If the spesh log entry fills up
13:35 Geth ¦ MoarVM: the log and causes it to be sent, then we might have a frame with no
13:35 Geth ¦ MoarVM: static_info on the temp roots stack. This can cause a NULL pointer
13:35 Geth ¦ MoarVM: dereference inside the GC. We could NULL-guard it there, but it's
13:35 Geth ¦ MoarVM: less work to just make sure that situation can never happen.
13:35 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/953c38423c
13:35 Geth ¦ MoarVM: be8e7dfa0c | (Jonathan Worthington)++ | src/gc/worklist.h
13:35 Geth ¦ MoarVM: Catch frame worklist adds with NULL static_info
13:35 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/be8e7dfa0c
13:41 * dogbert17 sees cool bugfixes, jnthn++
13:45 zakharyas joined #moarvm
13:45 jnthn Hunting another one. Somehow, a frame ends up with an outdated ->outer into fromspace
13:46 dogbert17 is it a MoarVM issue?
13:46 timotimo well, probably
13:46 jnthn Yeah, surely
13:46 timotimo you can't really modify that stuff from nqp or rakudo
13:46 jnthn Oh, unless you mean "is it a MoarVM GitHub Issue"
13:46 jnthn In which case, no
13:47 dogbert17 aha, interesting
13:47 dogbert17 yeah, GitHub issue is what I was after :)
14:00 dogbert17 is it the MVM_gc_root_add_frame_roots_to_worklist panic you're hunting? https://gist.github.com/dogbert17/f8cb997404699925730b76da44ef40da
14:01 jnthn I've probably got a fix for that one locally :)
14:02 dogbert17 impressive
14:05 Geth ¦ MoarVM: 856a9a6f93 | (Jonathan Worthington)++ | src/core/frame.c
14:05 Geth ¦ MoarVM: Missing MVMROOT of outer/code_ref
14:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/856a9a6f93
14:05 Geth ¦ MoarVM: 0374f7383a | (Jonathan Worthington)++ | src/core/frame.c
14:05 Geth ¦ MoarVM: Set frame->caller up earlier
14:05 Geth ¦ MoarVM:
14:05 Geth ¦ MoarVM: The GC could see the frame and the old value, which might have been
14:05 Geth ¦ MoarVM: junk, in some cases. We could NULL it so that didn't happen, but
14:05 Geth ¦ MoarVM: instead just set it earlier before GC can ever be triggered.
14:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0374f7383a
14:26 jnthn Enough GC bug hunting for today, methinks
14:27 jnthn That should at least make things a little better, though :)
14:27 dogbert17 indeed it will, jnthn++
14:29 jnthn Seems there's still some more hunting to do another day, though
14:33 dogbert17 so you've seen more problems?
14:37 jnthn Yeah
14:37 dogbert17 gah :)
14:38 timotimo i wish there was some kind of static analysis we could teach how to find these problems
14:38 timotimo the missing root problems, that is
14:44 timotimo it seems like the clang static analyzer is built to be extended
14:58 dogbert17 jnthn: have you only made changes in MoarVM today?
15:00 timotimo i see no others
15:01 jnthn dogbert17: Yeah
15:02 dogbert17 then I've probably messed up my rakudo install :)
15:09 brrt joined #moarvm
15:09 brrt ohai
15:09 yoleaux 4 Oct 2017 23:46Z <samcv> brrt: i think your even_moar_jit branch merge broke the windows build
15:09 yoleaux 00:24Z <AlexDaniel> brrt: fwiw a ticket for that: https://github.com/MoarVM/MoarVM/issues/718
15:09 samcv oh hi brrt :-)
15:10 brrt i'll take a quick look
15:10 samcv my guess it's it's putting in a path with '\'
15:10 brrt i'm basically in the process of moving
15:10 timotimo moving house?
15:10 samcv so it's getting unknown escape sequences. but i'm not sure how that info arrives in that file
15:11 samcv but it only is an issue on windows and it tries to interpret it as an escappe sequence. it was my belief that in C files '/' are used?
15:11 jnthn samcv: Are you sure that's what the error is about?
15:12 jnthn I thought that was just a warning
15:12 jnthn And the error was something else after it?
15:12 jnthn Maybe I misread the output though
15:13 dogbert17 there must have been changes in how MVM_GC_DEBUG works
15:14 dogbert17 if I turn it on I get fromspace panics immediately
15:15 Geth ¦ MoarVM: f97ce7a855 | (Bart Wiegmans)++ | 2 files
15:15 Geth ¦ MoarVM: Fix definition of MIN
15:15 Geth ¦ MoarVM:
15:15 Geth ¦ MoarVM: Had a semicolon (';'), which it really shouldn't. Probably fixes
15:15 Geth ¦ MoarVM: appveyor issue
15:15 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f97ce7a855
15:15 brrt anyway, moving house, yes, so afk
15:15 timotimo viel erfolg!
15:15 brrt thx
15:16 dogbert17 bizarre
15:28 zakharyas joined #moarvm
15:36 Geth ¦ MoarVM: 4092ccebca | (Jonathan Worthington)++ | 3 files
15:36 Geth ¦ MoarVM: Avoid a thread yield loop in mark_thread_ubnlocked
15:36 Geth ¦ MoarVM:
15:36 Geth ¦ MoarVM: Instead, use a condition variable, that is set when GC terminates.
15:36 Geth ¦ MoarVM: This saves a bunch of wasted scheduling work in various workloads. For
15:36 Geth ¦ MoarVM: example, `perf` used to show `sched_yield` accounting for a few percent
15:36 Geth ¦ MoarVM: in a web server benchmark; now it doesn't even appear in the report.
15:36 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4092ccebca
15:43 * japhb imagines that 'ubnlock' is something orcs do
15:44 japhb Nice win, BTW
15:44 japhb Very happy that Cro is yielding so many benefits for Rakudo and MoarVM.
15:45 jnthn Yeah, it was very helpful to have a fairly large, heavily-supply-using codebase when refactoring supply internals recently
15:45 japhb Time to bump nqp/rakudo to latest moarvm, or did you still need to chase down more bugs?
15:45 japhb I bet!
15:46 japhb jnthn: As I
15:46 japhb (FEK)
15:47 japhb As I'm starting to design the API for my widget lib, I'm thinking about every widget/subwidget having an input event supply, and bubbling of events happens through widgets emitting to other widget's supplies.
15:48 japhb This means a lot of event objects wisking between various supplies every time any input happens anywhere.  How likely is it that having O(100) supplies active at once will be a problem at this point?
15:49 jnthn Unlikely
15:49 japhb The other possible design is something like IRC::Client using .? method dispatch and a master dispatcher, if the supply route would have scaling problems.
15:49 japhb Ah good.
15:49 jnthn I mean, I'm running Cro load tests with -c 100 in ab
15:49 jnthn So 100 concurrent requests
15:50 japhb OK, that's encouraging
15:50 jnthn And ab doesn't know how to do HTTP/1.1 (gah!) and Cro doesn't know how to do the old HTTP/1.0 keepalive
15:50 jnthn So it's 100 connectinos, and every one has a Supply dangling off it
15:50 japhb How in the world does ab not do 1.1?!
15:51 jnthn :)
15:51 jnthn Yeah, that was my thought too :P
15:52 * japhb wonders how much code still exists in the wild that knows 1.0 keepalive and *doesn't* know 1.1 and/or 2.0
15:52 timotimo i don't know 1.0 keepalive, bu ti'm not code
15:53 japhb .oO( Apache: We lots of leading edge projects ... but that httpd thing we started with?  Not much love there anymore ....)
15:53 japhb *We fund
15:54 timotimo well, apache can't scale because it was made before async was discovered
15:55 jnthn m: my $s = supply { whenever Supply.interval(0.1) { emit 1; done } }; my $i = 0; react { for ^500 { whenever $s { $i++ } } }; say $i
15:55 camelia rakudo-moar b33c2d: OUTPUT: «500␤»
15:55 jnthn There's 500 active :)
15:56 timotimo MoarVM panic: Collectable 0x7fd494085750 in fromspace accessed - even in this supply example just now :(  (but with a small nursery)
15:58 Zoffix m: my $s = supply { whenever Supply.interval(0.1) { emit 1; done } }; my $i = 0; react { for ^50000 { whenever $s { $i++ } } }; say $i
15:58 camelia rakudo-moar b33c2d: OUTPUT: «(timeout)»
15:58 Zoffix m: my $s = supply { whenever Supply.interval(0.1) { emit 1; done } }; my $i = 0; react { for ^5000 { whenever $s { $i++ } } }; say $i
15:59 camelia rakudo-moar b33c2d: OUTPUT: «(timeout)»
16:00 Geth ¦ MoarVM: 64b62ab6cd | (Jonathan Worthington)++ | 4 files
16:00 Geth ¦ MoarVM: Basic JIT of lock/unlock
16:00 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/64b62ab6cd
16:01 lizmat joined #moarvm
16:12 AlexDaniel_ joined #moarvm
16:18 robertle joined #moarvm
16:25 jnthn Got curious why that example above tanks once it gets much over 1000
16:25 jnthn Turns out huge amounts of time go on GC. Odd
16:25 jnthn But, time to head home now
16:25 timotimo hmm, deep recursive stacks?
16:26 jnthn timotimo: Only if continuations are accidentally creating frames they shouldn't
16:26 jnthn I think maybe it's that we have tons of frames alive in continuations
16:27 timotimo the heap snapshot tracker ought to be able to show this?
16:41 leont_ joined #moarvm
16:43 squashable6 joined #moarvm
16:45 timo joined #moarvm
16:47 timo1 joined #moarvm
16:51 squashable6 joined #moarvm
16:57 lizmat joined #moarvm
16:58 timotimo huh, i grabbed the latest moar commits and get segfaults rather quickly now
16:59 timotimo wow, wat. tc->instance->VMString is a null pointer? how'd this happen?
17:01 samcv jnthn, maybe i misread it but i thought that was the error
17:01 Zoffix oh heh :)
17:01 * Zoffix changes mind about doing bumps :)
17:02 samcv it's already been bumped though
17:02 samcv i mean. the appveyor build of rakudo is failing as well
17:02 timotimo oh, i bet it's because i didn't recompile rakudo
17:02 Zoffix Don't see any bumps in the last day or so
17:02 samcv jnthn, oh it does says it is a warning. and then an error later on
17:03 samcv https://ci.appveyor.com/project/rakudo/rakudo/build/job/48fqvjnm2r93c0at well it's failing for the same reason our builds are
17:03 samcv been failing for at least a day
17:03 samcv not sure how long. i only noticed it yesterday
17:03 lizmat joined #moarvm
17:05 timotimo yup, my problem was from missing some changes for rakudo's extops
17:05 Zoffix ah, cool
17:12 domidumont joined #moarvm
17:14 squashable6 joined #moarvm
17:14 Ven`` joined #moarvm
17:15 samcv gonna go through some rt's
17:15 samcv maybe fix a java one
17:23 Zoffix m: use Test:HahaYouMissedAColonBruh
17:23 camelia rakudo-moar c73221: ( no output )
17:39 samcv hah
17:45 [Coke] m: use 3
17:45 camelia rakudo-moar c73221: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤    use used at line 1␤␤»
17:45 [Coke] O_o
17:49 Zoffix 3 is not a valid identifier or version literal :)
17:49 Zoffix But it'll likely get improved as part of SQUASHathon :)
17:56 timotimo m: sub use(Int $foo) { say "lol" }; use 3
17:56 camelia rakudo-moar 6c928d: OUTPUT: «lol␤»
18:03 zakharyas joined #moarvm
18:22 [Coke] m: need 3
18:22 camelia rakudo-moar 6c928d: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤    need used at line 1␤␤»
18:23 Zoffix It's on this ticket: https://rt.perl.org/Ticket/Display.html?id=132214#ticket-history
18:24 Zoffix Wait, no on this: RT#126669
18:24 synopsebot RT#126669 [open]: https://rt.perl.org/Ticket/Display.html?id=126669 [LHF][LTA] error with "need 6"/"use 6" (no "v")
18:24 Zoffix Both are marked LHF for new SQUASHathon participants
18:28 [Coke] Guess I should not be surprised I'm not finding new issues. :)
18:42 samcv LHF?
18:44 timotimo "low-hanging fruit"
18:49 Zoffix as in easy stuff to do
18:52 zakharyas joined #moarvm
19:50 Zoffix .tell jnthn tried bumping nqp/MoarVM versions, but stresstest hangs. S32-io/lock.t  S32-num/power.t appear to hang entirely and MVM_SPESH_DISABLE and MVM_JIT_DISABLE don't help. S17-channel/stress.t appears to take about 300s to run. The same issues don't exist without the bump and the entire stresstest run comples in ~150s. This is on 24-core box
19:50 yoleaux Zoffix: I'll pass your message to jnthn.
19:51 * Zoffix relocates
19:56 zakharyas joined #moarvm
20:08 MasterDuke seeing the same thing with S32-io/lock.t and S32-num/power.t
20:18 brrt joined #moarvm
20:35 MasterDuke .ask jnthn does my comment in https://github.com/MoarVM/MoarVM/pull/689 about the MVM_CF_USES_FSA flag make sense?
20:35 yoleaux MasterDuke: I'll pass your message to jnthn.
21:40 jnthn .
21:40 yoleaux 19:50Z <Zoffix> jnthn: tried bumping nqp/MoarVM versions, but stresstest hangs. S32-io/lock.t  S32-num/power.t appear to hang entirely and MVM_SPESH_DISABLE and MVM_JIT_DISABLE don't help. S17-channel/stress.t appears to take about 300s to run. The same issues don't exist without the bump and the entire stresstest run comples in ~150s. This is on 24-core box
21:40 yoleaux 20:35Z <MasterDuke> jnthn: does my comment in https://github.com/MoarVM/MoarVM/pull/689 about the MVM_CF_USES_FSA flag make sense?
21:41 jnthn MasterDuke:
21:41 jnthn MasterDuke:
21:41 jnthn crap1
21:41 jnthn MasterDuke: #define it in MVMString.c also
21:41 jnthn Ah, I'll note it on the ticket
21:41 jnthn grr, too used to office keyboard :P
21:42 MasterDuke heh
21:43 Zoffix That's why I use the same keyboards at home and office :)
21:43 timotimo is it a good keyboard?
21:45 jnthn No :P
21:47 jnthn Zoffix: If you or anyone has chance to work out which commit did it, that'd be handy. I've got family visiting, so am liable not to have time to dig into it until early next week.
21:47 jnthn otoh, we don't have to bump :)
21:48 Zoffix Doesn't sound like a fun exercerse :) Maybe AlexDaniel has the moarvm bisector ready
21:53 jnthn :)
21:53 jnthn I may find a moment tomorrow for it, we'll see :)
21:53 jnthn Though it's potentially not an easy fix :S
21:54 jnthn Given I can't think of anything that went in that could be to blame
21:54 MasterDuke https://github.com/MoarVM/MoarVM/commit/64b62ab6cd somehow?
21:55 jnthn But it was still there with JIT disabled?
21:55 MasterDuke ah, right
21:55 jnthn Also S32-io/lock.t is file locking
21:55 jnthn Not mutex locking
21:56 jnthn But I don't see anything I/O-ish
21:58 MasterDuke the moar process just seems to be sitting in a futex call according to strace
21:58 MasterDuke futex(0x563f575746b0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, 0xffffffff
21:58 Zoffix It does have tests that fire off a promise. Remember when we were adding the close-on-exit feature and some tests in lock.t were hanging because there was a lock waiting on a handle and another thread waiting to close the handle or something
21:58 MasterDuke futex(0x5613933163e0, FUTEX_WAIT_PRIVATE, 0, NULL
21:59 MasterDuke the first is the t/spec/S32-io/lock.t process, the second is the getout-22215-992720.code process
22:16 AlexDaniel_ trisectable is not ready yet, and once it's ready… it'll take a week or two to prebuild stuff
22:20 timotimo whoa
22:44 rba joined #moarvm
23:20 lizmat joined #moarvm
23:25 samcv sounds awesome AlexDaniel_
23:25 AlexDaniel_ yeah, it sounds awesome! Just does not sound ready yet :)
23:26 AlexDaniel_ I'll work on it tonight

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