goyox86 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yopp has quit [Ping timeout: 264 seconds]
yopp has joined #rubinius
noop has quit [Ping timeout: 240 seconds]
|jemc| has joined #rubinius
JohnBat26 has joined #rubinius
diegoviola has joined #rubinius
sshao has joined #rubinius
mustmodify has joined #rubinius
<mustmodify>
So I'm setting up a new server ... trying rubinius in production now that I finally understand Puma enough to use it. The new run is that tasks seem to be dying after taking a while to perform. All I get back is the message "Killed" ... is Rubinius generously telling me to take a coffee break? Or can I blame something else in my stack?
<brixen>
ie, default is to log to /var/log/$PROGRAM_NAME.log
<brixen>
where PROGRAM_NAME may be rbx or ruby depending on how it's built
<brixen>
also, get your statsd set up and set rbx to emit
<brixen>
then start debugging this
<mustmodify>
ok I'll let you know what I find.
<brixen>
mustmodify: 6 month in rbx time is like 10 years in people time ;)
<mustmodify>
dog years.
<mustmodify>
rbx years.
<brixen>
basically, the inverse of dog years
<mustmodify>
so dogs using rbx would experience...
<mustmodify>
hm...
<mustmodify>
it's like traveling at the speed of light.
<brixen>
I mean, look at the changelog for MRI from 2.1.0 to 2.2.0 and look at the change log for rbx from 2.2.10 to 2.4.1
<mustmodify>
you go to work, come back, and everyone is 20 year older.
<mustmodify>
or younger.
<brixen>
I wish :)
|jemc| has quit [Ping timeout: 244 seconds]
<brixen>
ok, let's see if I can ditch syck for bootstrapping yaml again
<mustmodify>
brixen: I was just fighting with pysch. :)
<brixen>
did you kill it?
<brixen>
I'll literally name a release of rbx after the person who kills psych
<mustmodify>
I lived to fight another day. capistrano changes your bin directory and I told it to stop doing that. It caused some kind of disaster. I said, "never mind."
diegoviola has quit [Ping timeout: 255 seconds]
goyox86 has joined #rubinius
<mustmodify>
brixen: Still waiting for you guys to name a release after Jim Weirich
<mustmodify>
what is it you dislike about psych?
<brixen>
it depends on libyaml
<brixen>
which is not well distributed
<brixen>
for example, heroku does not have it installed
<mustmodify>
oh right, I was reading about that.
<brixen>
since we don't cram everything into our lib dir but instead use gems as Jim et all intended, rbx can't run normally on heroku
<brixen>
s/et all/et al/
<mustmodify>
I can't decide whether heroku is dumb for not including that, or whether psych is dumb for ... whatever. But psych's docs say they include it now?
<brixen>
mustmodify: where does it say that?
<mustmodify>
(hits back button furiously)
<mustmodify>
Sorry, that was nokogiri. "As of Nokogiri 1.6, libxml2 and libxslt source code is bundled with Nokogiri, and compiled at gem-install-time. This document should work for all versions 1.6.4 and later."
<brixen>
yeah, that's a fun one, too
<brixen>
"hmm, seems like my gem installs have hung on this mini-portile thing..."
<brixen>
10 min later, "Installed nokogiri"
<brixen>
rubygems should just use "Installing nokogiri..."; do something; "\rInstalled nokogiri"
<mustmodify>
I was doing a really great job of documenting my server setup process and now I'm totally off-the-wagon on that one. I couldn't reproduce this server if I tried.
<brixen>
so yeah, add nokogiri to the list of things I'll name a release after you if you kill
<brixen>
pretty sure yorickpeterse is well on his way to having his own named release
<yorickpeterse>
wut?
<brixen>
yorickpeterse: for replacing nokogiri you should get an rbx release named after you :
<brixen>
er :)
<brixen>
so what the hell is bundler writing to .bundle/config now?
<flavorjones>
so, how can I help nokogiri to support rubinius? any ideas?
<brixen>
flavorjones: yes!
<brixen>
don't use libxml2
diegoviola has joined #rubinius
<flavorjones>
I'd love to hear alternatives :)
<brixen>
we're working on it
<brixen>
check out yorickpeterse's Oga
<flavorjones>
Yeah, I checked it out.
<brixen>
flavorjones: I have spent days trying to debug libxml2 and its use of the specified allocators
<flavorjones>
Yup, saw that open issue as well ...
<brixen>
the only thing I can conclude is that on certain operations, it deletes nodes in a way that is not visible
<brixen>
hence the Ruby linkage isn't updated
<brixen>
and mark is called on free'd memory
<brixen>
I'm not spending any more time trying to debug it
<flavorjones>
It's possible, if you can help me repro I can look into it. I think I know libxml2's patterns better than most at this point
<brixen>
there's a ticket somewhere
<flavorjones>
But I had trouble getting Rubinius to build on my linux machine last week and pushed it off
<brixen>
I simply don't have time or interest in debugging it anymore
<brixen>
the approach is flawed
<brixen>
I'm going to replace it with a system that doesn't need a C-ext
<flavorjones>
Mmm. I saw the ticket, I'm saying I'll help debug
<brixen>
flavorjones: what was the issue building rbx?
elia has quit [Quit: Computer has gone to sleep.]
<flavorjones>
One sec
<brixen>
we get segvs with nokogiri all the time in production on MRI
<brixen>
completely sporadic
<brixen>
no hope of debugging it
<flavorjones>
Anything's possible, standardizing on a version of libxml2 was an important first step towards addressing the long tail of libxml2 issues
<brixen>
oh for sure
<brixen>
I'm not making light of the tremendous effort
<brixen>
just saying that effort, and all the Java work, could have gone into a non-implementation specific, not C-specific real library
<flavorjones>
I wonder: when you see crashes, are you using Reader? The API is known to be unsafe
<brixen>
that's the siren song of "just wrap this C library and we're golden"
<brixen>
after more than a decade of it, I can spot that a mile away
<flavorjones>
Agree, I'd love to be able to replace libxml2 with something better. But that's a lot of surface area.
<brixen>
flavorjones: I don't know the systems in detail enough to tell you, I just get told of the issues
<brixen>
we do a ton of XML parsing and some XML generation
<brixen>
pretty sure when I was debugging it on rbx, it was only parsing
<brixen>
the poor FFI perf on MRI probably could have been addressed
<flavorjones>
I'm told it has been since, but I'm past it
<brixen>
FFI is the only native-ish option for cross-implementation compatibility though
<brixen>
so the fact that it's a crap pile of nonsense now just sucks
<brixen>
but also, I don't care anymore
<brixen>
so whatever
<flavorjones>
hey, rbx 2.4.1 is building for me now. *shrug*
<brixen>
FFI is getting a massive face lift in rbx 3.0
<brixen>
flavorjones: weird
<flavorjones>
it was a clang issue with libstdc++, I think ... a flavor of "cannot find -lstdc++", except I *do* have it installed. well, whatever. I'll see if I can repro https://github.com/sparklemotion/nokogiri/issues/1047
<brixen>
flavorjones: btw, allocation rate appears to affect that repro
<brixen>
ie, use more threads, hit it sooner
<brixen>
but the number of things in play there are hard to disentangle
cypher23 has quit [Ping timeout: 246 seconds]
<brixen>
allocation pressure can cause objects to be allocated in mature zones
<brixen>
it can obviously change gc interleaving
<brixen>
it can impact concurrent gc interleaving
<brixen>
etc
<brixen>
I instrumented all the alloc, dealloc, mark calls
<brixen>
there was a very clear pattern of alloc, no dealloc, mark -> segv
cypher23 has joined #rubinius
kfpratt has joined #rubinius
<flavorjones>
Anything I should know about rbx's concurrent GC going in?
DanielVartanov_ has quit [Ping timeout: 244 seconds]
<brixen>
you can disable it
<brixen>
-Xgc.immix.concurrent=no
<brixen>
flavorjones: ^^^
<flavorjones>
roger
<brixen>
flavorjones: you can also force a lock around C-exts -Xcapi.lock=yes
<brixen>
but just because the segv does not happen doesn't mean anything
<flavorjones>
Hey, my rbx build problem is apparently related to `rvm`, which fails with '/usr/bin/ld: cannot find -lstdc++'
<brixen>
don't use RVM :)
<flavorjones>
tarball builds fine. nod.
havenwood has joined #rubinius
<yorickpeterse>
flavorjones: We don't use Reader, just regular XML::Document/HTML::Document
<flavorjones>
OK
amsi has joined #rubinius
pietr0 has joined #rubinius
mustmodify has left #rubinius [#rubinius]
DanielVartanov_ has joined #rubinius
benlovell has quit [Ping timeout: 244 seconds]
goyox86 has quit [Read error: Connection reset by peer]
<yorickpeterse>
brixen: chruby already requires re-installing all gems between every release I believe
pietr0 has joined #rubinius
kfpratt has quit []
<brixen>
yorickpeterse: it doesnt'
<brixen>
er doesn't
<brixen>
we hit this constantly
<yorickpeterse>
huh? Every time I update some Ruby I have to re-install all my gems
<brixen>
oops, forgot to push a gem
max96at is now known as max96at|off
<yorickpeterse>
right, MRI 2.2 now suddenly adds warnings for duplicate Hash keys
<yxhuvud>
yorick: when constructing a hash using literals? makes more sense than the time.parse issue
<yorickpeterse>
Yeah, so {:a => 10, :a => 20} produces a warning
<yorickpeterse>
even when not using -W
<mustmodify>
brixen: When changing versions of Ruby with chruby, do I need to tell gem to clean out the attic?
<brixen>
yorickpeterse: are you serious?
<yorickpeterse>
brixen: yes
<yxhuvud>
are there any other warnings that are output when not running -W?
<yorickpeterse>
yxhuvud: not that I can see so far
<mustmodify>
yxhuvud: I guess we'll just have to find out as they happen. :)
<yxhuvud>
if not it seems very weird. surprise output from programs is :(
<brixen>
travis is weird, restarted build, 3 workers fail anyway, one worker appears to be progessing
<brixen>
yorickpeterse: that's pretty weird
<yorickpeterse>
brixen: I actually recall complaining about it to postmodern at some point because I hated having to re-install my Gems on minor releases
<brixen>
yorickpeterse: just in case you misunderstood, my "are you serious" was about hash warning
<brixen>
I guarantee current version of chruby puts all gems for rbx in ~/.gem/rbx/2.1.0
<brixen>
and rubygems puts explicit shebangs in bin wrappers
<brixen>
rubygems has that gem pristine thing
<yorickpeterse>
brixen: oh right
<yorickpeterse>
But yes, I'm serious about the warning
<yorickpeterse>
also hm
<yorickpeterse>
it seems that for rbx it does indeed smack it in rbx/2.1.0
<yorickpeterse>
but for MRI it doesn't
<yorickpeterse>
right
<yorickpeterse>
"/home/yorickpeterse/.gem/ruby/2.2.0/gems/ansi-1.4.3/lib/ansi/chart.rb:26: warning: duplicated key at line 29 ignored: :concealed" re the hash warning
<brixen>
yeah, it's the RUBY_VERSION
<brixen>
what?!
<brixen>
"ignored"
<brixen>
what the hell
<brixen>
that's not just a warning, that changes behovior
<yorickpeterse>
it does still overwrite the initial key