00:13 Ven`` joined
Geth MoarVM: e9d331d40b | (Samantha McVey)++ | src/strings/unicode_ops.c
Fix quaternary collation level's. Fixes RT#132216

Previously quaternary collation levels were only checked for checking ties via string length. Now it also applies changes in quaternary level for codepoint.		 00:42
synopsebot RT#132216 [new]: 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 02:06 timotimo joined 02:08 unicodable6 joined, nativecallable6 joined, quotable6 joined, statisfiable6 joined, squashable6 joined 02:11 ilmari_ joined 02:25 releasable6 joined 02:32 nativecallable6 joined, quotable6 joined, unicodable6 joined, squashable6 joined, statisfiable6 joined 02:33 japhb_ joined 02:39 releasable6 joined, nativecallable6 joined, squashable6 joined, quotable6 joined, statisfiable6 joined 02:40 leedo_ joined 05:25 evalable6 joined 05:39 domidumont joined 06:04 bloatable6 joined, committable6 joined, quotable6 joined, nativecallable6 joined, unicodable6 joined, greppable6 joined, coverable6 joined, evalable6 joined, bisectable6 joined, benchable6 joined, releasable6 joined, squashable6 joined, statisfiable6 joined 06:12 domidumont joined 06:14 domidumont joined
nwc10 Stage parse : moar: src/6model/sc.c:383: MVM_SC_WB_OBJ: Assertion `!(obj->header.flags & MVM_CF_FORWARDER_VALID)' failed. 06:47
make: *** [perl6-valgrind-m] Aborted
different one this time
can't reliable reproduce 06:48
(was ...-gdb last time IIRC)
07:31 leont_ joined 08:36 rba joined
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
I will get the latest MoarVM from github and hav a look at this one...
Zoffix Sweet 08:50
moritz amazed that people still use solaris 08:51
Zoffix :)
moritz especially after Oracle fired nearly all engineers and management working on solaris: dtrace.org/blogs/bmc/2017/09/04/the...f-solaris/ 08:52
Zoffix Yeah, I heard. I think rba said there were lots of banks in $location still using it or something.
moritz I'm sure there's money in maintaining solaris for the next 15 or more years 08:53
09:17 cog__ joined 09:30 squashable6 joined
Geth MoarVM: 54216e5542 | (Samantha McVey)++ | src/strings/unicode_ops.c
collation: simplify quaternary and use define's for the bitmask

Use define's to make setmodeup more clear. Simplify the quaternary return function collation_return_by_length() and change it to be called collation_return_by_quaternary().		 09:36
samcv were there issues or can i bump now or not?
i remember reading there were certain issues
Zoffix No, don't bump 09:37
There are still issues, AFAIK
Yeah, don't see any commits fixing them
samcv ok
ok there will be a failing test or two in S32-str/Collation.t then
since i just added that file 09:38
Zoffix ok :)
09:41 timo joined
dogbert17 samcv: didn't you fix github.com/MoarVM/MoarVM/issues/664 ? 09:42
samcv yep 09:43
i fixed many things :P
and haven't gotten around to closing all the issues
will close that one now 09:44
09:47 rba_ joined
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... ;-)
Guest65627 rba: if memmem is a problem, you can just try the #define that enables our copy-pasted implementation 09:53
dogbert17 nite samcv 09:58
rba timotimo: I changed src/platform/memmem.h: #if defined(_WIN32) || defined(__APPLE__) || defined(__Darwin__) || defined(__sun) 10:07
timotimo: yet, I have then errors on nqp tests
timotimo good 10:08
can you paste the errors somewhere?
rba timotimo: shure, give me a sec... 10:09
timotimo: nqp test output: gist.github.com/rba/6925e11391a4e5...6b2444165e 10:16
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:17
rba timotimo: and more worse rakudo segfaulted: gist.github.com/rba/8369cfa00dc3e9...a1e09905c4 10:18
timotimo stage parse could also die because of too little ram; how much free ram and swap do you have? 10:19
rba timotimo: gist.github.com/rba/9c771b7341fc90...f5f940119e
timotimo: gist.github.com/rba/dda378519609f2...d7d621b54d 10:20
timotimo OK, let's look at the pow_n one first 10:21
hold on, what versions are you running? 10:23
there's more tests there in my version than in your output 10:24
rba rakudo-star.2017.07
timotimo OK, that's probably just fine
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)'?
oh sorry
nqp-m -e 'say(nqp::pow_n(1,nqp::inf))
damn it
rba timotimo: all the above is now from rakudo star again
./nqp-m -e 'say(nqp::pow_n(1,nqp::inf))' 10:26
NaN
timotimo well, that's not what we expect
rba timotimo: will be off for lunch quicky... 10:27
timotimo but we literally just call pow() with those values
If x is +1, the result is 1.0 (even if y is a NaN).
this is from "man pow"
it's not a critical problem, of course. we don't use this anywhere in compilation or something 10:28
it's just users will get strange results
rba timotimo: maybe one of my build fixes is wrong too. here my notes: gist.github.com/rba/58fa69c6ac59ef...da15e6e749 10:29
timotimo: Solaris seems to be a beast
timotimo anyway, for the crash you can look into stuff like setting the MVM_SPESH_DISABLE env variable to 1 10:30
and seeing if that makes it better
if so, try MVM_JIT_DISABLE instead (if we have jit on solaris at all)
if not, it's gotta be something else
rerun moarvm's Configure.pl and pass --debug=3 --optimize=0 then we can get useful info out of gdb 10:31
i'll be afk for a bit 10:32
11:00 evalable6 joined, AlexDaniel_ joined 11:20 AlexDaniel_ joined
timotimo hm. where should the isconcrete checks live .. 11:22
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
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:36
11:40 rba joined 11:48 domidumont joined 12:16 evalable6 joined
rba timotimo: Do we nightly builds for any platform? 12:39
Zoffix nope 12:40
There's travis and appveyor watching the repo tho
timotimo right, we don't upload the build results anywhere
the whateverables have a build for every commit 12:41
but only for linux
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 :)
Well, per push, I guess :) 12:42
timotimo including pull requests, which is really extra helpful
12:58 rba joined 13:01 AlexDaniel_ joined 13:06 Ven`` joined
dogbert17 timotimo: what do you think about creating a new coverity scan of MoarVM master? 13:30
aha a new libuv. github.com/libuv/libuv/blob/v1.x/ChangeLog 13:34
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:39
rba: nothing special = it's just a stresstest on roast HEAD and errata, some irrelevant release stuff, and a couple of other things 13:40
I can upload pre-release tars somewhere if people want to 13:41
13:43 rba joined
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:50
13:56 stmuk joined
stmuk I think its still broken on windows 13:58
gist.github.com/stmuk/69b80a930bff...3a2981165b
Zoffix stmuk: is that during rakudo build or you compiled moarvm on its own? 14:01
stmuk during rakudo build
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?
"it in" even
Zoffix stmuk: yeah: github.com/MoarVM/MoarVM/commit/f9...83eeb78823
stmuk returns to his until recently malware ridden windows VM 14:04
14:09 rba joined 14:18 rba_ joined
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:18
14:19 rba joined
dogbert17 #0 MVM_panic (exitCode=1, messageFormat=0xb7cc0224 "Collectable %p in fromspace accessed") at src/core/exceptions.c:688 14:19
#1 0xb7c22895 in MVM_sc_set_object (tc=0x804c5f8, sc=0x882e478, idx=45, obj=0xa76be58) at src/6model/sc.c:221
#2 0xb7c29dda in stub_object (tc=0x804c5f8, reader=0x86a31a0, i=45) at src/6model/serialization.c:2200
#3 0xb7c2c51a in MVM_serialization_demand_object (tc=0x804c5f8, sc=0x882e478, idx=45) at src/6model/serialization.c:2752
jnthn fwiw, reverting a9f4770 indeed seem to fix the hang in t/spec/S32-num/power.rakudo.moar 14:25
About those panics, probably it's that the fromspace detection logic isn't quite right any more 14:27
Hm, well, maybe 14:28
oh, yes
14:28 domidumont joined 14:32 rba joined
Geth MoarVM: e03cf88b03 | (Jonathan Worthington)++ | 2 files
Update GC debug code for growing nurseries
 14:33
jnthn dogbert17: ^ likely ends panicfest 14:34
dogbert17 yay :-)
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
jnthn Yeah, the revert fixes it 14:36
Though not pushing the revert
dogbert17 you want to figure it out I guess
jnthn Yeah
dogbert17 running the IO test with RAKUDO_SCHEDULER_DEBUG I get 14:38
ok 6 - \(:!non-blocking, :!shared), ""
1..3
[SCHEDULER] Created initial affinity worker thread
[SCHEDULER] Supervisor started
[SCHEDULER] Supervisor thinks there are 4 CPU cores
[SCHEDULER] Created initial general worker thread
and then nothing ...
Zoffix Hmm... 14:44
$ perl6 -e 'start { sleep 2; exit }; "foo".IO.open.lock: :!shared;'
Could not obtain blocking, exclusive lock: Failed to lock filehandle: 9
I thought blocking blocked instead of failing :/
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:45
jnthn It's odd, the program at least keeps doing *something* 14:46
But not sure what
All of the resizing logic is producing the output that I'd expect
Oh, but it's the spawned process that hangs 14:47
Not the parent one, which I guess is just waiting on it 14:48
Oh heck, I think I know what might be going on 14:49
Zoffix \o/ 14:50
jnthn So, in
start { sleep 2; say ‘pass’; exit }; EVAL ‘say 1.0000001 ** (10 ** 8)’
The start is now run on a thread with a tiny nursery. Probably I should make it a bit less tiny
Anyway, somewhere on that thread's way to setting itself and its $*AWAITER up and so forth, it hits GC 14:51
Before, because it had 4MB of space, it didn't every reach that point
It then waits for the main thread to join in with GC
Zoffix Ahh 14:52
jnthn But...it won't. Why? 'cus it's busy doing the epic power
Before it only passed because the thread had enough memory overhead
And of course that bigint operation is written in C code
Zoffix And in the S32-io/lock.t case: 'cus it's busy waiting for a lock
jnthn So the usual "check if we need to GC at backbranches" thing doesn't happen
Zoffix (on a filehandle)
jnthn Yeah, but that lock really should be marking the thread blocked. 14:53
Ah, it doesn't do that
OK, so that lock/unlock is an easy fix, just make sure we mark the thread blocked while it does I/O
The power one...well, same fix perhaps, but maybe we should consider how big the power is? 14:54
Since the thread block/unblock costs something. Not a lot, but still
Geth MoarVM: ce8f27c6ef | (Jonathan Worthington)++ | src/io/syncfile.c
Mark thread GC blocked when locking file
 15:00
jnthn That's lock.t fixed, it seems
dogbert17 is back from meeting 15:07
looks like you're killing off the bugs at a rapid pace .) 15:08
Geth MoarVM: d4e230a697 | (Jonathan Worthington)++ | src/math/bigintops.c
pow_I can be very expensive, so GC-block thread

We may want to tune this based on exponent size, and may also want to review if other bigint ops can be so very costly and do a similar thing. In the meantime, this is enough to address the hang in the power.t spectest after the resizable nursery changes.		 15:10
15:11 domidumont joined
dogbert17 sees a bump getting closer and closer 15:11
jnthn Clean spectest 15:12
So, original patch was fine enough, it just uncovered some other shortcomings :)
dogbert17 very cool 15:13
15:14 AlexDaniel_ joined
dogbert17 Zoffix: if stresstest works for you then perhaps it's bump time 15:17
Zoffix ok, I'll bumop 15:18
.oO( nqp::bum() op )
 15:19
15:21 rba joined, travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Update GC debug code for growing nurseries' 15:21
travis-ci.org/MoarVM/MoarVM/builds/284237752 github.com/MoarVM/MoarVM/compare/5...3cf88b039c
15:21 travis-ci left
Zoffix 1 linux job: t/p5regex/01-p5regex.t ................. ok 15:22
*** Error in `/tmp/moar/bin/moar': munmap_chunk(): invalid pointer: 0x00000000030b2970 ***
dogbert17 .oO 15:25
Zoffix Hm, there's actually a third (possible) issue: t/spec/S17-channel/stress.t takes ages 15:28
It didn't use to.
ages ~300s; the entire stresstest runs in 170s
It's sitting on it ATM 15:29
If it manages to complete, I'm bumping still.....
ZOFVM: Files=1277, Tests=152562, 261 wallclock secs (21.52 usr 3.35 sys + 3474.31 cusr 178.82 csys = 3678.00 CPU) 15:30
.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.
dogbert17 the last two tests, 4 and 5 are very slow 15:35
oops
ok 4 - Correct answer (2)
MoarVM panic: Could not spawn thread: errorcode -11
I believe it runs out of memory 15:39
ok 4 - Correct answer (2) 15:42
[SCHEDULER] Heuristic queue progress deadlock situation detected
[SCHEDULER] Added a general worker thread
[SCHEDULER] Heuristic queue progress deadlock situation detected
[SCHEDULER] Added a general worker thread
MoarVM panic: Memory allocation failed; could not allocate 8192 bytes 15:43
dogbert17 relocates &
16:09 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Mark thread GC blocked when locking file' 16:09
travis-ci.org/MoarVM/MoarVM/builds/284248955 github.com/MoarVM/MoarVM/compare/e...8f27c6effd
16:09 travis-ci left 17:03 AlexDaniel_ joined 17:11 rba joined 17:28 leont_ joined 17:55 AlexDaniel_ joined 19:10 evalable6 joined 19:32 patrickz joined 19:35 domidumont joined 20:35 perlawhirl joined
perlawhirl I'm getting error trying to make moarvm at the moment 20:40
error: redefinition of typedef ‘MVMJitCompiler’
pastebin.com/Xansbjdy
any ideas?
samcv did you try a make realclean? 20:41
or make distclean
20:47 Ven joined 21:06 AlexDaniel_ joined
perlawhirl i'll give it a shot 21:23
hrm.... blew away my entire rakudo build... even building fresh clone of Moar by itself is failing 21:41
timotimo wow 21:42
that is actually wrong
there's two identical typedefs for MVMJitCompiler 21:43
Geth MoarVM: 64b5dc03c4 | (Timo Paulssen)++ | src/types.h
remove duplicate typedef for MVMJitCompiler
timotimo perlawhirl: try now
perlawhirl timotimo++
21:50 committable6 joined 21:58 committable6 joined
perlawhirl timotimo: standalone build of Moar successful. thanks 22:13
23:22 sivoais joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!