00:33 evalable6 joined 01:56 ilbot3 joined
Geth MoarVM: MasterDuke17++ created pull request #734:
If dividing by 1, just return the numerator		 03:05
03:25 lizmat joined 06:21 evalable6 joined 06:40 domidumont joined 06:45 domidumont joined 06:47 domidumont joined
Geth MoarVM: b73edfa4b3 | (Samantha McVey)++ | 6 files
Include the type of unhandled register in error messages

Added better errors for CStruct, MVMiter, VMArray, and frame.c Example: Unhandled lexical type 'int8' in lexprimspec for '$var' Before: Unhandled lexical type in lexprimspec for '$var'		 07:13
MoarVM: 7d666c203c | niner++ (committed using GitHub Web editor) | 6 files
Merge pull request #732 from samcv/lexical_type

Include the type of unhandled register in error messages
07:50 zakharyas joined 07:55 zakharyas joined 08:10 Ven joined 08:48 brrt joined 10:53 brrt joined
dogbert2 jnthn: how was the vacation? 11:43
timotimo github.com/perl6/roast/blob/master...ixin.t#L20 - to be able to reconcile this test with an Int cache we'd have to add a candidate for "does" that takes its target "is rw" and for the rebless op to return the result rather than only modify its target 12:03
yoleaux 02:05Z <Zoffix> timotimo: you commited the original commit. Would you double check that the change propagated to other native array types is OK and doesn't harm anything: github.com/rakudo/rakudo/commit/f3b497c85e
timotimo another idea i had for implementing this was to only take objects from the cache if the STable still matches, i.e. having "does"ed an Int that came from the cache would not influence what comes out of the cache in the future 12:09
it will, however, still impact every instance of that object that has been taken out before
jnthn dogbert2: Nice food, nice beer, nice place :) 12:16
timotimo yay :)
12:35 Ven joined
dogbert2 but no smelly cheese :-) 12:41
brrt good * #moarvm 12:49
14:02 zakharyas joined 14:06 zakharyas joined
dogbert2 jnthn: I sometimes get a SEGV at github.com/MoarVM/MoarVM/blob/mast...ard.c#L411 due to 'test' being null. Is there some ('test' retrieving) statement missing there? 15:01
timotimo dogbert2: can you figure out what arg guard it crashes for? the spesh log outputs them 15:03
jnthn No, it's normally because something pokes a real NULL into a register, when that should never happen
timotimo oh, that's a good point
jnthn I don't want to NULL-test things in the arg_guard; that's just sweeping the problem under the carpet 15:04
And means we'll get more of them
15:04 brrt joined
dogbert2 to get the SEGV I run this for a few seconds: while MVM_SPESH_NODELAY=1 ./perl6 t/spec/S12-attributes/undeclared.t; do true; done 15:04
jnthn (Not to meniton slowing arg guard evaluation down)
timotimo you could set a break point in SPESH_GUARD_OP_LOAD_ARG conditional on whether test comes back null or ont
dogbert2 I can try 15:05
15:07 zakharyas joined
dogbert2 timotimo: yes, the test comes back null 15:10
timotimo now you can check out which argument it is, what other arguments are in the args array, ... 15:11
also, what the caller is, etc
dogbert2 tries 15:12
timotimo see if MVM_dump_bytecode(tc) does anything helpful 15:16
(it's full of off-by-ones though)
dogbert2 timotimo: gist.github.com/dogbert17/00cb2c89...f4a97d70aa 15:20
timotimo do you have a backtrace for that? 15:21
dogbert2 not yet :-)
timotimo i find it surprising to have it die inside the actions file?
could it be running multiple evals in parallel or something?
gtg 15:24
Geth MoarVM: 9c97cd72aa | (Stefan Seifert)++ | 3 files
Fix JITed nativeinvoke accessing wrong arg registers

