00:35 jnthn joined 00:53 khagan joined 01:50 zakharyas joined 03:20 diakopter joined 05:07 diakopter joined 05:19 TimToady joined 05:55 domidumont joined 06:00 domidumont joined
nwc10 jnthn/nine: local merge and ASAN build happy 06:07
nine excellent :) 06:57
jnthn nwc10: Thanks; will merge in a bit :) 08:03
dalek Heuristic branch merge: pushed 68 commits to MoarVM by jnthn 09:33
jnthn There we go :) 09:34
09:48 travis-ci joined
travis-ci MoarVM build failed. jnthn 'Merge branch 'reframe'' 09:48
travis-ci.org/MoarVM/MoarVM/builds/129950941 github.com/MoarVM/MoarVM/compare/1...d2836ca43b
09:48 travis-ci left
jnthn wtf, here too 09:48
But it's just the very same merge I tested last night... 09:49
ohhh
duh
jnthn merged the reframe-jit PR, after testing it on a checkout of reframe-jit with detached HEAD and merged master 09:50
And then today git merge reframe and of it wasn't up to date 09:51
nwc10 neuralise it!
dalek arVM: 13666ec | brrt++ | src/core/ (4 files):
Make frames identifiable using a sequence number

Because frames can now be garbage-collected, they can be moved, and the identity check used in the JIT will no longer work. Thus, we'd 4186ee2 | jnthn++ | .travis.yml: Hopefully do Travis OSX builds too.		 09:52
09:52 dalek joined 10:07 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Merge branch 'reframe'' 10:07
travis-ci.org/MoarVM/MoarVM/builds/129954828 github.com/MoarVM/MoarVM/compare/2...9a0bda284c
10:07 travis-ci left
nine /win 40 10:33
jnthn grmbl, seems the JIT changes may be OSX-bust 10:42
(Yes, they are) 10:47
jnthn brrt: For when you're about, this is the debugger output of the with-JIT crash on OSX: gist.github.com/jnthn/c745be540689...c5d32ec4c4 10:57
nwc10 jnthn: those backtraces don't tell anyone the values in the register? 10:59
r: say 0x7fff0000036b % 16 11:00
camelia rakudo-jvm 40a953: OUTPUTĀ«cannot connect to eval server: Connection refusedā¤Ā»
..rakudo-moar 110087: OUTPUTĀ«11ā¤Ā»
nwc10 although I assume that the lack of alignment is the issue
oh wait, shut up, I don't know :-)
jnthn :) 11:01
dalek arVM: 9fd80cf | jnthn++ | Configure.pl:
Disable JIT on OSX for a little bit; it's bust.
 11:02
