<brixen>
yorickpeterse: since there's no artifact, it's very difficult to determine whether the write triggered an event or not
<brixen>
thinking about how to address that
|jemc| has joined #rubinius
<tarcieri>
:D
mrb_bk has quit [Ping timeout: 260 seconds]
mrb_bk has joined #rubinius
<brixen>
hm, I wonder if this Process.spawn non-deterministic failure is a process race
<brixen>
lmao if you think races only happen if you use threads
GitHub159 has joined #rubinius
<GitHub159>
[rubinius] brixen pushed 1 new commit to master: http://git.io/iKKvQQ
GitHub159 has left #rubinius [#rubinius]
<GitHub159>
rubinius/master 6c8237f Brian Shirai: Make Console request thread GC dependent at exit.
<yorickpeterse>
brixen: it happens for me when I try to install rbx itself
<yorickpeterse>
basically when it starts compiling C extensions
<brixen>
ok, will see what I get running this
jb443 has quit [Read error: Connection reset by peer]
<yorickpeterse>
brixen: unrelated to the above, how does the Rbx bytecode store different CompiledCode objects? That is, say you have a method def and call in the global scope
<yorickpeterse>
Context: working on VM instructions for defining methods, not entirely clear to me how you'd go about jumping between a definition and back to the original scope
<yorickpeterse>
and that question is super abstract :/
<yorickpeterse>
I guess it's a bit easier if you have a stack VM, but it's a bit tricky for register ones
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci>
[travis-ci] rubinius/rubinius/master (6c8237f - Brian Shirai): The build has errored.
|jemc| has quit [Read error: Connection reset by peer]
|jemc| has joined #rubinius
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 250 seconds]
<brixen>
yorickpeterse: shouldn't depend at all on the execution model
<brixen>
defining a method should just result in a value
<brixen>
whether that value is on the stack or in a register is immaterial
<brixen>
if you can use Ruby to pseudo-code this up, you can rbx compile it to see what rbx does :)
<brixen>
yorickpeterse: the last travis run has the hang on os x, so nice it's not a linux specific thing :p
<yorickpeterse>
brixen: well yeah, but does rbx have some kind of instruction to say "yo, all following instructions belong to this method we just defined"?
<yorickpeterse>
not entirely sure how to phrase the question properly :/
elia has quit [Ping timeout: 258 seconds]
postmodern has joined #rubinius
havenwood has joined #rubinius
<|jemc|>
yorickpeterse: each method gets its own Generator and each generator gets #close'd and #package'd up independently
<|jemc|>
my apologies if that's already known or not helpful
<yorickpeterse>
hm, so the file it's written to is basically an array of CompiledCode objects?
<|jemc|>
I haven't looked at the rbx emission process yet - that's on my list for next week
<|jemc|>
err.. rbc emission
<|jemc|>
but I think it's less of an array of marshalled CompiledCode objects so much as a nested tree
<|jemc|>
as in, the CompiledCode object is marshalled as a literal or sorts into the place where it is defined