<headius>
I am going to look at the last few blockers on my list for 9.3
<enebo[m]>
The last sentence I made in the comment on 6173 (case/when) is very interesting though
<enebo[m]>
Basically we build Array/List node as an array/list which means it will never end up being the all literal case
<enebo[m]>
but MRI now destructures the array into individual whens which allows when 1,2,3 to still be detected as only literals
<enebo[m]>
One issue with this strategy is that when not literals it causes both our interps to call eqq more
<enebo[m]>
err not more but more from witin the interp
<enebo[m]>
vs in a helper method in C/Java
<headius>
so the problem is that we are eagerly evaluating the list of conditions and then passing that out to a list-based eqq logic
<enebo[m]>
well the actual issue has nothing to do with list node
<headius>
but we should eval and eqq separately for each in the list
<enebo[m]>
the actual lazy issue reported is that they will not generically build an argspush but pass it to a special method which builds lhs and rhs in their own branches
<headius>
does this need to change in parser or just compiler? We could build the IR such that there are separate when conditions each with the same target
<enebo[m]>
although in theory a listnode could have the same issue
<enebo[m]>
it is just a builder issue
<enebo[m]>
it will just be more branches
<headius>
yeah
<headius>
can't really be avoided
<enebo[m]>
for the destructuring list part of this we could even do this more java-friendly and still pass as a list internally in cases where that would not cause problems
<headius>
ah right, as long as there's no side effect to evaluating a condition
<enebo[m]>
It is a little hairy though...like all constants...no problem leave as IRuubyObject[] internally but laziness in 2.6 may mean no resolution of things like autoload
<enebo[m]>
in any case the big benefit is people tend to put homogeneous data into whens so this may allow us to use literal-only case optimizations more often
<enebo[m]>
when it isn't the case more interp (which no biggy once JITd) and more code generated
<headius>
PR coming soon hopefully or we can fix it the way he describes
<headius>
I am triaging recent issues and then back to 9.3 for the rest of the week
<enebo[m]>
500ms cache?
<enebo[m]>
stat() is the source of all performance issues as I used to always joke but I wonder how that patch effects us on faster systems too
<headius>
yeah for sure
<headius>
also interesting that the cache is getting evacuated right away... we may want to audit other weak caches
<headius>
they may be doing nothing at all
<enebo[m]>
the other comment was interesting too about weakmap never having anything in it
<enebo[m]>
yeah
<enebo[m]>
we will halve startup time :)
<headius>
I wish
<headius>
it will help jruby-complete and other embedded use for sure though
<headius>
really wish we could find a good jar caching library to replace this stuff with
<enebo[m]>
I do remember years ago load resolution was 20-30% of startup but that was before rubygems and tough to measure
<headius>
jar filesystem logic basically
<enebo[m]>
oh yeah this was for jar but I started thinkg about it in terms of actual filesystem as well
<enebo[m]>
there is a lack of determinancy in time stamps and file system changes so I wonder if we could stat less in that case troo
<enebo[m]>
I have always wanted a user-based filesystem where all gems and lib/ruby lived where we could just re-index on anything changing and precalculate a lot of stuff
<enebo[m]>
so it would still be a file-based resolution but behave more like an image-based one
<headius>
yeah for sure
<headius>
99% of those files never change
<headius>
99.9
<enebo[m]>
yeah virtually no files ever change outside the actual project itself
<enebo[m]>
I had thought about the idea also of having a mode which assumes no gems or stdlib can change while running so we just precalc all that stuff
<enebo[m]>
if you need to debug by changing a line in an installed gem you disable the mode
<enebo[m]>
but I am not a fan of filesystem resolution. The utility of it is obvious but we all pay a pretty big time penalty for it
<headius>
ugh another problem with JAVA_HOME determination
<headius>
appears to affect the bash script too... the /usr/bin/java on MacOS is not a symlink so we can't traverse it to find the actual JDK dir
<headius>
it is a binary that launches whatever JDK is default for the system
<headius>
FML
<headius>
enebo: I think we will have to check some command output at least on MacOS to figure out if this is a module-enabled JDK level
<headius>
now I am sad
<enebo[m]>
HAHAH man that is disappointing but so Apple
<enebo[m]>
OTOH linux has alternatives which does work but is largely useless for us
<headius>
benefit of walled garden is that this will work on all MacOS... so I guess we need to modify the launcher to check for MacOS (or check for this command) and use that as home
<headius>
only if env is not set
<enebo[m]>
ok well so we will just roll this out whenever and people can manually set HOME until then
<enebo[m]>
JAVA_HOME that is...I hope we all have HOME set
<headius>
hah
<headius>
yeah the workaround is not that onerous
<headius>
funny we never saw this because I always use pickjdk which sets JAVA_HOME
<enebo[m]>
yeah our dev envs always are a little different just due to needing to switch jvms often
<headius>
right
<headius>
and who uses java without JAVA_HOME I mean come on seriously
<enebo[m]>
Some mac users
<headius>
pshaw
<enebo[m]>
just nedding it up
<headius>
I guess I'll just fix this while I am here
<headius>
similar change will be needed in launcher so I will look into that too 🙄
<byteit101[m]>
> looks like byteit101 identified a problem but not sure if any moves have been made to fix it
<byteit101[m]>
No moves, I wasn't sure how to fix. The super search algorithm was very confusing to me when implementing my changes, and I am surprised I got it working as much as I did
<byteit101[m]>
> and who uses java without JAVA_HOME I mean come on seriously
<byteit101[m]>
_raises hand_
<headius>
hah but you are on Linux no?
<headius>
it is mostly just annoying that MacOS does not set a default JAVA_HOME for the default JDK
<byteit101[m]>
yes, debian
<headius>
yeah on linux at least we can traverse the java symlink to find JDK
<byteit101[m]>
Probably a good idea to add a test for 6718 once fixed. easy enough with my minimal repro
<byteit101[m]>
6718
<headius>
for sure
<headius>
ahh it is a symlink but to another useless location
<headius>
basshelal: I can handle JRuby and others but if you want to go through the jnr projects that would be great
<headius>
I will look at your changes later and try to apply the same to non-JNR projects (I hate the current test output because it is useless on remote CI)
RobertNicholas[m has joined #jruby
<RobertNicholas[m>
you can always add `gem list` in after it installs them
<RobertNicholas[m>
the only thing I can think is the gems are being installed in a different ruby than the one it's using
<headius>
yeah I can't repro on a local ubuntu VM which should be pretty close to travis... it works fine
<headius>
commenting out those lines makes it work, but why would they affect anything
<headius>
there is no /usr/libexec/java_home on my u
<headius>
ubuntu env
<RobertNicholas[m>
I'd put `gem env` into the pipeline and `GEM_PATH=/home/travis/.gem/jruby/2.5.0:/home/travis/build/jruby/jruby/lib/ruby/gems/shared gem list`
<RobertNicholas[m>
more than likely the gems are being installed in a system ruby instead of at `/home/travis/.gem/jruby/2.5.0:/home/travis/build/jruby/jruby/lib/ruby/gems/shared`
<headius>
it's not a bad theory, I just don't know how my patch could cause that
<headius>
UGH ok maybe it was a travis problem
<headius>
it is green with latest push
<headius>
enebo: TRAVIS
<RobertNicholas[m>
switch to gitlab 😆
<headius>
we need to get off travis... this happens almost weekly
<headius>
unexplainable failures
<RobertNicholas[m>
gitlab is super easy to setup
<RobertNicholas[m>
moved all our stuff to it 6 months ago and have never looked back, just wish the company I work for would do the same 🤣
enebo[m] has joined #jruby
lopex[m] has joined #jruby
kai[m]1 has joined #jruby
enick_654 has joined #jruby
MatrixTravelerbo has joined #jruby
XavierNoriaGitte has joined #jruby
edipofederle[m] has joined #jruby
CharlesOliverNut has joined #jruby
UweKuboschGitter has joined #jruby
ahorek[m] has joined #jruby
JesseChavezGitte has joined #jruby
OlleJonssonGitte has joined #jruby
MarcinMielyskiGi has joined #jruby
fzakaria[m] has joined #jruby
JulesIvanicGitte has joined #jruby
KarolBucekGitter has joined #jruby
basshelal[m] has joined #jruby
FlorianDoubletGi has joined #jruby
TimGitter[m] has joined #jruby
dan64[m] has joined #jruby
<headius>
yeah moving away from github is probably not feasible right now but I should start doing my other projects at gitlab
kares[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
BlaneDabneyGitte has joined #jruby
ChrisSeatonGitte has joined #jruby
byteit101[m] has joined #jruby
TimGitter[m]1 has joined #jruby
MattPattersonGit has joined #jruby
RomainManni-Buca has joined #jruby
kalenp[m] has joined #jruby
mattpatt[m] has joined #jruby
Hao[m] has joined #jruby
olleolleolle[m] has joined #jruby
onghu[m] has joined #jruby
TestAccount[m] has joined #jruby
donv[m] has joined #jruby
rtyler[m] has joined #jruby
worldnamer[m] has joined #jruby
mrtommy[m] has joined #jruby
<RobertNicholas[m>
you can always mirror the repository, though I suppose for outsiders working on jruby that might complicate things
<RobertNicholas[m>
but whatever you do don't use github actions, if you think travis is bad 😆
<headius>
why do you say that?
<headius>
we have used some GHA so far and it is at least more reliable than Travis
<RobertNicholas[m>
we use it heavily at work, have had 6 outages (longer than an hour) in the past 2 months, it doesn't have a way to add non-secret values to your projects as variables, you can't modify secrets after they've been created, having proper manual triggered pipelines is hidden behind a only half working beta feature. You can self-host their runners but the runners don't work when actions goes down anyway, there's a ton more lmao
<headius>
hmm yeah that does sound unpleasant
<headius>
ok well I merged in the fix for jruby.bash and pushed a new jruby-launcher gem with that fix