<enebo[m]>
Rails 6 always ran into the sassc thing
<enebo[m]>
headius: can you commit that. I have a commit already for version change and I will just rebase over that
<headius>
Wow rails 7 on windows
<headius>
Yeah will do
<headius>
pushed
<enebo[m]>
I think we are ok as far as the typical sort of testing goes. I think it is a bonus we also run on an earlier version of Rails and not a bug we throw :)
<headius>
very nice
<enebo[m]>
I have no illusion we will have ample evidence of .1 coming by tomorrow but we can only test what we can test
<headius>
yeah ship it
<enebo[m]>
I think we do resist a .1 until after Rubyconf unless it is horrifically bad
<enebo[m]>
ok I will respin and verify that works on windows
<enebo[m]>
It is possible something else is wrong when run from there
<headius>
of course there's a large class of bugs we won't see until people start trying it, so I think we're fine putting out what we have
<headius>
it works on our verifications and we have continued to improve while working on new features
<enebo[m]>
jirb_swing works on windows
<enebo[m]>
I am going to push gem and release on maven
<headius>
hot crackers
<enebo[m]>
headius: did I dream this but I think you wrote up notes a couple of weeks ago?
<headius>
I wrote up notes for 9.3.9 a couple of weeks ago
<headius>
don't believe I have started anything for 9.4
<enebo[m]>
yeah I do remember that so I think I probably just remembered that twice :)
<headius>
we need to change around the version text and stuff... I will start putting together notes but I'm mostly going to just list the gem versions at release, have a bullet for compat upgrade to 3.1 with caveats (scheduler, ractor, etc), and then maybe scan issues and PRs for anything special work calling out
<headius>
we have not that many issues because we have put most issues into 9.3 over the past year
<enebo[m]>
I think this set of notes will just be about updating compatibility
<enebo[m]>
actual things fixed maybe is not even worth doing specific issues
<enebo[m]>
we have gazillions of development PRs which do not really help anyone
<headius>
yeah
<headius>
exactly
<enebo[m]>
So what we broadly support what we decided not to and what we plan on
<enebo[m]>
I decided to leave all punctuation of that sentence for the challenge
<headius>
ok there's too many gems, I'm just going to link to the lib/pom.rb
<enebo[m]>
yeah honestly I don't think even that level of detail is too importat as we mostly are trying to ship same gems as 3.1. Of course we know we have a lot of open issues there but I think from a consumption perspective they will use what we have
<headius>
punted remaining Rails 7 bullets to a 9.4.1 issue
<enebo[m]>
headius: going to break for a short lunch
<enebo[m]>
probably ~15-20 minutes
<headius>
notes are done for now, let me know if you think we need anything else
<headius>
we can collab on the general text about 9.4 but I assume it will be similar to 9.3 (intended to be compatible with 3.1, updates will continue to fix and improve, etc)
<headius>
tweet is ready to go
<headius>
let me know when you are back and we can finalize, I'm going to have some quick lunch too
<headius>
I want to say something about being the first alternative Ruby with full support for Ruby 3.1 language features, not sure if that is for notes or tweets or a blog post
<enebo[m]>
just making some coffee now
<enebo[m]>
headius: back
<headius>
Yo
<enebo[m]>
headius: perhaps we should reference the execution order issue and say it is not done
<enebo[m]>
it is quite uncommon for anyone to hit it but it is a language feature which is not completed
<headius>
Call it out in a separate bullet?
<enebo[m]>
maybe since we have an issue for it
<enebo[m]>
Also you say mysql is not working did you try it?
<enebo[m]>
we have .pre for it so I thought it was in some form of working
<enebo[m]>
It is difficult to see what the state is when they delete the logs
<enebo[m]>
but I am guessing mysql must have been mostly passing tests when I put 70.pre of it
<enebo[m]>
I did not explicitly put out postgresql
<headius>
Ah good point about mysql
<enebo[m]>
I just don't remember any of this
<headius>
Oh right, there's a 70.0 for it?
<headius>
Pre
<enebo[m]>
yeah for sqlitre3 and mysql but not postgresql
<headius>
well mysql would be better for my talk at least
<enebo[m]>
once this is done I am going to figure out if I can make our test runs a bit more green there
<enebo[m]>
Try it out this afternoon. If something is wrong then it can also be tacked onto the priority list
<headius>
yeah I am pulling mysql in docker now
<enebo[m]>
Interesting that for 6.1 (last thing run) our only real failures is something with serializing Ruby objects using the db somehow
<enebo[m]>
At some previous point those were totally green so that looks like it could be new tests
<enebo[m]>
I half feel like doing a bump commit of something trivial just to see how 70 is
<headius>
in CI?
<enebo[m]>
I just merge 61-stable to master (70) which will update the sqlite3 commit which will do a CI run
<headius>
nice
<headius>
ok
<enebo[m]>
they only keep CI logs so long
<enebo[m]>
So let's see if mysql looks ok or horrible
<headius>
Rails 7 just came out this fall, right?
<enebo[m]>
I remember mysql and sqlite3 being ok but postgresql not working at all
<enebo[m]>
? I don't remember
<enebo[m]>
but this pre was 7 months ago
<enebo[m]>
So maybe last fall
<enebo[m]>
or this spring
<enebo[m]>
yikes something really bad with mysql but I think it may be configuration
<enebo[m]>
ActiveRecord::AdapterNotSpecified: The default_env database is not configured for the default_env environment.
<headius>
I am seeing alias_method_chain error again for some reason
<headius>
trying to figure out if it is my env
<headius>
you ran rails 7 just a bit ago right?
<enebo[m]>
this is CI for arjdbc
<enebo[m]>
It appears whatever was making the databases in mysql is not there perhaps
<headius>
so I can say mysql is working in notes
<enebo[m]>
I have not tried it so I don't know that but I cannot see how I could have released with it looking like this in CI
<enebo[m]>
Seems like something changed
<headius>
I can change the notes any time
<headius>
trying to test it here myself
<enebo[m]>
err I just realized I was not looking at real AR tests but the copied local ones
<headius>
ugh what is up with my env, I am getting that jzlib Java 9 classfile thing on openjdk 8 now
<headius>
which could never have gotten through CI
<enebo[m]>
ok. so tons of errors with sqlite3 tests too :)
<enebo[m]>
but we know the basics of it works so if you can get mysql right then perhaps it will also work
<headius>
some of that might be small global changes to data types etc?
<headius>
not that we shouldn't fix but they may be common small changes across all adapters
<enebo[m]>
fwiw a large number is a kwargs thing but I think it is us calling a Ruby method from Java and it should use kwargs and not hash
<headius>
oh I see
<enebo[m]>
which is not a problem with JRuby but with ARjdbc
<headius>
interesting
<enebo[m]>
it appears to be the case in one trace but I could also see generic ruby issues where we do foo(something, options) and not something, **options as well
<headius>
I am having trouble on Java 8, did you verify with 8?
<enebo[m]>
We push forward and I will first hack on sqlite3 just to kill those simple kwargs errors then move to mysql
<headius>
too late now but I don't understand what's happening here
<enebo[m]>
I use 8 to build and test
<headius>
we run 8 on many jobs
<headius>
so this has to be my env
<headius>
oh snap I know
<enebo[m]>
openjdk version "1.8.0_242"
<enebo[m]>
java -version
<enebo[m]>
I wonder if something is pulling that independently somewhere
<headius>
I was mucking around with modules and jzlib doesn't have a descriptor so I made a module version in a fork
<headius>
compiled with 9
<headius>
it is still in my repo
<headius>
so that openj9 problem was also my fault... I can look into the CI failure now yay
<enebo[m]>
so can you explain this? something with 9 got committed somewhere but is only loaded some times?
<headius>
I guess I should rehome that on org.jruby if I'm going to fork it
<headius>
I was trying to get modularity working, and jzlib has no module descriptor, so I made a fork of it that adds the descriptor and built a local copy for testing
<headius>
using Java 9ish
<headius>
so it is just a stale dev jar in my local m2 repo
<enebo[m]>
so we were not also seeing this in the CI j9 job
<headius>
right
<enebo[m]>
ok. That was my confusion. I did not realize this was only your env
<headius>
different issue showing in the CI job but I couldn't get to it because of this (I only tried openj9 Java 8
<enebo[m]>
yeah
<headius>
yeah deleted the crud and I'm fine, whew
<enebo[m]>
so perhaps we generalize the stmt about arjdbc and say more work is coming
<enebo[m]>
and just finish the release itself then spend afternoon on Rails stuff which also helps support the talk
<headius>
oh duh
<headius>
the alias_method_chain thing is due to old ARJDBC
<headius>
I had forgotten
<enebo[m]>
yeah
<headius>
so that is fine too
<headius>
I should be able to try mysql scaffold shortly
<enebo[m]>
50 got yanked but it now with --pre goes to 1.4.3 for some reason
<headius>
I can say "SQLite and MySQL are mostly working, but work remains to update them and PostgreSQL for Rails 7."
<enebo[m]>
sure assuming you get mysql to come up
<headius>
assuming
<headius>
wish you could generate with pre gems but then it would probably pull in rails 9 or something
<enebo[m]>
but I just don't think I would have put it out broken (although 7 months ago it may have worked and head fixes may have broken it
<enebo[m]>
7 months ago kwargs was probably very unstrict
<enebo[m]>
or possibly accepted regular hashes as kwargs here and there
<headius>
yeah 2.6 style
<enebo[m]>
but beyond that from a db perspective I doubt much would change
<headius>
at least it tries all tasks in the rails 7 new app generation, so I can go back and re-run them
<enebo[m]>
we would have to look at release of AR to see if something was released which broke things internally
<enebo[m]>
yeah
<enebo[m]>
I only have a very fuzzy recollection about this but I remember postgresql not working and thinking 2 of 3 is not bad
<enebo[m]>
but I am 100% sure we were not 100% passing on either of those
<enebo[m]>
kind of like horse shoes
<headius>
this was all done just prior to railsconf talk
<headius>
pretty sure I ran those numbers against mysql
<enebo[m]>
oh hahah I even forgot why we did this
<enebo[m]>
man what a time to be alive
<headius>
ugh allowPublicKeyRetrieval=true
<headius>
I have to relearn this shit every six months
<headius>
undefined local variable or method `reload_type_map' for #<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x297bbd41>
<headius>
well that's not good
<headius>
trying to db:create
<headius>
after adding that property above so it doesn't cough a gigantic Java stack trace at me
<enebo[m]>
hmm
<enebo[m]>
That looks bogus to me
<enebo[m]>
When I saw that I thought, "hmm that looks like a postgresl thing"
<enebo[m]>
if I look in activerecord it is only referenced in postgresql
<enebo[m]>
well I have a number of commits after the .pre
<headius>
blog app works
<headius>
ship it
<enebo[m]>
ok good. So work to do but it confirms my notion that this worked somewhat
<enebo[m]>
I will put what time I have this afternoon and improve on the situation and do 70.0 for those two
<headius>
yeah so if we push some 70.0 gems from head it should work out of the box
<headius>
cool
<enebo[m]>
I think we can get a bit more working
<headius>
I can run with pre gems for working on talk but others may try it over the weekend
<headius>
it's not thanksgiving everywhere
<enebo[m]>
yeah I mean they are screwed
<enebo[m]>
whatever comes out this afternoon will still have smoe issues
<enebo[m]>
I think not making much out of Rails support today is probably better but I do plan on a 70.0 this afternoon
<enebo[m]>
although daylight is burning
<headius>
* Initial support for Rails 7. SQLite and MySQL are largely functional, but work remains to update them and PostgreSQL. coming soon.
<enebo[m]>
sure sounds good
<headius>
minus the rogue coming soon
<enebo[m]>
coming to a theatre near you
<headius>
release notes are basically ready then
<enebo[m]>
ok I will put them onto the site and push
<enebo[m]>
once we see it up we will just do our normal stuff
<headius>
good job everybody
<headius>
ice creams all around
<headius>
so when do we fork 9.4
<enebo[m]>
not for a while
<headius>
I'm planning to stick to maintenance until holidays but then I want to push some perf and compat edges
<enebo[m]>
I just think we will have a lot of compat reports and anything we do which is beyond probably is just a topic branch for a while
<headius>
I'd like to see if we can run mastodon with some work
<headius>
fork will start to become necessary whenever we start to rework call protocol for kwargs
<headius>
we need a new site design
<enebo[m]>
yeah although that itself can just get merged back. If it is destined for a point then it will be but in any case we can make a support branch in a bit
<enebo[m]>
anyone who contributes will get the wrong branch too so near term not branching will cause a little less confusion
<headius>
I dunno, the kwargs support I envision may need to break some stuff
<headius>
it may be possible to merge back but we need to greatly expand what we can pass on the call path
<headius>
if we can pass in things like scopes, frames, callee method name, etc, we can start to eliminate threadcontext use
<enebo[m]>
yeah I realize that but are you saying this is .next or still destined for a point release?
<headius>
.next
<headius>
JRuby Z
<enebo[m]>
well I don't care a ton here but lets start with a topic and then we can just create maint at some point and then take over main
<enebo[m]>
It is git so I don't see much issue here and if people are still using jruby-head I don't think they want to see broken runtime
<headius>
this work will happen on a branch anyway so it's not pressing until we want to have it in mainline .next
<enebo[m]>
so I think you want that design to be baked enough for when that happens to show how it needs to update
<enebo[m]>
yeah
<enebo[m]>
that is how I feel too
<enebo[m]>
I pushed site...we can make sure it looks ok before going further
<headius>
I still don't have a good sense for how to manage maintenance versus active dev on git branches
<enebo[m]>
I checked links for downloads and they all work
<headius>
live for me now
<enebo[m]>
for me I think for CI people are using jruby-head for 9.4 and will be for a while. For PRs people always seem to open against our main branch too
<headius>
looks pretty good to me, but maybe we should add some links to issue tracker, matrix, twitter/mastodon?
<enebo[m]>
So until we get to a reasonably stable point it seems easier to leave it as main and move to maint once things slow down
<headius>
we didn't in the past but I want people to easily know how to reach us
<enebo[m]>
oh sure you can commit changes I guess
<enebo[m]>
I paste the raw text for email off of the web site
<headius>
ok give me a minute
<enebo[m]>
for GH releases I do use the .md
<headius>
pushed
<headius>
live for me, how does that look to you
<enebo[m]>
yeah looks good
<enebo[m]>
I will push out emails and GH releas
<headius>
sweet
<headius>
it's live
<enebo[m]>
and you can do what you have been doing?
<headius>
I'll do my socials and installers
<enebo[m]>
ok
<headius>
I'll do socials after installers this time
<headius>
I assumed what we had was along the 0.1.0 line since 2.6 had just barely started to gemify, so I grabbed the security fix 0.1.0.2
<headius>
that tag exists in cgi repo but I cannot find any branch for it
<enebo[m]>
The :: to . makes this noisy but it is what it is
<headius>
yeah
<headius>
I opened an issue on cgi to figure out where the heck these old versions are maintained
<headius>
if this passes, though, it should be ok to go with
<headius>
oh come on
<headius>
the 0.1.0.2 tag in cgi repo has a VERSION of 0.1.0.1
<enebo[m]>
I don't see where the fix is
<headius>
I'm going to try copying from 0.1.0.2 gem
<headius>
who knows where the hell they are keeping those sources
<enebo[m]>
There seems to be a single line about user agent env which returns early but everything else seems to just be changing how it is written
<headius>
I see the fix in the gem
<headius>
it is incremental on 0.1.0.1
<enebo[m]>
headius: is it in your PR yet?
<headius>
on its way
<enebo[m]>
oh ok. good
<enebo[m]>
heh. I read all that code twice and it looks like deck chair swapping
<enebo[m]>
some of it I do get why they changed it though
<headius>
pushed an additional commit updating from 0.1.0.1 (apparently) to 0.1.0.2 gem contents
<headius>
I do not know where those gem contents came from
<enebo[m]>
well that fixes multiple security problems
<headius>
yeah
<headius>
why can't they get these repos together
<headius>
cgi is fully gemified now and they have no branches for maintenance versions
<headius>
how do they even cope
<enebo[m]>
they fix it in MRI and remember to just commit it later in the gem
<enebo[m]>
My theory
<enebo[m]>
because they have never removed any tests for these libraries in MRI proper
<headius>
so bad
<enebo[m]>
yeah ergonomically having one repo is so easy
<enebo[m]>
so this decision is making things less ergonomic (albeit for reasons)
<enebo[m]>
it feels like the solution to one problem sort of created two problems
<enebo[m]>
Makes you wonder why they never just made ext/cgi where that is in MRI but has a rakefile for making the gem
<enebo[m]>
The source of that dir may or may not be in the release which I think is the answer but that is very very unlikely to be true since they commit to MRI first
<enebo[m]>
Anyways I am willing to roll with this assuming we can do some kind of sanity on this
<enebo[m]>
I am hoping this is actually used by stuff like Puma?
<headius>
very frustrating
<headius>
we'll see how CI goes
<headius>
I do not know how exposed this is via e.g. puma
<enebo[m]>
yeah if not then it probably really is not worth rushing this out
<enebo[m]>
but that second commit does look reasonable
<headius>
I would like to get an answer from cgi maintainer before we push this
<enebo[m]>
no \n and some no special regexps for some values
<headius>
btw in case we didn't discuss before, we can't really update 2.6 stdlib automatically anymore because it has continued to move on from CRuby 2.6 branch
<headius>
this for example
<enebo[m]>
6:40am in Japan
<enebo[m]>
yeah it is an issue with taking so long for 9.4
<enebo[m]>
in other mildly bad but also not so bad news. There are some kwargs errors running sqlite rails ar tests
<enebo[m]>
Thus far whenever I extract the code it does not happen but it is AR library code calling AR library code
<headius>
ok I was wrong about the tag being wrong, I copied from 0.1.0.1 tag somehow
<headius>
but I still don't see how 0.1.0.2 tag exists in this repo... master HEAD is at 0.3.5 and there's no other branches
<postmodern[m]>
Hello, I'm trying to get some code passing specs under JRuby 9.4 (congrats on the release btw) but the code deps in net/ftp, which deps in time, which deps in date, which contains C extensions which obviously won't install under JRuby. How do I work around the stdlib gem deps for JRuby?
<headius>
unclear what is up there
<enebo[m]>
It should make a {} in 9.3 and then gets to be *value so [{}]
<headius>
postmodern: some of those transitive deps just don't exist yet, and we know that's a problem... you see this because net-ftp is in Gemfile?
<headius>
we may need to get someone maintaining the date gem to release a -java no-op version temporarily
<headius>
test works on 9.4
<enebo[m]>
There is really weird semantics with **r and getting passed to non-kwarg *r
<headius>
this appears to be the first test that attempts to pass through a merged hash using **h
<headius>
it may be a bug in kwarg hash merging in 9.3
<enebo[m]>
maybe?
<enebo[m]>
run that same code with 2.6 to be sure I guess
<headius>
I can't install 2.6 still, no ossl 3 support and I have not had much luck working around it
<postmodern[m]>
headius: correct. I had to add the `net-ftp` gem to the `Gemfile` but only `if RUBY_VERSION >= '3.1.0'` so my code can require `net/ftp`.
<enebo[m]>
**r in 2.6 should literally just end up making a hash
<enebo[m]>
and *value should slurp that in
<headius>
postmodern: because that is the first version where it moved to a bundled gem?
<enebo[m]>
I do not even think there is any kwarg magic for this in 2.6
<postmodern[m]>
headius: correct, ruby 3.1.0 made some changes to which stdlib gems were part of stdlib. I believe they moved some of the `net-*` gems out.
<headius>
postmodern: looks like time 0.1.0 does not require date
<postmodern[m]>
headius: https://stdgems.org/3.1.0/ right they moved `net-ftp` from being a stdlib gem to being a "bundled gem".
<headius>
best option at the moment is however you can avoid date being a dependency
<headius>
net-ftp just appears to require time >= 0 so 0.1.0 would probably be fine
<enebo[m]>
the noop gem would be a reasonable stop-gap
<headius>
we are lucky rails deps do not pull it in so far
<enebo[m]>
the other fun bit is we have native parts
<postmodern[m]>
headius: That worked. Locked `time` to `0.1.0`. Specs run, but now there's a lot of interesting zlib and openssl failures.
<headius>
enebo: so do they
<headius>
so it either needs to be another native gem with jruby parts, or it stays a no-op, or we just include our Ruby bits in the gem and assume the rest stays in JRuby
<headius>
enebo: back to cgi
<headius>
I'm not sure what to do here... this test breaks on 9.3 but it is not related to the cve
<headius>
the same code passes the test on 9.4
<headius>
using cgi v0.1.0.2
<headius>
do you have 2.6 installed?
<headius>
git clone git@github.com:ruby/cgi.git
<headius>
then go into it and bundle ; rake test
<enebo[m]>
I have 3.6.7 I think
<headius>
I will try to fix my 2.6 install some day
<enebo[m]>
but I am a bit worried about that test that fails
<headius>
so security release friday or saturday then?
<enebo[m]>
If that is 2.6 callable new example then any changes to initialize probably broke that part of the library
<enebo[m]>
I believe we can wait a week on this and I/you can figure out the constructor. I don't think we can accept that signature without figuring out if that is a valid call to the constructor
<enebo[m]>
I think waiting is not a big deal because I do not think it is commonly used
<enebo[m]>
getting it fixed next week is not horrible considering it is a major us holiday
<headius>
it's only done in the test though
<headius>
it is just failing on the call side when it tries to negotiate those hashes
<enebo[m]>
that call might be done in webrick using that rype of signature to new
<enebo[m]>
I am just saying the test doesn't work but the call it uses in the test may be a form the library needs to accept
<headius>
I see no recent changes to webrick
<headius>
I disagree
<enebo[m]>
Maybe we are talking past each other here.
<headius>
I believe this is just nobu using nobu tricks to save typing out the hash every time
<headius>
tricks that work on 2.7 but not 2.6
<enebo[m]>
I don't care about the test per se. I am concerned the changes to initialize breaks 2.6 acceptable calling conventions due to how the method was change
<headius>
what method?
<enebo[m]>
initialize for Cookie
<enebo[m]>
def initialize(name = "", *value)
<enebo[m]>
Has it always been that or has the body always been the same
<headius>
I see no changes to initialize
<headius>
that signature has not changed since 2008
<enebo[m]>
ok reading the docs the whole thing is an options hash as a regular argument but then also an extra **h
<headius>
it just expects an options hash as a possible argument and uses it later in the method
<enebo[m]>
which as you said earlier should merge
<headius>
this test is just a nobuism
<enebo[m]>
yeah I find this extremely confusing as a snippet
<headius>
I patched the test and it passes
<enebo[m]>
So in 2.7+ that snippet will end up somehow merging into a single kwarg
<enebo[m]>
in 2.6 the first hash becomes name
<headius>
I swear I'm going to rip the pgup pgdn keys off this keyboard
<headius>
who thought it was a good idea to put them right next to the arrow keys
<enebo[m]>
so I am on the same page of opinion that nobu wrote something which will just not work on 2.6 (which I suppose is fine) but it is an odd way to write the test
<enebo[m]>
why did he bother to use ** at all
<enebo[m]>
or why did he even use strings vs symbols fork eys?
<headius>
ok, we'll let hsbt and friends sort this out and reconvene after the turkey
<postmodern[m]>
Should I still be adding the jruby-openssl gem in the Gemfile for JRuby 9.4?
<headius>
postmodern: it is always present in stdlib as a default gem so it is not strictly necessary, but without having it in Gemfile you won't get updates
<headius>
postmodern: thank you for the issues!
<postmodern[m]>
one last one
<headius>
I have an open issue for updating zlib to match CRuby, which should fix most of these things once I figure out what to update
<headius>
if you can add links there that would also be a great help
<postmodern[m]>
really weird edge-case where I was sub-classes OpenSSL classes to extend them but using initialize_copy to convert objects to my class. Apparently JRuby's initialize_copy expects the same class type.
<headius>
individual issues will make it easier to figure out what needs to be ported
<headius>
oh weird
<headius>
ok
<headius>
that might be a JRuby proper issue or just need some love in some OpenSSL initialize_copy
<headius>
open in JRuby for now and I can migrate it if necessary
<headius>
ok postmodern I'm checking out for the holiday... will be back around this weekend to figure out 9.3.9.1 release
<postmodern[m]>
headius: Cool, enjoy TGiving. I think that's all of the bugs I found from this libraries test suite. My goal is to try to release this giant new refactoring project by EoY. Hopefully I can get JRuby and TruffleRuby support checked off by then.