00:02 <brixen> Bish: what version of Rails?

00:02 <Bish> 4.2

00:02 <brixen> pretty sure they've patch it but may not be released yet

00:02 <brixen> check on HEAD to see if that's been fixed

00:02 <brixen> then you'll need to edit your Gemfile to put it in a platforms :mri block

00:23 <Bish> brixen, which head, and can i simply remove the 'gem 'byebug'' line in the gemfile?

00:24 <Bish> well looks like that is possible :3

00:24 <Bish> rubinius does not come close to MRI in rails performance, right?

00:34 <|jemc|> Bish: depending on what you're doing, rubinius performance may be either better or worse than MRI

00:35 <Bish> well, it sounds funny, but i played around with rbx alot already, and i feel it is less painful than the others

00:35 <Bish> but i never seen it being faster

00:35 <|jemc|> if your application can take advantage of the true concurrency and the JIT, you are more likely to get better performance than MRI

00:35 <Bish> what about a simple rails app.. nothing special?

00:36 <|jemc|> however, at the moment, startup times will almost always be slower, and once you're loaded, the JIT takes time to warm up

00:36 <Bish> i figured, i gonna keep testing because i failed at installing rails in MRI ^^.. why so ever

00:36 <Bish> somehow i fucked up my system ruby-wise, and rubinius is the only which works for me right now :D

00:39 <Bish> if the jit heats up, and will be only a bit slower than MRI, than everything is cool, that is a tradeoff i would like

00:40 <Bish> s/than/then

01:14 <RageLtMan> Bish: RBX works well as a server platform due to the concurrency model and JIT - we've had rails apps "figure themselves out" days after boot because of usage patterns. One good example is a geospatial analysis system... over time i gets a hell of a lot better at figuring out traversals across a curved surface

01:15 <Bish> why is the startup time so big, though?

01:19 <RageLtMan> Because its self-compiling

01:20 <RageLtMan> RBX is written largely in Ruby, so the compiler builds a low-level scaffolding of object primitives in C++ and uses them to bootstrap a pure-ruby version of ruby

01:20 <RageLtMan> Comparably, MRI isn't very "ruby" at all :)

01:21 <RageLtMan> (take a look at the innards of MRI or Perl runtimes if you want to spend the rest of your days in a padded room with an oversized coat)

01:23 <Bish> i know how rubinius works, but i am wondering, isn't it able to cache the precompiled file

01:23 <Bish> i know it does something like that in .rbx, but i never looked into it in detail

01:23 <Bish> or does the .rbx only concern the jit?

01:26 <|jemc|> Bish: if it helps, there are (at least) two conceptual stages of compilation here - ruby code to rubinius bytecode and rubinius bytecode to native machine code

01:27 <|jemc|> the JIT is the compiler that does the latter transformation

01:28 <|jemc|> the *.rbc files and those files you see cached in the .rbx dir contain representations of the "middle" stage - rubinius bytecode

01:29 <Bish> that doesn't answer the question why caching them doesn't speed up the "load"

01:34 <|jemc|> it does if you think about the other parts of compilation that still need to happen

19:05 <heftig> Bish: it does.

19:05 <heftig> no cache: rbx -e 'puts 1' 0.69s user 0.02s system 135% cpu 0.525 total

19:05 <heftig> cached: rbx -e 'puts 1' 0.24s user 0.02s system 102% cpu 0.248 total

19:12 <heftig> well, to be fair the uncached time also includes writing out the cache files

20:40 <mustmodify> I'm experiencing an infinite loop in Rubinius 2.5.2 but not MRI. I'm trying to find create a simple repo. I'm wondering if anyone can tell me WHAT IS GOING ON IN THIS METHOD. It's kind of rediculous. https://github.com/Wardrop/Scorched/blob/master/lib/scorched/options.rb#L18-L20

20:40 <brixen> mustmodify: I already answered this

20:41 <brixen> on the ticket you opened about it

20:41 <mustmodify> brixen: Did you? I didn't get an email.

20:41 <mustmodify> drat.

20:41 <mustmodify> stupid email clients hiding interesting emails from me.

20:42 <brixen> https://github.com/rubinius/rubinius/issues/3309

20:44 <mustmodify> thanks. Yeah, I thought it was something like that but the specifics were eluding me. Thanks. I'll see if I can make that better.

20:47 <mustmodify> So if I understand your post correctly, the reason it works in MRI is because C won't call the overriden methods because they're ruby methods, not C methods... is that right?

21:07 <|jemc|> @mustmodify correct, more or less

21:09 <brixen> mustmodify: anything object that overrides an ancestor method needs to preserve that method's contract

21:10 <brixen> mustmodify: in Ruby, this is complicated by the fact that methods on classes are not partitioned into primitive operations and compositions of those operations

21:10 <brixen> so, when you override a method, you don't know what may depend on it

21:10 <brixen> but in general, you can't go very wrong by following liskov

21:10 <brixen> and you can go very wrong indeed by disregarding liskov

21:10 <brixen> in Scorched code, there is just absolutely no reason to be structured like that

21:11 <brixen> compose a Hash and provide your interface

21:11 <brixen> Scorched *isn't* a Hash and shouldn't try to fake being one

21:12 <mustmodify> I agree it is senseless.