<byteit101[m]> There are already two workarounds, which I put in https://github.com/jruby/jruby/issues/6888
deividrodriguez[ has joined #jruby
<deividrodriguez[> Hello friends! Rubytogether kindly sent me an OS X machine to be able to help out with MacOS specific issues. I'm setting it up now, but I'm unable to install jruby. This is what I get... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f69fd5aec94cafa4f0ab57cc47b7b5fb2f8fb991)
<deividrodriguez[> Any ideas?
<deividrodriguez[> I guess it's some issue with this new M1 architecture?
<headius> deivid.rodriguez: yeah there are two issues I know of with M1 right now: varargs and signing the jffi binary
<headius> the latter might be an issue with all macos 11+
<headius> I believe the ffi gem got updates at some point to use libffi functions for setting up varargs, while the jffi library does not and jnr-ffi (the Java-facing API) sets them up manually
<headius> so there's a bit of work to get varargs using the proper libffi logic
<headius> enebo: shall I merge that errno fix then?
<deividrodriguez[> aha, thanks. So as of now, it's not yet possible to run jruby on M1, correct?
<headius> you can run it with an x86 JDK, or do limited things with an M1 JDK
<headius> I hope to get it fixed before RubyConf though, in 9.3.2
<deividrodriguez[> Great, I'll look into installing an x86 JDK for now, thank you!
<headius> enebo: another windows thing you might be able to test quickly: https://github.com/jruby/jruby/issues/5662
<headius> I have a PR to remove some canonicalization of filenames in https://github.com/jruby/jruby/pull/6735
<headius> my vbox suddenly stopped working so I'd have to reboot into Windows to test this
<headius> ahah upgrading seems to have fixed it
<deividrodriguez[> Yay! I reinstalled an x86 JDK and now jruby installed fine, thanks for the tip!
<headius> Yay!
<enebo[m]> headius: yeah errno I think so.
<enebo[m]> headius: part of me wonders if natuve properly raises on a broken symlink
<headius> I wonder that as well but I don
<enebo[m]> I will try FILE on windows
<headius> don't see any pre-checks on CRuby for unlink
<enebo[m]> yeah I feel like this somehow was a hack around unlink not doing it right but if both are literally calling the same unlink then I would guess we should just work
<enebo[m]> It logically follows but I still wonder why we ended up needing special logic in the first place
<headius> this is the bulk of the work CRuby does around unlink (just path munging mostly): https://github.com/ruby/ruby/blob/master/file.c#L410
<headius> I suspect that we had those pre-checks from code before we started to use a native unlink
<headius> we used to only use JDK delete which isn't quite the same, so the errors it raised were unhelpful
<enebo[m]> yeah that makes sense we just evolved and did not fix it
<enebo[m]> popping over to windows for a little bit
<headius> ok
<headius> I will merge errno thing
<headius> oh and merge it to master
<headius> enebo: I just noticed this might also be fixed by the canonicalization change: https://github.com/jruby/jruby/issues/5240
<headius> enebo: I'm merging master into that PR and pushing so it has other load fixes
<headius> I can test this other issue on macos
<headius> does not appear to fix the over-canonicalization with loaded features
<headius> enebo: if it doesn't fix the windows issue then I'm fine punting this to 9.3.2 and taking another look
<enebo[m]> ok having typical windows issues but almost testing it
<headius> ok we'll punt then
<headius> gonna take a deeper look at how we handle the path throughout loading
<headius> I have other reasons to look into that anyway: I want to start setting the JIT source path as relative paths from LOAD_PATH so we can hook up a JVM debugger and have it find sources
<headius> huh I guess we haven't punted anything to 9.3.2 yet because the milestone isn't there
<headius> enebo: should I punt these coverage and tracing items to 9.3.2 or 9.4
<headius> I don't think they'll be any harder than previous trace/event fixes but it just needs doing
<enebo[m]> 9.4 or untarget
<headius> at least one of them was reported by a user with a coverage library
<headius> ahh yeah, simplecov added branch coverage a while back and it doesn't work on jruby
<headius> just a comment from pragtob
<enebo[m]> yep. I mean I think this is mostly about likelihood and priority
<enebo[m]> I don't see either one of us doing this by end of year so we will just keep punting it
<headius> so my nudging you has not increased your likelihood of taking this on
<enebo[m]> HAH
<headius> not a high priority I admit...I will untarget but that means it goes into the black abyss
<enebo[m]> well it is not much different than the light abyss
<headius> down to 46 open issues/PRs marked for 9.3.1
<headius> enebo: on second thought I want to punt the socket constant updates to 9.3.2 so we can see how it affects things
<headius> just don't want to ship with constants defined that we don't actually support, and have code with `defined?` start trying to use them
<headius> kares: what's the status of this? https://github.com/jruby/jruby/pull/6439
<headius> my only concern was making it all native with no Java fallback... I believe we need to at least keep the Java impl around in JRuby or in jnr-posix
<headius> down to one page of open issues and PRs
nelsnnelson[m] has joined #jruby