The code blindly assumed that the native function's arguments are in the WORK register corresponding to the argument number which worked by conincident. Changes in the generated function body can thwart this assumption leading to wrong values getting passed to the native function.
Fix by using the information from arg_ins instead.		 16:25
nine Quite a surprise that it worked so well
16:29 zakharyas joined 17:04 zakharyas joined 17:09 ilmari joined 17:33 domidumont joined 17:44 Ven joined
dogbert17 timotimo: is the information we're interested in still present when the SEGV occurs? 18:13
here's what I have: gist.github.com/dogbert17/6257f2d6...b260ef8a29 18:16
18:28 Ven_ joined
Geth MoarVM: ugexe++ created pull request #735:
Don't throw exception for EINTR when writing to fd		 19:03
19:15 Ven joined 19:26 Ven_ joined
samcv good * all 19:34
yoleaux 18:37Z <AlexDaniel> samcv: let me know when you're here
AlexDaniel o/ 19:51
nine Oh, it looks like I found the error in Str arg handling of JITed native calls. Or at least one error. 19:53
AlexDaniel nine: should we wait then? 19:54
how serious is it?
nine AlexDaniel: I've already reverted the patch for implementing Str arg handling. This can wait. 19:55
AlexDaniel ah okay
cool
now I remember :)
19:58 Ven joined
nine And with that I've got confirmed working "is rw" support for ints (which is what Inline::Perl5 needs) and with that a JIT compiled p5_call_method which gives another nice speedup :) 20:13
But more on that tomorrow
Geth MoarVM: 1c75e5cea3 | (Nick Logan)++ (committed using GitHub Web editor) | src/io/syncfile.c
Don't throw exception for EINTR when writing to fd

Fixes `Failed to write bytes to filehandle: Interrupted system call` when running:
  `strace perl6 -e 'while 1 { use nqp; my $s := $*SCHEDULER; my $c := nqp::list("echo", "-n", q||); my $e := CLONE-HASH-DECONTAINERIZED %*ENV; await ^500 .map: { start nqp::spawnprocasync($s.queue, $c, "/", $e, nqp::hash()) }; print "." }'`		 20:52
MoarVM: ea47c93d64 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/io/syncfile.c
Merge pull request #735 from ugexe/patch-3

Don't throw exception for EINTR when writing to fd
samcv nine, should i push my tag or no? 21:20
or do it with that commit. seems that may be important?
Zoffix samcv: which commit? The one about JIT? nine++ said "I've already reverted the patch for implementing Str arg handling. This can wait." 21:30
samcv no the one that just got pushed
Zoffix Oh
No idea
samcv it's fine i'm gonna include that
21:33 evalable6 joined
jnthn oh, didn't think about ongoing release... 21:36
But yeah, it's safe IMO
MasterDuke jnthn: re my div_I PR and Int.new. should we create a box_I (or something like it) so Int.new doesn't have to (ab)use a side effect of div_I? 21:40
samcv ok release is done 21:45
AlexDaniel yay! samcv++
samcv and tag is signed. didn't sign by default so i had to delete it. but it looks like it didn't trigger when i pushed the commits so hopefully none of the bots got the new tag 21:46
well i interupted the git push, so that's probably why
the tag appeared on github site, but then i deleted it right after, and geth didn't show that i pushed any commits at all 21:47
updating the release instructions
do we want to start signing all the moarvm tags? 21:48
AlexDaniel sure? 21:49
Geth MoarVM: 213fc77426 | (Samantha McVey)++ | docs/release_guide.md
Update the release guide
AlexDaniel samcv: maybe it should suggest "$(date '+%Y.%m')" 21:51
or maybe we should automate it…
jnthn MasterDuke: Thing is, an _I thingy is already boxed 21:52
samcv AlexDaniel, maybe... i guess. there's only a few steps really
MasterDuke right, rebox_I?
jnthn coerce_II mebbe
If we want to follow the pattern we already have for those...well, provided I remember the pattern correctly
samcv i'd only be ok with that if it asked you before doing each step
ugexe fwiw with or without that last PR the code example it contains, sans strace, always runs ~800 iterations before eeking out 1-3 more iterations really slow, after which point it seems to be deadlocked 21:53
22:02 brrt joined
samcv jnthn, so how do i go about uploading it and such 22:47
jnthn samcv: Hm, thought I told you that? :) I certainly gave you access to do it... Just commit it here: github.com/MoarVM/moarvm.org/tree/...r/releases 22:48
Changes are automatically pulled every minute
So within a minute of your push it'll be released 22:49
samcv++ # first person to do a MoarVM release
samcv ok
jnthn (I was zeroth, of course ;))
samcv heh 22:50
23:14 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Merge pull request #735 from ugexe/patch-3 23:14
travis-ci.org/MoarVM/MoarVM/builds/293356962 github.com/MoarVM/MoarVM/compare/9...47c93d6437
23:14 travis-ci left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!