subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
<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 have pushed byteit101 PR as a test branch here to confirm the logger errors are gone:
<headius> will review code again now
<headius> ugh testing locally and just realized I had not rebuilt with that PR in place 🤦‍♂️
<headius> byteit101: ok I must be doing something wrong here... why does this output not include the stringField:
<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
<headius> yeah just that
<enebo[m]> the close issue associated with it and close milestone
<enebo[m]> do you want me to make next version of one too?
<headius> 500 error when I try to make milestone
<headius> the issue he links in JRuby is just my jcodings update PR
<headius> but that exclude can go away
<headius> I will update my jcodings PR once the release is out
<headius> and when that is pushed you can merge it and we should be good
<enebo[m]> oh I thought this was related to
<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]> do you need to threaten yourself?
<headius> We don't have the rights to push the artifacts anywhere I don't think
<headius> Maven and rubygems
<byteit101[m]> I've found that I can resolve newer artifacts just fine, but older artifacts have strange maven errors
<byteit101[m]> Ah
<byteit101[m]> so not sure if it's the old maven or what
<byteit101[m]> does anyone know of any dead java/maven projects that died recently?
<headius> I'm not sure... All of those may even related JV projects need big time updating though
<headius> s/may/maven/, s/even//, s/JV/JVM/
<byteit101[m]> I see ruby-maven was recently updated
<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