Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-19

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

All times shown according to UTC.

Time Nick Message
00:06 timotimo welp, i wrote a template for gethow but i got the jit to panic with "no inbound edge"
00:08 timotimo https://gist.github.com/timo/e7f7088cd82e2f7322b474fe59d10a84 - brrt can have a look at this to see what i messed up :)
00:09 timotimo oh, maybe there was a real reason to have ptr_sz as the return value for call ... :)
00:09 timotimo nope. that didn't actually fix it
00:20 timotimo i was able to build "iter" without a crash, but only as a super simple c function call
00:23 timotimo huh, i still get "cannot get template for iter" messages in the jit log though
00:31 timotimo i put the iter function up in that gist, too, for good measure
00:31 timotimo bedtime
00:32 MasterDuke i was thinking about trying some of those really simple *_i  ones
00:32 yoleaux 18 May 2017 06:01Z <brrt> MasterDuke: yes; i think there's a parser bug somewhere in there which means you need to have an extra newline after the last template
00:34 MasterDuke timotimo: how do you get that log?
00:36 timotimo MVM_JIT_LOG
00:37 timotimo grep "tree out of" /tmp/coresettingjitlog.txt  | sort | uniq -c | sort -n | less    - gives you what chunks of mvm ops it turns into expression trees
00:37 timotimo grep "get template for" /tmp/coresettingjitlog.txt    | sort | uniq -c | sort -n | less    - gives you the mvm ops that terminate individual exprjit attempts
00:38 MasterDuke cool, thanks
00:39 timotimo https://gist.github.com/timo/2b25fca488f179a29c9a555863343d78   - the thing at the top gives you the scoreboard based on the "tree out of" lines
00:40 MasterDuke i don't know what expression trees are
00:42 timotimo well, the major leap forward that the exprjit (aka even-moar-jit, aka the new jit) has over the current jit is that it creates a close-to-assembly datastructure from multiple mvm ops in a row
00:42 timotimo the jit before that would immediately spit out a piece of machine code for every mvm op it finds and then it'll be done with it
00:43 timotimo that forced us to have a load for every argument and a store for the written registers around every op
00:44 timotimo the exprjit has a low-level representation of things that get created from mvm ops and then a register allocator runs through it; that's the most basic benefit we get from the exprjit
00:44 timotimo the next step is that REPRs can have their own implementations of their reprops written in expr templates
00:44 timotimo the effect of that is much like inlining function calls
00:45 MasterDuke ah, nice
00:45 timotimo the previous jit was able to emit a direct call to a specific repr's reprop if the type of object was known at jit time
00:45 timotimo but even then the call was still opaque and presented a barrier in terms of optimization
00:46 timotimo with the exprjit we could get common subexpression elimination across multiple calls to the same reprop, for example
00:47 MasterDuke immediately subsequent calls?
00:47 timotimo another thing is that the VMArray repr has a big switch/case in many of its reprops to do the right thing based on the type of slot that the type has
00:47 timotimo well, like nqp::push_o($a, 1); nqp::push_o($a, 2); nqp::push_o($a, 3)
00:49 timotimo the pieces of dump in the jitlog that start with "digraph {", you can feed to graphviz, for example by piping/pasting it into "dot -Tx11"
00:50 timotimo the tile list log is, if i understand correctly, closer to the metal, i.e. already linearized
00:50 MasterDuke the new jit could just do the right branch of those ops?
00:50 timotimo yup, but of course it requires these reprops to be implemented once in C and once in expr tree language
00:51 MasterDuke each branch as a separate c function?
00:51 timotimo no
00:51 timotimo the C portion would be kept as is
00:52 MasterDuke oh, nice
00:52 timotimo ok, i'm off
00:52 timotimo have a good one :)
00:53 MasterDuke likewise
00:55 timotimo don't forget to look into unsafe.expr where brrt collected some templates that cause some kind of breakage
00:55 MasterDuke i wondered what that was
01:38 * Zoffix wonders if tools/contributors.p6 is buggy
01:39 Zoffix timotimo: says you made just 2 commits this month. Does that sound right? I thought there were all the telemeh stuff
01:47 MasterDuke Zoffix: month == may or month == past 30 days?
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:49 Zoffix MasterDuke: since last release.. tho the date it gives me is "Contributors to Rakudo since the release on 2017-04-23:"
01:50 Zoffix Ah, that's the last point release date
01:51 Zoffix Guess I should tweak it to last proper release
01:52 Zoffix "Contributors to Rakudo since the release on 1970-01-18:"
01:52 Zoffix I think I overtweaked
01:53 MasterDuke timotimo does only have 2 commit (in moarvm) for may, but a couple more in april after the 23rd
02:18 Zoffix k, shows 8 when I fix it to use date of last non-point release.
02:19 Zoffix ... and my new count suggests I've gone insane...
03:01 geekosaur joined #moarvm
05:01 KDr2__ joined #moarvm
05:25 domidumont joined #moarvm
05:31 domidumont joined #moarvm
06:01 brrt joined #moarvm
06:09 domidumont1 joined #moarvm
06:46 brrt i'm now stepping throuw the code to see wth is wrong
06:52 brrt omg, i'm seeing it, but i still don't get it :-o
07:09 brrt joined #moarvm
07:17 brrt i'm seeing it now
07:17 brrt i'm preparing the proper arguments, but passing them in the wrong order
07:17 brrt presumably due to the shuffling logic
07:17 brrt so
07:18 brrt the body is the STable
07:18 brrt the root is the array body
07:19 brrt and the st handle is the object including header
07:19 brrt *thank god it is a bug like this*
07:20 nwc10 I'm glad that it's less horrible than you first feared
07:20 nwc10 you fell off IRC too fast for me to suggest "go get coffee"
07:21 Geth ¦ MoarVM/even-moar-jit: 1f3c57544c | (Bart Wiegmans)++ | 4 files
07:21 Geth ¦ MoarVM/even-moar-jit: Introduce new test-against-constant tiles
07:21 Geth ¦ MoarVM/even-moar-jit:
07:21 Geth ¦ MoarVM/even-moar-jit: For quick flag checking. Reading the sequence of load memory, load
07:21 Geth ¦ MoarVM/even-moar-jit: const, binary and, and test zero was getting annoying. Uncovers new
07:21 Geth ¦ MoarVM/even-moar-jit: problems with elems (probably due to register shuffling?) so disabled
07:21 Geth ¦ MoarVM/even-moar-jit: that for the time being.
07:21 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/1f3c57544c
07:22 * nwc10 is now AFK for "go get wheelbarrow"
07:26 zakharyas joined #moarvm
07:28 brrt i'd gotten coffee even before i entered my commute
07:28 brrt i have one of those horrible/convenient coffee machines that just has you pop in some cups
07:29 brrt so making coffee in the morning is a managable endeavour
08:15 domidumont joined #moarvm
08:43 jnthn So is still on tea, though his guts are probably recovered enough from this week's gremlins to drink coffee again already...
08:43 yoleaux 18 May 2017 23:08Z <Zoffix> jnthn: should Blob.Stringy be dying (as it does right now)? We don't have any cases of .Numeric dying. .Stringy on `utf*` types coerces them to Str, which also feels wrongish. If we follow the Stringy for stringy is like Numeric for numerics, then .Stringy on all Blobs should just return `self`
08:49 zakharyas joined #moarvm
08:51 robertle joined #moarvm
08:57 nwc10 brrt: make s the coffee easy, but the compost hard?
08:58 brrt true
08:58 brrt it does
10:05 Geth ¦ MoarVM: 863e9205ae | (Jonathan Worthington)++ | 10 files
10:05 Geth ¦ MoarVM: Remove asyncwritestr op and supporting code.
10:05 Geth ¦ MoarVM:
10:05 Geth ¦ MoarVM: Deprecated and not used by Rakudo for a while.
10:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/863e9205ae
10:14 Geth ¦ MoarVM: 9d3ede0009 | (Jonathan Worthington)++ | 9 files
10:14 Geth ¦ MoarVM: Remove asyncwritestrto op and supporting code.
10:14 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9d3ede0009
10:28 Geth ¦ MoarVM: 5f23324971 | (Jonathan Worthington)++ | 10 files
10:28 Geth ¦ MoarVM: Remove asyncreadchars op and supporting code.
10:28 Geth ¦ MoarVM:
10:28 Geth ¦ MoarVM: Deprecated and unused by Rakudo for a while.
10:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5f23324971
10:28 jnthn That does a bit of housekeeping.
10:38 samcv nice
10:38 Geth ¦ MoarVM/sync-socket-no-uv: ca7de1752a | (Jonathan Worthington)++ | src/io/syncsocket.c
10:38 Geth ¦ MoarVM/sync-socket-no-uv: Remove encodable support from sync socket.
10:38 Geth ¦ MoarVM/sync-socket-no-uv:
10:38 Geth ¦ MoarVM/sync-socket-no-uv: This is a first step towards removing string I/O support from sync
10:38 Geth ¦ MoarVM/sync-socket-no-uv: sockets, which in turn will simplify re-implementing them without the
10:38 Geth ¦ MoarVM/sync-socket-no-uv: use of libuv. (Note that no work in this branch will be merged until
10:38 Geth ¦ MoarVM/sync-socket-no-uv: the corresponding Rakudo branch is merged, which will not be until
10:38 Geth ¦ MoarVM/sync-socket-no-uv: after the 2017.05 release.)
10:38 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/ca7de1752a
10:43 Geth ¦ MoarVM/sync-socket-no-uv: 71e8122bd0 | (Jonathan Worthington)++ | src/io/syncsocket.c
10:43 Geth ¦ MoarVM/sync-socket-no-uv: Remove seekable from sync sockets also.
10:43 Geth ¦ MoarVM/sync-socket-no-uv:
10:43 Geth ¦ MoarVM/sync-socket-no-uv: Only the tell part of it was implemented and even then it was not
10:43 Geth ¦ MoarVM/sync-socket-no-uv: used, and since it relies on DecodeStream then it would complicate
10:43 Geth ¦ MoarVM/sync-socket-no-uv: upcoming refactors.
10:43 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/71e8122bd0
10:59 Geth ¦ MoarVM/sync-socket-no-uv: 43cdeb4fef | (Jonathan Worthington)++ | src/io/syncsocket.c
10:59 Geth ¦ MoarVM/sync-socket-no-uv: Have string I/O ops on sync sockets throw.
10:59 Geth ¦ MoarVM/sync-socket-no-uv:
10:59 Geth ¦ MoarVM/sync-socket-no-uv: These functions will go away from the I/O tables in the future, once
10:59 Geth ¦ MoarVM/sync-socket-no-uv: other forms of sync I/O are all done in binary mode only at VM level.
10:59 Geth ¦ MoarVM/sync-socket-no-uv: For now, it helps with disentangling sockets from syncstream.
10:59 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/43cdeb4fef
11:05 timotimo brrt: any obvious problems with my two templates i posted?
11:06 brrt timotimo: i'm  bad at backlogging these days
11:06 timotimo ah, hehe
11:06 timotimo https://gist.github.com/timo/e7f7088cd82e2f7322b474fe59d10a84
11:07 timotimo as the gist says, one gives me a moarvm panic for "no inbound edges"
11:07 timotimo the other just doesn't seem to end up used at all
11:07 brrt actually timotimo, those look pretty much alright
11:08 brrt gethow gives you a no inboud edge error? okay
11:08 brrt i need to check that
11:09 timotimo cool :)
11:20 timotimo i was searching for "iter" in the jit subfolder and found registers typo'd as regsiters
11:24 brrt lol
11:24 brrt you can change that
11:25 timotimo should i wait for you to figure out gethow and iter? :)
11:29 AlexDaniel joined #moarvm
11:29 timotimo with bated breath
11:33 brrt well, you can try to debug it yourself, as well
11:33 brrt but frankly i'm still trying to figure out the elems breakager
11:34 brrt (i do have a reasonable theory wrt that, though)
12:33 KDr2_ joined #moarvm
12:41 Geth ¦ MoarVM/mutex_parameterization_add: 4cf22677a1 | (Timo Paulssen)++ | 3 files
12:41 Geth ¦ MoarVM/mutex_parameterization_add: protect the parameterization lookup list with a mutex
12:41 Geth ¦ MoarVM/mutex_parameterization_add:
12:41 Geth ¦ MoarVM/mutex_parameterization_add: addresses #554
12:41 Geth ¦ MoarVM/mutex_parameterization_add: review: https://github.com/MoarVM/MoarVM/commit/4cf22677a1
12:42 Geth ¦ MoarVM: timo++ created pull request #599: protect the parameterization lookup list with a mutex
12:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/599
12:43 Geth ¦ MoarVM/mutex_parameterization_add: 3399df06c7 | (Timo Paulssen)++ | 3 files
12:44 Geth ¦ MoarVM/mutex_parameterization_add: protect the parameterization lookup list with a mutex
12:44 Geth ¦ MoarVM/mutex_parameterization_add:
12:44 Geth ¦ MoarVM/mutex_parameterization_add: addresses #554
12:44 Geth ¦ MoarVM/mutex_parameterization_add: review: https://github.com/MoarVM/MoarVM/commit/3399df06c7
12:44 timotimo (comment fix forcepush)
13:42 Geth ¦ MoarVM/sync-socket-no-uv: 9c3bdfe6f1 | (Jonathan Worthington)++ | src/io/syncsocket.c
13:42 Geth ¦ MoarVM/sync-socket-no-uv: Duplicate syncstream functions into syncsocket.
13:42 Geth ¦ MoarVM/sync-socket-no-uv:
13:42 Geth ¦ MoarVM/sync-socket-no-uv: This is the first step towards pulling the two apart, in preparation
13:42 Geth ¦ MoarVM/sync-socket-no-uv: for syncsocket ceasing to use libuv.
13:42 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/9c3bdfe6f1
13:49 Geth ¦ MoarVM/sync-socket-no-uv: 3b1ac1c13c | (Jonathan Worthington)++ | src/io/syncsocket.c
13:49 Geth ¦ MoarVM/sync-socket-no-uv: Put sync stream struct members into socket struct.
13:49 Geth ¦ MoarVM/sync-socket-no-uv:
13:49 Geth ¦ MoarVM/sync-socket-no-uv: Completing the breakout of syncsocket from syncstream.
13:49 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/3b1ac1c13c
13:57 Geth ¦ MoarVM/sync-socket-no-uv: 3cec878c9c | (Jonathan Worthington)++ | src/io/syncsocket.c
13:57 Geth ¦ MoarVM/sync-socket-no-uv: Toss various unused struct members.
13:57 Geth ¦ MoarVM/sync-socket-no-uv:
13:57 Geth ¦ MoarVM/sync-socket-no-uv: Along the way starting to wean us off using the decode stream.
13:57 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/3cec878c9c
14:32 japhb OOC, why are you removing libuv from sync sockets?
14:34 jnthn japhb: Primarily because it's the cause of the "can't share them between threads" issue
14:35 jnthn (Because a libuv event loop lives on a single thread, and you can't move handles between loops)
14:35 * Zoffix baits with https://rt.perl.org/Ticket/Display.html?id=131306#ticket-history
14:35 Zoffix Such a fun ticket to fix!
14:35 Zoffix m: sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
14:35 camelia rakudo-moar 902fac: OUTPUT: «27071659120799␤229376␤»
14:35 Zoffix ^ supposed to give same values for both
14:35 japhb jnthn: Ah, gotcha.
14:36 jnthn Will fix it for all the sync handles, which will in turn deal with the not being about to read from $*IN from anything other than the main thread
14:37 jnthn But sockets were the easiest starting point
14:38 japhb Fair enough.
14:38 jnthn And also the one people trying to do multi-threaded web servers the non-IO::Socket::Async way tend to run into.
14:38 brrt joined #moarvm
14:39 japhb Is Uni input (from $*IN at least) on your current short list, or is that farther out?
14:39 japhb yeah, gotcha
14:39 jnthn Farther out
14:39 japhb OK, roger that.
14:41 jnthn Likely made easier by these refactors, however.
14:45 committable6 joined #moarvm
14:55 Geth ¦ MoarVM/sync-socket-no-uv: 87f2c02e52 | (Jonathan Worthington)++ | src/io/syncsocket.c
14:55 Geth ¦ MoarVM/sync-socket-no-uv: Eliminate the use of the decode stream.
14:55 Geth ¦ MoarVM/sync-socket-no-uv:
14:55 Geth ¦ MoarVM/sync-socket-no-uv: In doing so, introduce a simple 1-packet buffer in its place. In the
14:55 Geth ¦ MoarVM/sync-socket-no-uv: best case, programs will hit the no-memcpy path and the buffer we get
14:55 Geth ¦ MoarVM/sync-socket-no-uv: from the network will be handed straight on back to userspace after
14:55 Geth ¦ MoarVM/sync-socket-no-uv: being wrapped in an MVMArray. The buffer helps in cases where folks
14:55 Geth ¦ MoarVM/sync-socket-no-uv: do stuff like .read(1) on the socket to pull a byte off at a time.
14:55 Geth ¦ MoarVM/sync-socket-no-uv: review: https://github.com/MoarVM/MoarVM/commit/87f2c02e52
14:59 jnthn I think that gets all the preparatory refactors I can do to make the big step easier out of the way.
15:04 brrt we're doing the order of cycle breakage all wrong!
15:04 brrt i'm doing it wrong, at least
15:05 timotimo oh!
15:05 AlexDaniel joined #moarvm
15:07 committable6 joined #moarvm
15:08 timotimo all wrong, eh? time to use that "delete repository" button
15:13 brrt lol
15:13 brrt stuff isn't that bad just yet
15:17 brrt ah, i see it
15:17 brrt i build the stack in reverse order
15:17 brrt so say we have:
15:17 brrt a -> b -> c -> a
15:18 brrt well, what i have is that from a, c is inbound
15:18 brrt from c, b is inbound
15:19 brrt what i do is iterate backwards, from a to c, c to b, and i stop when c i s a
15:19 brrt no, hang on
15:20 brrt i stop when i see that the next thing is a
15:20 brrt anyway
15:20 brrt i end with a stack looking like: c, b, a (if a is even on there)
15:21 brrt now supposing i move a out of the way to t, i need to move c -> a, b to c, a to b
15:21 brrt actually, t to b
15:21 brrt so i need to iterate the stack 'upwards', rather than downwards
15:50 timotimo if it's that easy ... :)
15:50 timotimo just quite tricky to find i imagine
17:45 domidumont joined #moarvm
19:02 AlexDaniel joined #moarvm
19:06 Ven joined #moarvm
19:19 Ven_ joined #moarvm
19:51 zakharyas joined #moarvm
20:19 Ven joined #moarvm
20:31 Ven_ joined #moarvm
20:38 MasterDuke timotimo: any idea why adding `(template: gt_i (gt $1 $2))` to src/jit/core.expr would cause the NQP build to segfault (it doesn't segfault with that commented out)?
20:40 timotimo i haven't the slightest :)
20:41 MasterDuke valgrind if you're curious https://gist.github.com/MasterDuke17/001bda1864543bb3b2a1496f688da448
20:42 timotimo i know basically nothing about the code the exprjit is made out of
20:43 Ven_ joined #moarvm
20:44 Geth ¦ MoarVM: 3bcd19ee91 | (Jonathan Worthington)++ | docs/ChangeLog
20:44 Geth ¦ MoarVM: ChangeLog for 2017.05.
20:44 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3bcd19ee91
20:44 Geth ¦ MoarVM: cc390f5b29 | (Jonathan Worthington)++ | VERSION
20:44 Geth ¦ MoarVM: Bump VERSION.
20:44 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cc390f5b29
20:45 jnthn Checking of that welcome
20:45 jnthn timotimo: Especially from you; if you want more/differnet notes on telemeh in there tweak awa
20:45 jnthn *away
20:51 timotimo we could point out that the line number info in spesh is mostly good for the line coverage
20:52 jnthn Yeah, I was looking at the patch and it seemed exception reports don't bonefit yet?
20:52 jnthn *benefit
20:53 timotimo oh, i don't think so
20:53 timotimo i didn't realize we'd have trouble with that at all
20:54 jnthn Yeah, we do :)
20:54 jnthn And you've done a chunk of the work to fix it, it turns out ;)
20:55 timotimo that's nice, i can look into the rest of that soon
20:55 Geth ¦ MoarVM: 9c1762636c | (Jonathan Worthington)++ | docs/ChangeLog
20:55 Geth ¦ MoarVM: Mention spesh position info is used for coverage.
20:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9c1762636c
20:55 jnthn Cool :)
20:55 jnthn timotimo++
20:56 jnthn Anything else, or shall I go for release?
20:57 timotimo we could already merge the mutex for parameterization
20:57 timotimo so we can at least not get the segv in that spec test
20:57 Zoffix If the bug disappears with MVM_SPESH_DISABLE does it mean it's somewhere in src/spesh/ code?
20:57 timotimo not necessarily
20:57 Zoffix ok
20:57 timotimo it could also be a bug in the jit
20:57 timotimo because when you disable spesh, it'll turn off the jit, too
20:58 Zoffix MVM_JIT_DISABLE doesn't remove the bug tho
20:58 Zoffix m: sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
20:58 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤229376␤»
20:58 Zoffix ^ that bug
20:58 timotimo it might have something to do with inline or osr
20:58 Zoffix hm
20:58 timotimo so you can check those separately, too
20:59 Zoffix yeah, OSR = still bug; INLINE = no bug
20:59 timotimo cool.
20:59 timotimo also: oh no
20:59 jnthn That gets it down to inlining then :S
21:00 timotimo we're not handling stuff like unsignedness across inlines?
21:00 timotimo we should just be memcpy-ing flags around, though
21:00 jnthn Yeah, not sure it'd need special handling
21:01 jnthn I wonder if it's the inlining of rotr itself, of the inlining of things inside of rotr
21:02 jnthn m: sub rotr(uint32 $n, uint32 $b) { my $ignore = nqp::ctx(); $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:02 camelia rakudo-moar a61746: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Could not find nqp::ctx, did you forget 'use nqp;' ?␤at <tmp>:1␤------> $n, uint32 $b) { my $ignore = nqp::ctx()⏏; $n +> $b +| $n +< (32 - $b) }; say rot␤»
21:02 jnthn m: use nqp; sub rotr(uint32 $n, uint32 $b) { my $ignore = nqp::ctx(); $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:02 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤229376␤»
21:02 Zoffix m: my $x; for ^1000 { my uint32 $n = 1652322944; my uint32 $b = 18; $x = $n +> $b +| $n +< (32 - $b) }; say $x
21:02 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤»
21:02 jnthn Looks like the inlining of +> or +| or +< itself
21:03 jnthn m: use nqp; sub rotr(uint32 $n is rw, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:03 camelia rakudo-moar a61746: OUTPUT: «Expected a modifiable native int argument for '$n'␤  in sub rotr at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
21:03 jnthn ah, right
21:06 MasterDuke m: my $x; my uint32 $n = 1652322944; my uint32 $b = 18; for ^1000 { $x = $n +> $b +| $n +< (32 - $b) }; say $x
21:06 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤»
21:07 Zoffix m: sub rotr(int $n, int $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:07 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤27071659120799␤»
21:07 Zoffix m: sub rotr(int32 $n, int32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:07 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤229376␤»
21:07 Zoffix m: sub rotr(int64 $n, int64 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:07 camelia rakudo-moar a61746: OUTPUT: «27071659120799␤27071659120799␤»
21:07 Zoffix Something with the 32 size?
21:08 jnthn Certainly the program relies on promotion from 32-bit to get the correct result
21:09 jnthn Though we're meant to do computation in 64-bit wide and then nothing should be narrowing it again in this code
21:10 jnthn m: sub rotr(int32 $n, int32 $b) { $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:10 camelia rakudo-moar a61746: OUTPUT: «27071659114496␤27071659114496␤»
21:10 jnthn m: sub rotr(int32 $n, int32 $b) { $n +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:10 camelia rakudo-moar a61746: OUTPUT: «27073309340288␤27073309340288␤»
21:10 jnthn m: sub rotr(int32 $n, int32 $b) { ($n +> $b) +| $n }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:10 camelia rakudo-moar a61746: OUTPUT: «1652325023␤1652325023␤»
21:11 jnthn m: sub rotr(int32 $n, int32 $b) { ($n +> $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
21:11 camelia rakudo-moar a7c23a: OUTPUT: «6303␤6303␤»
21:11 jnthn Doesn't seem keen to be golfed further...
21:15 jnthn Zoffix: Is this a release blocker at all? I'm not sure I've the energy to investigate/fix it tonight. Tomorrow maybe.
21:15 Zoffix m: sub rotr(int32 $n = 10, int32 $b = 33000000000000) { $n  +< $b }; my $y = rotr; my $x; for ^1000 { $x = rotr }; say $x == $y
21:15 camelia rakudo-moar a7c23a: OUTPUT: «False␤»
21:16 Zoffix jnthn: not really, I have a workaround for it by undoing a bug fix
21:17 Zoffix Basically putting back this bug: https://rt.perl.org/Ticket/Display.html?id=126942
21:17 Zoffix (which we already had in last releease)
21:17 Zoffix Oh wait, I mean this one: https://rt.perl.org/Ticket/Display.html?id=131278
21:17 Zoffix m: my $i = -0x8000000000000000; say ($i div 2**23) == ($i +> 23) ?? 'good' !! 'bad';
21:17 camelia rakudo-moar a7c23a: OUTPUT: «good␤»
21:17 Zoffix m: my $i = -0x8000000000000000; say ($i div 2**33) == ($i +> 33) ?? 'good' !! 'bad';
21:17 camelia rakudo-moar a7c23a: OUTPUT: «good␤»
21:17 Zoffix m: my $i = -0x8000000000000000; say ($i div 2**43) == ($i +> 43) ?? 'good' !! 'bad';
21:17 camelia rakudo-moar a7c23a: OUTPUT: «good␤»
21:18 Zoffix Oh right. Well, the undoing will make the last two say bad
21:40 jnthn Zoffix: Would you prefer to wait and see if I can fix it tomorrow, or should I go ahead with the release?
21:41 Zoffix jnthn: up to you. I'm leaning towards release now.
21:42 jnthn OK. I don't think this is a MoarVM regression, rather than something streamlined code in Rakudo has exposed.
21:42 jnthn Totally agree it wants fixing.
21:43 jnthn But it's probably better to put in a carefully considered fix for an inlining related bug than try and rush one in.
21:43 jnthn That code is...complex.
21:43 MasterDuke joined #moarvm
21:43 Zoffix Yeah
21:43 jnthn Alright, I'll tag and upload
21:43 Zoffix \o/
21:47 jnthn I can't believe bash tab completion works for SCP remote paths
21:47 jnthn <3 to whoever did the work to make that happen
21:47 japhb jnthn: Yeah I seriously <3 that feature
21:47 jnthn I discoverd it totally by accident
21:48 jnthn Yet another reason to do keys not passwords :)
21:48 jnthn https://www.moarvm.org/releases/MoarVM-2017.05.tar.gz
21:48 Zoffix w00t
21:49 jnthn Tag pushed also
21:56 Ven joined #moarvm
22:43 Ven joined #moarvm
22:44 jnthn I'll do the website tomorrow; sleep time now o/
22:45 Zoffix night
23:06 Ven_ joined #moarvm
23:24 Ven_ joined #moarvm
23:40 Ven joined #moarvm

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