subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
<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
<puritylake[m]> I'll do a quick check on ruby 2.6 just to be sure
<enebo[m]> interesting and ruby 3 does this differently...interesting to see a rounding change
<enebo[m]>"%#{f}", 1.123456789).should == "1.123457#{exp}+00"
<enebo[m]> it "cuts excessive digits and keeps only 6 ones" do
<enebo[m]> end
<enebo[m]> oh that is for 'eE' but it is the same basic one as 'f'
<enebo[m]> it "cuts excessive digits and keeps only 6 ones" do
<enebo[m]> end
<enebo[m]>"%f", 1.123456789).should == "1.123457"
<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
subbu has joined #jruby
<headius> ok release notes time
<headius> I didn't include all issues in notes but the super fixes being regressions seemed worth a call-out
<enebo[m]> We should mention simplecov
<enebo[m]> It is not specifically for that but anyone use simplecov and mailer? would explode
<headius> which issue is that
<enebo[m]> I guess one generated file for a gem had >32k lines
<enebo[m]> I raised parsing to use full int (since we store an int for line already in AST)
<headius> ok I'll add something for it
<enebo[m]> cool. I have all bits uploaded and site edited sans release notes
<enebo[m]> once site it up let's divide up rest like last couple of releases
<enebo[m]> Maven is propagated too and I think I hate the lack of feedback that oss sonatype web interface gives
<enebo[m]> I did everything right but I sit there for like 10 minutes sweating it anyways paranoidly thinking I hit drop instead of release
<enebo[m]> puritylake: I think you said you are using Emacs? I think you are in that mode where you are mixing tabs and spaces
<headius> enebo: ok added
<headius> you can wordsmith if you want
<enebo[m]> just going to proof and make sure site displays before I push
<enebo[m]> then when we see site is live we can do notifications
<headius> I'm using link references in my markdown so let me know if that works oik
<headius> ok
<enebo[m]> headius: we could link to stadium's page or not?
<headius> yeah good idea,
<puritylake[m]> enebo: oops, sorry I’ll fix that, tabs or spaces?
<headius> added
<enebo[m]> we only use spaces...I think I have this in my .emacs file...I can find it
<puritylake[m]> Please do, thanks
<enebo[m]> headius: That is not rendering for me
<headius> where?
<enebo[m]> on our rake server but get this....
<enebo[m]> I do raw on that and what I get is most definitely not what you put in
<headius> hmm
<enebo[m]> [MacStadium's OSS program][macstadium]
<enebo[m]> That is definitely weird
<headius> that's how you do a link reference with text
<headius> it works right in the gist, hmm
<headius> the other links render ok?
<enebo[m]> oh wait this is my mistake
<enebo[m]> I did not add the footnote
<headius> oh ok
<enebo[m]> I have not actually use this form. I have only uses the []() form where it is inlined
<headius> yeah this is a bit easier to handle when putting together the issue lists
<enebo[m]> funny I typed in "[]()"
<enebo[m]> hahah neat
<enebo[m]> ok so matrix must get that markdown
<enebo[m]> [#6989 - case when with an empty array](
<enebo[m]> fun
<headius> [foo](bar)
<enebo[m]> so that is pretty cool
<headius> mine isn't a real link
<headius> but yeah I guess so
<enebo[m]> not sure I just rattle that off with my fingies but it is still cool you can do it
<headius> hello
<headius> ====
<headius> yeah md throughout
<enebo[m]> Does this mean we can paste tables in here :)
<headius> kickban
* headius slaps enebo around a bit with a large trout
* enebo[m] reacts
<enebo[m]> haha
<enebo[m]> slash me is a thing which makes sense
<enebo[m]> so many ways
<headius> yeah
<headius> tweet is locked and loaded
<enebo[m]> HAHA I merged someones PR the other week taking exception to 'C Ruby' over 'CRuby'
<headius> crooby
<enebo[m]> I pushed site so it should be soon
<enebo[m]> site is up. I will make GH release and send out emails
<headius> ugh none of my recent rvm PRs have merged because I didn't include a changelog entry
<enebo[m]> puritylake: I believe it is this (setq-default indent-tabs-mode nil)
<headius> I'll get these other PRs cleaned up today along the way to 9.3.3 PRs
<enebo[m]> Although I do not edit Java with emacs so it may not be for Java mode (although it probably will)
<enebo[m]> ok
enebo has joined #jruby
ChanServ changed the topic of #jruby to: Get! | | | | Paste at
enebo has left #jruby [#jruby]
<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]> cool
<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
<puritylake[m]> Of course, completely understand
<headius> like and subscribe
<headius> socials are done
<headius> I think that's all my tasks
<headius> good work everybody, take a long lunch
<headius> onward to 9.4
<enebo[m]> hahah
<puritylake[m]> Congrats, here is to many more versions
<puritylake[m]> enebo: having trouble with running the mri tests on windows saying that wait is unsupported
<enebo[m]> puritylake: ok I will take a look.
<puritylake[m]> I appreciate it, I'll run it in WSL until then
<enebo[m]> puritylake: yeah WSL should be fine
<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]> 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 thru homebrew rbenv failed gonna try dropping in a zip
<rebelwarrior[m]> zip works! but predictably sassc gem fails to install.
<rebelwarrior[m]> tested rails 5.2.6 btw