subbu has joined #jruby
subbu has quit [Quit: Leaving]
<headius> good morning!
<headius> edipo.federle: yeah this would be fixed with a larger project I have wanted to do
<headius> basically need a way to track instance variables on a per-instance basis rather than having the table be in the class
<edipofederle[m]> Morning, yes, I'm exploring MRI to see if I can check how they do it. If I find something, I share will share here
<headius> enebo: so 9.2.20, ready to release?
<headius> I can put notes together
<enebo[m]> headius: I actually still need to do some testing on windows but it is up so yeah release notes would be great
<headius> there are two issues still marked for 9.2.20
<headius> one is launcher but other seems to be parser related so not sure if you got to that
<headius> I moved the launcher issue to 9.2.21... but it may be a while before we can fully resolve it because it is waiting on a change to freebsd's java-selecting commands
<enebo[m]> shoot I missed the parser one
<enebo[m]> the freebsd one is more icky since we are looking at JAVA_HOME for more than just invoking (like looking for module support)
<headius> yeah
<headius> though it did occur to me today this will all be over once we use modules all the time and drop 8
<enebo[m]> The parser issue itself is so unusual though I think we can punt it
<headius> ok
<enebo[m]> You see it was Exc => ///nothing
<headius> yeah it is a syntax error in CRuby too?
<enebo[m]> so it sucks we do not return a nice exception and crash but it is not valid syntax
<enebo[m]> yeah MRI will return
<enebo[m]> syntax error, unexpected '\n', expecting '.' or &. or :: or '['
<enebo[m]> which honestly is not a crash but not helpful at all either
<headius> heh yeah generic unexpected newline
<enebo[m]> jruby (3.0.2) 2021-10-29 1ad025fd94 OpenJDK 64-Bit Server VM 16.0.2+7 on 16.0.2+7 +jit [linux-x86_64]
<enebo[m]> SyntaxError: ../../../snippets/pars1.rb:6: syntax error, unexpected '\n'
<enebo[m]> So it is for sure fixed in 9.4 already
<enebo[m]> I do not have a 9.3 handy to see if somehow it is already fixed for 9.3
<enebo[m]> Not entirely sure why we don't provide the expected list but I also never find these expected values to be useful :)
<headius> hmm
<headius> shoot
<headius> bit of a problem
<headius> the backtrace fix I patched for 9.3.1 also affects 9.2.20
<enebo[m]> so while this may be true I think we have to consider that we can put out a after rubyconf and that it has been in 9.2 the entire time right? So people noticed when they tried 9.3 but did not report it against 9.2
<headius> 9.2 never had this in a release
<enebo[m]> OH you backported it
<headius> it was fixed on 9.2 for 9.2.20 but first went out in 9.3
<enebo[m]> ok then we should fix it
<headius> ok, should be an easy backport
<enebo[m]> ok
<enebo[m]> going to look at axact AIIOBE error on that parsing issue
<headius> ok
sagax has quit [Remote host closed the connection]
<headius> something failing in backport PR, looking into it
<headius> of course it passes locally
<enebo[m]> sure. I fixed the other issue
<enebo[m]> It begs a question about why column == 0 but there is no actual harm in the fix since at worst it will not provide an extra line of output in the error stmt
sagax has joined #jruby
<headius> almost final
<enebo[m]> nice
<headius> ok not sure what's up here
<headius> this test is just to confirm that extensions will not be attempted to be loaded if we have disabled C ext support
<headius> it is supposed to fail with a LoadError but is failing with a FrozenError on GHA
<headius> Travis does not appear to be running PR builds for 9.2 anymore
<headius> it also does not appear to be running for the commit you just pushed to 9.2
<headius> oh FFS
<headius> enebo: "Owner jruby does not have an active subscription."
<headius> looks like about 6 days ago Travis started rejecting JRuby builds
<headius> actually no, just a day ago or so
<headius> yup they kicked us off on the 30s
<headius> 30th
<headius> "Expired October 30, 2021"
<kares[m]> yeah I've been trying to trigger jossl builds since the weekend - thought it would reset on November but not luck
<headius> kares: wonderful
<headius> I don't even see how to get a subscription... amazing how much they have killed this thing
<kares[m]> looking into GH actions, but yet again spending time elsewhere than I had hoped for ...
<headius> I am trying to activate the free plan now
<kares[m]> yeah shamy what Travis is doing ... been hit by this several times already - they promised free credits but apparently that went away.
<kares[m]> maybe the reset period for JRuby is some other date than the 1st
<headius> "You exceeded the number of users allowed for your plan. Please switch to a bigger plan"
<headius> "Trial Plan
<headius> Unlimited unique users"
<headius> what a clusterfrak
<headius> I sent a support message asking them to reinstate our service or we'll have to leave... the equivalent to the free plan they had been giving us would be almost $6000/year now
<headius> running some suites locally to make up for the missing CI now
<headius> enebo: I merged that PR since other stuff seems to be passing, but I am trying to verify now
<headius> I guess it is really time to get off travis
<headius> the same change has been on master and shipped in 9.3.1 so it should be fine but not having CI to verify is rough
<enebo[m]> yowch
<enebo[m]> Does not happen on linux
<enebo[m]> going back on linux box to for a bit to try and figure out what is happening
<headius> if you can get a jit trace it would help
<headius> tests seem to pass fine locally (macOS) after that backtrace patch merge
<headius> I'm not sure what causes this failure on GHA
<enebo[m]> I looked up past references to this method missing and it shows up around openssl not loading
<enebo[m]> which could have absolutely nothing to do with it obviously
<headius> yeah it is a pretty generic error
<enebo[m]> Any other options you are interested in?
<headius> just jit=0 should show us where it is
<enebo[m]> I get no output from setting threshold to 0.
<headius> no output??
<enebo[m]> just the error output itself
<enebo[m]> derp wait a sec
<headius> does not repro on macOS either, installs fine
<enebo[m]> I am guessing find_command is failing
<headius> this is a different error
<headius> it was looking for [] before and now it's looking for this build_args thing
<enebo[m]> this was in the original error too but lost down below
<headius> if we could see the trace for that error it might be a root cause
<headius> it fails to call [] because it gets nil somewhere, which could be causing the later call to fail too
<enebo[m]> just reading the backtrace it looks like it makes it through find_command without raising so it does self[possibilities.first] which returns nil
<enebo[m]> I am going to go back to windows side and put in some prints
<headius> that's pretty weird
<headius> enebo: MRI core tests, JRuby tests, and RubySpec are green on macOS for me
<headius> nothing comes to mind as a possible cause
<headius> for your issue
<enebo[m]> whoops
<enebo[m]> ignore that
<enebo[m]> It is something with ffi
<headius> hmmm
<headius> GHA may have run on that PR only because it was marked to merge to master at first
<headius> we do not run GHA for 9.2 branch it seems
<headius> so that failure may have been a temporary glitch
<enebo[m]> crtname = RbConfig::CONFIG["RUBY_SO_NAME"][/msvc\w+/] || 'ucrtbase'
<headius> I am going to focus on your issue instead
<headius> hmmm
<headius> that line does not appear in my copy of 9.2
<headius> where is it?
<enebo[m]> lib/ruby/stdlib/ffi/platform.rb
<headius> FFI would make sense as a cause because it was updated to match the gem
<enebo[m]> I am looking at this from untar'ing the source dist
<enebo[m]> ah yeah it is also in my jruby-9.2 dev dir
<enebo[m]> this logic assumes there will be a RBUY_SO_NAME entry that can be arefed
<headius> I found it in ffi files
<enebo[m]> I am going to just fix this on my windows install and make sure nothing else is wrong
<headius> so that config value is not there
<headius> it is there in the RbConfigLibrary
<enebo[m]> I am making that assumption that is it the second call to []
<enebo[m]> otherwise CONFIG would have gotten blown away
<enebo[m]> or not loaded
<headius> yeah which would break a lot of other stuff
<headius> setConfig(context, mkmfHash, "RUBY_SO_NAME", "jruby");
<enebo[m]> I will fix it and see ... I will pop back quick if it is even weirder
<headius> that is a different constant though
<headius> aha FFI does modify it
<headius> nevermind it does not modify but it reads it in a few places
<enebo[m]> I just removed the CONFIG lookup and I can see the runner script installing gems now
<headius> [] ~/projects/jruby-9.2 $ rvm ruby-2.5.7 do ruby -e 'p RbConfig::CONFIG["RUBY_SO_NAME"]'
<headius> nil
<headius> "ruby.2.5.7"
<headius> [] ~/projects/jruby-9.2 $ ruby -e 'p RbConfig::CONFIG["RUBY_SO_NAME"]'
<enebo[m]> I will go back and verify RUBY_SO_NAME is not an entry though
<headius> not sure what would have changed here but CRuby does define this
<enebo[m]> yeah it had to be the case
<enebo[m]> We probably never had anything query it until now
<headius> aha that is a good theory
<headius> it only does that section on Windows
<headius> so we just need to populate it
<enebo[m]> 5 months old
<enebo[m]> So this is first time pulling this in and seeing it on windows to break
<headius> jruby-9.3 $ ruby -e 'p RbConfig::CONFIG["RUBY_SO_NAME"]'
<headius> "ruby"
<enebo[m]> HAHA
<enebo[m]> YAY...upgrade!
<enebo[m]> may be interesting to see what else happened when that entry was added
<enebo[m]> rails ran to completion and my simple app is working
<headius> so those didn't get picked up when I did the FFI backport
<headius> I can cp those to 9.2 branch
<enebo[m]> RUBY_BASE_NAME
<enebo[m]> yeah
<headius> pushed those changes
<enebo[m]> cool...third time will be a charm
<headius> I am done fiddling with 9.2 and the release notes stand
<headius> trying current rails install on 9.3 and getting an odd error
<headius> I'm going to clean this and rebuild and make sure I have a proper 9.3 HEAD
<headius> might have been a glitch or dirty env... seems to work now
<headius> I'm doing a full git clean to make sure
<headius> it is working fine now 🤷‍♂️
<headius> weirdly slow to install a couple gems
<enebo[m]> releasing on maven + gem
<headius> install and generate worked with 9.3 HEAD and Rails
<enebo[m]> Yeah I do test 6.1 as part of releasing so I expected it but I am not sure which particular point was last time
<headius> ah ok... I wasn't sure what you are testing with
<enebo[m]> I only do older on windows due to sassc
<headius> I don't really want to try to test perf and we have a lot of outstanding perf items we want to do so I will not cover that much
<headius> have you tried Rails 6.1+ on Windows lately?
<headius> not sure if anything has changed to fix sassc but we need to deal with that at some point
<headius> yeah scaffold, migrate, and CRUD all working fine for me
<headius> woot
<enebo[m]> I tried it for
<enebo[m]> so you are saying it is working on windows?
<headius> not on Windows
<headius> this is just me testing locally on macOS
<enebo[m]> ah ok
<headius> sassc has had some tweaks for install on Windows but I don't think they helped us
<enebo[m]> I no longer macos so I have not tried on there but usually it just works (M1 :( )
<headius> I think the main thing is that it tries to build the library on Windows so it needs build tools
<headius> where CRuby can just install the premade platform gem
<enebo[m]> ok so on our updated website for 9.2.20 the topbar will still show 9.3 release and notes link
<headius> enebo: I am in favor of spinning a 9.3.2 tomorrow or early next week so I can have recent fixes out there for RubyConf
<enebo[m]> headius: I am open either way
<enebo[m]> next week won't hurt us
<headius> I speak on Tuesday
<ahorek[m]> good evening!
<headius> ahorek: hello!
<enebo[m]> wait let's make sure I understand what you are thinking about
<enebo[m]> you will want a release either way before your talk? Or you will just say we are ready to release in a day or so sort of thing?
<ahorek[m]> thanks @enebo for fixing that token issue :)
<enebo[m]> ahorek: oh yeah no problem...the method was nearly already made in the lexer already
<ahorek[m]> about sassc, there's a new alternative that works out of the box on jruby
<enebo[m]> headius: see my statement above about our web site
<headius> oh really
<enebo[m]> I need to get this out really soon
<enebo[m]> it is already 4pm central
<headius> enebo: I'm fine either way but it is always nice to have the latest downloadable
<headius> I am not sure if there are any blockers for people trying 9.3.1
<headius> 9.2.20 ship it if you are comfortable with it now
<enebo[m]> headius: well monday may work for that BUT it depends on how smoothly it goes
<ahorek[m]> but it's probably not worth integrating it to sprockets, rails is moving to a simpler assets management
<headius> yeah not sure what else we have slated for 9.3.2 but there are a few good items in there already
<headius> enebo[m]: seems fine to me.. 9.2 is in maintenance mode
<enebo[m]> headius: I think from my perspective so long as I can test enough to know it is largely working then I can evaluate any late commits
<enebo[m]> ok
<enebo[m]> I am pushing site and then emails and github release
<headius> ahorek[m]: well that is good news... this pipeline has gotten **thick**
<headius> enebo: ok I will handle socials and dockers
<enebo[m]> we will need social media/docket
<enebo[m]> haha
<enebo[m]> docket
<enebo[m]> I want there to be a docket
<headius> docket on the socials
<headius> "JRuby 9.2.20 is released with several user-reported bugs fixed, FFI as a default gem (upgradable independent of JRuby) and a new jruby-openssl fixing a long-standing certificate verification issue. We recommend 9.2 users upgrade!"
<headius> enebo: I just noticed an unmerged PR was still marked for 9.2.20 so might need to regen list or remove it
<headius> I think you did a different PR for that but it was never retargeted
<enebo[m]> ok removing it
<enebo[m]> yeah looks good...finishing GH release
<enebo[m]> no emails yet but that ended up being a good thing
<headius> enebo: I tried to merge 9.2 to 9.3 and had a conflict I could not fix in your SyntaxError patch
<enebo[m]> ok I can merge...
<headius> everything else merges ok so maybe you can take a look at that
<enebo[m]> sure
<enebo[m]> updating version to SHAPSHOT
<headius> lol SHAPSHOT
<headius> if only it were SHAPSNOT
<enebo[m]> can you do ruby-build?
<headius> and ruby-versions? I'm fine officially taking those along with docker
<enebo[m]> I almost updated our irc/matric
<headius> hah
<enebo[m]> yeah that would be great
<headius> yeah fun with branch maintenance
<enebo[m]> I also noticed we still have 9.1 listed in downloads
<enebo[m]> We should probably kill that section
<headius> hah yeah kill it
<headius> I think that's everything
<enebo[m]> Man some releases are like pulling teeth
<headius> what now
<enebo[m]> This one in the end was not very stressful but it was time consuming
<enebo[m]> I pushed 3 releases
<enebo[m]> ahorek: thanks!
<headius> ah yeah blame me for not getting everything necessary for that backport FFI
<headius> enebo: we should add that to the list
<headius> rvm update
<headius> 9.2 will be around a while longer so we need to figure out a CI solution that also tests Windows
<enebo[m]> but shit happens. I think it is just normal to expect things to sometimes not be right
<headius> right now nothing is working in CI for 9.2
<enebo[m]> but we were not testing 9.2 on windows were we?
<headius> hopefully we can give up 9.2 when 9.4 comes out
<headius> "were not testing" other than what you run at release time
<enebo[m]> I am not saying we shouldn't but I am blanking
<enebo[m]> yeah I admit that is suboptimial
<headius> yeah I mean if we had a simple job that just tried to install rails and run it would have caught this early
<enebo[m]> 9.3 is when we start to pull out of that
<headius> we have one windows job on 9.3/master
<headius> at the very least we may have to migrate 9.2 on up off travis completely now
<enebo[m]> we don't run rails in any ci runs anywhere atm
<enebo[m]> but we do install gems I am sure
<enebo[m]> I have thought about making runner part of it but we have so many jobs already
<enebo[m]> maybe check-versions could also run rails
<headius> yeah I just want to turn your verification into a simple smoke test
<headius> save you the hassle of finding those issues on the day
<headius> I'm just looking out for you bro
<enebo[m]> haha yeah. admittedly having a simple run would tag errors when they first occured too
<headius> yeah
<headius> ok
drbobbeaty has quit [Quit: Textual IRC Client:]
<ahorek[m]> => false on CRuby