<xardion[m]>
yeah, I think that is a reasonable limitation
<xardion[m]>
Just because you can do it in Ruby doesn't mean you should be able to do it to a Java collection that won't allow for that in Java itself.
<xardion[m]>
You probably COULD make it work, but it would almost certainly break all sorts of other expectations that various Java APIs might make about the immutability of that collection
<headius[m]>
And it forces us to stand up a Set full of Entry objects rather than using Java 8's own efficient internal iteration
<headius[m]>
That alone seems like justification
<headius[m]>
I will benchmark but it will be a gazillion times faster
thegeekinside has quit [Ping timeout: 256 seconds]
ur5us has joined #jruby
nirvdrum has quit [Ping timeout: 256 seconds]
sagax has quit [Remote host closed the connection]
sagax has joined #jruby
ur5us has quit [Ping timeout: 244 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 256 seconds]
<xardion[m]>
<3
ur5us has joined #jruby
ur5us has quit [Ping timeout: 260 seconds]
<lopex>
NUMBERZ
sagax has quit [Remote host closed the connection]
<headius[m]>
but by default jnr-posix returns a LazyPosix that delays binding, so it's not the one that implements Linux
<headius[m]>
there's no way to get at the underlying POSIX it actually uses
<headius[m]>
so options...
<headius[m]>
add a way to get the "real" posix from any posix, which would unwrap things like LazyPOSIX and CheckedPOSIX
<enebo[m]>
so you more or less want to be able to detect which platform
<headius[m]>
maybe ok but the lazy and checked behavior would be lost on the unwrapped one
<headius[m]>
well that and I need the one that actually implements the linux-only stuff
<enebo[m]>
I mean lazyPosix tends to push everything as a wrapped method with notimplemented
<headius[m]>
but that brings us to a second option: move posix_fadvise to POSIX interface
<enebo[m]>
but you do not want to call it to find out
<headius[m]>
I still need to know if it's implemented though
<enebo[m]>
so you need to know what platform
<headius[m]>
which we do other places by checking Platform.IS_LINUX or whatever
<enebo[m]>
yeah which is not pretty
<headius[m]>
or I could ask jnr-posix to give me a new Linux POSIX just for this usage
<enebo[m]>
but I think our real problem with the design of jnrposix is we group functionality by platform and not capablity
<headius[m]>
unfortunately we never added a way in jnr-posix to query if individual functions are actually implemented
<headius[m]>
yeah exactly
<headius[m]>
another more drastic option would be to make all posixes lazy and just kill that wrapper
<enebo[m]>
ultimately we would want checks/interfaces for each set of related things
<enebo[m]>
but that is a big big change
<headius[m]>
right
<headius[m]>
PosixFadvise interface
<headius[m]>
check if it's implemented, and then you know you have access to it
<headius[m]>
something like that
<enebo[m]>
For that matter if I did this today I think I would consider all static methods that could be imported which probably passed a handle in
<enebo[m]>
fadvise(posix, args...)
<enebo[m]>
then the API could endlessly grow without being a specific big bag of methos
<enebo[m]>
internally you still have to make it decide if it can do it
<headius[m]>
right
<headius[m]>
we have other functionality specific to platform in jnr-posix but mostly it's all internalized
<enebo[m]>
and externally you still need a user providable guard
<headius[m]>
the linux separation started out by handling __xstat garbage
<enebo[m]>
I think libcrypt was my first big reservation on the design
<headius[m]>
yeah lots of gymnastics to make that conditionally load
<enebo[m]>
but yeah various stat layouts on similar platforms is bad as well :)
<headius[m]>
one justification for me just moving this up is that it is impossible to know if it does anything
<enebo[m]>
Ok. This is mildly helpful for a new library but does not help this one today
<headius[m]>
it's just advising the kernel of how you will access the data in question and there's no way to query it
<headius[m]>
our no-op passed all tests
<enebo[m]>
you need a method can_fadvise() and fadvise()
<headius[m]>
yeah
<enebo[m]>
This would make the bag even bigger but it would be a path forward until we rewrite this thing
<headius[m]>
I don't like that we check platform externally to know if we can call something on jnr-posix, jsut because it provides no way to query that directly
<enebo[m]>
My underscore was a conscious spelling
<enebo[m]>
can_xxx for each thing could be a new convention as we limp this along
<enebo[m]>
on posix interface itself
<enebo[m]>
internally we need to wire up that guard but that seems doable in many ways
<enebo[m]>
camel case I reject because canFadvise or canFAdvise is just fighting what the thing is called
<headius[m]>
would it be better to do can_xxx for each thing or isImplemented("methodname")
<headius[m]>
there's not really any great pattern for capabilities in Java
<headius[m]>
instanceof is kinda it
<enebo[m]>
well it is not type checked but it is less methods in the javadoc we don't publish :)
<headius[m]>
but that breaks with wrappers
<enebo[m]>
isImplemented("fadvice") I guess could raise saying no such method name so not too bad that way either
<enebo[m]>
I mean we Ruby so neither move me strongly
<headius[m]>
yeah ditto
<enebo[m]>
If I am consuming the library from an IDE and I don't know it completion could be nice
<headius[m]>
what I really want is respond_to
<enebo[m]>
OTOH isImplemented is not too hard here
<headius[m]>
true... have to manually type name and not get it wrong
subbu is now known as subbu|lunch
<enebo[m]>
we know we want to call a specific method
<enebo[m]>
knowing what to type is not going to be confusing
<headius[m]>
the interface still seems cleaner... if posix instanceof Fadvise
<headius[m]>
but it will lead to dozens of interfaces
<enebo[m]>
but a typo sure but we can raise so no one will just type in their method and deploy straight to prod
<headius[m]>
I wish Java method references were actually objects you could use and attach metadata to
<headius[m]>
if (posix::fadvise.isImplemented())
<enebo[m]>
meh on interface. but I don't care on that mechanism if it was easy to do either
<enebo[m]>
annotations!
<headius[m]>
heh yeah that's the only way
<enebo[m]>
funny that many people reading that will not realize I identified it would work but I was still being sarcastic
<headius[m]>
also breaks with wrappers, but posix.getClass().getMethod("fadvise", ...).hasAnnnotation(Implemented.class)
<headius[m]>
so pretty
<headius[m]>
can_ is still easiest
<headius[m]>
perhaps as a separate interface?
<headius[m]>
posix.capabilities().can_fadvise()
<headius[m]>
doesn't clutter up the actual functional interface then
<headius[m]>
default impls of every can_ would just return false
<headius[m]>
though we need to pull the trigger on Java 8 minimum for the real magic
<enebo[m]>
yeah it could be something else...at this point I care less and less. I think we should seriously think about second system affect for calling foreign functions
<enebo[m]>
effect
<enebo[m]>
heh
<enebo[m]>
And in this case I am being totally serious
<headius[m]>
wouldn't take much effort to transfer over the guts and come up with a new user API
<headius[m]>
hell it could just backend on jnr-posix for now and eventually supercede it
<enebo[m]>
maybe
<enebo[m]>
I mean it could
<enebo[m]>
Part of me wants the entire stack to be something I would want to support
<enebo[m]>
nothing against jffi but I think we all can get lost pretty fast walking through the layers
<enebo[m]>
but perhaps that is just too much at this point
<headius[m]>
well we need to consider a possible panama future too
<headius[m]>
we're talking about a whole full-time project though to build a new Java posix environment on top of ffi or panama
<headius[m]>
just need to commission some interns to do the work for us
<headius[m]>
I think for now I should just use POSIXFactory.getNativePosix and go after the linux posix directly
<headius[m]>
not thrilled about it being a new instance though
<enebo[m]>
yeah Panama is a good point...we should not consider anything until we can use that
<headius[m]>
just need to finish fixing all the JRuby issues and we can move on to other things
subbu|lunch is now known as subbu
<headius[m]>
enebo: how annnoyed would you be if I added a getNativePosix to Ruby.java
<headius[m]>
I could do the can_ thing as well for this one method but I feel like we both are iffy on that idea too
<enebo[m]>
Ruby is a pangea pattern already
<enebo[m]>
The Genie is out of the bottle so to speak
<headius[m]>
appears to be working properly now and actually doing the fadvise call
<headius[m]>
need to spin jnr-posix release before merging though
<headius[m]>
which I think means spinnning unixsocket too
<headius[m]>
sigh... jnr does need a bit of a reboot
<enebo[m]>
hmm what happens with native disabled on linux?
<headius[m]>
it will be null and not instanceof Linux
<headius[m]>
I don't know a better option than returning null
<headius[m]>
Optional? 🤪
<enebo[m]>
ah ok it will not be Linux sure
<headius[m]>
this is a goofy feature anyway because there's zero feedback
<headius[m]>
CRuby just no-ops it on platforms where it doesn't exist, so it's always there and maybe sometimes it will do something
<headius[m]>
feels like bending to pressure from Linux fanatics
<headius[m]>
oh and get this
<headius[m]>
this posix_fadvise is really posix, published by Open Group
<headius[m]>
but the list of unixes that don't support it includes Darwin, all the BSDs, Solaris, AIX, HP-UX, and pretty much everything except Linux
<headius[m]>
so like, what even is a posix
<enebo[m]>
nothin
ur5us has joined #jruby
dopplergange has joined #jruby
dopplerg- has quit [Read error: Connection reset by peer]
<headius[m]>
enebo: I removed azure builds
<headius[m]>
we will need to move windows testing somewhere else
<headius[m]>
probably GH
<enebo[m]>
ok
nirvdrum has quit [Ping timeout: 272 seconds]
<headius[m]>
enebo: current old issue is one about properties that are no longer used
<headius[m]>
I ran into some that we might start using again, like "chainSize" and unsure whether to deprecate and maybe undeprecate later or just leave it there
<headius[m]>
I think deprecating and then maybe later we need it again is better than having properties published that do nothing
<headius[m]>
anyway I'll do it as a PR and we can discuss