yosafbridge has quit [Quit: Leaving]
yosafbridge has joined #jruby
ahorek[m] has quit [Quit: You have been kicked for being idle]
subbu has joined #jruby
wybpip[m] has joined #jruby
wybpip[m] has left #jruby [#jruby]
subbu has quit [Quit: Leaving]
subbu has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 276 seconds]
<headius> enebo: so this pathname thing might just need some URI components added back to one regexp
<enebo[m]> fun
<enebo[m]> well I believe all method-related kwargs stuff is working now. all those delegation specs pass now too
<headius> buy you a beer
<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
<enebo[m]> "Ruby 2.7.0+ required, Ruby 3.0+ preferred"
<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> it is running
<enebo[m]> yum
<headius> odd.. it seems to work at command line
<headius> Gem.ensure_gem_subdirectories("uri:file://bogus/classpath")
<headius> that's what hangs
<headius> it was a different spec to confirm RG does not try to create URI components when running from a URI
<headius> it's a fileutils change
<headius> since we are using the gem now
<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> but with the bad line it gets stuck forever on uri:file://
<headius> short term hack might be to make File.directory? recognize a root URI as a dir
<enebo[m]> hmm
<enebo[m]> I wonder what the motivation was for this?
<headius> yeah I'm not sure
<enebo[m]> to remove map I guess
<headius> if dirname returns the same path that should be good enough to know it is a dir, no?
<enebo[m]> one whole array create
<headius> well it is just that one line
<headius> until File.directory?
<headius> ignore the rest
<enebo[m]> yeah that is an addition
<headius> I reverted that line and it is ok
<headius> it is arguable that File.directory? should see uri:file:// as a dir so I'm going to go with that approach
<headius> anything else it can't tell because it is behind a URI
<enebo[m]> The whole dirname thing in the original lines comment may be a clue
<enebo[m]> I guess we will hope no one has that as an actual file for real
<enebo[m]> but the // should be safe I guess
<enebo[m]> does test///////mri work?
<headius> dirname should peel it down to test
<enebo[m]> uri:file:/foo as a real file system path
<enebo[m]> I don't think this is a real problem but I am just thinking about the corners of it
<headius> i'm tracing to see how it handles this uri
<headius> if it were to resolve it to a file:// it might work but the uri: bit might be keeping it from getting there
<headius> I want a better name for -Xdebug.parser
<enebo[m]> you can make another name but my muscle memory for it exists :)
<enebo[m]> I didn't realize how useful it would become beyond parser debugging at the time :)
<headius> ok yeah
<headius> so basically we recognize file: as a filesystem path but not uri:file
<headius> I think that is an ok addition
<headius> that kinda feels like form-fitting but it fixes this
<headius> this is just more fuel for the fire to get a unified URI/file pathing rig set up
<headius> final failure in spec:ji is due to some hash thing, might be kwarg related
<enebo[m]> yeah looks reasonable
<headius> ok the last JI failure is because MapJavaProxy no longer properly overrides RubyHash.size
<headius> so that is simple
<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> hmm
<headius> three of the four failures are this:
<headius> but nothing has changed in those specs recently
<headius> ok I got it
<headius> you added newline support but it adds '\' and 'n' and I guess it should just add a proper '\n\
<headius> s/\/\\/, s/\/\\/, s/\/'/
<headius> or rather, you rewrote this and newline was pulled out as its own thing but not using right chars
<headius> pretty good showing for such a large change
<headius> I half wonder if intellij borked this for you
<headius> ok two more fixes, spec:ruby:fast should be green again
<headius> test:jruby:aot crashed with that same segv we saw yesterday
<headius> fine locally on temurin
<headius> does not crash locally on that zulu build or a previous one
<headius> enebo: spec:ruby:fast:jit still fails and it is all kwarg related
<headius> I think I will wait to mess with that until your stuff lands
<headius> jit fails int doesn't
<enebo[m]> headius: yeah and the new stuff will be just simple calls to helper methods
<headius> int is green now in any case
<headius> ok
<enebo[m]> optimization excluded
<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
<headius> done for today!
distant[m] has joined #jruby