<boc_tothefuture[>
Morning everyone... quick question for the crew in here.. I couldn't find it in the docs and didn't appear that way in my testing.. is there anyway for JRuby to automatically call to_java on a ruby object if it exists before passing to a java method?
<boc_tothefuture[>
Right now it throws an exception on the not matching the Java method being called.
<headius[m]>
good morning
<headius[m]>
boc_tothefuture: there is no auto-coercing like that except for numeric, boolean, or string values
<headius[m]>
we have considered ways to add some auto-coerce to the dispatch logic for Java methods but never decided to add that complexity
<boc_tothefuture[>
Thanks. I am guessing there are lots of corner cases that make calling to_java if it would otherwise result in a non-method match pretty complex.
<headius[m]>
yeah so the tricky part is not calling to_java, it is knowing that we should call to_java and what types are supported
<headius[m]>
so you want some way to query the types an object supports and then use that to do a best match with Java methods
<headius[m]>
so like most Ruby APIs we stick to the core types for converting automatically
<headius[m]>
that is basically it but from 4 to 5 it multiplies the method search by however many types can coerce with to_java
<headius[m]>
so if we have three values and they all have to_java we have to considere 2^3 combinations of types when looking up a target method
<headius[m]>
one for the natural type and one for the coerced type
<boc_tothefuture[>
Yep, figured there was some complexity to it.. but I wasn't understanding hte query statement.. ok.
<headius[m]>
and then ideally we don't want to do that search every time so we need some way to cache what methods matched last time and what coercions we used
<headius[m]>
right now we know every object either passes as itself or in the case of a few core elemental types, as an elemental Java type (numerics, strings, booleans)
<headius[m]>
even that is already complex because you can call methods taking primitive or boxed type (long vs Long) and any integer type can be called with Fixnum because there is no other integer type in Ruby
<headius[m]>
there are cases we cann't disambiguate even with just these simple conversions
<boc_tothefuture[>
Ok, thanks for indulging my curiosity!
<headius[m]>
Freaky: that json does indeed parse for me locally
<headius[m]>
Freaky: if you can run again and reproduce it, pass -Xbacktrace.style=full to JRuby or -Djruby.backtrace.style=full to Java, that will let us see the exact Java line numbers in the parser where it failed
<headius[m]>
maybe that will give a clue as to why this source fails to parse
<headius[m]>
only theory I have right now is that the string maybe is being modified at the same time it is being parsed, so we are not seeing the actual source it fails on
<headius[m]>
nothing in the parser should be thread-unsafe but I will check that today
<Freaky>
headius[m]: I'll set that and see if/when it happens again
<headius[m]>
yeah other than that I am not sure how to investigate this... it seems fine in the library and I don't see any obvious threading problems in JRuby or json lib
<boc_tothefuture[>
Can you use field_accessor with private static final elements? I don't see any examples in the wiki.
<headius[m]>
daveg_lookout: kroth_lookout I have merged that PR to 9.2
<headius[m]>
I think snapshot builds are still broken but I will force one
<daveg_lookout[m]>
ok, great. we have custom build 9.2 build from your tree about to be merged, it'll be in staging this afternoon probably, waiting on some other stuff to be verified first
<headius[m]>
enebo: deploy builds are still failing on 9.2 branch so it wasn't the racc gem
<headius[m]>
if you are able to do a full release build of 9.2 locally then maybe we give up on travis and do this in GHA
ruurd has quit [Read error: Connection reset by peer]
<enebo[m]>
headius: but I did get another failure from something which happened since the racc commit. I wonder if it works for me locally now
<enebo[m]>
trying with HEAD now
ur5us has joined #jruby
<enebo[m]>
ok still fails...so racc is not the commit
<headius[m]>
ok need to figure out when it started failing then
<headius[m]>
I don't care if we unrevert the racc gem
<headius[m]>
enebo: what failure do you get?
<enebo[m]>
the same snakeyaml error
<headius[m]>
and that is with a clean clone?
<enebo[m]>
no
<enebo[m]>
but I got the same error before we thought it was racc and it went away the commit before the original merge of racc changes
<enebo[m]>
From that I am surmising maybe it was not racc at all but one of the other commits
<headius[m]>
hmm
<headius[m]>
but it still doesn't work after reverting the racc commits
<enebo[m]>
no
<enebo[m]>
I ran from head of 9.2
<enebo[m]>
when I have the bandwidth available I can try bisecting perhaps
<enebo[m]>
It takes so damn long to run this too but I will obviously be doing something else while it runs
<enebo[m]>
There are only like 4 changes so bisect seems perhaps weird
<headius[m]>
I am doing a deploy -Prelease locally in macos
<enebo[m]>
I just had to reboot so I lost the exact error as well
<enebo[m]>
So if it does work in macos then does that tell us anything?
<enebo[m]>
We do some generic lock_jars error at the same time too. Feels weird like we somehow load something we should not
<enebo[m]>
which could indicate a non-clean env BUT it did work before the racc merge commit and my env was as dirty back then as now
<headius[m]>
deploy is successful for me locally on macos and on linux in the GHA PR
<enebo[m]>
ok so my guess might be that non-clean env is causing it to grab wrong thing which has wrong snakeyaml
<enebo[m]>
but if next time I try this I see it work with that commit that worked on friday I want to figure out what changed
<headius[m]>
I only hooked it up on this branch to test
ur5us has quit [Ping timeout: 264 seconds]
<headius[m]>
that action also worked with the racc gem in place
<headius[m]>
travis error is different than yours and is a clean build other than the maven caching
<enebo[m]>
fwiw I don't really care where we do this from but I would like to figure out why it stopped working
<headius[m]>
maven cache scrub might fix it but if it does it is more motivation to get off travis
<enebo[m]>
I will try HEAD when possible from a shallow clone
<headius[m]>
I will try
<enebo[m]>
can you see my error anywhere?
<headius[m]>
enebo: and you were trying 9.2 branch yeah?
<enebo[m]>
and also does travis maintain old state in the sandbox?
<headius[m]>
I have not seen your error anywhere
<enebo[m]>
yes
<headius[m]>
only the ScriptingContainer missing error on travis
<headius[m]>
travis does not save any state other than maven caching for us
<enebo[m]>
It is funny to look at some of our build output. I see some weird /bin/sh classpath:bleh at one point
<enebo[m]>
Too bad I did not save off the log
<enebo[m]>
but I doubt that is anything at all other than some weird output
<headius[m]>
yeah that is an issue attempting to run some script during build when it has no pwd
<headius[m]>
or rather pwd is classloader
<enebo[m]>
yeah and so something is not running but not causing the build to fail
<enebo[m]>
and no reported issues :)
<headius[m]>
daveg_lookout: kroth_lookout there is a 9.2 snapshot including that PR now
<daveg_lookout[m]>
ok, thx. since we're using jruby-jars gem, easier for us to just build ourself. it's running in staging now, going to prod later today i think
<headius[m]>
ok no problem
<headius[m]>
enebo: we could just transition this to travis anyway...9.2 doesn't need as much verification and master runs several other suites in GHA that would be reasonable smoke tests
<headius[m]>
and I think the writing is on the wall about migrating off travis sooner than later anyway
subbu is now known as subbu|lunch
<enebo[m]>
headius: you mean from travis right?
<enebo[m]>
GHA is fine by me for everything at this point unless there is a perf issue
<headius[m]>
ugh yeah I mean transition to GHA
<headius[m]>
only reason we still have a bunch of stuff in travis is that we have like 50 jobs
<enebo[m]>
The rust launcher builds are quick once the action actually starts but you only get one at a time
<enebo[m]>
or at least my account does
<headius[m]>
GHA is harder to parallelize
<enebo[m]>
but using rust as an example is lame since it is small enough where it takes very little time
<enebo[m]>
I am not using matrix though either
<headius[m]>
you have to set up separate workflows to get parallel execution, and then every workflow shows up as an entry in the PR actions
<headius[m]>
so it would be super noisy to have 50 jobs like that
<enebo[m]>
I was going to set up a freebsd build until I saw how much work that would be
<headius[m]>
there may be a better way I have not found
<enebo[m]>
My 50s GHA for big three would end up like a 20 minute cycle
<headius[m]>
are your builds saving the executable?
<enebo[m]>
no but I have seen examples
<headius[m]>
yeah that would be slick
<enebo[m]>
It is the plan on a tag to have it auto release
<enebo[m]>
and then have the gem use that url to grab the binary on gem install
<headius[m]>
perfect
<headius[m]>
well mabye
<headius[m]>
gems that fetch other stuff are problematic if you are deploying behind a firewall etc
<headius[m]>
perfect = deploy on release tag but I think the executables should just be in there
<boc_tothefuture[>
Checked the docs and didn't see anything.. is there a way to check if a java object has an annotation? I saw some reference in a google search to `annotation_present?` but that method doesn't seem to exist.
<enebo[m]>
headius: and of course we can do that too. It was the original plan...
<enebo[m]>
ok I think I can configure this so it avoids this. I am not trying to make a .so
<enebo[m]>
nope. This is looking weird. I may need to use thermite as inspiration
<headius[m]>
Why are GitHub searches so terrible
ur5us has joined #jruby
subbu|lunch is now known as subbu
<boc_tothefuture[>
So, I guess my question actually is.. how do I go from the ruby method to get the actual java method object?
<boc_tothefuture[>
oops.. to_java of course.
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
<boc_tothefuture[>
Actually, no that method doesn't work.
<boc_tothefuture[>
headius: is there a way from a ruby method object to determine if 1) It is coming from Java, and 2) get the underlying Java method object to see what annotations are on it?
<headius[m]>
boc_tothefuture: well the Ruby object should basically be the Java object... we wrap it but that wrapper should be transparent
<headius[m]>
ruby method object as in obj.method(:something)?
<headius[m]>
not sure I am following what you need
<boc_tothefuture[>
headius: Sorry didn't see this.. I have a java object that I am accessing in JRuby, I want to find all the methods on that object that have a particular annotation. But I want to find it on the all the Jruby variants of the method too.
<boc_tothefuture[>
So, I was iterating with `public_methods` and then getting it with `method()` and then trying to get to the java method object should I could check if an annoation was present, but I don't seem to be doing that correctly.
victori has quit [Ping timeout: 260 seconds]
<boc_tothefuture[>
I can do it I think by doing Foo.java_class.methods.. but I seem to lose any of the aliased methods in Jruby so to_string instead of toString, etc.