<cgautam[m]>
<headius> "I'm sure there's a JVM library..." <- is this message for me
ahorek[m] has quit [Quit: You have been kicked for being idle]
<headius>
cgautam: yes sorry
subbu has joined #jruby
<headius>
enebo: okay other than fixing these refinement issues do you have any high priority items for 9.4.1?
<enebo[m]>
whatever came in over break
<headius>
I have a fix in progress for one such item
<headius>
I triaged most of the items from the break
<enebo[m]>
I am hopeful whatever is broken for refinements will also fix the use of it in tzinfo
<enebo[m]>
Ok. I am going to examine the zsuper in a closure issue this morning
<enebo[m]>
headius: does your PR fix sorbet to the point of running
subbu has quit [Ping timeout: 260 seconds]
<enebo[m]>
headius: I reviewed the bound super PR. What you did makes sense to me.
<enebo[m]>
Part of me is not super solid on how use mixing in these included pseudo modules work in combination with other things but I guess without exhaustively working through prepends/refines or something in the super type?
<enebo[m]>
prepend may work fine is a super call asks for ???origin??? on the type it is referencing from the include
<enebo[m]>
which whatever getter that is I think we must do that
<headius>
it doesn't actually mix it in... it just creates the pseudoclass out of an include wrapper and uses that as the implementation class for the method
<headius>
so super can go up from there
<headius>
it's hacky as heck
<headius>
I don't get why it should do this
<enebo[m]>
yeah I did get that but I guess so long as the pseudo part of this is just going up one level it will be no worse than being in the original type
<enebo[m]>
"no worse" == "works the same"
<headius>
yeah there is some refinement-related code in the same blob of CRuby but I will have to circle back to that
<headius>
or wait until someone is using bind_call to invoke refined methods and it doesn't work
<enebo[m]>
Me using "no worse" shows my overall confidence :)
<headius>
and we thought Ruby was complicated 15 years ago
<enebo[m]>
wait until module adds the new concept "depends"
<enebo[m]>
(this is a joke)
<enebo[m]>
I believe much of the complexity added later was to satisfy library authors and I wonder if this all could have been done in some idiomatic coding style over more language features
<headius>
hah
<headius>
yes it probably could have
<enebo[m]>
prepend I can see why someone would do it but at the same time it just feels like some mind-bending hack
<headius>
they way they did it sure does feel hacky
<headius>
I considered implementing it such that all classes have a pseudo class below them that's actually on the object
<headius>
so you could just include above that and it would prepend the original
<headius>
but it adds one pseudoclass to every level
<enebo[m]>
I am not throwing shade at MRI here either (from an impl standpoint -- you have to do something with a huge old codebase) but from a language standpoint I am just questioning whether this complexity was ultimately worth it)
<enebo[m]>
ah yeah I simpler might be worth it even if it effects some micro benches
<headius>
rather than doing this origin dance all the time
<headius>
enebo: so recent bundler no longer works on 9.3
<headius>
ah yes, 2.4 was released before the holiday and must have dropped Ruby 2.5 support (at least)
<headius>
so my question is whether it's time to just drop the 9.2 images
<headius>
we don't support it anymore and 9.4 has been out for a couple months
nirvdrum[m] has quit [Quit: You have been kicked for being idle]
<enebo[m]>
headius: I don't have any idea who uses images and whether it should matter or not
<enebo[m]>
like we will not be releasing a new version of our stuff so it would be to pick up fixes in bundler or whatnot but bundler will not work for 2.5 so they cannot get that
<enebo[m]>
so it makes me wonder what benefit it would be for us to try and update the image and update it with what?
<enebo[m]>
I guess the base container deps getting security?
<enebo[m]>
I think we could stop supporting it and see if anyone gives a reason why we shouldn't?
<headius>
I could make the image install an older version of bundler on 9.2 but this is a pretty good excuse to just drop it
<headius>
Yeah that seems fine. We can always put it back if there's some compelling reason to do so
<headius>
Also that bind commit seems to have failed some suites so I need to look into that
<lopex[m]>
"Pragmatically, OpenAI was a mechanism for Microsoft to try risky things with AI without incurring the liability and reputational risk of doing it themselves. They became very conservative after Tay."
<lopex[m]>
indeed
<enebo[m]>
I don't know what compvis is but it is what it seems to use
<enebo[m]>
From a glance something in the reporting of Thread#inspect being different
<enebo[m]>
but I think it may be a little more than that
<headius>
aha
<headius>
well a bunch of these are due to to_java actually returning Thread now instead of our wrapper
<headius>
that is an API change indeed
<enebo[m]>
yeah Ruby-Thread is not in the name
<headius>
these might all be that
<enebo[m]>
but I did not look at all failures
<headius>
I did not notice these failures, my bad
<headius>
it seems to be all in our suites though
<enebo[m]>
Seems like a reasonable change but do we care to know if we are in a Ruby thread or a Java one?
<headius>
well you can still get the wrapped RubyThread with JRuby.ref or to_java(org.jruby.RubyThread) I think
<headius>
this does beg the question though... should the default now be Thread? It is one thing to make it possible to to_java(java.lang.Thread) but it is another entirely to change the API to always do that
<headius>
maybe we back off the default and push it for 9.5
<enebo[m]>
My main questions: a) should we provide API to know Ruby vs Java? b) Do people already assume this is how we determine that or is it just our test suites?
<enebo[m]>
I think the answer to a is yes but I have no idea on b
<enebo[m]>
If no one is looking for Ruby vs Java threads I don't care too much but if we cannot know then we consider the fallout of the change
<headius>
well this is literally to_java, it seems like the default of Thread is logical
<enebo[m]>
fwiw no one is using 9.4 yet
<headius>
but I'm worried about changing it mid-version
<enebo[m]>
but we did not announce (and let's be honest we do not have a real mechanism for this) it
<headius>
I was just about to change the tests but there may be library code using this
<enebo[m]>
yeah that is my main issue
<enebo[m]>
if someone is assuming this we cannot just change it even if we pretend .1 is out
<enebo[m]>
and personally .1 is like a pre for us
<enebo[m]>
but I have no idea how you would even figure this out either
<enebo[m]>
We should make a wiki page of breaking changes and deprecations
<enebo[m]>
Then we can just update it so 9.5 will replace X for Y. Z is going away
<enebo[m]>
This seems like a weird way to test to me
<enebo[m]>
isn't there an id?
<enebo[m]>
I am sure there is a reason and there is a comment above one of these mentioning parsing apart for windows but it is a fairly weird piece of text to parse. I am guessing there is no id-like method
<enebo[m]>
Although if we do plan on delaying this change we should either make '==' work or make an 'thread_id' which encapsulates logic like this
<enebo[m]>
I would assume all Thread.current would be a Ruby thread so I am not sure why 'saved = Thread.current; ...; assert_eq(saved, Thread.current)
<enebo[m]>
I am spamming :)
<headius>
heh yeah those are weird tests
<headius>
I dunno... hard to gauge the possible impact from this
<headius>
someone would have to have known thread.to_java returns the JRuby object wrapper and then know how to use it to get the real thread underneath
<enebo[m]>
headius: when kares sees this he can probably tell us where he saw this happening
<headius>
these failures may be the failures in my PR
<enebo[m]>
he said he saw it used by two different things
<headius>
yeah
<kares[m]>
I know it's breaking but 9.4 seemed like a fit, returning an internal org.jruby.RubyThread by default is simply inspected territory
<kares[m]>
some advanced uses assume this - have seen thread.to_java(org hrubý.RubyThread).native_thread to get the java thread
<kares[m]>
which would still work but having a blessed to_java do the same by default made sense to me
<enebo[m]>
So API to get native is fine since it will effectively be self.
<kares[m]>
I think LS might have the to_java.native_thread assumption but they will be fine changing once they upgrade
<enebo[m]>
I think the weird part is the testing using inspect on the old wrapper
<kares[m]>
I can poke around tomorrow to see if there are other potential.uses In gems
<kares[m]>
enebo[m]: Yeah sorry about that I did not notice those failures ...
<enebo[m]>
kares: yeah that's great. I have to wonder how many consumers there can eb
<enebo[m]>
it is no big deal but that matching code invites other questions
<enebo[m]>
Like should we have an API for what it is trying to do
<enebo[m]>
Or should == just work
<enebo[m]>
Likely without a wrapper == probably does work now
<kares[m]>
hmm I think those will be just weird tests, but yeah can poke around history when they were introduced for context
<kares[m]>
believe it was just fewer types to test that way ...
subbu has quit [Ping timeout: 260 seconds]
<kares[m]>
(but am not behind a computer to check now)
<enebo[m]>
kares: I suspect the to_java(Thread) stuff will be just fine so I think our only concern is why people are looking at inspect output
<enebo[m]>
"I suspect" == it is just returning this/self so it is fine
<kares[m]>
assert_match(/Ruby\-\d+\-Thread\-\d+\:\s(.*\.rb)?\:\d+/, native_thread_name(Thread.current)) ... this one?
<kares[m]>
will still work the same ... btw.most use-cases at least the two Logstash and the
<kares[m]>
stuff I am working on these days to the native thread extraction simply to set the name
<enebo[m]>
kares: that happens in I think more than one place but yeah
<kares[m]>
okay will inspect those places one by one tomorrow or the day after
<headius>
hey what's our policy on merging 9.3 to 9.4 now
<headius>
9.3 is in maintenance mode so all new work is on 9.4
<headius>
enebo: asking because this bind/call behavior apparently predates 2.6 so I need to apply a similar fix to 9.3, but it won't merge cleanly because 9.4 added bind_call
<enebo[m]>
I think we should backport things which are not risky if someone notices it broken on 9.3
<enebo[m]>
but I think we should not move everything we discover unless it is mostly just a cherry-pick
<headius>
so not merging forward but backporting/cherry-picking to 9.3
<enebo[m]>
I think when it is some obvious language semantic especially
<headius>
I just don't know if it is too early to cut off merging but not sure when we last did it either
<enebo[m]>
but when we change things like the whole module iinclude/prepend/... we should consider risk
<enebo[m]>
I am mixed
<headius>
yeah so the question in my mind is whether we will have enough fixes coming in for 9.3 that we need to keep merging forward
<headius>
it is already hard to merge many pieces
<headius>
we did it while 9.4 was in dev but it's out now and new fixes and code should largely go there
<headius>
but it is not adopted by many people yet
<enebo[m]>
I think if we get a simple core method fix in 9.3 we merge forward
<enebo[m]>
but if it is already a mile apart we just punt it (or possibly examine how important it is to make it work)
<enebo[m]>
but I think that is largely bi-directional
<headius>
so I should apply this to 9.3, merge 9.3 to master, and then make the additional change to bind_call separately
<lavamind[m]>
(aside: IRC bridge is still broken, messages from IRC not showing up in Matrix)
<headius>
bleh specs failed
<headius>
lavamind: JRuby could never b
<headius>
never build openssl because it is an extension made for CRuby
<headius>
we need to have the openssl gem maintainer add a no-op gem for us that just installs our jruby-openssl
<lavamind[m]>
hrmm, strange that its now trying to build it in the test though ? it was working two weeks ago
<lavamind[m]>
headius: is that something the openssl maintainer needs to do for every release of the openssl gem?
<lavamind[m]>
oh I see, the "trocla" gem itself has had a new release, adding openssl as a new dep
<lavamind[m]>
do you know of a barebones gem published on rubygems that has minimal dependencies and an executable ?
<lavamind[m]>
just so I can test if jruby can install a gem and launch the executable in a test
<headius>
lavamind: yeah it would need to be done for every release so there's a -java version that just installs our stuff
<headius>
ugh ok so gems are starting to add openssl as a dep
<headius>
we'll need to bump up the timeline on dealing with this enebo
<headius>
enebo: these failures do not appear to have anything to do with my UnboundMethod#bind change
<headius>
that libutil thing was previously seen only on master but byteit101 did something to patch that in subspawn... I don't know why we are seeing it on 9.3 now
<headius>
the other one would mean some JI is loading early but I don't know what would have changed that either
<enebo[m]>
so something broke it but it was not what you suspected...but still a good fix
<headius>
the spec failures don't make sense either
<headius>
Etc.sysconf returns the value of POSIX.1 system configuration variable SC_SYMLOOP_MAX ERROR
<headius>
Errno::EINVAL: Invalid argument - No message available
<headius>
these have nothing to do with my patch
<enebo[m]>
yeah that I see locally
<headius>
there's some environment change on GHA I suspect
<byteit101[m]>
I would have expected it to always be broken on 9.3 on fedora
<enebo[m]>
so now GHA has it I guess
<enebo[m]>
err doesn't have it
<lavamind[m]>
headius: I have lots of these errors as well on Debian
<headius>
byteit101: GHA must have updated something
<headius>
lavamind: commented with more details about how to fix this... the long term fix would be in openssl, but trocla could remove the dependency or release a separate -java gem with jruby-openssl as the dep
<headius>
there's no way to do conditional dependencies in RubyGems itself
<lavamind[m]>
ah ok I understand
<lavamind[m]>
thanks
<lavamind[m]>
A bit tangential but jruby-openssl seems to be compatible with bouncycastle 1.72 in testing
<headius>
we always try to keep it up to date but it lags sometimes
<lavamind[m]>
you won't find me, a Debian dev, blaming you for that lol
<headius>
enebo: do you see this Etc failure locally too?
<headius>
I want to confirm it fails in CRuby before I file something with rubyspec
<enebo[m]>
oh can you give me the line to try
<enebo[m]>
It must be happening on my machine though since this only just started wit GHA