<donv[m]>
I think most of the tooling is obsolete and can be removed for "Ruboto 2". I am working through the README for a new project. How far have you come setting up a new project?
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
PavanNambi[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
reydi[m] has quit [Quit: Bridge terminating on SIGTERM]
skumarg[m] has quit [Quit: Bridge terminating on SIGTERM]
nilsding has quit [Quit: Bridge terminating on SIGTERM]
BZK[m] has quit [Quit: Bridge terminating on SIGTERM]
TimUckun[m] has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
donv[m] has quit [Quit: Bridge terminating on SIGTERM]
JinhoYoon[m] has quit [Quit: Bridge terminating on SIGTERM]
PeterRamm[m] has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
rcrews[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has joined #jruby
<headius>
I was just trying to run tests against ruboto 2 to see if it could be updated for recent android versions
<headius>
I believe Michael got stuck when it broke trying to use Android APIs that are removed or disabled or something
<headius>
yes
donv[m] has joined #jruby
<donv[m]>
Run tests against the ruboto/ruboto repo?
<headius>
I got to the point where it tries to generate apps and test something about them, but it doesn't seem to have the right flags or paths
enebo[m] has joined #jruby
<headius>
so I stopped there to see if this is the best way forward
nilsding has joined #jruby
BZK[m] has joined #jruby
imlostlmao[m] has joined #jruby
kares[m] has joined #jruby
PavanNambi[m] has joined #jruby
reydi[m] has joined #jruby
byteit101[m] has joined #jruby
PeterRamm[m] has joined #jruby
skumarg[m] has joined #jruby
TimUckun[m] has joined #jruby
JinhoYoon[m] has joined #jruby
ahorek[m] has joined #jruby
rcrews[m] has joined #jruby
lopex[m] has joined #jruby
agent-novichok has joined #jruby
PavanNambi[m] has quit [Quit: You have been kicked for being idle]
<headius>
donv: The priority short-term would be getting it fixed up enough we can generate an app, Even just a simple one to demonstrate it's possible
<headius>
I thought maybe if the tests were working and I could make some minor alterations I could push a new gem and Michael would be able to use it
<headius>
I have a 13-hour flight tomorrow, probably will work for at least half that time, and then pei starts next week Friday so we have about a week to cobble something together
subbu has quit [Ping timeout: 268 seconds]
PavanNambi[m] has joined #jruby
agent-novichok has quit [Quit: Leaving]
<headius>
GHA speed improvements seem to be panning out... a clean run on master is now around 30 minutes down from 45
<headius>
we need to tweak spec:ruby:fast to be much faster and move more tests to slow
<enebo[m]>
headius: this will not help but I am slowing moving test:jruby and spec:regression into spec:jruby
<enebo[m]>
I realized we are testing a lot of stuff altready spec'd but also I was having a hard time finding what tests we do have
<enebo[m]>
spec/jruby has beginnings of same layout as spec/ruby but it will only contain specs specific to us
<enebo[m]>
I move common specs over to ruby/spec unless they are there already then I just delete them
<enebo[m]>
I guess it will eventually help because I am deleting some tests. It will mostly reduce the size of our matrix and make it easier to find specs
<headius>
yeah the more we can reduce it the less important it is we run it many ways
<headius>
a lot of remaining test:jruby stuff could also move into spec:ji
<headius>
enebo: `literal` flag on Hash/HashNode does not appear to be used anymore since we have separate kwarg handling
<headius>
I have removed from IR and JIT locally but parser changes would be needed to remove from node
<enebo[m]>
yeah Java specific things can be in ji but one example in spec:jruby was classpath URI handling for File and Pathname
<enebo[m]>
It is more specific to those functions than to Java interaction
<headius>
I just realized profiling that at some point I removed non-varargs construction paths for literal arrays and hashes, so they're both creating an array of elements and then inserting those elements into a separate object
<headius>
so simplifying this before I fix that
<headius>
literal hashes should have like 5-10 element construction paths to avoid creating temp arrays
<enebo[m]>
My yarp branch I am hoping to merge this summer (still a ways out but it massively changes IRBuilder)
<enebo[m]>
So this is a trivial thing to merge but just a heads up
<headius>
kwargs too... all pairs in an IRubyObject[] and then inserting those into a normal hash
<headius>
I'm confused though... I know I had this hooked up to the "small hash" logic
<headius>
may have been part of kwargs cleanup and never got put back
<enebo[m]>
possibly
<enebo[m]>
I do remember us talking about small version of something earlier this year too but I am not positive it was for kwargs
<headius>
mmm I think Array doesn't do it because there's only two practical cases for passing without the []: 1 and 2 specialized arrays
<headius>
so it's just using the indy-constructed array as the array
<headius>
but hash and kwargs should skip the intermediate array
<headius>
and use small hashing
<headius>
yeah I think when we stopped using the literal flag the calls to the spread forms went away
subbu has joined #jruby
<headius>
we need to get that thread-safe direct addressing hash in place
<headius>
that would cut down allocation for hashes a ton
<headius>
moving indy small hash creation to non-varargs + small hash logic improves a three-element hash bench by 33%