<byteit101[m]>
headius: just noticed that Reified (non-concrete java extension) constructors don't call initialize(), is this intentional?
ur5us has quit [Ping timeout: 260 seconds]
<headius[m]>
Well it is generally the pattern we use in the various core class implementations. Construction of the Java object is a separate step from running the Ruby initialize. I have been wary of putting initialize in the constructor since Java objects are in a weird state at that point
<byteit101[m]>
should I do the same for concrete extension? it would simplify a lot
<headius[m]>
It's a thought I revisit occasionally though, because it would bring the Java constructor workflow in line with the Ruby allocate plus initialize workflow
<byteit101[m]>
though I dislike it form a users point of view, particular as it will make some javafx stuff very tricky
<headius[m]>
The problem with concrete extension is all that extra default code we have to run to set up both sides of the proxy
<headius[m]>
So if we don't run initialize from a concrete extension constructor, we need some other way to ensure the objects gets initialized properly
<byteit101[m]>
though it brings the question of what to do with overridden ::new
<byteit101[m]>
which I do in jrubyfx
<headius[m]>
Most of those weirder edge cases could just be forbidden and possibly error out. There's a limited set of patterns we can support given the complexities of concrete extension logic
<headius[m]>
Arguably, allocate should be doing the call to the Java side constructor, which would allow new to work properly
<headius[m]>
But that would prevent us from passing initialize arguments to the Java superclass constructor
<byteit101[m]>
and also adds friction to being constructed from java-side reflection
<headius[m]>
Right, the problem here is that allocate and initialize all happen at once on the Java side so there's no way we can hook into the middle of that step
<headius[m]>
So there has to be some trade-off in how we do the Ruby side of the initialize
<headius[m]>
The static Ruby field should be setup up immediately after the class is generated
<headius[m]>
It could use getRuntime but that does getMetaClass.getClassRuntime so it's more hops. The static field should maybe be final and set up more creatively but this reduces the memory accesses to get it
<headius[m]>
If we could figure out a clean way to initialize it as a final static field then the jvm should optimize it as a constant
<headius[m]>
One idea for initializing static final would be to just get it from the class loader, which I believe has a reference to the runtime
<headius[m]>
These reified classes are not meant to be used across runtimes anyway so the more static we can make that access the better
<byteit101[m]>
Ah, that last sentence was what I was looking for :-)
mark_menard has joined #jruby
<byteit101[m]>
> why does the reifier call setClassAllocator (uses no-arg) call, vs setRubyClassAllocator?
<byteit101[m]>
^ ?
<byteit101[m]>
> If we could figure out a clean way to initialize it as a final static field then the jvm should optimize it as a constant
<byteit101[m]>
I found a hacky way to do that in my wip that's pushed right now
<byteit101[m]>
What's the "old style" class in RealClassGenerator?
<fzakaria1>
okay finally put the kids to bed
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
<headius[m]>
<byteit101[m] "What's the "old style" class in "> I need to refresh my memory... There are a few ways I generate the interface logic because some platforms can't load new bytecode like Android
<headius[m]>
At least one of the ways just uses the normal Java interface proxy logic
<headius[m]>
Old and new are terribly non-descriptive names so I'm not sure what I was thinking there
<headius[m]>
There's a lot of stream of consciousness code in the Java integration layer
<headius[m]>
I'm going to have a look an finish this disappointing gluten-free beer
<byteit101[m]>
Cool. No reason, was more curious. I have some probably questionable init logic working, I'll push it to the wip pr shortly, getting late
<headius[m]>
ah I remember one confusion... "newProxyInterfaceImpl is actually the most compatible version that uses java.lang.Proxy
<byteit101[m]>
Interesting bug: MyClass.become_java! returns the class, but it isn't cached in MyClass.java_class
<headius[m]>
oldStyleImpl is an earlier code generated version I made, and realImpl is the one we use now except for a few edges case that don't work I think
<headius[m]>
the names are terrible
<headius[m]>
the whole newInterfaceImpl could use better doco and a cleanup
<headius[m]>
ah yeah I would expect that class to be cached
<headius[m]>
I guess it just switches the allocator and it's done
<byteit101[m]>
I didn't get an aswer to "> why does the reifier call setClassAllocator (uses no-arg) call, vs setRubyClassAllocator?", so just swapped them for sanity's sake
<headius[m]>
golly I don't even know the difference between those anymore
<headius[m]>
see one thing you should know about this stuff is that we never throw anything away
<headius[m]>
we should do a better job of deprecating when we add a new "right way" to do these things but we don't always
<byteit101[m]>
Fixed java_class with this.setInstanceVariable("@java_class", Java.wrapJavaObject(runtime, clazz));
<byteit101[m]>
Oh, are IRubyObject classes that DON'T decend from RubyBasicObject generated at runtime or otherwise not visible?
<headius[m]>
these are all three over a decade old, wow
<headius[m]>
there are no IRubyObject classes not descended from RubyBasicObject
<byteit101[m]>
Excellent, I wanted the methods from the latter, so am using it in the new code
<headius[m]>
some of this is a relic of us attempting to make that possible, but too many things depend on the concrete RubyBasicObject class
<headius[m]>
plus IRubyObject has like a million methods so it was never practical to not extend RubyBasicObject
<byteit101[m]>
Yay: working now: concrete via modified reification with no-arg ctors & initialize called on non-ruby init
<headius[m]>
wow that's cool
<byteit101[m]>
broken now: all concrete non-zero arg ctors :-)
<headius[m]>
hahah
<headius[m]>
deprecated
<byteit101[m]>
That's going to be a job for tomorrow though I think
<headius[m]>
I will get this load service work landed this week one way or another so we can start to close the book on 9.3 soon
<byteit101[m]>
I'm hoping to have this done for 9.3 to close the book on the other concrete stuff I put in. Is that reasonable?
<byteit101[m]>
oh, what is a way to get the source file the class (or method) was defined in (from a RubyClass)
<headius[m]>
yes
<headius[m]>
that is reasonable and I would like this all in 9.3
<headius[m]>
if the method is implemented in Ruby you should be able to use obj.method(:name).source_location
<headius[m]>
I have thought of making that work with the Java-based methods but never got around to it
<byteit101[m]>
hmm... This is for line numbers in traces for the reified code
<headius[m]>
if it's a core method written in Java, you need to unwrap it and look at the class of the "invoker" object: m = obj.method(:name); JRuby.ref(m).getMethod
<headius[m]>
ahh hmm
<byteit101[m]>
DynamicMethod
<headius[m]>
for generated code like that I've been using bogus lines for my own debugging
<headius[m]>
what lines do you want it to map to exactly?
<headius[m]>
like the line where the interface method impl was defined?
<headius[m]>
in ruby
<byteit101[m]>
yes, so if on line 12 I say class Foo; def overriddenmethod(); end; end, then the bactrace for overrideen method will say line 12
<byteit101[m]>
yes, in ruby
<headius[m]>
ok right
<headius[m]>
refreshing memory...
<headius[m]>
check if DynamicMethod implements PositionAware and then use that to get file and line
<byteit101[m]>
MethodData.getFilename(), but I don't see a line number
<headius[m]>
"Abstraction of all metadata about a method"
<headius[m]>
I guess not
<byteit101[m]>
:-) no worries, I can look at that tomoorrow
<headius[m]>
PositionAware should work
<headius[m]>
it's implemented by all the Ruby-based DynamicMethod types
<byteit101[m]>
AbstractIRMethod has it
<headius[m]>
yeah and that covers pretty much all ruby methods
<byteit101[m]>
not quite: java.lang.ClassCastException: class org.jruby.javasupport.Java$JCreateMethod cannot be cast to class org.jruby.runtime.PositionAware (org.jruby.javasupport.Java$JCreateMethod and org.jruby.runtime.PositionAware are in unnamed module of loader 'app')
<headius[m]>
ah yeah you need to instanceof
<headius[m]>
JCreateMethod is used for part of the allocation dance in interface impls
<headius[m]>
I don't think you want to use that for anything
<headius[m]>
it's like __jcreate internally
<byteit101[m]>
yup
<headius[m]>
the pure Ruby methods will all be subclass of AbstractIRMethod and will be instanceof PositionAware
<headius[m]>
if I remember right we have the jcreate dance mostly to delay implementing interfaces until you first construct
<headius[m]>
yeah what a mess
<headius[m]>
but we'll clean it up with your help :-)
<byteit101[m]>
well.. I'm making more of a mess to start with :-)
<byteit101[m]>
Alright, mess pushed, comments added, time for bed
victori has quit [Read error: Connection reset by peer]
johnphillips3141 has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
victori has joined #jruby
victori has quit [Read error: Connection reset by peer]
victori has joined #jruby
victori has quit [Read error: Connection reset by peer]
victori has joined #jruby
mark_menard has quit [Ping timeout: 272 seconds]
mark_menard has joined #jruby
_whitelogger has joined #jruby
nirvdrum has quit [Remote host closed the connection]
nirvdrum has joined #jruby
nirvdrum has quit [Remote host closed the connection]
subbu is now known as subbu|afk
xardion[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
invictus78[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
ahorek[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
rcrews[m] has left #jruby ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
rdubya[m] has quit [Quit: Idle for 30+ days]
subbu|afk is now known as subbu
Alex[m] has joined #jruby
<Alex[m]>
I'm trying to update an old jruby rails app. I'm trying to keep version numbers in sync. It's unclear to me if I should just be upgrading to different jruby numbers or if I can update to a more recent jruby version and specify the ruby version seperately. I'm currently on `ruby 1.9.3` `jruby 1.7.27`. I would like to first switch to `ruby 2.0`.
<Alex[m]>
Might be a super obvious question but I couldn't figure it out from the site/wiki
<chrisseaton[m]>
Does your app also run on MRI?
<Alex[m]>
No
<chrisseaton[m]>
Have you tried just running it on latest JRuby and seeing if that works?
<chrisseaton[m]>
That's 2.5.7 or something, but may just work.
<Alex[m]>
I'm on rails 3 so those shouldn't be compatible. I haven't tried though.
<chrisseaton[m]>
Hmmm yeah I see the problem
<Alex[m]>
I can go back through the changelog to find the versions that correspond to the appropriate ruby version but I didn't know if you could target different ruby versions with the same jruby
<chrisseaton[m]>
No
<chrisseaton[m]>
And the problem with older JRuby versions is you mix fixes you might want or need.
<Alex[m]>
Sorry, I couldn't parse that?
<chrisseaton[m]>
JRuby is constantly being improved. Run an older version and you don't get the improvements.
<Alex[m]>
Cool. Makes sense. I'll just find the versions to incrementally upgrade and try to get onto current. Thanks!
joshuacronemeyer has joined #jruby
<joshuacronemeyer>
Greetings! I was working on getting a local jruby build working so i could work on something. I was running the ruby specs. puts statements don't seem to go to std out when i am running with mspec. any thoughts on how i can get that working?
<joshuacronemeyer>
ha. nevermind. I'm going to go clean my glasses. I see the output.
subbu is now known as subbu|lunch
ur5us has joined #jruby
<headius[m]>
[Alex](https://matrix.to/#/@thekkid:dagarten.modular.im): we don't support multiple Ruby compatibility levels since the move to 9.x and that made the jump firmly into Ruby 2.x levels of compatibility.
<headius[m]>
You may be able to run an earlier 9.x version as a smaller step but it's probably not going to save effort if your goal is to get all the way updated
<Alex[m]>
What about minor levels? I might be misunderstanding the problem space as well.
<headius[m]>
Well 1.7.27 was the last release to support Ruby 1.9.3 behavior
<headius[m]>
We started with the 9.x numbering after that and at that point I think we moved to Ruby 2.2 behavior
<headius[m]>
We don't track every minor release of Ruby but the latest jruby release supports Ruby 2.5 and jruby 9.3 will jump to 2.6
<Alex[m]>
Thanks!
subbu|lunch is now known as subbu
<headius[m]>
Let us know if you have any other questions, I know an update like this can be frustrating
<headius[m]>
It looks like rails 4.2 still supported Ruby 1.9.3 so that may be the smallest incremental step you could take on jruby 1.7
<headius[m]>
Or rather the biggest jump forward on Rails without changing jruby
<headius[m]>
For rails 5 you would need to jump to jruby 9.1 or so, but at that point you might as well go all the way to 9.2
<Alex[m]>
I was planning on doing incremental steps on the rails side since that's worked for me before. I'll see how that goes. Really appreciate the help!
Antiarc has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
Antiarc has joined #jruby
Antiarc has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]