Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-05

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

All times shown according to UTC.

Time Nick Message
00:45 evalable6 joined #moarvm
01:45 Geth ¦ MoarVM: ad86184681 | (Timo Paulssen)++ | src/core/fixedsizealloc.c
01:45 Geth ¦ MoarVM: fix pointer arithmetic with a cast
01:45 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ad86184681
01:45 timotimo that's the one nwc10 found
01:56 TimToady joined #moarvm
02:22 evalable6 joined #moarvm
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:42 hoelzro joined #moarvm
04:58 samcv timotimo, what are your thoughts on having rakudo default to not utf8 but format detection for slurping and opening file handles
08:17 nine samcv: doesn't sound like a good strategy for the 100 year language ;)
08:30 nine t/spec/S04-exceptions/fail.t fails on masteer with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1
08:33 robertle joined #moarvm
08:37 nine t/spec/S32-str/encode.rakudo.moar sometimes fails on master with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 especially when under load. Dies (probably segfaults) right after ok 31 - Can encode noncharacters to UTF-8
08:39 nine t/spec/S32-exceptions/misc.rakudo.moar fails on master with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1
08:42 nine t/spec/S06-signature/slurpy-params.t sometimes fails on master with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 especially when under load.
08:43 nine Oh, Test::Util::doesn't-hang has a timeout of only 1.5 seconds. No wonder those tests like to fail under heavy load.
08:44 nine Zoffix: ^^^
09:07 nine t/spec/S32-str/CollationTest_NON_IGNORABLE-3.t also sometimes fails on master with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1. Maybe related to the S32-str/encode.t failure. Dies right after "ok 1046 -  ('U+FFF0') n+ll Line 197597 <=>  ('U+FFF0') n+ll Line 197598"
09:07 nine samcv: ^^^
09:08 samcv nine, ah ok. so i should run those tests until they fail and diagnose right
09:08 samcv i haven't seen them failing. what OS are you on and compiler
09:09 nine samcv: that would be nice, yes :) I'm on openSUSE Tumbleweed with gcc (SUSE Linux) 7.2.1 20170901 [gcc-7-branch revision 251580]
09:09 nine CollationTest_NON_IGNORABLE-3.t took really long to reproduce on master. I almost gave up and attributed the fail to the inline_in_place branch where it happened sooner.
09:19 Geth ¦ MoarVM/inline_in_place: 92dce2b51c | (Timo Paulssen)++ (committed by Stefan Seifert) | 4 files
09:19 Geth ¦ MoarVM/inline_in_place: Put inlined blocks between their caller and its succ
09:19 Geth ¦ MoarVM/inline_in_place:
09:19 Geth ¦ MoarVM/inline_in_place: Previously inlined callees were added to the end of the basic block list.
09:19 Geth ¦ MoarVM/inline_in_place: We now put the inlined blocks into the list at the position of the invoke op.
09:19 Geth ¦ MoarVM/inline_in_place: However we cannot yet get rid of the goto ops entering and exiting the inlined
09:19 Geth ¦ MoarVM/inline_in_place: code as that would lead to odd bugs possibly related to the annotations on
09:19 Geth ¦ MoarVM/inline_in_place: these ops.
09:19 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/92dce2b51c
09:20 nine As it stands, this ^^^ could actually go into master. Apparently it works well but Some review may still be a good idea :)
09:39 samcv i gotta go to bed. will look at that tomorrow nine o/
09:41 nine Good night :)
10:07 evalable6 joined #moarvm
10:28 evalable6 joined #moarvm
10:40 domidumont joined #moarvm
10:45 domidumont joined #moarvm
11:39 stmuk joined #moarvm
12:50 evalable6 joined #moarvm
13:23 Zoffix nine: 1.5s is plenty during normal stresstest runs. If that's insufficient because you're setting some non-standard options then set ROAST_TIMING_SCALE env var to a larger value (default is 1)
13:34 Zoffix I guess it don't matter now since the normal test behaviour is meant to not hang.
13:35 buggable joined #moarvm
13:36 buggable joined #moarvm
15:20 committable6 joined #moarvm
15:57 nine Zoffix: but why pick a rather low value in the first place? Once a hanging bug is fixed (which it usually is when tests go into roast), it's unlikely that it will appear again. And even if, if the worst case is a 10 second penalty for a test file, few people will even notice.
15:58 Zoffix nine: 'cause that routine was created when a bunch of fudges for unfixed bugs were added and slowing down the entire run by dozens of seconds was unwanted.
15:59 Zoffix Actually, they're still fudged for JVM I think, though perhaps with a `skip` fudge
15:59 colomon joined #moarvm
16:02 nine Zoffix: I see your reasoning. I'm just a little sad that I lost so much time chasing trivialities and didn't have a chance to get some actual developing done.
16:04 nine Of course those really hard to reproduce flappers that are also in master cost much more than the timeouts
17:08 colomon joined #moarvm
17:32 stmuk_ joined #moarvm
18:12 dogbert17 jnthn: is this familiar? https://gist.github.com/dogbert17/bd6dbcda7119ee23dedc89b54eab3da8
18:12 timotimo yeah that's when fixing up wvals doesn't abort when an object needs to be deserialized
18:12 timotimo didn't i commit something for that purpose?
18:13 dogbert17 perhaps it's still in a branch?
18:15 timotimo "refuse_dangerous_inlines"
18:17 dogbert17 perhaps it should be merged?
18:28 timotimo i'd be happier if there were some better way to handle this
18:28 timotimo nonblocking spesh will cause a bunch of things to not be inlined ever
18:28 timotimo well, it's better than crashing
18:29 timotimo we could turn the wval into a guaranteed failing guard that causes an uninline
18:30 nine Maybe just block GC during deserialization of that wval?
18:41 timotimo that's not how that works :)
18:41 timotimo where would you allocate that object to?
18:42 timotimo the problem arises because we're not allowing GC inside spesh, but wval deserialization can trigger it
18:43 jnthn I think the problem is actually because it needs to require a mutex, and to do that without risk of deadlocking the VM it has to have a GC safepoint
18:43 jnthn Which might enter the GC
18:55 timotimo oh, huh!
19:07 colomon_ joined #moarvm
19:20 dogbert17 almost sounds like a catch 22 situation
19:32 evalable6 joined #moarvm
19:57 leedo__ joined #moarvm
20:02 hoelzro_ joined #moarvm
20:02 [Coke]_ joined #moarvm
20:11 evalable6_ joined #moarvm
20:11 nativecallable6_ joined #moarvm
20:11 bloatable6_ joined #moarvm
20:11 committable6_ joined #moarvm
20:15 lizmat jnthn  timotimo: is it a known issue that you cannot precompile something like "class A { constant %h = a => { "foo" }; say %h<a>() }" ?
20:15 lizmat ===SORRY!===
20:15 lizmat No lexical found with name '$_'
20:15 lizmat nine also perhaps ??  ^^
20:24 jnthn lizmat: Didn't know that particular issue, no
20:24 lizmat so worthwhile of a ticket ?
20:24 lizmat works fine if you s/constant/my/
20:25 jnthn What about my constant ?
20:25 lizmat same
20:25 jnthn And yeah, ticketable for sure
20:25 lizmat ack, rakudo or moar ?  feels like a precomp issue, and therefore more moary than rakudoy ?
20:30 jnthn All levels of the stack are involved
20:30 jnthn At least as many end up needing fixes at Rakudo level
20:31 benchable6 joined #moarvm
20:31 bisectable6 joined #moarvm
20:31 jnthn So I'd file it there so long as we ain't sure
20:31 quotable6 joined #moarvm
20:31 coverable6 joined #moarvm
20:31 releasable6 joined #moarvm
20:31 unicodable6 joined #moarvm
20:31 statisfiable6 joined #moarvm
20:42 lizmat ack
20:45 lizmat afk for a bit
21:50 SmokeMachine joined #moarvm
21:51 ugexe joined #moarvm
21:53 benchable6 joined #moarvm
21:53 statisfiable6 joined #moarvm
21:53 unicodable6 joined #moarvm
21:53 bisectable6 joined #moarvm
21:53 releasable6 joined #moarvm
22:11 evalable6 joined #moarvm
22:11 nativecallable6 joined #moarvm
22:11 bloatable6 joined #moarvm
22:28 ilmari[m] joined #moarvm
22:40 samcv nine, running S32-str/encode.t in a loop right now until i get a segfault
22:40 samcv maybe should rebuild with gcc instead hm and not clang
22:52 * jnthn at long last got one of the blog posts in this backlog written... https://6guts.wordpress.com/2017/11/05/moarvm-specializer-improvements-part-3-optimizing-code/
22:52 jnthn *in his
22:53 japhb \o/ jnthn blag!
22:54 * jnthn will only sign up for an advent slot if he first manages to get through his backlog...
22:55 samcv can't get that thing to segfault even running on a loop for half an hour
22:57 lizmat jnthn++  # too tired to read now, but will do so tomorrow
22:57 AlexDaniel` joined #moarvm
22:58 MasterDuke heh, i've been ./t/spec/S11-modules/nested.t in a loop for about 30min now also, with spectests running in the background, but nothing is failing
23:00 jnthn lizmat: And in good time for the weekly :)
23:00 lizmat indeed  :-)
23:00 jnthn lizmat: My other perhaps weekly-worthy Perl 6 work this week was getting Cro 0.7.1 out :)
23:01 lizmat jnthn: noted  :-)
23:01 lizmat anything special about that release ?
23:01 MasterDuke jnthn: btw, i don't remember if i asked this before and you answered, but what would cause interpolating a variable into a regex to have its 2nd-most expensive by exclusive time routine be Match.Bool's proto?
23:02 MasterDuke or, what extra logging should i use to diagnose myself?
23:03 jnthn lizmat: https://github.com/croservices/cro/blob/master/docs/releases.md#071 are the release notes; probably the biggest things are `cro web` now starts a web interface for stubbing/running/tracing/viewing logs from services in development, the router has include/delegate support for composing routes, and we fixed loads of issues, especially in HTTP/2.0 support.
23:03 lizmat jnthn: even more noted  :-)
23:04 jnthn I'm not sure if http://cro.services/docs/intro/spa-with-cro ever made the weekly either
23:04 jnthn Tutorial on doing a react/redux single page app with a Cro backend
23:23 evalable6 joined #moarvm
23:26 lizmat jnthn: no, it is new to me..  :-)

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