snickers has joined #jruby
snickers has quit [Remote host closed the connection]
snickers has joined #jruby
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
lucasb has joined #jruby
snickers has quit [Quit: Textual IRC Client: www.textualapp.com]
rsim has joined #jruby
shellac has joined #jruby
rusk has quit [Remote host closed the connection]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
rsim has quit [Remote host closed the connection]
Iambchop has quit [Ping timeout: 257 seconds]
lopex has quit [Ping timeout: 258 seconds]
Iambchop has joined #jruby
lopex has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
Antiarc has quit [Read error: Connection reset by peer]
Antiarc has joined #jruby
<travis-ci> jruby/jruby (master:67fed2f by Thomas E. Enebo): The build was broken. https://travis-ci.org/jruby/jruby/builds/560567143 [201 min 13 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<headius[m]> blast this load service concurrency bug
<headius[m]> so close to done and I can't find this last thing
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:67fed2f by Thomas E. Enebo): The build was broken. https://travis-ci.org/jruby/jruby/builds/560567143 [201 min 9 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:a6302ad by Charles Oliver Nutter): The build was broken. https://travis-ci.org/jruby/jruby/builds/560246314 [214 min 17 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> what in the world is going on
<enebo[m]> headius: I am restarting some sequel jobs as it seems like something weird is happening but I don't understand why
<headius[m]> I just went to travis and it claime there's no jruby/jruby repo
<headius[m]> we need to get off that service
<headius[m]> every week it's some new failure
<enebo[m]> sequel has not changed in a week so I don't get what is failing
<enebo[m]> this I highly doubt has anything to do with travis
<headius[m]> how did it fail?
* headius[m] uploaded an image: Screen Shot 2019-07-18 at 3.50.38 PM.png (85KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/kHXRPXLiIwqQgbNWKeiCzzwB >
<headius[m]> I'm just about fed up man
<enebo[m]> well besides restarting the sequel job I am trying to figure that out
<headius[m]> it seems to be back now but it gets flakier every day
<headius[m]> no errors in the failed job?
<enebo[m]> It is fine to bag on travis and consider another thing but I am more confused how sequel is failing now
<enebo[m]> It may be one of the gems it depends on got updated and I did not notice which one
<enebo[m]> sequel itself has not changed and my last commits seemed impossible to cause whatever is wrong
<headius[m]> travis may indeed not be related to your issue
<enebo[m]> I just restarted yours since it was green
<headius[m]> but it's pretty hard to tell when everything seems to be falling apart
<enebo[m]> hey I am not disagreeing
<headius[m]> that push was over 24h ago
<enebo[m]> what push was?
<headius[m]> yeah I know I'm just frustrated
<headius[m]> my commit that apparently failed above
<headius[m]> the float fallback
<headius[m]> I have not pushed anything to master today
<enebo[m]> I restarted sequel in that job which was already green and whatever is wrong with that is from something in running sequel
<enebo[m]> So it is totally totes legit message
<headius[m]> ah so that result looked delayed because you restarted part of it
<headius[m]> there's definitely nothing in my commit that should break sequel
<enebo[m]> yes and that was what I tried to say immediately after it notified the channel
<headius[m]> we don't even run those tests with indy
<headius[m]> yeah I thought you meant your own jobs
<enebo[m]> Since I realized once I saw it that it would look confusing
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:c527185 by Thomas E. Enebo): The build was broken. https://travis-ci.org/jruby/jruby/builds/559647148 [209 min 17 sec]
<headius[m]> I'll look too
<enebo[m]> So green on our part with no functional change in sequel
<headius[m]> I've been reduced to throwing locks at the problem and letting stuff run forever and praying
<enebo[m]> Some gem or something in running sequel at this moment changed
<jeremyevans> Sequel's last travis run was green on jruby-master https://travis-ci.org/jeremyevans/sequel/jobs/559999007
<headius[m]> locally I've got the test running continuously for an hour with no failure but that means nothing
<enebo[m]> I guess I will copy/paste and see if I can see a different set
<headius[m]> jeremyevans: thank you
<enebo[m]> jeremyevans: yeah this is really weird since a bigdecimal seems to be passing a 'd' somewhere versus a number
<jeremyevans> I've noticed Travis being flaky in regards to JRuby recently as well, but IIRC it was an RVM issue where it didn't even run any tests
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (load_service_redux:3e27195 by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/560675568 [187 min 25 sec]
<enebo[m]> jeremyevans: yeah something with a command from rvm which downloads an empty version of itself. travis seemingly runs an extra rvm command which is not run for MRI
<headius[m]> that's a combination of rvm and travis problems most likely
<enebo[m]> AHA!
<headius[m]> omg my build passed without the concurrency failure I've been looking at
<headius[m]> and still running locally
<headius[m]> a spoonful of synchronization helps the medicine go down
<enebo[m]> kares: put out a new jdbc-sqlite3 on the 16th ... The jdbc-{sqlite2,postgresql} is the only visible change in displayed gem set
<jeremyevans> enebo[m]: That would explain the error
<enebo[m]> That though is weird since the jobs which were green was after the 16th
<enebo[m]> hahahah no it is 18th
<enebo[m]> ok so totally is the issue ... Locally I mst be locked to older version
<enebo[m]> I will bundle update and see if I can get it happening local
<jeremyevans> Sequel's last job ran 1 day ago, so it wasn't affected
<headius[m]> sequel failed in my branch build also
<headius[m]> which has nothing from master for days
<enebo[m]> ok well progress. (not the database progress) so we will figure this out. I am really happy we run your suite in our runs :)
travis-ci has joined #jruby
<travis-ci> jruby/jruby (load_service_redux:3e27195 by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/560675568 [211 min 23 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> there are two remaining failures relating to concurrent autoload
<headius[m]> this is going to be done before the weekend or I'll eat my hat
<enebo[m]> jeremyevans: this is pretty interesting output and I can reproduce
<enebo[m]> in older jdbc-sqlite3 it had like 739 runs or something around there and now it has 801
<jeremyevans> I get the same 2 errors running with jdbc-sqlite3 3.27.2.1 on JRuby 9.2
<jeremyevans> So it looks like not a JRuby bug, but a jdbc-sqlite3 bug. I'll update the Sequel travis config to not allow that version
<enebo[m]> I also put in a puts for getBigDecimal call in jdbc.rb and before 3.27.1 I saw a handful and now I see tons of calls
<enebo[m]> more runs probably means the db is advertising more features and running tests which have never run before
<headius[m]> that's interesting
<enebo[m]> I notice there are some 'end if DB.predicate?' stuff
<jeremyevans> That's another possibility, I should probably look into that.
<headius[m]> what were you fixing with the jdbc-sqlite release?
<enebo[m]> kares released this but I believe it was to update the JDBC adapter for sqlite3 (which also will include sqlite3 impl) and postgresql
<enebo[m]> so likely new sqlite3 probably may support more features and between our code and maybe sequel we are just hitting new behavior for the first time
<enebo[m]> I can tell we hit more runs+assertions with this update in sequel doing: SEQUEL_SQLITE_URL="jdbc:sqlite::memory:" jruby spec/adapter_spec.rb sqlite
<headius[m]> oh right
<jeremyevans> If I had to guess, sqlite3 doesn't really support numeric/double types, so Sequel guesses based on column name, and one of the columns in the metadata query uses a column name that is interpreted as numeric/decimal but actually contains string
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (load_service_redux:ced903e by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/560699341 [184 min 33 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (load_service_redux:ced903e by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/560699341 [203 min 17 sec]
<jeremyevans> Fixed one of the bugs, about to look into the second one
<headius[m]> Oh nice!
<jeremyevans> Looks definitely like a bug in jdbc-sqlite3. It is using java.sql.types.NUMERIC for a field that does not contain numeric values for the PRAGMA foreign_key_list query
<jeremyevans> Found the other issue. Similar issue, different pragma. That one is a regression because the pragma was supported in the old version
<jeremyevans> yay, clean run in JRuby 9.2 with jdbc-sqlite3 3.27.2.1
<jeremyevans> Let me run some more tests to see if the fixes break anything on other versions
<jeremyevans> headius[m]: I just pushed fixes to Sequel, can you retry the JRuby Travis jobs and see if they work?
<headius[m]> Yeah I'll restart one of mine
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (load_service_redux:ced903e by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/560699341 [205 min 24 sec]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:67fed2f by Thomas E. Enebo): The build was canceled. https://travis-ci.org/jruby/jruby/builds/560567143 [202 min 30 sec]
travis-ci has left #jruby [#jruby]
<enebo[m]> jeremyevans: it works!