<headius[m]>
I reverted my fix because it's not important
<enebo[m]>
I am trying to look at that recent ENOENT filewatcher thing since it looks like it could be something reasonably simple and people use that library
<enebo[m]>
I believe it is only the tests that are broken but without knowing what is wrong who knows
<headius[m]>
after I get jnr releases out i'll triage remaining 9.2.10 stuff
<enebo[m]>
could easily just be some threading problem and not our issue
<headius[m]>
I saw you culled the herd a bit yesterday
<enebo[m]>
I got started but lag fatigued me quickly :)
<headius[m]>
we need to get jruby-launcher caught up too :-(
joast has joined #jruby
subbu|breakfast is now known as subbu
<headius[m]>
we need to rig up jnr-* to release as a block
<headius[m]>
bloc?
<headius[m]>
I hate this steppy step process
<headius[m]>
maybe I can coax mkristian into helping set that up
<headius[m]>
plus a jnr-all
<enebo[m]>
I have always hated this huge chain of deps
<enebo[m]>
I understand why they were broken up but it is a huge pain in the ass to manage
<headius[m]>
since the dawn of time
<headius[m]>
well broken up is maybe the wrong term... it started out as jffi and jnr-ffi and then each new area seemed better as a separate lib
<enebo[m]>
yeah I understand why I just never liked it from a management standpoint
<headius[m]>
I don't have a problem with there being separate libraries when it makes sense but jnr-enxio is really small and should probably just be part of a jnr-stdio which jnr-posix and jnr-unixsocket could depend on
<headius[m]>
it would make more sense if these were split up
<enebo[m]>
It is a double edged sword as well
<headius[m]>
... split up by functionality rather than the way they are
<headius[m]>
like many people want just IO and not all of jnr-posix
<enebo[m]>
getting more is not really a problem but having to upgrade because something else you don't care about changed is a problem also
<headius[m]>
well that's mostly a problem with maven complaining, no?
<headius[m]>
I wouldn't release all these if upgrading jffi alone didn't mess with the dependency graph
shellac has quit [Quit: Computer has gone to sleep.]
<headius[m]>
releases are out
<headius[m]>
I gave maven 15 minutes
<headius[m]>
enebo: I'm looking at refinements issues
<headius[m]>
the eval one basically isn't picking up that the containing scope may have refinements but I'm not sure how to communicate that to the parse/compile process
<headius[m]>
currently it only looks at whether the immediate parent scope has a refinement overlay, which usually won't be the case (since that doesn't show up in the method scope)
<headius[m]>
ok maybe I don't need to go deeper than just checking maybeHasRefinementsWhatever
<headius[m]>
refined send should be fixed shortly too but I'm going to PR it
<headius[m]>
we've had this to_generator protocol (which I thought came from rubinius, but I can't find it anywhere) so I made an attempt to use it
<headius[m]>
with this patch, ary.each.next creates no thread... I can loop forever and it works fine
<headius[m]>
we really ought to figure out how to fully implement this protocol for 9.3
<headius[m]>
if we did that for the key core classes 99% of all Enumerator#next uses would be fiber-free
subbu is now known as subbu|lunch
<headius[m]>
down to 16 open for 9.2.10
<headius[m]>
refined send is merged
<headius[m]>
ugh I suppose I need to look into this rubygems update showstopper
ur5us has joined #jruby
<headius[m]>
this warn patch in rubygems is disgusting
subbu|lunch is now known as subbu
<headius[m]>
ok I'm stumped
<headius[m]>
the patch replaces Kernel#warn with a new version that calls the old Kernel#warn via Method#call
<headius[m]>
old Kernel#warn will redispatch to Warning#warn to do the actual printing, or if called against Warning it will go straight to the write logic
<headius[m]>
broken test replaces Warning#warn with a new version that just calls super
<headius[m]>
so we get new Kernel#warn => old Kernel#warn => new Warning#warn => super to new Kernel#warn
<headius[m]>
I don't get why this isn't broken in CRuby
<headius[m]>
gotta be something about the warn super from Warning not going the same place as in JRuby
<headius[m]>
all this nonsense just so the RubyGems warn patch can remove RubyGems lines from warning output 🙄
<headius[m]>
GAH
<headius[m]>
it doesn't work in MRI
<headius[m]>
well thank goodness
<headius[m]>
omg ok
<headius[m]>
they fixed this after that and it's never gotten into any 2.5 release
<headius[m]>
we have the test in our repo because I updated from 2.5 head
<headius[m]>
I don't understand why the fix fixes it but at least I know we don't have to be fixed in 2.5.7 compat
<headius[m]>
ok I'm not insane
<headius[m]>
2.6.5 fails as well
<headius[m]>
the rubygems patch plus this Warning#warn change is bad
<headius[m]>
MRI must be running this test without gems active