<kares>
are you able to put together a simple reproducer Rails app, maybe even just triggering an AR rename manually and capturing that it also renames the index
<kares>
if so and the difference from MRI Rails is clear I am sure it will get fixed, as it gets reported
<Nikolay_>
and I think this prevented the invocation of ActiveRecord's #rename_table_indexes method
<kares>
Nikolay_: nice find, please include that in your report
<Nikolay_>
I'll link it all
<kares>
enebo: hey! so how far do you think a release would be? I see there's a bunch of refinement issues open for 9.2.6
<kares>
+ of course there's the problem with local date - which I think might be a blocker
<enebo>
kares: 9.2.6.0 would have been released before xmas break but i18n relied on refinements. Since then they have put in non-refinement workaround so we work in newer version
<enebo>
kares: there was a second gem we noticed also used refinements but I cannot find what it is and I don'
<enebo>
t remember
<kares>
oh yeah I have seen that i18n issue
<enebo>
kares: so refinements being pushed to 9.2.7.0 may be ok
<enebo>
since i18n was main obvious issue and we have some breathing room
<kares>
sounds good
<enebo>
kares: the date issue I would like to see resolved though
KeyJoo has joined #jruby
<kares>
okay I will try looking into that - since I am able to reproduce locally
<kares>
but I had a feeling that the code was matching 9.1 quite good
<kares>
and if not it was due some other fixes done in 9.2
<kares>
enebo: one q through: you're able to `rake test:jruby` wout a failure from recent master?
<enebo>
kares: let me try
<enebo>
after landing that travis passed and I did not try :jruby specifically locally
<kares>
there's failures in mri suite for me as well
<kares>
all related to date
<enebo>
I will try that as well but I believe I did that one
<kares>
a UTC env obviously works so I wonder ...
<kares>
just to confirm whether yours is also fine than
<enebo>
in one sense it is too bad our tests are noisy to dev env envs
<enebo>
on another we do find bugs
<enebo>
I also see fail in test:jruby
<enebo>
so that is good
<kares>
that is definitely a relief :)
<enebo>
<#<Date: 2019-01-29 ((2458513j,0s,0n),+0s,2299161j)>> expected but was
<headius>
enebo: it appears you can cherry-pick 5b5bc5e8f12c306c84fa916b6e92f487d21e0402 and get that fix
<headius>
it applies fine and appears to work
<headius>
there were two halves to the fix...using the refinement in its own scope and also flagging refinements as being on in those scopes (IRBuilder change)
<headius>
gem "i18n"; require "i18n/core_ext/hash.rb"; using I18n::HashRefinements; p({"a" => "b"}.deep_symbolize_keys)
<headius>
works properly with just that one commit added to master
<headius>
so I think that's equivalent to their workaround
<headius>
I'll run a sanity check here and then push if it's ok
<headius>
did we have an issue for the i18n thing?
<enebo>
I don't recall but it would be against 9.2.6.0 if we did
<headius>
it looks like this fixes two tests and regresses another
<enebo>
hmm
KeyJoo has quit [Quit: KeyJoo]
<headius>
the regression is due to us not copying refinements into scopes at using time
<headius>
whatever you activate in a refined scope gets seen by all code before and after that using
<headius>
in MRI every time you do using it copies the refinements into the current scope, and then they don't search up the scope hierarchy
<headius>
my branch mimics that generally but master always searches all the way up, so there's no way to have temporal differences
<headius>
the case is like class X; using A; blah { some code that uses A }; using B; blah { some code that uses A and B }; end
<headius>
the first blah block there should NOT see B
<headius>
I think it regresses because we now refine the refinement's own scope properly so more refinements end up visible
<enebo>
so perhaps we just wait
<enebo>
I don't see how it would break someones working refinement code but it is surprising to hear this
<headius>
test_mixed_using is the test in MRI test_refinements.rb