00:06 AlexDani` joined 01:50 buggable joined 01:51 ilbot3 joined 02:33 geekosaur joined 04:47 leedo joined 04:59 leedo joined 05:01 leedo_ joined 06:22 geekosaur joined 06:56 ggoebel joined 07:43 domidumont joined 07:48 domidumont joined
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.
nine .tell AlexDani` The fix for the Windows build could look like this: gist.github.com/niner/b71ecb3b0a02...09ad66ef16 08:34
yoleaux nine: I'll pass your message to AlexDani`. 08:35
08:37 dogbert17 joined
timotimo magically invokes brrt 10:19
github.com/MoarVM/MoarVM/blob/mast...dasc#L1829 - on windows, this doesn't compile, error: bad operand mode in `lea i?,x?' 10:21
oh, look
ARG5 isn't even defined on windows at all
Geth MoarVM/fix_new_jit_ops_win32: 4afc0fe0d0 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
fix usage of ARG5 on windows to use stack instead
 10:24
MoarVM/fix_new_jit_ops_win32: dbae7ff849 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
fix usage of ARG5 on windows to use stack instead
 10:30
timotimo (a force-push)
Geth MoarVM/fix_new_jit_ops_win32: bff5385947 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
lea only targets registers
 10:38
timotimo yikes, now it crashes in make install? 10:42
it actually crashes in the first step of building nqp 10:44
10:58 nwc10 joined 11:24 dogbert17 joined 12:33 brrt joined
brrt ohai 12:34
i read the brrt sign
i can haz a windows vm
so, lets' check what's broken 12:37
timotimo well, i fixed the assembly problems, perhaps. it could very well be that the invoke thing is still wrong 12:41
we invoke really early in running anything much, so if that's wrong, we can immediately crash 12:42
brrt yeah, i saw that 12:46
good work :-0
:-)
timotimo thanks! 12:51
the error message was incredibly unhelpflu :)
... unhelpflu?
lizmat flu is usually unhelp :-)
brrt yeah, that's dynasm for you 12:52
i'll try to help, but i'm also making hummus, so... 12:53
oh i see 12:54
TMP1 is rcx, as is ARG1 on windows
timotimo m( m( m( m( 12:55
i could have figured that out
brrt since you've already set that to be TC, you'll overwrite rcx when you do the lea
timotimo which one should i use?
brrt rax
just by name, in this case
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 ....
but you should check
timotimo it says so up top
that it aliases with FUNCTION
brrt oh yeah
but that is a silly convention, i've learned 12:57
we're going to stop doing that
anyway
TMP6 never aliases with anywthing :-)
timotimo yay
Geth MoarVM/fix_new_jit_ops_win32: 4f01cba5b9 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
TMP1 is an alias for ARG1; TMP6 overwrites nothing
 12:58
brrt does that actually make it work for you, it doesn't for me 13:07
(it being nqp build) 13:10
timotimo i don't have a windows 13:19
i got distracted by stuff
brrt i have a windows vm...
but unfortunately, that doesn't make it work :-(
maybe just bisect it 13:20
developer.microsoft.com/en-us/wind...l-machines you can download windows vms with visual studio preinstalled here 13:21
although i usually just use strawberry perl
timotimo anyway, yeah, it's still broken :\ 13:32
brrt hmm
okay, lets just bisect it
messy history makes that hard 13:43
timotimo aye :(
would spesh bisect be able to help at all?
brrt if it's spesh-related, certainly 13:44
so, nqp breakage is pretty certainly JIT related 13:50
oh, i have an idea... 13:51
param_rp_i and param_rp_o are now jitted 13:57
they return structs, and struct returnin isn't very well specified on either API
(ABI)
windows/posix, i mean 13:58
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…
well, to be clear
i thought 'jnthn must've overhauled them'
'and now they can be'
yeah, thats'.. naive
timotimo easy to throw out at least 14:02
brrt yeah, i'm trying now 14:03
nqp builds at least 14:05
Geth MoarVM/fix_new_jit_ops_win32: aca7a6776d | (Bart Wiegmans)++ | src/jit/graph.c
Revert "JIT param_rp_i" and "JIT param_rp_o"

This reverts commits 84f426ecaa8578bdeeb532ace82400e219b4cc38 and 9c578330f79c9f1e831b94c074ea7ca4d7de33f9.
param_rp_o and param_rp_i return structs, and struct returning isn't well-specified by the x86-64 ABI either on windows or on posix.		 14:07
brrt timotimo, that builds for me 14:11
doesn't pass any of the nativecall tests, but thats probably because of mingw 14:12
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)
i'm going to complete making my hummus 14:13
timotimo aye, good idea to squash it
Geth MoarVM/fix_new_jit_ops_win32: a42c89a7b8 | (Timo Paulssen)++ | src/jit/emit_x64.dasc
fix usage of ARG5 on windows to use stack instead
 14:15
MoarVM/fix_new_jit_ops_win32: 882ed0bcd9 | (Bart Wiegmans)++ (committed by Timo Paulssen) | src/jit/graph.c
Revert "JIT param_rp_i" and "JIT param_rp_o"

This reverts commits 84f426ecaa8578bdeeb532ace82400e219b4cc38 and 9c578330f79c9f1e831b94c074ea7ca4d7de33f9.
param_rp_o and param_rp_i return structs, and struct returning isn't well-specified by the x86-64 ABI either on windows or on posix.
timotimo that's rebased and squashed and everything
14:27 releasable6 joined 14:37 zakharyas joined
Zoffix m: \(42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs 15:31
camelia ( no output )
Zoffix m: dd \(42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs
camelia (42 => 0, ([1, 2]) => 1, ({:a(42)}) => 2, ([3, 4]) => "x", 72 => "a", ({:a(42)}) => "y").Seq?
Zoffix m: dd (42, [1, 2], %(:42a), :72a, :x[3, 4], :y{:42a}).antipairs
camelia (42 => 0, ([1, 2]) => 1, ({:a(42)}) => 2, (:a(72)) => 3, (:x([3, 4])) => 4, (:y({:a(42)})) => 5).Seq?
17:13 zakharyas joined
jnthn So, we need a point release with some Windows fixes? 19:11
lizmat jnthn: yeah, I think that's the gist of it 19:34
from what I understand, Moar wouldn't even build on Windows 19:35
20:04 zakharyas joined
jnthn OK, is it actually fixed by now? 20:08
lizmat jnthn: I've been away the past hours, so I have no idea 20:21
20:25 brrt joined
brrt ohai 20:25
yoleaux 14:34Z <AlexDaniel> brrt: I see no change
brrt yeah, the fix_new_jit_ops_win32 branch needs to be merged
.tell AlexDaniel ok, unfortunately
yoleaux brrt: I'll pass your message to AlexDaniel.
Geth MoarVM: bdw++ created pull request #655:
Fix new jit ops win32		 20:26
brrt i'm wondering what the most interesting thing to do next would be 20:27
i think i want to try to remove spesh codegen from the JIT path
which i think we should be able to do 20:28
also, get your windows vms here, folks: developer.microsoft.com/en-us/wind...l-machines
no registration required, iirc 20:29
i also really want to get started with the optimizer 20:31
that is going to be such a fun part 20:35
lizmat jnthn: was the atomic ops work part of work for a grant? if so, should I mention the sponsor ? 20:44
timotimo jnthn: would be interested what you think of the new names for atomic subs lizmat made: github.com/rakudo/rakudo/commit/ca8aafc173 20:51
AlexDaniel jnthn: we also have a problem with this: RT #131935 20:56
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131935
yoleaux 20:25Z <brrt> AlexDaniel: ok, unfortunately
Zoffix jnthn, jnthn, jnthn! 20:58
:)
lizmat hopes jnthn has left the keyboard for some excellent rest 20:59
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 ?
lizmat jnthn: yeah, also working on slides :-) 21:32
*and* the P6W
jnthn Really don't want to do it all crouched over my laptop...
Plus of course left some trip admin until now too
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
To be fair, they took a month to make 'em, so there was only so many days earlier I coulda done it...
Yes, atomicops were sponsored 21:34
lizmat should the sponsor be known ? 21:35
jnthn I should confirm how they wish to be know...
lizmat ok, no hurry, still about 24h until the publication of the next P6W
jnthn Will let you know 21:36
lizmat: fwiw I was going to just go without any texas forms for the pre-increment versions...
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
That is, they name the order that things happen 21:38
lizmat ok...
jnthn So atomic-fetch-dec and atomic-dec-fetch, atomic-fetch-add and atomic-add-fetch
lizmat ok, will do :-) 21:39
AlexDaniel … really?
ah ok, unicode variants are there… :)
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 :)
And since we have atomic-fetch then this fits nicely with our existing naming also 21:40
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
jnthn Then really liked how it made the atomic things stand out
Which "it"? :) 21:42
Not sure whether you're talking about the Unicode or Texas being hard to read :)
AlexDaniel well, when writing something like atomic-fetch-dec($foo, 5) 21:44
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?
it may be my personal problem, so nvm :) 21:46
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
lizmat jnthn: thanks for the answers so far :-) 21:49
AlexDaniel releasable6: status 21:50
releasable6 AlexDaniel, Next release will happen when it's ready. 1 blocker. 220 out of 221 commits logged
AlexDaniel, Details: gist.github.com/6a8c1b6219092aa1d5...3d733c312f
22:03 geekosaur joined
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:13
timotimo the appveyor doesn't have an important commit 22:14
i'm starting a new build right now
the windows build now works AFAIK, but these tests that were failing are still failing, i believe
AlexDaniel: look at the appveyor again. it says it's still running but it looks like it finished 22:25
23:38 eater 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!