<edipofederle[m]>
headius: I'm checking some old issues, and I looking at this one now: https://github.com/jruby/jruby/issues/2167 it works with current version, But I didnt try with v1.7.x (issues to compile it right now). So this is relevant yet? (I also propbhaly comment and ping you in another issues, so sorry for 'spam' you).
<enebo[m]>
edipo.federle: no this appears to be fixed for 9.2 and 9.3 and we don't support anything earlier. So I will close this one.
<enebo[m]>
It is nice to find old fixed issues and get them off the logs!
<edipofederle[m]>
yep, makes sense
Bi[m] has quit [Quit: You have been kicked for being idle]
<headius>
"SortedSet has been removed for dependency and performance reasons."
<headius>
so sorted_set was pulled out because it depends on rbtree... which has no official public repository and no maintainer
<headius>
might be a while before we can figure out how to add JRuby support to this orphaned gem
subbu has joined #jruby
<headius>
enebo: this would be nice to get fixed on master
<headius>
$ jirb
<headius>
irb(main):001:0> binding.NoMethodError: undefined method `token' for #<Ripper::Lexer:0x5daad59a>
<headius>
Did you mean? tokenize
<headius>
on_error1 at /Users/headius/projects/jruby/lib/ruby/stdlib/ripper/lexer.rb:195
<headius>
I think ahorek first noticed this method is missing but it prevents some functionality in irb from working (here it is trying to do some formatting or reflection in response to `binding.`
<enebo[m]>
headius: I just merged a PR from ahorek yesterday I think adding this
<headius>
hmm I should be current
<enebo[m]>
yeah it does not work
<enebo[m]>
I have every intention to support it trhough
<headius>
ok
<headius>
I am trying to update checkboxes on 3.0 issue and was hoping to use irb to verify features, but I'll make do
<enebo[m]>
oh I see what it was...it was just an empty stub and not merged
<headius>
yeah but I get NoMethodError so did it get put in the wrong place?
<enebo[m]>
"not merged"
<headius>
oh not merged
<enebo[m]>
Making an empty method is not worth it
<enebo[m]>
I will add an impl now
<headius>
yeah probably not
<headius>
cool
<headius>
this one is interesting: "IO#nonblock? now defaults to true."
<headius>
in support of the new scheduler, which will probably take a bit of work for us
<headius>
so they must be setting all IOs to nonblocking now by default
<headius>
this is the change to not copy module contents into include/prepend targets anymore
<enebo[m]>
no
<headius>
ok
<headius>
good be a big job, or could be simple (just add delegation for method/constant lookup in include wrapper)
<enebo[m]>
yeah I am fairly familiar with it from fixing a recent prepend
<headius>
enebo: so here's a small conundrum... alias_method now returns the new name instead of the self module
<headius>
however...
<headius>
public RubyModule alias_method(ThreadContext context, IRubyObject newId, IRubyObject oldId) {
<headius>
so we have to change the return type or deprecate and add some other name
<headius>
I have no idea how likely this is called by third-party code from Java
<enebo[m]>
yeah we just make aliasMethod and have that return the proper type I guess
<enebo[m]>
but if it is called by third party code this will continue to work by just moving the annotation
<headius>
yeah unfortunate down side of trying to be more strict on return type
<enebo[m]>
That signature is pre-2008
<enebo[m]>
I last touched the line when I added ThreadContext
<headius>
heh wow
<headius>
I am curious now
<enebo[m]>
I agree though we should not be sharing any internal method with a @jrubyMethod anno
<enebo[m]>
mixing two concerns is only going to bite us eventually
<headius>
wow
<headius>
that return type goes back to Jan Arne
<enebo[m]>
I see petersen for private_class_method in 2002
<headius>
funny
<enebo[m]>
So an ancient mistake which only took 19 years to be revealed :)
<headius>
deprecate the old signature?
<enebo[m]>
yeah or don't
<headius>
well that's why I asked
<enebo[m]>
yeah I think we just make a new one for the anno and have old one call new one
<headius>
sure
<headius>
I'm fine leaving it undeprecated
<enebo[m]>
convenient that it returns this
<headius>
should I make the new signature return RubySymbol? 🤣
<enebo[m]>
HAHAH no
<enebo[m]>
in 3 years it will conditionally return nil :)
<headius>
they will support passing arrays at some point and we'd break again
<headius>
yeah or that
<enebo[m]>
In a perfect world we would islate and just rename all things so we cannot easily consume the annos as internally embedding
<enebo[m]>
That would definitely break things but it could also lead to knowing what the native extension requirements are better
<headius>
as I go through these features I am tossing quick fixes directly on master
<headius>
like this thing
<headius>
about half of the features I have checked you got to in May
<headius>
most that remain are nontrivial
<headius>
ahorek: if you want a challenging task that would have a huge payoff, we could start looking at using the FFI-based socket impl
<headius>
it would immediately improve compatiblity of sockets to at least rubinius/truffleruby level
<headius>
last I looked at it the main problem was all the socket structures that would need to be generated per-platform
<headius>
I believe TR generates code for them at build time so we could duplicate that process for as many platforms as possible and reuse the entire library
<headius>
this all goes back to the rbx folks but I assume there have been minor updates in TR
<headius>
enebo: hey why did we originally add the "ID" enum for warnings?
<headius>
I need warning(file, line, message) and not sure if I should be adding new IDs for warnings anymore
<headius>
the existing form only has warning(id, file, line, message) and it doesn't actually appear to use the ID at all
<headius>
which makes me wonder why we have ID now
<enebo[m]>
we don't use them any more but they were for when the parser was used for the IDE
<enebo[m]>
They have not been removed but could be deprecated and replaced
<headius>
ok... so for the case I'm doing I'll add a non-ID signature and we can clean out the ID signatures later as a task
<enebo[m]>
sure
<headius>
"Mutex is now acquired per-Fiber instead of per-Thread. This change
<headius>
should be compatible for essentially all usages and avoids blocking when
<headius>
using a scheduler."
<headius>
they are basically making fiber easier for us to implement with all the scheduler stuff, because they can't just pretend a lock is acquired across fibers
<headius>
this is basically done because we couldn't do it another way without a lot of hassle
<headius>
oh enebo dunno if you saw but there is a backport Ractor impl... likely very inefficient but it is a fallback option for us
<headius>
it might advise a proper impl if it has the right semantics
<enebo[m]>
sure
<headius>
we could even box it up and ship it with 9.4.0
<headius>
why not
<headius>
maybe add it as a default gem so it can be updated
subbu has quit [Ping timeout: 268 seconds]
<headius>
we need to reevaluate Ola's profile stuff during init and see whether it's worth keeping
<headius>
it checks for things like "is Bignum allowed" that if disallowed would break most of JRuby anyway
<headius>
unsure if it is really practically useful at this point, and if it is it's only useful for a very small subset of core classes
subbu has joined #jruby
<enebo[m]>
I would be happy to remove old features so long as they are not used
<headius>
I have finished auditing core class changes and updating checkboxes
<headius>
most stuff is there
<enebo[m]>
I have been studying new args stuff last day or so