<headius>
enebo: I'm tagging these Enumerator::Lazy specs that blow up memory for now
subbu has joined #jruby
subbu has quit [Quit: Leaving]
<headius>
ahorek: so if I'm getting these PRs right you have some to add more syslog platforms and this other one to move the constants to jnr-constants?
<headius>
so if we moved them to jnr-constants we don't need the ones that add to JRuby
<headius>
the socket constants are ok to merge though, yeah?
<headius>
jnr-socket probably should be a thing some day 🤔
<headius>
I merged in my small change that allows aliasing from one frame-aware method name to another frame-aware method name but it doesn't really change much
<headius>
ahorek makes a good point on one of those PRs... if we define constants we did not before, code that checks defined? might start trying to use them
<headius>
so if we can't support them it it might not be a good idea to define them
<headius>
not surprised using native stat makes this work bette
<headius>
what do you want to do with this?
<enebo[m]>
I want it fixed but it is kind of icky
<headius>
it may not be possible to detect the conditions for EACCES using JDK APIs
<enebo[m]>
so here is part of the main problem. the unlink is returning the wrong errno due to the logic of trying to see if we are traversing a back symlink
<headius>
right
<enebo[m]>
So the errno itself is bogus
<headius>
and it is trying to guess what errno to use
<headius>
so you have a fix that works with native stat?
<enebo[m]>
no
<enebo[m]>
I looked at it 15 days ago and only remembered yesterday this should be fixed
<enebo[m]>
This is hit by 2 or more parties so it feels like we should do something
<enebo[m]>
JRubyFile.exists() should more or less work for unreadble yet existing files but it may be that we are broken when native is disabled and then it will return the wrong errno in that case
<enebo[m]>
but I feel that is the worst-case solution
<enebo[m]>
as a solution I would prefer it over nothing since almost no one runs jruby with native disabled
<enebo[m]>
but it would be cool to somehow make this work with Java APIs
<enebo[m]>
afk for a while so chew on that and maybe you will think of another idea
<headius>
I had two minor 3.0 fixes in flight so finishing that quick
<headius>
enebo: so what is your stat change to fix this ENOENT thing
<headius>
looking at unlink it seems like we should just remove the checks and let the errno tell the stroy
<headius>
story
<headius>
yeah that works
<headius>
that path is only followed for native anyway so I'm not sure why we would need our artificial checks
<headius>
enebo: I will push this as a PR and we can see how it behaves, but it passes the unllink specs and MRI test_file
<headius>
enebo: perhaps I should fix this on 9.2 branch and we can merge it in for 9.3.1
<headius>
but there are problems that may doom this approach... we may want to instead move the built-in extensions out of the jar and make the base jar only contain things that are not stdlib
<headius>
we have this weird hybrid builtin set-up where some stdlib are half in lib/ruby/stdlib and half in a Java extension in the jar
<headius>
it basically means the jruby-base jar is partially broken if run without the stdlib files
<headius>
and of course we also use FFI internally which is really problematic without the filesystem
<headius>
this is an experiment anyway and it allows most of the built-in extensions to work from just the jar
<enebo[m]>
yeah I am not sure what the best route is (ignoring the FFI issue which is maybe a tangential issue to bundling)
<headius>
if we were to set this up more like CRuby we would have a .jar for each extension and they'd load from that
<headius>
but that would mean none of them are available at all in the base jar... which might be fine
<headius>
we serve two masters here
<headius>
.jar for each will also tie into modules later on... each JRuby ext will have a JVM module and be loaded that way
<headius>
trying to mesh the two layouts will be interesting