<kares[m]> pushed jossl pre yday - will pbly push 0.11.0 later today
<kares[m]> (includes the alt-chain certificate verification - basically a complete rewrite of that part there wasn't another way)
<klobuczek[m]> I'm including a java interface and implementing all the methods. So far so good, everything has been working fine. Now they added a default method to the interface overloading one of the existing interface methods. Now when java calls the method with the original signature it goes directly to the default interface method ignoring my ruby method and failing due to the not matching signature. Can anything be done about it?
<klobuczek[m]> I'm routinely intercepting method calls on java classes by prepending a ruby module to them with the methods I want to override, but prepending such a module to an interface with default implementation does not work.
sagax has joined #jruby
<enebo[m]> puritylake: I have a guard in SprintfParser.sprintf to only do some letters (see indexOf line around line 38)
<enebo[m]> I mostly do print debugging as a practice but this work tends to be helpful with an actual debugger for tracing since it is much more unclear what is happening
<puritylake[m]> enebo[m]: Would that include blocking System.out.println? Cause it is not actually printing. Maybe I’m building it incorrectly
<enebo[m]> if it is above that point it should print out
<enebo[m]> it will return back to old code at that point if it is not in the list
<puritylake[m]> Ok cool, thanks
<enebo[m]> mvn with no args should be fine
<puritylake[m]> I’m not at my machine currently but I’ll double check that when I’m back at it
<enebo[m]> puritylake: ok
<headius> yo
<headius> enebo: I will try to get the M1 work done today and tomorrow, so we might be able to do a 9.3.2 next week before starting to prep RubyConf stuff
<headius> I'm fixing the few little bugs filed against 9.3.1
<enebo[m]> I got a perf PR for kpeg landed to only get a report of an off by one issue
<enebo[m]> I fixed it but I don't know kpeg enough to write a test :)
<headius> hah
<headius> yeah me neither
<headius> funny how you can do perf PRs without actually knowing much about the library
<puritylake[m]> That worked btw enebo, I seem to have %c working
<headius> woot
<enebo[m]> puritylake: coolio
<headius> man I hate objectspace
<headius> I wish we could ditch our impl and finally find some way to use Java tooling
<headius> flip a switch and just use JDI to walk heap objects
<enebo[m]> puritylake: I will need to make some substnatial parser changes since I found a bunch of weird weird formatting rules. I will fix up anything which breaks whenever I get to it
<enebo[m]> The good news is it is really odd so you won't notice
<puritylake[m]> Ah good to know
<enebo[m]> mri26 -e 'printf("%5.0d", 0)'
<enebo[m]> look at that shit! :)
<enebo[m]> It just returns 5 spaces
<puritylake[m]> Well that looks painful lol I wonder why anyone would need that
<headius> mrnoname and I were playing with some printf formatting like that the other day
<enebo[m]> puritylake: cool. PR whenever you want.
<headius> simplest way to get awk to format an N wide block of spaces was something similar
<puritylake[m]> Just gotta ask first, should width matter for %c I added it but I dunno if it is valid
<enebo[m]> so you were looking at '%*5$.*1$2$d'?
<headius> we did "%5 s"
<enebo[m]> puritylake: I see logic for width
<headius> space-pad a string to 5 width
<enebo[m]> yeah so space padded to 5 width for a string
<enebo[m]> MY above example is width for 5 arg with precision from 1 and actual value from 2
<enebo[m]> width from...I have never ever used numbered formatting with printf other than %*d
<enebo[m]> puritylake: looks like you have that logic in there
<enebo[m]> worst part of the example I gave above if you can swap all those index specifiers in any order
<enebo[m]> .* can come before *
<puritylake[m]> Might need to update the .gitignore, few files and folders might be slipping past but unsure `test/.classpath` `test/.project` and `Gemfile.lock`
<puritylake[m]> OR should I clean before commiting?
<enebo[m]> just add exactly the files you modified but in geneal cleaning is fine
<enebo[m]> I am a bit messy so I always have something untracked
<enebo[m]> but I like to explicitly commit so I don't accidentally commit extra stuff
<puritylake[m]> Cool, not often had to work with a repo not of my own lol
<enebo[m]> After this I recommend looking at p and s since the floating point stuff will be the biggest challenge
<enebo[m]> puritylake: I have just accidentally committed too many files so I tend to always git status even after I explcitly commit files
<enebo[m]> not that making a mistake is a big deal we will just remove the changes...the jots of revision control :)
<enebo[m]> s/jots/joyd
<headius> kares: I see a PR for the 1.1.1 cert verification, I guess you want to look into this after the current jossl release?
<enebo[m]> LOL
<enebo[m]> afk for about 20 minutes
<headius> kares: ok no I guess this PR is the fix and not merged... let me know how I can help
<puritylake[m]> OH also regarding error handling for %c, and how should I handle the errors of a RubyString longer than 1 character, a negative number or a number out of range of unicode?
<headius> enebo: I pushed PRs for two new issues reported against 9.3.1
<headius> minor things so that's good
<enebo[m]> great
<puritylake[m]> I have some TODOs added in comments that just `return;` from format_c
<puritylake[m]> Ok an issue I'm having with tests is Unicode
<puritylake[m]> `Expected "\u0006" == "Ԇ"`
<puritylake[m]> Odd now I am getting fails even without `SPRINTF=1`
<puritylake[m]> That is for the specs
<puritylake[m]> enebo: Not sure how to go about fixing that
<puritylake[m]> The test seems wrong tbh, that unicode character code doesn't equal what it's expected
<puritylake[m]> Ya cause my implementation returns a unicode character correctly
<enebo[m]> puritylake: hmm
<enebo[m]> so one problem with the approach is that we try and parse with new parser and then fall back to old way
<enebo[m]> That can lead to errors during parsing
<enebo[m]> puritylake: Also perhaps the result is backwards...perhaps the test expects the second value and you are returning the first one
<enebo[m]> puritylake: you can open a PR with what you have and mark it draft or work in progress (I cannot remember the term github uses) and I can then look at it too
<puritylake[m]> There is a single fail in mri tests too
<enebo[m]> sounds close
<puritylake[m]> I think the problem is it uses `%-1c` in the test, which seems to be converted into a negative width which me following from your code wrt the negative width being turned positive and right pad being set to true adding a single space after the 'a'
<puritylake[m]> Unless there are different rules for %c
<puritylake[m]> I'll make a PR regardless
<enebo[m]> there is a flag_minus section which is for the right padding
<enebo[m]> That should be t.rightPad in your new code
<puritylake[m]> Well still throws the error so my intuition was wrong
<puritylake[m]> So I assume I can't push directly to the repo?
<enebo[m]> puritylake: did you fork jruby/jruby or just clone it?
<puritylake[m]> Just cloned
<enebo[m]> ok. then fork our project and then commit to your fork of our repo and then github will give you a nice url for opening a pull request
<enebo[m]> once you push a branch to your repo
<puritylake[m]> Cool
<enebo[m]> git workflow is a bit involved but having your own fork is useful for playing around too
<puritylake[m]> I'm glad ya don't mind putting up with a newbie to the process lol
<enebo[m]> puritylake: not at all. I enjoy helping people get rolling on OSS contribution
<enebo[m]> I think most people never make it past the first step of engaging so they think it is intimidating.
<enebo[m]> This is a shame. Not all OSS is fun but it is a nice way to learn a little, build up something for the CV, meet new people, feel like you accomplished something others will use.
<puritylake[m]> Ya, my CV is rather lacking experience wise, I just have my degree, been finding it hard still to find work around where I live as I don't drive yet
<enebo[m]> ah yeah well this won't hurt from the CV part but beyond just learning new stuff it is something to talk about at interviews too
<enebo[m]> I can say there are not many people who have worked on an implementation of printf
<headius> There are not many people who have contributed anything at all to OSS
<enebo[m]> yeah I definitely see it as an interesting value add for a job hunt since it is uncommon
<puritylake[m]> Might make up for the lack of experience
<puritylake[m]> I plan to contribute to others eventually but gotta take it one at a time with these things
<enebo[m]> It is experience. Just generally uncompensated
<enebo[m]> which is why it should also be enjoyable
<puritylake[m]> True and I'm enjoying seeing how JRuby runs under the hood, it'll certainly help me in my endeavours to make my own language
<enebo[m]> It won't hurt :)
<enebo[m]> I was thinking I might try and output all flags/state in the old parser while running tests and then run with new parser and make sure all state matches
<enebo[m]> which will be laborious but looking at some of the more weird format strings I can see aligning 100% will be helpful
<enebo[m]> At this point I am seeing other things like %05.0d where the first 0 is either zero pad or it is part of the 5? Confusing example
<enebo[m]> It is written currently as zero padded with a width of 5
<puritylake[m]> Made the pull request
<puritylake[m]> I also didn't realise how esoteric printf really is
<enebo[m]> yeah me either
<enebo[m]> No one uses most of the features of printf.
<puritylake[m]> I wouldn't be surprised if hidden under thousands of lines of code, are some joke specifiers
<headius> hah yeah I would at least bet there are some easter eggs in some printf impls
<enebo[m]> puritylake: I see some issues
<enebo[m]> So one thing to note is that a character in printf is potentially a multi-byte character for example a unicode character
<enebo[m]> byte[1] will only work for ASCII more or less
<enebo[m]> mimicking the codePoint/codeLength code exactly will be the right way to go
<puritylake[m]> Ok, cool, so `length()` will return 1 for these multibyte characters?
<enebo[m]> yeah it you look at RubyString.strLength you will see if it is 7bit ascii we just use the length (which will be 1 like you expected) but if it is a more elaborate encoding like UTF-8 it may be multiple bytes long
<puritylake[m]> Oh wait, if i do `bytes = rs.getBytes()` instance it'll just return all the bytes for a multibyte character, right?
<puritylake[m]> s/instance/instead/
<enebo[m]> So we are returning 1 character and 1 character can be multiple bytes
<enebo[m]> this is another wrinkle in how we represent things in JRuby
<enebo[m]> our bytes are stored in a ByteList but a ByteList may have many other bytes in it
<enebo[m]> It might just be a subset of the backing bytes it has within it
<enebo[m]> So if we read a bigger string 'this is a test' and we store that as a primitive array of byte[]s
<enebo[m]> We then hand that off to multiple bytelist instances which will save the reference with an offset and a length
<enebo[m]> then one bytelist might refer to 'this' with offset of 0 and a length of 4
<enebo[m]> 'a' will be whatever that offset is with a length of 1
<enebo[m]> so the codePoint and codeLength calls in the old code gets the actual character (codepoint) but then has to calculate how many bytes long that is
<enebo[m]> The solution to your PR is to do exactly what is in the old code but this is a useful thing to get wrong because it uncovers a lot of details about how strings work in a multiple encoding world
<puritylake[m]> Perfect I'll look into it
<enebo[m]> most programmers just get to get the result (a character) so this is a nice look under the hood
<puritylake[m]> Well seems that fixed the failing tests
<puritylake[m]> Anyway added a new commit if you want to check it out enebo