<chrisseaton[m]>
Is JRuby's incompatible signal behaviour (warn and ignore) based on practical experience working around applications that want to set signals that we can't handle?
<chrisseaton[m]>
Wondering if we can push this behaviour up to MRI more with a documented exception.
ur5us__ has joined #jruby
ur5us_ has quit [Remote host closed the connection]
chrisseaton[m] has quit [*.net *.split]
GabrielMazetto[m has quit [*.net *.split]
marcheiligers[m] has quit [*.net *.split]
marcheiligers[m] has joined #jruby
GabrielMazetto[m has joined #jruby
chrisseaton[m] has joined #jruby
ur5us__ has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 245 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 245 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
drbobbeaty has quit [Read error: No route to host]
drbobbeaty has joined #jruby
drbobbeaty has quit [Read error: No route to host]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
sureshbabu[m] has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
headius[m] has quit [Quit: Bridge terminating on SIGTERM]
daveg_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
boc_tothefuture[ has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
caleb_land[m] has quit [Quit: Bridge terminating on SIGTERM]
GabrielMazetto[m has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
jswenson[m] has quit [Quit: Bridge terminating on SIGTERM]
rdubya[m] has quit [Quit: Bridge terminating on SIGTERM]
chrisseaton[m] has quit [Quit: Bridge terminating on SIGTERM]
johnphillips3141 has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
vortex1111[m] has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
souravgoswami[m] has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
kalenp[m] has quit [Quit: Bridge terminating on SIGTERM]
kai[m]1 has quit [Quit: Bridge terminating on SIGTERM]
marcheiligers[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
enebo[m]1 has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
sdlin[m] has quit [Quit: Bridge terminating on SIGTERM]
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
drbobbeaty has joined #jruby
lopex[m] has joined #jruby
enebo[m] has joined #jruby
GabrielMazetto[m has joined #jruby
kai[m]1 has joined #jruby
FlorianDoubletGi has joined #jruby
caleb_land[m] has joined #jruby
jswenson[m] has joined #jruby
kares[m] has joined #jruby
sureshbabu[m] has joined #jruby
kalenp[m] has joined #jruby
KarolBucekGitter has joined #jruby
MattPattersonGit has joined #jruby
JulesIvanicGitte has joined #jruby
ChrisSeatonGitte has joined #jruby
boc_tothefuture[ has joined #jruby
chrisseaton[m] has joined #jruby
souravgoswami[m] has joined #jruby
marcheiligers[m] has joined #jruby
johnphillips3141 has joined #jruby
vortex1111[m] has joined #jruby
XavierNoriaGitte has joined #jruby
sdlin[m] has joined #jruby
TimGitter[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
rdubya[m] has joined #jruby
headius[m] has joined #jruby
daveg_lookout[m] has joined #jruby
CharlesOliverNut has joined #jruby
JesseChavezGitte has joined #jruby
byteit101[m] has joined #jruby
OlleJonssonGitte has joined #jruby
RomainManni-Buca has joined #jruby
BlaneDabneyGitte has joined #jruby
ahorek[m] has joined #jruby
TimGitter[m]1 has joined #jruby
MarcinMielyskiGi has joined #jruby
UweKuboschGitter has joined #jruby
cyberarm has joined #jruby
nirvdrum has joined #jruby
<headius[m]>
chrisseaton: you mean for signals we expect the JVM wants to handle?
<headius[m]>
we have a few we never support and the other warning about JVM usage depends on whether the JDK signal API allows us to install it
<headius[m]>
I don't know what you mean by practical experience
<chrisseaton[m]>
You ignore and warn, rather than raise an exception, right? TruffleRuby raises an exception. Just wondering if you used to raise an exception and decided ignoring and warning was better in practice or something like that?
<headius[m]>
oh I see, why warning vs error... it has been a while but yes some of these would terminate an app where simply not installing the handler didn't really hurt it
<headius[m]>
an example would be USR1 which several frameworks hook for zero downtime reloads etc... if we don't add the hook it just can't be signaled to reload, but if we error it terminates
<headius[m]>
we do hard error for SEGV BUS ILL FPE VTALRM
<headius[m]>
chrisseaton: part of the justification is also that signal trapping usually gets set up early in startup so warnings would be seen at deploy time
<headius[m]>
so it isn't hidden in a log... you would see right away that e.g. USR1 will not be handled
<headius[m]>
enebo: ok we need to get the dist situation sorted out
<headius[m]>
I need to refresh my memory where we gather all the bits together
<headius[m]>
this racc thing is a little embarrassing because we fixed it for HEAD but it is still wrong in the dists, and GHA jruby-head uses a snapshot dist too
<headius[m]>
might be worth figuring out how we can run tests using a built dist rather than an in-place build of JRuby
<headius[m]>
like build full dist, then unpack and switch to that for testing
<enebo[m]>
mkristian did all this stuff
<headius[m]>
yeah
<enebo[m]>
I believe it expands stuff into a temp dir and retars it though
<enebo[m]>
where and how I don't know
<enebo[m]>
So the issue is that we are missing bin/racc
<headius[m]>
well that is at least one of the issues
<enebo[m]>
I do recall there is some mystical filters which is a whitelist of what we copy into bni
<headius[m]>
I think the error that marcandre reported has evolved
<headius[m]>
right the whitelist is what I need to locate again
<headius[m]>
I think it should instead be reworked as a blacklist of things we don't want to ship (core/, tool/, ...)
<headius[m]>
because having to update this whitelist every time we adjust bin/ or add a gem is clearly not working
<enebo[m]>
they are both error prone but extra stuff in bni probably is less reported problems
<headius[m]>
working on the module stuff also made me realize that without mkristian as a regular contrib we need to take ownership of the build and clean all of this up
<headius[m]>
the pom.rb is fine but there are some interesting choices
<headius[m]>
one thing that might make this simpler is if the dist is assembled from build pieces, and THEN we do default gem installs and bundled gems into that assembly so whatever they install automatically is included
<headius[m]>
so like we build a "simple" dist without gem-based libs, and then install those libs into the simple dist for release dist
<headius[m]>
I am just spitballing
<enebo[m]>
So that whitelist is basically virtually nothing from bin
<headius[m]>
yeah
<enebo[m]>
so at some point some stuff gets copied into what is an empty bin
<enebo[m]>
I have went down this rabbit hole :)
<enebo[m]>
I forgot about it
<headius[m]>
dist should probably be doing what the release plugin does and re-checkout current hash into a tmp dir and build from there
<headius[m]>
that would avoid the need for being so cautious about including bin and gems
<headius[m]>
you could still do that tmp checkout yourself but I assume this is so restrictive so we don't accidentally include gems installed along the way
<enebo[m]>
Thinking outloud I think main dist issue was not recreating anything which would have been fingerprinted
<enebo[m]>
We shallow clone as part of release so we should not care about extra crud
<headius[m]>
e.g. scripts with full path in shebang or something
<headius[m]>
yeah we already shallow clone for release but if the dist process did this then it could be more inclusive safely
<headius[m]>
I mean right away the first thing I could see doing to this whitelist is simply flipping it and starting from the assumption that this is a clean clone
<enebo[m]>
so jruby.jar would be replaced after dist generated so it lines up with maven artifact for it?
<headius[m]>
so exclude core, tool, maven dirs and go from there
<headius[m]>
well this is the funny bit: we have designed this repo around being in dist form
<headius[m]>
so that anyone can build and go
<enebo[m]>
I think this process was made around the jruby.jar being the same jrbuy.jar as our core/base artifact
<headius[m]>
the only thing this should be doing is removing things an end user doesn't need
<enebo[m]>
ok so one build and we exclude some stuff
<headius[m]>
yeah longer term that won't be a real problem... my module branch removes shading from lib/jruby.jar
<headius[m]>
instead there is lib/modules/jruby.jar plus deps and they go in module path
<headius[m]>
but it is identical to jruby-base artifact
<enebo[m]>
well if this cuold just be a one step thing it would be more helpful too
<headius[m]>
yeah
<headius[m]>
that is what I am angling for
<enebo[m]>
all dist really needs is to repackage and rename some things
<headius[m]>
so your process is clone, build, and then tar up everything except sources
<enebo[m]>
and as you said exclude stuff like dev dirs
<headius[m]>
the automatic process would do the same
<headius[m]>
I hope we didn't have this discussion a decade ago and decide a whitelist was better
<enebo[m]>
Not sure if I commit this whether an older maven will try and make it http again
<headius[m]>
it might but that would be tacking into the wind anyway
<headius[m]>
I say commit it and anyone that reverts it needs to update
<enebo[m]>
ok so I am going to commit on master because I hate doing a checkout on these files
<enebo[m]>
ok
<headius[m]>
we should actually stop versioning the pom.xml
<headius[m]>
we only did that because some CI envs didn't have a new enough maven
<headius[m]>
and possibly for IDEs but they could pick up generated on a local build
<enebo[m]>
we won't get some weird maven warning if we remove it?
<headius[m]>
shouldn't
<headius[m]>
we are configured with polyglot so any newer maven will see that
<headius[m]>
and any older maven won't work either way
<headius[m]>
could give it a shot on master for a while and see
<headius[m]>
maybe now is the time to try
<enebo[m]>
hmm It maybe was changed and this branch is a week old
<headius[m]>
so short term we will not drastically change dist logic in 9.2 so I will spend today verifying that everything is where it should be in 9.2 dist
<enebo[m]>
I will try removing the version
<enebo[m]>
ah yeah good idea
<enebo[m]>
minimum change there ...just get bin/racc in there and probably audit
<headius[m]>
right
<enebo[m]>
our biggest source of embarrassment has always been build/packaging
<headius[m]>
there may be other exe getting missed
<headius[m]>
I will compare dist package with clean + build
<headius[m]>
clone + build I mean
<enebo[m]>
I don't think people appreciate how many more packaging issues exist in a generic language env than other software
<headius[m]>
that will also provide list for blacklisting sources on master
<headius[m]>
yeah for sure
<enebo[m]>
ah yeah
<headius[m]>
this isn't even a "bug"
<headius[m]>
just bar tarballs
<headius[m]>
bad
<headius[m]>
I think it is a Ministry day
<headius[m]>
nearly 200MiB repo 🤦♂️
<enebo[m]>
I removed model from pom.rb and it still generates modelVection in the pom and the xmlschema bits are still getting output
<enebo[m]>
and It am not surprised the emit that so namespacing can be validated
<headius[m]>
I say go for it and delete the pom.xml
<headius[m]>
it has been on my mind for a while
<enebo[m]>
afk until after lunch
<headius[m]>
heh ok clearly you are not building with Java 11 because it really hates our javadoc
<headius[m]>
enebo: first problem I see with blacklist is that rspec is required to run rake, which is used to copy the release bits to the release dir
<headius[m]>
we need to get rspec to be optional in rake so we can run that without polluting the release with rspec instal
<enebo[m]>
yay
<enebo[m]>
fwiw I have occasionally did builds with java 11 but mostly -pl core so it does not run javadocs
<enebo[m]>
intellij is pretty good at helping us find actual errors though
<headius[m]>
I file an issue for it
<enebo[m]>
I have fixed at least a dozen in the last year when I see one marked red
<headius[m]>
there's only a few pages of errors in my terminal
<headius[m]>
aha
<headius[m]>
so jruby-dist does not assemble stdlib itself... it unpacks what we ship in the jruby-stdlib artifact
<headius[m]>
and then does filtering of its own on top of that
<headius[m]>
but not sure if any of the filtering is relevant... I don't think we install or ship rub-maven gem anymore which is most of the lines in common.xml
<headius[m]>
ruby-maven
<enebo[m]>
heh the hoops
<enebo[m]>
If only buildr had won any war on build tools
<headius[m]>
ahahaha
<enebo[m]>
I liked it and it was really quick (plus we could run it)
<headius[m]>
it doesn't include any -java platform gems because it does a path glob against the simple gem names
<enebo[m]>
aha
<headius[m]>
so that is where racc goes
<enebo[m]>
that can't be good
<headius[m]>
nope
<enebo[m]>
if I am reading the issue right you are shooting for getting bin/racc included but also figuring out why it run without it
<headius[m]>
yeah the bottom of lib/pom.rb spells it out
<headius[m]>
enebo: well I have seen a few different errors which may reflect some differences in this build on master
<headius[m]>
.16 just simply doesn't include any racc executable
<headius[m]>
HEAD dist builds should be similar
<headius[m]>
none of them seem to have a bin/racc
<headius[m]>
but I also saw the error about not being able to activate the right racc when running from a normal HEAD build, which might be a bundler issue
<enebo[m]>
ah
<headius[m]>
FYI I am doing this according to release instructions so there is a release staging repo on sonatype... I will wipe them out when I am done
<enebo[m]>
headius: ok
<enebo[m]>
headius: I have noticed that sonatype does not keep those around very long. I would be surprised if they last 2 days
<headius[m]>
yeah so I am basically going to change this to include all of bin/ and lib/ruby/gem/**/* except for a few specific excludes
<headius[m]>
we may want to expand that further based on that diff but this should get all the missing executables back
<headius[m]>
I guess I like the fact that we assemble the dist from the jruby-core and jruby-stdlib but that needle's eye needs to be bigger to fit this camel
<enebo[m]>
I think so long we do the diff against 9.2.16 we should be golden for 9.2
<headius[m]>
yeah I will run that once I think I am done
<headius[m]>
once merged to master, marcandre's issue could be closed because he just wants it to be runnable against master HEAD
<headius[m]>
but we still have broken racc in .16 so may want to do a release sooner than later
<headius[m]>
have not gotten any other major reports
victori has quit [*.net *.split]
michael_mbp has quit [*.net *.split]
<enebo[m]>
yeah for .17 I think we should wait a couple of weeks just to see what else comes in
<enebo[m]>
hopefully that is all we need :)
<enebo[m]>
and as a workaround people can still gem install racc right?
<headius[m]>
no
<headius[m]>
that doesn't work
<headius[m]>
I think it sees we already have racc installed as a default gem and doesn't actually install anything
<headius[m]>
I will try to come up with a workaround after I have this fixed
<headius[m]>
byteit101: ok will try to look into that soon then
<enebo[m]>
headius: I will have to see. It is possible there is quite a bit of output with lots of warnings streaming by
ur5us has joined #jruby
<enebo[m]>
ah yeah I do see it
<headius[m]>
ok
<headius[m]>
ok so there are multiple things going on here
<headius[m]>
first off, installing a default gem does not generate binscripts... I don't know if that was my bug or not but it appears to only set up the lib files and the default gem stuff under gems/shared
<headius[m]>
that may be why mkristian wrote his own manual default gem installer that installs them as normal and then copies out the relevant pieces
<headius[m]>
which in turn missed bin stubs and other things due to platform gems etc
<headius[m]>
in short this is a mess
<headius[m]>
I am trying to modify lib/pom.rb to just use RubyGems to install the gems directly into place but with the additional step of forcing binstub generation for default gems
<enebo[m]>
it is a snake
<headius[m]>
I have shaken my head at this code many times
<enebo[m]>
I actually forgot restkwargs worked for hashes until I realized IRBuilder just puts this logic into buildHash
<headius[m]>
ah yeah I forgot too
<headius[m]>
enebo: we should just move this lib/pom.rb logic into a rake task and have maven call the rake task
<headius[m]>
it is misleading in pom.rb since the generated xml has none of this logic
<enebo[m]>
it is like pypy internals
<headius[m]>
ha
<enebo[m]>
I like the syntax of pom.rb but it is still a declarative thing. It feels the natural mechanism for Ruby to be used in a build would be to just have a Rakefile and a way for maven to call that.
<enebo[m]>
There is some notion of data exchange which maybe is complicated in that hand off I guess?
<enebo[m]>
I actually think using ruby as a substitute grammar for poms looks nicer but it is not really buying us anything
<headius[m]>
well no worse than having a build-generation script that itself does build tasks
<headius[m]>
which is basically what this is
<enebo[m]>
we also generate the xml poms so tools and stuff can read it
<headius[m]>
it would be like having a configure script copy stuff around before generating the makefile