01:55 ilbot3 joined 05:39 domidumont joined 05:45 domidumont joined, brrt joined
brrt good * #moarvm 05:59
i have a quick-and-dirty fix ready for the expr jit eq_i issue
samcv good * brrt 06:02
brrt ohai samcv 06:05
Geth MoarVM/even-moar-jit: e5458167cf | (Bart Wiegmans)++ | 3 files
Let FLAGVAL return a 64 bit word

This is kind of a hack since it circumvents the automatic cast inssertion mechanism, because that doesn't work for STORE nodes, and because making it work is more involved than I had initially thought. Needs to be replaced by 'proper' upcasting, which at least includes signed constants as well.		 06:18
brrt MasterDuke++ for finding the bug
06:22 domidumont joined 06:38 brrt joined
brrt now i have to think of the 'correct' fix :-) 06:46
07:35 domidumont joined 07:37 zakharyas joined 07:47 domidumont joined 08:27 robertle joined
jnthn morning o/ 08:51
nwc10 well spotted :-) 08:53
jnthn Yeah, I can have coffee again, so it was easy to spot :P 08:54
timotimo turns out turning a laptop with wifi into an external wifi card for a desktop by connecting the two with ethernet is now ridiculously easy 09:00
yoleaux 00:53Z <MasterDuke> timotimo: if it helps, here's the MVM_dump_backtrace output at the problematic coerce_ni when running `say(100000000000000009)` gist.github.com/MasterDuke17/a34c6...a67f0249db
10:07 Ven joined
brrt so, with regards to the 'correct' fix, there's a bunch of things interplaying 10:15
the const_i64_16 tile, used a *lot*, generates 64 bit integers from 16 bit ones in the bytestream 10:16
but as it happens, the expr builder, generates a 16-bit constant as its argument
now, as these are CONST, we can 'upcast' them automatically to a 64 bit value 10:19
but as they are wrapped by a COPY, that fails
(i.e. we can tell the CONST node to automatically generate a 64 bit value)
so what happens with such values, is that they're directly STOREd to memory 10:21
and what's somewhat funny is that we load a (signed) 32 bit constant in a 64 bit register, and store it directly into a 64 bit memory location, and that stuff works as expected, i.e. the number is sign-extended
while *normally* register-to-register moves are supposed to be zero-extended, iirc
i should check that though 10:22
anyway, the root problem is one of the following: 10:36
a): const_i64_16 should argubably include its own cast
b): const nodes should arguably indicate whether they represent signed or unsigned values
nine brrt: sounds to me like in the JIT being explicit beats things happending automagically. 10:39
brrt there was a pretty good reason for the automagic behaviour though
let me think what it was
11:00 domidumont joined
brrt oh, right 11:04
because the expr jit can connect stuff in 'surpsising' ways, and because that is mostly ok as long as the sizes are all correct 11:05
i.e. you can't know a priori all the sizes you'll use
i do agree in general, though 11:06
Geth MoarVM/sync-socket-no-uv: a9cb2506fe | (Jonathan Worthington)++ | src/io/syncsocket.c
Re-implement sync sockets without using libuv.

This passes most of the socket spectests on Linux, with one timeout still to be hunted down and fixed. An attempt has been made to write this code so it can also work on Windows; that will be tested and fixed up as required in a follow-up commit.		 11:09
jnthn timotimo: Under MSVC: c:\consulting\moarvm\src\main.c(249) : warning C4700: uninitialized local variable 'interval_id' used 11:22
timotimo yeah, it can't prove that the value for the getenv doesn't change 11:26
Geth MoarVM/sync-socket-no-uv: 20aeb043bb | jnthn++ | src/io/syncsocket.c
Pick a different error-check macro name.

The previous one conflicted with a macro brought in by Winsock.		 11:28
dogbert17_ jnthn: let me know if you want me to 'stress' your branch a bit, i.e. small nursery etc 11:38
jnthn dogbert17_: Thanks, will do 11:39
lunch; bbiab
(I should make sure it works in all other aspects first :)) 11:40
Geth MoarVM: cono++ created pull request #600:
Add ability to get port from already bind-ed socket		 11:47
12:38 AlexDaniel joined
Geth MoarVM/sync-socket-no-uv: 1aa523edba | jnthn++ | src/io/syncsocket.c
Fixes for IPv6 handling.
 13:01
