Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-06

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

All times shown according to UTC.

Time Nick Message
00:13 Ven`` joined #moarvm
00:42 Geth ¦ MoarVM: e9d331d40b | (Samantha McVey)++ | src/strings/unicode_ops.c
00:42 Geth ¦ MoarVM: Fix quaternary collation level's. Fixes RT#132216
00:42 Geth ¦ MoarVM:
00:42 Geth ¦ MoarVM: Previously quaternary collation levels were only checked
00:42 Geth ¦ MoarVM: for checking ties via string length. Now it also applies
00:42 Geth ¦ MoarVM: changes in quaternary level for codepoint.
00:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e9d331d40b
00:42 synopsebot RT#132216 [new]: https://rt.perl.org/Ticket/Display.html?id=132216 [UNI] 'a' coll 'A" not Same but More with disabled tertiary and primary levels
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
02:06 timotimo joined #moarvm
02:08 unicodable6 joined #moarvm
02:08 nativecallable6 joined #moarvm
02:08 quotable6 joined #moarvm
02:08 statisfiable6 joined #moarvm
02:08 squashable6 joined #moarvm
02:11 ilmari_ joined #moarvm
02:25 releasable6 joined #moarvm
02:32 nativecallable6 joined #moarvm
02:32 quotable6 joined #moarvm
02:32 unicodable6 joined #moarvm
02:32 squashable6 joined #moarvm
02:32 statisfiable6 joined #moarvm
02:33 japhb_ joined #moarvm
02:39 releasable6 joined #moarvm
02:39 nativecallable6 joined #moarvm
02:39 squashable6 joined #moarvm
02:39 quotable6 joined #moarvm
02:39 statisfiable6 joined #moarvm
02:40 leedo_ joined #moarvm
05:25 evalable6 joined #moarvm
05:39 domidumont joined #moarvm
06:04 bloatable6 joined #moarvm
06:04 committable6 joined #moarvm
06:04 quotable6 joined #moarvm
06:04 nativecallable6 joined #moarvm
06:04 unicodable6 joined #moarvm
06:04 greppable6 joined #moarvm
06:04 coverable6 joined #moarvm
06:04 evalable6 joined #moarvm
06:04 bisectable6 joined #moarvm
06:04 benchable6 joined #moarvm
06:04 releasable6 joined #moarvm
06:04 squashable6 joined #moarvm
06:04 statisfiable6 joined #moarvm
06:12 domidumont joined #moarvm
06:14 domidumont joined #moarvm
06:47 nwc10 Stage parse      : moar: src/6model/sc.c:383: MVM_SC_WB_OBJ: Assertion `!(obj->header.flags & MVM_CF_FORWARDER_VALID)' failed.
06:47 nwc10 make: *** [perl6-valgrind-m] Aborted
06:47 nwc10 different one this time
06:48 nwc10 can't reliable reproduce
06:48 nwc10 (was ...-gdb last time IIRC)
07:31 leont_ joined #moarvm
08:36 rba joined #moarvm
08:37 rba hi all. I'm currently try to build radkudo star 2017.07 on Solaris 10. Struggeling with different things. E.g. memmem
08:37 rba I will get the latest MoarVM from github and hav a look at this one...
08:50 Zoffix Sweet
08:51 * moritz amazed that people still use solaris
08:51 Zoffix :)
08:52 moritz especially after Oracle fired nearly all engineers and management working on solaris: http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/
08:52 Zoffix Yeah, I heard. I think rba said there were lots of banks in $location still using it or something.
08:53 moritz I'm sure there's money in maintaining solaris for the next 15 or more years
09:17 cog__ joined #moarvm
09:30 squashable6 joined #moarvm
09:36 Geth ¦ MoarVM: 54216e5542 | (Samantha McVey)++ | src/strings/unicode_ops.c
09:36 Geth ¦ MoarVM: collation: simplify quaternary and use define's for the bitmask
09:36 Geth ¦ MoarVM:
09:36 Geth ¦ MoarVM: Use define's to make setmodeup more clear. Simplify the quaternary
09:36 Geth ¦ MoarVM: return function collation_return_by_length() and change it to
09:36 Geth ¦ MoarVM: be called collation_return_by_quaternary().
09:36 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/54216e5542
09:36 samcv were there issues or can i bump now or not?
09:36 samcv i remember reading there were certain issues
09:37 Zoffix No, don't bump
09:37 Zoffix There are still issues, AFAIK
09:37 Zoffix Yeah, don't see any commits fixing them
09:37 samcv ok
09:37 samcv ok there will be a failing test or two in S32-str/Collation.t then
09:38 samcv since i just added that file
09:38 Zoffix ok :)
09:41 timo joined #moarvm
09:42 dogbert17 samcv: didn't you fix https://github.com/MoarVM/MoarVM/issues/664 ?
09:43 samcv yep
09:43 samcv i fixed many things :P
09:43 samcv and haven't gotten around to closing all the issues
09:44 samcv will close that one now
09:47 rba_ joined #moarvm
09:50 samcv i gotta go to bed guys. see you tomorrow o/
09:50 rba_ Still have time to get it running in Solaris as Oracle meant to delivery support till 2034... ;-)
09:53 Guest65627 rba: if memmem is a problem, you can just try the #define that enables our copy-pasted implementation
09:58 dogbert17 nite samcv
10:07 rba timotimo: I changed src/platform/memmem.h: #if defined(_WIN32) || defined(__APPLE__) || defined(__Darwin__) || defined(__sun)
10:07 rba timotimo: yet, I have then errors on nqp tests
10:08 timotimo good
10:08 timotimo can you paste the errors somewhere?
10:09 rba timotimo: shure, give me a sec...
10:16 rba timotimo: nqp test output: https://gist.github.com/rba/6925e11391a4e50024107c6b2444165e
10:17 timotimo OK, can you also ./nqp-m t/nqp/059-nqpop.t  and also  ./nqp-m t/nqp/104-method-cache.t  so we get the full output from the tests?
10:18 rba timotimo: and more worse rakudo segfaulted: https://gist.github.com/rba/8369cfa00dc3e92f2cb2bfa1e09905c4
10:19 timotimo stage parse could also die because of too little ram; how much free ram and swap do you have?
10:19 rba timotimo: https://gist.github.com/rba/9c771b7341fc908d52cda9f5f940119e
10:20 rba timotimo: https://gist.github.com/rba/dda378519609f2703344b0d7d621b54d
10:21 timotimo OK, let's look at the pow_n one first
10:23 timotimo hold on, what versions are you running?
10:24 timotimo there's more tests there in my version than in your output
10:24 rba rakudo-star.2017.07
10:24 timotimo OK, that's probably just fine
10:25 rba timotimo: I have started with rakudo-star. I reached the segfault and then I get the latest MoarVM from github.
10:25 timotimo can you run: nqp-m -e 'say(nqp::pow_n(1,nqp::inf)'?
10:25 timotimo oh sorry
10:25 timotimo nqp-m -e 'say(nqp::pow_n(1,nqp::inf))
10:25 timotimo damn it
10:25 rba timotimo: all the above is now from rakudo star again
10:26 rba ./nqp-m -e 'say(nqp::pow_n(1,nqp::inf))'
10:26 rba NaN
10:26 timotimo well, that's not what we expect
10:27 rba timotimo: will be off for lunch quicky...
10:27 timotimo but we literally just call pow() with those values
10:27 timotimo If x is +1, the result is 1.0 (even if y is a NaN).
10:27 timotimo this is from "man pow"
10:28 timotimo it's not a critical problem, of course. we don't use this anywhere in compilation or something
10:28 timotimo it's just users will get strange results
10:29 rba timotimo: maybe one of my build fixes is wrong too. here my notes: https://gist.github.com/rba/58fa69c6ac59efac7131d1da15e6e749
10:29 rba timotimo: Solaris seems to be a beast
10:30 timotimo anyway, for the crash you can look into stuff like setting the MVM_SPESH_DISABLE env variable to 1
10:30 timotimo and seeing if that makes it better
10:30 timotimo if so, try MVM_JIT_DISABLE instead (if we have jit on solaris at all)
10:30 timotimo if not, it's gotta be something else
10:31 timotimo rerun moarvm's Configure.pl and pass --debug=3 --optimize=0 then we can get useful info out of gdb
10:32 timotimo i'll be afk for a bit
11:00 evalable6 joined #moarvm
11:00 AlexDaniel_ joined #moarvm
11:20 AlexDaniel_ joined #moarvm
11:22 timotimo hm. where should the isconcrete checks live ..
11:22 timotimo in the repr ops or in interp.c; if they live in interp.c they'll have to be reproduced in the jit, too, though
11:31 rba joined #moarvm
11:36 rba timotimo: i will do the proposed steps, yet I have to do some other task at the moment. Will come back if a have new output from the debugged moarvm build...
11:40 rba joined #moarvm
11:48 domidumont joined #moarvm
12:16 evalable6 joined #moarvm
12:39 rba timotimo: Do we nightly builds for any platform?
12:40 Zoffix nope
12:40 Zoffix There's travis and appveyor watching the repo tho
12:40 timotimo right, we don't upload the build results anywhere
12:41 timotimo the whateverables have a build for every commit
12:41 timotimo but only for linux
12:41 jnthn Travis gives Linux/OSX build feedback, AppVeyover gives Windows. They're per commit, so (unless we're all being really lazy :-)) a lot mroe often than nightly :)
12:42 jnthn Well, per push, I guess :)
12:42 timotimo including pull requests, which is really extra helpful
12:58 rba joined #moarvm
13:01 AlexDaniel_ joined #moarvm
13:06 Ven`` joined #moarvm
13:30 dogbert17 timotimo: what do you think about creating a new coverity scan of MoarVM master?
13:34 dogbert17 aha a new libuv. https://github.com/libuv/libuv/blob/v1.x/ChangeLog
13:39 AlexDaniel_ rba: fwiw, I have a sakefile here (not committed to any repo yet) that makes rakudo releases locally. It does not do anything special though, but it's good to know that I can go through the release process sucessfully before the release day
13:40 AlexDaniel_ rba: nothing special = it's just a stresstest on roast HEAD and errata, some irrelevant release stuff, and a couple of other things
13:41 AlexDaniel_ I can upload pre-release tars somewhere if people want to
13:43 rba joined #moarvm
13:50 rba AlexDaniel: thank you. may come back to you. will step-by-step go ahead to build rakudo star on Solaris 10 (currently x86 as I have no SPARC with gcc around atm). If I'm able to build it I will eventually try to get it into OpenCSW.
13:56 stmuk joined #moarvm
13:58 stmuk I think its still broken on windows
13:58 stmuk https://gist.github.com/stmuk/69b80a930bff9e2ca61c663a2981165b
14:01 Zoffix stmuk: is that during rakudo build or you compiled moarvm on its own?
14:01 stmuk during rakudo build
14:02 Zoffix stmuk: I don't think the fix is available in it yet. The bumps are blocked by a bug
14:02 stmuk is it it moar-blead?
14:02 stmuk "it in" even
14:02 Zoffix stmuk: yeah: https://github.com/MoarVM/MoarVM/commit/f97ce7a855aae410d0f92bc2dc04ec83eeb78823
14:04 * stmuk returns to his until recently malware ridden windows VM
14:09 rba joined #moarvm
14:18 rba_ joined #moarvm
14:18 dogbert17 jnthn: wrt the problems with MoarVM master. Setting MVM_GC_DEBUG=1 will make a a normal spectest run into a panic fest :) Whether the backtraces will lead to the real problem I don't know
14:19 rba joined #moarvm
14:19 dogbert17 #0  MVM_panic (exitCode=1, messageFormat=0xb7cc0224 "Collectable %p in fromspace accessed") at src/core/exceptions.c:688
14:19 dogbert17 #1  0xb7c22895 in MVM_sc_set_object (tc=0x804c5f8, sc=0x882e478, idx=45, obj=0xa76be58) at src/6model/sc.c:221
14:19 dogbert17 #2  0xb7c29dda in stub_object (tc=0x804c5f8, reader=0x86a31a0, i=45) at src/6model/serialization.c:2200
14:19 dogbert17 #3  0xb7c2c51a in MVM_serialization_demand_object (tc=0x804c5f8, sc=0x882e478, idx=45) at src/6model/serialization.c:2752
14:25 jnthn fwiw, reverting a9f4770 indeed seem to fix the hang in t/spec/S32-num/power.rakudo.moar
14:27 jnthn About those panics, probably it's that the fromspace detection logic isn't quite right any more
14:28 jnthn Hm, well, maybe
14:28 jnthn oh, yes
14:28 domidumont joined #moarvm
14:32 rba joined #moarvm
14:33 Geth ¦ MoarVM: e03cf88b03 | (Jonathan Worthington)++ | 2 files
14:33 Geth ¦ MoarVM: Update GC debug code for growing nurseries
14:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e03cf88b03
14:34 jnthn dogbert17: ^ likely ends panicfest
14:34 dogbert17 yay :-)
14:34 dogbert17 Zoffix also complained that t/spec/S32-io/lock.t hung but I suspect that the revert fixes that as well
14:35 domidumont1 joined #moarvm
14:36 jnthn Yeah, the revert fixes it
14:36 jnthn Though not pushing the revert
14:36 dogbert17 you want to figure it out I guess
14:36 jnthn Yeah
14:38 dogbert17 running the IO test with RAKUDO_SCHEDULER_DEBUG I get
14:38 dogbert17 ok 6 - \(:!non-blocking, :!shared), ""
14:38 dogbert17 1..3
14:38 dogbert17 [SCHEDULER] Created initial affinity worker thread
14:38 dogbert17 [SCHEDULER] Supervisor started
14:38 dogbert17 [SCHEDULER] Supervisor thinks there are 4 CPU cores
14:38 dogbert17 [SCHEDULER] Created initial general worker thread
14:38 dogbert17 and then nothing ...
14:44 Zoffix Hmm...
14:44 Zoffix $ perl6 -e 'start { sleep 2; exit }; "foo".IO.open.lock: :!shared;'
14:44 Zoffix Could not obtain blocking, exclusive lock: Failed to lock filehandle: 9
14:44 Zoffix I thought blocking blocked instead of failing :/
14:45 Zoffix dogbert17: it's possible that hang is replicated by running this in one terminal `perl6 -e '"foo".IO.open(:w).lock; sleep'` and in the same dir in another terminal this: `perl6 -e 'start { sleep 2; exit }; "foo".IO.open.lock: :shared;'`  normally, the second code is meant to exit after 2 seconds
14:46 jnthn It's odd, the program at least keeps doing *something*
14:46 jnthn But not sure what
14:46 jnthn All of the resizing logic is producing the output that I'd expect
14:47 jnthn Oh, but it's the spawned process that hangs
14:48 jnthn Not the parent one, which I guess is just waiting on it
14:49 jnthn Oh heck, I think I know what might be going on
14:50 Zoffix \o/
14:50 jnthn So, in
14:50 jnthn start { sleep 2; say ‘pass’; exit }; EVAL ‘say 1.0000001 ** (10 ** 8)’
14:50 jnthn The start is now run on a thread with a tiny nursery. Probably I should make it a bit less tiny
14:51 jnthn Anyway, somewhere on that thread's way to setting itself and its $*AWAITER up and so forth, it hits GC
14:51 jnthn Before, because it had 4MB of space, it didn't every reach that point
14:51 jnthn It then waits for the main thread to join in with GC
14:52 Zoffix Ahh
14:52 jnthn But...it won't. Why? 'cus it's busy doing the epic power
14:52 jnthn Before it only passed because the thread had enough memory overhead
14:52 jnthn And of course that bigint operation is written in C code
14:52 Zoffix And in the S32-io/lock.t case: 'cus it's busy waiting for a lock
14:52 jnthn So the usual "check if we need to GC at backbranches" thing doesn't happen
14:52 Zoffix (on a filehandle)
14:53 jnthn Yeah, but that lock really should be marking the thread blocked.
14:53 jnthn Ah, it doesn't do that
14:53 jnthn OK, so that lock/unlock is an easy fix, just make sure we mark the thread blocked while it does I/O
14:54 jnthn The power one...well, same fix perhaps, but maybe we should consider how big the power is?
14:54 jnthn Since the thread block/unblock costs something. Not a lot, but still
15:00 Geth ¦ MoarVM: ce8f27c6ef | (Jonathan Worthington)++ | src/io/syncfile.c
15:00 Geth ¦ MoarVM: Mark thread GC blocked when locking file
15:00 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ce8f27c6ef
15:00 jnthn That's lock.t fixed, it seems
15:07 * dogbert17 is back from meeting
15:08 dogbert17 looks like you're killing off the bugs at a rapid pace .)
15:10 Geth ¦ MoarVM: d4e230a697 | (Jonathan Worthington)++ | src/math/bigintops.c
15:10 Geth ¦ MoarVM: pow_I can be very expensive, so GC-block thread
15:10 Geth ¦ MoarVM:
15:10 Geth ¦ MoarVM: We may want to tune this based on exponent size, and may also want to
15:10 Geth ¦ MoarVM: review if other bigint ops can be so very costly and do a similar
15:10 Geth ¦ MoarVM: thing. In the meantime, this is enough to address the hang in the
15:10 Geth ¦ MoarVM: power.t spectest after the resizable nursery changes.
15:10 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d4e230a697
15:11 domidumont joined #moarvm
15:11 * dogbert17 sees a bump getting closer and closer
15:12 jnthn Clean spectest
15:12 jnthn So, original patch was fine enough, it just uncovered some other shortcomings :)
15:13 dogbert17 very cool
15:14 AlexDaniel_ joined #moarvm
15:17 dogbert17 Zoffix: if stresstest works for you then perhaps it's bump time
15:18 Zoffix ok, I'll bumop
15:19 Zoffix .oO( nqp::bum() op )
15:21 rba joined #moarvm
15:21 travis-ci joined #moarvm
15:21 travis-ci MoarVM build failed. Jonathan Worthington 'Update GC debug code for growing nurseries'
15:21 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/284237752 https://github.com/MoarVM/MoarVM/compare/54216e554295...e03cf88b039c
15:21 travis-ci left #moarvm
15:22 Zoffix 1 linux job: t/p5regex/01-p5regex.t ................. ok
15:22 Zoffix *** Error in `/tmp/moar/bin/moar': munmap_chunk(): invalid pointer: 0x00000000030b2970 ***
15:25 dogbert17 .oO
15:28 Zoffix Hm, there's actually a third (possible) issue: t/spec/S17-channel/stress.t takes ages
15:28 Zoffix It didn't use to.
15:28 Zoffix ages ~300s; the entire stresstest runs in 170s
15:29 Zoffix It's sitting on it ATM
15:29 Zoffix If it manages to complete, I'm bumping still.....
15:30 Zoffix ZOFVM: Files=1277, Tests=152562, 261 wallclock secs (21.52 usr  3.35 sys + 3474.31 cusr 178.82 csys = 3678.00 CPU)
15:31 Zoffix .tell jnthn when you get a chance, take a look at t/spec/S17-channel/stress.t It seems to take a lot longer than before. My pre-moar-bump stresstest time was 160s, post-bump it's 261s with the stresstest sitting on that test file
15:31 yoleaux Zoffix: I'll pass your message to jnthn.
15:35 dogbert17 the last two tests, 4 and 5 are very slow
15:35 dogbert17 oops
15:35 dogbert17 ok 4 - Correct answer (2)
15:35 dogbert17 MoarVM panic: Could not spawn thread: errorcode -11
15:39 dogbert17 I believe it runs out of memory
15:42 dogbert17 ok 4 - Correct answer (2)
15:42 dogbert17 [SCHEDULER] Heuristic queue progress deadlock situation detected
15:42 dogbert17 [SCHEDULER] Added a general worker thread
15:42 dogbert17 [SCHEDULER] Heuristic queue progress deadlock situation detected
15:42 dogbert17 [SCHEDULER] Added a general worker thread
15:43 dogbert17 MoarVM panic: Memory allocation failed; could not allocate 8192 bytes
15:43 * dogbert17 relocates &
16:09 travis-ci joined #moarvm
16:09 travis-ci MoarVM build failed. Jonathan Worthington 'Mark thread GC blocked when locking file'
16:09 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/284248955 https://github.com/MoarVM/MoarVM/compare/e03cf88b039c...ce8f27c6effd
16:09 travis-ci left #moarvm
17:03 AlexDaniel_ joined #moarvm
17:11 rba joined #moarvm
17:28 leont_ joined #moarvm
17:55 AlexDaniel_ joined #moarvm
19:10 evalable6 joined #moarvm
19:32 patrickz joined #moarvm
19:35 domidumont joined #moarvm
20:35 perlawhirl joined #moarvm
20:40 perlawhirl I'm getting error trying to make moarvm at the moment
20:40 perlawhirl error: redefinition of typedef ‘MVMJitCompiler’
20:40 perlawhirl https://pastebin.com/Xansbjdy
20:40 perlawhirl any ideas?
20:41 samcv did you try a make realclean?
20:41 samcv or make distclean
20:47 Ven joined #moarvm
21:06 AlexDaniel_ joined #moarvm
21:23 perlawhirl i'll give it a shot
21:41 perlawhirl hrm.... blew away my entire rakudo build... even building fresh clone of Moar by itself is failing
21:42 timotimo wow
21:42 timotimo that is actually wrong
21:43 timotimo there's two identical typedefs for MVMJitCompiler
21:43 Geth ¦ MoarVM: 64b5dc03c4 | (Timo Paulssen)++ | src/types.h
21:43 Geth ¦ MoarVM: remove duplicate typedef for MVMJitCompiler
21:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/64b5dc03c4
21:43 timotimo perlawhirl: try now
21:43 perlawhirl timotimo++
21:50 committable6 joined #moarvm
21:58 committable6 joined #moarvm
22:13 perlawhirl timotimo: standalone build of Moar successful. thanks
23:22 sivoais joined #moarvm

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