chrisseaton[m] has quit [*.net *.split]
BlaneDabneyGitte has quit [*.net *.split]
XavierNoriaGitte has quit [*.net *.split]
ahorek[m] has quit [*.net *.split]
NightMonkey has quit [*.net *.split]
ur5us has quit [*.net *.split]
Liothen has quit [*.net *.split]
lanceball has quit [*.net *.split]
daveg_lookout[m] has quit [*.net *.split]
JulesIvanicGitte has quit [*.net *.split]
FlorianDoubletGi has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
JesseChavezGitte has quit [*.net *.split]
boc_tothefuture[ has quit [*.net *.split]
rdubya[m] has quit [*.net *.split]
kovyrin[m] has quit [*.net *.split]
ruurd has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
CharlesOliverNut has quit [*.net *.split]
TimGitter[m]1 has quit [*.net *.split]
headius[m] has quit [*.net *.split]
UweKuboschGitter has quit [*.net *.split]
byteit101[m] has quit [*.net *.split]
MattPattersonGit has quit [*.net *.split]
OlleJonssonGitte has quit [*.net *.split]
kai[m] has quit [*.net *.split]
michael_mbp has quit [*.net *.split]
Antiarc has quit [*.net *.split]
Caerus has quit [*.net *.split]
Freaky has quit [*.net *.split]
satyanash has quit [*.net *.split]
olleolleolle has quit [*.net *.split]
sagax has quit [*.net *.split]
truths33ker[m] has quit [*.net *.split]
GGibson[m] has quit [*.net *.split]
KarolBucekGitter has quit [*.net *.split]
jeremyevans has quit [*.net *.split]
quadz_ has quit [*.net *.split]
justinmcp_ has quit [*.net *.split]
knu has quit [*.net *.split]
havenwood has quit [*.net *.split]
hopewise[m] has quit [*.net *.split]
liamwhiteGitter[ has quit [*.net *.split]
slonopotamus[m] has quit [*.net *.split]
dentarg[m] has quit [*.net *.split]
MarcinMielyskiGi has quit [*.net *.split]
RomainManni-Buca has quit [*.net *.split]
ChrisSeatonGitte has quit [*.net *.split]
TimGitter[m] has quit [*.net *.split]
lopex[m] has quit [*.net *.split]
Iambchop has quit [*.net *.split]
kares[m] has quit [*.net *.split]
fidothe has quit [*.net *.split]
ebarrett has quit [*.net *.split]
enebo[m] has joined #jruby
Antiarc has joined #jruby
truths33ker[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
ur5us has joined #jruby
GGibson[m] has joined #jruby
KarolBucekGitter has joined #jruby
TimGitter[m]1 has joined #jruby
headius[m] has joined #jruby
JulesIvanicGitte has joined #jruby
CharlesOliverNut has joined #jruby
FlorianDoubletGi has joined #jruby
ChrisSeatonGitte has joined #jruby
RomainManni-Buca has joined #jruby
daveg_lookout[m] has joined #jruby
MattPattersonGit has joined #jruby
MarcinMielyskiGi has joined #jruby
UweKuboschGitter has joined #jruby
boc_tothefuture[ has joined #jruby
byteit101[m] has joined #jruby
OlleJonssonGitte has joined #jruby
JesseChavezGitte has joined #jruby
kovyrin[m] has joined #jruby
rdubya[m] has joined #jruby
TimGitter[m] has joined #jruby
kai[m] has joined #jruby
lopex[m] has joined #jruby
satyanash has joined #jruby
justinmcp_ has joined #jruby
fidothe has joined #jruby
hopewise[m] has joined #jruby
jeremyevans has joined #jruby
sagax has joined #jruby
dentarg[m] has joined #jruby
ruurd has joined #jruby
slonopotamus[m] has joined #jruby
drbobbeaty has joined #jruby
knu has joined #jruby
kares[m] has joined #jruby
havenwood has joined #jruby
Caerus has joined #jruby
NightMonkey has joined #jruby
lanceball has joined #jruby
olleolleolle has joined #jruby
Iambchop has joined #jruby
Liothen has joined #jruby
Freaky has joined #jruby
quadz_ has joined #jruby
michael_mbp has joined #jruby
ebarrett has joined #jruby
chrisseaton[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
XavierNoriaGitte has joined #jruby
ahorek[m] has joined #jruby
hopewise[m] has quit [Ping timeout: 246 seconds]
slonopotamus[m] has quit [Ping timeout: 246 seconds]
chrisseaton[m] has quit [Ping timeout: 240 seconds]
XavierNoriaGitte has quit [Ping timeout: 240 seconds]
BlaneDabneyGitte has quit [Ping timeout: 240 seconds]
ahorek[m] has quit [Ping timeout: 240 seconds]
liamwhiteGitter[ has quit [Ping timeout: 246 seconds]
CharlesOliverNut has quit [Ping timeout: 246 seconds]
TimGitter[m]1 has quit [Ping timeout: 246 seconds]
OlleJonssonGitte has quit [Ping timeout: 246 seconds]
UweKuboschGitter has quit [Ping timeout: 246 seconds]
byteit101[m] has quit [Ping timeout: 246 seconds]
MattPattersonGit has quit [Ping timeout: 246 seconds]
dentarg[m] has quit [Ping timeout: 246 seconds]
MarcinMielyskiGi has quit [Ping timeout: 246 seconds]
RomainManni-Buca has quit [Ping timeout: 246 seconds]
ChrisSeatonGitte has quit [Ping timeout: 246 seconds]
TimGitter[m] has quit [Ping timeout: 246 seconds]
lopex[m] has quit [Ping timeout: 246 seconds]
JulesIvanicGitte has quit [Ping timeout: 258 seconds]
daveg_lookout[m] has quit [Ping timeout: 258 seconds]
FlorianDoubletGi has quit [Ping timeout: 258 seconds]
enebo[m] has quit [Ping timeout: 244 seconds]
kovyrin[m] has quit [Ping timeout: 244 seconds]
boc_tothefuture[ has quit [Ping timeout: 244 seconds]
JesseChavezGitte has quit [Ping timeout: 244 seconds]
kai[m] has quit [Ping timeout: 246 seconds]
kares[m] has quit [Ping timeout: 268 seconds]
truths33ker[m] has quit [Ping timeout: 260 seconds]
KarolBucekGitter has quit [Ping timeout: 260 seconds]
GGibson[m] has quit [Ping timeout: 260 seconds]
rdubya[m] has quit [Ping timeout: 244 seconds]
headius[m] has quit [Ping timeout: 246 seconds]
lopex has quit [Ping timeout: 274 seconds]
lopex has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
lopex[m] has joined #jruby
JesseChavezGitte has joined #jruby
enebo[m] has joined #jruby
boc_tothefuture[ has joined #jruby
rdubya[m] has joined #jruby
kovyrin[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
slonopotamus[m] has joined #jruby
RomainManni-Buca has joined #jruby
MarcinMielyskiGi has joined #jruby
dentarg[m] has joined #jruby
CharlesOliverNut has joined #jruby
TimGitter[m]1 has joined #jruby
headius[m] has joined #jruby
OlleJonssonGitte has joined #jruby
hopewise[m] has joined #jruby
UweKuboschGitter has joined #jruby
TimGitter[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
kares[m] has joined #jruby
MattPattersonGit has joined #jruby
byteit101[m] has joined #jruby
daveg_lookout[m] has joined #jruby
FlorianDoubletGi has joined #jruby
JulesIvanicGitte has joined #jruby
BlaneDabneyGitte has joined #jruby
ahorek[m] has joined #jruby
chrisseaton[m] has joined #jruby
XavierNoriaGitte has joined #jruby
truths33ker[m] has joined #jruby
KarolBucekGitter has joined #jruby
XavierNoriaGitte has quit [Ping timeout: 240 seconds]
kares[m] has quit [Ping timeout: 240 seconds]
liamwhiteGitter[ has quit [Ping timeout: 246 seconds]
daveg_lookout[m] has quit [Ping timeout: 240 seconds]
boc_tothefuture[ has quit [Ping timeout: 240 seconds]
MattPattersonGit has quit [Ping timeout: 244 seconds]
lopex[m] has quit [Ping timeout: 244 seconds]
FlorianDoubletGi has quit [Ping timeout: 240 seconds]
rdubya[m] has quit [Ping timeout: 240 seconds]
JesseChavezGitte has quit [Ping timeout: 240 seconds]
kovyrin[m] has quit [Ping timeout: 240 seconds]
ahorek[m] has quit [Ping timeout: 246 seconds]
KarolBucekGitter has quit [Ping timeout: 246 seconds]
enebo[m] has quit [Ping timeout: 246 seconds]
TimGitter[m] has quit [Ping timeout: 268 seconds]
dentarg[m] has quit [Ping timeout: 240 seconds]
JulesIvanicGitte has quit [Ping timeout: 258 seconds]
byteit101[m] has quit [Ping timeout: 258 seconds]
slonopotamus[m] has quit [Ping timeout: 244 seconds]
RomainManni-Buca has quit [Ping timeout: 244 seconds]
MarcinMielyskiGi has quit [Ping timeout: 244 seconds]
OlleJonssonGitte has quit [Ping timeout: 240 seconds]
UweKuboschGitter has quit [Ping timeout: 258 seconds]
BlaneDabneyGitte has quit [Ping timeout: 260 seconds]
TimGitter[m]1 has quit [Ping timeout: 260 seconds]
truths33ker[m] has quit [Ping timeout: 268 seconds]
chrisseaton[m] has quit [Ping timeout: 268 seconds]
hopewise[m] has quit [Ping timeout: 268 seconds]
CharlesOliverNut has quit [Ping timeout: 268 seconds]
headius[m] has quit [Ping timeout: 268 seconds]
ChrisSeatonGitte has quit [Ping timeout: 268 seconds]
ur5us has joined #jruby
dentarg[m] has joined #jruby
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 258 seconds]
GGibson[m] has joined #jruby
kai[m] has joined #jruby
lopex[m] has joined #jruby
enebo[m] has joined #jruby
byteit101[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
headius[m] has joined #jruby
hopewise[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
KarolBucekGitter has joined #jruby
ahorek[m] has joined #jruby
boc_tothefuture[ has joined #jruby
TimGitter[m] has joined #jruby
MattPattersonGit has joined #jruby
FlorianDoubletGi has joined #jruby
UweKuboschGitter has joined #jruby
RomainManni-Buca has joined #jruby
MarcinMielyskiGi has joined #jruby
rdubya[m] has joined #jruby
kovyrin[m] has joined #jruby
chrisseaton[m] has joined #jruby
daveg_lookout[m] has joined #jruby
JulesIvanicGitte has joined #jruby
JesseChavezGitte has joined #jruby
truths33ker[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
slonopotamus[m] has joined #jruby
XavierNoriaGitte has joined #jruby
CharlesOliverNut has joined #jruby
OlleJonssonGitte has joined #jruby
kares[m] has joined #jruby
TimGitter[m]1 has joined #jruby
joast has joined #jruby
ur5us_ has quit [Ping timeout: 240 seconds]
ur5us_ has joined #jruby
ur5us_ has quit [Ping timeout: 264 seconds]
fidothe has quit [Quit: Connection closed for inactivity]
nhh[m] has joined #jruby
<headius[m]> enebo: hey when you verify on WIndows you don't build JRuby on Windows, right?
<headius[m]> this irb+reline update is problematic because it requires the io-console gem, and we have not been able to get them to do a -java release of that gem that doesn't require C ext pipline
<daveg_lookout[m]> headius: Just a heads up, we had an instance running 9.2.14.0+Monitor monkeypatch wedge overnight. Thread count spiked and a few seconds later instance was killed and replaced by load balancer. I'm still trying to figure out what happened, this appears more like an AR lock than a repeat of a Redis lock. I'm not sure I'm going to figure much out here, but I'll keep on trying. I'll let you know if it happen again.
<headius[m]> ok hopefully you are able to learn more or it never happens again
<enebo[m]> headius: I never try to build on windows although I do build on windows occasionally when there is something like a patch
<headius[m]> ok
<headius[m]> this is related to new irb+reline
<headius[m]> reline depends on the io-console gem, which normally has a C ext
<headius[m]> we use an FFI version that I am trying to get into the gem, but in the short term they modified the C ext to generate a dummy makefile on JRuby
<headius[m]> unfortunately although that avoids building the C ext it means we have to have `make` present, so you can't install it on a typical Windows JRuby rig
<enebo[m]> ah
<headius[m]> I am trying to convince them to do a -java platform gem that has the FFI stuff even if it isn't 100% compat yet
<enebo[m]> cool
<headius[m]> enebo: I am trying to get this one out of the way: https://github.com/jruby/jruby/issues/6129
<headius[m]> issue there is that WSL does not appear to fully support the file descriptors that inotify uses, and when we try to fstat such a descriptor it blows up
<headius[m]> the fix I am looking at is to use fcntl... pretty much every platform must have fcntl right?
<headius[m]> MRI appears to use it to verify the incoming fd for IO.new so I am hoping that will be a clean fix
<enebo[m]> You got me. I would have thought fstat was more common at least in how it works
<headius[m]> but they guard it in an ifdef if fcntl is available
<enebo[m]> fcntl used to be a hodge podge of incompatible options between even unixy stuff
<enebo[m]> that may have changed in the following decades :)
<headius[m]> but still present at least?
<enebo[m]> well all unixy platforms has it
<headius[m]> all I want is to use GETFL to see if the fd is valid and open
<enebo[m]> have
<headius[m]> that is how MRI verifies it (and gets original oflags)
<enebo[m]> I believe ioctl GETFL is very very old
<enebo[m]> As in I remember using it a long time ago
<enebo[m]> I would be surprised if platforms like *BSDs do not also have it
<enebo[m]> VMS
<headius[m]> fstat raises EPERM for inotify fd on wsl
<headius[m]> it is a known issue and no apparent work to improve it right now
<headius[m]> other filesystem notification utils don't work on wsl either without polling
<enebo[m]> Seems like worth trying to me. If it ends up not being true then I suppose this just means adding more to the conditional
<headius[m]> yeah that is what I would like to avoid and just have one path but I don't know if fcntl is more or less reliable
<enebo[m]> proving everyone has it is difficult but it is not an obscure function...then again you would expect fstat to work
<headius[m]> yeah I would
<headius[m]> but playing devil's advocate, fstat returns a lot of info that may not be valid for this sort of fd anyway, while fcntl is more targeted
<headius[m]> so I dunno
<headius[m]> I do not know why this fstat+inotify case breaks in WSL
<headius[m]> heh ok well one issue is that Windows does not have fcntl
<headius[m]> they do appear to have fstat though
<headius[m]> this logic is not being used on Windows right now because it is native IO
<enebo[m]> funny. yeah they support a number of compat functions
<headius[m]> so I will use fcntl normally but future proof this and use fstat on Windows
<headius[m]> if other platforms come along that don't have fcntl we can deal with that then
<enebo[m]> GetFileInformationByHandle
<enebo[m]> So perhaps you make fcntl on posix call this and support F_GETFL and error on anything else
<enebo[m]> I prefer the notion of this in that we are not putting more windows-specifif stuff in JRuby proper
<enebo[m]> SPECIFIF
<headius[m]> yeah we can look into that in jnr-posix in the future
<headius[m]> fstat on Windows and fcntl everywhere else is simple enough fix in JRuby for now
<headius[m]> assuming fcntl works with this weird fd
<headius[m]> (it appears to on CRuby)
<enebo[m]> is it simple to detect WSL2?
<enebo[m]> or WSL at all
<headius[m]> I have no idea
<enebo[m]> since this is likely an issue for both
<headius[m]> it is a virtualized linux environ
<enebo[m]> yeah
<headius[m]> some amount of Windows specificity may be warranted here because the C code does the same thing
<enebo[m]> hahah there will be some deep magic in figuring it out in code base on how many people cannot figure it out from the command line (amd I in 1 or 2)
<enebo[m]> That is interesting
<enebo[m]> they actually prefer FCNTL
<headius[m]> yeah I did not remember that from working on this code years ago
<headius[m]> so my patch looks like this now
<enebo[m]> sure and in the future this can just be the fcntl assuming GetFileInformationByHandle can return appropriate ret
<enebo[m]> in this case we do not care about all the flags but if we add it to jnr-posix we should replicate the info in ret
<enebo[m]> Almost makes me wish we took a more Rust way of distilling that we have the need for a common API whether something is still open
<headius[m]> yeah if we can emulate fcntl well enough I am game
<enebo[m]> but that does not really belong in POSIX per se
<headius[m]> we do that for a few other features not supported on different platforms
<headius[m]> Windows is such a hassle
<enebo[m]> seems though like maybe adding something in util might be useful then this would be if (SomeUtil.isFileOpen(fileno) {
<enebo[m]> not sure if we actually have this need more than once but it would read nice
<headius[m]> hmm yeah I am sure we check other places
subbu is now known as subbu|lunch
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:60d84f7 by Charles Oliver Nutter): The build was fixed. https://travis-ci.com/jruby/jruby/builds/213344694 [214 min 2 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> enebo: this is ready for a review: https://github.com/jruby/jruby/pull/6535
<enebo[m]> the ignore fstat error gives me feelings but I think we have not ever raised there for any other reason
<headius[m]> yeah I don't know what else to do there
<headius[m]> not sure how to determine if it is a file other than fstat
<headius[m]> aaargh maven
<headius[m]> some days the damn thing propagates in 5 minutes and sometimes not for an hour or more
<headius[m]> master might be broken until options 1.5 is available... I thought I gave it ample time
subbu|lunch is now known as subbu
<headius[m]> enebo: ok so I confirmed that patch works on WSL1 but I can't run WSL2 in a VM
<headius[m]> I can reboot into native Windows later but I have asked the folks on that issue if they can verify also
<enebo[m]> ok
<headius[m]> this MBP is too old to support nested virtualization apparently
ur5us_ has joined #jruby
peacand has joined #jruby
<peacand> Hi !
<headius[m]> peacand: hello!
<peacand> I've logged the issue https://github.com/jruby/jruby/issues/6529 which will be released with the future 9.2.15 if I understood properly. I'm actually a Logstash user, not JRuby directly. And I wonder if there would be an easy way to include this fix in JRuby for Logstash, without doing stuff too "hackish"
<headius[m]> ahh that was you
<peacand> that was me  :)
<peacand> thank you again for the quick fix (y)
<headius[m]> well to be honest I do not know how logstash packages JRuby or what their upgrade cycle is like
<headius[m]> the fix is ultimately trivial and would just involve swapping the core of JRuby
<headius[m]> you might want to open an issue with them so they know about this problem, and they may be able to help you get Logstash running on a build of this for now
<headius[m]> Thank you for the report!
<peacand> to be honest I dont know much how JRuby works, it's the first time I dig in "that deep" to understand why I had file descriptor leaks
<headius[m]> impressive start
<headius[m]> yeah I think your best bet is to contact logstash folks then
<peacand> But ... Basically is JRuby only a Jar file ? Do you think there is a good chance Logstash will work if I just swap the JRuby jar with a new one including the fix ?
<headius[m]> we have periodic snapshots of 9.2.x that can be used so you don't have to build on your own, but beyond that it is a logstash config situation I guess
<headius[m]> very good chance that swapping the jruby jar will just work
<peacand> Yes I've also opened an issue on Logstash, of course ;D . But unfortunately they are not as efficient as your are
<headius[m]> ok well if they use the "complete" jruby jar just grab latest from here: https://oss.sonatype.org/content/repositories/snapshots/org/jruby/jruby-complete/9.2.15.0-SNAPSHOT/
<headius[m]> those are built on every successful push to 9.2 branch
<peacand> That's why I'm asking here for advices as well. Maybe there are some good guys who could help
<headius[m]> in here, I believe kares has been working with or on logstash for some time and he might know how to swap this in safely... but if you can locate the JRuby jar in your logstash setup, it is worth trying to swap it
<peacand> ok thx ! I'll give a try. And, there is absolutely no workaround to prevent the fd to leak ? I mean without applying the fix in JRuby
<headius[m]> ahh I see your logstash issue
<headius[m]> I will comment there so they know everything is all set on our end
<peacand> thank you !
<headius[m]> Good luck!
peacand24 has joined #jruby
peacand is now known as Guest94269
peacand24 is now known as peacand
Guest94269 has quit [Ping timeout: 248 seconds]
peacand has quit [Ping timeout: 248 seconds]
peacand has joined #jruby
<peacand> arrfff it does not seem to work as easily as replacing the Jar
<peacand> "(GemNotFound) Could not find jruby-openssl-0.10.4-java in any of the sources" when trying to start logstash with the Jar of the latest build
<peacand> Is there any way for me to "backport" the fix in version 9.2.13 ? So that Logstash will be happy because the Jruby version does not change maybe
ur5us_ has quit [Ping timeout: 264 seconds]
Iambchop has quit [Read error: Connection reset by peer]
Iambchop has joined #jruby
nhh[m] has quit [Ping timeout: 246 seconds]
CharlesOliverNut has quit [Ping timeout: 246 seconds]
ChrisSeatonGitte has quit [Ping timeout: 246 seconds]
CharlesOliverNut has joined #jruby
nhh[m] has joined #jruby
<peacand> @CharlesOliverNut ?
<headius[m]> hey there
<headius[m]> sorry doing other stuff
<headius[m]> that is too bad
<peacand> arff I'm quite sad about that :-(. I really need to find a way to workaround this issue. For the moment the only way which seem possible is to port my Logstash plugin in pure Java, but it's a lot of work just to workaround this issue. Even if the Logstash team upgrade JRuby in the current version, I will not be able to upgrade my production on the latest version of Logstash easily
<headius[m]> hmmm
<headius[m]> what was the name of the file you replaced?
<headius[m]> I did not think they did a lot of repackaging but I don't know
ChrisSeatonGitte has joined #jruby
CharlesOliverNut has quit [Ping timeout: 268 seconds]
daveg_lookout[m] has quit [Ping timeout: 268 seconds]
JesseChavezGitte has quit [Ping timeout: 268 seconds]
liamwhiteGitter[ has quit [Ping timeout: 268 seconds]
KarolBucekGitter has quit [Ping timeout: 268 seconds]
byteit101[m] has quit [Ping timeout: 268 seconds]
kai[m] has quit [Ping timeout: 268 seconds]
<peacand> jruby-complete-9.2.13.0.jar
<peacand> I dont know much about java/jruby packaging, but I had a look at their Gradle config and they fetch the jruby tar ball from https://repo1.maven.org/maven2/org/jruby/jruby-dist. So it looks like during the build, they dont just pull the jar, maybe they repackage some stuff. Dont know actually
OlleJonssonGitte has quit [Ping timeout: 260 seconds]
JulesIvanicGitte has quit [Ping timeout: 260 seconds]
kares[m] has quit [Ping timeout: 260 seconds]
boc_tothefuture[ has quit [Ping timeout: 260 seconds]
MattPattersonGit has quit [Ping timeout: 260 seconds]
enebo[m] has quit [Ping timeout: 260 seconds]
lopex[m] has quit [Ping timeout: 260 seconds]
dentarg[m] has quit [Ping timeout: 260 seconds]
kai[m] has joined #jruby
CharlesOliverNut has joined #jruby
liamwhiteGitter[ has joined #jruby
JesseChavezGitte has joined #jruby
daveg_lookout[m] has joined #jruby
byteit101[m] has joined #jruby
KarolBucekGitter has joined #jruby
jeremyevans has quit [*.net *.split]
jeremyevans has joined #jruby
lopex[m] has joined #jruby
JulesIvanicGitte has joined #jruby
boc_tothefuture[ has joined #jruby
OlleJonssonGitte has joined #jruby
kares[m] has joined #jruby
MattPattersonGit has joined #jruby
enebo[m] has joined #jruby
dentarg[m] has joined #jruby
<ahorek[m]> https://github.com/jruby/jruby/pull/6535 thanks for the fix headius ! tests are green
<headius[m]> peacand: ahh well that would explain it
<headius[m]> they may repackage specifically for this openssl issue
<headius[m]> if we can find that out maybe there is something we could do to improve it
<headius[m]> I don't know how much more help I can be at this point unfortunately
<headius[m]> ahorek: rb-inotify is working?
<ahorek[m]> yeah
<headius[m]> I just tested your script
<ahorek[m]> there's a second issue https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/runtime/Helpers.java#L293 doesn't work on localized environments. But it doesn't prevert rails from starting.
<headius[m]> well I am explicitly not getting localized message there but it is still an issue?
<headius[m]> I knew that could be a problem
<headius[m]> if they would have just made these blasted errors into their own exceptions, or provide an enum of error type 😡
<ahorek[m]> https://github.com/ahorek/jruby/blob/master/core/src/main/java/org/jruby/RubyIO.java#L2876 there should be EINVAL and wait until the resource is available, but because the error message doesn't match it fails to EOFError
<ahorek[m]> there's no problem on EN environment
<peacand> no pb thank you for your help anyways @headius :)
<headius[m]> peacand: sure keep us posted
<ahorek[m]> however, your PR fixes the main problem with Operation not permitted - 48
<headius[m]> ahorek: I really don't want to start matching localized error messages, do you have a reproduction?
<headius[m]> I didn't want to match error messages in the first place of course
<ahorek[m]> unfortunatelly, we can't map ERRNO code from the java exception, all we have it the localized error message, that sucks
<headius[m]> If these messages are being localized properly, we may be able to look them up and build a table
<headius[m]> I had assumed that the normal get message would give me the non-localized one
<headius[m]> Typical Java localization would use a resource bundle or property file that we could access to get a mapping of message to error
<headius[m]> Some of these may be standard localized errno messages as well