nine Nothing like fixing JIT issues on plattforms you don't have access to, eh? 11:05
lizmat I could give jnthn access to an OS X machine 11:06
11:06 travis-ci joined
travis-ci MoarVM build errored. jnthn 'Hopefully do Travis OSX builds too.' 11:06
travis-ci.org/MoarVM/MoarVM/builds/129965777 github.com/MoarVM/MoarVM/compare/7...86ee2554f8
11:06 travis-ci left
lizmat jnthn: confirm mac os x build ok with Moar HEAD 11:14
jnthn: another datapoint: t/spec/S17-supply/syntax.t now consistently fails (used to be a flapper) 11:20
PERL6LIB=lib perl6 t/spec/S17-supply/syntax.t 11:21
ok 53 - did we throws-like X::ControlFlow?
Abort trap: 6
nwc10 lizmat: it only flaps on Linux: paste.scsys.co.uk/513650
11:24 travis-ci joined
travis-ci MoarVM build errored. jnthn 'Disable JIT on OSX for a little bit; it's bust.' 11:24
travis-ci.org/MoarVM/MoarVM/builds/129967860 github.com/MoarVM/MoarVM/compare/4...d80cf56d5a
11:24 travis-ci left
lizmat fwiw, it runs to completion ok when run in lldb :-( 11:25
jnthn heh, yeah, that's why those are so fun to fix :P 11:30
I think we know the underlying issue there though, or to some degree at least 11:31
Gah, /win 16
oops
Gah, setting up the OSX travis isn't just as easy as adding osx to the OS list :P 11:33
dalek arVM: ee5846f | jnthn++ | .travis.yml:
Another try to get OSX Travis builds working.
 11:39
nine syntax.t is a very easy fix: just add some debug output and it runs rock stable 11:43
lizmat yeah, or run it under lldb/gdb
jnthn :P 11:44
yay, think I nailed the OSX travis for Moar :) 11:50
(Was my first time editing a .travis.yml :P)
I could always crib on others before, and at $dayjob stuff we use Jenkins. 11:51
Pretty sure by now I prefer travis :P
nine I sometimes wonder if a 5 line shell script would just suffice... 11:52
jnthn But it wouldn't make teh pretty outputs :P
Mostly I just like that it comes ready-integrated with various things, though.
moritz nine: it can always start with that, but then you want notifications, web output, automatic git polling that works even after a force push, ....
notification only when the build status failed etc.
nine And then you go back to jenkins and deal with dieing workers because puppet tells it to reload the config right in the middle of a build... 11:57
jnthn oh darn it 11:58
The --has-libffi ones ain't going to work out on OSX
And meeting time now, so bbiab 12:01
12:03 travis-ci joined
travis-ci MoarVM build failed. jnthn 'Another try to get OSX Travis builds working.' 12:03
travis-ci.org/MoarVM/MoarVM/builds/129974204 github.com/MoarVM/MoarVM/compare/9...5846fbd964
12:03 travis-ci left 12:45 cognominal joined 13:46 cognominal joined 14:10 brrt joined
brrt good * 14:10
jnthn o/ brrt
brrt os x bustage again
:-(
jnthn Yeah, 'fraid so :( 14:11
brrt does os x use libffi perchance?
where does it bust?
jnthn It busts on the very first file of the NQP compilation with JIT enabled
brrt oh.. .that is soon
jnthn Which gives some hope it might be silly/big rather than small/hard to find.
brrt do we have a ssh session to an os x machine? 14:12
yeah, that is hopeful
jnthn lizmat might be able to offer one
She provided me one in the past, at least, so I could debug OSX things :)
brrt you know, if apple would provide vms... 14:13
lizmat jnthn: it's still there, I only need to open it up :-)
brrt but i digress
would be much appreciated lizmat :-)
jnthn lizmat: Well, brrt++ can find this one faster than me, I'd bet :) 14:14
geekosaur OS X comes with libffi, but I think minus the headers
jnthn I think the travis build there is just trying to test we can use a pre-installed libffi 14:15
But not sure we need that for OSX
jnthn is trying to figure out how to turn that off :)
dalek arVM: 2279a5c | jnthn++ | .travis.yml:
Try not to do --has-libffi builds on OSX.
 14:19
jnthn (Don't mind if somebody wants to make 'em work, but all I want for now is *some* testing on OSX :))
yay, looks like I got it right: travis-ci.org/MoarVM/MoarVM/builds/130010332 14:21
dalek arVM: 92491d7 | jnthn++ | src/profiler/heapsnapshot.c:
Avoid pointer type warning from GCC.
 14:30
arVM: 1d63987 | jnthn++ | src/strings/normalize.h:
Pointless parens to shut up clang.
arVM: 973592c | jnthn++ | src/core/frame.h:
Missing declaration in frame.h.

