<anubhav8421[m]>
headius: not that great, did some work during college. Nothing special. But I can try reading the code base and see if I can understand whats happening
ur5us has quit [Ping timeout: 256 seconds]
rusk has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
nirvdrum has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
lucasb has joined #jruby
shellac has joined #jruby
nirvdrum has quit [Remote host closed the connection]
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
rusk` has joined #jruby
rusk has quit [Ping timeout: 268 seconds]
xardion has joined #jruby
shellac has quit [Ping timeout: 240 seconds]
<headius[m]>
Yeah have a look. I am going to work on it today because it's coming up daily as a problem
<headius[m]>
enebo: is there any file in dist we can use to determine JRuby version?
<headius[m]>
I'm reluctantly working on launcher and one of the issues is that it can't use --add-opens with org.jruby.dist unless we're in a version that actually exports that module
<headius[m]>
doesn't look like it :-\
<enebo[m]>
VERSION?
<headius[m]>
is it in dist?
<enebo[m]>
I don't know
<headius[m]>
that would be perfecto if so but I don't think it is
<headius[m]>
we could make launcher depend on that and start adding it
<headius[m]>
I mean we won't have a release with updated launcher until the next launcher and current launcher doesn't work right
<headius[m]>
it would mean current versions that work properly with bash script would work no worse than previous launcher
<headius[m]>
and versions that don't export module wouldn't error
<headius[m]>
I could also make the launcher export specific modules to ALL-UNNAMED if there's no version present
<headius[m]>
which would get the opens working across all JRuby versions
<headius[m]>
and then known versions > 9.3 would use specific module
<headius[m]>
🤷♂️
<enebo[m]>
maybe?
<enebo[m]>
There is a carrot angle to this as well
<headius[m]>
give me the answer
<headius[m]>
true
<enebo[m]>
I think unintended consequences of things generically means we should tread carefully on allowing older versions to behave differently
<enebo[m]>
in all honesty I cannot think of a downside here
<enebo[m]>
but with that said if it helps encourage people to move to 9.3 that is a good thing
<headius[m]>
so right now the reason people see some warnings is because we added more opens but they're in bin/.jruby.module_opts
<headius[m]>
so only the three that were hardcoded in launcher work
<enebo[m]>
I also look at this another way...Java 8 is recommended version for for 9.2 and earlier so supporting 11 on 9.2.x is not the end of the world since 9.3 will be out somewhat soon
<headius[m]>
will 9.3 require Java 11? :-D
<enebo[m]>
no :)
<enebo[m]>
but we should make it a major release goal that it is fine to use
<headius[m]>
yeah
<enebo[m]>
"all aboard the java dev cycle release train" ... whoo who
<headius[m]>
the two issues I know of in jruby-openssl should be fixed with next release...both did not need to use reflection anymore
<headius[m]>
the remaining ones in JRuby proper should all be good with updated launcher
<headius[m]>
the ones we know about anyway
<headius[m]>
enebo: I just realized a trivial workaround: check version during install
<headius[m]>
that doesn't help the exe but we only ship the exe in dist right now
<enebo[m]>
write it out
<headius[m]>
well we build the launcher on every other platform
<headius[m]>
so it can just be a define
<headius[m]>
we probably should throw VERSION into dist though
<enebo[m]>
install can write out what installed it which is fine so long as people do not have their own gem home
<headius[m]>
yeah shared won't work
<headius[m]>
but it doesn't really work with any Ruby ever
<enebo[m]>
we probably do work that way but I guess I would not expect people to do that
<headius[m]>
so this will basically be a change to the make/rake process for jruby-launcher... check JRuby version and if > X we use org.jruby.dist, otherwise ALL-UNNAMED
<headius[m]>
god I hate working with C++
<enebo[m]>
headius: so you do want to have older version do ALL-UNNAMED
<headius[m]>
well I'm on the fence
<headius[m]>
I don't remember when we added org.jruby.dist
<anubhav8421[m]>
Side note, shall we change the channel welcome message, it still says get 9.2.9.0
<headius[m]>
9.1.17.0 does not appear to have it
<headius[m]>
oh the matrix room is not updated
<anubhav8421[m]>
👍️
<headius[m]>
thanks for noticing
<headius[m]>
ok I guess it's not an error, but it's annoying
<headius[m]>
I guess I could skip this whole complexity and just add the module opts file if present and do nothing otherwise
<headius[m]>
that will cover 9.2.9+
<headius[m]>
and jruby-launcher could install that file if not present for old versions
<enebo[m]>
I think it has the least risk and also has the carrot benefit
<headius[m]>
looks like 9.2.3+ have org.jruby.dist set
<enebo[m]>
lopex: can linux have weird iso8859 encodings for the file system?
<enebo[m]>
lopex: I sort of remember this from years back
<enebo[m]>
"weird" meaning 8th bit for non-english chars
<lopex>
yeah, 8859-1 is just latin1
<lopex>
you can have any iso I guess..
<enebo[m]>
lopex: thanks.
<lopex>
there's convmv too, though I've never used that
<lopex>
enebo[m]: not sure what's compiled in the kernel and what the modules are now
<headius[m]>
enebo: I think I'm going to do a release that just switches module options to using the same file the bash script does and get this out, so that at least people with launcher and JRuby 9.2.9.0 will get all the add-opens we configured
<headius[m]>
and this will fix the warning about bad module name too
<headius[m]>
but 9.2.3.0 through 9.2.8 will go back to not setting module flags
<headius[m]>
I'm hoping with the java_opts files we can move at least some of these ongoing changes into a common location for both launcher and script
<headius[m]>
for a while the org.jruby.dist was getting stripped from the actual released jar
<headius[m]>
I'm going to need to check the actual releases
<headius[m]>
this patch works properly for anything with .module_opts file though, which should be 9.2.9+
<headius[m]>
and that's the path forward, not hardcoded in each launcher codebase
<headius[m]>
ok seems like it's there back to 9.2.1.0
<headius[m]>
so earlier versions do not have the module name and will warn for add-opens
<headius[m]>
enebo: so I guess the bottom line is how you feel about 9.2.1.0 through 9.2.8.0 returning to having module warnings for things that were masked previously
<headius[m]>
hmm not sure how I feel about that in fact
<headius[m]>
ah and 9.2.9 did not ship those files 😡
<headius[m]>
bleh ok fine world you win
<headius[m]>
I'll have logic to open up modules to at least org.jruby.dist hardcoded on 9.2.1-9.2.9
<headius[m]>
ALL-UNNAMED is up for debate
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]