<invictus78[m]>
hello everyone. Need a little help here. I am working on a heroku project which is being run Ruby 2.0.0.0. I want to know which version of jruby is compatible with that and how n' where I can download it? I downloded the lastest as well as 9.1.x release but that is compatible with Ruby 2.5.x. Is there any way I can downgrady ruby version in jruby?
<david1>
Hi, anybody working with JavaFX from JRuby, please :)
david1 is now known as davinci
davinci is now known as Guest15447
Guest15447 is now known as _davinci_
<_davinci_>
I have a very strange problem trying to use Control classes from JavaFX. I can see base classes, like javafx.scene.Scene but I am not able of loading javafx.scene.control.Button :(
<_davinci_>
I use Maven for downloading and using jar packages in my project.
ur5us_ has joined #jruby
ruurd has quit [Quit: ZZZzzz…]
ruurd has joined #jruby
ur5us_ has quit [Ping timeout: 260 seconds]
_whitelogger has joined #jruby
zacts has quit [Quit: leaving]
zacts has joined #jruby
zacts has quit [Ping timeout: 256 seconds]
zacts has joined #jruby
sagax has quit [Remote host closed the connection]
zacts has quit [Quit: leaving]
zacts has joined #jruby
pedran[m] has quit [Quit: Idle for 30+ days]
neoice has quit [Ping timeout: 240 seconds]
neoice has joined #jruby
sagax has joined #jruby
<headius[m]>
invictus78: hello there
<headius[m]>
I believe you can select which JRuby you want to use on Heroku, but they keep the default up-to-date with latest
<headius[m]>
2.0 is pretty old though... we never had a release that supported 2.0 exactly, and I think the best you could do would be an early JRuby 9.0.x which was 2.3 I believe
<headius[m]>
_davinci_: you are just using the classes from Ruby code, not using JRubyFX yeah?
<headius[m]>
In here there's byteit101 and enebo who have some experience with JRuby, JavaFX, and JRubyFX
<enebo[m]>
I will make a very random guess that Scene is not backed by the native lib JavaFX needs so it appears to load (e.g. it is only Java) and JButton does not load because javafx runtime native stuff is not getting loaded
<enebo[m]>
The very unfortunate aspect of JavaFX is that they have changed how it is loaded more than once and then separated it from the jvm as a side project. So some experimentation on your env may be needed.
<enebo[m]>
A specific gist of error and how you invoke we might be able to give more help... byteit101 probably has more recent experience hitting a problem like this too so he may have more to say
<enebo[m]>
I found an interesting semantic bug in JRuby
<enebo[m]>
"found" == an MRI syntax test hits it
<headius[m]>
oh yeah?
<enebo[m]>
a[0] += raise(1) rescue 1
<enebo[m]>
we emit opelementasgn as getting a[0] then calling raise then adding the result
<enebo[m]>
all of what I just said is put into an exception region
<enebo[m]>
the problem being that adding the result bit should not actually be in that region
<enebo[m]>
The non-atomic aspect of op elementasgn makes this hard to see
<headius[m]>
hmm
<headius[m]>
what do we do for a[0] += begin; raise(1); rescue; 1; end?
<enebo[m]>
I generally do not feel a syntax tree should represent anything other than syntax but this is much simpler to solve by replacing that syntax with the semantics
<enebo[m]>
headius: that works
<enebo[m]>
although I am sure we end up seeing nested exception markers doign that
<enebo[m]>
ok I think I am seeing the world clearly
<enebo[m]>
MRI violates my principle here already
<enebo[m]>
they write the tree as RESCUEMOD(RESCUEBODY(1), OPELEMENTASN)
<enebo[m]>
vs OPELEMENTASN(RESCUEMOD(...))
<enebo[m]>
That said generically this rescue wrapping is a generic pattern
<enebo[m]>
I cannot just willy nilly reverse the order
<enebo[m]>
The essence of the problem is that half of opelementasgn does not belong in the region
<enebo[m]>
My immediate fix would be to write a node for RHS of the opelementasgn and a node for the subsequent use of the RHS
<enebo[m]>
That RHS being wrapped like now with the rescue mod
<headius[m]>
in MRI a[0] ends up as 1 right?
<enebo[m]>
yeah
<enebo[m]>
if you look at original IR it is obvious what happens here
<enebo[m]>
the A[0] = A[0] + RHS is all just emitted into the RHS calculation as well
<enebo[m]>
so when you hit rescue none of that ever happens
<headius[m]>
ah so basically it skips the rest of the op asgn and the 1 goes off into the ether
<enebo[m]>
yeah
<enebo[m]>
in fact so into the ether we eliminate it as dead code :)
<enebo[m]>
I looked at compiled result instead of startup instrs and I was wtf happened to Fixnum:1 :)
<headius[m]>
yeah an interesting case... hah yeah
<enebo[m]>
I do think now breaking this up is a very simple solution
<enebo[m]>
and pretty easy to track back to the syntax it came from
<headius[m]>
so it should really be a call(a[0]) plus a separate add + assignment in the rescue
<headius[m]>
I mean outside of the rescue
<enebo[m]>
yeah the operation is two separate calls over all (and the write)
<headius[m]>
right ok
<enebo[m]>
here is what messed me up though
<enebo[m]>
v += raise 'fff' rescue 1 works
<enebo[m]>
It happens to work just due to how the parser will in this case nest the rescue more into the rhs
<enebo[m]>
I guess it is worth seeing if I can pull that off here
<enebo[m]>
I think the only significant difference is one is a local variable access and the other is the result of a call
<enebo[m]>
one will potentially raise and the other will not
<enebo[m]>
meh...I wonder if a[0] raising somehow hits the rescue
<enebo[m]>
whew...access of lhs raises first (which makes sense but still)
<headius[m]>
so this one improves isolation of those frame-local values by making them thread-local as well
<headius[m]>
for captured frames that is
<headius[m]>
CRuby does not do this isolation and has no clear plan to fix it
<headius[m]>
in order to avoid the cost of making it a thread-local always, this defers that until we see we're being used across threads
<headius[m]>
but this doesn't even go far enough... since ThreadLocal has to be manually cleaned, it will leak unless this also puts things in a weak reference
<headius[m]>
the feature can be implemented but it's expensive and at this point I'm not sure whether it's worth the cost
<headius[m]>
I believe the PR as is works correctly, except for the thread-local leak
<headius[m]>
ah I see now I did add the weakref logic
<headius[m]>
so the question is whether the cost is worth it... this logic will fire for any frame that has "escaped", which may not be cross-thread
<headius[m]>
I believe TR guards this on seeing different threads and at that point makes it local+weak
<headius[m]>
we could do that but it's a much bigger change than just using the escaped flag
<headius[m]>
basically we are more eagerly going to threadlocal
<enebo[m]>
I just read the initial text on this as well
<enebo[m]>
I personally think without a clear measured benefit but for us to see that then we need a clear representative use as well
<headius[m]>
I guess I don't want to add another frame field for origin thread and track that for every read and write
<headius[m]>
there's an issue linked, and others around... this does catch people by surprise fairly often
<headius[m]>
there's also an argument to be made that we should just split backref/lastline from our Frame completely and manage them as a separate stack
<enebo[m]>
So the semantic argument is it will also make access safe
<headius[m]>
right
ChrisBr- has quit [Remote host closed the connection]
<enebo[m]>
So there is a cost in cost and time when it does basically end up being non-captured but then also has a benefit when no concurrent access happens
<enebo[m]>
in code and time is what that should have said
<enebo[m]>
god what is wrong with me
<enebo[m]>
ignore that whole sentence
<headius[m]>
yeah so the scenarios are like this...
<enebo[m]>
no contention == faster, contention == slower, extra code
<headius[m]>
uncaptured, should be pretty much same cost as before except it's doing volatile reads and writes
<headius[m]>
captured, needs to spin up a threadlocal and weakref, whether or not it ends up being used across threads (without tracking threads we have to do this way)
<headius[m]>
so the middle ground where it's captured but not necessarily needed across threads becomes much slower with zero benefit
<headius[m]>
I don't know if that's common, or if it even happens without the possibility it might go cross-thread
<enebo[m]>
yeah I am wondering about that. but this does fix the confusion by making it always work as a developer would expect
<headius[m]>
yes
<enebo[m]>
other option is originating thread as a field (captured in some way) and that would end up being a single field compare always? and some extra frame management cost
<headius[m]>
the real stinker here is that we have to share the frame for some use cases... there's code that expects frame updates in the block WILL be reflected in the parent scope
<headius[m]>
so we can't just memoize the whole thing
<enebo[m]>
yeah
<enebo[m]>
now if we can detect that.... :)
<enebo[m]>
you have not even mentioned invokedynamic yet
<enebo[m]>
I feel you are slipping
<headius[m]>
I am growing more reluctant to introduce this over head AND differ in behavior from CRuby
<enebo[m]>
feels like a indy callsite with the field of originating thread doing something via switchpoint
<headius[m]>
it's possible but not free... all accesses would need to check some thread identification
<headius[m]>
that could be some serial number on ThreadContext, but it still has to be read and compared
<enebo[m]>
yeah so some numeric compare perhaps or object compare
<headius[m]>
so two extra reads plus a branch
<enebo[m]>
but only when accessing $~ $_
<headius[m]>
and an extra frame field
<headius[m]>
I am starting to circle back to "we need to reimpl backreflastline" rather than patching around it being on the literal frame
<enebo[m]>
I am not really advocating so much as thinking about what is acceptable in exchange for no user reports
<enebo[m]>
yeah I can get around that more
<enebo[m]>
I mean we have talked about how frame should change so perhaps we should change it
<headius[m]>
we can largely detect (statically) that they'll be needed by flagging those method names
<headius[m]>
FWIW it appears we can still access the changes of a PR even if the associated source branch is deleted
<headius[m]>
so if we just close this in hopes of a better backref impl, we can still return to it if needed
<headius[m]>
yeah ok I am on the side of dumping this for now and treating the cause rather than the symptom
<enebo[m]>
ok
<headius[m]>
i.e. if we never want backref/lastline to be visible across threads, they should not be tracked in a structure that leads to that
<headius[m]>
this avoids using openStream on URL because it caches those open jar files and can end up closing them while in use
<headius[m]>
we patched around this the other way by not closing the classloader
<enebo[m]>
There is a possible compromise here but not a healthy one...only do this on windows
<headius[m]>
there's zero motion on the JDK issue I filed
<headius[m]>
just "yes this is a bad bug"
<headius[m]>
well that's also an issue but not the core issue here
<headius[m]>
the core issue here was having two JRuby in the same VM, one shuts down and kills the cached JarFile that the other might still be using
<headius[m]>
it's a bad race internally in the JDK code for caching those open files
<headius[m]>
it also does indeed complicate getting those files to clean up on Windows
<headius[m]>
I think you can turn the caching off in 9+, maybe
<enebo[m]>
but you already landed this for all non-jruby-specific jar files to not cache
<headius[m]>
what I landed still allows the caching to happen, but only closes the classloader with runtime-local jar files (temp jars)
<enebo[m]>
So it is perhaps an ugly fix for an ugly bug we do not control but the only real remaining manifestation is the windows problem
<headius[m]>
the classloader using on-filesystem jars does not get closed... it's a "leak" sort of but not ours and limited to only what's on file system
<enebo[m]>
oh it does cache still
<headius[m]>
right
<headius[m]>
so this literally only fixes it by not closing them
<headius[m]>
I mean the patch we landed
<headius[m]>
this one tries harder to avoid the caching
<headius[m]>
maybe what we have is sufficient for now and it's not worth the effort to manually try to "avoid" calls that are associate with the JDK bug?
<headius[m]>
I could also try to just turn off the caching but then we'd want to actually close all classloaders 😀
<headius[m]>
and only on 9+
<headius[m]>
we can discuss Windows temp files after this but I did a lot of work there and it's not solvable
<enebo[m]>
I don't know. What we have at least had killed seeing it on CI.
<headius[m]>
so ignore that for now
<headius[m]>
right and we and users have not seen it since we stopped closing the classloader with likely-shared jars
<enebo[m]>
If a good version-specific fix is possible it probably is worth it at some point
<headius[m]>
so for at least the jars loaded by JRubyClassLoader we are pretty ok right now
<headius[m]>
jars opened elsewhere are not covered by this
<headius[m]>
JRubyCL jars were the cause of user problems, though (johnphillips31416 I believe this was one of yours)
<enebo[m]>
If it is out of CI flaking and user reports though I am ok with it being "done".
<headius[m]>
ok me to then I suppose
<headius[m]>
I need a grant to work on fixing JDK bugs like this because it doesn't look like anyone else wants to do it
<enebo[m]>
It does make me wonder how easy it is to fix too
<enebo[m]>
The "groaner" bugs are the worst :)
<headius[m]>
I got a LOT of feedback from that report
<headius[m]>
usually people groaning about it
<headius[m]>
it has apparently affected millions of devs and nobody knew what exactly was wrong
<headius[m]>
ok so a sidebar on windows temp files
<headius[m]>
jffi files are totally effed... there's no way to ask the JDK to unload the jni stub unless the classloader goes out of scope and finalizes at some point and unloads it
<headius[m]>
and even if we could get it to unload, we'd run into the issue of multiple JRuby in the same runtime all trying to load and unload their own jni stub
<headius[m]>
jar files seemed like they'd be more likely to be fixable, but we can't control how they're loaded and cached by URLClassLoader
<enebo[m]>
ah mentioning the issue on n ffi loadDLLs is probably the most convincing in how borked that is
<headius[m]>
the remaining idea I have had is to unpack these files always to a known location with a known name, version, and sha
<headius[m]>
that's probably the best we can do... a "soft" leak of files that won't grow without bounds
<enebo[m]>
I have always thought loading a single version of this was totally a-ok but the classloader aspect I did not consider
<enebo[m]>
the single location with single runtime removes disk leak even if it could not remove it
<headius[m]>
yeah it needs to both be a single classloader that loads jffi AND all runtimes reference-count against that classloader, or something
<headius[m]>
it's just really messy
<enebo[m]>
well minimizes it
<enebo[m]>
but n runtimes doing it to same location is a problem unless we make some special CL for a global ffi
<headius[m]>
yeah exactly that
<enebo[m]>
oh haha I just saw your comment
<enebo[m]>
yeah messy
<enebo[m]>
panama
<headius[m]>
I tried to hack jar temp files by opening them ourselves with FILE_SHARE_DELETE (can be done through NIO, I discovered) but all opens of the same file have to use that flag, and JDK doesn't
<headius[m]>
so if anyone doesn't open it with shared delete, nobody can delete it until they're done with it
<headius[m]>
in any case, that's still a big open issue and I have no good answers... but it isn't really helped by fixing the jar caching problem
<headius[m]>
this is more critical... we need a solution
<headius[m]>
currently it's not possible to call a public method from a non-public superclass because we completely ignore the superclass
<headius[m]>
we do not bind methods declared on class X anywhere but on proxy X, so there's nowhere for the method to live... you can't call it against the original non-private class, but you CAN call it against subclasses of it
<headius[m]>
the patches here basically fudge that by binding those methods at the first public subclass if they can't be bound on the superclass
<headius[m]>
I don't know how I feel about the fudging
<enebo[m]>
and it is possible to not find a public subclass?
<headius[m]>
if there's no public subclass the method will never be callable
<enebo[m]>
ah I guess that makes sense
<headius[m]>
the part I don't like is binding methods from a superclass on the subclass when they aren't from the subclass
<headius[m]>
there's a simple example that shows a problem with my patch
<enebo[m]>
yeah I think the question to ask is other than reflectively being able to observe that how else can we see that it is different?
<enebo[m]>
the iterator.next?
<enebo[m]>
hmm interesting it highlight.that
<headius[m]>
yeah
<enebo[m]>
something.next
<enebo[m]>
peculiar... .next must be a tld now?
<headius[m]>
the impl of next there is on a private subclass but since it lives as a public method on the interface we bind it to that subclass
<headius[m]>
with this patch
<headius[m]>
hah yes
<headius[m]>
I mean the bottom line may be that our proxy structure doesn't work with this case and it's not patchable without changing the structure
<enebo[m]>
do we need to JIT?
<enebo[m]>
I mean could we be way more sophisticated on binding
<enebo[m]>
making a synthetic subclass would be really crazy I suppose
<headius[m]>
we could do more at dispatch time, yes
<headius[m]>
do a dumb binding of all declared public methods on every class, and at invoke time we figure out how to call
<enebo[m]>
oh well I am thinking more about at proxy JI creation but either way
<headius[m]>
I guess the problem scenario describe more simply is like this...
<headius[m]>
public method foo on private class X can't be called against X instances
<headius[m]>
if class Y < X it can be called against Y instances
<headius[m]>
so just put it on X proxy and it's ok right? But not... sometimes the private class is the bottom as with the Iterator impl
<headius[m]>
so in that case we need to dispatch against the superinterface, not against the bottom private class
<enebo[m]>
ah ok so that is where you come in with doing it at dispatch
<headius[m]>
there's a lot of dancing in javac to cover this
<headius[m]>
they get around it somewhat by only seeing the compile-time types
<headius[m]>
so e.g. you won't ever see a reference to the private Iterator impl in bytecode
<headius[m]>
we see the private Iterator impl at runtime and have to make a choice... that choice up to now has been to never bind methods on non-public classes
<headius[m]>
which leads to this other breakage
<enebo[m]>
so it was not broken only because it never happened
<headius[m]>
we started getting reports about it after fixing the private impl problem, I think
<enebo[m]>
clearly as this stands we would start getting new error reports without something to address this
<headius[m]>
it's not a new problem then
<headius[m]>
yeah
<enebo[m]>
err we have
<headius[m]>
I think we may have avoided this somewhat because most APIs that had a private superclass with public methods ALSO put those public methods on an interface somewhere
<headius[m]>
so we had the interface to call against
<enebo[m]>
ok so when we generate a proxy we have all the info we need at that moment to know the problem points
<headius[m]>
we do
<enebo[m]>
I am stating the obvious but I feel like it is a logical jumping off point
<enebo[m]>
since only problem points need problem solutions :P
<headius[m]>
the additional problem case of Iterator impl may be solvable by still avoiding binding anything on private classes
<headius[m]>
I can try to look into that
<enebo[m]>
and .next used to work right?
<enebo[m]>
I remember this not working a long time ago
<headius[m]>
it does, because of us skipping private classes when binding methods
<headius[m]>
so only the interface versions get bound
<enebo[m]>
ah so interface
<headius[m]>
right
<enebo[m]>
so if we do not bind private methods on private classes what happens?
<headius[m]>
I mean a really drastic fix would be that we bind all publicly-callable methods on EVERY class where they can be called
<enebo[m]>
the Y<X not calling thr right thing?
<headius[m]>
but we wrote this logic years ago to avoid that
<headius[m]>
if we don't bind private methods from private classes nothing happens, that's ok
<headius[m]>
someone might make it public in a subclass, but we'd see that
<headius[m]>
and if it's public in some higher superclass, you can't make it private
<headius[m]>
the problem is a public method in a private superclass... not callable against that class, but callable against any public subclass, even though it's not declared there
<headius[m]>
not declared there means we don't bind it
<headius[m]>
the drastic fix would solve this because every method would bind everything callable
<headius[m]>
I mean every class would bind
<enebo[m]>
we used to do that didn't we?
<headius[m]>
we did and it's a lot of stuff
<enebo[m]>
I thought at one point we put everything on everything
<headius[m]>
I rewrote it more than a decade ago to only bind these methods where they live
<headius[m]>
clearly this is all my fault
<headius[m]>
ugh I just don't want to completely rewrite this because it works for all other cases
<enebo[m]>
so we only need everything on everything in the precense of prvate superclasses right?
<enebo[m]>
ignore my typos
<headius[m]>
pretty much
<headius[m]>
maybe this patch isn't terrible if I can fix the private subclass problem
<enebo[m]>
So in that sense this is not a very common scenario making it much less extreme
<headius[m]>
just pulls down public methods that wouldn't be callable against a superclass
<headius[m]>
pretend they are declared on the first public subclass
<headius[m]>
right it may not be common practice
<enebo[m]>
If mean if that happens for 2-3% (if it is even that much) and adds extra bindings it will not a big hit
<headius[m]>
and most cases the subclass will have its own public impl of something
<headius[m]>
or it will be from an interface
<enebo[m]>
I have also wondered if Java API design has evolved away from the stuff of Iterator.next in terms of visibility
<headius[m]>
I'll see if I can fix the .next problem
<enebo[m]>
I do really wonder how many classes in Java proper actually even have this
<headius[m]>
I suppose I could describe the javac view of this as basically whatever class you have in hand, they do getMethods, which gives a list of all callable methods against that class
<headius[m]>
we do getDeclaredMethods and try to finesse them into the right places
<enebo[m]>
I am a bad person to ask about this as I am not a big fan of visibility when I first write stuff since I feel I am almost always wrong about how it will be consumed later
<headius[m]>
agreed
<headius[m]>
and public method on private superclass... really why are you doing that
<headius[m]>
most common case is a package-visible abstract superclass
<enebo[m]>
yeah that is funny...so many ways to avoid this and not have what to me feels unintuitive
<enebo[m]>
"so many" well a couple of other more obvious ones
<headius[m]>
I think this has been aggravated more recently by us slowly backing off trying to setAccessible
<headius[m]>
to better support Java 9+
<headius[m]>
we used to go ahead and set these methods accessible if we figured we needed to be able to call them
<headius[m]>
nio IntBuffer has subclasses for heap and off-heap and we shouldn't try to call their methods
<headius[m]>
ok that's all PR talk for now then... I will try to massage this a bit and see if we can go with it
<headius[m]>
thanks bruh
<enebo[m]>
aye
<headius[m]>
🤦♂️
<headius[m]>
I have been running everything with JDK14 but JI specs do some invasive stuff that doesn't pass
<headius[m]>
I thought I broke something else
ur5us_ has joined #jruby
<_davinci_>
Thank you @enebo. I do a require for JavaFX jar packages. Before requiring javafx-base I have no access to javafx.scene.Scene. After doing it I see it and can instantiate. The same should be when trying to require javafx-controls, but then I don't have access to classes like javafx.scene.control.Button
<_davinci_>
First time I try to access the missing class I get the error: NameError: cannot initialize Java class javafx.scene.control.Button (java.lang.ExceptionInInitializerError)
<_davinci_>
from org/jruby/javasupport/JavaPackage.java:252:in `method_missing'
<_davinci_>
Second time I get error: NameError: missing class name (`javafx.scene.control.Button')
<_davinci_>
from org/jruby/javasupport/JavaPackage.java:252:in `method_missing'
lopex has quit [Read error: Connection reset by peer]
<enebo[m]>
_davinci_: I am done for tonight but if you give a simple script I will reply in the morning if I can run it since I can run javafx stuff locally
lopex has joined #jruby
<_davinci_>
_enebo_ OK. I'll do it tomorrow. Thank you again :)