<enebo[m]>
define_method and proc is still not quite right
<headius>
wow
<headius>
ah that's not surprising
<enebo[m]>
that is next but I am hoping that is just hooking this up more than it is already
<enebo[m]>
rails still hits the root 1 arity problem
<enebo[m]>
so that is either a) define_method/proc b) forwarding ... having some issue
<headius>
hmm
<headius>
they are not define_method so it must be forwarding
<enebo[m]>
well it depends
<enebo[m]>
if anything in the chain of calls has a define_method it may be marking something as ruby2_keywords and that is getting its status flag wiped and it then becomes a normal param
<enebo[m]>
I am really really hoping a hash with that flag is not traversing many calls down but it is peculiar
<headius>
oh I see, yeah I suppose that is possible too
<enebo[m]>
I think that flag will lead to weird errors when people decide to call with captured args into threads
<headius>
the delegate methods themselves are just normal (evaled) def blah(...); blah2(...)
<enebo[m]>
I do think that will be very uncommon but it will just show up as an arity error
<headius>
yeah well hopefully in a couple versions ruby2_keywords will be a distant memory
<enebo[m]>
yeah I am hopeful but I even thought that rails code was using it
<enebo[m]>
I think the method_missing itself was
<headius>
maybe as a temporary measure... rails 7 is rooted on ruby 2.7 right?
<enebo[m]>
hmm
<headius>
that was the word last year but I don't know if they went to 3.0 in the interim
<headius>
pushed my pathname tweak, should make test:jruby green
<enebo[m]>
HAAHA
<enebo[m]>
Don't tell me but tell me
<headius>
hah
<headius>
yeah
<enebo[m]>
damn
<enebo[m]>
I guess this means 2.7.x will always be 2.7+
<headius>
spec:ji is next for me... mostly passing but something hangs
<enebo[m]>
which means ruby2_keyword issues if there are any until next big release
<headius>
probably yeah
<enebo[m]>
If there is a serious issue we can patch rails or open an issue
<headius>
WONTFIX: use Ruby 3 kwargs
<enebo[m]>
it will just be due to state toggling
<enebo[m]>
but their code is using ruby2_keywords to make sure 2.7 can run in places
<headius>
well I am confused on that point
<enebo[m]>
I guess Rails 8 will be 3.0/1+
<headius>
yeah depending on when it comes out
<enebo[m]>
So my guess is there are enough 2.6+ libraries out there calling into Rails they were not comfortable enough with forcing full 3.0 keyword behavior
<enebo[m]>
but in their delegation it seems pretty strategic like method_missing
<enebo[m]>
which should be fine since that likely will just get untoggled in next call since rails seems pretty kwargs heavy
<enebo[m]>
but rails is still largely shared-nothing in the middleware once you are on a thread
<enebo[m]>
So we would only have an issue if someone leverages something in Rails and then wants to leverage parallel stuff
<headius>
RubyGems extensions
<headius>
should keep URLs together when splitting paths
<headius>
that's the one that hangs
<enebo[m]>
in that case if it is a problem it will be something where I think we will realize what is up and help people do somehting else
<enebo[m]>
hangs or heat death regexp
<headius>
I'd guess it is getting stuck on some path component and re-splitting the same thing forever
<headius>
and that's the diff that broke it... it is expecting File.directory? to eventually return true but it never does for a URI
<headius>
yeah reverting just that line lets it progress.. File.dirname for a URI will keep returning the root URI but File.directory? will not recognize it as a dir
<headius>
it should look like this when it processes the components down to root:
<headius>
that is what broke it but only because you access RubyHash.size field directly in your visitAll
<enebo[m]>
I thought I had reverted that
<enebo[m]>
I spaced out I was replacing static impl for closures
<headius>
seems to still be intact on master
<enebo[m]>
well you can revert that if you care to
<enebo[m]>
seems you can also fix it as-is too
<headius>
why did you revert exactly?
<headius>
or I guess, why did you do this change
<headius>
I can revert but if there was a need for this change I don't want to break it
<enebo[m]>
oh I think I remember now
<headius>
FWIW this should have started hanging JI right away so I'm not sure why it wasn't caught
<headius>
probably because master has been so red
<enebo[m]>
I did a much larger change and some of those changes were adding state which did not need to be created per call
<enebo[m]>
I reverted the ones which did that and left the rest
<headius>
it should fix this to just use delegated size method
<enebo[m]>
So I think these were all more an effort to inline the logic using closures so it just reads nicer without having to navigate
<headius>
oh but maybe not
<headius>
it walks RubyHash internals
<headius>
so it would not work on the delegated version in MapJavaProxy
<headius>
ah yes
<headius>
the other visitAll is overridden in MapJavaProxy
<headius>
so I can override this and get it to work probably
<enebo[m]>
ok
<headius>
MapJavaProxy will probably need to be addressed at some point, probably by generifying RubyHash to work with opaque backends
<headius>
as it is we have to override everything or it runs into cases that expect RubyHash internals
<enebo[m]>
The closure motivation made me wish we could redo a bunch of stuff
<enebo[m]>
Funny how Java having inner classes is so obviously a smell (to nice looking code) once you get closures in the mix
<headius>
lastest push should have test:jruby and spec:ji green
<headius>
on PR
<enebo[m]>
nice
<headius>
so RubyHash will eventually need the treatment I did for RubyArray specialization... figure out the key methods to override and implement most of the rest atop those
<headius>
then we can back it with whatever we want, like a Java Map or a concurrency-safe impl or a compact impl
<headius>
JRuby X bruh
<headius>
test:jruby still failing on Windows
<headius>
I'm not going to dig into Windows stuff until everything else is green
<headius>
ok things are looking good on PR... I'm going to take a step back and get spec:ruby:fast green again
<headius>
CI starting to look a lot better in this PR in any case
<enebo[m]>
but it will be less complicated than our pre-3 stuff since it won't constantly be trying to extract a hash
<headius>
mostly MRI and WIP specs still failing with a few of our weirder runs
<enebo[m]>
I believe we never passed the mock of to_hash for that reason
<enebo[m]>
one thing I do wish but I don't really think it is worth it is recv instrs get keywords + args and if keywords is not undefined it knows it needs to potentially subtract one from args length
<enebo[m]>
I think that is good as it gets from a straightforward design since we would not want to modify args itself
<enebo[m]>
If we ever changed call path to separate out how we represent keywords then that would also go away
<enebo[m]>
but a single object check and decrement for a few methods is much less work than we were doing
<enebo[m]>
dinner prep but this is going well enough. hopefully tomorrow I will have block done. I might look at forwarding in the morning just to see if that is something simplish since methods + kwargs should be fine
<enebo[m]>
I know we do have an issue with **nil but that one is more amusing than likely to break code
<headius>
yeah probably not worth it since we will move forward with more custom call path logic for kwargs when we optimize
<headius>
specifically passing kwargs as a separate special arg or args so they are not part of positional arg array
<enebo[m]>
well we do not know it is a forward by the itme it passes IRBuild or I guess we can probably still detect it but the detection would be weird
<enebo[m]>
I guess since we give the 3 things funny names we can look at the names and if we have all 3 it is forward
<enebo[m]>
forward is largely just syntactical sugar to anonymous variables
<headius>
yeah makes sense
<headius>
I will finish today looking at spec:regression since these look easy
<headius>
then we are down to the suites we expect to fail plus some weird configurations
<enebo[m]>
cool
<headius>
it's coming together ok
<headius>
nothing major so far to get our suites green so hopefully that is a good sign
<enebo[m]>
I think main features are prepend/include subclass stuff and argument reordering
<enebo[m]>
The latter I think will not be hard. It is just changing IR for masgn (I think)
<enebo[m]>
I would think we do opt args for methods and the like correctly
<headius>
ah yeah the masgn ordering
<headius>
yeah IR build change should do it
<enebo[m]>
personally I doubt delivering it would break any real code
<enebo[m]>
yeah it is just reordering build order of rhs
<enebo[m]>
I am hoping only masgn methods
<headius>
tomorrow we should chat about release milestones... we will probably be working before RC but not perfect, but I'm comfortable doing a working 9.4.0 with promises to quickly address missing or broken features in updates
<enebo[m]>
I can dig they wanted it to be consistent but who depends on execution order
<headius>
I assume you don't want to do a release candidate or preview so .0 is the preview
<enebo[m]>
yeah we can talk about that and we still have some time to figure out which things we think we will have done
<headius>
I don't want to do a release candidate either because it makes no difference
<enebo[m]>
yeah I think so but let's stew on that a bit
<headius>
ok
<enebo[m]>
I am going to do some dinner prep
<headius>
ta ta
<enebo[m]>
cya
distant[m] has quit [Ping timeout: 240 seconds]
enebo[m] has quit [Ping timeout: 240 seconds]
enebo[m] has joined #jruby
<headius>
spec:regression should be green now
<headius>
I had to implement some random bytes to random Bignum logic... seems ok as is but review might be good
<headius>
not entirely sure I am handling the range properly... I am assuming if the Bignum requires N bits then any random fitting into N bits or smaller will work
<headius>
since most significant bit will always be the limit