<headius[m]>
olleolleolle: yeah I have been reviewing and came across my issue about getting the other native gems to have JRuby support
<headius[m]>
olleolleolle: almost the entirety of strscan is in one Java file for JRuby so it would not be a big job to integrate... just needs some time
<olleolleolle[m]>
Recently, I got into the Ruby "hangaround group" of people who maintain the standard library.
<olleolleolle[m]>
...and there, headius , I saw this GitHub Issue. & also, via the "gemification Ruby 2.5" Issue.
<headius[m]>
some of these will be tricky, like BigDecimal which we reference from within JRuby, but most others are just a matter of footwork to get a JRuby build and gem release
<headius[m]>
I have this one on a to-do to try to make at least a little more progress before 9.3... today I am triaging all things marked for 9.3 to see what can be closed or punted
<headius[m]>
enebo: I guess JRuby + Ruboto is still in use at Oslo airport so I closed this issue about getting 9k into Ruboto (it is already there with patches) and opened https://github.com/jruby/jruby/issues/6651 to reintegrate those patches back into 9.3 proper
<enebo[m]>
ok
<byteit101[m]>
headius: looks like a super-loop, so possibly, possibly not. I'd need to try it out
<byteit101[m]>
Oh, looks like a pure ruby reified class. I don't think I changed anything there, so issue likely still stands
<headius[m]>
basically I am modifying the "populator" generation to look at a new JRubyMethod field "implementers" to get a list of other classes that implement this method
<headius[m]>
so anywhere we have a JRubyMethod bound but it is abstract, we would need to add implementers for the overrides to show up in backtraces
<headius[m]>
this won't fix cases like "op_plus_one" but I think we could have JRubyMethod also aggregate a list of alternative names
<headius[m]>
maybe @JRubyMethod(name = "+", overloads = {"op_plus_one"}) or similar
<enebo[m]>
headius: hmm
<enebo[m]>
So we want Integer#+ to show up in trace but we won't because we are really in a RubyFixnum#+
<enebo[m]>
backtrace maker just sees the fixnum method as some internal logic we should be ignoring
<headius[m]>
yeah that is it
<headius[m]>
so if I add the overriding classes to the same table it should just work
<headius[m]>
(and overloaded method forms)
<enebo[m]>
It feels backwards to me
<enebo[m]>
Well I mean traceability is error prone either way
<enebo[m]>
but we have to @override in the case of let's say op_div
<headius[m]>
this is entirely about how we massage the Java trace into a Ruby trace
<headius[m]>
could be that with more logic I could have this dig down into subclasses and look for overrides but that is a messy path
<enebo[m]>
could we have an @jruby_backtrace("/") or something at the overriding methods
<enebo[m]>
That is not a real annotation but just the idea we put it on the implementers and not the main one
<headius[m]>
well, we could... it would need to be processed somewhere though
<enebo[m]>
similar to how @override is required to override the original
<headius[m]>
right now we only generate these populators for classes that have @JRubyMethod declaratins
<enebo[m]>
yeah
<enebo[m]>
I am just thinking about ergonomics of how to keep the implementing methods in-sync
<headius[m]>
so for example in the 1/0 case I have @JRubyMethod(name = "/", implementers = {RubyFixnum.class, RubyBignum.class})
<enebo[m]>
marking implementers seems less error prone in my mind to having a string list on main method
<headius[m]>
there won't be many of these cases but almost all of Integer will have to do this
<enebo[m]>
yeah I think IO may have this too
<headius[m]>
yeah it may if the overrides are not also @JRubyMethod
<headius[m]>
that is the trick
<enebo[m]>
I can see having it in @JRubyMethod is easier to implement
<enebo[m]>
Is there such a case?
<enebo[m]>
where implementer is override and the method
<headius[m]>
unsure about IO and subs
<enebo[m]>
but a different binding
<headius[m]>
RubyInteger does this an I think AbstractRubyMethod might too
<headius[m]>
(shared superclass of RubyMethod and RubyUnboundMethod)
<enebo[m]>
ok well if there were two annotations once for marking the implementers back to what it is for then I suppose there is an ambiguity but there is anyways I think
<enebo[m]>
but perhaps that is a corner case we cannot disambiguate just on examining a backtrace
<headius[m]>
chrisseaton: I am not sure I agree with your logic on that rescue thing
<headius[m]>
either the constant update does not propagate or the backtrace is incorrectly missing... I don't see how it is correct behavior either way
<headius[m]>
chrisseaton: to close the loop here, I don't think this case is really a bug but I appreciate your admitting that behavior does change when interruptible boundaries get swept away
<headius[m]>
enebo: I just realized we should not be using a SwitchPoint for thread interrupts
<headius[m]>
interrupts like kill and raise I mean
<headius[m]>
the current logic will invalidate the switchpoint, which I believe means it will throw out the old code, do the interrupt, and then reoptimize it with a new switchpoint
<headius[m]>
that might be fine for the first interrupt but if a piece of code is known to be interrupted a lot in the past it probably will be in the future... we should degrade to an active guard in that case rather than constantly throwing out code
<headius[m]>
so we need a smarter call site there that will give up on using SwitchPoint after some number of invalidations
<headius[m]>
this could potentially be impacting code with heavy cross-thread interrupts (though I hope that is less than rare)
<headius[m]>
hmm tricky bit is making this change local to a call site
<headius[m]>
any thread interrupt now invalidates all interrupt safepoints across the system so they all have to back off
<headius[m]>
I think I could process the subhierarchy but it would be heavier for runtime annotated methods
<headius[m]>
it would allow you do to something like @JRubyMethod(name = "+", overrides = true) and I would just search through all descendants for that method
<headius[m]>
right now I am doing this a dumb way... aggregate all classes seen in JRubyMethod.implementers and just add the list of names for each class
<headius[m]>
so I dunno
<headius[m]>
making the annotation less explicit means more processing
<headius[m]>
which will happen for all exts that are not shipping their own populators (i.e. all of them)
<enebo[m]>
Maybe limit annot searches to types which are RubyObject+
<headius[m]>
that would still include all descendants
<enebo[m]>
In most cases it will just be RubyObject and RubyBasicObject
<enebo[m]>
CACHE!
<headius[m]>
it is just tricky to make this do the smart way, and I have to add it to both an offline annotation processor and an online one
<enebo[m]>
yeah I don't know. online one makes this more onerous
<headius[m]>
I am also adding all names for the subclass so maybe I need to finesse this more
<headius[m]>
i.e. if you have two bound methods and only one has implementers, both names will be registered on the subclass too
<enebo[m]>
I suppose overrides = true is a good flag this is a problem for that method as well
subbu is now known as subbu|away
<enebo[m]>
I have seen this happen to == in places as an example
<headius[m]>
oh there is a complication there... looking up a method that does not exist raises an exception
<enebo[m]>
or clone
<enebo[m]>
Err maybe not clone
<headius[m]>
so overrides = true when one of the classes does not override will have to swallow errors
<enebo[m]>
yay
<enebo[m]>
so definitely not that path for online
<headius[m]>
that is at least justification for not being eager (i.e. processing all subclasses for all methods)
<headius[m]>
ugh
<headius[m]>
I think I have to do the subclass logic
<headius[m]>
it just feels like a bug waiting to happen if you have to be explicit, and then say one of them stops overriding or a new subclass is added
<headius[m]>
I will see how onerous it is... at least I know this fix is good so I will push a PR and then attempt to refine it
<enebo[m]>
I just noticed something I suspect is an ancient warning bug
<enebo[m]>
lvars named _foo will not warn if they are not used
<enebo[m]>
The check for '_' is there but not for all vars that start with underscore
<headius[m]>
there is still an outstanding issue for cleaning up all those naming checks
<headius[m]>
there are still some paths that force a symbol or other heavy things
<enebo[m]>
well in theory 9.3 is totally up to date :P
<enebo[m]>
except I guess it isn't after all since I noticed this
<enebo[m]>
This one is a trivial 9.2 fix too I think
ur5us has joined #jruby
<enebo[m]>
It would only affect -w with lvars and would only stop printing them
<enebo[m]>
I noticed this because rubocop-ast prints them out
<enebo[m]>
lol although 9.2 is pre symbol love
<enebo[m]>
ok well still trivial but not a nice merge
<headius[m]>
yeah 9.3 has a long tail
<enebo[m]>
oh wait I am wrong I saw a deprecated method
<enebo[m]>
I was thinking holy smokes if we didn't release with symbol love in there I would have been shocked :)
<headius[m]>
does not include any changes to existing JRubyMethod annotations but this is enough to fix it if we add implementers as needed
<headius[m]>
there is a general problem here that I think demands the more elaborate fix: any override of a JRubyMethod-annotated method should get translated in the backtrace, not even just ones that are abstract
<headius[m]>
we have this issue elsewhere, like in the specialized array classes that override some methods
<headius[m]>
sigh... guess I can't call this one done yet
<enebo[m]>
ah so this just looks for same named method
<headius[m]>
hmm
<headius[m]>
this would be easier if I could use StackWalker... I would have the class in hand and could just search for its ancestors in the mapping table
<headius[m]>
I will think on this and come up with something tomorrow