<enebo[m]> puritylake: was this error there before your changes: "TestSprintf#test_named_untyped [/home/travis/build/jruby/jruby/test/mri/ruby/test_sprintf.rb:459]:"
<enebo[m]> Seems like it would be but I thought I had all of these resolved
<puritylake[m]> For me there were no errors
<enebo[m]> yeah I see errors in both MRI and spec/ruby but I will look back at previous run.
<enebo[m]> ok this was me but I am pretty confused because I thought they were green locally
<enebo[m]> I even put a statement about last failing test
<enebo[m]> but the errors do not look like they would be your stuff since none of them are %c that I see
<enebo[m]> I think perhaps it is that I was running those individual commands like in my gist and not the full test suite runs maybe
<enebo[m]> I will try and straighten this out
<puritylake[m]> I run the tests the way they are in the gist and they all pass
<puritylake[m]> At least on the commit I'm on
<puritylake[m]> Just double checked the there
<puritylake[m]> s/the/them/
<enebo[m]> ./bin/jruby -S rake spec:ruby:fast and ./bin/jruby -S rake test:mri are the full runs
<enebo[m]> They take longer but test many more things
<enebo[m]> but for hacking on just a single thing like sprintf it is faster to use the other command lines
<enebo[m]> sprintf is used incidentally in things like String#succ and Marshall#dump so it is possible our changes might break other parts
<enebo[m]> but we have CI for catching this
<puritylake[m]> I'll give the full tests a quick run
<enebo[m]> I think you will see the same failures we see on CI
<enebo[m]> You may even see a couple of other issues pop up (like I have seen some errors involving IPV6 which seems to just be environmental issue with my laptop)
<puritylake[m]> I'll leave it then, my laptop isn't the fastest
<puritylake[m]> I use it as I have it running Linux
<puritylake[m]> Was like a snail with Windows
<enebo[m]> heh
<enebo[m]> yeah I will make this all green but your current PR is fine. You can work on next one which I think p/s
<enebo[m]> looks like only difference between the two is with 'p' we call inspect on the object so it can be they both can be shared
<enebo[m]> 1 if stmt is fine
<puritylake[m]> Very good, I'll get to it in a little bit
<enebo[m]> I will merge the PR you submitted after I get things green
<puritylake[m]> Brilliant
<enebo[m]> puritylake: ok I realized what happened. we run CI without the new sprintf enabled and I had removed tags/tests because the new code runs them now.
<enebo[m]> So I reversed what the env variable SPRINTF means in the commit I just pushed
<enebo[m]> SPRINTF=1 will run old sprintf on this branch
<enebo[m]> This makes more sense since we want to see failures in CI when running with the new code
<puritylake[m]> Awesome, I'll pull that commit now
<enebo[m]> It is possible there are still failing tests but I definitely untagged some specs which were passing with the new code so most of these should be from that
<enebo[m]> we will see how this run goes
<headius> Good morning!
<puritylake[m]> Morning or more like good afternoon here
<puritylake[m]> How are you today headius?
<puritylake[m]> First time I've had to merge from upstream, same command for adding origin so nothing too taxing
<enebo[m]> puritylake: you can git pull --rebase too
<enebo[m]> then it will not cause a merge commit it will just replay your commits on the new head
<puritylake[m]> Why thank you good sir
<enebo[m]> Sometimes you want to do a merge especially when you hit conflicts but rebase ends up not showing any merging to us so for like my last commit that probably is better to rebase
<enebo[m]> don't worry about it though if you did a merge. It is not a big deal
<puritylake[m]> I had added a merge but it seams rebase got rid of that commit
<puritylake[m]> s/seams/seems/
<puritylake[m]> Yup `git --oneline` just shows your commit messages
<headius> Rebase should collapse merges since it reapplies the commits at head
<headius> Oh enebo just said that
<headius> 👍
<puritylake[m]> enebo: `f.hasWidth` isn't being set correctly, using a workaround that tests if `f.width > 0`
<puritylake[m]> f being a FormatToken
<puritylake[m]> Other than that, the only test failing is the named parameters
<puritylake[m]> Is that part of the parser working?
<puritylake[m]> Ok I have confirmed it works, just need to checkout what is causing the fail
<puritylake[m]> I fixed one where width was made negative using `%*s`
subbu has joined #jruby
joast has quit [*.net *.split]
joast has joined #jruby
subbu has quit [Quit: Leaving]
subbu has joined #jruby
subbu[m] has left #jruby [#jruby]
subbu has quit [Quit: Leaving]