00:02 Ven joined 00:35 Ven joined 00:55 Ven joined 01:15 Ven joined
timotimo i wonder if we should ever try ubsan on moarvm 01:23
01:35 Ven joined 02:19 Ven joined 02:49 Ven joined 03:18 Ven joined 03:34 Ven joined 03:52 Ven joined 04:13 Ven joined 04:23 Ven joined 04:37 Ven joined 04:53 Ven joined 06:04 Ven joined 06:24 Ven joined 06:34 Ven joined 07:10 domidumont joined 07:15 domidumont joined 07:47 avar joined 07:51 jnthn_ joined 08:32 BinGOs joined 08:36 zakharyas joined
Geth arVM/even-moar-jit: f94803bca2 | (Bart Wiegmans)++ | 2 files
linear_scan depends on arch.h

linear_scan.c needs a recompile whenever arch.h is changed because it defines a static array based on its contents.
The jit-comparify tool skipped 'add' opcodes because they can be interpreted as hexadecimal. Made that check more strict, now it doesn't.		 10:02
timotimo haha, "add" 10:05
very good
10:59 geekosaur joined
Geth arVM/master: 4 commits pushed by jnthn++ 13:17
timotimo yay 13:18
jnthn wonders why the … after each one :)
timotimo good Q 13:19
Geth: source 13:20
Geth timotimo, Source at github.com/perl6/geth To add repo, add an 'application/json' webhook on GitHub pointing it to geth.perl6.party/?chan=#perl6 and choose 'Send me everything' for events to send | use `ver URL to commit` to fetch version bump changes
timotimo sub make-short-commit-message ($c, $e) {
"$c.sha.substr(0, 10) | &Δ(:style<bold>, $c.title)…"
it just puts that in there
the delta there is just irc-style-text 13:21
nothing special there
brokenchicken To show there may be more text :) 13:29
I guess it can go... 13:30
13:45 lizmat joined
jnthn starts release prep for MoarVM 2017.01 13:48
13:48 lizmat_ joined
brokenchicken \o/ 13:49
timotimo it can definitely stay if it shows that there is actually more text 13:54
would it be able to, without firing more API requests off?
brokenchicken yeah 13:59
14:04 Ven joined
Geth arVM: 0b81cf6d8e | (Jonathan Worthington)++ | docs/ChangeLog
Changelog for 2017.01.
 14:09
jnthn Really nice work this month
Geth arVM: 0c8b770f5a | (Jonathan Worthington)++ | VERSION
Bump VERSION.
 14:10
jnthn Will do release in an hour or so; hopefully I did no mistakes in ChangeLog, but feel free to check :) 14:11
timotimo + a file in UTF-8 file 14:17
:)
only one i spotted 14:18
Geth arVM: c4b45d71e4 | (Timo Paulssen)++ | docs/ChangeLog
fix a changelog line
 14:19
jnthn timotimo++ 14:23
timotimo wait a minute 14:24
MVMROOT was needed to generational violations?
wouldn't that be MVM_ASSIGN?
jnthn oh..
timotimo ASSIGN_REF
jnthn Yeah
It's to avoid outdated pointres :) 14:25
You tweaking or shall I?
timotimo please do 14:26
Geth arVM: 8c45c9d893 | (Jonathan Worthington)++ | docs/ChangeLog
Fix a change description; timotimo++.
 14:32
