01:15 benabik joined 01:30 woosley joined, woosley left, woosley joined, btyler joined 02:00 cognominal joined 06:26 colomon joined 06:38 FROGGS joined 07:03 zakharyas joined
nwc10 jnthn: I left valgrind running (1 core) overnight 07:20
all the spectests
still not done
this is on another "my" machine
[so faster than the Rasbery Pi :-)] 07:21
08:05 brrt joined
brrt \o #moarvm 08:06
hey i was thinking
supposing i do get to work on moarvm-jit 08:07
moar-jit
where do i post progress reports? should i start a blog fot that?
also, as a proof-of-concept i'm working on a polish notation calculator using dynasm 08:08
nwc10 a blog is probably useful. but get it added to planeteria.org/perl6/ 08:12
but really, if this is about a pending GSoC grant, ask the potential mentors
brrt i will :-) 08:15
masak +1 for blog, regardless 08:38
brrt starting a blog has been on my to-do list for ages 08:39
brrt is off for studying 08:40
09:05 woolfy1 joined
jnthn +1 to blog also 09:08
12:03 btyler joined 13:50 benabik joined 13:57 jnap joined, ggoebel111110 joined 14:07 brrt joined
brrt \o #moarvm 14:07
FROGGS brrt: +1 for blog :o) 14:08
brrt i have no choice then :-) 14:10
FROGGS *g*
brrt just blogspot will do, right? 14:11
FROGGS blogspot, wordpress... whatever you prefer 14:13
brrt suggestion for a title? 14:33
14:50 jnap1 joined
moritz brrsblag 14:51
moarjit
moarfasterthanlight
benabik brrt’s bllg? 14:52
FROGGS warp? 14:56
brrt lol 14:57
FROGGS sonic-brrt might work too (like sonic barrier / sonic bang)
moritz faster-than-brrt 14:58
tadzik :D
FROGGS where no man has brrt before?
brrt i wonder why this triggers so many star trek references 14:59
moritz just-in-brrt
benabik moritz: +1
FROGGS perhaps a back-to-the-future reference would work also 15:00
moritz back-to-jit 15:01
brrt i'll let you know :-) 15:02
FROGGS hehe 15:04
jnthn moarrt 15:07
"Dead serious about JITting"
brrt likes 15:09
benabik +1
timotimo jnthn: the multispec stuff for onlystar protos is now in full effect on moarvm; did you get around to making it work on parrot and jvm yet? i seem to recall commits to that effect 15:12
jnthn timotimo: no
timotimo: I did the stuff to get onlystar protos consistently hidden in the CALLER chain on all of them. 15:13
timotimo ah, but the optimization to also skip the proto in dispatch is only present on moarvm so far?
jnthn right 15:14
I know how to do it on JVM
timotimo good to know
timotimo is working on the weekly now
jnthn In fact I know how to do it on JVM better than Moar has it
But that won't last too long :P
timotimo :D 15:17
jnthn ok, I fried enough brains by teaching OO design while sleep deprived...time to go back to the hotel... 15:19
bbl
16:20 dalek joined 16:27 benabik joined 17:19 FROGGS[mobile] joined 17:20 brrt joined 17:29 benabik joined 17:47 colomon joined 17:51 japhb_ joined 18:24 FROGGS joined
retupmoca jnthn: github.com/retupmoca/MoarVM/compar...r...master 18:42
jnthn: ^ seems to fix GH#88 (my Array[Type] precomp issue), spectests fine, all the modules I tried installing worked
jnthn: but it feels like a bad fix to me. Unfortunately, I don't know the code well enough to know what this is actually doing 18:43
jnthn: so...thoughts? :)
timotimo i was wondering how the "turn posix signals into a supply" thing could be done 18:50
and i don't really know how to hook it up
because you really can't do much from a signal handler 18:53
so there ought to be some kind of trampoline 18:54
nwc10 possibly the most useful thing you can do is write (non-blocking) status about the signal down a pipe
to yourself, and have the event loop read the pipe 18:55
timotimo how does the event loop interact with the interpreter loop btw?
jnthn retupmoca: Yeah, that's almost certainly the wrong fix
nwc10 well, the "something" loop - I don't know the answer on the VM end
but IIRC I thought that something like this would even work for siginfo (or whatever it's called) 18:56
write the struct down a pipe (the write is legal)
and hope the other end is reading fast enough
jnthn retupmoca: But knowing it's that op is helpful indeed
nwc10 not *sure* if it's possible to figure out a way to flag "we lost signals" or if it's useful or what
jnthn Well, most things where you want to notify involves shoving something into a queue, but from a signal handler that's really not good as it wants to grab a mutex. 18:57
Which is most certainly a no-no. 18:58
nwc10 yes, hence using a pipe to the same process
jnthn yeah
retupmoca jnthn: if you want me to keep poking it, I think I need to be pointed a little towards the correct fix
not sure where to go from here
jnthn retupmoca: Well, did you have a backtrace from where it was triggered?
retupmoca in nqp-land?
jnthn yeah 18:59
The thing dump_backtrace spits out
retupmoca ah, I didn't do that for the problematic repossession 19:04
gist.github.com/retupmoca/a86b0726e55060b64baa 19:05
19:08 cxreg joined
retupmoca when I compile the test file, current master repossesses two objects - one happens in ParametricRoleGroupHOW.get_selector (the add_dispatchee call) 19:15
and the second in ParametricRoleGroupHOW.specialize (on the line that calls get_selector)
the second repossession is what seems to be causing the issue
if I use gdb to force that one to return out of MVM_sc_wb_hit_obj, the test works fine 19:16
jnthn The question now is, why would this work out fine on other backends and not on Moar... 19:17
gimme a mo to check something 19:18
retupmoca: Does it work out on JVM, ooc? 19:23
retupmoca jnthn: not a clue - I usually just have moarvm installed 19:24
jnthn Or Parrot for that matter.
OK, I went looking for a discrepancy and now wonder if it's a bug everywhere.
If it *is* I think I know that may be up.
retupmoca jnthn: I can build a -j and a -p if you need me to test 19:25
jnthn get_selector calls add_dispatchee
retupmoca or I can link you my reproduction gist
jnthn This does an nqp::push onto the dispatcher's candidate list.
That does *not* currently seem to trigger repossession on any backend.
The end result is that "@!add_to_selector := [];" tosses what was added, and triggers repo. But the actually adding of the candidates does not. 19:26
So they vanish, which...hm...is your error something about no candidates?
retupmoca error is here: gist.github.com/retupmoca/9953591
initial exception is: Cannot call ''; none of these signatures match:
so...no anything 19:27
jnthn yeah, "none matched" and an empty list means "there were none"
That matches perfectly.
retupmoca so the problem is actually that we aren't repossessing enough? 19:28
jnthn Looks like it may be that
If you want to try a hack to fix it 19:29
In src/Perl6/Metamodel/BOOTSTRAP.pm locate the line Routine.HOW.add_method(Routine, 'add_dispatchee', nqp::getstaticcode(sub ($self, $dispatchee) {
You'll see a
my $disp_list := nqp::getattr($dc_self, Routine, '$!dispatchees');
Beneath it, to force repo, just add a
nqp::bindattr($dc_self, Routine, '$!dispatchees', $disp_list); 19:30
it's a no-op really.
But it'll trigger repo.
retupmoca jnthn: building 19:31
jnthn It may have other interesting consequences... 19:32
If you feel like building an r-p or r-j to try this out too that's also great.
retupmoca jnthn: I'll do that.
jnthn: if this works, is this the fix we want? or do we want to trigger repossession some other way? 19:33
jnthn retupmoca: Well, if you look at the push_o op in interp.c, and push in JVM's Ops.java, or similar on Parrot in sixmodelobject.pmc, none of those trigger repo on a push 19:34
this is kinda why I'm asking.
(if it shows up elsewhere)
Because if it does then we undersand what's going on.
And if it works elsewhere then there's more to it than meets the eye.
retupmoca gotcha 19:35
well, that hack fixes it on perl6-m
or fixes my golfed version anyway, let me get panda and try the actual modules
and I'm building a non-hacked perl6-j/p to test 19:37
jnthn retupmoca++
retupmoca jnthn: if this is doing what we think it is, do we want to make push_o and friends trigger repossession? 19:40
if so, I think I'll have time to PR fixes tonight
jnthn retupmoca: We can try that, but who knows what is relying on it *not* triggering it righ tnow 19:41
retupmoca true
if I get the time, I'll test that as well then
19:41 brrt joined 19:49 eternaleye joined
timotimo jnthn: can you tell me if there's a sensible spot to cause supplies to get a value after a signal has reached the moarvm process? 19:50
so the signal handler could push a value into some queue or other for the libuv event loop to see 19:51
but where does that event loop get pumped?
jnthn timotimo: I'd leave it for now 19:52
timotimo OK
jnthn timotimo: I'm going to in a bit add an "async service thread" whose event look will deal with various async-y things and then shove stuff into an appropriate queue.
*event loop
timotimo OK
jnthn And we may be able to do that 19:53
timotimo it's just i have the desire to catch a SIGWINCH
and putting an actual callback in there using NativeCall sounds dangerous; given that the vast majority of things are not allowed in signal handlers
jnthn
.oO( Much more appropriate than SIGWENCH... )
timotimo :)
sigwrench? :)
jnthn Yeah, that's...dangerous. :) 19:54
Well, libuv does provide abstractions for this stuff
TimToady why we require "use MONKEY_WRENCH;" for that
jnthn So I think we should use those...
But I don't know their exact sematnics
I am aware that there's funky stuff wrt signals, threads, which thread gets the signal, some signals being thread specific, maybe sometimes sorta, etc. :) 19:55
timotimo yeah :|
what i *could* do is have a tiny C library that registers a super simple signal handler that just sets a flag to 1 and you can retrieve the flag and clear it 19:56
jnthn How soon do you need it? 19:57
timotimo knowing my programming speed
jnthn I'm planning to work on async bits and pieces later this week.
timotimo some time this year
jnthn oh. :P
timotimo i can easily deal without having it
it's just ... then i could just start doing stuff
jnthn Well, libuv has a uv_signal_[init&start&stop] 20:01
That deliver the signal on the event loop
What isn't clear from uv.h is their exact semantics.
timotimo if only they had documentation for that 20:02
jnthn heh 20:03
Well, it *looks* like it does the nasty for us
that is, it figures out how to install the the handler and safely marshall it to the event loop
Meaning that I can probably, once I get the service thread in place, get you this without a lot of hassle.
timotimo damnit, i can't find that cool library again that i wanted to bind with NativeCall :| 20:04
and i've already forgotten how i found it the last time
jnthn Was it something to do with cats and user interfaces? 20:05
timotimo heh 20:09
it's a lightweight terminfo database library thingie 20:10
i don't want to bind ncurses 20:11
it'd be terrible
our ncurses binding has already bound 5 functions 20:18
initscr, clear, endwin, printw, getch
and it doesn't even bind libncursesw, just the regular ncurses >_<
retupmoca jnthn: without the hack, parrot works fine and JVM throws the same error as moar 20:20
jnthn retupmoca: eek. the plit thickens. 20:21
uh. plot.
timotimo well, moar and jvm have been the "stricter" backends so far, have they not?
jnthn timotimo: well, kinda, but in this case I don't immediately see the "strictness" 20:22
:)
Oh...I wonder...
hmm 20:23
Thing is that Parrot uses RPAs for all the arrays
On Moar and JVM it's different. There's a VMArray REPR and then the VM provides a BOOTArray for bootstrapping. 20:24
ah, bingo... 20:25
ownedresiablepmcarray.pmc barriers all over
timotimo \o/
jnthn Which is why we see this. 20:26
er, why it works I mean
push gets barriered there.
timotimo yes
seems logical
jnthn Well, I guess we can try push_o in Moar triggering the WB
Which is a one-line patch 20:27
timotimo and the same on jvm?
jnthn I just worry if it will cause other bustage elsewhere.
timotimo should it, though?
jnthn Yeah, smae on JVM
2-line patch there
well, it probably should, yeah
retupmoca jnthn: I'm building a push_o moarvm patch right now
timotimo sounds good in any case :) 20:28
retupmoca t/spec/S04-phasers/first.t fails tests if I patch moarvm 21:08
fails 3/4 if I just patch push_o, fails 2/4 if I patch push_*
jnthn: ^ 21:09
jnthn retupmoca: uh, I'm not sure that's related 21:10
retupmoca: Do repeated runs of it without changing the patch and you may get the variance anyway?
Also set MVM_SPESH_DISABLE=1 and try it.
I think you may be seeing an unrelated issue.
retupmoca jnthn: it does run fine if I run the test file directly 21:11
jnthn retupmoca: I don't think it's related to your patch. 21:12
retupmoca: I'm much more concerned about its effects on pre-comp of other things.
retupmoca jnthn: I've successfully installed these modules: gist.github.com/retupmoca/cf13a8fe2562adfd1ae1 21:20
not seeing any issues yet
(patch is github.com/retupmoca/MoarVM/compar......master)
any in particular I can check for precomp breakage?
anything*
jnthn retupmoca: LWP::Simple and URI tend to be the ones that trip things most 21:28
I see how have URI
*you have
retupmoca: Patches look sane 21:30
Need to rest now...barely slept last night. Hope this one is better...
'night
retupmoca jnthn: will PR 21:31
lizmat jnthn: gnight!
retupmoca github.com/MoarVM/MoarVM/pull/92 21:32
jnthn: night!
jnthn++ # walking me through bugfixes 21:33
21:53 eternaleye joined 22:41 benabik joined 23:30 benabik joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!