<headius>
I will look into it. It's surprising because the changes were largely additive with a warning and one place and a new error on calling dup
<headius>
It might be a bad test
<enebo[m]>
headius: Yeah I did not look but that tends to be why our local suites fail lately
<headius>
interesting that this is only failing running in the complete gem
<headius>
enebo: ah I see what is happening... this is the replace fix for RubyHash again, needs to be overridden in the ENV hash to not use those guts
<headius>
I'm not ready to fix up on those fixes but I don't like this fragility
<headius>
the fragility is really from our ill-advised extension of RubyHash really
<headius>
really
<headius>
byteit101: did you get that libutil fix released? need to update the gems for 9.4 release
<headius>
enebo: fix is pushed
<headius>
I also removed that failing OpenJ9 job from the snapshot push until we can look into it and added the M1 -Ptest (M1 spec:ffi still failing to load test lib and I'm not sure why)
<headius>
I punted three windows-related irb/IO-related issues that have been around forever
<headius>
we should punt or resolve the "Run Rails 7" issue, because it does run now but we need the other databases
<headius>
punting to 9.4.1 for ongoing work here is my instinct
<enebo[m]>
yeah makes sense. If we get this out on Weds and nothing major comes in over xgiving then I will try and work on getting postgresql running
<enebo[m]>
That gives a very small probability it could be working a week from weds but I would not hold my breath :)
<headius>
I will be working on my talk over the weekend so I may be supporting that effort a bit
<enebo[m]>
If I remember pg changed some APIs significantly
<headius>
lovely
<enebo[m]>
At some level we put ourselves in this because we basically try and emulate the cexts
<enebo[m]>
I do not think that is a bad strategy since we get a lot of support work for free
<headius>
yeah but what else can we do
<headius>
Rails should have adopted a common DB API years ago, like sequel
<enebo[m]>
but it is the cheapest way to go without supporting our own specific adapter code in AR proper
<headius>
until they do that we don't have much choice
<enebo[m]>
yeah I am still amazed a sequel never happened since jeremy was helping
<enebo[m]>
I know there is some specific reasons why sequel itself does not work for AR but he knows everything you could ever want to know how to make a common layer
<enebo[m]>
I would bet a big issue is that each specific native adapter is maintained by a different group of people
<enebo[m]>
which makes homogenizing a common API more challenging
<headius>
yeah that's probably true
subbu has quit [Remote host closed the connection]
subbu has joined #jruby
lucerne has quit [Read error: Connection reset by peer]
<headius>
I tidied up the CI jobs a bit to have the main suites at the top and exotic or known-failing suites towards the bottom
<enebo[m]>
ok
<enebo[m]>
So I am looking to close some wip's out as not fixable for 9.4.0.0
<headius>
There are plenty of those
<enebo[m]>
I see if we include io/nonblock in 3+ tcpsocket and pipe will return 'true' by default when they open after that point
<headius>
I guess we haven't talked about how we want to handle the WIP jobs going forward
<enebo[m]>
This seems like a significant thing which could break something since it toggles the default
<enebo[m]>
but looking at cext I do not see how it could know...I guess I will look at MRI socket source
<enebo[m]>
but the reason I am mentioning this is that I think we will still see some of these things which seem like they could significantly break things like puma which may assume this change by version check
<headius>
There is something in the release notes about non-block being on by default but I'm not sure if that's all I owe or just specific situations
<enebo[m]>
I guess we have both run puma so that seems to not be the case but it looks like a significant thing
<headius>
IO
<enebo[m]>
yeah IO
<headius>
Right, seem to be working fine for my testing
<enebo[m]>
I will take a few minutes to see how easy this is
<headius>
I find it hard to believe all IO are now non-blocking because everyone making calls expecting them to block would have to change their code
<enebo[m]>
yeah it is odd to me too. spec is implying it defaults for pipe and tcpserver but I find it weird for another reason nonblock? is not defined on IO until the require
<enebo[m]>
I suppose if you require io/nonblock then you are probably already setting it to nonblock so you would not have to notice it is that already
<enebo[m]>
This may be why we also run since all existing sw probably explicitly still sets nonblock
<headius>
Yeah that nonblock library I think is not doing what I thought
<headius>
IO#nonblock is an existing interface to control whether I/O uses blocking or non-blocking system calls.
<enebo[m]>
It seems to merely provide setting state
<enebo[m]>
both in Ruby and on OS
<headius>
That description makes it sound like it's mostly internal and just changes how IO does the native calls
<enebo[m]>
So by requiring it TCPServer and some other things will do that set for you
<enebo[m]>
ok I think this will not be broken for a while so it is not critical
<enebo[m]>
this probably could be revisited at same time as IO Scheduler
<enebo[m]>
I also find it pretty weird that non_block? is not just defined all the time
<headius>
Yeah I think this is just changing the IO mode at the OS level
<enebo[m]>
yeah
<headius>
Which we basically already do because otherwise we can't interrupt NIO calls
<enebo[m]>
the C code toggles it in both OS and sets some internal ruby state
<enebo[m]>
but it is a minimal gem and feels strange to be a gem
<headius>
We may not need to change anything, or we may only have to modify IO code to set the non-blocking mode on creation
<enebo[m]>
yeah some of it anyways
<headius>
There has been some discussion about rolling it back into core because it's such a small gem and doesn't make sense externally
<enebo[m]>
but our nonblock needs to remember what it is
<headius>
Ideally it should only need to look at the NIO channel to see if it is in blocking or non-blocking mode
<enebo[m]>
yeah it is what we do
<headius>
I'm not sure anyone will see any behavior difference for us because we had to use non-blocking already whenever possible
<enebo[m]>
but we are not true by default
<enebo[m]>
so TCPServer is not non-blocking by default for us
<headius>
Right because we don't have it set non-blocking all the time
<headius>
We just flip it to non-blocking whenever there's an IO operation and then flip it back
<enebo[m]>
So do you think that is just how this works they toggles to nonblocking all the time but you cannot see it is nonblocking unless you load the module which can set/read nonblocking :)
<enebo[m]>
I mean that is a good explanation but a weird lack of consolidation in these APIs
<headius>
I think that is what MRI used to do, and now they may just set things non-blocking immediately and always use non-blocking semantics to implement blocking
<headius>
Where as we always had to switch to non-blocking for every IO operation or we would not be able to interrupt them
<enebo[m]>
yeah that also would fit with io scheduler
<headius>
But we are not setting them to be non-blocking by default yet so unless you are in the middle of an io operation that flag will be false
<headius>
So the flag is really the only visible difference since we are doing things the non-blocking way whenever possible already
<enebo[m]>
ok I am tagging two of these tests from wip to fails
<headius>
I think 😀
<enebo[m]>
I can assume nonblock is for making your own scheduler
<enebo[m]>
since you can decide to block and wait of let someone else do stuff
<headius>
It would not be hard for me to whip up a quick PR that sets all selectable in IO channels to non-blocking and we can get ahead of that for 9.4.1
<enebo[m]>
so it makes sense it would just be nonblock for that by default
<enebo[m]>
yeah
<headius>
I think non-block just makes it eligible for fiber scheduling
<enebo[m]>
sure
<headius>
It doesn't otherwise change much from a user perspective
<headius>
If you're not using a scheduler it changes nothing really
<enebo[m]>
but it changes it for someone since you can affect fiber scheduling
<enebo[m]>
yeah
<enebo[m]>
and we don't have it yet
<headius>
But until we support fiber scheduling it will make a difference for us either
<headius>
So this is really a task that falls under implementing the scheduler hooks
<enebo[m]>
yeah
<headius>
Well I forgot how tiny this extension is
<headius>
Literally all it does is set O_NONBLOCK
<headius>
So our existing library does the equivalent and sets the NIO stream into non-block mode, and we just need to make that happen at NIO channel creation time
<enebo[m]>
yeah
<enebo[m]>
Having thought about it though it makes sense to not mess with this since we know puma works fine as-is
<enebo[m]>
The only thing we break by not fixing this now is new code
<enebo[m]>
which is less likely since it was not the default until recently
<headius>
Right, 9.4.1 at the earliest
<headius>
I honestly don't think any user code is going to see this unless they are checking nonblock? for some purpose
<enebo[m]>
yeah
<enebo[m]>
and why bother changing your code over it
<enebo[m]>
It will still work to explicitly set it and work on older Ruby
<headius>
enebo: any objection to me linking the mastodon Dre Ruby account to the Twitter one?
<headius>
Hey now that's a misspelling I can get behind
<enebo[m]>
yeah good idea
<enebo[m]>
I still need mastadon client for my phone
<headius>
I've been using the default mastodon app and it seems fine
<enebo[m]>
ok I will check it out
<enebo[m]>
I saw some shit with some app owner not allowing a set of mastadon instances from using the app but did not see what the drama was about
<headius>
I am just using Mastodon.social and ruby. Social and they both seem to work
<enebo[m]>
ok
<headius>
hmm so we actually have our own nonblock flag in OpenFile
<headius>
I don't know why we don't just use the NIO blocking for this... perhaps because I did not understand this version of nonblock when I made the ext years ago
<enebo[m]>
mspec will somehow turn on deprecated warns for MRI but we do not toggle it
<headius>
hmm
<headius>
that's why we get all that warning noise?
<headius>
oh deprecated warns
<enebo[m]>
well it is off by default
<headius>
oh I see
<enebo[m]>
It is off by default too but somehow it is on for MRI running but not us
<headius>
it is testing for deprecated warnings and enabling them in MRI but not us
<headius>
hmm
<headius>
well I thought I added the right flag support for that with -W:deprecated
<enebo[m]>
I fixed two simple deprecation issues but noticed this
<headius>
maybe I botched it
<enebo[m]>
and you are right we were 100% showing deprecations for constants
<enebo[m]>
oh I should see. I could not remember the name of that
<enebo[m]>
ok that is the problem
<enebo[m]>
I will fix that
<enebo[m]>
I keep seeing weird code and I am resisting the urge to fix ity
<enebo[m]>
Feels like "Object".equals(getName()) is horribly wrong as a check
<headius>
rubyspec ran green with default nonblocking
<headius>
that's promising
<enebo[m]>
ok I figured it out. you properly added the right stuff to arg processing but a helper adjustCategories was still called in setVerbose which then undid some of that
<enebo[m]>
So I will also look for raw warn(deprecated strings and we may see a reduction in those calls in test suites