Fixes a warning in collect.c.		 14:35
jnthn That should make us a tad quieter :) 14:37
timotimo i like the sound of that. especially heapcollect has been spammy as all hell 14:38
jnthn still finds it surprising that it's surprising that the precedence of && and || don't naturally follow from the precedence of * and + :)
timotimo but it was a daunting prospect to put a bajillion casts into the code just to make it not complain
jnthn Uh, that wasn't the best English but... :) 14:39
timotimo your fix clearly looks better than what i would have built
brrt jnthn, i suppose you are aware of it, but you can't move ->work, or at least make it moveable
we take references to registers everywhere, sometimes on stack, often from ->work 14:40
jnthn brrt: I'm aware that we can't *at the moment* :)
Yes :)
brrt let's rephrase that then too, 'if we're going to be super careful about moving MVMRegister*, we will have something completely different from what MoarVM is today' 14:41
jnthn Note that the circumstances env or work would move would be a lot more constrained than those where MVMFrame can move. 14:42
The latter can happen on any allocating path 'cus they're GC-able.
env/work won't become that.
So it'd only be possible on the small handful of paths that can cause stack -> heap promotion.
So it's not quite so daunting. 14:43
But yes, it would need a good bit of care.
The pay-off is quite high though, potentially. 14:44
brrt hmmm
14:45 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Try not to do --has-libffi builds on OSX.' 14:45
travis-ci.org/MoarVM/MoarVM/builds/130010332 github.com/MoarVM/MoarVM/compare/e...79a5c5d5d0
14:45 travis-ci left
brrt i see how you might get away with it if you can limit the number of possibilities 14:45
jnthn yay, I fix0red travis :)
brrt yay 14:46
jnthn And now we have OSX in there, so we'll know sooner rather than later about busting things there again.
[Coke] \o/ 14:50
14:56 leedo joined 15:12 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Pointless parens to shut up clang.' 15:12
travis-ci.org/MoarVM/MoarVM/builds/130013509 github.com/MoarVM/MoarVM/compare/2...63987d9550
15:12 travis-ci left
brrt didn't i kill the has-dynasm button... 15:13
dalek arVM: 5d854b2 | jnthn++ | src/ (4 files):
Speed up non-specialized frame creation.

By having an initial work environment that we can memcpy into place rather than having to look at what needs to be set to VMNull every time. Still to do for specialized frames.		 15:29
jnthn is tired, probably from today's meetings, so will do the specialized case another time :)
15:30 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Missing declaration in frame.h. 15:30
travis-ci.org/MoarVM/MoarVM/builds/130014922 github.com/MoarVM/MoarVM/compare/1...3592c00266
15:30 travis-ci left
jnthn Travis really wants us to know things work :P 15:45
ilmari I believe you can make it to only announce success when the state changes 15:50
jnthn ilmari: Yes, that's what we have set in the .travis.yml 15:51
github.com/MoarVM/MoarVM/blob/mast...is.yml#L27
(Unchanged for ages) 15:52
Maybe it's at-least-once semantics rahter than exactly-once semantics. Web scale and all that. :)
16:30 domidumont joined 16:38 domidumont1 joined 17:34 domidumont joined 17:37 brrt joined
brrt hmmpf 17:48
this bug disappears under nearly all debugging conditions... 17:49
geekosaur timing sensitive? (mmm heisenbugs) 17:51
brrt i'm going to see if i can 'just' trigger it
hmm, still can 17:52
we die, rather surprisingly, in GOTO NEXT 17:55
timotimo oh, oops
bytecode got b0rked and we stumbled outside of our bytecode blob?
brrt not sure... 17:56
and entirely not sure /why/ bytecode would get borked
timotimo spesh went awry? :\
brrt unlikely
it's after returning from the jit 17:57
timotimo ah, hmm
so maybe our deopt indices are b0rked?
nwc10 valgrind? 17:58
brrt not installed on lizmat++s box 18:00
no, it is likely to be jit - specific 18:01
Oh 18:05
*ahem*
which side does the stack grow to again? :-P
brrt is an idiot 18:06
also, this ought to have been present on more platforms
all of them, except windows perhaps
timotimo the bad direction 18:07
18:11 TimToady joined
dalek arVM: b4d1dc6 | brrt++ | src/jit/emit_x64.dasc:
Stacks grow downward on x86_64

I exchanged [rbp-0x20] with [rbp+0x20], making the JIT write the frame number outside its stack space. On OSX, this caused a crash, but unfortunately it was masked by alignment on linux/windows and under debuggers.		 18:16
brrt dalek tells
timotimo haha
that's amazing :) 18:17
jnthn brrt++ 18:18
That's a good'n :P
brrt it's a silly, silly, silly bug
jnthn I'm amazed it works as well as it did with that :P
arnsholt Candidate for best bug ever =D
jnthn Could you git revert my Configure patch, then we'll see if Travis is happy with the JIT fix too? :) 18:19
lizmat++ # providing an OSX shell 18:20
brrt will do
jnthn Thanks :) 18:21
dalek arVM: 9879233 | brrt++ | Configure.pl:
Revert "Disable JIT on OSX for a little bit; it's bust."

