<headius>
Yeah I will review and finalize tomorrow
subbu has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 252 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
sagax has joined #jruby
<headius>
ok I have modified the logger specs to guard on logger version rather than Ruby version
<headius>
updating logger tests from the gem brings us down to one failure I'm looking into
<headius>
ok I think I have an explanation
<headius>
the final failing test confirms that once a log file has been shifted (e.g. after a certain size or time) any other open logs against that file reflect the new name (old name + ".0")
<headius>
the test in this case is identical?(new name, old log File object)
<headius>
in CRuby I think they are using fstat to always get the actual name of the open file, which will reflect renames... but we use the original name the file was opened under
<headius>
ahh not quite that: in CRuby, File.identical? stats both file objects (or paths) and uses that to compare, while we just canonicalize the stored path and compare
<headius>
so this is a valid failure but unrelated to logger
<headius>
the renamed file should actually propagate to other open logs on the same entry but it is a querying/reporting bug in File.identical? preventing the test from seeing that
<headius>
so I will exclude this and we can deal with the identical? issue separately
<headius>
I wanted to confirm outside of specs that the field was there and getting set so I could then also confirm invokedynamic is binding to the field
<headius>
I must be doing something wrong but this seems to match your example specs
<headius>
if I can get an explanation of that we can merge that PR any time and then I think 9.3.4 is ready
<headius>
enebo: ^
<headius>
the branch I pushed with the logger test fixes and ivar stuff together is green
<enebo[m]>
yeah great
<headius>
enebo: I tried to merge 9.3 to master but your kwarg change has a conflict and I'm not sure what to do
<enebo[m]>
oh I can do it. It probably is confused because the 9.4 flag is very similar to the one on 9.3
<headius>
yeah that and setKeywordArguments vs setKeywordRestArguments
<enebo[m]>
yeah it appears both flags are still present in MRI
<headius>
enebo: something seems to be broken with my github account
<headius>
those commenting errors I got the other day are now preventing me from commenting or merging ahorek's jcodings fix, which we should ship in 9.3.4
<headius>
I tried to log out and got a 500. Tried to log in on an incog tab and a different browser and I get 500s.
<enebo[m]>
I can see if you are listed on jcodings
<enebo[m]>
oh ok well that likely is something else
<headius>
something is really screwed up with my account
<enebo[m]>
yeah I guess contact support. We need to release jcodings?
<headius>
yes
<headius>
we did not mark the bug for 9.3.4 but since ahorek found the problem we might as well
<enebo[m]>
ok. I can release. we use the full release plugin for that
<headius>
it is that AIOOB issue in a japanese encoding
<headius>
I can release if you can do the milestones... git stuff seems to work but the site is not letting me do much
<enebo[m]>
It is not linked and this only points at your PR which only changes a test
<headius>
I thought it was too but I guess this is a different failure
<enebo[m]>
ok
<headius>
it is a failure we had excluded
<enebo[m]>
so I will close out the milestone and make a new one
<enebo[m]>
It is merged
<headius>
ok
<headius>
it's weird... I can interact with jruby/jruby ok but not jruby/jcodings
<headius>
all 500s on jcodings
<enebo[m]>
I did notice one weird thing on jcodings
<enebo[m]>
The UI when setting mileston is not updating locally but if I click back on the selection pulldown it is marked
<headius>
it was doing that for me too
<headius>
I thought it was not updating
<enebo[m]>
That could be them doing 70 releases a day and messing something up or network or them breaking something with firefox support
<enebo[m]>
It appears to really be set though
<headius>
well I tried to log in on both chrome and safari and got 500 on both
<enebo[m]>
500 is something else
<enebo[m]>
Perhaps they shard or something where you have a broken deploy
<headius>
I see merged PR, I will start release of jcodings 1.0.56
<enebo[m]>
ok
<enebo[m]>
I am trying to remember if it is github but I believe they said they have multiple versions of github running at the same time
<enebo[m]>
some for a/b testing and some because they mitigate pushing bugs by partial rollouts
<headius>
ugh
<headius>
I can't push tags to jcodings
<enebo[m]>
I might be thinking of another company too but i guess I am not saying anything unrealistic on any huge deployed codebase
<headius>
time to move to gitlab?
<enebo[m]>
lol
<enebo[m]>
That is really odd
<enebo[m]>
I cannot imagine that the actual git repo itself is anything other than git but the auth part must be tripping you up
<byteit101[m]>
headius: you are missing some requires. require 'jruby/core_ext' or 'java' I think
<headius>
oh wow why is that
<byteit101[m]>
commented that on issue
<headius>
ok so this is not new but I don't like it
<byteit101[m]>
it's why in the blog post draft I added `require 'jruby/core_ext' # required for become_java! to do anything useful` everywhere
<headius>
no sir don't like it
<headius>
not your issue but we should do something better
<byteit101[m]>
Yes when writing the blog post I ran into this a few times and wanted to change it before realizing that even warning would affect jrubyc usage
<headius>
ok
<byteit101[m]>
could it be possible to have jrubyc automatically include a no-op version, and default then gets a warning or b_j version?
<headius>
PR is merged
<byteit101[m]>
yay!
<byteit101[m]>
I'll prepare to fix it again :-P
<headius>
that's the spirit!
<headius>
lunch break, maybe GitHub will fix my issue and I can get back to work
<byteit101[m]>
btw, the test line you did didn't use any of the new code in the PR. add `, instance_variable: true` if you want to test it
<headius>
Yeah I was using that to dig into assembly but removed it for the simple example when I couldn't get the field to show up
<headius>
I suppose it is picking up the normal Java integration java_field when you don't have the require, so it just tries to bind a field that isn't there
<byteit101[m]>
yes
<headius>
GitHub support claims there were issues earlier today that are now resolved
<headius>
Continuous deployment is a giant steaming load of BS if you ask me
<byteit101[m]>
ruby-maven-libs is at 3.3.9, should it be updated to a more recent version of maven?
<headius>
Yeah probably. We've been trying to take over ownership and maintenance of those projects for a while
<byteit101[m]>
works with all versions specified, and allows "latest" for most recent gems. I suspect it may work for all gems if maven is updated, but not sure
<byteit101[m]>
*maven coordinates, not gems :--P
<byteit101[m]>
2/4 things done for the blog post now