Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-04-14

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary