deobalds has quit [Quit: Computer has gone to sleep.]
vtunka has joined #jruby
headius_ has joined #jruby
Aethenelle_ has joined #jruby
headius has quit [Ping timeout: 240 seconds]
Aethenelle has quit [Ping timeout: 240 seconds]
deobalds has joined #jruby
lanceball has quit [Ping timeout: 240 seconds]
shellac has joined #jruby
lanceball has joined #jruby
<chrisseaton>
headius_: did you notice LabsJDK and GraalVM now have a macOS layout?
<chrisseaton>
We finally listened to you.
m4rCsi_ has joined #jruby
CustosLimen has quit [*.net *.split]
Antiarc has quit [*.net *.split]
m4rCsi has quit [*.net *.split]
CustosLimen has joined #jruby
Antiarc has joined #jruby
Aethenelle_ has quit [Ping timeout: 264 seconds]
Aethenelle has joined #jruby
olle has quit [Quit: olle]
rdubya1 has joined #jruby
rdubya has quit [Ping timeout: 276 seconds]
rdubya1 has quit [Read error: Connection reset by peer]
rdubya has joined #jruby
swills has quit [Quit: No Ping reply in 180 seconds.]
swills has joined #jruby
swills has joined #jruby
jimbaker has quit [Ping timeout: 255 seconds]
jimbaker has joined #jruby
jimbaker has quit [Ping timeout: 260 seconds]
jimbaker has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
olle has joined #jruby
bbrowning_away is now known as bbrowning
yosafbridge has quit [Quit: Leaving]
yosafbridge has joined #jruby
olle has quit [Quit: olle]
lanceball has quit [Changing host]
lanceball has joined #jruby
olle has joined #jruby
yahonda has joined #jruby
<yahonda>
Hello.
<enebo>
yahonda: howdy
<yahonda>
pretty good. Thank you.
<enebo>
yahonda: I was going to ask you about needing to set RAILS env for testing but I realize your config would require it
<enebo>
oh actually no
shellac has quit [Quit: Leaving]
<enebo>
yahonda: you clone both projects into same parent director
shellac has joined #jruby
<enebo>
yahonda: I feel like we should not need to env RAILS by default if we check out in this way.
shellac has quit [Client Quit]
<yahonda>
Yeah, agreed.
<enebo>
yahonda: the code in rails.rake seems to load any installed gem so either I am doing something wrong or this magic is not quite right
<enebo>
ok I re-ran bundle install and now it thinks I want to use installed gem
<enebo>
before it was at least set to ../rails repo
<enebo>
kares: I don't quite grok who this should work
<enebo>
oh I see by default with nothing set it generates this to use whatever version of 5 you happen to have installed from arjdbc.gemspec
<enebo>
but that means if you are new to the project you need to learn about these project specific ENV vars to even try and run tests
<enebo>
I feel this is the opposite of what we want. We want travis to config whatever it needs via ENV vars but if not env vars assume Rails is in a parrallel dir or bail with a helpful message
<enebo>
This way all new contributors will get pestered once about needing correct Rails repo cloned but after that point it should just work
<enebo>
I guess one other wrinkle is version supported but we say which version we support or test against in README. I feel we should be updating that over time and defaulting to it
<enebo>
If we have that info coded somewhere we can also git co to proper version in Rails repo
<yahonda>
I actually did not know well how to run Rails ActiveRecord unit tests from ARJDBC like "rake rails:test_sqlite3"
<yahonda>
also current ARJDBC master suppors Rails 5.1 `5-1-stable` then i needed have some time to jun unit tests.
<enebo>
yahonda: yeah we sort of had dual track going about rubyconf time and this used to be rails:test:sqlite3 but I think kares was trying to unify these better
<yahonda>
sounds good.
<enebo>
yahonda: both of these branches used to only test a single version but it would reload twice
<enebo>
yahonda: actually I take that back...for local tests we would gem load the right version but for rails test we would use whatever was checked out in rails
<enebo>
yahonda: I would like both worlds to merge...it assumes a single version does not load twice and will git co rails to proper version tag
<enebo>
I think our ultimate goal should be to clone our repo, clone rails repo, bundle install, run rake
<enebo>
with no other setup
<yahonda>
yes. this would be an ideal solution.
<enebo>
we could even eliminate the clone rails but personally I think if they are hacking on this stuff they probably have a rails repo already
<yahonda>
well, I always clone rails repository in my development environment. Sometimes I would like to change some code at cloned rails
<yahonda>
and wanted to run unit tests for modified one.
<enebo>
yahonda: ok that is a good point
<enebo>
yahonda: it should not do a checkout on a version perhaps but maybe warn if wrong version
<enebo>
yahonda: or wrong branch...like 'warning: you may be testing against the wrong version (expecting v5.0.6 and got yahonda_test_prepped_stmts)
<enebo>
yahonda: which I guess means it is responsibility of user to checkout proper version tag in rails repo?
<yahonda>
I think once ARJDBC master branch supports Rails master branch,
<yahonda>
it will be a developer/user's responsibility
<yahonda>
to checkout the correct version/tag/branch.
<enebo>
yahonda: yeah I think so too
<yahonda>
i.e. Oracle enhanced adapter does like that.
<enebo>
yahonda: for travis though we will need proper magic but I think we should be doing a shallow clone
<enebo>
yahonda: although we might be already...I have not looked at travis config
<yahonda>
if someone wants to use local branch, I usually use bundler feature to use local cloned repository.
<enebo>
yeah I think we should be doing that universally though
<enebo>
err well local repo maybe not branch
<enebo>
sorry that was confusing
<enebo>
but I am guessing that is only one more keyword from using a local repo in Gemfile
<yahonda>
you do not have to update Gemfile.
<yahonda>
let me explain my use case.
<yahonda>
Oracle enhanced adapter Gemfile sets like this:
<yahonda>
by doing so, bundler uses local activerecord gem, not from github.
<enebo>
ok
<enebo>
so this allows you to override the gemfile without needing extra customization like we have but it is similar to our gemfile in that it requires each user to override the default
<yahonda>
yes.
<enebo>
although your stuff is all current perhaps so it does not matter that the default is master
<enebo>
yahonda: so I think we want the default to be what you have in config but give travis env way of overriding for specific values
<yahonda>
It does not have to be "master" branch.
<enebo>
yahonda: yeah it could be a tag too right?
<enebo>
yahonda: v5.0.6 for example
<enebo>
yahonda: that actually would make most sense perhaps...for stable-XX branches at least
<enebo>
and master for that short period of time where we are still catching up to rails support
<yahonda>
I "think" so but I have not set tags, I usually set branch names.
shellac has quit [Quit: Computer has gone to sleep.]
rdubya has joined #jruby
claudiuinberlin has joined #jruby
<kares>
yahonda: cool
<kares>
enebo: am getting close with the support kind of 'merge'
<kares>
lots of issues along the way but I bet you won;t like the big change :)
subbu|workshop is now known as subbu|lunch
<kares>
I still consider 50.0 51.0 pretty much a pre - quite some stuff is broken
<kares>
e.g. jndi completely
<enebo>
kares: ok so merging what was on master for the Java bits?
<kares>
yeah pretty much - but I carefully cherry-picked since the stuff I wanted was scaterred through commits
<kares>
basically the force push master really surprised me I somehow assumed a merge will happen
<kares>
some people were actually using the master branch
<kares>
now they're consufed (well at least one person) and miss the features that were there ...
<enebo>
kares: I did not expect a force but I did not expect a merge either
<kares>
fair enough :)
<enebo>
kares: but yeah we definitely don't want to lose support for java-specific uses we just want to make sure we can support them without cloning large portions of AR itself
<kares>
yeah it is possible but there are some tricks
<kares>
anyway I think it should be close - hopefully next week
<enebo>
kares: actually copying is not totally the end of the world so long as we heavily document why and what it is for
<kares>
the thing is if I only do this on master it will diverge too much
<kares>
so I'd like to put it into 50 -> master
<enebo>
kares: 51.1 will probably go out early next week to since postgresql support is ok enough for people to try
<enebo>
kares: so add to stable-50 and then merge that to master?
<kares>
well there's the data loss issue in PG
rdubya has quit [Quit: Leaving.]
<enebo>
kares: which issue?
<kares>
yeah that seems as simples for long term
<kares>
not sure now - have seen it in tests - there was a TODO from Rob
<kares>
I tackled it down a bit --- its probably AR
<kares>
question is whether core also run into it
<kares>
also had a couple of others e.g. double quoting in PG
<kares>
which means, as far as I know, that all BC timestampts are broken
<enebo>
kares: yeah I will try and get postgres set up and look things over locally
<kares>
it needs a better review
<enebo>
kares: atm I have gotten minitest-excludes working
<enebo>
kares: so I am in process of excluding
<kares>
so I have plently of fixes but it still needs polishing on my end
<kares>
cool that is a another headache
<enebo>
kares: I made a fork of your fork of that gem and added gemspec so we can use it now
<kares>
seen your gemspec bits
<enebo>
the re-exec of rails was losing it somehow so that seemed to be missing link
<enebo>
I sort of expected it to find that plugin magically
<kares>
re-exec arent's you using rails:test_xxx helpers?
<enebo>
b
<kares>
you really should -> its much cleaner with our Gemfile
<enebo>
env_sh env, "#{FileUtils::RUBY} #{args}" do |ok, status|
<kares>
basically do the same as CI does
<enebo>
what is that for?
<enebo>
isn't that reexecing ruby?
<kares>
do get the ENV bits passed over
<kares>
yeah but there we bundler/setup from our Gemfile
<enebo>
sure but that is executing jruby a second time isn't?
<kares>
that is right yes
<kares>
thought you meant the re-re-exec that you used before
<enebo>
oh ok well somehow minitest-excludes is not loading as a plugin without an explcit require
<kares>
that should be doable since we load some bits from ARJDBC
<enebo>
well I just called Rails rake but I guess it was calling Ruby a third time
<kares>
yep
<kares>
think I added an explicit -rminitest/excludes
<kares>
let me check
<kares>
not seeing it but I think its needed and should be fine
<enebo>
kares: yeah that is what I just did
<enebo>
kares: so I have one bogus rails test excluded and I will need to maybe add issues for each other one
<enebo>
kares: but I will commit this soon so you can see it
<kares>
oki
<kares>
think I already added a few excludes as well
<kares>
should be on 50-stable
<enebo>
kares: yeah I see the Mysql ones but I don't think those will work
<enebo>
kares: for each module that class is in you need a corresponding directory
<enebo>
kares: but simple enough to move it to the right place
rdubya has joined #jruby
<enebo>
kares: do you know what a timeout of nil means
<enebo>
kares: I am looking at sqlite3 but I maybe think unlimited?
subbu|lunch is now known as subbu
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]