00:55 <enebo[m]> headius: we went with rdubya leveraging another gem

01:38 <headius[m]> Yeah is there something we need to do for this other contributor?

01:49 <enebo[m]> headius: I mean I don't really know...they just forked and kept going after we expressed a desire to do what we ended up doing. We definitely can link to their fork or perhaps encourage some name change perhaps?

01:55 <enebo[m]> So I guess we could document that it exists and close the PR

02:02 <headius[m]> Yeah just looking for some kind of closure on that

02:03 <enebo[m]> Let's talk about this tomorrow. I want to say something positive but we already made a choice based on maintenance cost.

02:47 <headius[m]> Ok

16:46 <cshupp[m]> OK I have my build working w/o the torquebox server on java 11.

16:46 <cshupp[m]> Here is what I had to do.

16:46 <cshupp[m]> 1: Make the maven changes outlined previously in here

16:47 <cshupp[m]> 2: In java 11 in java.security make these changes to the file:

16:47 <cshupp[m]> #keystore.type=pkcs12

16:47 <cshupp[m]> keystore.type=jks

16:48 <cshupp[m]> 3: There is apparently a bug in the version of rubygems outlined here that torguebox is using:

16:48 <cshupp[m]> https://bundler.io/blog/2019/05/14/solutions-for-cant-find-gem-bundler-with-executable-bundle.html

16:48 <cshupp[m]> So in my pom I ensure if I have this:

16:49 <cshupp[m]> That my gemfile.lock matches:

16:49 <cshupp[m]> BUNDLED WITH

16:49 <cshupp[m]> 2.1.4

17:46 <headius[m]> cshupp: Ahh I remember that bug

17:46 <headius[m]> we only got that patched up within the last year I think

18:06 <travis-ci> jruby/warbler (master:6d395d8 by Charles Oliver Nutter): The build has errored. (https://travis-ci.org/jruby/warbler/builds/640068948)

18:35 <headius[m]> I'm working on AOT...first trying to get a grip on how much ovrehead is currently involved in deserializing IRScope

18:36 <headius[m]> tricky bit seems like it's going to be getting the IRScope instances in a place where the bytecode can see them

18:36 <headius[m]> enebo: what's the status of your branch at this point? It may be a better place for me to work from

18:36 <enebo[m]> I have to walk out the door

18:36 <headius[m]> ok

18:36 <headius[m]> we'll talk later

18:37 <enebo[m]> but you can look at it jit_irscope_removal

18:37 <headius[m]> ok

18:39 <headius[m]> running a bench deserializing erb.rb looks like it's sub-ms times very quickly

18:44 <headius[m]> yeah this is tricky...persisted IR and AOT bytecode both have their own tree of scopes and they need to know about each other

18:46 <headius[m]> perhaps the IRScopes could be deserialized along with method handles to point at their JVM version

18:47 <headius[m]> need to look at branch for a bit

18:51 <headius[m]> https://gist.github.com/headius/cf8af0793c7ca3e04211589b4d279421

18:52 <headius[m]> hmmm

18:53 <headius[m]> if JVM compiler mapped scopes to method names in the resulting output it should be possible to inject those handles when deserializing

22:46 <lopex> numbers?

22:46 <headius[m]> soon perhaps!

22:47 <lopex> w00t

22:50 <lopex> I hope not many unstable 2.7 changes get adopted soon

22:52 <lopex> thankfully ruby never made the python 2.7 mistake

22:52 <lopex> headius[m]: right ?

22:53 <headius[m]> what's the python 2.7 mistake?

22:53 <lopex> headius[m]: splitting the versions basically

22:53 <lopex> which hampered adoption

22:54 <lopex> keeping 2.7 so long slowed down 3.x

22:55 <lopex> they're passed that point, but that's what it was

22:56 <headius[m]> 1.9 was really the big move, and 1.8.7 was a bad attempt to bridge the gap

22:56 <headius[m]> in Ruby

22:56 <lopex> yea, it was never the case in ruby

22:57 <lopex> even if it might seem so

22:57 <lopex> the changes like print 'a' no being syntax anymore

22:57 <lopex> ruby never had those

23:00 <lopex> headius[m]: in any case print was a keyword in 2.x

23:00 <lopex> so that;s a pretty dramatic change

23:06 <headius[m]> ah yeah that sort of change is so risky