Time |
Nick |
Message |
00:57 |
|
patrickz_ joined #moarvm |
00:59 |
|
evalable6 joined #moarvm |
02:58 |
|
ilbot3 joined #moarvm |
02:58 |
|
Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at http://irclog.perlgeek.de/moarvm/today |
05:06 |
|
wander joined #moarvm |
06:04 |
|
releasable6 joined #moarvm |
06:04 |
|
greppable6 joined #moarvm |
06:05 |
|
squashable6 joined #moarvm |
06:29 |
|
BinGOs joined #moarvm |
07:18 |
|
domidumont joined #moarvm |
07:23 |
|
domidumont joined #moarvm |
07:27 |
|
geospeck joined #moarvm |
07:35 |
|
reportable6 joined #moarvm |
08:09 |
|
brrt joined #moarvm |
08:25 |
|
lizmat joined #moarvm |
08:26 |
brrt |
good * #moarvm |
09:01 |
|
lizmat joined #moarvm |
09:29 |
|
brrt joined #moarvm |
09:50 |
|
geospeck joined #moarvm |
09:56 |
jnthn |
morning o/ |
09:56 |
yoleaux |
09:38Z <lizmat> jnthn: is there a reason we don't have a nqp::split_s that generates a list_s rather than a list ? |
09:56 |
yoleaux |
09:40Z <lizmat> jnthn: is there a reason why we don't have a Failure.throw method ? |
09:56 |
lizmat |
jnthn: morning! |
09:56 |
nwc10 |
good *, jnthn |
09:58 |
jnthn |
No split_s simply because at a Perl 6 and NQP level, we expect boxed strings, so may as well just get an appropriate result back right away |
09:59 |
dogbert2 |
good morning jnthn, nwc10, lizmat and brrt |
09:59 |
lizmat |
well, I can point at some situations where a list_s would have been nice, e.g. in Str.split |
10:00 |
jnthn |
Str.split is meant to return Str though? |
10:00 |
jnthn |
Well, a bunch of 'em, but still |
10:00 |
lizmat |
yes, it is, but if you're using multiple needles |
10:02 |
* lizmat |
checks her reasoning again |
10:04 |
lizmat |
hmmm.... must have been a brainfart I wrote down last night while being offline on the ferry |
10:04 |
lizmat |
second question: re Failure.throw |
10:05 |
lizmat |
is there a reason for it not existing ? |
10:05 |
jnthn |
Lack of need (thus far)? :) |
10:06 |
jnthn |
If you want to throw Failures returned into a given lexical scope, there's use fatal, which saves the boilerplate of checking if the thing is a Failure |
10:07 |
brrt |
good * lizmat, jnthn, nwc10, dogbert2 |
10:07 |
jnthn |
.sink is a letter shorter and also does the job |
10:07 |
lizmat |
no, it's more for internal usage: try something, if it is a Failure, throw the exception of the Failure now |
10:07 |
jnthn |
And that can't be solved by use fatal? |
10:08 |
lizmat |
hmmm.. use fatal in core setting ? |
10:09 |
jnthn |
Every single try block implicitly has a "use fatal" at the top of it |
10:09 |
jnthn |
And we have a lot of try blocks in the setting ;) |
10:09 |
lizmat |
true |
10:10 |
lizmat |
anyways, it looks to me that there are several cases of Failure.throw in the setting, and the only reason that works is that FALLBACK throws |
10:10 |
jnthn |
hehe :) |
10:11 |
jnthn |
I was thinking, won't it already do that anyway :) |
10:11 |
lizmat |
I know that .sink is one char less, but this is more about readability |
10:11 |
jnthn |
True, otoh, .exception.throw is readable also |
10:12 |
jnthn |
But since .throw already works from FALLBACK... :) |
10:12 |
lizmat |
meh |
10:13 |
lizmat |
by that reasoning we could also remove Failure.CALL-ME and Failure.STORE |
10:15 |
jnthn |
True :) |
10:16 |
jnthn |
Actually it's easier to argue from an introspection angle that an explicit .throw is far more justified than either of those two |
10:20 |
jnthn |
(Since .throw is something you can do on a Failure, while CALL-ME and STORE are things you *can't* do :)) |
10:20 |
lizmat |
ok |
10:21 |
jnthn |
Anyway, sounds like it's just making explicit something that's already happening |
10:21 |
jnthn |
So no real objections |
10:21 |
jnthn |
Other than "there's usually a better way" |
10:22 |
dogbert2 |
are there any easy optimization wins left in MoarVM or will things get horribly difficult from now on? |
10:23 |
lizmat |
from what I understand, there's a lot of grunt work laying around re JITting stuff |
10:24 |
dogbert2 |
interesting |
10:28 |
lizmat |
brrt would know more |
10:29 |
dogbert2 |
perhaps he's optimizing/JITing as we speak :) |
10:29 |
jnthn |
There's still plenty of wins to be had; it depends how one defines "easy" :) |
10:30 |
dogbert2 |
say "easier" than the thing you did last week :) |
10:30 |
evalable6 |
dogbert2, rakudo-moar 76158136f: OUTPUT: «(exit code 1) ===SORRY!=== Error while compiling /tmp/EEl3Ls_VhiTwo ter…» |
10:30 |
evalable6 |
dogbert2, Full output: https://gist.github.com/2cabbe83d8814e05a3041ab1ef208500 |
10:30 |
dogbert2 |
heh |
10:33 |
jnthn |
There's easier than that, surely :) |
10:38 |
lizmat |
jnthn: a Failure.STORE is needed because Failure is Nil and there's a Nil.STORE |
10:41 |
jnthn |
Ah, ok :) |
11:57 |
brrt |
hey, yes, many things left to do |
11:57 |
brrt |
i haven't had much time last few weeks |
12:47 |
timotimo |
brrt: there was a spesh bisect script, wasn't there? i couldn't find one in tools/ and jit-bisect doesn't seem to support spesh limits |
12:47 |
brrt |
there wasn't a spesh bisect script yet, no |
12:47 |
brrt |
so |
12:47 |
brrt |
seems like a plan to make one |
12:48 |
timotimo |
that'd be nice |
12:48 |
timotimo |
i've got a patch that makes PHI nodes have no more duplicate entries for reads, but it causes -e "say 'hi'" to die with "No exception handler located for catch" :\ |
12:48 |
brrt |
well |
12:48 |
timotimo |
looks like that happens at the very end of command_eval, maybe |
12:48 |
brrt |
lemmethink |
12:49 |
brrt |
can we force the spesh limit on the basic block as well? |
12:49 |
brrt |
anyway |
12:50 |
timotimo |
i don't think we can, but it'd be good enough if it just gave me the frame |
12:50 |
brrt |
okay |
12:50 |
brrt |
i'll whip something up |
12:50 |
timotimo |
i'm glad, especially since it'd have to be in perl5 which i don't write :) |
12:51 |
|
Util joined #moarvm |
12:52 |
timotimo |
i'm now assuming that the problem comes from usage counts not being messed up by wrong phi nodes |
12:52 |
timotimo |
and something gets thrown out as unused code even though it shouldn't have been |
12:52 |
|
lizmat joined #moarvm |
12:55 |
timotimo |
also, can't compile nqp with spesh on because it hangs :\ |
13:00 |
timotimo |
found the right spesh limit for t/nqp/003-if-else.t to hang |
13:00 |
timotimo |
it's 34 |
13:03 |
|
geospeck joined #moarvm |
13:14 |
timotimo |
aha, here's a difference |
13:14 |
timotimo |
now let's see if the difference makes much sense |
13:16 |
timotimo |
yeah, it kicks out a sub_i instruction, that can definitely cause a loop to hang |
13:17 |
brrt |
aha |
13:17 |
|
scovit joined #moarvm |
13:17 |
brrt |
well, if you debug it before i get to finish the script :-P |
13:58 |
|
geospeck joined #moarvm |
15:42 |
|
geospeck joined #moarvm |
15:52 |
|
geospeck joined #moarvm |
16:06 |
|
brrt joined #moarvm |
16:23 |
|
geospeck joined #moarvm |
16:26 |
|
brrt joined #moarvm |
16:28 |
|
brrt1 joined #moarvm |
16:43 |
japhb |
brrt1: ... then you have the script for next time. :-) |
16:45 |
brrt1 |
:-) |
16:47 |
Geth |
¦ MoarVM: 0eefa189ae | (Bart Wiegmans)++ | tools/jit-bisect.pl |
16:47 |
Geth |
¦ MoarVM: [Spesh] extend jit-bisect.pl to use MVM_SPESH_LIMIT |
16:47 |
Geth |
¦ MoarVM: |
16:47 |
Geth |
¦ MoarVM: Currently no per-basic block granularity, but it should probably |
16:47 |
Geth |
¦ MoarVM: help find tricky spesh bugs. Tries to find which combination of |
16:47 |
Geth |
¦ MoarVM: inline / osr / JIT disabled still shows the bug. |
16:47 |
Geth |
¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0eefa189ae |
17:36 |
|
domidumont joined #moarvm |
17:37 |
|
domidumont joined #moarvm |
19:30 |
patrickz_ |
I have a very minimal p6 program using nativecall that fails with a "Bus error". Is the segfaulty nature enough hint to assume it's a MoarVM and not a rakudo bug? |
19:30 |
timotimo |
not necessarily. is this on a non-x86 system? |
19:30 |
timotimo |
bus error is often alignment-related |
19:30 |
patrickz_ |
RPi. |
19:31 |
patrickz_ |
armhf |
19:31 |
timotimo |
i bet that one's rather susceptible |
19:31 |
timotimo |
can you find out where exactly it explodes with gdb or something? |
19:31 |
patrickz_ |
it worked in 2017.08 and failed in 2017.09 onwards |
19:31 |
patrickz_ |
I'll give it a try, hang on |
19:33 |
patrickz_ |
https://gist.github.com/patzim/631553c16b675c24c0decdaf2714cffc |
19:33 |
timotimo |
aha, now here's something interesting |
19:33 |
patrickz_ |
My gdb-foo isn't the best. Can I squeeze more out of it? |
19:33 |
timotimo |
can you recompile moarvm to include debug info? |
19:34 |
patrickz_ |
how do I do that (link to docs is fine ;-) |
19:34 |
timotimo |
how did you build rakudo? |
19:34 |
patrickz_ |
rakudobrew |
19:34 |
patrickz_ |
I'm fine checking it out again |
19:34 |
timotimo |
OK, i believe that lets you do it with a switch |
19:35 |
timotimo |
maybe --configure-opts=--moar-option=--debug=3 --configure-opts=--moar-option=--optimize=0 |
19:36 |
|
unicodable6 joined #moarvm |
19:36 |
|
bisectable6 joined #moarvm |
19:36 |
|
committable6 joined #moarvm |
19:37 |
patrickz_ |
Can I just `./Configure.pl --debug` in ~/.rakudobrew/moar-2017.11/nqp/MoarVM ? |
19:37 |
timotimo |
almost |
19:37 |
timotimo |
you'll have to make sure you pass the right --prefix |
19:37 |
timotimo |
you can find that in the Makefile in the first ~30 lines |
19:38 |
patrickz_ |
got it |
19:39 |
timotimo |
then you'll just need to "make install" in that folder and everything should be finished |
19:39 |
patrickz_ |
that'll take some time. It's a pi... |
19:39 |
timotimo |
but use --debug=3 and --optimize=0 |
19:39 |
patrickz_ |
aww... |
19:39 |
timotimo |
without optimize=0 it'll still not be possible to get the values of the variables you find in there |
19:40 |
patrickz_ |
./Configure.pl --debug=3 --optimize=0 --prefix=/home/pi/.rakudobrew/moar-2017.11/install --make-install ? |
19:40 |
timotimo |
not sure if it has --make-install, but yeah, that sounds good |
19:41 |
patrickz_ |
thanks for taking me through this btw! |
19:42 |
timotimo |
no prob, but i might be AFK for a bit soon :S |
19:42 |
timotimo |
"bt full" can be insightful |
19:46 |
patrickz_ |
updated the gist |
19:47 |
timotimo |
haha, that feeling when you think "these pointers are fare too short to be correct" |
19:48 |
timotimo |
a "list" would be good to have (so i don't have to check out the right source version) |
19:48 |
patrickz_ |
list? |
19:48 |
timotimo |
yeah, that's the gdb command |
19:49 |
patrickz_ |
it's there |
19:49 |
timotimo |
62 } |
19:49 |
timotimo |
that's the line where it explodes |
19:49 |
patrickz_ |
:-P |
19:49 |
timotimo |
cool. |
19:49 |
patrickz_ |
irony? |
19:50 |
timotimo |
yeah; debugging is always fun ;( |
19:50 |
timotimo |
can you also paste the perl6 code? |
19:52 |
patrickz_ |
it's there |
19:52 |
patrickz_ |
three files :-/ |
19:52 |
patrickz_ |
it does need the extra module and NativeCall to fail |
19:52 |
timotimo |
huh, weird, i would have expected double or so to be involved |
19:52 |
timotimo |
ok, i'm not sure if it'll work, but can you try "call MVM_dump_backtrace(tc)" in gdb? |
19:53 |
patrickz_ |
done |
19:53 |
timotimo |
huh, this is happening during compilation actually |
19:59 |
patrickz_ |
Is it worth it finding the commit that causes this? I could try putting a git bisect together... |
20:33 |
|
benchable6 joined #moarvm |
20:51 |
|
timo joined #moarvm |
20:52 |
timotimo |
sorry, the server my irc runs on shut down |
20:58 |
patrickz |
np. Waiting for a build anyways... ;-) |
20:59 |
timotimo |
i imagine it'd take ages to bisect this :\ |
21:00 |
patrickz |
moarvm rebilds quite fast actualy |
21:01 |
timotimo |
right, but along the way between one rakudo version and the next, you'll need to build newer moarvms to fit changes made |
21:05 |
patrickz |
actually I thought I'd get away with only bisecting moarvm, not rakudo.. |
21:05 |
timotimo |
not terribly likely to work out all that well |
21:10 |
patrickz |
ages... :-/ |
21:16 |
* patrickz |
is off to bed... |
21:16 |
timotimo |
good night! |
22:52 |
|
dogbert17 joined #moarvm |
22:57 |
lizmat |
and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/12/04/2017-49-mischieventing/ |