jnthn Looking decent on Windows. Now back to the Linux box to figure out the hang that happened there, but not on Windows... 13:21
Oh, it musta been that ipv6 thing here also 13:30
spectest looks ok, except from being a load behind from master... :) 13:34
Well, nom
lizmat sorry, been busy today :-) 13:38
jnthn It's fine
lizmat should not affect anything you're doin
jnthn No, it doesn't
None of the spectest failures are anything close to sockets :)
I think I've now got synchronous sockets nicely disentangled from libuv 13:39
And happy spectests
lizmat wonders if that will be visible in test-t
jnthn It doesn't do any socket programming, does it? 13:40
lizmat ah, no
I was thinking synchronous file handles
jnthn Yeah, those are second-to-next on the hit list
Next is, alas, getting the streaming decode stuff sorted out on JVM
lizmat wishes jnthn strength 13:41
jnthn Otherwise, I can't merge the sockets stuff without huge regression there
And doubly so once I get to file handle stuff
brrt oh, synchronous sockets without uv, very nice, yes 13:47
jnthn Oh my, now I'm seeing why I didn't do the line-based bits of the decoder API on JVM last time around... 14:05
nwc10 "your sanity is at risk if you do not keep up repayments"? 14:07
jnthn It's that fun combination of "the API doesn't naturally do what I need" and "I don't own the API" 14:10
nwc10 blame Larry? (the other Larry) 14:11
jnthn I think the great evil that is NIO may be from the pre-other-Larry days... 14:13
NIO seems disliked among folks who are otherwise generally happy with Java stuff. 14:14
brrt which larry are we talking about in this case 14:20
ins't NIO like super complicated
nwc10 brrt: the one who likes Yachts more than his own customers 14:22
er, maybe that should be yachts but he does like them big 14:23
(Ellison)
brrt oh, that guy
14:47 KDr2 joined 15:02 hoelzro joined 15:08 Ven joined 15:13 brrt joined 15:26 Ven joined
brrt anyway, let's see what plan.org tells me is left to do 15:39
15:47 Ven_ joined
jnthn Grrr...such annoying, but getting sorta close 15:50
But should head home, for grocery delivery 15:51
And that's prolly enough NIO for a day
moritz nio, that's java, right? :-) 16:19
16:42 Ven joined
nine moritz: yes 16:46
jnthn Indeed. 16:47
16:49 Ven_ joined 16:58 Ven_ joined 17:12 Ven_ joined 17:18 Ven joined 17:27 Ven joined 17:53 Ven_ joined 18:27 Ven joined 18:47 domidumont joined 19:10 Ven_ joined 20:12 Ven joined 20:16 avar joined 21:40 dalek joined
samcv morning/afternoon 21:40
Zoffix evening
jnthn evening...almost morning though :) 21:41
jnthn goes to rest 21:53
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/05/22/...-21-yap6b/ 22:32
nebuchadnezzar Hello 22:42
I'm trying to update the Debian packages and I wonder if its normal that --libdir is not passed to gcc: paste.debian.net/934241/, because the moar binary ends with “libmoar.so => not found” paste.debian.net/934242/ 22:43
It looks like we only add rpath if --prefix ne '/usr'
looks to be due to cac2a57c045fade4695fa4eed350e4bb9ece0a8f 22:44
github.com/MoarVM/MoarVM/commit/ca...bb9ece0a8f 22:45
timotimo hm, i have no clue about this, this is some kind of policy issue 22:53
nebuchadnezzar I think we may test if libdir is outside ld.conf instead of just --prefix 22:55
timotimo: I'm patching the debian package for now and I will open an issue 22:56
Open issue ✓ 23:04
!l www.youtube.com/watch?v=Lh49fLPhw2I 23:30
erf
sorry for the #BadChannel ;-)
23:41 MasterDuke 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!