<headius> kares: it could come back
<headius> Celluloid
<headius> lopex: great news... JVM is slowly adapting to JRuby
<headius> stringio, strscan, net-http, and io-wait gems have been released with JRuby support (non-pre gems)
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
<JasonRogers[m]> Thanks for sharing that lopex.
<headius> enebo: JRuby master can now install rails 7 and generate an app without any special gem flags
<headius> still using arjdbc 50 but if 70 is installed it will use that
<headius> it would be good to get 70 released for the base gem and the sqlite adapter
<enebo[m]> headius: yeah I was able to do it without database before you left but I guess it is good it can generate with 50...which is surprising
<headius> I don't think it uses the database for anything during generation of the app
<enebo[m]> I would guess it does very little with AR when first generating
<headius> or rather, doesn't use AR
<headius> yeah
<enebo[m]> So for arjdbc master I got rid of like half the errors on friday
<headius> it does choose 70 if it is already installed, and I assume if it were released it would do the same, but I'm not sure why it uses 50 instead of 60+
<enebo[m]> err only for sqlite3
<headius> nice
<enebo[m]> but it may be enough to actually use it
<enebo[m]> I fixed another kwargs bug this morning but I feel much better about it after doing it
<headius> it was enough to use it after my minimal patches... crud worked at that point
<headius> but maybe you mean actually use it
<enebo[m]> That stupid Time.now crazy mock thing is still outstanding as a big issue
<enebo[m]> Interestingly, it probably only affects testing Rails in anything directly observable
<enebo[m]> but not being able to test parts of Rails is a big issue in itself
<enebo[m]> I am pulling on a kwargs thread this afternoon because we still have some old logic in here and I want to make sure it is not being acted on
<enebo[m]> If it is then we likely are still missing something in the new design
<headius> did you put your example in an issue or anything?
<headius> last thing I see in here from you was "bleh all this is working"
<headius> I can try to look into it as time permits the next day or two
<headius> just point me in the right direction
<enebo[m]> no...but it is this:
<enebo[m]> system ~/work/gems/rails/activesupport (v7.0.2.4) * 4567% JRUBY_OPTS="-Xreify.classes -d -Xbacktrace.style=raw -X+C" jruby -w -I"lib" /home/enebo/work/jruby/lib/ruby/gems/shared/gems/rake-13.0.6/lib/rake/rake_test_loader.rb "test/cache/stores/file_store_test.rb"
<enebo[m]> It actually helps with something else too
<headius> wtf
<headius> reify?
<enebo[m]> ignore all the opts
<headius> heh ok
<enebo[m]> they were so I could see what was being called
<headius> so running that from activesupport head
<enebo[m]> from v.7.0.2.4
<enebo[m]> but it is in time_helpers.rb where it does the time_travel stuff where it aliases/undefs now on Time
<enebo[m]> Here is what I find weird...Time.now seeming is gone and this is doing a collection of alias_method/define_method/undef on Time.singleton...BUT...after this is messed up ::Time.now still works
<headius> ok I see your output
<headius> NameError: Undefined method __simple_stub__now for 'Time'
<headius> so it is some method delegation/redef issue
<enebo[m]> It is obviously because it is aliasing on a singleton_class
<enebo[m]> so the singleton class somehow is Time and then it loses now and then it cannot see Time itself has now
<enebo[m]> but I guess that may be a blessing since it appears to mess up all Time references everywhere after that
<headius> I see
<headius> yeah so it is aliasing on the metaclass not working somehow
<enebo[m]> If it worked then we would lose real Time and be indirecting through it
<headius> which is a singleton
<enebo[m]> I think so
<headius> ok
<enebo[m]> My original theory was something was exploding and it was not undoing stuff
<enebo[m]> but that does not really make sense because now would continue to exist and we would just see the same time forever more
<headius> do you know where the aliasing code is?
<enebo[m]> time_helpers.rb
<enebo[m]> because this is in AS and it is testing in AS it has its own small encapsulated code for this
<enebo[m]> It is called SimpleStubs
<enebo[m]> It having Simple in the name does describe a big part of this. It is all in a single file
<enebo[m]> It was almost made to be debugged
<enebo[m]> I am just not doing a good job so I punted and switched to something else for a while
<headius> stubbed_time = Time.now if simple_stubs.stubbing(Time, :now)
<headius> simple_stubs.stub_object(Time, :now) { at(now.to_i) }
<enebo[m]> yeah
<headius> ok
<enebo[m]> you are in the right place
<enebo[m]> If I inline everything that happens into a stream of actions it passes (that was what I pasted the other day)
<headius> object.singleton_class.alias_method new_name, method_name
<headius> object.define_singleton_method(method_name, &block)
<headius> yeah ok
<enebo[m]> I admit by the time I made it to that point I was already annoyed so I stopped at that point
<enebo[m]> Oh so I fixed sequel kwargs bug and active_model kwargs bug
<enebo[m]> sequel still fails but is because refinements added a method 'import_methods' or something like that and we have no impl yet
<headius> yeah and a naive allias works
<headius> ah sweet
<enebo[m]> It will copy ruby impls into the refinement
<enebo[m]> here is my fun thing of the moment. We should not need to frobnicate kwargs now but we were in prepareblockargs. This is only a result of ACP pass
<headius> ok
<headius> I will fix this time thing
<enebo[m]> So I am musing whether I can see this get hit propery using spec:ruby:fast:jit
<headius> hmm
<headius> it should
<headius> we jit blocks
<headius> if not you can always add a case to compiler specs
<enebo[m]> you would hope something will do it but will it do it with kwargs
<enebo[m]> -X-C should be able to test this but maybe we don't run that pass there
<headius> oh hey different topic... I was researching env shebang with mrnoname1000 and apparently linux fixed that dumb behavior in a late 2.6 update
<enebo[m]> bleh. only prepareForCompilation
<headius> with even 2.6 EOL at this point we could stop using env shebangs on linux if we want, which would align some path-finding behavior with CRuby
<enebo[m]> heh when was 2.6 EOL?
<headius> i.e. jruby's bin/ would not have to be in path because the scripts could use absolute path
<headius> like 2011
<headius> no 2016
<enebo[m]> hehehehehe
<headius> the change was in 2.6.27 from late 2008
<headius> 2.6.27.something
<enebo[m]> well 6ish years will hit someone but should we care?
<headius> doubtful because I would be surprised if current Java versions would even run on 2.6
<enebo[m]> I think if someone does update to 9.4 and on a system that old can they even run modern Java?
<headius> they would have to be running JRuby on a 2.6 kernel prior to 2009
<headius> so pretty unlikely
<enebo[m]> yeah so it would be on older Java but we are saying Java 9+ for 9.4 right
<enebo[m]> That is I guess maybe more than 6 years old
<headius> did we make that commitment? I thought 9.4 was going to be the last 8
<headius> JRuby X moving to 11+
<enebo[m]> yeah I am just thinking about dates but I think it is uncommon even without saying any of this
<headius> no value in 9
<headius> yeah
<headius> it would be one less diff from CRuby gem installs
<headius> not that we can share but it would eliminate bin PATH
<enebo[m]> oh yeah perhaps you are right. I thought we said 9 for 9.4 and 8 for 9.3 but I don't care
<headius> and env intermediate
<enebo[m]> I thought we were going to update because 9.3 is still new
<enebo[m]> headius: anyways my opinion on #!env thing is that it can get removed. If someone really needs this then they can just grab the old version out of our history
<headius> it's worth considering
<headius> but we don't have to
<enebo[m]> It is literally the launcher script
<enebo[m]> They can also install the native launcher
<headius> yes
<headius> most do
<headius> rbenv and rvm do
<headius> it was just a passing thought because I uncovered a bundler env shebang issue
<enebo[m]> I think it is ok since ~6 years since EOL. Multiple possible workarounds.
<enebo[m]> I like the idea of supporting things past the point most people would care but this is also simple to just edit the script and re-add the env
<enebo[m]> This is literally just about not annoying someone the first time they try to update something no an old platform
<enebo[m]> which we both figure is very few people
<headius> Right
subbu has quit [Ping timeout: 276 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]