<headius[m]>
wanted to get a stack trace from that example code on Windows with -Djnr.ffi.asm.enabled=false
<headius[m]>
hard to see why it's presenting such a weird error when it's all generated code
<headius[m]>
my Windows is on a dual boot at the moment
rusk has quit [Read error: Connection reset by peer]
rusk has joined #jruby
shellac has joined #jruby
<headius[m]>
enebo: I'm trying to tidy up some libraries that come from gems but I remember we had issues in the past where they were not being included in dist
<headius[m]>
I'm not sure what to update to make sure they're included
<headius[m]>
slowly getting rid of our local copies of stuff, yay
shellac has quit [Quit: Computer has gone to sleep.]
<enebo[m]>
headius: heh I do remember the struggle of understanding why dist was not getting the gems but I don't have any recollection what ended up being the thing which added them
<enebo[m]>
lib/pom.rb was it?
<enebo[m]>
I mean no doubt if this does not address that we will just figure it out later
<headius[m]>
lib/pom.rb has the gems but I know that it does anything for ensuring those gems' files get into dist
<headius[m]>
it does the installing and copying and such
<enebo[m]>
headius: yeah we figured it out before and if it needs more I think we will figure it out 10x faster this time around
nirvdrum has quit [Ping timeout: 264 seconds]
nirvdrum has joined #jruby
<headius[m]>
oh ugh
<headius[m]>
I think a bunch of gems that should just be bundled are being set up as default
<headius[m]>
I'll sort this out on PR
<headius[m]>
(i.e. they are copied to stdlib and should left as a plain gem)
<enebo[m]>
ok once it is fixed if there is multiple steps we should write down how to add new gems
<headius[m]>
there's still only six gems in MRI's gems/bundled_gems and they match what we have but I'm not sure if this is their default gem list or not
<headius[m]>
aha ok I found tool/sync_default_gems.rb in MRI which seems to match... I guess most of these actually are default gems
mistergibson has joined #jruby
mistergibson has quit [Client Quit]
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
<headius[m]>
ok that last commit should do it
<headius[m]>
2.7 moves a bunch more stuff to gems... I am wondering what it would hurt for us to adopt those gems early
nirvdrum has quit [Ping timeout: 240 seconds]
<headius[m]>
enebo: I'm done with that error output if you want to nuke it
<enebo[m]>
hmm
<enebo[m]>
was there something on there?
<enebo[m]>
I generally just leave gists forever
<headius[m]>
no nothing important there
<headius[m]>
I try to occasionally clean out any gists I haven't marked as public
<headius[m]>
anything public I assume I've linked somewhere so it should remain forever
<enebo[m]>
yeah I look at it as an endless scratchpad
<headius[m]>
I like to be able to find the ones I intend to keep and there's no search function for your own gists
<headius[m]>
enebo: it seems like MRI may actually be explicitly shutting down known threads
<headius[m]>
if we did the same this might address some open issues around thread shutdown at script exit
<enebo[m]>
yes this was what I thought was the original outlined solution for all but adopted threads but there was some disagreement on how possible it was
<headius[m]>
yeah I think at least one issue was not clear about how adopted threads should be handled
<headius[m]>
but we can treat them separately at this point
<enebo[m]>
sure
<headius[m]>
gem update is fine, will merge shortly