<LordHeini>
hi am i right that the highest ruby version compatible with jruby is 2.3.1?
sebastia1 has joined #jruby
<sebastia1>
exit
sebastia1 has quit [Client Quit]
knu has quit [Quit: Reboot...]
olle has quit [Quit: olle]
knu has joined #jruby
Lord_Hei1i has joined #jruby
Lord_Hei1i has quit [Client Quit]
Lord_Hei1i has joined #jruby
alex0ptr has joined #jruby
Lord_Hei1i has quit [Client Quit]
olle has joined #jruby
alex0ptr has quit [Ping timeout: 255 seconds]
LordHeini has left #jruby [#jruby]
Lord_Heini has joined #jruby
alex0ptr has joined #jruby
cheba_ has joined #jruby
<cheba_>
Hello! I’m observing weird behaviour. bundler can install all gems but then it can not find them on a consequent run of `bundle exec`. Here’s an example: https://travis-ci.org/prawnpdf/prawn/jobs/194493247 It appears to only happen on jruby. Also I can not reproduce it locally but happens all the time on Travis. Have anybody ever seen this before?
<olle>
"If anyone is interested in running a git bisect, that might make it clearer what caused the regression -- I don't know when I'll be able to look into the issue myself."
<cheba_>
hopefully it’ll be resolved soon.
<olle>
cheba_: segiddins asks for JRuby users to step up and assist him with clues.
<olle>
cheba_: Anyway, have a nice day!
olle has quit [Quit: olle]
alex0ptr_ has quit [Remote host closed the connection]
alex0ptr has joined #jruby
jimbaker has quit [Ping timeout: 260 seconds]
enebo has joined #jruby
hobodave has joined #jruby
joevandy1 is now known as joevandyk
lanceball is now known as lance|afk
<nirvdrum>
enebo: I don't suppose you know why jnr-ffi tries to replicate all the functionality of ld.so, do you?
knu has quit [Quit: Reboot...]
knu has joined #jruby
aardvark179 has joined #jruby
<enebo>
nirvdrum: I know it tries to reflect a bunch but I think there are rules it cannot parse
<enebo>
nirvdrum: I was unaware that it made any attempt at all until last year when someone pointed out some wildcard did not work
shellac has quit [Quit: Leaving]
vtunka has quit [Quit: Leaving]
bbrowning is now known as bbrowning_away
alex0ptr has quit [Remote host closed the connection]
alex0ptr has joined #jruby
alex0ptr_ has joined #jruby
alex0ptr has quit [Read error: Connection reset by peer]
alex0ptr_ has quit [Ping timeout: 260 seconds]
<nirvdrum>
enebo: I've been digging more. It actually tries to use dlopen on the name first. If you qualify the name a bit more, dlopen succeeds, and you can avoid walking the filesystem.
<nirvdrum>
ld.so caches entries, so it can be a fair bit faster.
<enebo>
nirvdrum: I just know there is something with parsing /etc/ldconfig.conf
<enebo>
err whatever the name is :)
<nirvdrum>
Yeah. We have a crazy set of rules that involves paths that can be added by 4 different system properties.
<enebo>
ls ld.so universal on unixy machines?
<enebo>
I guess it may not be in the same place itself
<nirvdrum>
enebo: To make this a bit more concrete, my search path in FFI has 13 directories. 2 of them don't exist. libc.so.6 is found in the 10th entry. So it'll walk the contents of 7 others trying to match names until it finds that.
<enebo>
heh
<nirvdrum>
But, libc.so.6 is qualified and dlopen finds it just fine, avoiding all those walks.
<enebo>
path-based searching has contributed to global warming
<nirvdrum>
Behaviorally, qualifying it changes things a bit since someone theoretically could try to load their own libcrypt. But I just can't see that being something sensible to do anyway.
<enebo>
nirvdrum: I think this issue has some diaglogue abotu libcrypt
<enebo>
nirvdrum: I think the specific issue was that jffi explodes if a shared library cannot be found
<nirvdrum>
enebo: Well, what would happen is dlopen("libcrypt.so") will be called and if that returns a NULL address, we'd fall back over into this more extensive lookup.
<nirvdrum>
Incidentally, in the case of libcrypt, I'd still expect it to fail.
Guest75281 has joined #jruby
<enebo>
nirvdrum: ok well so long as it is not substantially different on resolution it sounds fine
<nirvdrum>
Currently, it's doing dlopen("crypt") and that always fails. Then it falls back to the extensive lookup.
<enebo>
nirvdrum: seems like in this case only risk would be you find a different libbrypt somehow than the long search
<nirvdrum>
Yeah. It's basically the same thing we're doing with libc already.
<enebo>
nirvdrum: well without any memory or knowledge it seems reasonable to follow the libc pattern over whatever I did
Guest75281 has quit [Changing host]
Guest75281 has joined #jruby
<nirvdrum>
Okay. I'll go ahead with it then. If it breaks somehow, you can slap me.
<enebo>
nirvdrum: when I added this wmeissner had already taken the golden ships to the far shore
<nirvdrum>
Heh.
<nirvdrum>
I'm not blaming. I just want to make sure what you did wasn't deliberate.
<nirvdrum>
A lot of this is black magic.
<enebo>
nirvdrum: yeah I understand. I am just explaining
<nirvdrum>
Apparently eregon uses a hybrid SSHD or something and he's noticed the disk activity during boot-up, so I thought I'd look into it.
shellac has joined #jruby
thedarkone2 has joined #jruby
bbrowning_away is now known as bbrowning
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
<nirvdrum>
headius: What was the issue with clock_gettime in jnr-posix?
shellac has quit [Quit: Computer has gone to sleep.]
alex0ptr has joined #jruby
<nirvdrum>
enebo: If not a bother, I'd love a jnr-posix release with that libcrypt change in place. I don't know how long you want to let that percolate though.
alex0ptr has quit [Remote host closed the connection]