siasmj has quit []
fidothe has quit [*.net *.split]
fidothe has joined #jruby
adam12 has quit [*.net *.split]
adam12 has joined #jruby
<headius> good afternoon
<headius> Gaurish Sharma: I am in the office now and looking at your issue
<GaurishSharma[m]> Thank you!
<headius> Gaurish Sharma: I just added a comment... I can't get JDBC to work in any case without having the jar file on the command line... just requiring it does not work
<headius> do you have any environment variable that might be causing the driver to be loaded at startup?
<headius> I will add some suggestions for further investigation on the issue
<headius> enebo: do you remember any tricks for getting jdbc drivers to work with a simple require? We have not had someone go directly at the JDBC APIs in a while
<headius> Gaurish Sharma: Another option for you would be to use a Ruby database API like Sequel rather than using JDBC directly, since they will take care of loading the driver appropriately.
demon36[m] has joined #jruby
<headius> demon36: I am trying to figure out when the linking of the `native` method happens
<headius> if it is lazy then we can add a new function and only use it when it works
<headius> if it causes the whole class to fail to load then we need a separate class as I described in chat
<headius> recently I did add something to the native binary (special varargs handling from newer libffi) but I was able to pack it into an existing API as bit flags
<demon36[m]> so u avoided having to create new builds ?
<headius> for that case, yes, because no new functions were added
<demon36[m]> ah
<demon36[m]> dropping prebuilt binaries from the release is not an option right ?
<headius> not really... users could build their own but for us to work out of the box we need to ship a binary for each supported platform
<headius> there's been work to get qemu/docker set up to do all platform builds but not to automate that completely
<headius> and that only supports linux on those platforms
<demon36[m]> i remember u telling me that
<headius> so until we have a solution that can build every platform we need to be able to incrementally add things
<demon36[m]> its not really a simple thing
<headius> yeah
<headius> in the past we have just had users rebuild for us but it is not reliable
<headius> I would say rebase your PR and we can see if it fails fast or slow
<headius> if it fails slow we can work around the old binaries and fall back to old logic
<demon36[m]> will, ofc you have more knowledge about who exactly uses the library, but I would suggest dropping platforms that the team does not have access too
<demon36[m]> so that we can liberate the jffi library
<headius> for 2.0 that might be the right option
<headius> and any new platform would need someone to contribute a way to build it automatically
<demon36[m]> yes
<demon36[m]> so, rebasing itself is not a big deal, but what will happen next ?
<headius> it might also make sense to publish the native platforms in separate maven artifacts so you can just pull the platform you need, and if it is not available you see it right away
<headius> so after you rebase we will see whether we can load Foreign without error if that native method is not available
<headius> if we can load Foreign and it only fails when we try to call those new functions, then we can just fall back at that point
<headius> you PR is pretty small so it is a good test
<demon36[m]> playing on that level with maven is not sth i can help with sadly
<demon36[m]> yes but again im disliking that optional fallback method
<demon36[m]> thoughts from anyone ?
<headius> others may chime in different times of day
<headius> let's just take it a step at a time and see how it behaves after a rebase
<demon36[m]> ok
<headius> I guess I would ask you to consider whether it is worth waiting until we can fix the build problem to get this feature... or if it is better to get the feature in place with fallbacks for now
<demon36[m]> so jffi's master does not build ?
<headius> I just mean the problem building the native binary for all platforms
<demon36[m]> yea
<demon36[m]> feeling like doing the fallback method now could be a waste
<headius> Then we would need to tackle the 2.0 library building and loading first
<headius> We need and want that to happen but that's obviously more work