<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: 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.
<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 :/
<|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
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