yosafbridge has quit [Quit: Leaving]
yosafbridge has joined #jruby
aquijoule__ has quit [Remote host closed the connection]
aquijoule__ has joined #jruby
DrBob has quit [Quit: Textual IRC Client: www.textualapp.com]
<headius> enebo: I am baffled by this behavior in Kernel.autoload
<headius> both of those should print "time" because the autoload gets defined on that anonymous class
<headius> but as far as I can tell autoload is using cref, which should be Object because this is a block at toplevel
<headius> in fact, if you try to access the `Time` constant inside that method, it **will** get you the top-level ::Time class
<headius> but the autoload goes on the anon class's constant table somehow
<enebo[m]> I am just about to start to eat lunch but this reminds me of people doing module cloning for some reason
<headius> I was wondering if we are supposed to be forcing that class to be the cref class (in the StaticScope) but if I changed it then the Time constant would not see Object like it should
<headius> it is like this is not possible to support but I am clearly missing something
<enebo[m]> yeah after I finish eating I will look up what I am trying to remember
<headius> ok
<enebo[m]> it has something to do with Module.new and behaving like a cref when it isn't...I think we have some excludes/tags on something like that
<headius> this is a regression spec that started failing when I started using cref class only for Kernel.autoload
<headius> but MRI uses cref only
<headius> I will keep looking around
drbobbeaty has joined #jruby
<enebo[m]> headius: I cannot find what I was looking for but
<enebo[m]> jruby -v ../snippets/clone1.rb
<enebo[m]> jruby 9.3.0.0-SNAPSHOT (2.6.5) 2021-07-06 bf7bbf324e OpenJDK 64-Bit Server VM 25.242-b08 on 1.8.0_242-b08 +jit [linux-x86_64]
<enebo[m]> "time"
<enebo[m]> "time"
<enebo[m]> ignore the name this is the snippet you are using above
<headius> Yeah this broke on my pr
<headius> enebo PR removes using the frame class because
<headius> CRuby only uses cref so I made ours use scope module
<enebo[m]> oh I see
<enebo[m]> sorry I was trying to find a report where people were doing module.clone() and then setting different values. It is foggy but I thought the issue was MRI was cloning and making a new cref for the clone
<enebo[m]> Maybe I can see evidence in module.clone in MRI source
<enebo[m]> maybe rb_single_class_clone_and_attach
<enebo[m]> This is constant table and not cref
<enebo[m]> This is not what I am looking for but for a module with an autoload it seems you would autoload twice here
<enebo[m]> although not if they shared same cref
<enebo[m]> which I guess is where you are stuckl
<headius> It is just a Class.new though
<headius> Yeah you see my conundrum
<enebo[m]> yeah I am just trying to see something odd but I do think they may be a case they dup static scope equiv
<headius> Const lookup needs to go to Object but autoload goes to that anon class
<headius> So I am missing something about how they each get the target module
<headius> The frame does have the right place but I can't use both
<headius> I think this worked previously because it always used Object's singleton class
<headius> So it looked like it worked but was not on the right module
<enebo[m]> looking for cref in MRI so far I only see clone_method making new ones
<headius> Look at rb_f_autoload for the Kernel impl
<headius> load.c
<enebo[m]> VALUE klass = rb_class_real(rb_vm_cbase());
<enebo[m]> hmm
<enebo[m]> so I notive autoload_p just uses rb_vm_cbase
<enebo[m]> but actual autoload() will get the rb_class_real of that
<headius> Yeah I don't know why
<headius> Probably because it searched up hierarchy
<headius> I made us match and then this other case broke
<headius> if my logic for autoload is right then the problem might be in Class.new handling
<headius> I just don't see how constants would go to one place and autoload with cbase/cref would go to another
<enebo[m]> I am confused by that difference
<enebo[m]> So for the actual autoload it goes potentially to some place different to store the constant than when it just sees if it is defined I guess
<headius> yes
<headius> I confirmed that assigning a constant in that method (via eval) also goes to Object, not to the anon class
<headius> but autoloads go to the anon class
<headius> 🤷‍♂️
<enebo[m]> HAH
<enebo[m]> I really don't get this..now unless .new { } somehow gets really funky
<enebo[m]> which is why I was looking there originally
<headius> yeah I looked at that a bit but I couldn't figure out how it would affect the method, which will have its own frame and scope
<enebo[m]> we see autoload_p uses same method
<headius> and as far as I know we are doing that right
<enebo[m]> err same c call
<enebo[m]> rb_vm_cbase is perhaps doing something weird here and not just hitting cref
<headius> possibly yes
<headius> I don't quite know all of the CRuby frame internals but it looked like it just goes to current frame and gets the cref
<enebo[m]> const rb_control_frame_t *cfp = rb_vm_get_ruby_level_next_cfp(ec, ec->cfp);
<enebo[m]> so execution context perhaps is different within class/module.new block
<headius> I just don't see how it could be different target for autoload and constant lookup within the body
<headius> they are looking for the target differently but I don't see how
<enebo[m]> yeah but I am working backwards from the premise they are based on the c method seemingly just calling the same thing so I figure it must be giving a diferent result
<headius> constant lookup is buried in the bowels of yarv so I am looking for that
<enebo[m]> yeah that is probably a better path than looking at autoload_p
<headius> hmm maybe I will ask for help in ruby-core slack
<headius> only this one regression spec regressed so this is clearly not tested well... may be undoc behavior or even a bug
<headius> I posted something on slack about this
<headius> this appears to have changed around 1.9
<headius> 1.8.7 behaves like we do on my PR