ur5us has joined #jruby
<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
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:af0582d by Charles Oliver Nutter): The build was fixed. https://travis-ci.com/jruby/jruby/builds/208735016 [212 min 40 sec]
<kares[m]> I am still interested in the reflective approach - but not having it exposed by default.
<kares[m]> something to opt in or use selectively: `Java.reflective_inspect obj, transient: false`
<kares[m]> we could mark it as an experimental ... the thing is it would help a lot poking around Java objects (despite the reflection headaches).
<kares[m]> which reminds me JRuby still uses reflection with `field_reader` and friends ...
travis-ci has joined #jruby
<travis-ci> jruby/jruby (load_service_redux:a43cbe1 by Charles Oliver Nutter): The build was fixed. https://travis-ci.com/jruby/jruby/builds/208735839 [202 min 57 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> double bam
<headius[m]> kares: that is a good idea
<headius[m]> my IR printer uses reflection to inspect all instructions and operands, might be a simple enough pattern to expose in Ruby
<headius[m]> it is all the same sort of thing though I guess
<kares[m]> yy ... also had it in the previous inspect PR
<headius[m]> cool ok
<headius[m]> I think I will merge the load service stuff tomorrow and then see about getting the remaining specs and zeitwork 100%
<headius[m]> 9.3 is in sight
<headius[m]> ah let's just merge it now
<headius[m]> start the baking process!
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
drbobbeaty has quit [Quit: Textual IRC Client: www.textualapp.com]
drbobbeaty has joined #jruby
<jbeyer_wgt[m]> headius: thanks for your note on Apple Silicon, and of course for all of your hard work!
<jbeyer_wgt[m]> I'll likely order one soon, and report back what I find
kovyrin[m] has joined #jruby
<kovyrin[m]> Hello, Everybody
<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
<headius[m]> in this case the "if 2..3" should not just automatically be true, it should be comparing the range with $.
<headius[m]> a regexp should be comparing with $_
<headius[m]> some weird awk/sedisms that we don't appear to do in our compiler
<enebo[m]> hmm wot
<headius[m]> this is the source of two failures in the -e specs
<enebo[m]> $. is used for 2..3?
<headius[m]> and probably a bunch in the -n specs
<headius[m]> yes
<headius[m]> when an if has a bare literal like these it is not just true, it does a hidden comparison
<enebo[m]> That is true universally as well then?
<headius[m]> I don't know all the literals supported
<headius[m]> yeah that example is just printing out iseq for that snippit of code
<enebo[m]> 2..3 in any if does that?
<headius[m]> when run with -n that will take $. (the parsed gets result as an Integer) and only print if it is in 2..3 range
<headius[m]> I could do the same with if /[23]/
<headius[m]> but that would use the unparsed $_
<enebo[m]> unparsed $_ would not match 2 or 3 unless it contained it
<enebo[m]> but $_ is what a bare regexp uses
<enebo[m]> I just did not realize $. is for a range...unless it is only with -n
<headius[m]> well it works without -n
<enebo[m]> ok yeah that is good
<enebo[m]> I would have expected that but you never know
<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
ahorek[m] has quit [Ping timeout: 268 seconds]
ahorek[m] has joined #jruby
ur5us has joined #jruby
<travis-ci> jruby/jruby (master:1fa407b by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/208965064 [201 min 38 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
MattPattersonGit has quit [Ping timeout: 260 seconds]
MattPattersonGit has joined #jruby
ur5us has quit [Ping timeout: 258 seconds]