<headius[m]>
deivid.rodriguez: huh, I don't know why that would be
<headius[m]>
oh I see, repository goes idle and it stops scheduling
<deividrodriguez[>
Yeah. For an automated solution, I guess you need to create some "artificial" activity with some frequency less than 60 days from an active repository (for example, jruby/jruby)
<deividrodriguez[>
Or maybe move the logic and the action the create the nightly builds to the jruby repo itself
<deividrodriguez[>
<del>the create</del> that creates
TimGitter[m]1 has quit [Ping timeout: 276 seconds]
olleolleolle[m] has quit [Ping timeout: 276 seconds]
slonopotamus[m] has quit [Ping timeout: 276 seconds]
kares[m] has quit [Ping timeout: 276 seconds]
OlleJonssonGitte has quit [Ping timeout: 276 seconds]
KarolBucekGitter has quit [Ping timeout: 276 seconds]
kalenp[m] has quit [Ping timeout: 276 seconds]
subbu has joined #jruby
joast has joined #jruby
knu has joined #jruby
justinmcp_ has joined #jruby
michael_mbp has joined #jruby
lopex has joined #jruby
ebarrett has joined #jruby
quadz has joined #jruby
victori has joined #jruby
Antiarc has joined #jruby
olleolleolle has joined #jruby
jeremyevans has joined #jruby
lanceball has joined #jruby
den_d has joined #jruby
c355e3b has joined #jruby
drbobbeaty has joined #jruby
Iambchop has joined #jruby
satyanash has joined #jruby
fidothe has joined #jruby
havenwood has joined #jruby
Freaky has joined #jruby
c355e3b has quit [Ping timeout: 252 seconds]
Liothen has joined #jruby
Iambchop has quit [Ping timeout: 246 seconds]
Iambchop has joined #jruby
c355e3b has joined #jruby
Iambchop has joined #jruby
Iambchop has quit [Changing host]
JulesIvanicGitte has joined #jruby
enebo[m] has joined #jruby
lopex[m] has joined #jruby
cyberarm has joined #jruby
kai[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
byteit101[m] has joined #jruby
headius[m] has joined #jruby
UweKuboschGitter has joined #jruby
fzakaria1 has joined #jruby
surge_g[m] has joined #jruby
TimGitter[m] has joined #jruby
OlleJonssonGitte has joined #jruby
FlorianDoubletGi has joined #jruby
rdubya[m] has joined #jruby
RomainManni-Buca has joined #jruby
kares[m] has joined #jruby
deividrodriguez[ has joined #jruby
MarcinMielyskiGi has joined #jruby
yaasky[m] has joined #jruby
JesseChavezGitte has joined #jruby
chrisseaton[m] has joined #jruby
ahorek[m] has joined #jruby
nonlandi[m] has joined #jruby
kalenp[m] has joined #jruby
olleolleolle[m] has joined #jruby
slonopotamus[m] has joined #jruby
caleb_land[m] has joined #jruby
XavierNoriaGitte has joined #jruby
CharlesOliverNut has joined #jruby
TimGitter[m]1 has joined #jruby
marcheiligers[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
MattPattersonGit has joined #jruby
KarolBucekGitter has joined #jruby
rtyler1 has joined #jruby
drbobbeaty has quit [Ping timeout: 265 seconds]
<headius[m]>
deivid.rodriguez: I do not have write access to that repo so I pinged Benoit about it
<headius[m]>
enebo: so this method binding thing is a good exercise... lots of cleanup to do here
<headius[m]>
like I realized it tries to set up all aliased method names in the mapping table but there is only one slot and we only have one Java method name in the Java stack trace so there is no value in adding mappings for aliases
<headius[m]>
it does mean we can't show the actual name called with a single method has many aliases
<headius[m]>
but as long as the primary name (first one) is descriptive I don
<headius[m]>
don't think it matters
<enebo[m]>
perhaps not
<headius[m]>
only fix at that level would be to add Java entry points for each alias name
<headius[m]>
🤷♂️
<headius[m]>
more invokers, more classes, more methods
<headius[m]>
enebo: what do you think about a pass to delete more deprecated 19 methods
<headius[m]>
master only of course
<enebo[m]>
headius: I have been leery because I removed one earlier and it ended up being needed by jruby-rack
<headius[m]>
hah
<headius[m]>
yeah that is why I ask
<headius[m]>
did that get fixed?
<enebo[m]>
yeah I think a big part of our problem is we need to audit all the java native exts and make sure they are even using the right methods
<enebo[m]>
This is not even about deprecations. There are still extensions that are probably pre m17n
<enebo[m]>
It wasn't but there is some confusion over the codebase and how it needs to change
<headius[m]>
may be that train has sailed for 9.3 but we could set up a hard task to do for 9.4
<headius[m]>
9.4 is shaping up to be a big cleanup and perf release along with 3.0 work
<enebo[m]>
yeah I think if we could just hit top 50 native exts we could probably nearly make a list of methods used
<headius[m]>
another project that came to mind during this binding work would be making it easier for exts to generate invokers and stuff.. we are paying to generate those every time for those libraries
<headius[m]>
very likely impacting startup
<headius[m]>
or I need to revisit the zero-generation indy-based invokers again
<headius[m]>
they may be faster than loading a bunch of custom classes at this pont
<headius[m]>
if we could flip all invokers to a single IndyDynamicMethod with a handle that would eliminate hundreds of classes
<headius[m]>
deivid.rodriguez: that dev build is enabled again and I have write access now so I can kick it when it stops... a better solution is needed though
<headius[m]>
maybe we can set up an action on master that will update something in that repo, like a git hash or last-successful-build link
<headius[m]>
enebo: so this idea about walking subclasses to look for overrides hit a bit of a snag: there is no way to walk subclasses
<headius[m]>
neither in the compiler API nor reflection
<enebo[m]>
excellent
<headius[m]>
we would have to do some notation regardless to know the subclasses to walk
<enebo[m]>
This reminds me of not being able to know packages
<headius[m]>
yeah it is the same thing... late bound language and all that
<headius[m]>
so I am thinking the simplest option now would be to look for a JRubyClass(subclasses = { ... }) annotation when binding and just add additional entries for the classes specified there
<headius[m]>
then any of those classes that have the same method names as parent will get the translation
<headius[m]>
no inspecting them, no digging into subclasses, just a second or third entry from className => mapping table
<enebo[m]>
yeah seems like there is no other choice for finding the classes to look at
<enebo[m]>
If you took your original idea of specifying the method and combined it so it was org.jruby.RubyFixnum#op_plus(...) we could make a build-time tool which would error if those methods ever disappeared or perhaps were marked as deprecated
<enebo[m]>
my main issue originally was just thinking about simple we can map the bindings and my main fear was having to keep a list up to date. FQN java to the impls could mean we forget to add one but the fact they are FQN at least would mean we would not remove it without warning
victori_ has joined #jruby
victori has quit [Ping timeout: 252 seconds]
<headius[m]>
yeah and it won't be per method anymore, it is not worth it
<headius[m]>
so RubyInteger will have @JRubyMethod(implementers = { RubyFixnum.class, RubyBignum.class }) and those two classes will get the same mapping table
<headius[m]>
this avoids accidentally walking some big subhierarchy and trying to determine which methods are actually overridden
<headius[m]>
enebo: I will have this working momentarily
<enebo[m]>
ok
<headius[m]>
logic is in and green, just pushed the annotation changes for RubyInteger, RubyArray, and AbstractRubyMethod that should still be green
<headius[m]>
it is cleaner... I don't like having to list the classes but it is what it is