<kares[m]>
headius: thanks for the JI `inspect` feedback. yeah, the previous inspect -> toString was quite a bad idea in retrospective. good that it never made it into a release!
<kares[m]>
will continue making progress on the PR, as time permits, there's much work that can be done here but I'll fix specs and make it green before adding "more features" ...
ur5us has quit [Ping timeout: 260 seconds]
<headius[m]>
kares: I suppose the user accessible way to add inspect would just be to reopen these classes from Ruby... might be worth some addition to JI docs on wiki to suggest that for cases we don't customize
<headius[m]>
jbeyer_wgt: hello!
<headius[m]>
JRuby is currently working fine on Apple Silicon but there are a couple in-progress items
<headius[m]>
firstly, there are very few fully-functional Java builds for Apple Silicon, but the ones I have tested on look good
<headius[m]>
secondly, our low level native library support is not currently functional on Apple Silicon so there are some compatibility gaps that result
<headius[m]>
both of these items are being worked on by other teams and should be resolved soon (if they haven't been already)
<headius[m]>
I would say there is no reason not to go ahead with the new machine... we can work with you to prioritize and fix or workaround the remaining issues if it comes to that
<headius[m]>
I will say we intend to fully support Apple Silicon in the next major release 9.3, which is just around the corner and has working snapshot builds today
<headius[m]>
sequel failure pointed at a bug in the new 2.6 timezone logic, so that's a good find
<headius[m]>
fixed now on master and should be green shortly
<kares[m]>
nice find, indeed!
<headius[m]>
the CRuby logic is arcane... I would be surprised if there aren't more little bugs in there
<headius[m]>
ported to Joda best I could
<kares[m]>
for the user inspect I am thinking about tools we could provide to help ... probably a follow-up PR
<kovyrin[m]>
Oh, and one more weird factoid: `Thread.list` at the end of the method contains a single value in each thread - the new thread object for each thread. Meaning in each of 4 worker threads `Thread.list == [Thread.current]`
<kovyrin[m]>
Finally, Java thread name and thread id remains the same all throughout this mess.
<kovyrin[m]>
This is terrifying, I have been hoping I'm doing something wrong, but after a day of fighting it, I'm fairly convinced the problem is real. Now just looking for a way to find where it is coming from.
<byteit101[m]>
headius: If you haven't seen, I have a bunch of smaller questions now on my PR
<kovyrin[m]>
ok, kares provided some information about the possible reasons for this kind of behavior. I'm glad I'm not going crazy :-)
<headius[m]>
byteit101: ok cool I will have a look
<headius[m]>
kovyrin: ok glad kares got back to you... do you have any other questions?
<headius[m]>
jbeyer_wgt: FWIW I have one of the DTK machines so I have been actively working on JRuby support... hopefully by the time you get your machine all the wrinkles will be worked out
<headius[m]>
enebo: load service redux merged last night
<headius[m]>
there are still some excludes and tags but it can now bake over the holiday and any spec work we do
<kovyrin[m]>
headius: I'm looking for a way to make sure I have a chance to perform a pretty complicated (and relatively long, up to 10-20 seconds) shutdown procedure when a process running jruby-rack is shut down. One option I'm considering is running it from an `at_exit` block directly. Would that work or are those blocks supposed to be fast and it would mess something up?
<headius[m]>
kovyrin: well orchestrating at_exit sections would be complicated, but they are basically just pushed on a queue and run in order before termination
<headius[m]>
we try to order shutdown such that all resources are still active until after Ruby shutdown hooks have run
<kovyrin[m]>
perfect, thank you
<kovyrin[m]>
that seems to work
<kovyrin[m]>
And a huge thank you for all your work on JRuby! I've been following the project for a very long time and am amazed at the quality of the work you all do.
<headius[m]>
Thank you! We have been lucky to have many great contributors and users... so do let us know right away if you have any further questions
<headius[m]>
enebo: I am poking at specs a little today and the first one in the list is for some weird command line -n behavior
<headius[m]>
it seems like we are missing some logic for if statements given specific types of literals
<enebo[m]>
So it looks like IR Builder needs to access $. and compare
<headius[m]>
so this is just a behavior of if conditionals given some types of literal
<headius[m]>
there may be better specs for this somewhere in language
<headius[m]>
if_spec probably
<enebo[m]>
yeah I guess so
<enebo[m]>
2..3 itself is just a range
<headius[m]>
right
<headius[m]>
hmm maybe not
<headius[m]>
spec gap
<headius[m]>
the only if specs we have tagged are flip-flops
<headius[m]>
but there should be specs for these other special cases
<headius[m]>
dunno if this is tested anywhere in CRuby tests either
<enebo[m]>
I am looking at compile.c and so far I do not see what is up
<enebo[m]>
NODE_DOT{2,3} just makes a range when compiled
<headius[m]>
yeah it is only doing this if it is used as a condition
<headius[m]>
it is in "if" compilation presumably
<enebo[m]>
compile_branch_condition would be where I would expect to do something magic
<enebo[m]>
I also wonder about 2..3 || 4..5
<enebo[m]>
because neither would be directly in the if
<headius[m]>
yeah not sure how deep this rabbit hold goes
<headius[m]>
hole
<enebo[m]>
yeah I guess we are not really a CLI impl so this ends up not getting hit but implicit variable binding is something most people also do not do
<headius[m]>
-n specs look gappy too but this isn
<headius[m]>
isn't really a -n behavior
<enebo[m]>
yeah it would be confusing if they conditionally did that I think
<enebo[m]>
not that many people do this stuff
<headius[m]>
nobody does this stuff
<headius[m]>
but fixing it would remove at least two tags 😀
<headius[m]>
there should be more specs for all these special case conditionals though
<enebo[m]>
I am wondering if it is only conditionals too
<enebo[m]>
it cannot be assignment
<enebo[m]>
so it must be in a test context
<enebo[m]>
while(2..3) probably works
<enebo[m]>
for a in 2..3 probably doesn't
<enebo[m]>
but that is not a test
<headius[m]>
hard to search for but I am not seeing MRI tests for this so far
<enebo[m]>
try while
<headius[m]>
ok
<enebo[m]>
I have a curbside I have to go to
<headius[m]>
does not seem to use $.
<headius[m]>
oh wait maybe it does
<headius[m]>
added to gist
<headius[m]>
should I put this in a bug for now?
<headius[m]>
it is at least the root cause
<enebo[m]>
yeah sure...I will look when I get back since this will likely just be a simple IRBuilder fix
<headius[m]>
yeah probably
<headius[m]>
ok
<enebo[m]>
It will just be getting $. and doing a compare
<headius[m]>
yeah just need to find where CRuby is doing this and implement all the same cases