nirvdrum has quit [Ping timeout: 260 seconds]
_whitelogger has joined #jruby
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has joined #jruby
zacts has joined #jruby
_whitelogger has joined #jruby
zacts has quit [Ping timeout: 260 seconds]
ur5us_ has quit [Ping timeout: 260 seconds]
<byteit101[m]1> headius: enebo: argh! I need to figure out matrix notifications. I seem to either be able to get ALL notifications or None at all. Can't seem to figure out just mentions for me...
<byteit101[m]1> headius: enebo: Yes, that bootstrap code is actually reason #2 I wanted the PR for java abstract classes, and the fxml loader is #1 :-)
<byteit101[m]1> headius: enebo: _davinci_: I'll be around tomorrow if you want to chat about JRubyFX.
<byteit101[m]1> The bootstrapping and the fxml (1 & 3) are the parts I've persionally cared about the most. I remember trying to keep the method_missing DSL magic intact as I modified mostly around it, and failing a few times with some spectacular m_m loops!
<byteit101[m]1> I personally rarely use the DSL except for small things, preferring the fxml
<byteit101[m]1> headius: enebo: I also will re-mention what I said here: https://logs.jruby.org/jruby/2020-09-06
<_davinci_> byteit101[m]1: Great. I hope for a jrubyfx functional gem ASAP. Thank you very much :)
sagax has quit [Read error: Connection reset by peer]
sagax has joined #jruby
nirvdrum has joined #jruby
donv[m] has joined #jruby
<donv[m]> Hi all! Anybody running parallel tests with Rails? I am getting database deadlock when using JRuby while MRI works fine on the same project.
<donv[m]> `parallelize with: RUBY_ENGINE == 'jruby' ? :threads : :processes`
zacts has joined #jruby
zacts has quit [Quit: leaving]
subbu|away is now known as subbu
subbu is now known as subbu|afk
<headius[m]> byteit101 _davinci_ enebo: Johan Vos provided a Java snippit for launching that amounts to this Ruby code: https://gist.github.com/headius/dea319c77caeb0f367ea267c76446be3
<headius[m]> either of those command lines work, as would a command line that just add all javafx jars to classpath
<headius[m]> we need to fix the launcher's handling of module path though
<headius[m]> I'm thinking JRuby should add a --module-path argument
<headius[m]> donv: not I but we should look into that
<headius[m]> could be us, could be Rails
subbu|afk is now known as subbu
<enebo[m]> headius: yeah I saw that tweet. Very cool if it works
<enebo[m]> headius: I agree for one substantial reason...the -J for module-path is fine but for the argument to it?
<headius[m]> Yeah, that issue is nothing new, but it is pretty ugly
<enebo[m]> headius: yeah but it is what tips me over the top on the option itself
<headius[m]> The code in that gist works fine for me starting up a single component app
<enebo[m]> headius: it will clearly end up a popular option over time so we should remove some amount of confusion if we can
<enebo[m]> nice
<headius[m]> I'm not sure what we're missing by routing around the standard launcher
<enebo[m]> possibly nothing
<headius[m]> There's literally no documents or how to's out there that show how to do this
<enebo[m]> but the real issue with javafx is they have changed stuff per version so this may not work back all the way
<headius[m]> I spent another half hour searching with this code in mind and never found it anywhere
<headius[m]> Apparently nobody else knew about it either
<enebo[m]> someone at gluon probably does :)
<headius[m]> Yeah that's what it took
<headius[m]> Mr OpenJFX himself
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
ur5us_ has joined #jruby
<headius[m]> still can't reproduce that sporadic failure
<headius[m]> enebo: this still reproduces: https://github.com/jruby/jruby/issues/6413
<headius[m]> what could cause that?
<enebo[m]> It could just be the wrong character is being passed in
<enebo[m]> the optimization comment cannot be it...it reverses the logic right?
<headius[m]> yeah I don't know of any optimization that would do this
<headius[m]> it must just be a typo or off-by-one somewhere
<byteit101[m]1> headius: ah, that only works in 9+
<enebo[m]> headius: this is just a typo
<enebo[m]> rel_expr : arg relop arg %prec tGT {
<enebo[m]> $$ = p.dispatch("on_binary", $1, p.intern(">"), $3);
<enebo[m]> relop can be more than >
<headius[m]> oops
<enebo[m]> This can just be targetted for 9.1.14.0 The fix will be small and have no risk
<headius[m]> byteit101: can recent openjfx be used on 8?
<headius[m]> I have been assuming people doing javafx would use openjfx builds
<byteit101[m]1> yes, that's been what I've been typically been doing
<byteit101[m]1> going to set up a 14 env to test shortly, but it works as-is on 8, which is what I've mostly been doing as it's still integrated-ish
<headius[m]> ok
<byteit101[m]1> headius: huh, maybe not anymore
<byteit101[m]1> No idea how I got it setup running 8, but they don't exist upstream as builds (sources exist)
<byteit101[m]1> and most linux repos have moved on to 11
nirvdrum has quit [Ping timeout: 265 seconds]
<byteit101[m]1> ah, right. some dists do have 8 still
<byteit101[m]1> either way, jrubyfx does the right thing as long as you pass -J--add-opens=java.base/sun.nio.ch=org.jruby.dist -J--add-opens=javafx.graphics/com.sun.javafx.application=org.jruby.dist -J--add-opens=javafx.graphics/javafx.stage=org.jruby.dist
<byteit101[m]1> using zulu14
<byteit101[m]1> (with jfx)
<headius[m]> here's an interesting bug
<byteit101[m]1> and still works fine on zulu8
<headius[m]> a gzipped file that only sees about 19k of data when uncompresed with ruby, but 95k of data via gzcat or gunzip
<headius[m]> `file test.gz` also shows "original size 19680"
<headius[m]> something very odd about this file
<byteit101[m]1> oh shoot, ctors don't work
<byteit101[m]1> Looks like concrete types need a default ctor without JavaProxyInvocationHander
<byteit101[m]1> Whats the easiest way to dump the bytecode to a .class file for later analysis for a rubyobj. (no java parent) ?
rcrews[m]1 has joined #jruby
rcrews[m] has quit [Ping timeout: 246 seconds]
ur5us_ has quit [Ping timeout: 260 seconds]
ur5us_ has joined #jruby