jnthn Wow, didn't realize make of NQP was 92188maxresident 14:33
Always assuemd it needed over 100MB 14:34
Or even 200
timotimo :D
nqp is surprisingly good
compared to rakudo, that is
jnthn Maybe that was another win from the ->work lifetime 14:35
Spectest clean on MoarVM HEAD, so looking good 14:45
diakopter clang gives some warnings 14:56
timotimo my gcc gives me a firehose of warnings (but it's always the same warning) 14:57
jnthn There's a PR to fix some warnings; will merge post-relesae 15:01
16:05 domidumont joined 16:14 brrt joined
brrt good * #moarvm 16:14
timotimo good
brrt so
i've noticed both errors in three-to-two-operand conversion, *and* spill/load inversions 16:15
😂
so, in other words 16:16
the fact that the expr JIT gave the correct results so far was down to pure dumb luck
and compiling really small fragments 16:17
timotimo oh?
wow.
Geth arVM: d7e286b3e6 | TimToady++ | src/6model/reprs/NFA.c
Revert "Allow for fate offsets when unique fates in use"

This reverts commit e167934e83ddebdd6a685193cd9758f56f73f809. Gonna use a different approach eventually, which needs to be figured out in a branch.
brrt :-)
i'm going to see if i can fix the inversions first 16:18
16:21 donaldh joined
jnthn TimToady: Heh, just sneaked that revert in in time for me to include it in the release :) 16:21
timotimo brrt: "both errors" sounds like there's only two errors all in all :P 16:23
brrt well, i expected two different kinds of errors, and was kind of worried that i wouldn't be able to figure out which was which 16:26
but the disassembly made it sufficiently clear
Geth arVM: 5971948a13 | (Jonathan Worthington)++ | docs/ChangeLog
Remove removed commit from ChangeLog.
arVM/even-moar-jit: e6fdb10f14 | (Bart Wiegmans)++ | src/jit/linear_scan.c
Fix spill/load inversion failure

In case we spill a value just before we load it, then (aside from the fact that the load is redundant) we should take some care not to swap that order, lest we overwrite our value with nonsense. There is a mechanism for that and now I've activated it.		 16:33
brrt nb, we're still seeing three-op failures 16:34
might as well try to resolve these now 16:37
jnthn Release tagged and uploaded: www.moarvm.org/releases/MoarVM-2017.01.tar.gz 16:40
brokenchicken \o/ 16:58
jnthn++
17:05 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Fix a change description; timotimo++.' 17:05
travis-ci.org/MoarVM/MoarVM/builds/193755617 github.com/MoarVM/MoarVM/compare/c...45c9d89382
17:05 travis-ci left
brokenchicken that one is "Found /tmp/moar/bin/moar version 2016.12-137-g8c45c9d, which is too old." 17:23
18:21 ggoebel joined 18:25 FROGGS joined 18:59 zakharyas joined 19:04 geekosaur joined 19:12 brrt joined
dalek href="https://moarvm.org:">moarvm.org: 31070b5 | jnthn++ | / (3 files):
Update for MoarVM 2017.01 release.
 19:36
19:37 brrt joined
jnthn www.moarvm.org/ updated \o/ 19:37
brrt \o/
jnthn++
jnthn Nice release \o/
brrt believes he has introduced a memory leak
or an infinite loop or something like that
jnthn Congrats :P 19:44
brrt hmm yeah 19:47
usually the jit bisector can find the problem it, but that may be a bit harder now
is there a unix program that runs a command with a timeout
i mean, simple enough to write, just a matter of signal handling 19:48
Geth arVM/even-moar-jit: 349b3605d1 | (Bart Wiegmans)++ | 3 files
Try to resolve two-operand code

