nirvdrum has quit [Ping timeout: 244 seconds]
nirvdrum has joined #jruby
_whitelogger has joined #jruby
jmalves has joined #jruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:26eba27 by Benoit Daloze): The build has errored. https://travis-ci.org/jruby/jruby/builds/485022341 [247 min 34 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:e650791 by kares): The build has errored. https://travis-ci.org/jruby/jruby/builds/484725245 [267 min 31 sec]
travis-ci has left #jruby [#jruby]
aqd has joined #jruby
Nikolay_ has joined #jruby
lucasb has joined #jruby
<Nikolay_> Hello! Is here an ok place to present a "If you're not sure if something's a bug" problem related to activerecord-jdbc-adapter?
<Nikolay_> gonna leave this here just in case:
<Nikolay_> I'm trying to upgrade my Rails 4 app to 9.2.5.0
<kares> Nikolay_: yes, welcome
<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_> I created a demo migration that passes when running with jruby-9.1.2.0 (my current ruby) and fails with jruby-9.1.17.0 (my first step in the upgrade): https://gist.github.com/nbekirov/b41690913c81a9da12de8e88012e6057
<Nikolay_> yields: "Index name 'index_mega_suppliers_on_name' on table 'mega_suppliers' does not exist"
<Nikolay_> what I found so far
<kares> okay well there's a lot we need to do by only having a migration
<kares> it would be best if you reduce that -> with a full blown app or an isolated reproducer
<Nikolay_> ok, I'll do that
<Nikolay_> do you want me to link specific code I found to be related in the meantime, as I already prepared some
<Nikolay_> or when done with the app?
<kares> Nikolay_: feel free to report this as is and link what you've found
<kares> definitely open up an issue
<kares> put everything in there so we have it all in one place :)
<kares> its weird that this would work on 9.1.2 but not on 9.1.17 so include that with your gem versions
<Nikolay_> Thank you @kares, I'll open an issue in activerecord-jdbc-adapter repo
<Nikolay_> in 9.1.7.0 repond_to? behaviour was changed https://github.com/jruby/jruby/issues/4253
<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
<enebo> <#<Date: 2019-01-29 ((2458513j,0s,0n),+0s,2299161j)>>
<kares> ah nice - you have the same julian date number
<kares> mine is always off 1
<enebo> so some internal equality issue here then
<enebo> I did manually run this but I just did a print and they were identical
<enebo> so I assumed they would be equal :)
<kares> <#<Date: 2019-01-29 ((2458512j,0s,0n),+0s,2299161j)>> expected but was
<kares> <#<Date: 2019-01-29 ((2458513j,0s,0n),+0s,2299161j)>>
<kares> for me, yay!
<enebo> This could be more than one error then although likely 1
<kares> yy, need to first understand the issue you were trying to fix :)
<enebo> well I was applying a fix someone else was trying to fix but it seemed reasonable based on Charlie's fix
<enebo> return this.start == that.start && this.dt.equals(that.dt) &&
<enebo> this.subMillisNum == that.subMillisNum && this.subMillisDen == that.subMillisDen;
<kares> fyi regarding Travis's recent fails -> on my fork green :) https://travis-ci.org/kares/jruby/builds/485935429
<enebo> kares: so which MRI test was culprit? or did you find more than one?
<kares> MRI was failing ~ to JRuby's test_date.rb -> julian number of by one
<enebo> kares: but I was seeing a no 10 minute error for last week or two
<kares> a no 10 minute error?
<enebo> no output in 10 minutes
<kares> oh yeah on Travis that was due expired certificates
<kares> they expired recently
<kares> that was fixed by my commit 2 days ago
<enebo> kares: ah excellent I saw you land that
<kares> but than we got this new failures
<kares> I tried purging the caches already twice on jruby repo
<kares> it seems mvn does just get stuck -> let's hope it will run in a week cause these are really annoying
<kares> 1) Failure:
<kares> TestDateParse#test_parse__comp [/home/kares/workspace/oss/jruby/test/mri/date/test_date_parse.rb:618]:
<kares> <[2019, 1, 29, 23, 55, 0]> expected but was
<kares> <[2019, 1, 28, 23, 55, 0]>.
<enebo> I just assumed it was more thread test flakiness
<kares> mri:stdlib
<kares> so I will start there
<enebo> kares: ok. I am trying to finish up oj port this week...it is going on way too long
<kares> +1
<enebo> kares: but if we get the date thing fixed 9.2.6.0 can go out
<enebo> 9.2.7.0 can be require + refinements
<kares> sounds like a plan!
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:ae888ff by Thomas E Enebo): The build has errored. https://travis-ci.org/jruby/jruby/builds/485935565 [300 min 9 sec]
travis-ci has left #jruby [#jruby]
<Nikolay_> @kares, here's the issue I promised: https://github.com/jruby/activerecord-jdbc-adapter/issues/985
lucasb has quit [Quit: Connection closed for inactivity]
Nikolay has joined #jruby
Nikolay has quit [Client Quit]
lucasb has joined #jruby
Nikolay_ has quit [Ping timeout: 256 seconds]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:ae888ff by Thomas E Enebo): The build has errored. https://travis-ci.org/jruby/jruby/builds/485935565 [290 min 43 sec]
travis-ci has left #jruby [#jruby]
Nikolay_ has joined #jruby
haze has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]
Nikolay_ has quit [Ping timeout: 256 seconds]
Nikolay_ has joined #jruby
<headius> hello hello hello!
<headius> back from vacay and ready to rock
Nikolay_ has quit [Ping timeout: 256 seconds]
<kares> welcome back!
Nikolay_ has joined #jruby
Nikolay_ has quit [Ping timeout: 256 seconds]
<headius> kares: thanks!
<headius> sounds like we are doing ok on rails 6 AR support with some upcoming patches?
<kares> headius: enebo pbly knows better - but there's definitely some great work by Daniel already in
<headius> cool, good leg up
<headius> I'm going to finish refinement work this week and hopefully get to 100% passing
<headius> maybe with optimization but that's not priority at themoment
<enebo> we have only like 2F on all three adapters same 2F too
<enebo> so AR is looking pretty good for 6
<headius> refinements are at 11F7E but there are some knock-on effects in other tests I need to tidy up too
<headius> that appears to be all that was necessary to fix JRuby on i18n so I guess the basics of refinements were ok
<headius> but this is already fixed on my branch too
<kares> I also should have a proper fix for the Date.today TZ madness
<kares> like tomorrow hopefully
<headius> oh very nice
<headius> remaining refinements issues should mostly just be getting non-refined logic to recognize and ignore refinements as appropriate
<headius> since this mechanism basically decorates method tables with special refinement markers
<enebo> nice
<enebo> that they still used our existing refinements impl and it works with that small change
<kares> MRI uses JRuby refinements impl?
<headius> kares: I think he means that we mostly worked except for the minor thing they patched around
<enebo> kares: no I just meant other than a single include our existing refinements impl worked for i18n
<headius> the patch they did was that refinements are supposed to be active in the scope they're defined, which we didn't do until my branch
<headius> other than that we must have dispatched correctly 👍
<enebo> Based on some of the reports I expected it to be a bit more exotic
<enebo> headius: could be land just that change easily?
<enebo> for 9.2.6.0?
<headius> and related...JRuby will mimic MRI refinements impl for now for simplicity
<headius> hmm that's possible
<enebo> Just does not look very risky from that description
<headius> it's just a matter of adding the current scope to its own refinements
<headius> basically
<enebo> but it is ok not to since they basically released with that
<enebo> the one release we did not work with was short-lived
<headius> it could fix a number of things for users since this prevents refined methods from seeing themselves
<headius> which for any non-trivial refinement is probably not uncommon
<enebo> headius: well up to you based on risk/effort
<enebo> I know you wanted to wait for bulk to be 9.2.7.0
<headius> yeah the method table changes should wait
<headius> but I'll have a look at that
<headius> a quick look
<headius> enebo: 1.3.0 is the bad i18n?
<headius> looks like that's the last release before they patched around refinement thing
<enebo> headius: If I had to guess you would not see much other than that in the release
<enebo> since it was released like the 23 of dec
<enebo> or thereabouts
<headius> yeah ok
<enebo> zowie
<headius> 20 dec
<enebo> they put out 4 releases since then
<enebo> I like 1.4.0 -> 1.5.1 but whatevs
<enebo> maybe a gem push failed
<headius> enebo: I think this is a trivial fix
<headius> testing now
<enebo> headius: if you do land review to see if that is enough for any of those issues marked against 9.2.6.0
<enebo> It would be slick if they are
travis-ci has joined #jruby
<travis-ci> jruby/jruby (refinements:f601372 by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/486117997 [222 min 48 sec]
travis-ci has left #jruby [#jruby]
<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
<headius> that regresses
<headius> yeah so this regression is a direct result of actually activating refinements at the top of that refine block
<headius> that's really all it is
<headius> previously the block wouldn't be marked as refined until the using
<headius> now it is marked as refined the whole time, but the using isn't temporal
<headius> so I am not sure this is really a big regression
<enebo> the main question would be could someone be using refinements today and be broken with this fix
<enebo> and I mean correctly using refinements vs working with our current impl
<headius> the cases that fail would only be ones where using comes later in a scope (earlier methods shouldn't see it)
<enebo> I could see someone doing refinements wrong because we do but that is not a problem we can worry about
<headius> so they're using into a scope but expect scopes before that using not to see it
<enebo> but that would be using it wrong?
<headius> well I wouldn't say wrong
<headius> it's weird
<headius> I have not seen it in the wild but this is probably in response to them "refining" the feature for a user
<headius> oh well there's another half to this
<headius> they'd have to be using something late in the scope that actually affects the first part of the scope
<headius> like if they wanted the first few methods not to see a String refinement, and the later ones to see it
<headius> actually
<headius> wait
<headius> that still wouldn't be affected
<headius> because we would not be activating the refinement until the using
<headius> so the only case that is different from before is doing this *within* a refine block
<headius> and expecting early parts of the refinement to not see later using
<headius> that is pretty narrow and weird
<headius> on the flip side this fixes a pretty core flaw in 9.2.5 refinement logic
<enebo> ok well I am ok either way. 9.2.7.0 hopefully will not be too far from 9.2.6
<headius> I think it's ok
<enebo> ok cp it then
<enebo> looks like kares fixed the date bug so I will test release bits in the morning
<enebo> and probably make sure nothing else critical is slipping by
<headius> ok
<headius> I have nothing else for 9.2.6
<enebo> ok trying to reduce number of marked issues for each point
<enebo> but I don't want to miss any simple incidental fixes from users
rdubya has joined #jruby
<headius> ok, I pushed the cp and the temporary tag
<headius> back to my branch now
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:8f0ada6 by Thomas E Enebo): The build has errored. https://travis-ci.org/jruby/jruby/builds/486140189 [269 min 9 sec]
travis-ci has left #jruby [#jruby]
mat_bug has joined #jruby
mat_bug has quit [Ping timeout: 252 seconds]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:5913dff by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/486140626 [261 min 37 sec]
travis-ci has left #jruby [#jruby]
mat_bug has joined #jruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (refinements:0073bf2 by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/486169071 [182 min 27 sec]
travis-ci has left #jruby [#jruby]