Guimauve has quit [Quit: what do a cigarette and a hamster have in common? they're both harmless until you put them in your mouth and light them on fire. ]
<headius>
e
<headius>
enebo: so that require_relative thing
<headius>
it only affects cases where the file doing the require_relative is loaded via a relative path, like running main.rb at command line
<headius>
because we do not put the full path into the AST/IR for relative-pathed files, it tries to resolve it against cwd, so if cwd has changed (Dir.chdir) the require_relative will fail to resolve the original file
<headius>
it will probably need to have full path in the IR so we don't try to canonicalize it later against a changing CWD
<headius>
may be low enough priority that we can punt to 9.3.10
<headius>
that would just leave that socket bug I can't repr
<headius>
repro
<ldywicki[m]>
Is it used anywhere in jnr ?
<enebo[m]>
headius: yeah I don't know. Do we need to record both relative and absolute?
<headius>
That would probably be ideal
<enebo[m]>
I believe we use relative for errors but then also I guess depend on absolute for CWD?
<headius>
There's also the debugging angle, we can't get IDEs to pick up sources automatically from our bytecode because we always use the absolute path there
<enebo[m]>
Are we really different than MRI here?
<headius>
I think we need to plumb through both the relative path that was requested at require time and the resolved path from which we actually load the file
<enebo[m]>
Not the chdir thing but just what we record
<headius>
Well we've always had little bug reports about us storing canonicalized to happen instead of symlinked, storing absolute path when someone wants a relative path, etc
<enebo[m]>
yeah
<headius>
s/to/path/, s/happen//
<enebo[m]>
we also spend more time resolving because of that
<enebo[m]>
but a lot of it is also incidental since we do tricks to figure it all out
<headius>
We may actually plumb both paths through but we only use one in IR
<enebo[m]>
If we decide pure-Java is off the table we could potentially simplify a lot of stuff for files/dirs
<headius>
You mean by calling native realpath function and stuff like that
<enebo[m]>
I don't think we do..AST only stores it once I think now in root and parseresult maybe has something more but I would have to look
<headius>
Yeah it might not be getting into parse results
<enebo[m]>
yeah just full native 100% for all resolution of paths (except I guess classpath)
<headius>
I'm pretty both make it through the lookup process in load service but we only set up one of those paths when we do the actual parse and load of the file
<headius>
It's actually a little weird that the file we run directly uses the relative path. It is set up outside of load service so it's probably passing in the relative path when parsing
<enebo[m]>
yeah so we need to maybe pass that in and we can store both in rootnode and then we put it into staticscope or irscope or something
<enebo[m]>
yeah so if we resolve that to absolute then this bug is fixed but all other oddities will remain but it will be consisten
<enebo[m]>
I think we don't possibly just because the errors will not be ./main.rb
<enebo[m]>
anyways for .10.0 if we fix we probably do what I just said or we always pass both in which involves a bit more API tweaking
<enebo[m]>
The former may break someone's expectations since main file is sort of special and we are reporting relative like MRI
<headius>
Yeah I've never quite gotten a hold on when MRI canonicalizes those paths and when it doesn't
<headius>
Looking at the require relative code, it seems like it's expecting a full path to come out of the instruction sequences
<headius>
Always
<enebo[m]>
and we happen to do it for all but main file :)
<enebo[m]>
so my opinion is we do not fix this for .10.0 but for .11.0 to prioritize 9.4 but we fix by passing both
<enebo[m]>
I could fix this a different way
<enebo[m]>
The third dirty fix would be to take first parsed file in IRBuilder and use CWD only for that build
<enebo[m]>
Hmm I guess I have to know it is main file and not internal
<headius>
.9 is what we want to release this week
<enebo[m]>
oh yeah decrement both of those numbers :)
<headius>
Yeah applying CWD right away would also solve this
<headius>
I'm guessing the main path for command line scripts just isn't passing the canonicalized path through, which might be right for some things
<enebo[m]>
but it must only be for that file but I guess if this is the only file which can be relative we do it for only relative files
<enebo[m]>
afk for a little bit but I think perhaps there is a simple temporary fix here
<headius>
yeah so forcing the absolute path before loading cli file would break `__FILE__` in that file
<headius>
[] ~/work/jruby93 $ jruby blah.rb
<headius>
"/home/headius/work/jruby93/blah.rb"
<headius>
[] ~/work/jruby93 $ rvm ruby-3.1 do ruby blah.rb
<headius>
"blah.rb"
<headius>
we only have one file parameter to the parser, so it has to be one or the other
<headius>
CLI uses relative and load service uses absolute, and we can't get from one to the other after the fact
<headius>
ldywicki: hey if you have a chance let's chat about your status again... there's also this one blocking some users on MacOS that we should get fixed up:
<ldywicki[m]>
hey headius, I ran out of time over weekend to get dockcross (see earlier message https://matrix.to/#/!vyEDBdbmzqApWaugdd:matrix.org/$166583190725331DuPnM:matrix.org?via=matrix.org&via=libera.chat&via=rrerr.net), but I will target it as soon as I get spare time.
<headius>
ok... I don't want to mess with stuff too much while you are looking into it, but someone pinged that MacOS signing issue over the weekend
<headius>
maybe I should look into a quick fix for that that can go into 9.3.9
<ldywicki[m]>
I currently have no clue how mac stuff is being built (beyond make) and what are odds for that platform, so if you are able to address this over some quick fix it will be definitely faster than what I can do. I found older sources of jnr-parent project I started doing ~2 years ago, updated my jnr checkouts and started going over ffi stuff.
<ldywicki[m]>
One of questions I have is - which version of ffi you have copied in your source tree?
<headius>
ok
<headius>
good question
<headius>
I updated it fairly recently, last year or so
<headius>
should include appropriate text in the sources in repo
<ldywicki[m]>
all right, will look there
<ldywicki[m]>
I looked at commit log and versions mentioned there were ~2014 or 2015
<headius>
enebo: getting a weird concurrency error from bnd when building jruby-complete
<ldywicki[m]>
but indeed there were some commits from last year and prior that year too (AFAIR)
<headius>
byteit101: forgive me if I asked already... there's several issues floating around for the IRB thing... but is this not fixed enough to close, or are you waiting to get the additional patches in IRB?
<byteit101[m]>
> it only affects cases where the file doing the require_relative is loaded via a relative path, like running main.rb at command line
<byteit101[m]>
this sounds similar to a bit of confusion I got in MRI when I was mixing r_r and require and getting some files loaded twice
<byteit101[m]>
headius: I got Process.spawn passing using subspawn for all but 3 tests: Open3 when run integrated (separate run passes 100%), and two "no extra children" for shell-but-not-really-shell launches
subbu has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<headius>
nice!
<byteit101[m]>
I would like some review of my approach to the 4 gems and the split thereof though, at some point
<byteit101[m]>
and I also would like some help with apple: both testing and building arm64
<headius>
Will do tonight or tomorrow
<byteit101[m]>
the builds aren't fully integrated yet, but I'll be around if you need help building
<byteit101[m]>
I was also pondering putting openpty in there too, thus moving the entire pty.rb to subspawn