<puritylake[m]>
Ok things are improving, only failing 3 tests atm
<puritylake[m]>
One of which I am unsure how to solve
<puritylake[m]>
Eventually figured out a way
subbu has quit [Quit: Leaving]
<puritylake[m]>
Also noticed an inconsistency in the spec for sprintf
<puritylake[m]>
I'm majorly tired now so I'll look into other tests tomorrow
edipofederle[m] has quit [Quit: You have been kicked for being idle]
drbobbeaty has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
_whitelogger has joined #jruby
<mattpatt[m]>
On the off-chance anyone's here and doesn't mind a somewhat OT question, I'm having problems with a Java project. The original dev builds with Eclipse, and we have to supply to code to someone who builds it with Maven. This hasn't been a problem, except now it is because not all the source .java files use the same character encoding. There's a per-file override in the Eclipse settings, but I can't find anything equivalent in Maven. Am I
<mattpatt[m]>
missing something, or do I need to get the original dev to be consistent.
<mattpatt[m]>
(I have been googling all morning and am pretty convinced that, aside from being a bad idea, it doesn't work in Maven.)
<puritylake[m]>
enebo: I can point out what tests I think are wrong later as Ruby 3 prints what I print and buy JRuby expects something different
<enebo[m]>
puritylake: Sure. It is possible we were doing some things wrong. I am not sure which tests you are running but we do have tags/excludes (ruby/spec, mri test suite).
<puritylake[m]>
enebo: I'm running spec you specified in a gist
<enebo[m]>
puritylake: ah yeah the first spec run command-line is not using any tags so if it is in there then it is likely just something we have always been doing wrong
<enebo[m]>
If it is the MRI one that is using the excludes and we should pass all of that
<enebo[m]>
If the new version doesn't but does match Ruby 3.1 then that is really cool
<puritylake[m]>
Yup everything else passes, just two specs failing
<puritylake[m]>
Will I edit the spec to match ruby's output?
<enebo[m]>
nope. This is likely because we are running as Ruby 2.6 and if you look in the spec files you will see it has version checks
<enebo[m]>
So if you ran with Ruby 3 you would probably see it pass because it is running a different test
<enebo[m]>
(which of course I don't know to be true but it would be strange for spec to not work properly for printf if behavior is wrong)
<enebo[m]>
We could change our version on that branch to advertise 3.1 even though we are implementing on 2.6 (we branched from JRuby 9.3 codebase)
<enebo[m]>
puritylake: If you can gist I will see what is up
<enebo[m]>
I actually did not think printf output would change between versions unless error reporting change
<enebo[m]>
I see no guard for pre-3 so I am a bit confused
<enebo[m]>
mri31 -e 'printf("%f", 1.123456789)'
<enebo[m]>
1.123457
<puritylake[m]>
O_o that's ruby 3? I need to double check my calls
<enebo[m]>
Looks like it truncates but performs a round
<enebo[m]>
Our code has a weirdness in that we call Java's format library then reprocess the value again
<enebo[m]>
That is a stretch goal is to just directly implement the whole float formatting code but not an immediate one
<enebo[m]>
So I am not sure whether Java NumberFormat does this rounding for us or whether we do it in the second pass
<puritylake[m]>
Kinda rolled my own thing
<headius>
mattpatt: I would say you definitely need to get the developer to fix their file encoding
<enebo[m]>
headius: mattpatt If this is checked out via git maybe there is a posthook like on windows which does some basic translation. I don't know if that exists but on windows you can do that for CRLF
<puritylake[m]>
enebo: if ya look at my mess out a code, you'll see how much pain I caused myself lol
<enebo[m]>
puritylake: I look forward to it :)
<enebo[m]>
puritylake: although if you did start rolling your own you could consider implementing this without using numberformat and doing the entire format
<puritylake[m]>
200+ lines just fo %f lol
<enebo[m]>
puritylake: The only challenge is to not break any copyrights (e.g. do not just whole cloth steal another impl)
<enebo[m]>
oh ok does it use numberformat?
<puritylake[m]>
Nope, all my own code
<enebo[m]>
I am not even sure 200 is a lot for this
<enebo[m]>
That is super. If you understand what you wrote and it works then it will be fun to see e/g/a get added
<puritylake[m]>
Ya, it's gonna be fun to write
<puritylake[m]>
Not many comments on the %f so before I go to and others I'll fix the spec fails and add comments where things are unclear
<puritylake[m]>
s/and/any/
<enebo[m]>
yeah it makes sense to totally iron out %f
<enebo[m]>
when you feel you have the tests from those command-lines running there are more tests which hit this code
<puritylake[m]>
I'll report back when they are passing so
<enebo[m]>
test/mri/ruby/test_sprintf_comb.rb is a big one
<enebo[m]>
It has tons of more esoteric tests in it
<enebo[m]>
If you run that from our old to new code you will see most of the new ones are fixed except for us having more "perfect" values
<enebo[m]>
MRI seems to introduce precision oddities but I think this is because our use of things like BigInteger make us come up with the 'perfect' answer and theirs seems to partially get hung up on whatever precision they are using
<enebo[m]>
(and to be honest I am not sure if we should fix those or not so I have been ignoring them)
<puritylake[m]>
Ya I’m unsure how mri handles floats or bignums although working on mri in the future might be a thing I’m interested in
<headius>
rvm is like ten times more work to update than the others
<headius>
changelog entry needs to be included, but for this it needs to include the PR, so I have to push the PR, get the URL, edit changelog, and push again
<enebo[m]>
puritylake: There is a significant problem with %f impl you will need to change
<enebo[m]>
You call RubyFloat.toString which ends up calling .to_s which ends up calling our sprintf impl using %e and %g
<enebo[m]>
I think making a String numeric value to reprocess this again to make another String is how the old way worked but it would be nice to just process the number apart and build up a String a single time vs have another library give us a source string to process.
<enebo[m]>
As I said earlier today this was what I considered a stretch goal but if you are going to change from original method you may as well look at doing the processing yourself (and it will also be way faster when you are done)
<enebo[m]>
It is a bigger ask though
<puritylake[m]>
Ok, I can see how that is a problem, I'll work on that asap
<puritylake[m]>
I'll ignore the specs for the time being
<enebo[m]>
A second smaller thing I noticed is I do not think we want integers to be auto converted into floats because it means constructing a new ruby object
<puritylake[m]>
Should I throw if that is the case?
<enebo[m]>
The original code handled the int as its own case
<enebo[m]>
It just never had anything past the period so that part of it was simpler
<headius>
installers and docker are in flight
<headius>
gonna finish up socials
<enebo[m]>
I admit I liked the simplicity of what you did but we don't want to have that overhead
<enebo[m]>
If you know lispy langs this is a couple of algos for converting floating point values to binary
<puritylake[m]>
Will I need to turn a float to binary?
<enebo[m]>
well you need to convert the float into a string so you need to accurately parse a float value
<enebo[m]>
Getting the proper values which align with how it may compute by other printfs is likely to just work using someone's academic paper on the subject
<enebo[m]>
with that said I have not read this yet. I just noticed a dtoa impl mentioned this paper
<puritylake[m]>
I'll definitely read it, might take some time to reimplement it if it helps
<enebo[m]>
puritylake: the thing is you have a double in Java and we need a string which represents it so we need to be able to break it down so we can output chars
<enebo[m]>
puritylake: in ye olden days no one wanted to take this on and Java did about 95% of what we needed so we sort of double parse
<enebo[m]>
but the second parse is taking a string to make another string
<enebo[m]>
Let's take out the middleman
<puritylake[m]>
Ya, that makes sense, the way I am doing it I might as well just use System.out.printf
<enebo[m]>
well the way you are doing it is very similar to how we are doing it currently just differently
<enebo[m]>
so in that sense it is no worse off and it seemingly works for at least as much as we had before
<enebo[m]>
but if we are going to change how we do it that much we may as well go the rest of the way
<enebo[m]>
new impls mean new risk so we may as well get as much out of that risk as possible
<puritylake[m]>
Indeed, I appreciate the link, I'll see what I can do
<mattpatt[m]>
<enebo[m]> "headius: mattpatt If this is..." <- The problem was chars valid in 1252 but not utf-8 and vice versa
<enebo[m]>
ouch...you can 1252 java?
<mattpatt[m]>
<headius> "mattpatt: I would say you..." <- That is what is happening. After so long with Ruby and the potential for explicit declaration of source file encoding i kind of assumed you could do that in Java too, and there’s some kind of eclipse specific config that stores the encoding as sidecar metadata, which was what was being used by the dev. But not in maven
<mattpatt[m]>
enebo: you can, and it kinda makes sense here because we’re parsing a thing that predates 1252 and makes heavy use of all the bits. Typesetting markup from the 70s. 👍
<lopex[m]>
numbers
<puritylake[m]>
enebo: that doc is short but a puzzle for certain
<rebelwarrior[m]>
FYI my attempt to install 9.3.3.0 thru homebrew rbenv failed gonna try dropping in a zip
<rebelwarrior[m]>
zip works! but predictably sassc gem fails to install.