<kares[m]>
oh really - almost fully no-arg? that's interesting ...
ur5us has quit [Ping timeout: 260 seconds]
Liothen has quit [Ping timeout: 244 seconds]
Liothen has joined #jruby
<headius[m]>
DI frameworks are often also no-arg if I remember right
<headius[m]>
SPI
<headius[m]>
It's a stupid pattern but there's quite a few uses
<headius[m]>
And if we do this I think we can eliminate the Java stub right?
<kares[m]>
thought the pattern lately was to provide all deps in a ctor, not that I follow up-to-date best practices that much
<kares[m]>
> And if we do this I think we can eliminate the Java stub right?
<kares[m]>
you mean the JI generated proxy?
<kares[m]>
* >
<kares[m]>
And if we do this I think we can eliminate the Java stub right?
<kares[m]>
you mean the JI generated proxy?
<kares[m]>
<headius[m] "And if we do this I think we can"> you mean the JI generated proxy?
lopex has joined #jruby
<headius[m]>
Sorry I mean the superclass stub in JRubyFX
<headius[m]>
byteit101 may have worked around that by reimplementing the launcher, but even in that case we can eliminate code by using the standard one
<byteit101[m]>
Err, sorry, which stub?
<byteit101[m]>
Application#launch?
<headius[m]>
Yeah
<byteit101[m]>
With ctors, all that + jrubyfxml code can go
<byteit101[m]>
to use the java one
<byteit101[m]>
wihout weird reflection
<headius[m]>
Perfect
<byteit101[m]>
Side question: is is possible to reimplement Class<> and have Class.forName return the custom impl? That would be another way to get rid of only the launcher code today (not the fxml code)
<byteit101[m]>
`public final class Class<T>` oh never mind, it's final
<headius[m]>
Yeah that's why I hate this pattern. If it were like Ruby we would have proper class objects that could be overridden
<byteit101[m]>
But yes, there is a reason I'm motivated to get these changes in to delete 75% of the jrubyfx{,ml} code!
<headius[m]>
There's no class objects in java, just this bag of
<headius[m]>
Bag of static methods and constructors
<byteit101[m]>
oh right, the other big question I had was: should I look into merging the concrete java & reified code at all?
<byteit101[m]>
I know you said the latter was a bit more well thought out
<byteit101[m]>
(and/or the jrubyc code)
<headius[m]>
Anything we can do to get rid of that nasty old concrete extension code would be great, and hopefully we have enough specs to make sure we're maintaining behavior
<headius[m]>
There's a lot of weird decisions in there
<byteit101[m]>
I've noticed :-)
<byteit101[m]>
I'm off work this week, so I've some extra time to work on this hopefully (as long as leaf-peepery doesn't take up too much of it)
<byteit101[m]>
Should no-arg ctors always be generated if applicable? or require some `java_constructor`-esque annotations?
drbobbeaty has quit [Ping timeout: 260 seconds]
nirvdrum has joined #jruby
ruurd has quit [Quit: bye folks]
ruurd has joined #jruby
subbu is now known as subbu|away
subbu|away is now known as subbu
jean[m]2 has quit [Quit: Idle for 30+ days]
carla[m] has quit [Quit: Idle for 30+ days]
nikolaos[m] has quit [Quit: Idle for 30+ days]
alexej[m] has quit [Quit: Idle for 30+ days]
valentina[m] has quit [Quit: Idle for 30+ days]
<headius[m]>
Hmmm
<headius[m]>
It would be nice to always generate it but it clearly won't work in all cases so I'm not sure
<headius[m]>
lopex: hah, well I was just merging a few dozen junit bumps
<headius[m]>
hopefully the flood is over
<headius[m]>
kares: that cleanup is fine and I am all for getting rid of that code in JRuby, but I think it should be moved into jnr-posix as part of the pure-Java backend
<headius[m]>
with your PR, non-native mode will error out for this logic when it did not before
<headius[m]>
jnr-posix is a better place for the reflective logic anyway
<lopex>
headius[m]: is it normal on osx for gem cli scripts to install under gems directory ?
<lopex>
and why then there is /usr/local/bin then ?
<headius[m]>
it has changed over time so I'm not sure
<headius[m]>
global gems directory?
<lopex>
it seemed so yeah
<headius[m]>
the bin scripts that gems install are really just stubs for the scripts under /bin in the gem (basically all the stubs do is load RG and then load the bin/ file)
<headius[m]>
so where those stubs go has been pretty fluid
<headius[m]>
gems dir is separated by Ruby version perhaps?
<headius[m]>
obviously can't do that with /usr/local/bin
<lopex>
but after some pretty straight forward brew installs, not PATH was updated etc
<lopex>
there's some weird interplay with /Libary and /usr/lib then
<lopex>
or /Libraries
<lopex>
and includes as well
<lopex>
we had problems with plain gem install pg
subbu is now known as subbu|lunch
<lopex>
so, like we had search for some postres header file in /usr and then update equivalent of include path
<lopex>
all that seemed like unix/mac bifurcation
subbu|lunch is now known as subbu
victori has quit [Ping timeout: 256 seconds]
<headius[m]>
lopex: In general I try to avoid global installs of gems because there's just too much churn in Ruby land
victori has joined #jruby
<lopex>
headius[m]: can you install locally via gemfile ?
<lopex>
or gemspec ?
<lopex>
and ideally, change that local path like in node
<lopex>
btw no unicode tables change in 2.7.2
<lopex>
just that pesky utf-8 variation
<headius[m]>
you can set an env var to install to a specific place
<headius[m]>
I think there's a way to configure RG to install stuff under .gems too
<lopex>
bleh
<lopex>
so no way to conf that on just bundler install ?
<headius[m]>
I'm not sure anymore
<headius[m]>
there's a lot of options in bundler :-)
<lopex>
yeah, I should just google
ur5us has joined #jruby
<headius[m]>
WARNING: An illegal reflective access operation has occurredWARNING: Illegal reflective access by org.jruby.ext.zlib.RubyZlib (file:/Users/headius/.m2/repository/org/jruby/jruby-core/9.1.17.0/jruby-core-9.1.17.0.jar) to field java.util.zip.CRC32.crcWARNING: Please consider reporting this to the maintainers of org.jruby.ext.zlib.RubyZlib
<headius[m]>
need to get the JRuby-based maven plugins updated to something more recent that doesn't have these warnings
<fzakaria1>
oh STDIN isn't interruptible in Java :(
<headius[m]>
Can you show me the output you think is unexpected?
<headius[m]>
JRuby should be setting up standard input as an interruptible native channel
<byteit101[m]>
headius: not easy to merge concrete extension and reify, the latter generates RubyObject descendants
<fzakaria1>
I'm trying to bisect some changes and figure a reproducible example.
<fzakaria1>
I suspect I have some code which plays with concurrent-ruby ThreadPoolExecutor wrapper and calling `#kill` on it isn't playing nice.
<fzakaria1>
Unfortunately for me Java Thread interrupting is quite complex and easy to muck up.
<headius[m]>
Yeah I am not sure exactly how the wrapper is implementing kill
<fzakaria1>
I keep writing minimal examples but running into other sharp edges.
<fzakaria1>
It's just calling Java's ThreadPoolExecutorService#kill which does Thread#interrupt.
<headius[m]>
Hmm
<fzakaria1>
then i discovered JRuby was swallowing interrupt with sleep, so i moved to STDIN (trying to write a tiny repro)
<headius[m]>
Yeah there are some edges between interrupting like a ruby thread or interrupting like a Java thread
<fzakaria1>
relying on interrupt overall is pretty weak; i'll have to manually track some invariant which seems to be guiding principle when working with interrupting/cancelling threads
<headius[m]>
I believe this case should be using select to wait for input, which should be interruptible by Thread.interrupt
<fzakaria1>
(kids grabbing me ; afk 30 -- thanks for the quick response)
<headius[m]>
Sure, let me know when you have a more concrete example I can try