<ldywicki[m]>
Had to hang dockcross and ci/cd stuff, got a bunch of support calls last few days which will keep me busy till weekend.
<headius>
No worries, it's not a critical need right now, take care of your own stuff and we appreciate whatever you can do
<headius>
enebo: almost no pushback on Twitter against dropping 8
<headius>
Closest was a legacy app but it probably won't upgrade from 9.3 anytime either
<enebo[m]>
yeah twitter does not really count
<enebo[m]>
but I tend to agree most people will not care
<enebo[m]>
I think they notion of people keeping up on tech but needing to stick with Java 8 on their sutff is going to be a smaller venn overlap
<enebo[m]>
So I guess I don't really have a good sense on how to actually figure out. Java deployment survey/reports might help but even those do not tend to pick up small back-office stats as much as cloud deploys
<enebo[m]>
headius: one takeway from yesterdays conversation is our ergnomics is worth examine more
<headius>
Oh yeah I will catch up
<headius>
What was it you wanted from Java 9?
<enebo[m]>
well as it turns out I just used MBean data for it but the original answers made me realize a lot of stuff we work around is just in Java now. We just need to update to get those benefits
<headius>
Yeah
<enebo[m]>
I have traditionally been much more conservative on updating Java but I think we have waited a long time no leaving 8 behind
<headius>
Upgrading before we release means we can start taking advantage of those improvements during the 9.4 maintenance cycle
<headius>
If we don't upgrade beforehand we can't really put any of that stuff in until 9.5, or we have to do complicated version specific code
<enebo[m]>
That AddOpens.java is worth looking at above
<enebo[m]>
yeah exactly
<enebo[m]>
I just changed forward = true to keywords = true based on a coversation we had a couple of weeks ago
<headius>
Free hand to start leveraging 11+ feature on the way to a big tech improvement in 9.5
<headius>
Ok makes sense
<enebo[m]>
I am also going to add some convenience methods I put off. I actually wanted our current system to be a bit painful to nudge us to a new system but a couple of methods won't really make this much less painful :)
joast has joined #jruby
<headius>
Good Lord yubikey is hard to set up under Linux
<enebo[m]>
Taking a shot as Process::Status#wait
<enebo[m]>
I got a number of 3.1 features done yesterday
<enebo[m]>
I plan on unit testing Rails this afternoon to find issues
<headius>
ok I'm bagging this for now and I'll just deploy from MBP I haven't sent back yet
<headius>
73 open issues and PRs
<headius>
I find it very hard to believe that AddOpens could work within a modularized app
<headius>
you will not be able to access those private methods without opening java.lang to JRuby, which I guess is an option...
<headius>
it could potentially be something we allow in a debug setting to handle the case of being deep into IRB and unable to proceed
<headius>
of course you could put --add-opens java.base:java.lang=org.jruby.dist in .jruby.java_opts and always have that option available 😄
<headius>
something in one of the maven plugins does not work right under 11
<headius>
hmm there's a much newer one
<headius>
no dice
<enebo[m]>
yeah we still have other things to do before release so any issues we should just bail
<headius>
Caused by: org.jruby.embed.EvalFailedException: (OpenSSL::X509::StoreError) setting default path failed: No password supplied for PKCS#12 KeyStore.
<headius>
so here's status then
<headius>
Java 11 does appear to be able to build us fine for a local dist, but not for full release without changes
<headius>
my workaround for jruby-core javadoc was to skip it, which is fine because the docs should be in jruby-base already
<headius>
oh I also access a class from backport9 for Java 8-style stack walking but it is not exported, so that requires a backport9 release
<headius>
and the java 11 build pkey store thing I believe I have an issue filed about... I think it is due to using an older JRuby as part of the build, so that would need to be upgraded in the relevant plugins
<headius>
that's as far as I can get
<headius>
I kinda put 11 build and modularity work on the back burner when we decided we weren't going to drop 8
<enebo[m]>
yeah well it is maybe a better .next thing when the whole project is records and kotlin
<headius>
haha
<headius>
KRuby
<headius>
ok, priorities
<headius>
transpiled to JavaScript and running on V8
<headius>
having looked through issues there are not a ton of them that are critical to this release now
<headius>
I can do a better review but do you have some items in mind that I should deal with?
<headius>
lots of wishes
<headius>
we are kind of down to wishes and fishes
<enebo[m]>
At this point I have just been knocking down failing specs/tests
<headius>
with fishes being features
<enebo[m]>
I did definitely focus on features recently
<enebo[m]>
I think refinements and prepend are two of note for 3.1 which you may have addressed part of with your landing
<headius>
I can check on the refinement part
<enebo[m]>
fiber stuff is lurking especially with io scheduler
<headius>
the prepend thing should be resolved with PR merged today
<headius>
IO scheduler is definitely a 9.4.1
<enebo[m]>
Not sure how much it will matter but we need to at least noop if like puma is using it
<headius>
but all code that uses it does respond_to? with a fallback so far
<enebo[m]>
ok yeah that makes sense
<enebo[m]>
we are probably covered
<headius>
it needs to come and it will make some things better (back to a native timeout, for example) but it is just a lot of fiddly work
<headius>
adding callbacks all over
<enebo[m]>
I did find another kwargs bug with super I need to fix but I think we are mostly just squashing new APIs and addressing things we find which are broken
<enebo[m]>
I am hoping not much will turn out with Rails unit tests but it will be a good test
<headius>
"The flip-flop syntax deprecation is reverted."
<enebo[m]>
I need to hit up some ripper-based libraries this week too
<enebo[m]>
hahahah
<headius>
done: Refinements take place at Object#method and Module#instance_method.
<headius>
I went through test_refinement WIP excludes and knocked a few extras off in that PR
<headius>
there's some weird shit though
<headius>
pardon my french
<enebo[m]>
oh so another thing I did is I went through all of benoit's last spec tags with attention to any 3.x fails
<enebo[m]>
He has does a few syncs since spec had wip: so we should go back in history and examine those syncs
<enebo[m]>
About 90% were 3+ fails so I think that will be true for a few other commits
<enebo[m]>
The work for this is to build up a lhs/rhs set of nodes and/or operands (depending on what) and then emitting them but you don't want to bother unless it matters
<enebo[m]>
I do have it partially written but it is a little weirder than I thought since lhs can have nested lhs masgns which all have to eval before rhs which will just be a single rhs
subbu has quit [Ping timeout: 255 seconds]
<headius>
warning stuff is merged and 2.7 is done except for flip-flop and some unresolved stdlib exts
<enebo[m]>
FFF is an acronym for something involving flip flips
<headius>
yeah 3.0 and 3.1 are pretty much done now too other than ractor and scheduler stuff
<headius>
ok I created four total issues for features that stood out to me
<headius>
enebo: unsure if you saw this but getting the 7.0 arjdbc gems out would make it a fully stock process generating a new app
<headius>
can be deferred until closer to RC since there's a workaround to get the pre gems
<enebo[m]>
I can do that tomorrow I guess. I want to run unit tests first to make sure nothing huge
<enebo[m]>
pre works enough for scaffolding so that is good
<headius>
yeah
<headius>
production CRUD works
<enebo[m]>
with sqlite3
<enebo[m]>
so probably we need to try out pg
<headius>
what you wanted a real database?
<enebo[m]>
hahah yeah I only did sqlite3 as well
<enebo[m]>
I thought "ship it"
<headius>
sqlite is all anyone needs
<headius>
heh ten clients isn't enough to redline this machine
<enebo[m]>
lopex: you see netflix kleo? Or even have that option?
<lopex[m]>
but at times they hade the most powerful comouters
<lopex[m]>
no I dont
<lopex[m]>
and havent
<enebo[m]>
quirky german show about east german assassin
<enebo[m]>
There is also a polish series: krakowskie potwory
<enebo[m]>
unrelated to soviet union but I just remembered you were polish :)
<headius>
do people still use mysql
<headius>
I feel like I ask that once a year
<lopex[m]>
but hah, did you know that at the times we were in soviet "influence sphere" - that's how it was called, there was a propaganda that US was dropping potato beetle on our fields
<enebo[m]>
little did you realize...
<lopex[m]>
hah
<enebo[m]>
why can I never remember the empty IRubyObject array
<lopex[m]>
EMPTY_ARRAY ?
<headius>
brain tumor
<headius>
we have a lot of constants I forget about and sometimes add again
<enebo[m]>
I see 3 of those and none are the right one?
<lopex[m]>
haha
<lopex[m]>
like string/array constructor proliferation
<lopex[m]>
etc
<lopex[m]>
we shuld use spring
<enebo[m]>
NULL_ARRAY
<lopex[m]>
ah
<lopex[m]>
oh well makes sense since most likely it comes from mri
<enebo[m]>
We should have called is p
<enebo[m]>
p
<lopex[m]>
is/it ?
<enebo[m]>
it
<lopex[m]>
jeeze why is go so popular
<lopex[m]>
I hate it
<enebo[m]>
"it is simple" is what I hear
<lopex[m]>
basic is simple as well
<enebo[m]>
someone I know complains about go a fair amount so I am pretty amused by Go hate
<enebo[m]>
Every time I look at Go I feel like it was written by someone 25 years ago as a modern language
<enebo[m]>
but having said that I don't really care. If people like it that is fine by me
<lopex[m]>
well, yeah
<lopex[m]>
actually, the next native language I'd like to learn wuld be something like zig
<enebo[m]>
it compiles fast
<lopex[m]>
go ? yeah, it's sold sa such
<enebo[m]>
zig does
<lopex[m]>
it does
<lopex[m]>
I guess julia was quite interesting on the rise of ml bubble
<lopex[m]>
and then nim maybe
<enebo[m]>
Actually I think I was think of V as the super fast compiler
<enebo[m]>
but zig is not slow at compilation and compared to Rust it is amazing
<headius>
enebo: your arity message errors broke some green suites
<headius>
actually most of them
<headius>
I thought it was my encoding changes but maybe not
<enebo[m]>
ah I only ran spec:ruby:fast thinking it would hit enough
<headius>
that also failed though
<enebo[m]>
yeah how could this all fail?
<enebo[m]>
I will revert
<headius>
yeah weird errors
<enebo[m]>
yeah super weird
<enebo[m]>
how could this actually break anything
<enebo[m]>
HAHAHA I see it
<enebo[m]>
I named it instance_eval as a Java method
<headius>
oh nice
<enebo[m]>
I may have been a bit sloppy here and only tested the first commit which was for instance_eval
<enebo[m]>
It was the exact same fix to a different signature. ok well a little fast and loose
<enebo[m]>
just verifying it quick
<headius>
I forgive you
<enebo[m]>
lol
<enebo[m]>
so I looked at settracepoint stuff a little bit...ugh
<headius>
heheh
<enebo[m]>
I did do some work on it already but that is pretty granular now
<enebo[m]>
enable(line: 20)
<headius>
all the tracepoint stuff we are behind on?
<headius>
like branches and stuff
<enebo[m]>
yeah. we do all ruby stuff for the basics but they added a lot of extra options like specifying hwich thread
<headius>
ah yeah
<enebo[m]>
branches can get supported but I just made it for the resume/suspend feature
<enebo[m]>
just realized enable has 3 keywords now
<enebo[m]>
we are not emitting for native calls which makes omse of these tests weird
<enebo[m]>
they expect to see tracepoint methods themselves in the results
<headius>
I cancelled the current CI runs
<enebo[m]>
ok
<enebo[m]>
I will let one local spec;ruby:fast complete but this was definitely the issue
<enebo[m]>
I should not have even bothered to fix this but I was annoyed that what MRI wants is not really even reasonable
<enebo[m]>
1..3 for eval which can be 0 with a block
<enebo[m]>
0..3 seems more correct
<headius>
ah yeah I agree
<enebo[m]>
so this is a dummy method definition just to correctly report when you provide too many args
<enebo[m]>
I mostly did it just to figure out how to do it
<headius>
so they just skip the arity check altogether if there's a block
<enebo[m]>
contort our anno logic to my will
<headius>
or warn about unused args
<enebo[m]>
if no block it is one arity but that isn't even true. for no args it still prints 1..3 :)
<enebo[m]>
I am annoyed that ruby/spec even went down this rabbit hole...why are we comparing error strings
<headius>
yeah I liked it better when it did not
<enebo[m]>
MRI also seemed to have changed all the methods on type coversion errors
<headius>
they can only cram so much information into their rb_scan_args descriptors
<enebo[m]>
or many of them
<headius>
oh like quoting differently?
<enebo[m]>
just a different message
<headius>
courage
<enebo[m]>
in many cases the error messages in MRI have evolved to have more info which I welcome
<enebo[m]>
but some are just rearranging and using slightly different words
<headius>
hopslam is early this year
<enebo[m]>
I suppose at some point that will just stop
<enebo[m]>
hmm. I would drink one can of that
<enebo[m]>
honey is not my jam
<headius>
jam is not my jelly
<enebo[m]>
yeah
<headius>
ok well I have a few things to do... get M1 builds working (env issue), the big features I pulled out into bugs, see how far off we are on mysql and pg for testapp
<headius>
gonna break for a bit and bbl
<enebo[m]>
yeah until tomorrow for me but I plan on testing rails tomrrow and if good I will likely release 70 arjdbc stuff