<headius>
like I mentioned this is an open question, I just know about these libraries from previous exploration and never decided on the best one to use
<byteit101[m]>
I'll investigate those this week. woud like to get this released as a basic support rather soon
<headius>
yeah it will be a nice announcement
<headius>
enebo: I am pushing what I have, which includes another four or five refinements fixes
<headius>
some of those are older but it's things like honoring refinements when calling Object#method, #send, #public_send, and a few other small things
<headius>
I tried to fix #to_proc to use refinements but it goes through a LONG pipeline of functions for that checkCallMethod stuff in TypeConverter
<headius>
just got a bit too invasive for my taste right now and refining objects to have to_proc seems like a really unusual feature
<enebo[m]>
ok we just advance the state of things which is good
<enebo[m]>
So I decided I was annoyed at seeing 2F on every spec:ruby:fast run locally
<enebo[m]>
First problem was we error out in rake-ant because Ant exits and throws a non-persistent type. Easy fix which does not fix the errors but at least removes seeing an error every time I run this
<enebo[m]>
The second problem is two Etc.sysconf calls which return -1 as an error but their errno is 0
<headius>
ah ver nice
<headius>
ver naayce
<enebo[m]>
I am wondering if errno of 0 should just be a nil return since we obviously are not returning an errno
<enebo[m]>
which makes me wonder what is up with that
<headius>
hmm weird
<headius>
if there's actually an error it should be captured
<enebo[m]>
public long sysconf(Sysconf name) {
<enebo[m]>
}
<enebo[m]>
return libc().sysconf(name);
<enebo[m]>
hmmm :)
<headius>
I don't see anything wrong with the impl
<headius>
it just calls right down into sysconf
<headius>
and then checks errno immediately after
<enebo[m]>
I mean it literally is using the plumbing below to do a simple int return an int call
<enebo[m]>
but I guess I don't know how errno is set
<enebo[m]>
oh also a literal call
<enebo[m]>
haha
<enebo[m]>
I wonder if the value is -1
<enebo[m]>
SYMLOOP_MAX - _SC_SYMLOOP_MAX
<enebo[m]>
resolution returns ELOOP. Must not be less than _POSIX_SYM‐
<enebo[m]>
The maximum number of symbolic links seen in a pathname before
<enebo[m]>
LOOP_MAX (8).
<headius>
errno should be set by sysconf
<headius>
I think it's possible for us to bind methods without capturing the error number but pretty sure this one isn't set up that way
<enebo[m]>
yeah so I wonder if errno is 0 (and not threads thing) if -1 is really a valid return
<enebo[m]>
If it is defined
<enebo[m]>
to a value other than -1 or 0, then the option is supported
<enebo[m]>
So -1 means unsupported so? I guess I can write a small C program but then this would mean FC is not posix compliant?
<enebo[m]>
./a.out
<enebo[m]>
-1
<enebo[m]>
MRI returns nil
<enebo[m]>
HAHAH LOL: he return value is an integer or nil. nil means indefinite limit. (sysconf() returns -1 but errno is not set.)
<enebo[m]>
Exactly this -1 but errno of 0
<enebo[m]>
so that is a bug we should return nil here. ok fun times
<headius>
Ok
<enebo[m]>
It is amusing I have been staring at that for years
<headius>
Ha yeah
<headius>
Posix you so crazy
<enebo[m]>
POSIX.1 but we don't support that
<enebo[m]>
which it obviously gives you an option to return unsupported
<enebo[m]>
So does POSIX.1 mean it will respond to and have defined a constant but it need not do anything
<headius>
This is one of our extensions that I would love to replace with FFI Ruby code
<headius>
Or else turn this into a JNR sub project
<enebo[m]>
I may be onto a minimal linux distro idea
<headius>
Minimal like a ruby based on the ISO spec
<enebo[m]>
yeah this is not loaded by default and probably not used too much but with that said we also already wrote it
<enebo[m]>
and ISO spec with everything unsupported
<headius>
The fact that we already wrote it makes me lean toward the JNR option, so it's an external library and other people might use it and contribute to it
<enebo[m]>
yeah but using more FFI means potentially supporting jnr-posix and everything under it less
<headius>
Actually what am I saying, all of these native calls are already in jnr-posix
<enebo[m]>
I think we generally are the only people hacking it
<enebo[m]>
yeah
<headius>
So maybe what I really want is to just remove the Java extension and write it in Ruby to call those bindings
<enebo[m]>
that was also my original point
<headius>
Now I don't see any value so ignore the last 5 minutes
<enebo[m]>
Panama
<enebo[m]>
JRuby X
<headius>
The likely path forward for Panama may be that we start doing it parallel set of projects that are not JNR but panama-based and support the same but cleaned up and updated interfaces
<enebo[m]>
yeah I mean that is a way to do it
<enebo[m]>
I am not so sure I like jnr-posix API any more
<headius>
The Panama Way is to generate all the binding code so about half of what we have in jnr would just disappear
<enebo[m]>
but dropping in something would be the simplest way
<enebo[m]>
easy to config between the two for transition as well
<headius>
If we can make jnr-posix dynamically choose its back end that would obviously be the best migration path but it is pretty intimately tied to the JNR bindings
<enebo[m]>
I don't want to touch that
<enebo[m]>
It is a great idea on paper though
<enebo[m]>
since all we do is config a different backend with a fall back
<headius>
The Ruby FFI Will definitely want to be rehomed on top of Panama
<headius>
Yeah in theory it is just ripping out the existing Java FFI back end but that's a lot of ripping
<enebo[m]>
This is where your original statement is worth considering (e.g. taking some posix dependent stuff and just use FFI backed by panama)
<headius>
Yeah
<enebo[m]>
we will need to do some amount of work anyways and some libraries will be pretty easy to swap over
<headius>
I think it should be possible to dynamically generate the binding at runtime as well without emitting Java code
<enebo[m]>
but not all of them will be which sort of negates the benefits since we will still be making a backend for jnr-posix
<headius>
You have to tell the generator explicitly that you want Java code or otherwise it just spits out class files
<enebo[m]>
yum
<enebo[m]>
Nice they provide both options
<headius>
yeah there's some exciting stuff coming up. I need to sign off for Halloween stuff but I'll be back at it tomorrow and I'll merge this PR once the tests have run