|jemc| has joined #rubinius
GitHub187 has joined #rubinius
<GitHub187> rubinius/master 59f0038 Joe McIlvain: Add failing specs for FFI::Library#attach_function accepting an options hash
<GitHub187> rubinius/master df723e4 Joe McIlvain: Rubinius::FFI::Library#attach_function accepts an optional options hash
<GitHub187> [rubinius] brixen pushed 9 new commits to master: http://git.io/o43fbw
<GitHub187> rubinius/master a73e911 Joe McIlvain: Rubinius::FFI:Library#attach_function does NOT accept a Pointer as the c_name
GitHub187 has left #rubinius [#rubinius]
GitHub57 has joined #rubinius
<GitHub57> [rubinius] brixen closed pull request #3158: Accept an options hash passed to Rubinius::FFI::Library#attach_function (master...ffi_attach_options) http://git.io/7QBWMA
GitHub57 has left #rubinius [#rubinius]
<|jemc|> thanks, brixen :)
<brixen> thank you |jemc|!
<brixen> I am getting ever so close to working on llvm :)
<|jemc|> glad to hear it
<|jemc|> but (un)?fortunately I've got lots of other blockers to work on before rbx on arm really becomes a pressing need for me
<brixen> what kind of blockers?
<brixen> or perhaps, blockers that software can fix?
<|jemc|> other project blockers that aren't related to rbx
<brixen> oh
<|jemc|> stuff that requires me programming C and QML instead of Ruby :/
<|jemc|> but hopefully soon I can get back to the ruby stuff
<brixen> cool
elia has quit [Quit: Computer has gone to sleep.]
<brixen> hrm clang ci passed but gcc looks to be hanging
<brixen> of course, not locally
<brixen> guess we'll just sit here looping
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (170be46 - Brian Shirai): The build passed.
travis-ci has left #rubinius [#rubinius]
<|jemc|> heh, whup?
tenderlove has quit [Quit: Leaving...]
<brixen> yeah, damn thing
<brixen> I restarted the hung build
<brixen> I've got it looping in a vbox machine
<brixen> no hang yet
<brixen> really need to make the specs run about 10x faster
<brixen> removing rubygems shaves a good 25% off
<brixen> ah shite, IO.popen
<brixen> these sleep 1000 processes stick around
<brixen> Y U NO DIE WITH KILL
<brixen> they die just fine on os x
<brixen> and they die on linux when run manually
dimday has joined #rubinius
<brixen> hmm, the pid report for the child on linux is wrong
dimday has quit [Ping timeout: 265 seconds]
havenwood has quit [Remote host closed the connection]
<brixen> ahh, because echo ready; sleep 1000 is returning the pid of the sh not sleep
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #rubinius
diegoviola has joined #rubinius
dimday has joined #rubinius
havenwood has joined #rubinius
diegoviola has quit [Quit: WeeChat 1.0.1]
GitHub152 has joined #rubinius
<GitHub152> [rubinius] brixen pushed 3 new commits to master: http://git.io/mZZwYg
<GitHub152> rubinius/master c6399be Brian Shirai: Child inherits the logging.
<GitHub152> rubinius/master ab061c1 Brian Shirai: Only exec one process or we don't get the right PID.
GitHub152 has left #rubinius [#rubinius]
<GitHub152> rubinius/master c463fea Brian Shirai: Simplify unlocking dead thread on fork....
josh-k has quit [Remote host closed the connection]
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (c463fea - Brian Shirai): The build passed.
travis-ci has left #rubinius [#rubinius]
samreh has joined #rubinius
<samreh> anybody able to build with LLVM 3.5 running Yosemite?
havenwood has quit []
meh` has quit [Ping timeout: 245 seconds]
samreh has quit [Quit: Page closed]
byprdct has joined #rubinius
byprdct has quit [Client Quit]
JohnBat26 has joined #rubinius
havenwood has joined #rubinius
havenwood has quit [Remote host closed the connection]
josh-k has joined #rubinius
carlosgaldino has quit [Read error: Connection reset by peer]
carlosgaldino has joined #rubinius
noop has joined #rubinius
josh-k has quit [Remote host closed the connection]
benlovell has joined #rubinius
flavio has joined #rubinius
flavio has joined #rubinius
elia has joined #rubinius
|jemc| has quit [Ping timeout: 255 seconds]
heroux has quit [Ping timeout: 255 seconds]
heroux_ has quit [Ping timeout: 272 seconds]
dimday has quit [Ping timeout: 240 seconds]
heroux has joined #rubinius
heroux_ has joined #rubinius
josh-k has joined #rubinius
<yorickpeterse> morning
flavio has quit [Quit: WeeChat 0.4.1]
flavio has joined #rubinius
flavio has joined #rubinius
<yorickpeterse> So I'm setting up MySQL/PostgreSQL benchmarks
<yorickpeterse> Surprise, I have actual benchmarking code!
<yorickpeterse> No fancy link-bait graphs just yet though
lbianc has joined #rubinius
postmodern has quit [Quit: Leaving]
flavio has quit [Quit: WeeChat 0.4.1]
heroux has quit [Ping timeout: 245 seconds]
heroux_ is now known as heroux
heroux_ has joined #rubinius
benlovell has quit [Ping timeout: 255 seconds]
Bish_ has quit [*.net *.split]
Guest53847 has quit [*.net *.split]
RealMarc has joined #rubinius
Bish has joined #rubinius
benlovell has joined #rubinius
noop has quit [Ping timeout: 240 seconds]
max96at|off is now known as max96at
flavio has joined #rubinius
havenwood has joined #rubinius
benlovel1 has joined #rubinius
benlovell has quit [Read error: Connection reset by peer]
Ngz00 has joined #rubinius
Ngz00 has quit [Ping timeout: 272 seconds]
tenderlove has joined #rubinius
<brixen> yorickpeterse: mysql vs postgresql really?
<brixen> I think the last benchmark between those two that I paid attention to was in '97 or something
<yorickpeterse> Yes, because we're currently using MyFirstSQL, and I'm looking into what to move our Mongo data to
<brixen> anyway, a *much* more important question for today is: What the hell is happening with Node?
<yorickpeterse> Node?
<brixen> a forking or something is in the works
<Rotonen> curious: which database engines and engine settings are you including in your results matrix for mysql?
<yorickpeterse> brixen: meh
<Rotonen> yorickpeterse: why only innodb?
<havenwood> then they yanked the fork after Joyent complained about trademark
<yorickpeterse> Yes
<yorickpeterse> I have no reason to use that crap that is MyISAM
<havenwood> apparently Joyent holds node.js but not node and they're waiting till that gets resolved
<Rotonen> yorickpeterse: did not mean that either :>
<brixen> yorickpeterse: shouldn't you be using hadoop or cassandra?
<yorickpeterse> brixen: we're not cool enough for that
<yorickpeterse> I've calculated we only need ~10GB for our entire DB
<yorickpeterse> instead of the 150 we have now
<yorickpeterse> so we're no longer cool
<yorickpeterse> actually because of the analysis we want to run a SQL DB makes perfect sense
<yorickpeterse> No more Mongo aggregations \0/
<yorickpeterse> Also no distributed hodge-podge-pig-map-reduce-whatever
<Rotonen> being boring is awesome
GitHub193 has joined #rubinius
<GitHub193> [rubinius] brixen pushed 1 new commit to master: http://git.io/Pe4KIw
<GitHub193> rubinius/master 5eabb95 Brian Shirai: Rearrange deleting VMs after fork.
GitHub193 has left #rubinius [#rubinius]
<Rotonen> some company paraphrased that nicely lately, cannot recall which
<yorickpeterse> See, if I get hit by a car I'd never forgive myself leaving behind a Mongo cluster
meh` has joined #rubinius
<yorickpeterse> (ignoring that I might be dead)
<yorickpeterse> With Pg/MySQL I at least know it will (sort of) work
<yorickpeterse> Though I wouldn't trust MySQL with my sister
<yorickpeterse> Pg, maybe
<brixen> I wonder if taking trains makes one more or less likely to be hit by a car
<yorickpeterse> brixen: over here you don't really notice that unless you're 1) in the car 2) at the front of the train
<yorickpeterse> But I think not, at least in my town it's far more likely to get run over by a car when biking
<yorickpeterse> people drive like drunken donkeys
<Rotonen> for me the main issue with SQL is usually dealing with replication latencies (becomes relevant once you have intercontinental this and that in the mix)
<yorickpeterse> RDS doesn't do Pg replication anyway so problem solved :D
<yorickpeterse> Right now we do have Mongo replication, but I don't think we really need it
<yorickpeterse> Writes happen twice a day on larger scale, in between that it's almost only reads (and some small changes like session info)
<yorickpeterse> Plus most of our apps need write access at some point, so setting up a read-only replica would only work for a small percentage
<brixen> what's happening with rake these days?
* brixen clones repo, tries bundle, no Gemfile, tries rake -T, no hoe WTF throws computer against wall
<brixen> so, who is using 32bit?
<brixen> apple announced that by feb 1, uploads to app store must have 64bit support
<Rotonen> for good reason too - the performance boost of being able to do magic with embedded pointers is quite hefty
<brixen> tempted to remove 32bit support from rbx in a few months
<brixen> there's that, yes
<brixen> there's also a bunch of memory layout stuff I want to do
<brixen> but yeah, with 64bit you basically get 2 (32bit) word CAS
<brixen> which makes a lot of lock-free stuff a bunch easier
<Rotonen> there were some fears that 32bit might make one revenge of a comeback in arm blade servers, but 64bit is going to be the way of those if they ever pop up
<brixen> I thought ARM was pushing 64bit
<Rotonen> currently, sure
<Rotonen> ~4 years ago it was just an idea, though
<brixen> well, what's the worst that would happen if we remove 32bit support?
<Rotonen> while arm really wanted to push into low power servers then, but the market of those did not catch on, due to PaaS and cloud offerings tickling beancounters the right way
<brixen> also, I'm only talking the runtime here
<brixen> the native code stuff would support 32/64bit
<brixen> intel is going full on super-low power support but afaik it's all 64bit
<Rotonen> i come from ye olden unix with larger memspaces and wacky stuff that allowed so i am quite anti-32bit to begin with, i might not be a sensible party to discuss this with as i have a clearly biased stance based on past technological arrogance
<chrisseaton> brixen: we've gone all in - Graal is 64bit only
<brixen> Rotonen: I'm most interested in supporting people like you :)
<brixen> rake is so ugh
<Rotonen> brixen: how about bringing back the concept that you can just span memoryspace across computers via pointers if you point outside your own space, then? :-)
<brixen> would someone just rewrite it in Go already so we can be done with it
<brixen> Rotonen: is this a plan9 thing?
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
<Rotonen> no, older and uglier
<brixen> heh
<brixen> Rotonen: I'm most interested in smaller, meaner, faster little things and better messaging
<brixen> all running on 64bit :)
<Rotonen> a mainframe could have some subunits where pointerspace was simply a table of what pointer goes where, usually in a repeating hierarchy of cache->ram->disk->tape->cache->ram->disk->tape...
<Rotonen> so you simply had to know, apart from the tape bit, what you are directly poking
<brixen> I'm a proponent of safe, selective poking
<brixen> especially if it's direct
<Rotonen> but unlike these days you did not much have to care about what and how things were connected so long as they were in the same memoryspace
<Rotonen> apple is actually doing something a bit like this with how the game center turn passing feature has been done
<Rotonen> you actually just plop objects from one obj-c virtual machine to another
<Rotonen> but the manipulation is limited, of course
<Rotonen> merely mostly just passing it around
<Rotonen> technically that is just serialization and HTTP (or such), but what the programmer is presented is reminiscent of older things
<brixen> mobile code has a long and sordid past
<Rotonen> yeah, i've seen some object caml used in cell tower routing :>
<brixen> well, looks like I fixed the fake array specs for rake
<brixen> but is the fix worth it?
<brixen> such a nasty pile of code
benlovel1 has quit [Quit: leaving]
JohnBat26 has joined #rubinius
<brixen> hm, the other failures look related to backtrace text mining
josh-k has quit [Remote host closed the connection]
josh-k has joined #rubinius
meh` has quit [Ping timeout: 272 seconds]
josh-k has quit [Ping timeout: 244 seconds]
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (5eabb95 - Brian Shirai): The build was broken.
travis-ci has left #rubinius [#rubinius]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
enebo has joined #rubinius
diegoviola has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
elia has quit [Client Quit]
flavio has quit [Quit: WeeChat 0.4.1]
JohnBat26 has joined #rubinius
meh` has joined #rubinius
diegoviola has quit [Quit: WeeChat 1.0.1]
<brixen> I have this vision of simple, interacting components and then my vision smashes headlong into C++
<max96at> that sounds familiar....
elia has joined #rubinius
<yorickpeterse> brixen: sounds like Unix :P
<yorickpeterse> clearly we need to rewrite Rbx in Rust
<yorickpeterse> because then it never crashes
elia has quit [Ping timeout: 255 seconds]
postmodern has joined #rubinius
<yorickpeterse> unrelated news, ./configure is quite the maze
<brixen> yorickpeterse: what are you looking at in configure?
<yorickpeterse> brixen: pain
<yorickpeterse> it was for https://github.com/rubinius/rubinius/issues/3162, but I _do_ have LLVM installed so I'd have to stub a few things to test it
<yorickpeterse> plus I'd much rather fix my CSS grammar for now :P
<yorickpeterse> (started re-writing it from scratch last night at 2AM)
<yorickpeterse> actually surprised how far I got
<yorickpeterse> and how clean it is
<brixen> yorickpeterse: probably going to remove llvm prebuilts
<brixen> just considering what to do with 12.04 right now because Travis
<yorickpeterse> Ah, Ubuntu still on 3.2?
<brixen> dunno
<yorickpeterse> Rotonen: I meant LLVM, not the kernel
<Rotonen> well, query modification should answer
<yorickpeterse> hm, 3.2, 3.4 and 3.5
<yxhuvud> seems a bit optimistic.
<brixen> perhaps
noop has joined #rubinius
<yxhuvud> (is it really still jit if the targets for jitting is declared?)
<brixen> JIT is a very broad term
<brixen> it literally means, just-in-time X
diegoviola has joined #rubinius
<yorickpeterse> I liked that JIT for MRI where they just called "cc" under the hood
<yorickpeterse> https://github.com/imasahiro/rujit this one
<yxhuvud> well, that at least has some believable shot of reaching C speeds :P
<yorickpeterse> raptorjit
<yorickpeterse> 4x faster than LLVM
<yorickpeterse> 2x faster than C
<yorickpeterse> Sign up here
<Gibheer> written in a lisp build on rust?
<yorickpeterse> *head explodes*
<chrisseaton> I tried to experiment with rujit but couldn't get it to compile when it was first released - has anyone else tried it?
<brixen> yxhuvud: in case you didn't know, MRI runs at C speeds
<yxhuvud> ah yes, I suppose. I meant without the layers over even more layers of abstraction.
<yorickpeterse> https://ind.ie/phoenix/ ha
<yorickpeterse> another language fork, also possibly vaporware
<yorickpeterse> "However, there is one area where you are falling behind Google, and that's in openness."
<yorickpeterse> "google" "openness"
<yxhuvud> openness is not a binary scale (in this frame of reference). While google certainly has more than a few issues, isn't apple about as far from being open you can get?
josh-k has joined #rubinius
<yorickpeterse> yxhuvud: Google certainly is less closed, but I'm not sure if it's a good company to compare yourself to
<yorickpeterse> Code wise they open sauce quite a bit, but I'd love to see them be more open about the NSA stuff and such (so basically more on a political level)
<yorickpeterse> Google also very much has this attitude of "Our way or the high way"
<enebo> chrisseaton: I saw his rujit talk and noticed that the tracing engine must have a massive amount of overhead
<headius> chrisseaton: I'm pretty sure this is based on a version I tried a couple years ago
<enebo> headius: It is not based on anything ko1 mentored
<enebo> headius: and he claimed he started it this spring
<headius> enebo: that's bizarre if true...I find it fascinating that there'd be another trace-based offline profiling JIT that uses cc for MRI
<yxhuvud> it is certainly nice that the japanese fraction of the community has started to play with the concept though.
<enebo> headius: offline?
<headius> well perhaps this one doesn't have that issue
<headius> in the other one, you had to pass a flag and run your app...it would run very slowly and profile that code, and then emit C to be compiled that represented it
<headius> it was able to get native numeric perf, for example, but it wasn't really practical for general use
<enebo> headius: This one runs tracingng profiling JIT and when it fails it runs like 2x slower than without rujit
<enebo> headius: This one currently also only targets loops
<enebo> which perhaps is the common thing in a tracing JIT
<headius> oh, so it's even more limited than I thought
<headius> the other one eliminated dynamic calls, float boxing, some other stuff
<headius> it actually profiled the whole app, calls and all
<enebo> headius: yeah I think so. I think he said he spent less than 2 months working on it as a side project
<headius> ok
<enebo> headius: but I think he is doing simple math
<enebo> headius: The numeric results were very good in what he showed
meh`_ has joined #rubinius
<chrisseaton> MRI needs a bog-standard template JIT that just emits some standard code for every YARV instruction to eliminate dispatch overhead - that would get something that could build on
meh` has quit [Ping timeout: 250 seconds]
|jemc| has joined #rubinius
<headius> chrisseaton: I guess nobody wants to write that because it's not exciting enough :-)
havenwood has quit [Remote host closed the connection]
<chrisseaton> it also wouldn't achieve any kind of exciting speedup
<headius> probably not
<headius> they might be able to compile out a lot of branching in the interpreter
havenwood has joined #rubinius
noop has quit [Ping timeout: 265 seconds]
elia has joined #rubinius
GitHub116 has joined #rubinius
<GitHub116> [rubinius] brixen pushed 7 new commits to 1.8.7: http://git.io/A26PVA
<GitHub116> rubinius/1.8.7 5cae6b0 Brian Shirai: Restrict Bundler to 1.6.3 for now.
<GitHub116> rubinius/1.8.7 6ccff51 Brian Shirai: Restrict rubinius-toolset to 2.2.x for now."
<GitHub116> rubinius/1.8.7 735272a Brian Shirai: Updated Changelog.
GitHub116 has left #rubinius [#rubinius]
max96at is now known as max96at|off
elia has quit [Quit: Computer has gone to sleep.]
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/1.8.7 (64f2394 - Brian Shirai): The build passed.
travis-ci has left #rubinius [#rubinius]
elia has joined #rubinius
<yorickpeterse> racc conflicts щ(゚д゚щ)
<yorickpeterse> makes no sense for the grammar to conflict here, but it does :/
<yxhuvud> how does your grammar look like?
<yorickpeterse> it seems to conflict in the `node_test` rule according to the grammar debug output
<yorickpeterse> ergh, might as well gist that too
<yorickpeterse> added
<yorickpeterse> You can solve it by adding a terminal in between, but I'm trying to get rid of that
<yorickpeterse> (in between the "selector selector" rule)
<yxhuvud> if I understand it correctly, it is saying that given node_test : node_name _, it doesn't know if it should reduce or shift another symbol.
<yorickpeterse> not sure what the underscores are for
<yorickpeterse> racc docs are...lacking
<yxhuvud> hmm. could they signify the dot in the lr item?
<yorickpeterse> but not sure what does
<|jemc|> yorickpeterse: I think you need the terminal in between
<yorickpeterse> Oh, I guess that's where it's currently pointing to in said state
<yorickpeterse> |jemc|: nevah!
<yorickpeterse> If I add a terminal it makes other rules a lot more complex
<yxhuvud> yes, definitely the dot then.
<yorickpeterse> Initially the terminal was T_SPACE
<yorickpeterse> so I had
<yorickpeterse> selectors T_SPACE selector
<|jemc|> as it stands now, when it is looking for 'selectors' and it encounters a 'selector' it has no way of knowing if it is done with 'selectors' or not because you don't have lookeahead
<yorickpeterse> but that messes up selectors such as "X > Y" which don't emit T_SPACE
<yorickpeterse> since "X>Y", "X > Y" and "> Y" are all valid
<yxhuvud> jemc: doesn't racc do lookahead though? or isn't that applied automatically?
<yorickpeterse> |jemc|: ehm, racc is LALR
<yorickpeterse> it sure as hell has lookahead, otherwise it wouldn't be LALR
<yxhuvud> LALR(0) ;)
<yorickpeterse> Racc is LALR(1)
<|jemc|> well, that's one token further than it can look, I mean
<yorickpeterse> hm
<yorickpeterse> argh
<|jemc|> when I was using racc and ran into stuff like this I always needed an 'end anchor' for rules like that
<|jemc|> at least that's how I ended up solving them, there may be other ways
<yorickpeterse> well, CSS makes this really fucking hard
<yorickpeterse> e.g.
<yorickpeterse> ".x.y#foo[bar]:root" this is one rule
<yorickpeterse> ".x.y#foo[bar]:root y" 2 rules
<yorickpeterse> so there whitespace has meaning, and is the terminal
<yorickpeterse> but for "x > y", "x ~ y", etc, it's not
<|jemc|> is the 'selectors' rule intending to match either one or two rules but not zero or more than two?
<yorickpeterse> As such, adding T_SPACE as a terminal means that "x>y" would not be valid, unless the lexer were to always emit T_SPACE in that case
<yorickpeterse> |jemc|: yes, it's a dummy example before I add full recursion
<yorickpeterse> since that adds more conflicts
<yxhuvud> You may have to break up the grammar into smaller parts, (while waiting for me to finish my implementation of marpa)
<yorickpeterse> so the hack I can do is this:
<|jemc|> is there some rule you can expect to always follow the selectors rule? that would make this easier
<yorickpeterse> "X > Y" is [IDENT, SPACE, GREATER, SPACE, IDENT]
<yorickpeterse> errr
<yorickpeterse> "X>Y" is [IDENT, SPACE, GREATER, IDENT]
<yorickpeterse> but then I have to hack the lexer to also do this:
<yorickpeterse> " >Y" is [GREATER, IDENT]
<yorickpeterse> so it would have to always emit a single SPACE in case of "X>"
<yorickpeterse> or "X >"
<yorickpeterse> hm, maybe I can rip Nokogiri's CSS parser
<|jemc|> wait, in this grammar, selectors is always followed by EOF
<|jemc|> because it's the entire grammar
<|jemc|> (disregarding empty)
<|jemc|> so you can use the EOF token as your 'end anchor' for the rule
<yorickpeterse> hm?
<|jemc|> I'll gist what I'm thinking
<|jemc|> or, to be faster, I'll just show a comparable example
<yorickpeterse> well, there's no definitive terminal in my case, EOF is only at the end of the entire input string
<yorickpeterse> hm, unless I use T_SPACE for that
<yorickpeterse> lemme see
<|jemc|> ah, I was just looking at your gist and thought the grammar was strictly: 'selectors',EOF or /*empty*/,EOF
<|jemc|> but I guess you've got more to add
<yorickpeterse> ah crap no, that still requires my lexer hack
<yorickpeterse> Fuckit, I'll make it so that "x > y" emits [IDENT, SPACE, GREATER, IDENT]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
<yorickpeterse> right, that hack wasn't so bad
elia has quit [Read error: Connection reset by peer]
elia has joined #rubinius
elia has quit [Read error: Connection reset by peer]
elia has joined #rubinius
<brixen> I would say that it would not be an exaggeration to say that the JIT is not operating even near half as good as it could
<brixen> which is to say, as it could with a very small number of tweaks and no major reorganization
<brixen> on the other hand, debugging JIT issues may even top debugging GC issues
<brixen> also, unix is stupid
<brixen> I wish someone besides M$ would replace it already
GitHub58 has joined #rubinius
<GitHub58> [rubinius] brixen pushed 3 new commits to master: http://git.io/mfB5dw
<GitHub58> rubinius/master 8dfce37 Brian Shirai: Deal with liars like Rake....
<GitHub58> rubinius/master 47c3aac Brian Shirai: More cleanup around fork+exec.
GitHub58 has left #rubinius [#rubinius]
<GitHub58> rubinius/master 47380b8 Brian Shirai: Added proper logging to util/thread.
<chrisseaton> brixen: I did a review of the rbx jit when I started at Oracle, and if there is a reason that the JIT is not as good as it could be it's that the JIT doesn't get chance to see most of your code. I used the example of Fixnum::div. This is implemented in C++, right? So the JIT never gets to do anything with this most basic operation. It can't constant fold
<chrisseaton> through it, it can't turn the corner cases into uncommon traps, it can't be optimistic about it - it's just a black box that LLVM has to give up with. And that's for a basic arithmetic operation.
<brixen> chrisseaton: now tell me something I don't already know :)
GitHub179 has joined #rubinius
<GitHub179> [rubinius] brixen pushed 1 new commit to master: http://git.io/QhBkPQ
<GitHub179> rubinius/master 1d3ebe5 Brian Shirai: Re-open logger in the child after fork()....
GitHub179 has left #rubinius [#rubinius]
<brixen> how do these damn files not get cleaned up...
<brixen> oops, pushed that too soon
<brixen> multitasking fail
GitHub16 has joined #rubinius
<GitHub16> [rubinius] brixen pushed 1 new commit to master: http://git.io/sNeppA
GitHub16 has left #rubinius [#rubinius]
<GitHub16> rubinius/master 2a0ef47 Brian Shirai: Fixed variable declaration.
diegovio1 has joined #rubinius
meh`_ has quit [Ping timeout: 265 seconds]
diegoviola has quit [Ping timeout: 265 seconds]
enebo has quit [Quit: enebo]
travis-ci has joined #rubinius
<travis-ci> rubinius/rubinius/master (2a0ef47 - Brian Shirai): The build was fixed.
travis-ci has left #rubinius [#rubinius]
|jemc| has quit [Quit: Page closed]
diegovio1 is now known as diegoviola
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #rubinius
elia has quit [Client Quit]
<brixen> ahh if you HUP the process it dies and doesn't clean up