timotimo ho-hum. we have effective_bytecode, but we don't have a corresponding bytecode size 00:50
so to dump the "currently executing bytecode", i'll have to hunt through the candidates to find the one that has the matching bytecode array address
well, at least i'll be able to :)
oh, i should be going to bed 00:59
but i've made progress already
next step is to make it mark up the current op if the frame being dumped is the one the tc is currently running 01:00
01:52 ilbot3 joined 05:13 lizmat_ joined 05:51 domidumont joined 05:57 domidumont joined 06:41 brrt joined
brrt good * #moarvm 06:52
06:58 vendethiel joined 07:01 domidumont joined 08:19 robertle joined
jnthn morning o/ 08:50
brrt \o jnthn 08:52
jnthn digs back into Proc[::Async] things, hoping he can get them wrapped up somewhat today 08:55
09:06 FROGGS joined
brrt i hope i'm going to have time for That Weird OSR bug 09:09
which doesn't appear to break on the OSR, for some reason
FROGGS hi brrt 09:10
brrt hi FROGGS
09:26 nebuchad` joined 09:27 colomon_ joined 09:30 cono_ joined, [Coke]_ joined, sivoais_ joined 09:41 camelia joined, FROGGS joined 10:13 zakharyas joined
lizmat jnthn: you may be interested in knowing that HARNESS_TYPE=6 no longer outputs the name of the test-file being run / completed 10:48
it also appears to hang after a while, with 1 moar process stuck in 0% CPU 10:49
jnthn *sigh* 10:50
At this point I'm semi-interested in reverting everything I did with Proc and leaving it to be somebody elses problem :/
lizmat well, maybe try to wrap it up first? and then maybe that issue will have gone away automagically ? 10:51
jnthn I've got RT #131576 sorted out at least 10:52
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131576
jnthn Well, in POSIX-y systems
On Windows, guess it's back to how it was before
There's just so many icky timing issues when you are doing this sync 10:53
lizmat not really a consolation, but I just found a number of errors in (-) and (+) :-(
jnthn And so many ways to deadlock
lizmat which I had deemed to be done by now
jnthn Which of course was the case *before* I did any of htis
*this
I'm currently confused how this test ever worked: 10:54
my $tt = shell :out, :err, 'tty';
if $tt and (my $path = $tt.out.slurp(:close).trim)
Oh, and I worry in sorting out the plumbing thing I've probably re-introduced the deadlock in reading from stdout/stderr 10:56
Which we had before
Basically because if you don't know whether the handle is going to be plumbed to something else, you can't start reading from it. 10:57
The above one stopped working because it seems we made Bool unconditionally block on process exit 10:59
I'm sure I had it not doing so
And we got away with it before when we started reading immediately 11:00
But we can't have that fix and the plumbing fix.
And retain the current API
The amount of relatively complex code I've got by now to try and make something inherently async work with a synchronous API scares me. 11:01
lizmat then perhaps we shouldn't try to do it synchronously after all ? 11:03
jnthn Well, yeah, I've been saying that about Proc for a while :) 11:04
But it's in relatively widepsread use by now in the ecosystem
And in some cases it's simpler
Until you start dealing with multiple of stdin/stdout/stderr being bound
And as soon as there's more than one, a sync API is in bother. 11:05
About the only consolation is that with the current set of changes you can now do
my $foo = start $proc.out.slurp; my $bar = start $proc.err.slurp; and actually ahve the two read in different threads 11:06
Which you couldn't before
So there is at least a way out of the deadlock I guess. 11:07
I dunno what to do about the boolification change though. I need to check if I'm right that I had it one way and it got changed.
Yes 11:08
github.com/rakudo/rakudo/commit/e4...985e056afc
I'm not sure we can keep e4468c61 11:09
Or at least, not all of it
Since it worked because we faked the file handling plumbing and it no longer can work now I've resolved that 11:10
So, figure I'll have to undo some of that
Lunch; bbiab 11:12
11:24 yoleaux joined
nine So previously we'd return wrong results if the user neglected to wait. Now we wait for her and could run into deadlocks that way. Leaves two options: 1. just explode instead to make it obvious to the user that he's holding it wrong, 2. close everything instead of waiting, so there's no deadlock. Could cause other issues for the user though. 11:26
brrt i'm for exploding 11:33
11:52 domidumont joined 11:54 AlexDaniel joined
jnthn nine: The problem is that we've got spectests that depend on being able to do what I pasted above 11:57
And so probably ecosystem code too
We can go with checking if there are active handles, anyway 11:58
And only waiting if not
That seems to do it 12:06
jnthn spectets
12:30 ilbot3 joined
jnthn nine: Hm, your suggestion seems to work out nicely :) 12:44
jnthn does another spectest
nine \o/
brrt nine++ jnthn++ collaborative debugging
12:49 ilbot3 joined
timotimo collatteral debuggage 12:49
brrt hehe 12:56
the alternative would be overwriting the bytecode
well, truth be told, there are a bunch of other bytecode possiilities 12:57
timotimo i might be able to just always use frame->spesh_cand instead of searching through to find which one matches the bytecode address 13:03
brrt that… ought to be right, yes
timotimo hm, then i get no output for that frame, though
brrt oh, that reminds
me
- the jit currently relies on spesh to run
- or well, spesh candidate generation to work 13:04
- it shoul dnot
jnthn Well, yes and no :) 13:05
This is one of the things I was alluding to in my spesh shortcomings do
*doc
timotimo you mean baseline optimization being completely missing?
jnthn Yeah 13:06
Part of the idea of that being that we'd JIT
13:13 ilbot3 joined 13:43 ilbot3 joined 14:02 zakharyas joined 14:04 sivoais joined 14:21 ilbot3 joined 14:42 brrt joined 14:53 ilbot3 joined 15:30 ilbot3 joined
timotimo i think i'll go ahead and merge it to master 15:39
Geth MoarVM: fcb1b35922 | (Timo Paulssen)++ | src/core/bytecodedump.c
add debug helpers: MVM_bytecode_dump, bytecode_dump_stackframe

shows not only the whole bytecode, but also puts a little arrow where the current op (or the next-to-run-after-return op) is. won't display jitted frame's original bytecode yet.
16:06 ilbot3 joined 16:15 ilbot3 joined, moritz joined
jnthn is working a bit on planning for the spesh re-work 16:26
Well, has been.
Time to stop and get some rest, I think
timotimo good rest! 16:35
jnthn Thanks. I've figured out a good way to get predictable runs, as brrt++ requested, at least :) 16:36
bbl
timotimo i'd love to have a good way to get predictable sleeps :| 16:39
i do know that if i go to bed after a certain time, birds are going to boot up and make trying to sleep impossible 16:40
17:28 zakharyas joined
DeadDelta Take sleeping pills :) 17:29
50mg of diphenhydromine hydrochloride immediatelly followed by a small meal. Half an hour later, you're sleeping. 17:30
timotimo is that an over-the-counter drug?
DeadDelta It is here.
Some places it isn't
timotimo there's some notable things that aren't over the counter in germany
geekosaur maybe you are sleeping after that; I'm not... 17:58
DeadDelta I sleep after 200mg :) 18:03
But are you having a meal? The food is crucial for this drug. 18:05
Or protein shake
timotimo the code from "'grinding out performance improvements" regressed a fair bit; it's now at 14.7 billion instructions, when in the middle of that blog post it was at 11 billion 18:12
geekosaur I'm just mostly immune to that kind of thing. ambien doesn;t work on e either (rather: it worked *once*. after that, I just get really dizzy for about 3 seconds and then nothing.) 18:15
weird brain chemistry ftw?
DeadDelta :) 18:17
geekosaur (it's genetic. overactive dopamine, possibly overactive GABA. I've already got early signs of familial essential tremor) 18:18
18:24 greppable6 joined, committable6 joined, evalable6 joined, unicodable6 joined, bisectable6 joined, benchable6 joined, quotable6 joined, bloatable6 joined, statisfiable6 joined 18:52 Ven joined 19:12 AlexDaniel joined 19:32 zakharyas joined, ggoebel joined
samcv good * everyone 21:48
timotimo heyo 21:51
21:51 DeadDelta left, DeadDelta joined
lizmat samcv o/ 21:52
timotimo jnthn: i think the way we put prof_allocated in for a param_op_o might be wrong; the branch it jumps to starts with prof_allocated on the register that the op would have written to, then it goes on to create the alternative value and prof_allocated the result value as well? 21:55
22:03 FROGGS joined
jnthn timotimo: Hm, that does sound suspect. given we just got better at kicking out the optional handling code, it also sounds like a candidate 22:13
yoleaux 21:29Z <DeadDelta> jnthn: RE from-slurpy-flat I tried with 2017.06 and 2017.05 builds, it's there in both at around 32%-38%
timotimo that doesn't explain the explosion all by itself, but if it mucks up the usage numbers somehow...? 22:14
jnthn Yeah, it's still odd
timotimo anyway, it throws out not only the block that'd fill in the default value, but also the whole getarg op, as well
it says it has a DeadWriter, too, but i don't know if that caused the issue or is just an expression of the same underlying problem 22:15
jnthn timotimo: Also, did you see the discussion on #perl6-dev about perl6-m --profile -e 'class A { method a() { } }; for ^100000 { A.a }' producing profile output that spends a bunch of time in List.from-slurpy-flat? 22:16
On 2017.05-468-g446dc19 I don't see it on the routines tab at all 22:17
timotimo i haven't looked into that 22:18
jnthn I'll try it at HEAD tomorrow
timotimo i do see it on HEAD 22:19
jnthn ah, ok
bizzare
timotimo it looks as though Nil.pm:8 calls into from-slurpy-flat on List.pm:275
it's the sink method
it has sink(*@ --> Nil) { } as its code 22:20
jnthn Why would sink *ever* be passed arguments?!
timotimo i have not a single clue
and since it's a method that also has a *%, why not just (|)?
it says "required by RESTRICTED.setting" 22:21
so it's probably something quite odd
jnthn That sounds odd too 22:22
timotimo i'm compiling a simpler one now
jnthn Not to mention that sink in Mu also returns Nil?
timotimo actually 22:23
all the methods on nil have *@
when they most probably could all just have |
jnthn I wonder if it was blanket applied 22:24
Also I wonder if this means soemthing sink-y changed at some point
22:24 Voldenet joined
jnthn Maybe when the for loop code-gen changed 22:24
timotimo i got the commit for it but helpfully fugitive isn't showing the commit itself where i could copy-paste it 22:25
parent ccee46ef0fa5c23b395ea852e517634dc4541341
and yes, all the *@ were put in at the same time
with | in the signature the from-slurpy-flat is gone 22:26
finishes in less than half the time, too
i'll spectest and push a commit 22:27
jnthn timotimo++ 22:28
lizmat aha, so it's an artefact of sinking Nil
timotimo yup 22:29
lizmat timotimo++
good night, #moarvm! 22:30
timotimo oh no, i have --optimize=0
no, i won't spectest like this %)
would be good to pull latest nom before 22:32
jnthn :) 22:36
jnthn heads for rest also
'night
timotimo gnite jnthn :) 22:37
and lizmat
i had to kill S11-modules/nested.t 22:40
S03-operators/mix.t and S32-io/open.rakudo.moar both have one test each failing 22:41
S32-io/open.rakudo.moar works fine when run outside the harness 22:42
same for the nested.t test

Powered by Cro and the Raku® Programming Language.

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

Thank you!