samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
patcon has joined #bundler
<indirect>
dwradcliffe: just got in
<indirect>
what's up?
<dwradcliffe>
indirect: hey!
<dwradcliffe>
I was trying to debug the api outage this morning
<indirect>
oh
<dwradcliffe>
did you fix it?
<indirect>
:(
<indirect>
basically the answer is "enough slow requests overwhelm all the puma worker threads"
<indirect>
and restarting everything clears the request queue
<dwradcliffe>
ok. I'll try that next time
<indirect>
dwradcliffe: in the past, I have always been able to bring it back up with heroku ps:restart, for whatever that's worth
g0bl1n has joined #bundler
g0bl1n has joined #bundler
g0bl1n has quit [Changing host]
slash_nick has quit [Changing host]
slash_nick has joined #bundler
b-dean has joined #bundler
<b-dean>
I am having some really strange encoding issues with bundler 1.3.5 on ruby 1.9.3-p484
<b-dean>
my gemfile is very simple: source 'http://rubygems.org/'; gem 'mixlib-shellout', '~> 1.0'
<b-dean>
when I have that, and bundle exec, strings are encoded ASCII_8BIT by default. not sure why. but if I comment out the ~> 1.0, it's back to UTF-8 like I'd expect
<indirect>
b-dean: have you considered that mixlib-shellout 1.x might be fucking with your encoding settings?
gazarsgo_ has joined #bundler
<b-dean>
that's what I thought at first, but I searched their github for encoding and didn't see anything
gazarsgo has quit [Read error: Operation timed out]
gazarsgo_ is now known as gazarsgo
<b-dean>
also Encoding.default_external is still UTF-8 and internal is nil,
<b-dean>
which is what I'd expect
<b-dean>
also, why would the ~> 1.0 make a difference? it gets the same gem either way
<indirect>
b-dean: if it's the same gem, then you've got me
<b-dean>
>=0 and ~> 1.0 are both 1.3.0, but when Gemfile has '~> 1.0' in it, it somehow has this encoding problem
axl_ has joined #bundler
<indirect>
no idea how that's possible off the top of my head
<b-dean>
ok. I'll see if opscode people have any suggestions and then just start digging through bundler code /shrug
gazarsgo has quit [Quit: gazarsgo]
gazarsgo has joined #bundler
ddd has quit [Quit: to reboot for kernel upgrade]
ddd has joined #bundler
gazarsgo has quit [Quit: gazarsgo]
gazarsgo has joined #bundler
patcon has quit [Remote host closed the connection]
<b-dean>
indirect: do you know if bundler does anything with the encoding of strings when it's processing the Gemfile to set up the environment for a bundle exec? because the string that is showing the weird ascii-8bit in my program is the same string from the version requirement, '~> 1.0'
AntelopeSalad has joined #bundler
<b-dean>
I don't know much about how ruby manages strings but maybe it's caching it somewhere?
<AntelopeSalad>
has anyone ever dealt with "argument list too long" bundler errors?
<indirect>
b-dean: bundler does nothing explicit or particular with encodings that I know of
<indirect>
AntelopeSalad: that's a bash error not a bundler error
<AntelopeSalad>
hmm, it comes from running bundle install programatically tho
<indirect>
AntelopeSalad: sounds like you're running it inside a shell
<indirect>
and passing it too many arguments for the shell to handle
<AntelopeSalad>
thoughts on getting around the issue?
<indirect>
pass it less arguments
<AntelopeSalad>
use case, i'm making a rails app template and i'm using... inside(app_name) { run "bundle install" }
<indirect>
iirc the limit is around 1000 arguments
<indirect>
uhhh
<AntelopeSalad>
which is basically saying "cd into app_name and then run bundle install"
<indirect>
no idea how "run" works
<indirect>
and that looks like zero arguments
<indirect>
so I have no idea where you're getting the error from either
<indirect>
sounds like it's time for a debugger or some debug printing inside the bundle binstub
<AntelopeSalad>
it comes from ruby_executable_hooks which is a bin for rvm i guess
<AntelopeSalad>
it originates from /.rvm/bin/ruby_executable_hooks
<AntelopeSalad>
maybe it's an rvm issue?
<indirect>
AntelopeSalad: sounds like an rvm bug, yeah
<AntelopeSalad>
ok thanks
<b-dean>
indirect: I did some more testing and it's not just mixlib-shellout, I can reproduce this with maybe any gem (I only tried it with two others, rake and rspec, happened both times).
<indirect>
b-dean: feel free to report with a repro case to the bundler issue tracker, then