<headius[m]>
json failures on 9.2 must just be old tests
<headius[m]>
well this is enough to repro the i18n issue anyway
<headius[m]>
thanks ahorek
<headius[m]>
I have updated the json tests to 2.5.1 and (bonus!) modified the mri:stdlib test run to actually run all of them... was only running a subset before
<headius[m]>
enebo: I think we should just switch the snapshot deploy to gha
<headius[m]>
I do not know why that deploy on 9.2 is still failing only on travis
<headius[m]>
same issue seems to be happening on master after latest merge
<headius[m]>
well after a short detour I can say there are no USB-C power delivery passthrough hubs supporting more than 2 USB-C ports, and that makes me very sad in 2021
<headius[m]>
guess I will get back to work
<headius[m]>
Freaky: are your json issues from freshbsd.org tooling?
<headius[m]>
I just saw your tweet about fast_find
<headius[m]>
I wonder if it would be possible to ship this as a replacement for the standard find
<headius[m]>
funny thing someone tweeted about wanting a better FS walking API for Ruby just the other day
<Freaky>
headius[m]: yeah, only reproduced it in a FreshBSD environment so far
<headius[m]>
you manage to narrow it down any more?
<Freaky>
I wouldn't recommend it, the benefit is limited unless you make explicit changes to take the File::Stat it passes
<Freaky>
there should be an unknown branch where the filesystem hasn't provided the type
<headius[m]>
yeah too bad
<headius[m]>
Freaky: I saw on your twitter profile that you are a rustacean... you might be interested in the new JRuby native launcher, which enebo is rewriting in Rust
<Freaky>
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "\xC3("', library/std/src/env.rs:775:51
<headius[m]>
ooo nice
<Freaky>
that's a file called "\xc3\x28"
<headius[m]>
definitely something we need to consider
<Freaky>
yeah, unreadable from JRuby irb too
<headius[m]>
the non-rust launcher output above, is that using the bash script or our C++ native launcher?
<Freaky>
native
<Freaky>
jruby.bash does the same thing
<headius[m]>
yeah that may be a limitation of passing through the Java command line
<headius[m]>
the <?> there tells me it is getting borked before we have a chance to do anything with it
<headius[m]>
but it doesn't panic!
<headius[m]>
we have no direct access to the command line from JVM so we can only receive the arguments via Java String
<headius[m]>
same issue as ENV with weird encodings
<enebo[m]>
Howdy
<headius[m]>
launcher could do some fancy magic to preserve the original bytes perhaps but we'd have to know how to interpret them on the other side
<headius[m]>
e.g. launcher could decode everything as ISO-8859-1 and then from JRuby we pretend they were just byte[] all along
<headius[m]>
a trick we use elsewhere
<enebo[m]>
Yeah I have been thinking it will need to change to OsString but the last time I chatted about this I think we convinced ourselves it would work out as Java wants a valid charset
<enebo[m]>
I can see that will cause some issue in needing to get things able to use PathBuf and stuff
<enebo[m]>
That ripper issue above may be trivial or quite a bit of work...who knows
<headius[m]>
ahorek: oh this is a good one
<headius[m]>
it is a combination of an original real method, a refined method, and our Synchronized module that wraps methods with synchronization
<headius[m]>
we see that the sync wrapper is refined, but then it is not an instance of RefinedWrapper so we don't know how to get the original and it fails
<headius[m]>
this is tricky for sure
<enebo[m]>
headius: I solved the windows orphan issue finally
<headius[m]>
aha what was it?
<enebo[m]>
well so your mention of winmain/main got me to change rust to use "windows" as a config. That ended up sort of working in that it eliminated any orphans BUT it caused every jruby invocation to in its own console window
<enebo[m]>
So it did make me realize invoking as console is the right hting to do
<enebo[m]>
which is what rust did by defaut
<enebo[m]>
On the other hand it made me realize something else was going on somewhere else
<enebo[m]>
That led me to notice that through a very indirect path it will detect whether you are already running within a console and if not then run java with javaw
<enebo[m]>
I added in similar logic and everything works the same now
<enebo[m]>
So we can probably fix our remaining issues with getting console windows with this knowledge
<enebo[m]>
jruby runner will run with console. jruby -S rails from within runner still runs console; the jruby exec within rails is runnning as windows so that process ends up creating a window
<enebo[m]>
Or at least I believe that is exec causing the second Rails process
<enebo[m]>
If so then I believe we are just doing it wrong there
<enebo[m]>
As I mentioned last week I can actually still make JRuby orphan in windows with jruby -e 'jruby -e 'jruby -e gets''' (ignore this is not quite valid ruby).
<enebo[m]>
I believe that orphaning is probably the same issue
<enebo[m]>
In that case I think I was using system but I will check on windows box later
<Freaky>
enebo[m]: windows_subsystem = "windows"?
<enebo[m]>
Freaky: yeah that was what I did where I got lots o windows
<Freaky>
that's what I use to get at a console from there
<Freaky>
attaches to the current console if launched from one, can open its own if needed
<enebo[m]>
Freaky: I believe in our case we are ok as it should always default to parent console
<enebo[m]>
Freaky: the problem we hit was that JRuby itself is calling JRuby without having a console
<enebo[m]>
in some code path(s)
<enebo[m]>
So I think CreateProcess happens in one or more paths with windows instead of console
<enebo[m]>
one code path we use internal Java APIs but in another via jnr-posix we actually directly call CreateProcess
<enebo[m]>
I guess tryng to ask the parent for their console does not seem like it could hurt though. I am just wondering if it will make a difference
<enebo[m]>
I guess I can see one difference. If you are in windows subsystem and it makes a console then anything create will also just stay in that window as well
<enebo[m]>
I do not actually want any extra windows from jruby.exe itself though
ur5us has quit [Ping timeout: 260 seconds]
<enebo[m]>
So headius I think we can get rid of the console windows popping up with an audit of which one ends up doing it
<enebo[m]>
That has nothing to do with the launcher though
<headius[m]>
that would be nice
<headius[m]>
hmm this is tricky
<headius[m]>
so our special Synchronized module basically installs logic into RubyModule that wraps everything you look up with a synchronized DynamicMethod wrapper
<headius[m]>
however that hides what the original method type was and interferes with other logic that wraps method entries, like refinements
<headius[m]>
not to mention the synchronized entries may get reinserted back into the method table where they don't belong (they should only be wrapped for caching)
<headius[m]>
hmmm
<headius[m]>
I might have a way
<headius[m]>
instead of wrapping with a DynamicMethod, we put the sync logic in the CacheEntry... and if you want to get a method from it you have to ask for original method or decorate method depending on what you are doing (metaprogramming vs invocation)
<headius[m]>
too many method table hacks stacking up