Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-08

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

All times shown according to UTC.

Time Nick Message
00:28 zakharyas joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:06 mst joined #moarvm
06:52 domidumont joined #moarvm
06:58 Geth ¦ MoarVM/even-moar-jit: 33392bd235 | (Bart Wiegmans)++ | 2 files
06:58 Geth ¦ MoarVM/even-moar-jit: Break reference cycles in ARGLIST compilation
06:58 Geth ¦ MoarVM/even-moar-jit:
06:58 Geth ¦ MoarVM/even-moar-jit: It is possible for cycles to occur in moving values towards their
06:58 Geth ¦ MoarVM/even-moar-jit: call argument positions. In this case, we need to clear it in
06:58 Geth ¦ MoarVM/even-moar-jit: reverse order of dependencies, which is what we achieve by a stack.
06:58 Geth ¦ MoarVM/even-moar-jit:
06:58 Geth ¦ MoarVM/even-moar-jit: Still todo: correctly spilling registers that 'survive' the call,
06:58 Geth ¦ MoarVM/even-moar-jit: correctly accounting for registers that are used by the call arg.
06:58 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/33392bd235
06:58 Geth ¦ MoarVM/even-moar-jit: 50508e0732 | (Bart Wiegmans)++ | 2 files
06:58 Geth ¦ MoarVM/even-moar-jit: Implement ARGLIST/CALL conflict resolution
06:58 Geth ¦ MoarVM/even-moar-jit:
06:58 Geth ¦ MoarVM/even-moar-jit: CALL may potentially use register values, which may conflict with the
06:58 Geth ¦ MoarVM/even-moar-jit: arguments used by ARGLIST, we have to move them out of the way prior to
06:58 Geth ¦ MoarVM/even-moar-jit: loading the ARGLIST values. Use a bitmap and (instrinic) find-first-set
06:58 Geth ¦ MoarVM/even-moar-jit: operations to efficiently find the conflicting register and a free spot.
06:58 brrt joined #moarvm
06:58 Geth ¦ MoarVM/even-moar-jit: Will need to take care of potential CALL arg spilling; any values need
06:59 Geth ¦ MoarVM/even-moar-jit: to be inserted prior to the ARGLIST, which is a pretty good argument for
06:59 Geth ¦ MoarVM/even-moar-jit: merging CALL and ARGLIST.
06:59 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/50508e0732
06:59 brrt good * #moarvm
07:18 Geth ¦ MoarVM/even-moar-jit: 478224197f | (Bart Wiegmans)++ | src/jit/linear_scan.c
07:18 Geth ¦ MoarVM/even-moar-jit: BitScanForward counts from 0
07:18 Geth ¦ MoarVM/even-moar-jit:
07:18 Geth ¦ MoarVM/even-moar-jit: As per MSDN library, in contrast to FFS.
07:18 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/478224197f
07:44 brrt joined #moarvm
07:54 samcv hello brrt
07:56 brrt hi samcv
08:11 Geth ¦ MoarVM/even-moar-jit: 56 commits pushed by (A. Sinan Unur)++, (Jan-Olof Hendig)++, (Jonathan Worthington)++, (Jeff Linahan)++, (Samantha McVey)++, (Timo Paulssen)++, (Daniel Green)++, (Moritz Lenz)++, (Stefan Seifert)++, (Lucas Buchala)++, (Bart Wiegmans)++
08:11 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/compare/478224197f...326ac8c789
08:28 samcv 56!
08:28 samcv oh you merged it huh
09:13 brrt yes
09:13 brrt it's a merge commit
09:15 nwc10 good *, #moarvm
09:55 brrt ohai nwc10
09:56 brrt in the continued spirit of rubberducking
09:56 brrt i probably, nay, fairly surely, want to merge ARGLIST and CALL into a single node
09:56 brrt well, that, or a single tile, at least
09:57 brrt the simplest way to do that, would be to not output an ARGLIST tile at all
09:57 brrt it's not necessary to be there
09:57 brrt (the arglist can be indirectly gotten from the CALL, since the ARGLIST is the second parameter to the CALL
10:01 brrt on the other hand....
10:01 brrt we kind of do want to distinguish between refs of the CALL itself, and refs of the ARGLIST
10:02 brrt because the second we have to issue a load for, after spilling, and the first we don't
10:04 brrt the real issue at hand is that we need to make sure that all register shuffles etc. are inserted *after* the loads for the CALL arg
10:10 nine When the same code handles the CALL and the ARGLIST, getting the order right is trivial, right?
10:15 brrt yeah
10:16 jnthn morning o/
10:16 brrt well, loading the values before the CALL is done by insert_load_before_use, which uses the CALL as the reference tile, and the maximum order number of 1 (to mean 'just before the tile')
10:17 brrt so i can start counting from 2 to order my new moves, and then i'll be good
10:34 jnthn Turns out if you introduce signal(SIGPIPE).tap: { say "SIGPIPE" } then it unbusts https://github.com/MoarVM/MoarVM/issues/547
10:34 jnthn (At the top of the script)
10:34 dogbert17_ cool
10:36 * dogbert17_ sneaks away for an early lunch
10:53 Geth ¦ MoarVM: 2c5974bc11 | (Jonathan Worthington)++ | src/main.c
10:53 Geth ¦ MoarVM: Ignore SIGPIPE by default.
10:53 Geth ¦ MoarVM:
10:53 Geth ¦ MoarVM: We already handle (or should handle) various errors. This addresses
10:53 Geth ¦ MoarVM: issue #547, where a write to a process that does not exist would not
10:53 Geth ¦ MoarVM: break the Promise of the write, but instead cause the program to exit
10:53 Geth ¦ MoarVM: due to the SIGPIPE it received. This does not block users from adding
10:53 Geth ¦ MoarVM: their own SIGPIPE handler.
10:53 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2c5974bc11
11:07 Geth ¦ MoarVM: b8861978d0 | (Jonathan Worthington)++ | src/main.c
11:07 Geth ¦ MoarVM: Only call signal on non-Windows.
11:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b8861978d0
11:07 nine -win 10-win 11
11:07 jnthn Don't think win11 is out yet :P
11:08 samcv jnthn, what does MVMROOT do?
11:11 jnthn Adds the location on the C stack holding a variable pointing to a MoarVM object to the temporary root set
11:11 jnthn Meaning that if GC occurs, then the variable will be updated
11:11 jnthn (Which the new address of the object)
11:12 samcv i'm gonna work on the ~~ m:i// problem rn
11:12 samcv when does it need to be used?
11:12 jnthn Whenever you have any GC-managed object in a C variable, and you call code that might enter the garbage collector
11:13 jnthn Either by allocating a new object, blocking for I/O/sleep, or acquring a lock
11:13 samcv kk
11:13 jnthn samcv++ # looking at the m:i issue
11:16 * jnthn is looking at https://github.com/MoarVM/MoarVM/issues/538 while he's in the area
11:16 jnthn I believe https://github.com/MoarVM/MoarVM/issues/547 is fixed, though seeing what Windows makes of the tests for that
11:17 jnthn OK, it passes those
11:28 samcv well I fixed that one RT, but broke all other matching with fc :P
11:28 samcv because it depends on where in the string it got longer
11:36 Geth ¦ MoarVM: 249db32ed9 | (Jonathan Worthington)++ | src/io/procops.c
11:36 Geth ¦ MoarVM: Only start readers if processed spawned OK.
11:36 Geth ¦ MoarVM:
11:36 Geth ¦ MoarVM: This avoids a panic due to the task handle being used after release.
11:36 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/249db32ed9
11:36 lizmat joined #moarvm
11:37 jnthn *process, d'oh
11:44 brrt jnthn, if on windows, can you try out something for me
11:44 brrt i have a windows vm at home, but i couldn't get it to compile yesterday
11:45 jnthn brrt: Sure, what'd you like me to try?
11:45 brrt i want to see if i've wrapped the _BitScanForward intrinsic correctly
11:46 brrt https://gist.github.com/bdw/92653ca6260e06167a1c703f95fd833b
11:46 brrt whether that, if compiled with MSVC, gives you the (1-offset) number of the first bit set
11:47 brrt e.g. in 0b100, it ought to give you '3', in 0b101, it ought to give you 0
11:47 brrt eh
11:47 brrt give you 1, in the last case
11:47 brrt i need that for efficient conflict resolution using a bitmap
11:48 brrt also, it will give me your ssh private keys, if that's no problem
11:48 brrt :-P
11:49 brrt (it will work on gcc and clang, so far as I know)
11:50 * dogbert17_ is back
11:50 dogbert17_ jnthn, should I test something?
11:58 samcv jnthn, weird for MVM_string_equal_at_ignore_case i'm getting the offset as 115 even when both strings are 1 or 2 cp's long
11:58 Geth ¦ MoarVM: 8e292b8a06 | (Jonathan Worthington)++ | src/io/procops.c
11:58 Geth ¦ MoarVM: Remove deprecated char-mode async proc reading.
11:58 Geth ¦ MoarVM:
11:58 Geth ¦ MoarVM: At the VM level, we always do this in terms of bytes these days, and
11:58 Geth ¦ MoarVM: the language-level code manages the decoding. Removing it now to ease
11:58 Geth ¦ MoarVM: an upcoming fix.
11:58 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8e292b8a06
11:58 Geth ¦ MoarVM: 91aab714f8 | (Jonathan Worthington)++ | src/io/procops.c
11:58 Geth ¦ MoarVM: Signal error to stdout/stderr on spawn failure.
11:58 Geth ¦ MoarVM:
11:58 Geth ¦ MoarVM: So that the supplies that are on the receiving end of these will
11:58 Geth ¦ MoarVM: quit rather than just hang around.
11:58 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/91aab714f8
11:59 samcv and obviously that's past the length of the string so it's probably why it's not matching it. or at least part of the reason. idk where it gets 115 from
12:02 jnthn dogbert17_: Could verify that the one I closed and the other one are fixed for you also...I pushed a test file to roast
12:03 jnthn brrt: heh heh...I read FFS something other than find first set :P
12:03 jnthn OK, seems 91aab714f8 fixes things up on windows too ;)
12:03 jnthn *:)
12:05 jnthn brrt: Um, some errors
12:05 samcv i'm not sure what is caling that mvm function. it doesn't seem to have a nqp op associated with it
12:05 samcv maybe somewhere else in moar?
12:06 jnthn static inline ain't written like that
12:06 brrt oh
12:06 brrt how ought it to be written
12:07 jnthn C:\consulting\MoarVM>ffs 50
12:07 jnthn 50 2
12:07 jnthn C:\consulting\MoarVM>ffs 49
12:07 jnthn 49 1
12:07 jnthn Checking
12:07 samcv jnthn, eqat_s is mapped to eqat, can i add a eqatic to map to eqatic_s
12:08 jnthn brrt: static __inline
12:08 brrt i think at least part of the problem is that MVMint32 isn't defined :-)
12:08 brrt wait, what
12:08 jnthn Yeah, I already threw in a #define for that
12:08 brrt you're telling me that MSVC doesn't understand 'inline'
12:09 jnthn brrt: https://gist.github.com/jnthn/bdaf6aa21216a99fe153dd5e2555fee7 compiles
12:09 jnthn Lunch time here
12:09 jnthn samcv: Can help you hunt it down after lunch :)
12:09 jnthn bbi30
12:09 brrt thanks! :-)
12:09 brrt have a good lunch
12:10 samcv i'm going to bed soon
12:11 samcv but it just has to do with the offset changing when the grapheme number changes
12:13 Geth ¦ MoarVM/even-moar-jit: b6787d8a6c | (Bart Wiegmans)++ | src/jit/linear_scan.c
12:13 Geth ¦ MoarVM/even-moar-jit: MSVC spells 'static inline' differently
12:13 Geth ¦ MoarVM/even-moar-jit:
12:13 Geth ¦ MoarVM/even-moar-jit: So let's use the pre-existing macro for it.
12:13 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/b6787d8a6c
12:13 brrt jnthn++ by the way
12:18 brrt that said.
12:18 brrt we could be using macro-based compiler feature detection, a lot more than we are now
12:19 brrt that could potentially make MoarVM more easily crosscompileable
12:39 dogbert17_ jnthn: both RT's (125651, 128526) now generate exceptions instead of exiting silently
12:42 dogbert17_ also MoarVM 538 works better on Linux now, instead of a moarvm panic it now says 'caught exception X::AdHoc \n Unhandled exception in code scheduled on thread 3 \n no such file or directory'
12:43 dogbert17_ the RT's on the other hand only say Promise broken, why that happened isn't mentioned but perhaps that is the way it should be?
12:49 * jnthn back
12:52 jnthn Curious
12:53 jnthn Original exception: Died with X::AdHoc+{X::Promise::Broken}
12:53 jnthn That's LTA
12:53 jnthn Oh
12:54 jnthn No, something is decidedly up
13:04 dogbert17_ uh oh
13:05 jnthn We convey a decent error from MoarVM land at least
13:05 jnthn Ah, this looks better
13:06 jnthn For some reason we seem to ahve been duplicately .done/.quit-ing the stdout/stderr supplies too
13:06 jnthn Which got filtered out, but still, it's waste
13:06 jnthn Spectesing a rakudo patch now that should get the error in better shape
13:07 dogbert17_ nice
13:17 jnthn Pushed and done version bumps so we can run tests :)
13:18 * dogbert17_ pulls ...
13:19 * lizmat also
13:20 * jnthn reproduced https://gist.github.com/dogbert17/037f464c4da80a286f9e0895fae63ed9 locally, fwiw
13:22 dogbert17_ oh :) so you're going after the interesting stuff now :)
13:23 dogbert17_ lizmat, don't think harness6 will play ball just yet ...
13:23 dogbert17_ jnthn 'Don't duplicately .done/.quit the stdout and stderr channels' were these called twice?
13:24 jnthn Yes, .done and .quit were already called
13:26 Geth ¦ MoarVM: ffd32f5313 | (Jonathan Worthington)++ | src/6model/reprs/Decoder.c
13:26 Geth ¦ MoarVM: MVMROOT decoder when building string result.
13:26 Geth ¦ MoarVM:
13:26 Geth ¦ MoarVM: An MVMString is a GC-able object, so fetching it may allocate, which
13:26 Geth ¦ MoarVM: in turn can cause the decoder to move. Thus the exit_single_user call
13:26 Geth ¦ MoarVM: could end up zeroing the wrong place.
13:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ffd32f5313
13:28 jnthn With that, we don't seem to trip it in the run I'm doing so far
13:31 dogbert17_ oO
13:32 dogbert17_ we should let lizmat test your latest fix since that should improve harness6 (well at least a bit :-)
13:34 jnthn Well, unfortunately the bug was in the mechanism I added to detect concurrent mis-use
13:34 lizmat running with prove6 now, only got out of sequence errors in the uniprop test so far
13:35 jnthn So now we're back to seeing if it trips properly :S
13:39 dogbert17_ yep, will start running it in the background
13:41 jnthn Gah, I forgot to compile with debug symbols and got a harness6 segv, and of course now I've no symbols and what happens...
13:42 jnthn Ah,now got the mp_clear explosion again
13:49 jnthn Language class now; after will have a crack at it with http://rr-project.org/
13:52 jnthn Aww...but I'm in a VM so seemingly don't have the required perf counters 'cus they ain't virtualized... :S
13:59 geekosaur joined #moarvm
14:04 dogbert17_ jnthn: tested RT #125651 and RT #128526. Looks very good. Should be set to resolved :)
14:04 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=125651
14:04 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128526
14:15 dogbert17_ jnthn: the example from MoarVM 547 still says 'Original exception: \n  Died with X::AdHoc+{X::Promise::Broken}' though
14:22 travis-ci joined #moarvm
14:22 travis-ci MoarVM build failed. Jonathan Worthington 'Only start readers if processed spawned OK.
14:22 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/208939183 https://github.com/MoarVM/MoarVM/compare/b8861978d032...249db32ed963
14:22 travis-ci left #moarvm
14:48 timotimo i got myself rr now
14:48 timotimo what exactly are we trying it on now?
14:48 timotimo harness6?
14:49 dogbert17_ yes
14:50 timotimo let's see...
14:50 timotimo it's now rr-ing make it seems like m)
14:50 timotimo need to plug that in somewhere deep there
14:50 dogbert17_ I have run it three or four times already (i.e. spectest) in gdb. Not a single SEGV :(
14:51 timotimo i hope my 9 gigs of storage are enough. it's already reached 1.2gigs before it started any spec tests
14:52 timotimo nope, i better kill this and try it another way
14:52 dogbert17_ uh oh
14:53 timotimo no biggie, i can just trace it to my external usb hard drive that's almost 1tb free space
14:54 timotimo oh i forgot to set more test jobs this time
14:57 timotimo OK, the external hard drive is set as the tracing target
14:57 timotimo it'll be a bit slower, but at least it'll be enough space
15:06 dogbert17_ I got a SIGABORT, seems to be the bigint thingie
15:10 timotimo t/spec/S04-statement-modifiers/with.rakudo.moar - failed 2 tests
15:10 timotimo maybe i ought to update my rakudo before i try rr the next time
15:10 timotimo for some reason it's stopped growing at 2.5gb
15:11 timotimo i wonder if i can give jnthn a completed trace so he can inspect things? is that something that rr tries to do?
15:11 timotimo make traces compatible across different machines?
15:12 timotimo ah, still growing, but more slowly
15:12 dogbert17_ I wonder if I should have turned on jnthn's array debug support
15:12 timotimo also, it doesn't seem like it's really doing multiple tests in parallel?
15:12 timotimo okay, maybe a little bit
15:13 timotimo but even though i have 8 test jobs, it's not maxing out my CPU
15:19 timotimo emulates a single-core machine. So, parallel programs incur the slowdown of running on a single core. This is an inherent feature of the design.
15:20 timotimo fair enough
15:20 jnthn I wonder if I have access to anything I can run rr on...
15:20 jnthn Seems VirtualBox doesn't expose the hardware perf counters
15:21 timotimo can always buy a cheapo laptop from a discounter around the corner ;)
15:21 leedo joined #moarvm
15:21 timotimo though i've heard that laptops that aren't thinkpads are kind of hit-and-miss with linux hardware support?!
15:27 jnthn I've got a linode I can try it on
15:27 brrt that depends a lot on what you want to do with it
15:29 timotimo hm, linode may also be "too" virtualized to do it
15:30 jnthn Aww, now I get errors about missing libc versions and stuff
15:31 jnthn And yeah, it likely is also
15:31 jnthn So won't sink too much time into that
15:32 dogbert17_ I got a SIGABORT,do you want a gist of it
15:32 timotimo https://github.com/mozilla/rr/wiki/Trace-Portability - just the question i was asking before
15:32 jnthn dogbert17_: Sure, can be interesting
15:33 jnthn dogbert17_: From spectest6, yes?
15:33 timotimo 7.4 GB by now
15:33 dogbert17_ make stresstest HARNESS_TYPE=6 TEST_JOBS=7
15:33 dogbert17_ https://gist.github.com/dogbert17/b873fa5df2b8fed7157880da0339f099
15:34 jnthn "VMware and KVM are known to work"
15:34 jnthn I think Linode uses KVM
15:35 timotimo cool
15:35 timotimo worth a try, then
15:35 jnthn Not if it's struggling with libc vesions :S
15:35 jnthn *versions
15:36 timotimo hmm
15:36 jnthn dogbert17_: Yeah, that looks like what I can often reproduce locally
15:37 dogbert17_ so, what more do you need :-)
15:37 dogbert17_ I assume that the output doesn't give enough info
15:39 jnthn No, sadly it's not in the slightest clear why we end up with a corrupt P6bigint
15:39 dogbert17_ what can cause this, which I just got (spectest)
15:39 dogbert17_ Unhandled exception in code scheduled on thread 11
15:39 dogbert17_ No such method 'handle-entry' for invocant of type 'IterationBuffer'
15:39 dogbert17_ in block  at /home/dogbert/repos/rakudo/lib/TAP.pm6 (TAP) line 290
15:40 jnthn I believe that may be a separate issue; if it's in print-ruler or whatever it's called it may be spesh related
15:41 timotimo i wonder how much smaller the trace would be if i threw out the jit ...
15:41 dogbert17_ so there are at least two issues left
15:41 timotimo i've reached t/spec/integration!
15:44 jnthn timotimo: given we want it to crash that's...not so promising :P
15:44 timotimo yeah ;(
15:44 timotimo doesn't it usually crash very late into the spec test?
15:44 jnthn I've seen it anywhere
15:44 jnthn Early, middle, late
15:44 timotimo OK
15:45 jnthn Mine just blew in S32
15:45 timotimo is "tests out of sequence" a problem we want to look at?
15:45 timotimo t/spec/S15-unicode-information/uniprop.rakudo.moar  (Wstat: 0 Tests: 161 Failed: 0)
15:45 timotimo Parse errors: Tests out of sequence.  Found (29) but expected (27)
15:45 timotimo (plus another hundred lines)
15:46 Geth ¦ MoarVM/helgrind_support: 90e71ccfdd | (Timo Paulssen)++ | 3 files
15:46 Geth ¦ MoarVM/helgrind_support: annotate a few places for helgrind
15:46 Geth ¦ MoarVM/helgrind_support:
15:46 Geth ¦ MoarVM/helgrind_support: hopefully cuts down on false-positives, but i haven't come
15:46 Geth ¦ MoarVM/helgrind_support: up with a good way to actually test that yet!
15:46 Geth ¦ MoarVM/helgrind_support: review: https://github.com/MoarVM/MoarVM/commit/90e71ccfdd
15:46 jnthn timotimo: I think IOninja was already looking in to that one
15:46 timotimo ok, cool
15:46 timotimo updating all my components now
15:47 jnthn The object it's trying to GC is really an Int, not something we mixed in to
15:47 jnthn So we can rule that part out
15:48 IOninja timotimo: that's caused by https://rt.perl.org/Ticket/Display.html?id=130953#ticket-history
15:48 IOninja timotimo: it's a release blocker and I don't know how to fix it. So... have at it? :)
15:49 timotimo oh, damn
15:52 lizmat jnthn: fwiw, 4 runs of prove6, no segfault seen yet
15:53 jnthn lizmat: Lucky you, I get them almost every time
15:53 timotimo "lucky" :)
15:54 lizmat well, that means it just easier for you to debug  :-)
15:55 timotimo oh! i had moarvm still with --optimize=0
15:55 timotimo i wonder if that's a good idea
16:01 jnthn I found one interesting thing examining the debug state
16:01 jnthn Which is that we were doing the gen2 freeing *after* marking a thread back to blocked rather than stolen
16:02 jnthn And that in theory means the thread could have started running again while another was freeing its gen2 still, and they'd race on the freelist
16:02 timotimo that'd be very bad :)
16:03 jnthn Done the simplest possible change to not do that
16:04 dogbert17_ is that change in master?
16:04 timotimo clearly not yet
16:04 dogbert17_ :-)
16:04 jnthn Just locally :)
16:04 jnthn Trying if it even helps us get through one local run
16:04 jnthn It still doesn't explain the rather spooky thing that everything we trip up on is an Int
16:04 geekosaur joined #moarvm
16:05 timotimo yes, quite mysterious
16:05 jnthn Run 1 passed
16:05 jnthn But that's not enough to say anything
16:06 jnthn (Passed as in no SEGV; require.t fails due to bustage, and there's the unicode-information issue that's not the thing we're hunting here)
16:06 brrt joined #moarvm
16:07 timotimo i could run more than one rr in parallel!
16:07 timotimo BBIAB
16:10 dogbert17_ so what you found was a bug but not necessarily the one we're after?
16:11 jnthn dogbert17_: Too early to say
16:12 dogbert17_ I'll wait :)
16:12 timotimo it is not advised to hold your breath at this time
16:13 jnthn Doing a third run at the moment
16:28 dogbert17_ jnthn, when you have time (RT's 125651 and 128526 can be set to resolved/closed)
16:28 Geth ¦ MoarVM: d4d9eb8ce1 | (Jonathan Worthington)++ | src/gc/orchestrate.c
16:28 Geth ¦ MoarVM: Do gen2 sweep before letting stolen thread go.
16:28 Geth ¦ MoarVM:
16:28 Geth ¦ MoarVM: Sweeping gen2 involves putting things onto a free list. Nursery sweeps
16:28 Geth ¦ MoarVM: are safe to do concurrently with the mutator running since there is no
16:28 Geth ¦ MoarVM: free list, just a now-unused fromspace that another thread is free to
16:28 Geth ¦ MoarVM: consider independently. However, gen2 sweeps manipulate a free list
16:28 Geth ¦ MoarVM: that is used to allocate, so the mutator runing at the same time would
16:28 Geth ¦ MoarVM: <…commit message has 6 more lines…>
16:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d4d9eb8ce1
16:28 jnthn 4 successful runs, so sharing the commit for wider testing
16:30 jnthn RT #125651 closed
16:30 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=125651
16:33 jnthn And now RT #128526 too
16:33 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128526
16:36 jnthn 5 completed harness6 runs now
16:36 dogbert17_ nice
16:36 jnthn That's the most I've ever seen
16:41 dogbert17_ where is lizmat when we need her :)
16:43 jnthn 6 fwiw :)
16:45 timotimo 6 is a good number
16:51 jnthn And the 7th was good too
16:51 jnthn Once I get to 10 I think I'll be satisfied :)
16:52 jnthn Especially if others can reproduce the improvement :)
16:52 timotimo this fixes what kind of failure now? the bigint explosion?
16:52 jnthn Yes
16:53 jnthn Well, none all of the failure modes we were seeing have recurred for me so far
16:54 timotimo that'd be pretty fantastic
16:57 jnthn Currently on run 9
16:58 jnthn Also may have a fix for another RT while was testing this out :)
17:00 timotimo rr is causing some tests to fail it seems like ... but the harness doesn't crash yet
17:00 timotimo of course it also takes quite a while to test all of this
17:11 jnthn Yup, 10 runs without a SEGV
17:12 jnthn Or any other kind of crash
17:12 jnthn Jsut the tests out of sequene one and require.t failing
17:13 timotimo ===(       0;4045  0/?  0/?  553/553  0/?  63/162  14/17  0/?  0/8)===fish: “env TEST_JOBS=8 _RR_TRACE_DIR=/…” terminated by signal SIGSEGV (Address boundary error)
17:13 timotimo cool!
17:15 timotimo wtf.
17:15 timotimo i "run" and "continue" and it says "program stopped."
17:16 timotimo the other one segfaulted, too!
17:16 * timotimo builds new moarvm
17:23 timotimo i'll let it run in a while loop and see how often it succeeds
17:46 travis-ci joined #moarvm
17:46 travis-ci MoarVM build errored. Jonathan Worthington 'MVMROOT decoder when building string result.
17:46 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/208968674 https://github.com/MoarVM/MoarVM/compare/91aab714f8e2...ffd32f5313ba
17:46 travis-ci left #moarvm
17:48 jnthn Bogus
17:52 dogbert17 is it LTA that the example from MoarVM 547 throws like this? 'Died with X::AdHoc+{X::Promise::Broken}'
18:02 domidumont joined #moarvm
18:15 domidumont joined #moarvm
18:21 timotimo 10 runs without trouble so far
18:28 vendethiel joined #moarvm
18:45 agentzh joined #moarvm
19:22 timotimo 21 successive successes
19:23 timotimo oh, wait
19:23 timotimo i tried to make it run as long as it doesn't crash
19:23 timotimo but the tests also fail, so my script should have immediately exited?!
19:23 jnthn heh :P
19:23 jnthn scripting fail :P
19:23 timotimo and of course my backscroll is only 1.8k lines
19:23 jnthn aww
19:24 timotimo in total, this day is one on which i'd like to flip every table in existence
19:24 timotimo and every table thas has ever existed, and every table that might ever exist in the future
19:25 * TimToady avoids tables today
19:26 timotimo just imagine, carpenters in the future try building tables, but mysteriously they always end up flipped when they finish building them
19:42 moritz leading to an agile carpentry revolution, where unfinished tables are shipped to the customer before they get a chance to flip
19:44 timotimo yup
19:44 timotimo there'll always be a hole for a screw, but no screw
19:44 timotimo in every table around the world
19:59 TimToady that's overkill, all they really have to do is ship all new tables upside-down, and then everything works out
20:00 TimToady and we can ship all the old tables to Australia...
20:03 vendethiel joined #moarvm
20:35 vendethiel- joined #moarvm
20:49 * jnthn will be very relieved if the spectest6 crashes really are all resolved by this fix
20:49 nwc10 well, it's still going round in circles
20:49 nwc10 (That's a good thing)
20:50 jnthn :)
20:50 * nwc10 hopes so too, because then it's a relatively small step to switching the default Rakudo harness to be 6
20:50 jnthn Aye
20:50 nwc10 IIRC that gets you parallel testing on Windows
20:50 nwc10 er, "As I understand it"
20:50 jnthn Hm, I should try it on Windows :)
20:50 IOninja :)
20:50 nwc10 (I know why the Perl 5 harness can't do Windows)
20:50 nwc10 (in parallel)
20:51 jnthn But yeah, in theory it should behave just the same on Windows
20:52 jnthn My $dayjob app that used to be Proc::Async-heavy worked just as well on Windows as on Linux, at least :)
20:53 * lizmat is back
21:23 ggoebel joined #moarvm
21:37 Geth ¦ MoarVM: samcv++ created pull request #548: Fix string_equal_at_ignore_case when string `a` changes length
21:37 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/548
21:38 samcv jnthn, let me know what you think of this PR. fixes the tests i have written using that op so at least all the ones i've written pass
21:39 samcv if everything is fine, just tell me you approve and i'll merge it once spectest for roast comes back
22:10 jnthn Hmm...not quite sure about exposing eqatic at an nqp:: op off hand
22:11 jnthn 'cus the ic is "integer constant" meaning it's a kinda wierd op; you can only give it a literal offset iirc
22:11 jnthn I'd probably declare the counter variable in the block where it's used
22:13 jnthn I'm a tad nervous about the termination of that while loop
22:13 jnthn (the one doing counter++)
22:14 jnthn Oh, I guess we know that they differ
22:15 jnthn Also, it doesn't MVMROOT a, but then accesses it
22:16 MasterDuke jnthn: don't want to distract you too much, but while you're reviewing PRs, have you looked at https://github.com/MoarVM/MoarVM/pull/546 ?
22:18 * jnthn leaves comments
22:18 jnthn MasterDuke: Will take a look, though getting tired...
22:19 MasterDuke jnthn: no worries
22:19 samcv jnthn, the ic isn't `ignore case`? what?
22:20 jnthn Oh...
22:20 jnthn Yes, it is :D
22:20 jnthn hah
22:20 samcv heh
22:20 jnthn We did have an op that used ic for integer constant, I think :P
22:22 samcv jnthn, i don't get this "the foldcase if it expands to can never start off with the same first codepoint"?
22:22 samcv i mean if the firstn cp is diffrent then counter ends up being value 0
22:22 jnthn Yes, what if the difference is at the end?
22:23 samcv you mean the very end?
22:23 jnthn if a is cccccC (where C is the codepoint that expands to 2 on foldcase)
22:23 samcv well tests i wrote pass
22:23 jnthn Then fca would become cccccXX (where XX is the expansion of C)
22:23 samcv i will add some extra just to double check
22:23 samcv yeah i understand that
22:23 jnthn Well, XY
22:23 samcv what i wrote works for that too
22:24 jnthn Right, but it hinges on X != C
22:24 jnthn Which I'm pretty sure always must be true
22:24 jnthn But it's...not the most obvious loop termination condition :-)
22:24 Ven joined #moarvm
22:24 samcv well it has to change, or else the length wouldn't change lol
22:25 jnthn Yes, I agree it'd be very odd if a codepoint being foldcase'd expanded to itself + another char
22:25 jnthn Because then fc(fc(x)) != fc(x)
22:25 jnthn And I'm pretty sure that identify holds
22:26 jnthn Anyway, I just get nervous about loops chugging through buffers where I don't immediately see why they terminate, is all :)
22:26 samcv ah k
22:26 jnthn I'm now convinced it's correct. It just wasn't obvious for a while *why* it was, so it may be worth a comment
22:26 samcv yeah of course. totally understandable
22:27 samcv and even if it did expand to itself + another, it would still end the loop
22:27 samcv it would just be off by one
22:27 jnthn Yes, but it'd be reading off the end of the buffer a then, potentially
22:27 jnthn Which could lead to SEGV
22:28 samcv i don't see why it'd be reading off the end, it would read up until they are different
22:28 jnthn Were it possible.
22:28 samcv yeah
22:28 jnthn Yeah but fca is longer than a
22:29 samcv oh i see what you're saying
22:29 samcv :)
22:29 samcv i will add an extra condition to make sure that can never happen
22:30 samcv just to be safe
22:32 MasterDuke jnthn: replied to your comment
22:34 samcv jnthn, this patch is not perfect, but it should get us back to where we were before we changed it from lc to fc for certain characters
22:34 Geth ¦ MoarVM: beefd2b121 | (Daniel Green)++ | src/strings/ops.c
22:34 Geth ¦ MoarVM: Check result of repeat/concat fit in an MVMString
22:34 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/beefd2b121
22:34 Geth ¦ MoarVM: dc40845b16 | (Jonathan Worthington)++ | src/strings/ops.c
22:34 Geth ¦ MoarVM: Merge pull request #546 from MasterDuke17/add_checks_on_resulting_size_to_string_concatenating_and_repeating
22:34 Geth ¦ MoarVM:
22:34 Geth ¦ MoarVM: Check result of repeat/concat fit in an MVMString
22:34 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dc40845b16
22:35 jnthn samcv: Yeah. Does my final comment make sense?
22:35 samcv yeah
22:37 MasterDuke jnthn++ it took me longer than it should have to get myself sure it wouldn't overflow, but by the end i was fairly confident
22:38 jnthn yeah, I shoulda looked a little more at the context :)
22:44 MasterDuke heh, i still haven't been able to reason out the mp_get_int64 business. i generally try to use Perl (5|6) to *avoid* thinking about the bittedness of my numbers!
22:47 samcv jnthn, i updated my PR https://github.com/MoarVM/MoarVM/pull/548 tell me if i MVMROOT'd correctly
22:49 jnthn MasterDuke: I'm afraid MoarVM is one of the places where we do a bunch of the thinking that lets others think less. ;-)
22:50 jnthn samcv: Hmm, github ain't showing me any updates :S
22:50 jnthn Still just shows the commit from an hour ago
22:51 samcv ok try now
22:58 jnthn samcv: Yeah, that MVMROOTing is right
23:02 samcv yay
23:07 jnthn Feel free to merge that PR once you're happy with it
23:07 * jnthn is off to rest :)
23:07 jnthn 'night
23:10 samcv thanks jnthn
23:29 geekosaur joined #moarvm
23:34 samcv u: { .chr.fc.chars > 1 }
23:46 zakharyas joined #moarvm
23:48 geekosaur joined #moarvm

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