<headius>
I can revert to `!relative?` or try to improve this regex to work with URL forms (perhaps just expanding what it allows before the `:` in the Windows drive letter support?)
<kares[m]>
there's an ugly issue with both 9.2 and 9.3 (seems like a RGs loading issue) when using Bundler and latest jruby-openssl gem is installed (along side the default gem):
<kares[m]>
just started looking into it - planning further reduction and trying to raise with RubyGems - at least for now it seems like it should be able to handle these cases
<headius>
kares: this might play into SSL context issues on master
<headius>
I will try to file bugs today for the missing bits that prevent net-http from working out of the box
<kares[m]>
headius: not sure about what the issues are on master, but this is a loading issue -> missing up openssl.rb from the default gem with the installed newer gem
<kares[m]>
feel free to point me towards the master thingy
<headius>
Yeah maybe not related then but I will figure out what needs to be done
<kares[m]>
in this case if latest jruby-openssl was the default gem shipped with jruby everything would work as expected (with regards to the bug I linked)
<kares[m]>
going to continue digging how's to blame and will report back if I find anything ...
<headius>
Aha I see
<kares[m]>
okay progress - 9.3.3.0 is not affected only JRuby 9.2
<headius>
Aha, is it just older RubyGems causing a problem?
<kares[m]>
tried 9.2 with the shipped one as well as latest - same behavior
<headius>
Hmm ok
<kares[m]>
also tried updating to the same RGs version that 9.3 has but still broken
<kares[m]>
oh right I think I have a lead on what this might be ...
<kares[m]>
9.3 shipped with the autoload rewrite right, so now an auto-loaded constant triggers a proper require (which is patched by RGs) ?
<kares[m]>
seems like it's that - given that `jruby -ropenssl -S bundle` works as a work-around (forcing an early load of OpenSSL - which bypassed the later autoload :OpenSSL)
<headius>
Ah yes that could definitely be the problem, but I don't remember when autoload started dynamically calling require
<headius>
So it does an autoload but that doesn't use the patched require and as a result does not activate the gem
<enebo[m]>
spec:ruby:fast ended up with 32 more F/E from this and I find this unexpected since this is just changes to our launcher script
<headius>
See anything that looks like it is related to the script?
<headius>
This is why I'm trying to get more suites green on master, because I don't know how many things are supposed to be failing
<enebo[m]>
not yet but it was consistent up to this commit as 190 total (a tiny bit of variation when you landed random stuff since you fixed something but created to NPEs -- we were 189 for a while)
<enebo[m]>
I just look at spec:ruby:fast as my main focus on results since that feels like a floor of support
<enebo[m]>
MRI test is much larger and more picky
<enebo[m]>
I do look at both suites when woking on an individual method or thing to make sure both are happy but as far as total number I look at spec:ruby:fast
<headius>
Perhaps we should tag things with some in progress tag name so we can see what we expect to fail right now and new failures will show up in CI
<headius>
We don't have to use the fails tag
<enebo[m]>
I expect by the time we tag out what we won't do on spec:ruby:fast all dependent CI using JRuby-head should be working again
<enebo[m]>
I think we are pretty close...like 50 of the 190 are just fiber
<enebo[m]>
10-20 are things like GC#total_time which we can probably just tag out now
<enebo[m]>
maybe make NotImplementedError
<enebo[m]>
(and who knows perhaps that one can be done but you get the idea)
<headius>
Many of the peripheral failures will go away but for example the JRuby suite fixes I made were about half new behavior that made the test wrong
<headius>
I'm just saying we could tag with WIP or something and not give up on fixing them but at least have a green CI baseline
<enebo[m]>
as far as outdated tests in our suites I don't care as much but I also think not as much is broken there
<headius>
You can ask mspec to just run the WIP specs
<headius>
It could even be added as a job so we don't look completely green but we have the known failures in one specific place
<enebo[m]>
so how do we communicate this to k77 etc?
<headius>
Are you saying we need them to fail or people won't try to work on them?
<enebo[m]>
will anyone besides us know they fail?
<headius>
Having the second job in CI that says something like unfinished features would convey it pretty well
<enebo[m]>
ah so run this twice but one is green
<headius>
Or we add a second job that excludes the work in progress tag and allow the main spec run to be read. I don't care either way, I just want some green runs of specs as a baseline
<enebo[m]>
I just wanted obvious missing stuff to stick out clearly that it is not done
<headius>
Right now there's nothing I can run locally or in CI that will tell me if we've regressed
<headius>
Even going by failure counts is not accurate because I might fix 10 things but break 10 others which isn't really progress
<enebo[m]>
A second green version of spec:ruby would be helpful
<headius>
A la my random changes
<enebo[m]>
as I said I am largely only focusing on the results of spec:ruby as baseline Ruby support
<headius>
Yeah I just can't track 190 failures and know that I didn't break something
<enebo[m]>
The output of that is alphabetical too so in many cases you can scroll to see
<headius>
Scroll through 190 failures and make sure I didn't regress anything?
<enebo[m]>
but if you want to make special tag and then run spec:ruby:fast twice that is an idea which gives us immediate feedback and a good showing of what is not done
<headius>
yeah I'll make a PR with some tags for WIP stuff
<enebo[m]>
I am ok with that and no I don't expect people to scroll through the whole output but I have not had issues with spec:ruby:fast in particular mostly because the features do not tend to hit other things
<enebo[m]>
Some things will hit many things like chaning IO perhaps
<enebo[m]>
I don't expect we will be able to notice regressions in that case
<headius>
would you prefer that spec:ruby:fast stay red or move WIP specs to a new spec:ruby:wip
<enebo[m]>
but I never thought of running the same tests twice
<enebo[m]>
I don't care. One will be temporary
<headius>
yeah maybe... we may want it for 3.2 work though
<headius>
this time is a big leap of course
<enebo[m]>
kiichi maybe will be less confused perhaps spec:ruby:fast job is suddenly green but I am sure they will figure it out
<enebo[m]>
oh yeah we can re-add this once we are done and move on to the next thing too
<enebo[m]>
at some level we want to cut down how long tests run so I would look at this idea as just a big cycle early testing strategy and not a persistent one
<headius>
WIP run would largely be a no-op if there's no WIP tags so it will just fade away until we start marking stuff WIP again
kovyrin[m] has quit [Quit: You have been kicked for being idle]
<enebo[m]>
Like we may still have some WIP tags in a month and then just make those hard tags at that point (with issues or not depending on severity)
<enebo[m]>
oh well that is fine. It will still spin something up and not do much
<headius>
this will add a little time but mostly just booting and running... the failed WIP specs will not run in spec:ruby:fast
<enebo[m]>
I guess that probably is not a lot of time and it requires no effort
<headius>
I can throw together a PR in a few minutes
<enebo[m]>
yeah that makes sense to me
<headius>
I have not come up with a good fix for that pathname thing that broke jruby suite but that is the last failure there
<enebo[m]>
I am still editing ripper again...I get bored and then look at other stuff. Some things are mind-numbing
<headius>
mentioned above... merging in updated stdlib broke Pathname#absolute? because the new version from CRuby loses our handling of URIs
<headius>
might be breaking other JI stuff but I have not checked
<enebo[m]>
ah maybe we can core-ext it as a monkey patch until it makes it upstream?
<headius>
it is one of the last few files we merge in from our forked stdlib so I have no problem with ending that merge
<headius>
but the "optimized" logic now uses a regex to match absolute paths and I have had trouble coming up with an expression that will work for URIs
<headius>
if we can fix that jruby suite should go back to green on master
<enebo[m]>
heh...I imagine that is a much larger regexp than they are using
<headius>
yeah I tried to just use a smaller part of the W3C recommended URI regex but couldn't get matching to work the way I expected
Freaky has quit [Ping timeout: 240 seconds]
<headius>
enebo: where did you see NPEs?
<headius>
I don't see any new ones locally in a run of core specs without fails/hangs
<enebo[m]>
SecureRandom.random_number generates a random value in given (float) range limits ERRO
<enebo[m]>
in spec:ruby:fast
<enebo[m]>
2 of them
<headius>
ah a library spec
<headius>
ok I will look into it
<headius>
random_number is new so not surprising I missed some case
<enebo[m]>
both bignum things
<enebo[m]>
I wish CI output was structural in the sense it could output across runs and you could just 'diff' and get tests which changed
<enebo[m]>
One could maybe make a good regexp to generate just the F/E messages on spec/mspec I guess
<enebo[m]>
So long as you can predict order or properly sort
<enebo[m]>
in error output for our runs mspec seems to output in alpha order
<enebo[m]>
It is a strange usecase I guess
<headius>
it could output some structured format
<headius>
I think there is a json renderer
<enebo[m]>
XML or nothing!
<headius>
SGML and DSSSL bruh
<enebo[m]>
The ultimate CI would keep last result and show differences
<enebo[m]>
People will tell me I am crazy because you always run CI green but I think we have an interesting usecase where this would be nice
<enebo[m]>
Plus on more invasive branches I have broken lots of stuff to unbreak it all again
<enebo[m]>
I guess temporary flags could solve it for that too
<headius>
I think it's fine to have a red job or two in CI that shows what needs to be done, but having no green jobs in the critical areas just makes it too hard for me to track regressions
subbu has joined #jruby
Freaky has joined #jruby
<headius>
1)
<headius>
An exception occurred during: loading /Users/headius/projects/jruby/spec/ruby/language/regexp/escapes_spec.rb ERROR
<headius>
/\cJ+/.match("\n\n").to_a.should == ...
<headius>
SyntaxError: /Users/headius/projects/jruby/spec/ruby/language/regexp/escapes_spec.rb:70: (RegexpError) target of repeat operator is not specified: /+/
<headius>
enebo: this one can't be tagged because the file fails to load
<enebo[m]>
headius: yeah that was the weird one i mentioned. I will look into it quick since I need a break
<headius>
ok
<headius>
I have the tags in locally, just adding a rake target and CI job for WIP
<headius>
It's currently running as part of a matrix so it shows up alongside a bunch of other runs. I can make it its own top level job for more visibility perhaps
<enebo[m]>
I think so long as we know to look at it when reviewing PRs and educating people about it then it won't matter. We will look at this first as a canary
<enebo[m]>
At least knowing it is there is not a big problem for me to check it
<enebo[m]>
bisecting when we change signatures in JRubyMethod is longer
<headius>
Ha
<headius>
/home/runner/work/jruby/jruby/bin/jruby:7: syntax error, unexpected local variable or method (SyntaxError)
<headius>
^~~~~
<headius>
if command -v local >/dev/null; then
<headius>
I have pinged mrnoname about it
<enebo[m]>
I pushed fix for language issue
<headius>
a few dozen things are only failing on CI and I'm not sure why