<nowhereFast>
the original rb works, but once compiled it breaks with an argument error, not sure if this is a jruby issue or just a consequence of the metaprogramming used in the lib
prasunanand has joined #jruby
donV has joined #jruby
<kares>
nowhereFast: you should try latest of 9K (9.1.9) ... believe some versions from the 9.x line had issues when being jrubyc-ed
<enebo>
kares: from what I understand this somewhat made something in JavaFX usable from a Java type at runtime and JavaFX stopped working after 9.1.5.0
<enebo>
kares: so the question seeing this commit is what do they gain from this.
<enebo>
kares: I am guessing something in this code adds something which is not added if you don't call become_java!
<kares>
interesting - well having a warning printed is still legit (as a bare minimum) ... the crazy part is that headius did the commit to avoid a NPE (mentioned in that commit)
<enebo>
kares: headius said he would look at this on the plane (he is travelling atm)
<kares>
... thus the question whether reverting would help - maybe some cases such as those for JFX but others might NPE :(
<enebo>
So it is either compound (as two commits started creating an NPE from some other fix) or in the specific case of JRubyFX is did not NPE
subbu is now known as subbu|away
<enebo>
after lunch I will also be looking at this as well. A significant JRuby user is blocked because of this errors in JRubyFX
<enebo>
Another thing to note is we can also fix this differentiny in JRubyFX itself if we understand it well enough
<enebo>
kares: but thanks for chatting about this. I think you are most up to date on JI stuff now
<enebo>
kares: haha another funny thing. headius fixed this for byteit101 for JRubyFX?
<kares>
yy :)
<enebo>
kares: so I think he reported an issue because he wanted this behavior but it NPEd so Charlie fixed the NPE by raising this error which then broke something in JRubyFX
<kares>
that you're on board - the underlying issue is a BIG one (which I am not sure Charlie will manage) :
<kares>
- Foo < Java.javafx.application.Application creates a proxy
<enebo>
which is not Application yeah
<kares>
- Foo.become_java! also generates a proxy but differently
<kares>
basically the second one is not meant to be used for Java classes but only plain Ruby ones
<enebo>
oh
<enebo>
ah I see
<kares>
but Foo has a Java super thus the reification problem ...
<kares>
it never really worked - but previously become_java! was silent and maybe even returned smt half usable in cases
<enebo>
So my take on this would be to just back out this single commit for 9.1.10.0 (the two commit release)
donV has quit [Quit: donV]
<enebo>
Then figure out proper reason why it is needed in JRubyFX when it fails to reify
<enebo>
Likely we can then change JRubyFX and put this commit back OR maybe we can figure out a proper way to make this work as well
<enebo>
kares: and I am betting it put enough crap on the failed class to work
<kares>
yeah I guess you need to look at the JRubyFX end ... which I never did how they managed to live with this previously
<enebo>
yeah I was not involved in the become_java! part of JRubyFX
<enebo>
I just did the DSL
<kares>
still you're infinitely more experienced than I am :)
donV has joined #jruby
donV has quit [Client Quit]
<enebo>
kares: yeah I definitely need to reduce this as I don't think Patrick ever has although he probably knows why he did it
<kares>
do you also have plans for adressing the each_with_index 'regression' (in that coming point release) ?
<enebo>
yeah that is the second commit
subbu|away is now known as subbu
<kares>
k
reevesg has joined #jruby
<reevesg>
hi - ive got a jruby-rack/warbler logging question
<reevesg>
i'm trying to use the log4j impl in jruby rack to do different things with different levels of logging
<reevesg>
but only the log(message) methods are being called, not the log(level, message)
<reevesg>
so my level info is getting lost somewhere between rails-rack-jruby-rack
<kares>
reevesg: its not implemented in 1.1 stable since the logger part replaces delegates using the logdev
<reevesg>
kares: are you saying that what i am trying to do is not possible in 1.1 stable?
<GitHub133>
[jruby] enebo pushed 2 new commits to bytelist_through_parser: https://git.io/vHthR
<GitHub133>
jruby/bytelist_through_parser 078d23e Thomas E. Enebo: Missed another identifier which was still using String instead of ByteList.
<GitHub133>
jruby/bytelist_through_parser 699b97b Thomas E. Enebo: We need to be like we were before in making a string from a bytelist in the helper. Note: Once we switch to bytelist this method will never be called again.
<kares>
reevesg: yes - all Rails.logger messages will come in at the Java INFO level
<kares>
its possible but you need to fork/hack jruby-rack at-this-point ... maybe in 1.2 some day :)
<reevesg>
ok thanks - do you have suggestions on how to fork it?
<reevesg>
what the best impl would be?
<reevesg>
the railties overwrites the rails logger right?
<reevesg>
which is called with the various level messages
<kares>
reevesg: sorry that's a long story atm - not scalable for IRC
<kares>
maybe look into other options - replacing Rails.logger with alternatives I am sure there's a log4r like gem which uses Log4J
<kares>
if not it shouldn't be hard to invent it using JRuby's Java Integration ...
<reevesg>
perhaps i'm confused, i was under the impression that jruby-rack is replacing the rails logger with its own implementation that writes to the servlet context
<reevesg>
so therefore anything that I do in the rails config will just be overwritten anyway
<GitHub52>
[jruby] kares closed issue #1635: Possible incompatibility with inherited and super https://git.io/vHqea
camlow325 has joined #jruby
lanceball is now known as lance|afk
<GitHub128>
[jruby] enebo pushed 1 new commit to bytelist_through_parser: https://git.io/vHqtf
<GitHub128>
jruby/bytelist_through_parser 64a132d Thomas E. Enebo: Gvar returning random identifier instead of the gvar
lance|afk is now known as lanceball
subbu_ has joined #jruby
subbu_ has quit [Client Quit]
hobodave has quit [Quit: Computer has gone to sleep.]