<headius[m]>
it turns out that there are a bunch of files in our ffi/platform that do not live in the gem, looks like generated constants probably from when we originally started pulling Rubinius FFI into JRuby
<headius[m]>
some of these are in use... at least syslog fails to load if these files are removed
<headius[m]>
I mentioned them to larskanis who has been doing much of the ffi gem maintenance work but I suspect these are not appropriate to include in the gem directly
<headius[m]>
we will probably want to move these somewhere else and potentially turn them into a gem of pre-generated useful constants similar to jnr-constants
<enebo[m]>
I will make no promises but I am looking at printf
<headius[m]>
syslog might be the only one using these files
<headius[m]>
yay printf
<headius[m]>
I believe in you
<enebo[m]>
looks like there are like 40 or so spec failings in syslog as well :)
<headius[m]>
I have not looked at this library in years
<headius[m]>
it still has goofball comments at the top from rbx days
<headius[m]>
latest FFI gem PR build seems like it will go green so I will merge after that and then see about moving these other rando files to better places or eliminating them entirely
subbu is now known as subbu|lunch
<headius[m]>
we will eventually need to get an FFI version into the syslog gem fwiw
<enebo[m]>
I can see kares ripping out 'e' to its own method instead of all this combined magic but even then there is an epic amount of conditionals
<enebo[m]>
err %f not %e
<headius[m]>
yes it is a lot of fun
<enebo[m]>
I guess this all came from Bill D.
<headius[m]>
oh really?
<headius[m]>
I saw a lot of lines of yours but did not trace this back to its origin
<headius[m]>
that would explain the overcomplicated mapping logic
<enebo[m]>
I committed his impl it looks like. This is SVN days too
<headius[m]>
ah great
<headius[m]>
"great"
<enebo[m]>
The thing about methods like this is they are so long it is easy to even forget what you are doing
<enebo[m]>
not to mention labels but I am a bit frightened this was ported from another C impl
<headius[m]>
yeah that seems likely
<headius[m]>
if ported from CRub
<enebo[m]>
LOL I am surprised this even compiles native
<enebo[m]>
much less fits in 32k
<headius[m]>
CRuby this would have been 1.8 or earlier
<headius[m]>
heh yeah it is large
<headius[m]>
I am not opposed to installing a new impl :-)
<headius[m]>
ffi gemification is green
<headius[m]>
one more set of sources we won't have to version
<enebo[m]>
LOL I worked on this stuff in 2017 to implement %p? I so don't remember doing that
<headius[m]>
you are the expert now
<enebo[m]>
Really feels like the long term cost of ports ends up biting us when the logic of those ports is complicated
<enebo[m]>
In this case we do not even know the lineage
<headius[m]>
well the code in CRuby is almost impenetrable
<enebo[m]>
so we cannot even go back and look
<headius[m]>
so many gotos and macros
<enebo[m]>
but yeah MRI code for this is not how one would do it if they were writing Java to begin with
<headius[m]>
right
<headius[m]>
I would say we should look for another printf impl but it would use Java strings and characters
<enebo[m]>
and MRI seems to favor having like 5-6 common things through the same code path with lots of conditionals
<headius[m]>
yeah exactly
<enebo[m]>
Actually the worst beyond arbitrary goto-like jumps is the multiple out values which forces it all to stay local to a loop
<headius[m]>
oh yeah that is fun also
<enebo[m]>
sign = ' '; width--
<enebo[m]>
HAHAHA ok first weird bit %a/A has 'E'/'e' as part of the number whereas all these other fields it marks exponent