all4miller has quit [Remote host closed the connection]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (jit_irscope_removal:793c28b by Charles Oliver Nutter): The build was fixed. https://travis-ci.org/jruby/jruby/builds/649202135 [168 min 36 sec]
<headius[m]> yes
Antiarc has quit [Quit: ZNC 1.7.4+deb7 - https://znc.in]
Antiarc has joined #jruby
nirvdrum has joined #jruby
travis-ci has joined #jruby
<travis-ci> JLLeitschuh/jruby-openssl (fix/JLL/use_https_to_resolve_dependencies:f251607 by Jonathan Leitschuh): The build has errored. (https://travis-ci.com/JLLeitschuh/jruby-openssl/builds/148319221)
travis-ci has left #jruby [#jruby]
nirvdrum has quit [Ping timeout: 265 seconds]
ur5us has quit [Ping timeout: 240 seconds]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:e7a6d97 by Charles Oliver Nutter): The build was broken. https://travis-ci.org/jruby/jruby/builds/649271444 [178 min 15 sec]
travis-ci has left #jruby [#jruby]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 265 seconds]
joast has quit [Ping timeout: 265 seconds]
enebo has left #jruby [#jruby]
<kares[m]> refresh my memory why is it that `(...) rescue 'foo'` is eligible for trace omission while `(...) rescue Foo` is not?
<kares[m]> think both avoided trace in the past but that was problematic ... not sure why
<enebo[m]> kares: I don't think we explicitly prevent it but likely it is not SideEffectFree?
<kares[m]> it seems prevented, was wondering what would be the side effects. auto-loading?
<enebo[m]> Which could be that we just need to be a bit more elaborate on calculating that from the AST
<kares[m]> askin since I have seen that pattern ... e.g. if you require 'yaml'
<kares[m]> so its pbly not worth the extra effort of calculating?
<enebo[m]> I believe any call at all and we do not do that opt right?
<enebo[m]> foo rescue nil can return something which is not a standarderror
<enebo[m]> so a while without method calls could be added but that is likely extremely uncommon
<enebo[m]> (going to make some breakfast but I will be back soon -- going upstairs :) )
lucasb has joined #jruby
<kares[m]> yes I think atm anything except literals (true, false, nil, 'str')
<kares[m]> will need to dog a bit in the past, recall the elimination was more aggressive as its was introduced (but there were issues)
<kares[m]> * yes I think atm anything except literals (true, false, nil, 'str') disable the optimization ...
<kares[m]> will need to dog a bit in the past, recall the elimination was more aggressive as its was introduced (but there were issues)
nirvdrum has joined #jruby
subbu is now known as subbu|breakfast
shellac has joined #jruby
<headius[m]> I broke the build
<headius[m]> I wear the cone of shame today
<headius[m]> serves me right for trying to fix useless features
<headius[m]> enebo: I assume you saw the fix that prompted this
<headius[m]> TR folks apparently added the specs, though I don't know if they ran into a problem or just noticed
<headius[m]> I'm going forward with jnr-releases today in prep for 9.2.10
<headius[m]> we have a fresh jffi native for MacOS that should fix issues with it being rejected for being too old
travis-ci has joined #jruby
<travis-ci> jruby/jruby (update_jffi:3e80960 by Charles Oliver Nutter): The build failed. https://travis-ci.org/jruby/jruby/builds/649497940 [177 min 53 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> yes yes
<enebo[m]> why why why why why why
<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
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:3141443 by Charles Oliver Nutter): The build was fixed. https://travis-ci.org/jruby/jruby/builds/649506686 [181 min 39 sec]
travis-ci has left #jruby [#jruby]
<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]> stupid refinements
<headius[m]> core compat issue but could be delayed
snickers has joined #jruby
<headius[m]> enebo: I replied to your comments. Basically the old finvokes now call finvokeWithRefinements passing a null scope
<headius[m]> btw anyone, check out https://github.com/jruby/jruby/issues/6006
<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
snickers has quit [Quit: Textual IRC Client: www.textualapp.com]
nirvdrum has quit [Ping timeout: 260 seconds]
lucasb has quit [Quit: Connection closed for inactivity]