<headius>
it's also possible for a user to just edit the RubyGems defaults and put the env-shebang option back again
<headius>
well that was interesting chasing my tail for the last three hours
<headius>
there was an issue with rubygems/bundler in 3.3.3 where it would install on-demand an older bundler to match the Gemfile.lock, but it installed the bundle script without the proper shebang (which is what made me look into shebangs yesterday). I filed a bug but then when I attempted to reproduce with lastest RG it appears to have been fixed. Master is updated to RG/B 3.3.13
<headius>
the other thing you may see on master is that there's an unversioned, unignored lib/ruby/stdlib/jruby/strscan.rb. This comes from the strscan default gem and is a duplicate of the file that's copied to lib/ruby/stdlib, due to the gem now having two require paths that are nested. I have pushed a PR for strscan that will fix it eventually, but for now it is just an annoying unversioned file present after the build
<headius>
I'm going to add that file to .gitignore just so we don't accidentally version it
<headius>
oy vey finally can work on what I intended to work on
<headius>
NoMethodError: undefined method `now' for Time:Class
<headius>
this Time stubbing thing may be a combination of two different ways to stub
<headius>
there's an ordering thing too
<headius>
it's doing stubbing using Time.stub and the stub_object thing
<headius>
I can see why this is frustrating... I keep trying to remove tests from this file and then the problem disappears
<headius>
ok starting to get a picture here
<headius>
undef_method does not just remove the method, it installs an UndefinedMethod entry
<headius>
I am guessing that with some sequence of these operations that the undefined method gets installed as Time.now
<headius>
well that is definitely happening
<headius>
that's all I've got for today... I can confirm that there's an undefined method entry getting put in place for Time.now, probably in the teardown of minitest/mock.rb:241, but I'm not sure how that undefined is getting in here because it should be the newer stub method at that point
<headius>
I found that there's some refinement logic missing from undef_method but porting that did not seem to help so far
<headius>
I think doing a review of undef_method and alias_method to see what has changed might help narrow this down
<headius>
battery low, shut down
subbu has joined #jruby
subbu has quit [Ping timeout: 246 seconds]
<enebo[m]>
headius: cool. The new piece of info for me is UndefinedMethod is at now. peculiar
<headius>
Yeah I have no evidence that refinements are involved btw
<headius>
Just noticed that section missing from undef
<enebo[m]>
headius: are you back in MN?
<enebo[m]>
headius: At the end of yesterday I circled back to the last fialure in spec:compiler. It only happens loading a complicated splat/masgn when loading it from IR persistence. The IR it interprets when printed out is identical. When inspecting the result value shit is weird.
<enebo[m]>
identical to --dev
<enebo[m]>
and weird compared to result value from --dev
subbu has joined #jruby
<headius>
Not back until some time Thursday but I got a good 7 hours in today and will work on the bus to Oslo tomorrow and the flight home Thursday
<headius>
Does it fail in a standalone script?
<headius>
With jit forced and logging it should be similar
<enebo[m]>
-X+C, -X-C, --dev as main script all seem to inspect the same array
<enebo[m]>
loading persisted IR shows same instrs but the Array result is weird. This can only be seen in code which loads it in spec:compiler or using -Xir.writing then -Xir.reading
<enebo[m]>
So something with persistence loading is causing what appears to be identical instrs to build the array weirdly
<enebo[m]>
The 4th element of result is a nested array and in all other modes it ends up as 2-elt shaped entry but in IR loaded one it is 5 element generic which then contains another 3 element generic one
<headius>
Ok well I can look at that too depending on what you fix today
<enebo[m]>
I am still looking and honestly it is not too critical in next week but I made progress and it is baffling. If something is not dup'ing which should be then it is possible all other modes are just getting lucky somehow
<enebo[m]>
The wacky element is that nested 5 element array which should be a 2-shape have a begin of 6
<enebo[m]>
which would imply it is grabbing off an 12 element array
<enebo[m]>
s/grabbing/sharing
<enebo[m]>
weirdly the parameters supplied happen to be from 1-12 (which is 11 total) and they are not in a contiguous array but it is strange to see it somehow correspond to last element value in the call: 12
<enebo[m]>
I have someone coming out to look at something on our house in a bit so I will likely pick this up after lunch but I am going to step debug the ir.reading version just to see what is up. yesterday I got to this weird place where I saw the same instrs but a different result and just assumed it would become clear :)
<headius>
Yeah huh
<headius>
Well I'll keep it in mind
<headius>
Compiler specs green would be another good milestone
<enebo[m]>
It is always the same index and wrong so I assume we somehow are just making a bogus array somehow
<enebo[m]>
final fall out from changing all those receive instrs to be super.encode friendly. Ultimately that change broke this but should eliminate other errors in the future when we decide to tweak these instrs
<headius>
Aha
<enebo[m]>
I am annoyed. I printed out instrs and did a diff and nothing was different
<headius>
So it was in the instr construction?
<enebo[m]>
It should have printed out this difference
<enebo[m]>
So I think I must have accidentally ran both in same mode and then saved the same output twice
<enebo[m]>
it would encode the persisted data in one order and read back in with the last two parms switched
<enebo[m]>
In a sense it is lucky that they were both the same type or it would have crashed
<enebo[m]>
This is one case where I think it is a shame there are not formal aliased types
<enebo[m]>
alias int argIndexInt and then just liberally assigning common types to have specialized values would prevent errors like this
<enebo[m]>
Java can encapsulate an int and enforce this but no one would ever bother being that heavy-handed
drbobbeaty_ has quit [Ping timeout: 260 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<headius>
bugger... it would be best if we could get the timeout gem to incorporate our java logic but I hate to add an ext to a gem that has no ext