subbu has quit [Ping timeout: 260 seconds]
subbu has joined #jruby
subbu has quit [Quit: Leaving]
sagax has joined #jruby
<edipofederle[m]> Morning guys,
<headius> Morning!
<edipofederle[m]> headius: I'm checking some old issues, and I looking at this one now: 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> ok...
<edipofederle[m]> is about it: ?
<headius> yup, there's a pure-Ruby gem that replaces it now
<headius> 🤷‍♂️
<headius> fine with me I guess, it will probably die in the wild now
<headius> ah I see
<headius> they replaced the implementation with RBTree and did not want to add that dependency into core
<headius> we're going to need to get our java Set into the `set` gem and get a JRuby impl of the RBTree gem
<headius> wow
<headius> double wow
<headius> knu already has been releasing -java versions of the sorted_set gem that just falls back on our shipped impl
<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 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> enebo: is this implemented on master yet?
<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
siasmj has joined #jruby
subbu has quit [Quit: Leaving]