GitHub98 has joined #rubinius
<GitHub98> rubinius/1.8.7-README-updates-bison 0f41330 jc00ke: Switch to datarootdir & use /usr/local in README...
GitHub98 has left #rubinius [#rubinius]
<GitHub98> [rubinius] jc00ke pushed 1 new commit to 1.8.7-README-updates-bison: http://git.io/e8aiww
meh` has quit [Ping timeout: 260 seconds]
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
dimday1 has quit [Quit: Leaving.]
josh-k has quit [Ping timeout: 272 seconds]
havenwood has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
|jemc| has joined #rubinius
amsi has quit [Quit: Leaving]
josh-k has joined #rubinius
pwh has quit []
pwh has joined #rubinius
dimday has joined #rubinius
jnh has joined #rubinius
amclain has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #rubinius
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
havenwood has quit [Ping timeout: 264 seconds]
havenwood has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
josh-k has quit [Ping timeout: 245 seconds]
jnh has quit [Quit: Leaving...]
josh-k has joined #rubinius
pwh has quit []
|jemc| has quit [Quit: WeeChat 0.4.3]
JohnBat26 has joined #rubinius
|jemc| has joined #rubinius
Benny1992_AFK is now known as Benny1992
havenwood has quit []
josh-k_ has joined #rubinius
amclain has quit [Quit: Leaving]
josh-k has quit [Ping timeout: 246 seconds]
havenwood has joined #rubinius
Benny1993 has joined #rubinius
Benny1993 has quit [Client Quit]
Benny1993 has joined #rubinius
Benny1993 has quit [Client Quit]
Benny1993 has joined #rubinius
Benny1992 has quit [Ping timeout: 260 seconds]
Benny1993 has quit [Client Quit]
bennyklotz has joined #rubinius
bennyklotz has quit [Client Quit]
bennyklotz has joined #rubinius
bennyklo1z has joined #rubinius
bennyklo1z has quit [Client Quit]
bennyklotz has quit [Client Quit]
bennyklotz has joined #rubinius
bennyklotz has quit [Client Quit]
bennyklotz has joined #rubinius
bennyklotz has quit [Client Quit]
bennyklotz has joined #rubinius
bennyklotz has quit [Quit: leaving]
bennyklotz has joined #rubinius
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
benlovell has joined #rubinius
havenwood has quit [Ping timeout: 264 seconds]
flavio has joined #rubinius
flavio has joined #rubinius
flavio has quit [Quit: WeeChat 0.4.1]
flavio has joined #rubinius
noop has joined #rubinius
josh-k has joined #rubinius
josh-k_ has quit [Ping timeout: 250 seconds]
josh-k_ has joined #rubinius
josh-k has quit [Ping timeout: 260 seconds]
elia has joined #rubinius
josh-k has joined #rubinius
havenwood has joined #rubinius
josh-k_ has quit [Read error: Connection reset by peer]
<yorickpeterse> morning
havenwood has quit [Ping timeout: 264 seconds]
<bennyklotz> morning
dimday has quit [Ping timeout: 246 seconds]
noop has quit [Read error: Connection reset by peer]
noop has joined #rubinius
soulhacker has joined #rubinius
soulhacker has quit [Quit: Textual IRC Client: www.textualapp.com]
josh-k_ has joined #rubinius
josh-k has quit [Ping timeout: 260 seconds]
kagaro has quit [Ping timeout: 245 seconds]
kagaro has joined #rubinius
dimday has joined #rubinius
noop has quit [Ping timeout: 260 seconds]
dimday has quit [Quit: Leaving.]
maasha has joined #rubinius
maasha has quit [Client Quit]
maasha has joined #rubinius
<maasha> hi
<maasha> Is is possible to enumerate in parallel using threads? https://gist.github.com/maasha/e7fd1ce7de6f73c73cd0
<maasha> this works sometimes, but mostly outputs nothing. probably some race condition.
<maasha> nothing*
<yorickpeterse> euh yeah, those threads are not doing anything
<yorickpeterse> You're enumerating over the result after you've killed the threads
<yorickpeterse> Plus, Enumerator.new { ... } doesn't do anything until you actually iterate over it
<yorickpeterse> so there's no real goal to doing that inside a thread
<yorickpeterse> errr s/goal/benefit
<maasha> yorickpeterse: if I swap line 22 and 24 only the first increment happens.
<maasha> yorickpeterse: So is there some way to enumerate in parallel?
<yorickpeterse> Yes, because then you're iterating before you kill the thread
<maasha> (gist updated. btw)
<yorickpeterse> That's the most basic way of doing it
DanielVartanov has joined #rubinius
<maasha> yorickpeterse: in fact I am trying to rewrite this piece of code (that actually works) to use threads to speed up using rbx: https://gist.github.com/maasha/cc7705f8d43a7e3a8abb
<yorickpeterse> you'd just use enums.last.each { Thread.new { ... actual work here ... } } there
<yorickpeterse> The Enumerator creation is lazy, the block isn't evaluated until you call #each on it
<yorickpeterse> Thus adding threads there doesn't help
<maasha> yorickpeterse: hm, so I have also tested this, which also works: https://gist.github.com/maasha/8973751f694c24f375ff - however, I would like to avoid IPC and IO.pipe, hence looking at Enumerate.
josh-k_ has quit [Remote host closed the connection]
<maasha> yorickpeterse: (I am doing a Ruby mochup of bash pipes: cmd1 | cmd2 | cmd3 ... | cmdn
<maasha> )
<maasha> mockup*
<yorickpeterse> If it's Bash pipes you'd actually _want_ to run those in sequence
<yorickpeterse> that's the whole point of them
josh-k has joined #rubinius
<maasha> yeah, so the deal is I have a bunch of records that I want to run through a number of commands each manipulating a record in what may be heavy computational steps.
<maasha> yorickpeterse: I suppose like this: https://gist.github.com/maasha/0ab9c18880e2a84dacaa if you imagine that (e + 1) is a heavy duty operation - but you tell me that this is not going to do what I want?
<yorickpeterse> two things there
<yorickpeterse> 1) you're only using the last enum, discarding the first 9
<yorickpeterse> thus only 1 thread is actually started
josh-k_ has joined #rubinius
<yorickpeterse> 2) the threading setup this way guarantees no order
<yorickpeterse> so your values can be yielded in any random order
<yorickpeterse> There's a much easier way of doing this, gimme a sec
<maasha> yorickpeterse: I am not discarding the first 9 enums - the output is as expected a list from 10 .. 20
<yorickpeterse> you're doing 10.times do ....., then push into enums
<yorickpeterse> then you do enums.last
<yorickpeterse> that discards the first 9
<yorickpeterse> well, it ignores them
<maasha> yorickpeterse: the enums << is outside the thread scope - I thought order would be preserved.
<yorickpeterse> That is correct
<yorickpeterse> But the moment you call the enum each value is processed in a thread
<yorickpeterse> thus each `yield` is done separately
<yorickpeterse> meaning there's no order anymore
<yorickpeterse> maybe I'm misreading it, but the code is rather cryptic
josh-k has quit [Ping timeout: 258 seconds]
<maasha> yorickpeterse: Hm, are you sure? I am for each thread creating a new enum in order not to mix up anything.
<yorickpeterse> https://gist.github.com/YorickPeterse/bcf46210c288c6fd045e this is all you need if I'm grokking it properly
<yorickpeterse> maasha: No, you're creating a thread for every value in the enum
<yorickpeterse> my gist does the same
<yorickpeterse> If you only want 1 thread per enum you'd do....
<maasha> yorickpeterse: output is on line 7 only in your gist?
<yorickpeterse> I'm not following
<maasha> yorickpeterse: I better see if I understand your code properly.
benlovell has quit [Ping timeout: 272 seconds]
<maasha> My code don't work with rubinius, only MRI
<maasha> yorickpeterse: so what is you output variable supposed to be? a yielder?
<yorickpeterse> eh no idea, I just tried to copy it based on your code
<yorickpeterse> also how does it not work on rbx?
<maasha> I htae trheds
benlovell has joined #rubinius
<maasha> yorickpeterse: so this outputs correclty 10, 11, 12 ... 20 in MRI but in rbx it outputs nothing, or it outputs 10 or rarely it completes as expected.
<maasha> oh, and CRASH + segfault :oP
meh` has joined #rubinius
<maasha> funny, adding a puts i at line 14: https://gist.github.com/maasha/d775dd7df701d5cf69b6 outputs i out of order.
<maasha> well, in MRI i goes from 9 .. 0, while in rbx i is random between 0 and 9.
<maasha> I would have expected it to go from 0 up to 9
<maasha> !sdaerht
<maasha> damnit, when it runs in rbx it is more that 2x faster than MRI (I have 2 cores). I want this to work!
<maasha> how come threads.size == 0?
DanielVartanov has quit [Ping timeout: 250 seconds]
jfredett-w1 is now known as jfredett-w
pwh has joined #rubinius
noop has joined #rubinius
DanielVartanov_ has joined #rubinius
<yorickpeterse> maasha: again, you're creating threads per values
<yorickpeterse> There's no guarantee that iterating over enumerators is thread-safe (you're accessing an enum from different threads here)
<yorickpeterse> 1 thread per enum should be more than enough
<maasha> OK, I think I got it in the mean time
<yorickpeterse> https://github.com/rubinius/rubinius/blob/master/kernel/common/enumerator.rb#L78 iterating definitely is not thread-safe
josh-k has joined #rubinius
<yorickpeterse> maasha: threads can have return values, you don't need to use Thread.current
<yorickpeterse> Thread#value returns the return value of a thread
josh-k_ has quit [Ping timeout: 246 seconds]
<yorickpeterse> t = Thread.new { 'foo' }; t.value # => "foo"
<yorickpeterse> for example
<maasha> yorickpeterse: Anyways, it looks like the speedup I see is from rbx being good at calculating fib numbers and not because it does so in parallel. monitoring htop shows only a single thread at work :o(
<maasha> yorickpeterse: aha! t.value
<yorickpeterse> correct about the 1 thread part
<yorickpeterse> You're joining 1 thread at a time
<yorickpeterse> Thus only 1 runs
<maasha> yorickpeterse: well, its complicated :o(
<yorickpeterse> remove line #20, move line #22 into the Thread.new block
<yorickpeterse> You'll need to lock around `enums` though
<yorickpeterse> You can't safely modify arrays from multiple threads
<maasha> yorickpeterse: what line 22 version are you seeing?
<maasha> I tried with Motex.synchronize
<maasha> *Mutex.synchronize
<yorickpeterse> also, in that code the actual work will still be done in 1 thread
<yorickpeterse> gimme a sec
<maasha> yorickpeterse: thing is that i is also not stable: https://gist.github.com/maasha/8a01e3571fc8506a6998
<yorickpeterse> That will still do the actual fib work in the main thread
<yorickpeterse> You're only _creating_ the enum in a new thread
<yorickpeterse> Also, why are you creating 10 enums and only using the last one?
<yorickpeterse> hmpf, this code is too confusing
<maasha> yorickpeterse: sorry, let me try to explain. I have a number of commands that each need to iterate over a bunch of records. This bunch is rather large so they are supplied as an Enumerable rather than an Array. Make sense so far?
<maasha> Now, the output of each command is the input of the next command.
<yorickpeterse> https://gist.github.com/YorickPeterse/c882dc0293ae55ebd346 you'll want something like this
<yorickpeterse> Right, if the next command depends on the previous one you can't run it in parallel
<maasha> yorickpeterse: well, you can. think of bash: cat | grep | sort. each command uses a core. I can do the same in Ruby with threads and IPC using IO.pipe. Now I want to do it with plain thread variables somehow.
<yorickpeterse> You can't run grep if the output of cat hasn't been produced yet
<yorickpeterse> nor can you sort if grep hasn't done its thing yet
<maasha> yorickpeterse: no, but with a lazy enumerator I was thinking that records would trickle through the pipeline.
<yorickpeterse> pipes don't change that, command 2 would still have to wait for command 1 to complete
<maasha> yorickpeterse: I disagree, UNIX pipes pass records down the pipeline on the fly (with IO buffering).
<maasha> hence you can do cat <large file> | head without waiting for all of <large file> to be catted.
<yorickpeterse> Ah, yeah streaming would be possible I guess
postmodern has quit [Quit: Leaving]
<maasha> yorickpeterse: so, I guess me question is if you can fake streaming with Enumerators?
<yorickpeterse> In that case you'd have to adjust the code though, the threads would have to wait until they're signalled to terminate (= no more input)
<yorickpeterse> So the first command gets it input from whatever it is
<yorickpeterse> It then writes, say, a line to some pipe/queue/whatever
<yorickpeterse> the next command takes that, does the same
<yorickpeterse> The moment the first command has no more input it signals the other threads to stop
<yorickpeterse> better: a command signals the _next_ command to stop
<yorickpeterse> each command would be something like
<yorickpeterse> Thread.new { loop { input = some_queue.pop; .....} }
<yorickpeterse> say `input` is something like :stop_processing, the thread would just return
<yorickpeterse> if that makes any sense
havenwood has joined #rubinius
<maasha> yorickpeterse: aint what you are describing the underlying flow of Enumerators and fibers?
<maasha> One could also go async with Celluloid.
<maasha> But I was wondering how far I could get with Rubinius on its own.
<yorickpeterse> Those have nothing to do with it
<yorickpeterse> fibers are just coroutines
|jemc| has quit [Ping timeout: 272 seconds]
<yorickpeterse> If you're using Rbx, you might also want to look into channels
<yorickpeterse> (Rubinius::Channel)
<yorickpeterse> it would be easier if you could just send data directly to a thread
DanielVartanov_ has quit [Ping timeout: 258 seconds]
<maasha> yorickpeterse: yeah, but this thing of mine was designed for MRI and fork. Now it turns out that my fork solutions suffers from IO lag during IPC.
<yorickpeterse> or maybe look into rubinius-actor https://github.com/rubinius/rubinius-actor
<maasha> yorickpeterse: Celluloid is an actor model.
<yorickpeterse> I know that, it's also an option
<maasha> and works on rubinius.
<yorickpeterse> but Celluloid's actor system is pretty heavy
<maasha> heavy?
<yorickpeterse> It spawns a thread for every actor, instead of using a pool
<yorickpeterse> So 500 actors == 500 threads
|Blaze| has quit [Remote host closed the connection]
<maasha> Celluloid can also use a pool AFAIK
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
<maasha> But I cant see how that could help me here with these pesky enumerators.
<yorickpeterse> maasha: because you don't have to use pesky enumerators
<yorickpeterse> You have the main thread, which does two things:
<yorickpeterse> 1) read the input as a stream, whatever it is
<cremes> celluloid spawns a thread for every actor on jruby only; on mri and rubinius it uses fibers backed by a thread pool.
<yorickpeterse> 2) spawn an actor for every command, and tell every actor what the next one is
<yorickpeterse> then send the input to the first actor, which then sends its output to the 2nd, etc
josh-k has quit [Ping timeout: 272 seconds]
<yorickpeterse> Could be that Celluloid changed that, I recall they, for quite some time, just spawned 1 thread per actor
<yorickpeterse> or 1 fiber or w/e it was
<yopp> yeah
<cremes> yes, 1 fiber per actor
<cremes> on jruby there aren’t any coroutines so they are faked with a real thread. i’ve run into this in my production apps a few times.
|Blaze| has joined #rubinius
<maasha> yorickpeterse: ok, thanks. I will need to think about this some more.
<yopp> maasha, you can't allocate 10k actors without allocating 10h threads
<yopp> •10k
<maasha> nope, I was thinking about an actor per command in the pipeline ~ at most 20
<maasha> OK, I gotta run. Thanks for the help yorickpeterse :o)
<yorickpeterse> np
maasha has quit [Ping timeout: 246 seconds]
cezarsa has joined #rubinius
cezarsa has quit [Client Quit]
cezarsa has joined #rubinius
JohnBat26 has quit [Ping timeout: 260 seconds]
pwh has quit []
|jemc| has joined #rubinius
DanielVartanov has joined #rubinius
DanielVartanov has quit [Ping timeout: 245 seconds]
JimmySieben has joined #rubinius
benlovell has quit [Ping timeout: 245 seconds]
pwh has joined #rubinius
tenderlove has joined #rubinius
flavio has quit [Quit: WeeChat 0.4.1]
DanielVartanov_ has joined #rubinius
tenderlove has quit [Quit: Leaving...]
DanielVartanov_ has quit [Ping timeout: 258 seconds]
amsi has joined #rubinius
<yopp> oh lol
<yopp> github.com is now blocked in russia
<Rotonen> any specific grounds officially given for why? also, any wild speculation in different press bubbles about actually why?
<yopp> Rotonen, dunno. It's blocked by request of Russian Consumer Rights Watch Agency
<Rotonen> i sadly have no greater insight in how the russian regulationscape is or is not organized, legalitywise and influencewise
<Rotonen> hard market to tackle and target so i've avoided that so far
travis-ci has joined #rubinius
travis-ci has left #rubinius [#rubinius]
<travis-ci> [travis-ci] seanchas116/rubinius/master (093f029 - Jesse Cooke): The build has errored.
<brixen> yopp: jeez, what the total fuck
<brixen> maybe I should make a nightly tarball then
<yopp> oh fuck
<yopp> there rumours that because of this: https://github.com/amdf/objidlib/blob/master/suicide.txt
benlovell has joined #rubinius
benlovell has quit [Ping timeout: 272 seconds]
pwh has quit []
|jemc| has quit [Quit: WeeChat 0.4.3]
|jemc| has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
<brixen> yorickpeterse: could you link me to your bundler patch and the rubygems threading bug fix?
<brixen> looking at the output on travis for this https://github.com/rubinius/rubinius/issues/3138
noop has quit [Read error: Connection reset by peer]
<brixen> seems plausible that mpapis is hitting that bug
<brixen> of course, forcing update of bundler on rbx for no good reason
<brixen> the way RVM rolls
DanielVartanov_ has joined #rubinius
elia has joined #rubinius
noop has joined #rubinius
havenwood has quit [Remote host closed the connection]
yxhuvud has quit [Remote host closed the connection]
havenwood has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
yxhuvud has joined #rubinius
<|jemc|> is there a way to get the Rubinius::VariableScope for a given Rubinius::Location?
JimmySieben has quit [Ping timeout: 258 seconds]
<yorickpeterse> brixen: gimme a sec
<yorickpeterse> welp, I have a bad headache and I'm out of painkillers
<yorickpeterse> here's to hoping this instant miso soup helps
<yorickpeterse> brixen: considering the patch wont land until 2.5 we can upgrade to stable and apply said patches manually
<yorickpeterse> that way people can at least use bundler 1.6.5 on rbx
<brixen> yorickpeterse: that's my plan
<brixen> yorickpeterse: just finished up some JIT changes and am looking at the console hang now
<yorickpeterse> <3
<brixen> I get it on OS X now that the JIT crash isn't happening anymore
<yorickpeterse> if you need any fill ins just holler, I still remember most of my debugging
<brixen> yorickpeterse: awesome, thanks
<yorickpeterse> tl;dr seems to be that pthread_join() in console.cpp waits forever for a thread hanging in a read() call
<yorickpeterse> in Console::stop_threads() if I remember
<yorickpeterse> * correctly
josh-k has joined #rubinius
JimmySieben has joined #rubinius
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
<yopp> huh
<yopp> yeah, that was because of this suicide.txt
<yopp> they removed github :)
<yopp> censorship is so fucked up
<yorickpeterse> what was it about?
josh-k has quit [Ping timeout: 240 seconds]
<yxhuvud> hrrm. I still get random type errors when running tests :/
<yopp> yorickpeterse, russian gov blocked github because of text with funny ways to kill yourself
<yopp> In Russia, there a special registry of forbidden websites and materials. You can't write about suicide, drugs, and whole bunch of stuff. If they found something like this on your website, it will be included in registry
<yopp> And will be blocked by all ISPs
<|jemc|> coming soon to a government near you
<yorickpeterse> yopp: damn
<|jemc|> it looks like the guy who posted it might have been a ukrainian that was trolling them
postmodern has joined #rubinius
<yopp> yeah. only one way to get out registry — remove the url or block it when accessing from russia
<|jemc|> yopp: looks like it is already out of the registry
<yopp> yeah
<yopp> guy who posted this text removed it
<yopp> and tweets of this registry deputy are hilarious
<bennyklotz> The usage example of https://github.com/rubinius/rubinius-actor throws an error, because a class is tried to include
<bennyklotz> is there an up 2 date documenation anywhere? :)
<bennyklotz> documentation*
<yopp> ahahaha
<yopp> someone forked this stuff
<yopp> I bet they will block them again
<yopp> Because as far I understand thats not a github who removed this text. So since march github just ignored requests to remove it
<yopp> I can't imagine how hey possibly can resolve this
<yopp> It's not like with wikipedia, you can just block URL from one country, you need to tamper with repo
<yopp> or block access
josh-k has joined #rubinius
amsi has quit [Ping timeout: 272 seconds]
JimmySieben has quit [Quit: JimmySieben]
josh-k_ has joined #rubinius
josh-k has quit [Ping timeout: 244 seconds]
DanielVartanov_ has quit [Quit: No Ping reply in 180 seconds.]
JimmySieben has joined #rubinius
amsi has joined #rubinius
noop has quit [Ping timeout: 272 seconds]
<|jemc|> ah, I see, using Rubinius::VM.backtrace(num, true) gives me Locations that have their VariableScope
<|jemc|> kept wondering why Location#variables was coming up nil
pwh has joined #rubinius
JimmySieben has quit [Quit: JimmySieben]
gaustin has quit [Quit: gaustin]
gaustin has joined #rubinius
mrb_bk has quit [Ping timeout: 272 seconds]
machty has quit [Ping timeout: 272 seconds]
mrb_bk has joined #rubinius
machty has joined #rubinius
gaustin has quit [Ping timeout: 244 seconds]
JimmySieben has joined #rubinius
JohnBat26 has joined #rubinius
elia has joined #rubinius
josh-k__ has joined #rubinius
josh-k_ has quit [Ping timeout: 272 seconds]
JimmySieben has quit [Quit: JimmySieben]
JimmySieben has joined #rubinius
ssedov has joined #rubinius
stass has quit [Read error: Connection reset by peer]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
JohnBat26 has joined #rubinius
JohnBat26|2 has joined #rubinius
JohnBat26|2 has quit [Client Quit]
JohnBat26 has quit [Client Quit]
Stranger has joined #rubinius
Stranger is now known as Guest60000
jnh has joined #rubinius
<jnh> hello all.
<jnh> does anyone have any idea when 2.2.11 will be released? I'm waiting on it for my next Huia release.
<|jemc|> jnh: next release will be 2.3
<jnh> at the moment it only works against master because rubinius-compiler doesn't work with 2.2.10
<jnh> ahh
<|jemc|> hearsay says its coming "soon"
<brixen> jnh: RSN
<jnh> damn. and now rvm can't compile rbx-head either :(
<brixen> jnh: don't use RVM
<brixen> I should make tshirts
<brixen> "Don't use RVM\nJust don't"
<brixen> build from a clone and point chruby at it
<|jemc|> you can do the same thing with rbenv if you do a little binstub fix
<|jemc|> which is, admittedly a bit of a pain and a reason to look to chruby instead
<|jemc|> but I'm set in my rbenv ways at the moment
<jnh> is setup_unwind and pop_unwind all I need to rescue exceptions raised further up the stack?
<|jemc|> jnh: those are the right instructions, anyway
<|jemc|> setup_unwind sets up the rescue handler and pop_unwind will remove it
<jnh> so I grab a label for an IP, and pass that into setup_unwind and it'll jump to that IP when there is an exception?
<brixen> jnh: have you run a Ruby example through 'rbx compile' ?
<jnh> no, will do.
JimmySieben has quit [Quit: JimmySieben]
<|jemc|> jnh: there's another argument to pass too
<brixen> jnh: cool, thanks :)
<jnh> the class. got it
<jnh> what about retry and ensure?
<brixen> it's much easier to answer a specific question than a general "how do I...?"
<jnh> fair enough :)
<|jemc|> jnh: there's some nice info in rubinius/vm/instructions.def
<brixen> rbx compile -B -e 'begin puts 1 rescue 2 ensure 3 end'
<jnh> would you believe that that's exactly what I just typed?
<|jemc|> as well as in gems/rubinius-ast-2.2.5/lib/rubinius/ast/exceptions.rb
<brixen> jnh: the rbx compile command I pasted?
<jnh> yah
<brixen> hah
<brixen> great minds something something :)
<jnh> I don't about great
<brixen> me neither :)
JimmySieben has joined #rubinius
<jnh> damn. tried to duck punch arity accessor in Generator#package but caused an RBX segfault :(
Guest60000 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
<|jemc|> heh
<brixen> jnh: can you reduce that code to a simple repro
<brixen> you shouldn't be able to segv rbx from Ruby code
<brixen> modulo FFI of course
<jnh> hrmm. I'll try
<brixen> thanks
elia has quit [Quit: Computer has gone to sleep.]
<|jemc|> brixen: I had one earlier today when trying to compile when variable_scope=nil
<|jemc|> I'll do a minimal repro for that one as well
<brixen> |jemc|: thanks!
<|jemc|> thanks for the tip-off that one shouldn't be able to segv rbx from ruby code
<|jemc|> I had kind of assumed that what I was doing was too invasive to expect that kind of safety, but now that you say it it makes sense that the rbx vm should be checking for garbage-input and failign gracefully
<jnh> undefined method `process_str' on an instance of Rubinius::ToolSets::Segfault::Melbourne
* jnh cries
<|jemc|> jnh: did you require 'rubinius/processor' in your new toolset?
<|jemc|> that's where those process methods come from
<jnh> |jemc|: that did it. tjhanks :)
DanielVartanov_ has joined #rubinius
<|jemc|> no problem - happy to save you some of the head-scratching I endured
<jnh> damn.
<jnh> trying to duck punch attr_accessor :arity onto Rubinius::CompiledCode gives me marshalling errors
<brixen> why are you not just using master?
<jnh> because I want this code to work on 2.2.10 as well.
<jnh> because otherwise no one else wants to try working with my lang if they have to build rbx from master.
<brixen> people want to try your bleeding-edge language but not if they have to use bleeding-edge rbx? :P
<jnh> pretty much
<jnh> also, I can't test it on travis :/
<brixen> heh
<brixen> that's true
<brixen> well, hopefully in the next couple days
<brixen> maybe even tomorrow
<brixen> just have one really nasty issue to fix
havenwood has quit [Remote host closed the connection]
|jemc| has quit [Ping timeout: 245 seconds]
JimmySieben has quit [Quit: JimmySieben]
DanielVartanov_ has quit [Ping timeout: 272 seconds]
<jnh> can rbx build with a system installed llvm or does it need the vendored version?
josh-k__ has quit [Remote host closed the connection]
|jemc| has joined #rubinius
josh-k has joined #rubinius
josh-k has quit [Ping timeout: 260 seconds]