lucerne has quit [Read error: Connection reset by peer]
greyrat has quit [Read error: Connection reset by peer]
_whitelogger has joined #jruby
<edipofederle[m]>
<enebo[m] "you had 'instance methods' in th"> lol, true. thx :D
<edipofederle[m]>
I will check these issues and see if I can help with some of them
greyrat has joined #jruby
lucerne has joined #jruby
lucerne has quit [Quit: Bye]
lucerne has joined #jruby
<headius>
enebo: that PR is green but I am sick and tired of ShellLauncher
<headius>
this all came up mostly because the native exec is more strict than the simulated one but it still used the same ShellLauncher logic... might be able to excise that and get it using the other native logic
lucf117 has joined #jruby
<enebo[m]>
headius: so should I look at making windows exec in jnr-posix build the full exe name and assume an exec*p behavior?
<headius>
it would be more useful if we did that
<enebo[m]>
I just finished case/when laziness so I am game if we think that is the right behavior
<headius>
we can do this search but having to do it only on Windows makes it more icky special case code
<headius>
and actually moving the path searching logic into jnr-posix might be useful as a utility across platforms
<headius>
I don
<enebo[m]>
At one level if the unix variants are not doing that we could say it is inconsistent but I think largely windows is a strange outlier in behavior already
<headius>
I don't know of a standard C API for PATH searches for executables but whynot
<enebo[m]>
execp will do path searches though
<enebo[m]>
So I think we could perhaps have jruby call jnr-posix execp() (and make that) and perhaps then we get path searching for free on linux because we just bind to it
<headius>
yeah but having the path search component as a callable util in jnr-posix would move more code out of JRuby and be useful to other jnr-posix users
<headius>
you will need to have that code anyway
<headius>
for Windows
<enebo[m]>
yeah
<enebo[m]>
and fwiw exec() is not a POSIX api
<enebo[m]>
The variant names are all the API right?
<enebo[m]>
so our shorthand name could add path searching as the impl
<headius>
yeah
<enebo[m]>
For a moment do you think anyone would notice we are calling execvpe instead of execve?
<enebo[m]>
not sure how for a moment got in that sentence :)
<headius>
so yeah this doesn't exist as a callable
<enebo[m]>
so full paths will not search but partials will...for JRuby this is fine for other jnr-posix users I am less sure
<enebo[m]>
but I think it may be fine
<enebo[m]>
since people basically are making / names already
<enebo[m]>
or exec would not work
<enebo[m]>
it would only break fopr people putting relative paths into exec and expecting an error
<enebo[m]>
my other hesitancy would be maybe not all unixy systems has execvpe()
<headius>
jnr-posix should expose the raw exec* versions but the literally "exec" version could be the friendly one that does path searching and has normal Java varargs or whatever
<enebo[m]>
yeah I agree with that premise already. I am more talking about whether anyone expecting our old friendly behavior vs new friendly behavior
<headius>
for Windows I would almost guarantee nobody is using it
<enebo[m]>
I think old friendly behavior will mean no one is passing in relative paths
<headius>
like 97.6% confidence
<enebo[m]>
hahah
<enebo[m]>
yeah
<enebo[m]>
adding the new behavior to windows is a no-brainer
<enebo[m]>
for all systems is more what I am wondering since it would be nice for this behavior to be consistent
<headius>
hmm yeah
<headius>
I am looking to see what we call on Linux
<enebo[m]>
but current behavior does not work on linux already with relative paths
<enebo[m]>
it must be execv or execvve
<enebo[m]>
execve
<enebo[m]>
those are the only two we bind to in LibC
<headius>
new intellij seems much laggier
<enebo[m]>
I have been finding index searches to be instanteous
<enebo[m]>
or do you mean UI?
<headius>
UI mostly
<headius>
like I bring up a type search and start typing but it takes too long and whatever I typed goes into the editor
<headius>
it was not this bad before
<enebo[m]>
ah yeah. I have not noticed but perhaps it is the year of the linux desktop
<enebo[m]>
I definitely hit that issue while it is still indexing
<headius>
once I have replaced my mac mini with a new M1 I will probably look into the linux machine
<headius>
since I can still test x86 there
<enebo[m]>
ok so I think we change exec() to do path search everywhere. I think main problem could be that we do not have execvpe() on 100% of systems (but maybe it is literally on all systems)
<headius>
jnr-posix has exec, execv, and execve exposed
<enebo[m]>
yeah and exec is not a method so we use one of those two in am impl somewhere
<headius>
hah
<headius>
exec is only on Windows?
<headius>
I think it is unimpl on Linux
<enebo[m]>
no kidding? I cannot find a generic impl anywhere which would explain it being windows only
<headius>
I mean the one you added to jnr-posix
<enebo[m]>
then I guess that makes the behavior change much simpler
<headius>
it raises in BaseNativePosix and is only impl in WindowsPOSIX
<enebo[m]>
yeah I saw that raise but assumed something higher overrode that...pretty funny
<headius>
yeah so no reason not to make it path search, and we can fill it out on other platforms with vpe or whatever
<enebo[m]>
yeah so only question is how pervasive vpe is
<headius>
mac and linux for sure
<enebo[m]>
If it is pervasive then this will make JRuby simpler
<headius>
and bsd
<headius>
next in line would be solaris and it drops off fast from there
<enebo[m]>
worse-case we rev jnr-posix when AS400 comes back and says it doesn't work :)
<headius>
even then we would have the path logic for Windows and v and e can be simulated easily
<enebo[m]>
but realistically any platform missing it is a 3 line method for a new release
<headius>
if that isn't enough then I guess you don'
<headius>
don't get exec
<enebo[m]>
yeah but if we call exec() from jruby then all platforms need to be considered
<enebo[m]>
still it is easy to fix if it happens
<enebo[m]>
and we could even catch unimplemented at jruby level and fall back if we really thought this was likely
<headius>
I will come up with a test for this PR and then merge it into 9.2
<headius>
the changes are small but kinda hacky and I hate them
<headius>
problem is so many of these weird paths in ShellLauncher are shared so making one path start to look up paths broke another path
<headius>
it just needs to go
<headius>
9.4
<enebo[m]>
yeah seems like a good idea
<headius>
now that you have that stuff for Windows exec I will try to finish native process stuff on Windows
<headius>
after that we have very little native stuff we can't do there which will finally close the gap
<headius>
ok I might only be able to add this test on master because kares fixed up the jruby suite to pass on Windows there
<headius>
it does not even boot on 9.2
<headius>
I will confirm the behavior in this test works and then merge and do a separate push for a master test
<headius>
6732 can't be fixed without updating the files but they keep diverging and we should be sourcing them from the gem anyway
<headius>
this will align FFI on 9.2 with master
<headius>
bbiab
<headius>
enebo: hit a snag with that PR because the ffi.rb from the gem only loads on 9.3+
<headius>
so we need to decide whether we want to do this backport in 9.2.20 or just manually patch the local copy of FFI to fix #6732. If we want the full backport we will need to get an ffi gem released that will load properly