<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
<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