<headius[m]>
something in Dir.glob works ok with the classloader/jar URI as a single string but does not work when it is passed as a separate base path
shellac has quit [Ping timeout: 240 seconds]
<enebo[m]>
headius: yeah hopefully it is a small change
<headius[m]>
if we fix that case in glob it may be done
<enebo[m]>
the fixed deps is not a big thing either
<headius[m]>
yeah if we're going to have people dependent on these deps not conflicting we need a CI job to keep us honest
<headius[m]>
there's too many connections
<headius[m]>
I'm going to spend a little bit on that RG issue but then I need to get back to AOT
<enebo[m]>
I made the milestone and assigned
<headius[m]>
you milestone the deps issue too?
<enebo[m]>
I just cloned the repo but I have some planned stuff this afternoon
<enebo[m]>
yeah it is marked for 9.2.11.0
<headius[m]>
ok
<headius[m]>
I might have found the problem already
<headius[m]>
if this fix is easy I'm going to feel bad
<headius[m]>
well I have a fix
<headius[m]>
I dunno if it is good or easy but it works
<headius[m]>
some day I'll learn the lesson: no matter what feature you remove or break, there's someone out there using it
<enebo[m]>
yeah I need to learn it as well
<headius[m]>
and the corollary: don't add features
<enebo[m]>
I know that one
<enebo[m]>
the disconnect of Java file APIs with Ruby string encoding always makes examining changes like this troublesome
<headius[m]>
well we have so damn many methods for resolving paths it's not clear what to use
<headius[m]>
my PR adds a string-only RubyFile.expandPath that handles all the same cases as File.expand_path
<headius[m]>
but we still have a half dozen other paths
<headius[m]>
I used this because the working version of the glob call used File.expand_path to combine the base and glob, so it made sense to use it from within Dir.glob
<enebo[m]>
One comment not related to the actual fix is we should make an expandPath which does not require passing in a boxed Encoding and one which just returns the RubyString
<headius[m]>
there was one that returned RubyString before but it was no longer used after I made this new one
<headius[m]>
expandPathInternal is the other RubyString version
<headius[m]>
that just backends on this new public expandPath now
<enebo[m]>
passing in the box to only use it once for making a RubyString looks strange to me
<headius[m]>
I basically split it in two but the enc carrier was necessary because it chooses either the base string's enc or the system enc
<enebo[m]>
I guess even having a method which hides that detail would make it look a tiny bit nicer
<headius[m]>
if you have RubyString in hand, calling the expandPathInternal is equivalent to calling expandPath with j.l.String
<headius[m]>
hmm yeah
<headius[m]>
I know a way
<headius[m]>
null enc[] path
<headius[m]>
the Dir.glob use doesn't care about the enc (maybe it should but it doesn't)
<enebo[m]>
as I said I am not really sure how to resolve these anyways
<headius[m]>
yeah
<enebo[m]>
Mostly we never seem to notice of care because utf-8 is king now
<headius[m]>
yeah that has probably "fixed" a bunch of remaining enc problems by making them moot
<enebo[m]>
but in any case any Ruby Encoding must have a matching charset for whatever encoding the file name is on the OS
<enebo[m]>
but if I am on UTF-8 filesystem and I have S-JIS encoded string it could probably transcode to UTF-8
<enebo[m]>
should it?
<enebo[m]>
This is where I get confused
<enebo[m]>
It is not like we even know what the FS is either
<headius[m]>
well I think the intent is that when you finally get a file path out, it's encoded like other filesystem strings would be rather than whatever input encoding you happened to use
<headius[m]>
I think we are just using file.encoding as meaning system FS encoding
<enebo[m]>
yeah I agree that seems to be what we hope for
<enebo[m]>
file.encoding I guess is as good as it gets in Java
<enebo[m]>
unless there is some newer API which tells us
<enebo[m]>
Even then people incorrectly writing to a fs with wrong encoding may still write out ok but just be weirdness
<headius[m]>
it would be a wacky system that defaulted to a local of UTF-8 but had filesystem encoded as something else
<enebo[m]>
I was merely using UTF-8 as an example of popular value
<headius[m]>
locale
<enebo[m]>
maybe to restate we should transcode to encoding/charset of file.encoding on all file apis? Or just assume they are passing in the proper strings to begin with
<headius[m]>
PR is green
<headius[m]>
oh I see what you're saying
<headius[m]>
why potentially use incoming encoding ever if we intend to provide a filesystem path
<headius[m]>
I guess I don't know 🤔 I was just trying to make that refactor zero-sum
<enebo[m]>
yeah my question is mostly wondering about the broader how should that work and not specifically if this fixes or doesn' fix RG globbingh
<headius[m]>
I could try pushing that change... no enc carrier and anyone calling it uses fsenc
<headius[m]>
or rather the one RubyString caller unconditionally uses fsenc
<enebo[m]>
I mean to me it is more of a general question...I only thought about because I did not see the need for the out param more than passing it in the first place...although I did come around that corner
<headius[m]>
it seems like it mostly replaces enc with fsenc when there's some shell character to expand
<headius[m]>
but I can't give a good reason why it shouldn't always use fsenc
<enebo[m]>
so in MRI can I write weird shit as a filename which is not technically an error in file.encoding of UTF-8 but will just be a lot of ???? in ls
<enebo[m]>
If so then we have some form of answer although it will raise the next question
<headius[m]>
yeah it switches to fsenc if expanding ~, if expanding based on a base path, or if it's the NUL path on Windows
<enebo[m]>
hahah funny
<headius[m]>
otherwise it uses the enc of the thing you're expanding
<enebo[m]>
I mean ~/S-JIS and S-JIS will write out differenrly
<enebo[m]>
headius: I feel like I am distracting you from what you would rather be working on
<headius[m]>
well I want to put this to bed
<enebo[m]>
This seems like it might be better but I do not know if this is proper semantics or not
<headius[m]>
neither do I
<headius[m]>
this logic only loosely resembles MRI because of the other forms of path we support
<enebo[m]>
yeah I think we should do minimal work here and maybe work on what is appropriate for 9.3
<headius[m]>
how about I merge this as is and we can throw the simplification into another branch to test
<headius[m]>
if it's green maybe it's ok
<enebo[m]>
sure I say merge it
<headius[m]>
gimme a thumbs up review on PR
<enebo[m]>
approved
<headius[m]>
ok merge was against master but I think I got 9.2 merged properly too and merge base is current
<headius[m]>
I'll push a PR for the additional change based on master
Nathan2296 has joined #jruby
<Nathan2296>
Hey, I'm trying to build concurrentr-ruby but I'm running into issues. Following the documentation leads to the following error: https://pastebin.com/Fa4VYsnV
<Nathan2296>
As it suggests, I set the JRUBY_HOME variable to both the jar file and the bin directory to no avail
<Nathan2296>
I also tried running the jruby command it suggests, which leads to a whole other set of errors: https://pastebin.com/PWJCWaTN
<headius[m]>
JRUBY_HOME should be the dir below bin/
<headius[m]>
the main JRuby dist dir
<headius[m]>
it also appears that it's not running with JRuby initially
<Nathan2296>
Great that actually led to a new error! Progress
<Nathan2296>
So running the direct jruby command still leads to the errors mentioned in the second paste