|
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. |
02:28 | |
| arVM: 8cc37e9 | jimmy++ | src/io/procops.c: Better MACRO wrapper |
02:44 | ||
|
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)» | ||
| FROGGS | \o/ | ||
| 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 |
20:47 | |
|
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 | ||
| jnthn | .oO( Marks and Spencers sell lock-free queues now? Wow! ) |
21:32 | |
| 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
|
|||