01:01 woosley joined
BenGoldberg r-m: 1 01:37
Not yet, eh? :)
TimToady take a vacation to Mars and back, and it'll be done fershure 01:40
01:53 arnsholt joined
dalek arVM: 7290e90 | jimmy++ | src/io/procops.c:
remove wrapper from shell by using libuv api directly, this avoids unnecessary string encode/decode and hash get/set.
arVM: 8cc37e9 | jimmy++ | src/io/procops.c:
Better MACRO wrapper
05:13 lue joined 05:21 johnny5_ joined 06:56 lizmat joined 08:01 lizmat joined 08:02 woolfy joined 08:19 woolfy left 08:26 FROGGS joined
FROGGS JimmyZ_++ 08:33
09:18 cognominal joined 13:56 jnap joined 14:43 benabik joined 15:49 benabik joined 16:41 BenGoldberg joined 16:58 benabik joined
FROGGS nqp: nqp::shell('echo $PWD', '/tmp', {}); nqp::spawn(['echo', '$PWD'], '/tmp', {}) # moar needs a rebuild :o( 17:01
camelia nqp-moarvm: OUTPUT«Error while compiling op spawn (source text: "nqp::spawn(['echo', '$PWD'], '/tmp', {})"): No registered operation handler for 'spawn'␤frame_name_1108␤»
..nqp-jvm, nqp-parrot: OUTPUT«/tmp␤$PWD␤»
diakopter nqp-m: say(nqp::null) 17:04
camelia nqp-moarvm: OUTPUT«␤»
diakopter o_O
FROGGS nqp-m: say(nqp::null_s) 17:05
camelia nqp-moarvm: OUTPUT«(signal SEGV)»
diakopter nqp-m: say(nqp::null) 17:07
camelia nqp-moarvm: OUTPUT«␤»
diakopter nqp-m: nqp::shell('echo $PWD', '/tmp', {}); nqp::spawn(['echo', '$PWD'], '/tmp', {})
camelia nqp-moarvm: OUTPUT«Error while compiling op spawn (source text: "nqp::spawn(['echo', '$PWD'], '/tmp', {})"): No registered operation handler for 'spawn'␤frame_name_1108␤»
diakopter FROGGS: what's the invocation to build nqp with --gen-moar 17:08
FROGGS I dunno, but I'd guess: perl Configure.pl --backends=moar --gen-moar --prefix=something --make-install 17:11
prefix might be just "install"
nqp-m: say(nqp::backendconfig<version>) 17:19
camelia nqp-moarvm: OUTPUT«2013.10-112-ge3e33c2␤» 17:20
diakopter meh
FROGGS ahh, we're just missing five commits :o)
timotimo so, i was thinking about games and VM integration again 18:48
ideally, i'd probably have a script for entities that looks kind of like an event loop
so could i, in principle, have a function "get_next_event" that magically returns from the VM into the game engine itself if there's no more events to be processed for that particular entity?
without having a stack that's ever growing? 18:49
and without having to manually trampoline?
also, i guess it would also be interesting to run the scripts of multiple entities in parallel 18:51
especially if the entity scripts are perl6 ... that would probably suck out most of the framerate :P 18:52
benabik I'd do it via continuations. Game calls VM, VM calls entity code, entity code calls get_next_event, which stores its state as a continuation for the game to call next time the entity gets an event. 18:54
timotimo yeah, something like that
i don't know how moarvm looks on the inside, so ... :) 18:55
benabik I think Moar is all linked continuations instead of a stack...
So it shouldn't be hard to do that. 18:56
timotimo sounds good
the game is completely vapourware at the moment though :P
as is the game engine
benabik Alternatively, run each entity in a thread and it just blocks until fed an event. 18:57
timotimo hm, huh. that'd possibly work, too 19:05
but there may be very many entities, depending on the nature of the game
you wouldn't want to start 3000 threads on a regular machine, would you? :P
benabik Depends on the threading model, I guess. 19:08
timotimo something like "green threads" is probably the same thing i was thinking of. like running up to 4 scripts in parallel or somethig 19:09
and then doing the continuation trick you mentioned
dalek arVM: 800a236 | (Tobias Leich)++ | / (7 files):
added filereadable, filewritable, fileexecutable
21:05 colomon joined
jnthn timotimo: tbh, I'd just throw the events into something with the LockFreeQueue REPR that Channel on MoarVM will be based on, since that'll be easy from C land. 21:21
timotimo: that's the way async lines works so far :)
timotimo hm. so you're suggesting the vm is running all the entity scripts all the time? 21:24
benabik is at the university where the M&S lock-free queue was designed. 21:30
.oO( Marks and Spencers sell lock-free queues now? Wow! )
timotimo: Well, decoupling on messages is generally looser than decoupling on invocations, is all. 21:33
21:43 colomon joined 21:54 woolfy joined
timotimo ah 22:08
22:20 ssutch joined 22:29 jnap left
diakopter . 23:09
23:42 colomon joined 23:49 benabik joined