<headius[m]> I wonder how well it maps to relational algebra
ur5us has quit [Ping timeout: 256 seconds]
<lopex> it doesnt, just as any sql / nonsql system
<headius[m]> makes sense
<lopex> its on the wiki even let me check
<lopex> it was about not preserving set laws
ur5us has joined #jruby
<lopex> which I think boils down to not having keys as requirement
<headius[m]> ah well that would make it tricky :-)
<lopex> but sql doesnt have it :P
<lopex> it's all bags
<headius[m]> bag algebra
<lopex> bingo
ur5us has quit [Ping timeout: 256 seconds]
<headius[m]> I thought this behavior was covered in the wiki but perhaps it's too hidden
<headius[m]> I hope GH is back up and working by morning
ur5us has joined #jruby
ur5us has quit [Ping timeout: 244 seconds]
ebarrett has joined #jruby
nirvdrum has joined #jruby
_whitelogger has joined #jruby
nirvdrum has quit [*.net *.split]
nirvdrum has joined #jruby
subbu is now known as subbu|lunch
<headius[m]> kares: I just caught up to https://github.com/jruby/jruby/pull/4714 in my "old bug" audit
<headius[m]> I'll give it a shot to merge and see if can repush but it's been a while
subbu|lunch is now known as subbu
<kalenp[m]> Hi JRuby folks. Trying to come up with a workaround for this bug a coworker discovered/filed (https://github.com/jruby/jruby/issues/6319) and have a few questions about some of our possible approaches.
<headius[m]> yah I saw that one, trying to dig out of a backlog so I can look at it
<headius[m]> that usually means that some optimization fired improperly (concurrency or otherwise) and we have an unoptimized method trying to run against optimized state (which would have eliminated the proper DynamicScope in this case)
<headius[m]> we did some concurrency fixes for IR optimization that may not have been fully good, it seems
<kalenp[m]> fwiw, we didn't hit this in 9.2.9, so that might help narrow the scope of the regression
<kalenp[m]> playing around with runtime options, it seems like jruby.jit.background=false may clear up the issue, which would agree with the concurrency hypothesis. but we weren't sure if that option would be a bad idea or not. from the outside, it seems like it might slow startup performance, but steady-state, once everything has been jitted, it should even out?
<kalenp[m]> the other route we tried was to do full AOT compilation, but we have issues with warbler and compiling gems. that got us to looking at the warbler project it seems like it's not very active anymore. is there another project we should be using for building a jar from our jruby+java application, instead?
<headius[m]> disabling background jit should be a fine change, and if that works for you without impacting other things too much it should be safe
<headius[m]> full AOT compilation largely had a reboot in JRuby 9.2 and as such it doesn't really AOT compile anything... my dodge to avoid reimplementing the AOT compiler was to just serialize the IR into a big string and stuff that into a class file 🤣
<headius[m]> so it might not actually help you in its current form... it literally just skips the initial parse and compile stages
<headius[m]> sorry, a reboot in JRuby 9k... it is now possible to fully AOT compile a piece of Ruby code to JVM bytecode again, but it's not hooked up in a usable way yet
<kalenp[m]> so this data's out of date, then? https://github.com/jruby/jruby/wiki/JRubyCompiler
<headius[m]> yeah I suppose it is
<headius[m]> warbler otherwise should be fine, but if you were hoping to use it for AOT compilation it won't get you anything
<headius[m]> and yeah it's not maintained well... our guy doing that from Heroku was moved on to other things and left a void
<kalenp[m]> ok. we were thinking that the error was in dynamic/jitted compilation, so doing AOT compilation might have helped avoid that. sounds like it doesn't make a difference, then
<kalenp[m]> probably just coincidence that we saw the error in gem code (not AOT due to warbler bugs) rather than our own (AOT)
<kalenp[m]> well, thanks for the info. I'm disappointed we didn't catch this before the 9.2.12 release went out. we're working on getting a testing environment set up where we can run looker with pre-release versions to get these to you before the release
<headius[m]> we'll queue up that issue and then debate whether we're close enough to 9.3 to drag our feet a bit
<headius[m]> it would help if you can give 9.3 snapshots a once over
<headius[m]> I'm glad the background jit helps
<headius[m]> kares: do you have any idea what's going on with this "fileutils" error on Travis?
<kalenp[m]> 🤞initial testing seems promising, at least. then we just need to figure out how to coordinate with ops to get that deployed...
<headius[m]> something changed in one of the maven plugins that I didnt' notice?
<headius[m]> kalenp: not sure what your deployment looks like but we do push those snapshots to Sonatype's snapshot repo, if it helps, and there's nightlies published from that on https://github.com/ruby/jruby-dev-builder/releases/latest
<headius[m]> so whatever form you use JRuby in it should be out there in a canonical snapshot form
<headius[m]> I wish we could do more frequent releases... just takes a lot of time to fix and verify stuff
<kalenp[m]> 👍️ will send that to the CI team
ur5us has joined #jruby
nirvdrum has quit [Ping timeout: 272 seconds]
<headius[m]> eliminated dozens of places we instantiate a new function object for Enumerator#size in place of static method references