<headius>
byteit101: yeah not really... but that would be an option
<headius>
it would also be reasonable to set some config that all reified classes (or some configured subset) go into the same classloader as runtime dependencies, for apps known to behave and not spin new classes constantly
<headius>
woot, digest gem changes have merged
<headius>
enebo: I am reviewing the last couple stdlib file updates but then this could merge
<headius>
when I run sync_ruby there are four files with diffs... I just need to figure out which direction the diffs should go
<headius>
we are down to just a handful of things copied out of CRuby lib though
<enebo[m]>
cool
<headius>
I submitted a PR for open3 yesterday (mostly adding our non-native Windows logic) which will eliminate one more
<headius>
spec:ruby:fast does not complete, but I will look into that
<headius>
still can't figure out what is up with that English gem
<headius>
it does not want to fetch properly through maven and there's very little help in the debug output
<headius>
e
<headius>
enebo: need your opinion on something
<headius>
the ProcessBuilder-based open3 can't do everything, of course, like if you want to redirect stderr to an existing IO, there's no way to do that
<headius>
should it silently fail (current behavior, redirect does not happen), warn, or hard error?
<headius>
the silently proceeding and ignoring the unsupported options means some of these specs hang
<headius>
(I am just trying to get them as green as possible with the PB version)
<enebo[m]>
well if you ask for something and it cannot do it would you prefer it to do something else?
<headius>
on the one hand silently ignoring the options will lead to bugs but allow the rest of the system to keep going
<headius>
where a hard error would break the whole workflow because of one possible bug
<headius>
but on the other hand if you are explicitly doing a redirect like this you probably need it
<enebo[m]>
yeah so perhaps this is where we just need to engine tag those tests?
<headius>
they fail either way but it is either a hang or an error
<enebo[m]>
If I asked for stderr to end up in an existing IO and it didn't I think I would have to do something else to work around it. Just having it do something helps move through the test suite (maybe) but I feel like we should unsupported operation exception
<headius>
I probably won't put skips in the open3 gem's repo but we can exclude in ours on Windows
<headius>
they do test this on Windows so if we want to add JRuby to that we would need another option
<enebo[m]>
There are two separate things though right? How we handle a feature we cannot support and how we interact with a gem which is testing that behavior
<headius>
yeah we are green in the open3 CI on *nix so that is not a problem right now
<headius>
this is mostly to get the best possible open3 on Windows until we have better native process support
<headius>
I guess I am leaning toward error as well
<enebo[m]>
so yeah I agree error on windows until we can do it
<headius>
so it would detect the piped redirects here and nope out
<enebo[m]>
for testing until we are testing this on windows with JRuby it perhaps is just deferrable
<headius>
I think so
<headius>
it largely works and most folks don't do these redirects since you can just capture the streams directly
<headius>
mostly affects the popen2/capture2 forms that only handle in and out... you have to do something with err so they redirect
<headius>
wow, this actually only fails a few things
<headius>
just two tests with piped redirects and another that expects to get a real pid back from the child process