<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
<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)
<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