This reverts commit 9fd80cf56d5a8783d9e4538d63379bfe34173139.
brrt lets see what travis thinks
jnthn :) 18:22
nwc10 will travis do a drive-by to tell us that the build is unbust? 18:30
is it it like that joke "how do you keep an idiot in suspense?"
anyway, 18:31
brrt++ # smart enough to figure out his own bugs
hoelzro nwc10: what do you mean by "will travis do a drive-by to tell us that the build is unbust?" 18:32
nwc10 does the travis bot track state, and hence when the state flips back from "bust" to "fixed" it will appear on channel and announce this?
brrt i think so?
nwc10 or does it only show up with bad news?
brrt well, last compilations were unbust, weren't they? 18:33
nwc10 ah, yes, sigh
good point
hoelzro I believe it does
it does for my other stuff, anyway =)
nwc10 are we going from "not bust (because it was skipped)" to "not bust (because it's fixed)"
timotimo i think so 18:34
though it was theoretically bust on linux and windows, too. it just didn't asplode properly
brrt right
timotimo brrt: i already forgot why param_rp_n isn't jittable at the moment :o 18:35
but that prevented a bunch of frames to be jitted in some silly benchmark i ran
brrt it relies on MVM_args_ somethingsomething, which returns a struct, and the returning of structures is not well-defined (afaik) 18:36
timotimo oh, ergh
brrt but i may be wrong, of course
timotimo is it feasible to implement these in the exprjit?
or should we rather hold out for the rewrite of the arg handling stuff?
brrt well, if we could learn a standard for returning structs, then this should be no problem in either jit 18:38
but as far as i'm concerned, it'd be better to refactor the struct out of there, since the interpreter only uses the value part 18:39
eh, the interpreter writes the value part, and copies the exists part
eh, reads 18:52
pff, my brane is done
19:20 brrt joined
lizmat is back 19:24
just minutes too late to help brrt :-( 19:25
jnthn: should we have heard from travis by now ? 19:34
timotimo travis-ci.org/MoarVM/MoarVM/builds/130073463 - it's happy 19:36
lizmat so we should be ok with bumping MOAR and NQP ? 19:37
timotimo i guess so? i don't think the moar build does a full spectest run, but iirc the jit asploded in the very first nqp file that got compiled with it?
so yeah, i expect it's safe
lizmat ok, bumping
nwc10 valgrind spots two problems with the JIT in the regression tests. I don't know if the problems are new: paste.scsys.co.uk/513693 19:47
timotimo ooooh yeah 20:06
i didn't know aboot these, tbh
20:50 patrickz joined 21:17 brrt joined
brrt webkit.org/blog/5852/introducing-t...-compiler/ 21:25
did we discuss this before?
lizmat hi brrt, I gathered the OS X issue is resolved? 21:26
jnthn lizmat: Thanks for bumping; there was an RT to close also if it wasn't already :)
Yes, JIT bug was fixed :)
brrt++
brrt the tl;dr of it is that webkit replaced llvm with a custom backend 21:27
yes
jnthn brrt: Not seen that article before
So will be interested to read :)
lizmat ok, then I'll close the gate again :-)
brrt good idea 21:28
i actually needed sudo to run lldb 21:29
i was somewhat amazed by that 21:30
thanks again for the access
lizmat brrt: yw :-)
just let me know if you need it again :-)
brrt :-) 21:32
expr jit will require a minor update aftee reframe 21:33
jnthn is glad it's minor :) 21:35
OK, after a skim, I need to read that article when less tired.
brrt the b3 backend uses 2 IRs just like expr jit
im going to sleep as well soonish 21:36
lizmat jnthn: on #p6dev nine just realized that Inline::Perl5's issues may be reframe related
brrt not jit related i hope... oh well :-) 21:39
lizmat brrt: doesn't look like it 21:41
jnthn Hugely unlikely JIT related 21:43
brrt okay, im really going to sleep now 21:45
see you
lizmat good night, brrt
jnthn 'night, brrt++ 21:47

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!