<headius[m]>
didn't we have someone get errors on Java 13 in Cape Town?
<headius[m]>
I think maybe something is locked down that prevents us getting real file descriptor
nirvdrum has joined #jruby
<enebo[m]>
So on Java 13 I was able to completely generate the app and run rails s but this is what I get one first page request
<headius[m]>
jeez, it spawns webpack during a request?
<enebo[m]>
but fwiw I was doing timings of Rails with java 9+ in the past year
<headius[m]>
yeah it seems to be something new
<enebo[m]>
well only until it is compiled
<enebo[m]>
this is dev mode
<enebo[m]>
ah perhaps that is why I did not see it
<headius[m]>
ahh ok
<headius[m]>
I am reluctant to open up java security packages to all unnamed
<headius[m]>
it's no worse than on java 8 really but still
<enebo[m]>
ah I know what is up...I ran the Rails apps with Java 8 and then tried later with 13 so stuff like webpacker had already did its stuff
<enebo[m]>
so I am ok with keeping the warning until 9.3 so long as we make a module for jruby-openssl and solve it next release
<enebo[m]>
I mean we have had it for years now. a month or two won't kill us
<enebo[m]>
but we definitely get confusion from these warnings so we need to get rid of these known ones
<headius[m]>
might be able to add the add-opens now and get a jossl release out later this week with module in place, but if we need to do something different loading the jar it won't help
<headius[m]>
I'm trying to start up server to see the other warning
<headius[m]>
right, there's open issues about it but I haven't had a chance to run through common tasks and look for them
<headius[m]>
still no warning starting server... will look at your script
<enebo[m]>
yeah I think we will always have a support issue for this generically
<headius[m]>
oh I'm on 11
<headius[m]>
ok so this is different on 13
<headius[m]>
I suspect it fails to get file descriptor which we interpret as a module problem and print that info
<headius[m]>
but it's not a module error, something has moved
<enebo[m]>
I do actually have that warning way up in my history though
<headius[m]>
aha
<enebo[m]>
it was before when running rails c + serialization on 13...I see the bouncy castle thing but not running the 'runner' script
<headius[m]>
you are using launcher
<headius[m]>
launcher does not have smarts to load .jruby.module_opts or the others
<headius[m]>
if you put those flags from .jruby.module_opts in JAVA_OPTS it will probably work
<enebo[m]>
/home/enebo/work/release/release/jruby-9.2.10.0/bin/jruby: Bourne-Again shell script, ASCII text executable
<headius[m]>
hmm
<enebo[m]>
ah I bet I know
<headius[m]>
ok I guess not but I can't repro
<enebo[m]>
jruby dist may not be bundling those files
<headius[m]>
with jossl warnings fixed I do not see any more warnings
<enebo[m]>
jruby.module_opts is not in the bin dist
<headius[m]>
oops my bad
<enebo[m]>
I will check -src too
<headius[m]>
all the dotfiles in there should be added
<enebo[m]>
not for source either
<enebo[m]>
So summary of things: 1) missing dot files 2) possible change to work around lack of jossl module 3) bin/webpacker having descriptor error on 13
<headius[m]>
I will get a complete list of jossl module warnings and open an issue
<enebo[m]>
so we do some unpack and re-tar for jruby-bin (don't know about src) perhaps that is the issue
<headius[m]>
the newInstance reflective stuff appears to go through reflection to create a new CertificateFactory for BC, but if there's an SPI for BC it should be possible to create it by name
<kares[m]>
by name will only work if the provider is installed
<kares[m]>
which in our case is not the case ... that is why there's the mess with going through reflection
<headius[m]>
installed how
<headius[m]>
this appears to be using SPI
<kares[m]>
at least that had been the case when it was introduced ... pbly ! Java 7
<kares[m]>
* at least that had been the case when it was introduced ... pbly ~ Java 7
<headius[m]>
which should work if it's on classpath
<headius[m]>
hmmm BC seems to be multi-release jar to hide module-info
<headius[m]>
I know for a fact that is problematic
<headius[m]>
BC does have a CertificateFactory SPI
<kares[m]>
right so we eventually call the SPI ctor with the provider ... reflectively as those aren't accessible
<enebo[m]>
not to throw a wrench in all this and I know there are issues but which Java has a proper date impl?
<headius[m]>
8
<enebo[m]>
so we are only using joda now because of java exts
<kares[m]>
(since the provider isn't installed and we still want to prefer BC stuff over JDK impls)
<enebo[m]>
and we exposed it somewhat in Time/Date
<kares[m]>
yeah exts ... AR-JDBC uses it heavily
<enebo[m]>
It is not really germane to today's discussion but we should maybe switch up and deprecate for 9.3 if we can
<kares[m]>
they say Java 8 are drop in replacements for joda but the APIs or slightly different in the details
<kares[m]>
enough so that its not that of a simple transition ...
<enebo[m]>
I need to eat I am not thinking too clearly
<headius[m]>
the assembly plugin is what puts together the tarball and I don't think it copies anything into target first
<enebo[m]>
but we know at this point in time that generic exclude is causing us issues
<headius[m]>
yeah just kill the dotfile line
<headius[m]>
there's nothing else in here that's a problem
<enebo[m]>
This is horrifically opaque
<enebo[m]>
but will we get something weird from removing it?
<headius[m]>
I showed you everything in mine above
<headius[m]>
just the three from bin/ and some gems' have .travis.yml etc
<enebo[m]>
you looked for all dot files in the resulting file?
<headius[m]>
yes
<enebo[m]>
ah I see it
<enebo[m]>
so we could add excludes for .travis.yml and .ruby-version
<headius[m]>
we could but no reason
<enebo[m]>
It is not fool proof but would make this release clean
<headius[m]>
gem contents shouldn't be fiddle with imgo
<headius[m]>
in my great opinion
<enebo[m]>
true
<enebo[m]>
I agree with that
<enebo[m]>
only negative outcome happens in 2 years when there ends up being a .npm directory somehow
<headius[m]>
.git
<headius[m]>
maybe exclude that one :-)
<enebo[m]>
``` <exclude>.git</exclude>
<enebo[m]>
```
<enebo[m]>
```
<enebo[m]>
<exclude>.git</exclude>
<enebo[m]>
```
<headius[m]>
yay
<enebo[m]>
ok well I will respin after lunch
<headius[m]>
ship it
<enebo[m]>
we still potentially have one final issue with rails on 13
<headius[m]>
do we?
<enebo[m]>
the invalid descriptor running webpacker
<headius[m]>
I thought that was because of the missing dotfile
<headius[m]>
EBADF because it can't get a real fileno
<headius[m]>
ok that is just a theory
<enebo[m]>
well I will see I guess
<enebo[m]>
but I have to eat
<headius[m]>
jossl PR is green, only failure is that damn Inflater is closed thing
<headius[m]>
I'll merge
<headius[m]>
and a suspicious failure in concurrent-ruby that looks unreliable
<headius[m]>
I suppose I should eat too
rusk has quit [Remote host closed the connection]
<headius[m]>
jossl 0.10.4 is merged, thank you again kares
<headius[m]>
I am pivoting back to AOT work
<kares[m]>
yay!
<lopex>
numbers..
subbu is now known as subbu|lunch
ur5us has joined #jruby
subbu|lunch is now known as subbu
<rwilliams[m]>
headius: Would it be worth exploring uploading the wiki to readthedocs.org and seeing with it looks like?
<rwilliams[m]>
It supports both markdown and sphinx
<rwilliams[m]>
enebo: Is there a way to do two @'s
<enebo[m]>
rwilliams do you think more people will contribute if our wiki is somewhere else? What is the motivation?
<rwilliams[m]>
I just seems like a really nice system
<enebo[m]>
I think you can just add them as a list and both will be pinged but it will not show it in the UI
<rwilliams[m]>
And you could have versioned docs for releases
<rwilliams[m]>
instead of a living wiki
<rwilliams[m]>
The latency for sending messages has been bad the last few days
<headius[m]>
yeah I'm not sure what's up with that
<headius[m]>
matrix growing pains
<enebo[m]>
yeah I guess we have ancient stuff which just has not been removed here and there on the wiki. Having more versions seems like a second problem to having people update and keep things temporally current
<rwilliams[m]>
Yeah like when i explored speeding up jruby start times
<enebo[m]>
@headius @rwilliams you both get pinged?
<headius[m]>
yes
<rwilliams[m]>
none of the methods were actually maintained and nailgun had literally been removed
<rwilliams[m]>
lol
<enebo[m]>
headius: you were first so I am assuming you noticed
<rwilliams[m]>
Yes
<rwilliams[m]>
I was typing but i got pinged
<headius[m]>
I'm not sure if the syntax @ does anything in riot/matrix
<headius[m]>
name + tab works enebo rwilliams
<enebo[m]>
rwilliams: headius heh
<rwilliams[m]>
oh that's nice
<rwilliams[m]>
I've been using @ and it picks up the wrong names a lot
<enebo[m]>
It may not work as well across irc bridge perhaps but that is nice to know
<enebo[m]>
or does it?
<rwilliams[m]>
It'd be a big project redoing the wiki but ideally moving it to sphinx or something and it could be automated and versioned with the code
<rwilliams[m]>
the sphinx part is not required but it seems really nice
<rwilliams[m]>
And then folks could just to PR's against a docs repo or something?
<enebo[m]>
rwilliams: here is a question does sphinx import from a git repo?
<rwilliams[m]>
In my project I have a docs folder with rst files
<rwilliams[m]>
and there are hooks for readthedocs that will update on relase, tags, etc
<headius[m]>
publishing javadoc would make sense as a first go
<enebo[m]>
headius: nio warning is gone but I still see it for jruby-openssl
<rwilliams[m]>
But i'm not sure I understand the question completely
<headius[m]>
but I usually use javadoc.io for that
<headius[m]>
enebo: see what exactly
<enebo[m]>
rwilliams: my question was how it works with publishing versions
<rwilliams[m]>
I yearn for discord right now. It's taking like 10 seconds to post a message
<enebo[m]>
Personlly I feel the barrier to entry is so low right now for our existing wiki that it is lack of interest in people doing documentation
<enebo[m]>
(myself included to some degree)
<enebo[m]>
If it was just kept up to date and formatted nicely once I would be happy much less keeping track of versions
<rwilliams[m]>
Gotcha
<rwilliams[m]>
Like i said my personal experience with the current wiki was a bit of a nightmare
<rwilliams[m]>
I wasted a lot of time
<enebo[m]>
I can make a pledge that I will try and revise some pages but I may or may not be crossing my fingers as I hit the return key on this sensence.
<enebo[m]>
but I think we do need to do a pass and update/delete soon
<headius[m]>
for sure
<enebo[m]>
headius: so we definitely seem to have less of those warnings overall
<enebo[m]>
nio is gone because the dot files are in place
<headius[m]>
enebo: ah the change I made got rid of one warning but not the other
<headius[m]>
I don't know what the other one is about
<enebo[m]>
hahah crud
<enebo[m]>
13 works BUT I realized I just did openJ9 13
<headius[m]>
sweet
<enebo[m]>
I will need to run again with hotspot to make sure that descriptor error is gone
<enebo[m]>
lopex: no idea but whether Java works or not lots of large services exist in GC envs. Not criticizing them but I wonder what made them special
<lopex>
yeah, I agreee
<enebo[m]>
lopex: (I did not read the article yet)
<lopex>
but nowbody can explain how exactly whatever can be the case
<lopex>
it's all theories
<rwilliams[m]>
enebo: headius Is there a way to make an off topic channel for JRuby? Or does that defeat the IRC esque approach?
<lopex>
enebo[m]: not that interesting at all
<enebo[m]>
good news everyone...s3 upload works for me on my new laptop
<headius[m]>
take the rest of the day off
<enebo[m]>
lopex: classic wrong architecture leads to greener pasture (if I had to make a blind guess)
<headius[m]>
btw can we merge 9.3 stuff after release is out?
<headius[m]>
if there's an 11 it can go off a 9.2 branch
<enebo[m]>
lopex: in nearly 100% of those scenarios new tech leads taking over
<headius[m]>
native image build made it to a C linker error, so I assume I'm past the hard part
<enebo[m]>
headius: merge master into irscope removal and merge that first
<headius[m]>
error is a bug that's fixed in 20.0 ... released less than an hour ago
<headius[m]>
enebo: yeah cool
<lopex>
enebo[m]: but otoh, gcs will always have some "pauses"
<enebo[m]>
headius: but I have not pushed so give me a hour or so
<headius[m]>
once this builds I'll pivot
<lopex>
enebo[m]: unless ppl discover new wonderland typesystem
<enebo[m]>
but the first merge of master into removal branch will have some "interesting" merging
<headius[m]>
at the very least we'll have a repeatable native image build of debug.parser mode JRuby
<enebo[m]>
I just recall trying that tired on the train to brussels and it did not immediately work
<enebo[m]>
I would not say I was too fresh when I attempted it though
<headius[m]>
I think I can get the ruby bits to load if I tweak resource requirements in native build, and then we'll have at least non-RubyGems booting
<headius[m]>
RG requires json
<headius[m]>
things are happening!
<headius[m]>
I merged into removal branch fairly recently and it wasn't bad, but maybe that was before big work
<enebo[m]>
well if it was after brussels then no
<enebo[m]>
I do recall I wanted to originally just cp a few commits to master at that time but then I abandoned that idea and merged the other direction
<headius[m]>
well shucks, another linker error
<headius[m]>
gonna have to use stale numbers if latest graalvm native fails to link properly
<enebo[m]>
I made this joke before but was is sonatype a bank? That timeout is pretty fast
<rwilliams[m]>
Anyways i'll play around with it some and re-link when the docs are n't super broken
<headius[m]>
ok
<enebo[m]>
I got kristian to use a stable release for the build because he used to use jruby.jar from the build and that would really suck when developing
nirvdrum19 has joined #jruby
dopplergange has joined #jruby
<enebo[m]>
Anything people wanted highlighted as fixed for 9.2.10?
<enebo[m]>
headius: ping on IM
<headius[m]>
just saw it, messages were delayed until I went into app