14:21 <headius[m]> enebo: is there a reason RationalNode and ComplexNode return EMPTY_LIST for child nodes?

14:21 <headius[m]> it means their components don't show up in AST printer

14:39 <enebo[m]> headius not that I know of

14:39 <headius[m]> Those seemed to be the only two so I fixed them

14:40 <enebo[m]> headius: was it just hitting a default impl?

14:40 <enebo[m]> or were they exlpicitly returning EMPTY_LIST?

14:41 <enebo[m]> They are the newest AST nodes so it probably just was an oversight when they are added since only ast program really examines by childNodes

14:44 <headius[m]> enebo: explicitly EMPTY_LIST

14:44 <headius[m]> yeah I figure oversight

14:44 <headius[m]> it's fixed now in any case

14:45 <headius[m]> I wanted to see what types of nodes can be inside a complex or rational since they currently are doing indy literals for each element and for the rational or complex itself

14:45 <headius[m]> if it's always numerics (appears to be) they could be a single indy

14:46 <headius[m]> I'm not working on that right now though...pretty unlikely that there's much literal rational or complex usage out there

14:58 <headius[m]> my son recommended using fmt to format this stuff but I think this is fine

15:41 <headius[m]> I think it's time to remove nailgun support

16:42 <headius[m]> Final env log and I am ready to merge the java_opts branch: https://gist.github.com/headius/564a67d7e1ddbb9921aa9be049632b66

16:53 <headius[m]> https://www.reddit.com/r/ruby/comments/d6gtdb/jruby_929_environment_flag_rfc/

17:23 <havenwood> headius[m]: It reminds me of `gem env` which kinda makes me want equivalent of `gem env gempath` to dig into the most commonly checked options, like: jruby --environment=home #>> /Users/headius/projects/jruby

17:23 <havenwood> I guess in that case, there's already an easy way to get the info that's more straightforward.

17:23 <headius[m]> Yeah exactly

17:24 <headius[m]> We do this for other stuff... --properties spots out a formatted .jrubyrc with all current settings

17:24 <headius[m]> Spits

20:31 <headius[m]> havenwood: if this weren't written in bash I might do something more elaborate like `gem env gempath` but this is what I've got to work with

20:32 <havenwood> headius[m]: no doubt. i'm not about to write a Thor clone in bash.

20:32 <havenwood> simple option parsing is convoluted enough in shell scripts.

20:33 <headius[m]> haha yeah

20:35 <headius[m]> ok weird breakage coming from my bash script changes

20:35 <headius[m]> not sure how launcher changes broke a tracer.rb test

20:57 <travis-ci> jruby/jruby (master:76f0f51 by Charles Oliver Nutter): The build was broken. https://travis-ci.org/jruby/jruby/builds/587189902 [211 min 4 sec]

21:00 <headius[m]> this can't be my bug

21:09 <headius[m]> ok I'm stumped

21:09 <headius[m]> I reverted back to before my jruby.bash changes and it still fails

21:11 <headius[m]> what the heck

21:12 <headius[m]> oh ho

21:13 <headius[m]> 12d481b6a71f361583e767ba364ed34a0985e8bd deals with line numbers but how could that be it

21:14 <headius[m]> lopex: hey what's the status of that docker image

21:16 <headius[m]> kares: could this be something you did?

21:16 <headius[m]> it looks like CI stalled for a couple days

21:17 <headius[m]> I confirmed it's still broken before my jruby.bash merge but not sure what it is...that commit hash above is from you

21:18 <headius[m]> I don't see how that would do it though

21:19 <headius[m]> could be my jit changes maybe

21:22 <headius[m]> at least looks like I messed up line number in the presence of tracing

21:24 <headius[m]> oh good lord

21:28 <headius[m]> well that's part of it at least 🤦🏻‍♂️

21:28 <headius[m]> this commit is likely the cause of the other problem too

21:29 <headius[m]> ok looks like it passes now

21:29 <headius[m]> need to get off travis.

22:16 <travis-ci> jruby/jruby (master:5c5d8d3 by Charles Oliver Nutter): The build was fixed. https://travis-ci.org/jruby/jruby/builds/587217346 [230 min 25 sec]