<headius> yeah I think I have it
<headius> fcntl is weird because the argument passed might have different widths but int64_t works on m1 for all tests
<headius> also works on darwin x86...
subbu has quit [Quit: Leaving]
sagax has quit [Ping timeout: 240 seconds]
<headius> if you are ambitious you could build that (see README.md for build instructions, and then do "mvn install") and then build JRuby with it (update pom.rb to point at the snapshot version and mvn clean build) and give it a try
<headius> might be a couple days before I work out the binary compatibility and upstream changes
<ssaschaa[m]> Good morning! Wow! That‘s awesome! I‘ll give it a try, definitely.
<ssaschaa[m]> So... got your PR #121 at jnr/jffi and build and installed it successfully. Then updated pom.rb to take the jffi-1.3.9-SNAPSHOT and build jruby. Unfortunately, the reported behaviour of creating a file (mode will be 0001 instead of 0666 or 0644) stays the same. Could it be due to any mistake while building?
<ssaschaa[m]> Pumping the same jffi-1.3.9-SNAPSHOT to jnr/jnr-ffi does not resolve any jnr.ffi.VarargsTest.
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
drbobbeaty has quit [Ping timeout: 268 seconds]
drbobbeaty has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius> Okay, seems like maybe it's not building quite right. I will try to get it released in the next day or two once I confirm it's fully working
<headius> scared me for a second that I might have been running x86 JDK but no, it
<headius> is aarch64
<headius> silly me... there are fixes up the stack that I did not have you build
<headius> clearly fixing jffi won't help if jnr-ffi also needs fixes, which it does
<headius> I was just excited to have you test it 😀
<headius> well I think I have a way to release this without rebuilding all platforms
dangerousdave has joined #jruby
<headius> I'll just stuff the fixed count into the high word of this `flags` value already passed into C
<headius> older builds will just ignore it and continue to work the way they do today and new builds will pick it up and use the variadic ffi logic
<headius> so I should be able to release today after getting some additional eyes on this
<ssaschaa[m]> Cool! Just direct me to any PR or release I should try.
<headius> enebo: I'd like your input on how to handle the varargs issue in jnr-posix bindings... also affects `open` which is ssaschaa case
<headius> maybe something as simple as a @Variadic(fixedCount = 123) annotation to attach to the binding
<headius> enebo: I think this is ready to review: https://github.com/jnr/jffi/pull/121
<headius> we can chat about the varargs issues in the upstream libraries when you are in the office
enebo[m] has joined #jruby
<enebo[m]> Ok
<enebo[m]> I get to shovel twice today because we are getting a delivery at 9
<headius> doesn't seem to be coming down very hard
<headius> how much are we supposed to get?
<enebo[m]> well I think we got about an 1" since last night but if we go north a little ways it will be 3+
<enebo[m]> I saw we were like 20% likely to get 3+ so we were likely pretty close
<headius> yeah inch or less near me here when I drove the kid to school
<enebo[m]> our driveway is steep enough and the delivery guy can be pretty old from this place so I want to limit liability :)
<enebo[m]> the required # of params is in flags but was it always like that or is that from another commit?
<enebo[m]> oh I see
<enebo[m]> callcontext is doing that
<enebo[m]> I missed that line first time through
<enebo[m]> reading your comments on the PR also helps
<enebo[m]> My main comment is that so long as all this stuff is released in lock-step then it doesn't matter how it is passed
<enebo[m]> So doing this to prevent rebuilding all the platforms we support seems like a good idea
<headius> yeah that is the reason for shoving it into the high bits
<headius> otherwise I need to modify the jni and check a version or failover to older code when the changes are not in the build binary... it just seemed like a lot more work than we want to do right now and we need a better migration path anyway
<headius> revving the jni stub without breaking old builds will require more thought
<enebo[m]> I think this is undoable later when we have more changes which will require the pain of rebuilds
<headius> with this last change it works properly on the x86 platforms tested in CI, which have not been rebuilt
<enebo[m]> So we are not using all those bits we may as well use them to put off rebuilding
<headius> yeah
<headius> the JNI changes are in private code anyway
<enebo[m]> but perhaps there should be a comment on needing to move this
<enebo[m]> err change it I guess
<enebo[m]> just in case we do not build for 2 years or something
<headius> I can add more explanation to the newCallContext API
<headius> and perhaps in the C code somewhere
<enebo[m]> Yeah I think just a FIXME somewhere or maybe an issue too?
<enebo[m]> One day we will live in a world where we have all these things as images (even IBM mainframes :) )
<enebo[m]> C compile farm seems like it should be a thing
<headius> we have an issue about versioning the native library
<headius> and there's related issues anywhere someone has submitted C patches
<headius> the CI for JFFI does do multi-arch builds for Linux but currently just builds them... no testing or saving them anywhere
<headius> a contrib set up qemu + debian docker to do that building automatically
<headius> testing it would require also running the JVM within qemu so I'm not sure that will scale well in CI
<enebo[m]> heh
<headius> maybe this will be moot some day when we can rely on Panama
<enebo[m]> Oh panama
<ssaschaa[m]> I just did a checkout on your PR #121 and if I didn't fail to build it correctly, it will still show the same permission issue on File.open ...
<headius> ssaschaa: correct
<headius> that is the other issue we need to talk about
<enebo[m]> foreign linker of panama is in 16
<headius> enebo: not sure if you saw my messages yesterday... have a look at this jnr-posix change: https://github.com/headius/jnr-posix/commit/c6d4478f076bcd04b5891cebc1b06431767dc36f
<enebo[m]> oh and call is in 15
<headius> so the problem here is that jnr-ffi was never fully adapted for variadic calls and just assumes varargs can be passed like normal fixed args
<enebo[m]> so when we can move to 17 we can probably ditch jffi
<headius> there's motivation
<headius> probably not happening until 2023 though 😀
<headius> so back to jnr-posix... this fcntl (and the open call ssaschaa is seeing bugs from) are variadic functions in C but jnr-posix binds them as having all fixed args
<headius> this works fine on platforms where both kinds of args are passed the same but on M1 we need to know how many args are fixed in the C call
<headius> there's no way to do that in jnr-ffi currently other than specifying the binding using Java varargs
<headius> this fcntl hack just removes the fixed bindings in favor of a single varargs binding but I'm not sure this is the way we want to go
<enebo[m]> hmm
<enebo[m]> yeah this side of things has a longer life
<enebo[m]> although if those two older signatures still works then I guess it works
<headius> they don't on M1
<enebo[m]> yeah I am just talking about existing users
<enebo[m]> They will still compile with new signature and not break
<headius> at minimum I think we need to introduce an annotation to say where the fixed args end if a user is binding a variadic call without java varargs
<enebo[m]> M1 will use new signature and work.
<headius> @Variadic(fixedCount = 2) for example in this fcntl case
<enebo[m]> Seems like this is not ideal and we have to consider if there are other bindings which are not working on M1
<headius> indeed, and I missed fixing open on this branch because jnr-posix apparently doesn't test it
<enebo[m]> If we end up making 3-4 functions into varargs like this then it feels more and more unappealing
<headius> the issue makes sense though... just looking at these bindings you can't tell if it is variadic, so neither can the new variadic logic in jnr-ffi
<headius> right
<enebo[m]> yeah
<headius> if it were just fcntl I'd just do it
<headius> I think I can add the method-level annotation easily enough
<enebo[m]> If we add an annotation that seems like a good solution since C has variadic functions and you may not want incoming args to have to line up exactly like C
<headius> I had also considered an annotation for varadic args passed as fixed args... like @Vararg(type = size_t.class)
<headius> but that is fixing another problem with this.. only the Object... form can specify how the varargs are supposed to be marshalled currently
<headius> the int64_t.class bit in that patch
<enebo[m]> non-variadic count fits my mental headspace if for no other reason we look at ruby defs the same way
<headius> yeah I think it is the minimum change
<headius> it will mean anyone with similar bindings will need to add this to work properly on M1
<headius> but I see no easier alternative
<enebo[m]> sure.
<enebo[m]> It feels like it is filling a semantic gap to me
<headius> it was "nice" that you could specify the args as normal params and it still works, but that doesn't translate to platforms with special variadic behavior
<enebo[m]> yeah it is just a pointer of pointers sort of stops if there functions don't work that way
dangerousdave has quit [*.net *.split]
andreimaxim[m] has quit [*.net *.split]
TimGitter[m]1 has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
greyrat has quit [*.net *.split]
siasmj has quit [*.net *.split]
fidothe has quit [*.net *.split]
joast has quit [*.net *.split]
JesseChavezGitte has quit [*.net *.split]
liamwhiteGitter[ has quit [*.net *.split]
BlaneDabneyGitte has quit [*.net *.split]
nowherefast[m] has quit [*.net *.split]
adam12 has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
TimGitter[m] has quit [*.net *.split]
CharlesOliverNut has quit [*.net *.split]
FlorianDoubletGi has quit [*.net *.split]
ssaschaa[m] has quit [*.net *.split]
headius has quit [*.net *.split]
edipofederle[m] has quit [*.net *.split]
ChrisSeatonGitte has quit [*.net *.split]
rebelwarrior[m] has quit [*.net *.split]
MattWelke[m] has quit [*.net *.split]
puritylake[m] has quit [*.net *.split]
RomainManni-Buca has quit [*.net *.split]
marcheiligers[m] has quit [*.net *.split]
MarcinMielyskiGi has quit [*.net *.split]
basshelal[m] has quit [*.net *.split]
KarolBucekGitter has quit [*.net *.split]
kares[m] has quit [*.net *.split]
XavierNoriaGitte has quit [*.net *.split]
Freaky has quit [*.net *.split]
MattPattersonGit has quit [*.net *.split]
JulesIvanicGitte has quit [*.net *.split]
klobuczek[m] has quit [*.net *.split]
mattpatt[m] has quit [*.net *.split]
satyanash has quit [*.net *.split]
puritylake[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
RomainManni-Buca has joined #jruby
marcheiligers[m] has joined #jruby
MattWelke[m] has joined #jruby
siasmj has joined #jruby
joast has joined #jruby
fidothe has joined #jruby
greyrat has joined #jruby
yosafbridge has joined #jruby
dangerousdave has joined #jruby
andreimaxim[m] has joined #jruby
TimGitter[m]1 has joined #jruby
drbobbeaty has joined #jruby
basshelal[m] has joined #jruby
kares[m] has joined #jruby
KarolBucekGitter has joined #jruby
Freaky has joined #jruby
XavierNoriaGitte has joined #jruby
headius has joined #jruby
ssaschaa[m] has joined #jruby
rebelwarrior[m] has joined #jruby
FlorianDoubletGi has joined #jruby
edipofederle[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
JesseChavezGitte has joined #jruby
BlaneDabneyGitte has joined #jruby
nowherefast[m] has joined #jruby
adam12 has joined #jruby
enebo[m] has joined #jruby
CharlesOliverNut has joined #jruby
TimGitter[m] has joined #jruby
nilsding has quit [Ping timeout: 240 seconds]
klobuczek[m] has joined #jruby
MattPattersonGit has joined #jruby
satyanash has joined #jruby
mattpatt[m] has joined #jruby
JulesIvanicGitte has joined #jruby
mattpatt[m] has quit [Ping timeout: 260 seconds]
MattPattersonGit has quit [Ping timeout: 260 seconds]
JulesIvanicGitte has quit [Ping timeout: 260 seconds]
klobuczek[m] has quit [Ping timeout: 260 seconds]
andreimaxim[m] has quit [Ping timeout: 240 seconds]
TimGitter[m]1 has quit [Ping timeout: 240 seconds]
enebo[m] has quit [Ping timeout: 245 seconds]
CharlesOliverNut has quit [Ping timeout: 245 seconds]
TimGitter[m] has quit [Ping timeout: 245 seconds]
FlorianDoubletGi has quit [Ping timeout: 250 seconds]
ChrisSeatonGitte has quit [Ping timeout: 250 seconds]
edipofederle[m] has quit [Ping timeout: 250 seconds]
rebelwarrior[m] has quit [Ping timeout: 250 seconds]
headius has quit [Ping timeout: 250 seconds]
ssaschaa[m] has quit [Ping timeout: 250 seconds]
UweKuboschGitter has quit [Ping timeout: 240 seconds]
OlleJonssonGitte has quit [Ping timeout: 240 seconds]
byteit101[m] has quit [Ping timeout: 240 seconds]
Albertico[m] has quit [Ping timeout: 240 seconds]
MattWelke[m] has quit [Ping timeout: 250 seconds]
marcheiligers[m] has quit [Ping timeout: 250 seconds]
puritylake[m] has quit [Ping timeout: 250 seconds]
MarcinMielyskiGi has quit [Ping timeout: 250 seconds]
RomainManni-Buca has quit [Ping timeout: 250 seconds]
liamwhiteGitter[ has quit [Ping timeout: 252 seconds]
JesseChavezGitte has quit [Ping timeout: 252 seconds]
nowherefast[m] has quit [Ping timeout: 252 seconds]
BlaneDabneyGitte has quit [Ping timeout: 252 seconds]
basshelal[m] has quit [Ping timeout: 268 seconds]
KarolBucekGitter has quit [Ping timeout: 268 seconds]
kares[m] has quit [Ping timeout: 268 seconds]
XavierNoriaGitte has quit [Ping timeout: 268 seconds]
mattpatt[m] has joined #jruby
klobuczek[m] has joined #jruby
MattPattersonGit has joined #jruby
JulesIvanicGitte has joined #jruby
andreimaxim[m] has joined #jruby
TimGitter[m]1 has joined #jruby
rebelwarrior[m] has joined #jruby
ssaschaa[m] has joined #jruby
edipofederle[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
FlorianDoubletGi has joined #jruby
headius has joined #jruby
TimGitter[m] has joined #jruby
CharlesOliverNut has joined #jruby
enebo[m] has joined #jruby
UweKuboschGitter has joined #jruby
MattWelke[m] has joined #jruby
RomainManni-Buca has joined #jruby
marcheiligers[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
puritylake[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
JesseChavezGitte has joined #jruby
BlaneDabneyGitte has joined #jruby
nowherefast[m] has joined #jruby
XavierNoriaGitte has joined #jruby
basshelal[m] has joined #jruby
KarolBucekGitter has joined #jruby
kares[m] has joined #jruby
<headius> I think I have a Variadic annotation working
<enebo[m]> I did mvn install on both and both ran tests (jnr-ffi I saw recompiled but you verified uncompile above)
<enebo[m]> on new_varargs just so that is clear
<headius> if you didn't run the ant targets for jffi then you should be using the archived binary
<headius> jnr-ffi builds some test libs, that's all
<headius> aha, adding Variadic test uncovered another place I needed to patch for FFI varargs
<headius> the ASM generated stubs also need this logic, but for now I will punt anything variadic into the non-ASM path
Albertico[m] has joined #jruby
OlleJonssonGitte has joined #jruby
byteit101[m] has joined #jruby
<enebo[m]> where is the ant build.xml file?
<headius> jffi, look in README.md for the proper incantation
<enebo[m]> hahaha I think I accidentally edited the wrong .git/config (I added wrong remote originally) and now jffi had jnr-ffi remote for you and it seemingly is happy to merge that
<headius> yeah it is pretty stupid about remotes
<enebo[m]> oh look now there is a build.xml
<enebo[m]> so I ran jnr-ffi twice I guess :)
<enebo[m]> hmm compile not working
<enebo[m]> ah I need makeinfo
<enebo[m]> texinfo is needed to build this
<enebo[m]> I was able to build 'ant jar && ant archive-platform-jar && mvn package'
<enebo[m]> So now it is not running tests from maven
<headius> if you install that then jnr-ffi should pick it up with the new binary
<enebo[m]> ok I will go back over to that
<enebo[m]> I just did mvn install that branch should pick it up proper version?
<enebo[m]> ok confirmed. It ran to completion with no errors
<headius> yes
<headius> it should pick it up from your local
<enebo[m]> yeah it did since I never had a SNAPSHOT build of that version
<headius> additional wrinkle with this variadic thing... for simple signatures it tries to use optimized JNI entry points to avoid marshalling the values via the JVM heap, but those paths do not know about fixed versus variadic
<headius> so this may have to skip the optimized entry points for these cases like fcntl
<headius> if you remove Variadic it will go back to optimized version but may not work on all platforms
<enebo[m]> hmm
nilsding has joined #jruby
<headius> ok I struggled with a bug here but I think I have it working
<headius> in jnr-ffi VarargsTest I added a signature for snprintf that has no Java varargs
<headius> it is formatting as "%zu" which should be size_t or 64-bit unsigned in this case
<headius> specifying the Java signature with an int param does not work... it does not marshal the int into 64 bits and so the result is garbled
<headius> using long works
<headius> I will have to see how this affects fcntl
<headius> so this is a case that was never tested, but needed uint64 and shows that the non-varargs signatures have to match width exactly or we need more annotations to convert properly
<headius> some of these things seem like they just worked by accident
<headius> I think the jnr-ffi Variadic changes are done... going to try applying it to jnr-posix now
<headius> I added another test for int with size_t annotation... also appears to work right
<headius> enebo: Have a look at the variadic annotation in https://github.com/jnr/jnr-ffi/pull/292 and my use of it in https://github.com/jnr/jnr-posix/pull/174
<headius> for the latter I also had to add a uint64 type annotation to get the int form of fcntl to work properly on M1. I suspect this is because it is pickier about variable alignment since it is sticking all varargs on the stack rather than in registers
<headius> I'm going to try plugging these into jruby on M1 and see how it looks
<enebo[m]> ok
<headius> my one concern about this change is that uint64 annotation
<headius> it works ok on x86 without it
<headius> well tests are looking better but every call to open is failing with permission errors 😝
<enebo[m]> The changes look ok to me but more because nothing jumped out.
<enebo[m]> I don't say that with a lot of confidence
<headius> ssaschaa: you run zsh or what?
<enebo[m]> but perhaps the more tests the better and you did add something so that builds a little bit more
<headius> I just noticed your command line has a ! in double quotes and that doesn't work on bash
<headius> enebo: this is exactly ssaschaa issue so I am close
<headius> heh
<headius> $ stat /tmp/test.txt
<headius> 16777233 4427426 --wxr-----
<headius> yeah not quite
<enebo[m]> SHIP IT
<enebo[m]> So n stack values must have word alignment?
<enebo[m]> to work as variadic call?
<headius> well that's my blind theory
<headius> I am trying to add @mode_t annotation to this open binding to see if that fixes it
<enebo[m]> so variadic call with int and short would force the compiler to cast a short into an int so it would be same size for the call
<enebo[m]> I will make an admission that I don't think I used va_* in like 30 years
<headius> yeah I have had to learn more about it than I wanted to know
<ssaschaa[m]> headius: yes zsh, but does it matter?
<headius> no I was just curious why that command line works for you
<headius> I just removed the ! to run it
<ssaschaa[m]> the whole issue seems to be quite challenging...
<headius> oh it's a lot of fun 😀
<ssaschaa[m]> fun fact: i simply enforce permissions using File.chmod 0755 when detecting a file with '[OTHERS_EXECUTE]' at sysopenInternal at jruby
<headius> ok it doesn't like mode_t, must not have the right plumbing to marshal that... uint64 seems to fix it but I want a better understanding of why
<headius> ssaschaa: yeah that's not a bad workaround if you can run off a local build
<ssaschaa[m]> bad hack
<ssaschaa[m]> but as you are talking about the background of this issue, i am really surprised that all the other things are working...
<ssaschaa[m]> i mean i am using oracle jdbc with jruby ;-)
<headius> all the stuff at the JVM level is easy peasy compared to this
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
dangerousdave has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dangerousdave has joined #jruby
<headius> heh well I managed to break open on x86... not sure if that is progress
<headius> expected:<438> but was:<33188>
<headius> not sure how it is getting this 100644 file permission
<headius> maybe I am doing something wrong in test
dangerousdave has quit [Ping timeout: 256 seconds]
<headius> oh for pete's sake... umask
<headius> I guess I should know this stuff
<enebo[m]> JavaLangReflect has a method newInstance which has alias annotation "new_instance". This stumbles over JavaClass having a "new_instance" method
<enebo[m]> This will always print out a warning.
<enebo[m]> // NOTE: (legacy) JavaConstructor compat - converting arguments
<enebo[m]> @JRubyMethod(name = "newInstance", alias = "new_instance", rest = true)
<enebo[m]> So I am a bit confused on how this works. The legacy support seems to be making this alias which is overwriting something which is not legacy all the time.
<enebo[m]> I guess for anything using j.l.reflect witin JI (which would be people manually using it) would want this alias to occur since you want the reflective version
<enebo[m]> It also seems like there is quite a bit of warning potential here since we are putting methods on the same class
<enebo[m]> I half wonder if we need an alias_no_warn="new_instance" just so we can skip it for JI
<headius> wait what?
<headius> JavaLangReflect is a package, it shouldn't get any methods
<headius> that should change anyway... the `alias` in JRubyMethod is the wrong way to alias methods on boot... CRuby just defines the methods again with the same name
<headius> not with an alias wrapper
<headius> there are almost no cases in CRuby where they set another name up for a core (C) method using alias
<headius> enebo: this is a kares thing that he moved out of the Ruby code I think
<headius> oh no I know what this is
<headius> he added this other newInstance to simulate java.lang.Class.newInstance I believe
<headius> as part of deprecating and replacing JavaObject, JavaClass, JAvaConstructor
<headius> the latter two and similar ones are just using java.lang.Class, java.lang.reflect.Constructor, etc, with these decorations to make them look like the Java* versions
<headius> this was in 9.3
<headius> hot crackers
<headius> [] ~/projects/jruby $ ruby -e "f = File.open('/tmp/test.txt', 'w'); f.puts 'Yeah'; f.close"
<headius> [] ~/projects/jruby $ ls -l /tmp/test.txt
<headius> -rw-r--r-- 1 headius wheel 5 Jan 5 15:01 /tmp/test.txt
<headius> 0666 with 022 umask... seems to be working now
<headius> another one that had to be annotated with a u_int32_t
<headius> edging closer... now some ioctl call is segv
<headius> aha... more varargs
<enebo[m]> headius: so can I remove this? This is stuff to emulate the old JI in Ruby
<headius> remove what
<headius> you could make it name = { both } to keep the "alias" and eliminate the warning
<enebo[m]> ah yeah
<enebo[m]> I will do that and it completely gets around the issue
<enebo[m]> I forgot I could do multiple names
<headius> we should probably deprecate alias... I'm not sure it is useful
<enebo[m]> There is one other issue in ffi/struct.rb I need to fix yet
<headius> I added it back when I thought additional names in CRuby were assigned like aliases but they are not
<enebo[m]> an "aliagn" alias in class << self is hitting another one already defined
<headius> not sure what that was meant to be
<headius> did you check if CRuby still warns for alias overwrite?
<enebo[m]> They have a lot of extra logic we don't but I thought it was an alias overwriting an alias but that is not the case
<enebo[m]> I have not spent time looking much at that one but I did try a simple repro and it did not work
<headius> oh goodie, Ruby FFI logic duplicates a bunch of stuff from jnr-ffi
<headius> ok well that's a mess for another day
<headius> I think this is crashing because our Ruby FFI impl basically duplicates a bunch of code from jnr-ffi and doesn't have my variadic tweaks
<headius> ioctl is variadic
<headius> are we having fun yet?
<enebo[m]> @JRubyMethod(name = { "alignment", "align" }, meta = true)
<enebo[m]> So we have a Java ext version of Struct but we also have the Ruby version part of the ffi gem
<headius> match the C version... if they are assigning this alias in Ruby we don't need the second name
<headius> there are a few cases like this that evolved while we were maintaining our own copy of the ruby files
<enebo[m]> ok so the goal here is we load native version then the ruby require overlays so we avoid alias errors by not defining this in the native case because the ruby version will alias
<headius> right
<headius> a number of things like this moved into Ruby from C... I fixed the big ones
<enebo[m]> ok looks like alignment is the a valid method here not overridden by ruby version but align actually points to a totally different method
<enebo[m]> so I believe this is an outdated name here in the Java annotation
<enebo[m]> in any case it is redefined so it is not being used anyways
<headius> huh ok
<headius> yeaaaah buddy... no more segv
<headius> still seeing some weird permission errors on open
<headius> these might be M1 or Big Sur behavior differences
<headius> ssaschaa: if I were to push a snapshot with these jnr fixes, which version of JRuby would you prefer to try?
<headius> ok this is looking pretty decent
<headius> spec:ruby:fast timed out on a UDP spec but there were thousands of specs before that and only a couple failures
<headius> there will be some platform oddities for sure
<headius> hanging in some Process.kill spec
<headius> probably need to dig deeper but IO and File and a bunch of other stuff look good
<headius> enebo: I think we might be able to spin some releases here
<enebo[m]> cool
<headius> need to investigate these hangs but IO and File specs are green and that's a lot of native calls including open and fcntl and posix_spawn
<headius> we may finally be ready for M1
<byteit101[m]> Should alias/alias_method work on extending java interfaces?
<headius> Yes
<headius> Interface implementation generates a stub method for each that read dispatches to appropriate Ruby names so it should find aliases
<headius> Re-dispatches
<byteit101[m]> works: module Address; def +(r);add(r);end;end
<byteit101[m]> fails: module Address; alias :+ :add;end
<byteit101[m]> Caused by: org.jruby.exceptions.NameError: (NameError) undefined method `add' for module
<byteit101[m]> at org.jruby.RubyModule.alias_method(org/jruby/RubyModule.java:3367)
<byteit101[m]> ^ File an issue?
<headius> Oh that
<headius> We do not actually define the interface methods on the interface modules because they interfere with dispatch when we try to call against Java classes that implement those interfaces
<ssaschaa[m]> headius: I don‘t prefer any specific version. I am happy to try anything.
<headius> I try a couple times but modules aren't quite the same as interfaces and installing dummy methods screws up the dispatch hierarchy
<headius> ssaschaa: I don't think I'll have time to spend any JNR releases until tomorrow, but once that's done we should have snapshots of 9.3 and 9.4 with these fixes in place
<byteit101[m]> Should I file an issue about that expectation?
<ssaschaa[m]> i have just tried to run the tests on jnr-posix (#174) which included jnr-ffi-2.2.11-SNAPSHOT (#292) which included the jffi-1.3.9-SNAPSHOT (#121) without success.
<ssaschaa[m]> java.lang.NullPointerException: Cannot invoke "java.lang.reflect.Field.set(Object, Object)" because the return value of "jnr.posix.JavaLibCHelper$ReflectiveAccess.access$400()" is null
<headius> What Java version is this?
<ssaschaa[m]> openjdk 17.0.1 2021-10-19
<ssaschaa[m]> OpenJDK Runtime Environment Homebrew (build 17.0.1+1)
<ssaschaa[m]> Darwin Kernel Version 21.2.0
<ssaschaa[m]> macos monterey 12.1
<headius> Could be Java modules interfering with the guts of jnr-ffi
<headius> I have not run tests on 17 and there's a lot of code generation and reflection in there
<headius> Do the jnr-ffi tests pass?
<headius> I am on Big Sur and Java 11 and things were passing
<ssaschaa[m]> yes, jnr-ffi test are passing
<headius> Okay file a bug with jnr posix and I'll have a look tomorrow. It would be nice to have it working on all Java versions before I release
<ssaschaa[m]> just tried with java 11 (OpenJDK Runtime Environment Homebrew (build 11.0.12+0)) and tests at jnr-posix are failing as well. but different. i am sorry!
<ssaschaa[m]> and:
<ssaschaa[m]> openTest(jnr.posix.FileTest) Time elapsed: 0.002 sec <<< FAILURE!
<ssaschaa[m]> java.lang.AssertionError: expected:<438> but was:<420>
<headius> oh rats I commited that test
<headius> that test was expected to fail... with umask 022 it turns the requested 666 into 644 so the test is in error
<headius> ssaschaa: I have reproduced your failures on 17 and pretty sure it is related to modules and reflection
<headius> I will remove or fix that other tests
<headius> ssaschaa: fixed
<headius> also pushed snapshot builds of jffi, jnr-ffi, and jnr-posix, and started a branch to pull the updates in (from 9.2 on): https://github.com/jruby/jruby/pull/6985
<headius> time for my 9-ball league, ttfn