brokkoli_origin has quit [Ping timeout: 252 seconds]
AnaBanana has joined #ruby
cappy has joined #ruby
brokkoli_origin has joined #ruby
AnaBanana has quit [Quit: Client closed]
konsolebox has quit [Ping timeout: 244 seconds]
konsolebox has joined #ruby
cappy has quit [Quit: Leaving]
aindilis has quit [Read error: Connection reset by peer]
donofrio has joined #ruby
xokia has joined #ruby
xokia has quit [Read error: Connection reset by peer]
donofrio has quit [Ping timeout: 252 seconds]
JulioPapel has quit [Remote host closed the connection]
JulioPapel has joined #ruby
TomyWork has quit [Remote host closed the connection]
TomyWork has joined #ruby
TomyWork has quit [Remote host closed the connection]
cappy has joined #ruby
JulioPapel has quit [Remote host closed the connection]
JulioPapel has joined #ruby
cappy has quit [Quit: Leaving]
brw has quit [Remote host closed the connection]
brw has joined #ruby
xokia has joined #ruby
xokia has quit [Read error: Connection reset by peer]
donofrio has joined #ruby
donofrio has quit [Ping timeout: 244 seconds]
JulioPapel has quit [Remote host closed the connection]
JulioPapel has joined #ruby
dviola has joined #ruby
xokia has joined #ruby
xokia has quit [Remote host closed the connection]
xokia has joined #ruby
JulioPapel has quit [Remote host closed the connection]
JulioPapel has joined #ruby
konsolebox has quit [Ping timeout: 250 seconds]
Furai has quit [Quit: WeeChat 4.4.4]
Furai has joined #ruby
JulioPapel has quit [Remote host closed the connection]
JulioPapel has joined #ruby
JulioPapel has quit [Ping timeout: 246 seconds]
xokia has quit [Read error: Connection reset by peer]
konsolebox has joined #ruby
konsolebox_ has joined #ruby
konsolebox has quit [Ping timeout: 244 seconds]
grenierm has joined #ruby
crespire has joined #ruby
crespire1 has quit [Ping timeout: 244 seconds]
nmollerup has quit [Ping timeout: 248 seconds]
nmollerup has joined #ruby
xokia has joined #ruby
xokia has quit [Remote host closed the connection]
Linux_Kerio has joined #ruby
crespire has quit [Ping timeout: 246 seconds]
crespire has joined #ruby
konsolebox_ has quit [Quit: .]
nakilon has joined #ruby
<nakilon>
hey
<nakilon>
got bnc
<nakilon>
"Matz is nice, so we are" is bs, people on github are aggressive and unhelpfull; I'll check if at least this place is yet any good
<mms>
Microsoft Github. You will never find a more wretched hive of scum and villainy.
<nakilon>
right now I want to figure out the issue that people just suffer for years, not willing to fix it -- that "gem install" on Linux is slow, takes a minute vs a second on macos; I always assumed it's a flaw in alpine linux but it's the same on slim and even desktop Ubuntu, that I have to use for a job right now, so I can't stand the issue anymore,
<nakilon>
wanna solve it
<nakilon>
oh, looks like the issue was finally solved in ruby 3.0 image; gotta port it to 2.7 somehow; the thing is: just start a fresh new container and do anything like "gem install -N --conservative --ignore-dependencies bundler:2.4.22" to upgrade the bundler and it will stuck for a minute -- it needlessly runs a nested loop over all the remote gems,
<nakilon>
doing millions of version comparison
konsolebox has joined #ruby
<nakilon>
if you do "docker run --rm -ti ruby:2.7.8-slim sh", edit the method "canonical_segments" in "/usr/local/lib/ruby/2.7.0/rubygems/version.rb" to add debug prints to it (I suck in debugging, that's why I'm here), and you'll see -- it is doing 16mln comparisons on that single "gem install" command
<nakilon>
on "-alpine" image it is doing 36mln calls and it takes more than a minute; when I copied the same debug prints to ruby 2.6 on macos, it appeared that the method "find_all" in "/usr/local/lib/ruby/2.7.0/rubygems/resolver/installer_set.rb" there is being called three times vs one, and then it somehow does not fall that route; what looks weird to be
<nakilon>
me the InstallerSet object does not have the flags I passed in command line set to true, but it's the same on macos
<havenwood>
nakilon: In the off chance you haven't already, I'd update your RubyGems to the very latest 2.7 supports to confirm no fix.
<havenwood>
gem update --system
<havenwood>
There were some dependency resolver changes around 3.0. Hem.
<havenwood>
An aside, but it's too bad the efforts can't go towards getting off 2.7 but I get it.
<havenwood>
The webs we weave!
<havenwood>
nakilon: What version of RubyGems on 2.7?
<nakilon>
when I joined the team in summer they had 2.6, I moved the things to 2.7, further would face even more resistance from the conservative team in the old company; neither I would use modern rubies fully and properly, so the priority right now is to just make things usable with as few changes possible
<nakilon>
I remember those "gem install", "gem update", etc. were slow on alpine, maybe for different reasons; but when it's the same issue on slim and even desktop ubuntu that we all you as a corporative standard, I would rather figure it out finally
<nakilon>
but it's the same on ubuntu and slim; the "canonical_segments" method is being called millions of times, while on macos rbenv ruby2.7 it's called zero times
<nakilon>
i.e. it's not musl
<nakilon>
I wish there was a way to get something like a list of all the methods that were called; like a millions lines long file that I will then diff to find the place where the process when off the rails
donofrio has joined #ruby
zayd has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
zayd has joined #ruby
itok has quit [Ping timeout: 260 seconds]
<nakilon>
I took alpine ruby 2.7.2 (as what I have on macos), it ships with rubygems 3.1.4 -- the issue is there, but once I did "gem update --system 3.4.22" (the version from macos too), the issue is now gone, and bundler is being installed instantly; so the bug was fixed somewhere in between, and not ported to 2.7 docker image
itok has joined #ruby
<nakilon>
and the rubygems shipped with rbenv (ruby-build?) install are 3.1.6 on ubuntu
grenierm has quit [Ping timeout: 240 seconds]
<nakilon>
(with ruby 2.7.8)
<nakilon>
it's between 3.2.0 and 3.2.34
trillion_exabyte has joined #ruby
<nakilon>
looks like it's in 3.2.3, but changelog does not seem relevant
<kjetilho>
nakilon: stackprof ?
<kjetilho>
not a list, but an overview of what (statistically) is called most often, from where, and takes most time.
<kjetilho>
(I have never used it myself, only similar tools in other languages)
<nakilon>
kjetilho I know what's called but I don't know at what moment we get there into the loop
<kjetilho>
git bisect might be your friend
<nakilon>
maybe that diff does not even cover the moment where we go crazy, but fixes some data that lead us to that decision, hard to tell from 4 pages of diff
<nakilon>
kjetilho I did "bisect" by updating rubygems-update, though the version probably involves several commits, but it's not guaranteed any specific commit is stable; so it's just a huge refactoring that was going there; and no one updated the dockerhub image
<nakilon>
can't decide if I want to figure out when the bug was introduced
<kjetilho>
I thought you were looking for the fix, so you could backport it
TomyWork has joined #ruby
<nakilon>
oh, looking at versions, looks like they were patching older major versions of rubygems-update, so... the 3.0.9 does not have the bug, so the fix is even ported to older rubygems somewhere in 3.0.x
<nakilon>
or rather it wasn't in 3.0.x at all
<nakilon>
it's not in 3.0.8; it is in 3.1.2 and in 3.1.6; so it was introduced in December 2019 with rubygems-update 3.1.0 (probably), and then was fixed only in December 2020 in 3.2.3; meanwhile the last 2.7 docker image was shipped in May 2023, and it's shipped with rubygems-update 3.1.6 (it's so confusing, the version literally matches the alpine version)
<nakilon>
so the bug was fixed after a year of its existence, and after that the docker image was updating for 5 more months but the rubygems in it wasn't
<nakilon>
I don't see how to check older versions of the image in dockerhub to find when the bug was baked into it
<nakilon>
not updating the rubygems to fix it looks almost like a sabotage to force people to move to ruby3
<nakilon>
oh wait, 2023 isn't right after 2020; so the bugfix existed and wasn't pushed to docker image for 2.5 years!
dhruvasagar has joined #ruby
<nakilon>
why the hell
graywolf has joined #ruby
<nakilon>
haven't checked other ruby versions -- probably there is the same flaw, smh
<nakilon>
I've no idea if there are any rules on when the docker, ruby-build, etc. maintainers update the rubygems
livoreno has joined #ruby
<nakilon>
since all the ruby2.7 docker images are with rubygems3.1 (from 3.1.2 to 3.1.6) and 3.1.2 is dated December 2019, I assume the ruby2.7.3 docker image was with the bug from the start, i.e. the only way to avoid it in docker is to use as old ruby as 2.7.2 that obviously sucks; otherwise you have to install any better version of 2.7 and then have to
<nakilon>
build through this buggy slow step to update the rubygems to a good version
<nakilon>
that's how things are bad in docker, and what about the desktop? is it possible to specify rubygems version in rbenv? in rvm? no idea
<nakilon>
and btw ruby 2.7 existed exactly since December 2019, i.e. probably it had the bug from the very beginning; i.e. ruby2.7 released in the same month the rubygems were broken, the year later they were fixed, but the 2.7 was updating for 2.5 years with the bug remaining; people were forced to switch, because exactly on December 2020 there was ruby3.0
<nakilon>
release, I assume with the fixed version of rubygems
<nakilon>
i.e. ruby2.7 was broken all the time, and the fix existed ~70% of the time, but wasn't applied
<nakilon>
so these are they "years that no one cared" I said two pages ago; it wasn't my illusion, the rubygems were really unusable, and it's still there in 2.7, the rbenv on ubuntu installs it broken while it's been 4 years since the fix
<havenwood>
nakilon: Can you manually bump the RubyGems version by swapping it out, just avoiding `gem update --system` entirely?
<havenwood>
Or update the package with a new one. Tools like RVM just copy/pasta RubyGems.
<havenwood>
(Assuming the patched version of RubyGems indeed does work on 2.7.)
<nakilon>
not sure what you mean by "swapping it out"
nmollerup has quit [Remote host closed the connection]
<nakilon>
docker image rubylang/ruby:2.7 is also with buggy version (3.1.6)
graywolf has quit [Quit: WeeChat 4.4.4]
<havenwood>
nakilon: Just copy the tarball and unzip it or clone the repo and run: ruby setup.rb --help
<havenwood>
RVM does it via the `rvm rubygems` command, but it was a classic way to install RubyGems back in the day and should still be documented.
<havenwood>
(From before RubyGems shipped with Ruby.)
<havenwood>
If I couldn't run `gem update --system` I'd try manually downloading the target version of RubyGems.
<nakilon>
looks like both by rbenv and coworkers' rvm use 3.1.6; they say "yeah it installs everything for like 20 seconds" and "it's ok we can wait"...
<nakilon>
... instead of the possibility to not wait at all
<nakilon>
they ask "why do you bother?" because they don't work with docker and never reinstall anything (while being QA...)
<havenwood>
Ruby 3.4 now just a fortnight away!
<havenwood>
Prism is a nice update from parse.y.
graywolf has joined #ruby
hwpplayer1 has joined #ruby
brokkoli_origin has quit [Ping timeout: 248 seconds]
hwpplayer1 has quit [Read error: Connection reset by peer]
hwpplayer1 has joined #ruby
nmollerup has joined #ruby
donofrio has quit [Ping timeout: 244 seconds]
brokkoli_origin has joined #ruby
user71 has joined #ruby
konsolebox has quit [Ping timeout: 244 seconds]
donofrio has joined #ruby
MsInput has quit [Quit: WeeChat 4.4.4]
MsInput has joined #ruby
aindilis has joined #ruby
trillion_exabyte has quit [Ping timeout: 272 seconds]
trillion_exabyte has joined #ruby
konsolebox has joined #ruby
hwpplayer1 has quit [Remote host closed the connection]