A reserved register (rax) is used as scratch space for transforming three-operand code to two-operand code as required by x86.
This or some earlier commit seem to introduce a memory leak + infinite loop in the rakudo build process.		 19:49
jnthn brrt: timeout
brrt yeah, not an os x thing unfortunately. 19:51
no matter
i'll figure it out at some point :-)
jnthn Aww
I already had it installed :)
oh, apparently from coreutils package or some such 19:52
So not standard UNIX-y thing.
brrt coreutils is rather awesome
it can be homebrewed apparently
jnthn Oh, quick googling suggests you can installed with homebrew
brrt well, i'll have a look at it later
^ the commit above does resolve some real issues though, so i'm happy about at least that 19:54
have a nice weekend :-)
jnthn Thanks, you too, brrt++
timotimo oooh, -fsanitize=object-size reads kind of interesting 20:23
-fcheck-pointer-bounds is what you need to get MPX turned on (it also requires you to use -mmpx and to also put that in the linker flags, and it'll link against two run time libraries) 20:31
-finstrument-functions will give every function call an extra call to __cyg_profile_func_enter and __cyg_profile_func_exit which both get a pointer to the function and a pointer to the position that makes the call passed 20:38
src/jit/graph.c:1452:22: runtime error: member access within misaligned address 0x0000019346f2 for type 'struct MVMSpeshIns', which requires 8 byte alignment 20:45
that happens a whole, whole lot
same for MVMSpeshFacts
src/core/validation.c:250:23: runtime error: load of misaligned address 0x7f11981232be for type 'MVMuint32', which requires 4 byte alignment 20:46
more interesting
src/6model/serialization.c:2411:50: runtime error: left shift of 4095 by 20 places cannot be represented in type 'int'
src/core/interp.c:1722:37: runtime error: load of misaligned address 0x7f11981232ce for type 'MVMuint32', which requires 4 byte alignment
22:15 ggoebel joined
jnthn Alignment rules vary by platform. 22:20
We have probes for that
And spesh alloc conditionally does stuff alignment as needed 22:21
Bytecode reading does similar things
timotimo that's curious. why wouldn't ubsan understand?
jnthn Well, from a C perspective, it *is* undefined behavior in that you're gonna get SIGBUS or whatever on some platforms if you do it. 22:22
timotimo oh, hm. but i did -march=native
jnthn Hmm
And ubsan pays attention to that?
timotimo i have no idea :) 22:23
jnthn If we add ubsan support to configure we can twiddle the alignment flags 22:25
geekosaur it may not pay attention to CPU flags... there's a flag that enables/disables unaligned memory access on x86 class cpus
(and they default to unaligned access disabled at boot time, but linux at least re-enables it because too much software broke with the default) 22:26
timotimo right, i could set that and get less explosive output
oh?
is it a performance penalty, though?
geekosaur significant one, yes
CPU has to do multiple reads for unaligned data 22:27
timotimo hmm
doesn't that mean we ought to set "we can't do unaligned reads" on x86 adn x86_64? 22:29
to make stuff faster?
jnthn It's not quite that clear cut, though
Data packed tighter together means better cache hit rate
timotimo like, if we do linear reads through a lot of stuff? 22:30
jnthn So yeah, it's a slowdown, but missing the L1/L2 is an even slowerdown
timotimo understood 22:31
jnthn (If anyone has data to contradict that, I'd be happy to see it, of course. But "afaik" :))
timotimo jnthn, S17-supply/syntax.t is the right place for next and last and such tests? 22:35
jnthn Very much so 22:37
Will look at that PR over weekend hopefully...today got zoned in to working on the await refactors
timotimo i'm glad to see nonblock-await getting worked on :) 22:38
last and redo for supply syntax can wait another release
syntax.t uses Interval(0.001) :P 22:39
multiple times
i might fix that to be 0.01 instead
jnthn Uh
At lesat one of the cases is covering an RT that reported a problem when you wrote 0.001 :)
(We used to round it to zero, pass that to libuv, and it took it to mean we didn't want any callbacks) 22:40
timotimo right, that was bad
i remember you fixing that
jnthn Yeah, what I committed is the third design. First one didn't get the optimization for the case the result is already available in place. Second one tried to address that but was racey without introducing more locking than I wanted. Third appraoch finally go that case cheap and unracey :) 22:41
*got
timotimo RT #128991 test has such a low interval
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128991
jnthn (that's about await)
timotimo don't actually see if that's because the interval was rounded down or not 22:42
yes, that sounds pretty good :) 22:43
third time's the charm
dang, cat has laid itself down next to me and is presenting belly to receive rubs 22:48
jnthn Smart cat :)
timotimo ok 70 - calling "next" inside a whenever block will not die. 22:51
simplest tests gotted 22:52
jnthn :) 22:56
Rest time; 'night o/ 23:15
timotimo night jnthn! 23:17
23:41 MasterDuke joined
MasterDuke webkit.org/blog/7122/introducing-r...collector/ was an interesting read 23:42
the moar gc is concurrent, but not yet parallel, correct? 23:43
timotimo no, it's parallel, but not concurrent 23:44
i.e. stop the world (not concurrent), but every thread rummages through objects it owns (parallel)
wait ...
i could be wrong here
MasterDuke it's kind of crazy that they can assume multiple cores for the hardware they run on. who would have suspected phones would have 4-8cores so quickly? 23:45
timotimo yeah, it's a bit surprising 23: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!