Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-20

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

All times shown according to UTC.

Time Nick Message
00:06 AlexDani` joined #moarvm
01:50 buggable joined #moarvm
01:51 ilbot3 joined #moarvm
01:51 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:33 geekosaur joined #moarvm
04:47 leedo joined #moarvm
04:59 leedo joined #moarvm
05:01 leedo_ joined #moarvm
06:22 geekosaur joined #moarvm
06:56 ggoebel joined #moarvm
07:43 domidumont joined #moarvm
07:48 domidumont joined #moarvm
08:29 nine .tell AlexDaniel really everything that's missing for unbreaking the Windows build is someone to figure out how to set an environment variable in a Makefile on Windows
08:29 yoleaux nine: I'll pass your message to AlexDaniel.
08:34 nine .tell AlexDani` The fix for the Windows build could look like this: https://gist.github.com/niner/b71ecb3b0a02a0212e4b8109ad66ef16
08:35 yoleaux nine: I'll pass your message to AlexDani`.
08:37 dogbert17 joined #moarvm
10:19 * timotimo magically invokes brrt
10:21 timotimo https://github.com/MoarVM/MoarVM/blob/master/src/jit/emit_x64.dasc#L1829 - on windows, this doesn't compile, error: bad operand mode in `lea i?,x?'
10:21 timotimo oh, look
10:21 timotimo ARG5 isn't even defined on windows at all
10:24 Geth ¦ MoarVM/fix_new_jit_ops_win32: 4afc0fe0d0 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
10:24 Geth ¦ MoarVM/fix_new_jit_ops_win32: fix usage of ARG5 on windows to use stack instead
10:24 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/4afc0fe0d0
10:30 Geth ¦ MoarVM/fix_new_jit_ops_win32: dbae7ff849 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
10:30 Geth ¦ MoarVM/fix_new_jit_ops_win32: fix usage of ARG5 on windows to use stack instead
10:30 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/dbae7ff849
10:30 timotimo (a force-push)
10:38 Geth ¦ MoarVM/fix_new_jit_ops_win32: bff5385947 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
10:38 Geth ¦ MoarVM/fix_new_jit_ops_win32: lea only targets registers
10:38 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/bff5385947
10:42 timotimo yikes, now it crashes in make install?
10:44 timotimo it actually crashes in the first step of building nqp
10:58 nwc10 joined #moarvm
11:24 dogbert17 joined #moarvm
12:33 brrt joined #moarvm
12:34 brrt ohai
12:34 brrt i read the brrt sign
12:34 brrt i can haz a windows vm
12:37 brrt so, lets' check what's broken
12:41 timotimo well, i fixed the assembly problems, perhaps. it could very well be that the invoke thing is still wrong
12:42 timotimo we invoke really early in running anything much, so if that's wrong, we can immediately crash
12:46 brrt yeah, i saw that
12:46 brrt good work :-0
12:46 brrt :-)
12:51 timotimo thanks!
12:51 timotimo the error message was incredibly unhelpflu :)
12:51 timotimo ... unhelpflu?
12:51 lizmat flu is usually unhelp  :-)
12:52 brrt yeah, that's dynasm for you
12:53 brrt i'll try to help, but i'm also making hummus, so...
12:54 brrt oh i see
12:54 brrt TMP1 is rcx, as is ARG1 on windows
12:55 timotimo m( m( m( m(
12:55 timotimo i could have figured that out
12:55 brrt since you've already set that to be TC, you'll overwrite rcx when you do the lea
12:55 timotimo which one should i use?
12:55 brrt rax
12:55 brrt just by name, in this case
12:56 timotimo or should i just move it up front so the TC will be set afterwards?
12:56 brrt or TMP5, i think TMP5 and TMP6 never conflict with arg1 ....
12:56 brrt but you should check
12:56 timotimo it says so up top
12:56 timotimo that it aliases with FUNCTION
12:56 brrt oh yeah
12:57 brrt but that is a silly convention, i've learned
12:57 brrt we're going to stop doing that
12:57 brrt anyway
12:57 brrt TMP6 never aliases with anywthing :-)
12:57 timotimo yay
12:58 Geth ¦ MoarVM/fix_new_jit_ops_win32: 4f01cba5b9 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
12:58 Geth ¦ MoarVM/fix_new_jit_ops_win32: TMP1 is an alias for ARG1; TMP6 overwrites nothing
12:58 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/4f01cba5b9
13:07 brrt does that actually make it work for you, it doesn't for me
13:10 brrt (it being nqp build)
13:19 timotimo i don't have a windows
13:19 timotimo i got distracted by stuff
13:19 brrt i have a windows vm...
13:19 brrt but unfortunately, that doesn't make it work :-(
13:20 brrt maybe just bisect it
13:21 brrt https://developer.microsoft.com/en-us/windows/downloads/virtual-machines you can download windows vms with visual studio preinstalled here
13:21 brrt although i usually just use strawberry perl
13:32 timotimo anyway, yeah, it's still broken :\
13:32 brrt hmm
13:32 brrt okay, lets just bisect it
13:43 brrt messy history makes that hard
13:43 timotimo aye :(
13:43 timotimo would spesh bisect be able to help at all?
13:44 brrt if it's spesh-related, certainly
13:50 brrt so, nqp  breakage is pretty certainly JIT related
13:51 brrt oh, i have an idea...
13:57 brrt param_rp_i and param_rp_o are now jitted
13:57 brrt they return structs, and struct returnin isn't very well specified on either API
13:57 brrt (ABI)
13:58 brrt windows/posix, i mean
14:01 timotimo ah, i was quite surprised to see them being jitted but i thought someone else must know better than me
14:01 brrt yeah, i thought the same thing…
14:01 brrt well, to be clear
14:01 brrt i thought 'jnthn must've overhauled them'
14:01 brrt 'and now they can be'
14:01 brrt yeah, thats'.. naive
14:02 timotimo easy to throw out at least
14:03 brrt yeah, i'm trying now
14:05 brrt nqp builds at least
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: aca7a6776d | (Bart Wiegmans)++ | src/jit/graph.c
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: Revert "JIT param_rp_i" and "JIT param_rp_o"
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32:
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: This reverts commits 84f426ecaa8578bdeeb532ace82400e219b4cc38 and
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: 9c578330f79c9f1e831b94c074ea7ca4d7de33f9.
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32:
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: param_rp_o and param_rp_i return structs, and struct returning
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: isn't well-specified by the x86-64 ABI either on windows or
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: on posix.
14:07 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/aca7a6776d
14:11 brrt timotimo, that builds for me
14:12 brrt doesn't pass any of the nativecall tests, but thats probably because of mingw
14:12 brrt if that passes, feel free to merge (although it could do with a rebase to fix the assemlby in one step, if you ask me)
14:13 brrt i'm going to complete making my hummus
14:13 timotimo aye, good idea to squash it
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: a42c89a7b8 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: fix usage of ARG5 on windows to use stack instead
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/a42c89a7b8
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: 882ed0bcd9 | (Bart Wiegmans)++ (committed by Timo Paulssen) | src/jit/graph.c
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: Revert "JIT param_rp_i" and "JIT param_rp_o"
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32:
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: This reverts commits 84f426ecaa8578bdeeb532ace82400e219b4cc38 and
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: 9c578330f79c9f1e831b94c074ea7ca4d7de33f9.
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32:
14:15 timotimo that's rebased and squashed and everything
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: param_rp_o and param_rp_i return structs, and struct returning
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: isn't well-specified by the x86-64 ABI either on windows or
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: on posix.
14:15 Geth ¦ MoarVM/fix_new_jit_ops_win32: review: https://github.com/MoarVM/MoarVM/commit/882ed0bcd9
14:27 releasable6 joined #moarvm
14:37 zakharyas joined #moarvm
15:31 Zoffix m: \(42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs
15:31 camelia rakudo-moar ca8aaf: ( no output )
15:31 Zoffix m: dd \(42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs
15:31 camelia rakudo-moar ca8aaf: OUTPUT: «(42 => 0, ([1, 2]) => 1, ({:a(42)}) => 2, ([3, 4]) => "x", 72 => "a", ({:a(42)}) => "y").Seq?»
15:31 Zoffix m: dd (42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs
15:31 camelia rakudo-moar ca8aaf: OUTPUT: «(42 => 0, ([1, 2]) => 1, ({:a(42)}) => 2, (:a(72)) => 3, (:x([3, 4])) => 4, (:y({:a(42)})) => 5).Seq?»
17:13 zakharyas joined #moarvm
19:11 jnthn So, we need a point release with some Windows fixes?
19:34 lizmat jnthn: yeah, I think that's the gist of it
19:35 lizmat from what I understand, Moar wouldn't even build on Windows
20:04 zakharyas joined #moarvm
20:08 jnthn OK, is it actually fixed by now?
20:21 lizmat jnthn: I've been away the past hours, so I have no idea
20:25 brrt joined #moarvm
20:25 brrt ohai
20:25 yoleaux 14:34Z <AlexDaniel> brrt: I see no change
20:25 brrt yeah, the fix_new_jit_ops_win32 branch needs to be merged
20:25 brrt .tell AlexDaniel ok, unfortunately
20:25 yoleaux brrt: I'll pass your message to AlexDaniel.
20:26 Geth ¦ MoarVM: bdw++ created pull request #655: Fix new jit ops win32
20:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/655
20:27 brrt i'm wondering what the most interesting thing to do next would be
20:27 brrt i think i want to try to remove spesh codegen from the JIT path
20:28 brrt which i think we should be able to do
20:28 brrt also, get your windows vms here, folks: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
20:29 brrt no registration required, iirc
20:31 brrt i also really want to get started with the optimizer
20:35 brrt that is going to be such a fun part
20:44 lizmat jnthn: was the atomic ops work part of work for a grant?  if so, should I mention the sponsor ?
20:51 timotimo jnthn: would be interested what you think of the new names for atomic subs lizmat made: https://github.com/rakudo/rakudo/commit/ca8aafc173
20:56 AlexDaniel jnthn: we also have a problem with this: RT #131935
20:56 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=131935
20:56 yoleaux 20:25Z <brrt> AlexDaniel: ok, unfortunately
20:58 Zoffix jnthn, jnthn, jnthn!
20:58 Zoffix :)
20:59 * lizmat hopes jnthn has left the keyboard for some excellent rest
21:31 jnthn Yeah, was relaxing a bit after day doing bits in prep for SPW...
21:31 yoleaux 21:08Z <lizmat> jnthn: I'm confused about 61e1f4d5f5a4c03cd7bbfd , it looks to me reverting to an older situation, basically making the atposNd_i ops useless ?
21:32 lizmat jnthn: yeah, also working on slides  :-)
21:32 lizmat *and* the P6W
21:32 jnthn Really don't want to do it all crouched over my laptop...
21:32 jnthn Plus of course left some trip admin until now too
21:33 jnthn Like collecting our railway discount cards that we used to get cheaper tickets on the bits of the trip out of/into .cz
21:33 jnthn To be fair, they took a month to make 'em, so there was only so many days earlier I coulda done it...
21:34 jnthn Yes, atomicops were sponsored
21:35 lizmat should the sponsor be known ?
21:35 jnthn I should confirm how they wish to be know...
21:35 lizmat ok, no hurry, still about 24h until the publication of the next P6W
21:36 jnthn Will let you know
21:36 jnthn lizmat: fwiw I was going to just go without any texas forms for the pre-increment versions...
21:37 lizmat why?  I mean, isn't it custom to have texas variants for all ?
21:37 jnthn But if we're going to have them I'd rather they were like atomic-fetch-inc and atomic-inc-fetch
21:38 jnthn That is, they name the order that things happen
21:38 lizmat ok...
21:38 jnthn So atomic-fetch-dec and atomic-dec-fetch, atomic-fetch-add and atomic-add-fetch
21:39 lizmat ok, will do  :-)
21:39 AlexDaniel … really?
21:39 AlexDaniel ah ok, unicode variants are there… :)
21:39 jnthn If we're going to pick names, we might as well pick ones along the lines of what is used in other atomics APIs :)
21:40 jnthn And since we have atomic-fetch then this fits nicely with our existing naming also
21:41 jnthn AlexDaniel: Yes, the Unicode variants feel the sixiest. I wasn't convinced by them until I actually wrote the tests and saw them :)
21:41 AlexDaniel totally makes sense, although IMO it's a bit hard to read
21:41 jnthn Then really liked how it made the atomic things stand out
21:42 jnthn Which "it"? :)
21:42 jnthn Not sure whether you're talking about the Unicode or Texas being hard to read :)
21:44 AlexDaniel well, when writing something like atomic-fetch-dec($foo, 5)
21:45 lizmat jnthn: fwiw, ? doesn't render very well in vim together with postfix characters
21:45 AlexDaniel you kinda have to jump with your eyes, no?
21:46 AlexDaniel it may be my personal problem, so nvm :)
21:48 jnthn So on release stuff: I really don't think me trying to make this happen late on a Sunday evening is a wise idea, so I guess I'll look into the state of things tomorrow
21:48 AlexDaniel jnthn: sure, no problem
21:49 lizmat jnthn: thanks for the answers so far :-)
21:50 AlexDaniel releasable6: status
21:50 releasable6 AlexDaniel, Next release will happen when it's ready. 1 blocker. 220 out of 221 commits logged
21:50 releasable6 AlexDaniel, Details: https://gist.github.com/6a8c1b6219092aa1d5494f3d733c312f
22:03 geekosaur joined #moarvm
22:13 AlexDaniel timotimo: hey. Can you clarify the situation with the windows build? I see that the branch with your work was not merged, and I also see that your appveyor setup is failing. So what's the status?
22:14 timotimo the appveyor doesn't have an important commit
22:14 timotimo i'm starting a new build right now
22:14 timotimo the windows build now works AFAIK, but these tests that were failing are still failing, i believe
22:25 timotimo AlexDaniel: look at the appveyor again. it says it's still running but it looks like it finished
23:38 eater joined #moarvm

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