<chester>
I know that it was a fad for a while that died off
<chester>
The fad is dead anyhow.
<chester>
Ruby with RubyOnRails was a hot thing for a while. For some, it's now just an outdated burden.
<arestifo>
The last commit on the Rails repository is from 13 hours ago. Ruby still has a very active an good community.
<adam12>
I think it’s just technologies natural ebb and flow. People’s skills change, their tastes change, and something new might replace it.
<adam12>
I definitely don’t do any Rails anymore, but I haven’t left Ruby. If anything, I’m enjoying the ecosystem more with Roda, Sequel, Hanami, ROM, Dryrb, +others.
<arestifo>
From my experience, I worked with companies that have a legacy Rails monolith, and with companies that have a legacy Node monolith. The legacy Node monolith was always worse than the rails monolith.
zodeishi has joined #ruby
<EdwardIII>
100%, i've run products in production on multiple tech stacks, ruby+rails was far away the best in so many ways. with node and the ecossytem we spend an enormous amount of time wrestling with the tooling and other weird problems when we could have been working on bug fixes + features
Bounga has joined #ruby
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chester has left #ruby [#ruby]
gr33n7007h has joined #ruby
jetchisel has quit [Ping timeout: 245 seconds]
tree has joined #ruby
arestifo has joined #ruby
splud has joined #ruby
Cata has joined #ruby
FemmeAndroid has quit [Read error: Connection reset by peer]
gearnode has quit [Ping timeout: 264 seconds]
gearnode has joined #ruby
seabre has joined #ruby
Garb0 has joined #ruby
Garb0 has quit [Quit: Garb0]
Garb0 has joined #ruby
tree has quit [Quit: tree]
chonkbit has joined #ruby
Bounga has quit [Ping timeout: 245 seconds]
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leftylink>
huh. haven't looked at those in a long time. nor the tiobe tpci which I used to check each month
Garb00 has quit [Read error: Connection reset by peer]
Garb000 has joined #ruby
goldfish has joined #ruby
goldfish has quit [Read error: Connection reset by peer]
Garb000 has quit [Quit: Garb000]
goldfish has joined #ruby
Garb0 has joined #ruby
arestifo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arestifo has joined #ruby
arestifo has quit [Client Quit]
arestifo has joined #ruby
arestifo has quit [Client Quit]
Garb0 has quit [Ping timeout: 245 seconds]
Garb0 has joined #ruby
Oblomov has joined #ruby
<Oblomov>
hello all. I'm looking for some documentation on the interaction between threads and fork in ruby (MRI specifically, but I'm not sure if the behavior I'm experiencing is universal or not)
<Oblomov>
specfically, I'm trying to understand which “side” of the fork keeps the threads that were live before the fork, because I'm seeing somewhat confusing behavior
<Oblomov>
we have a logger running on a separate thread, and if the main thread does the “double fork” thing to daemonize, the logger thread gets “lost”, so I assumed the threads to remain in the main process. HOWEVER, issuing an IO.popen("-"), it seems that the threads die on the main process too?
<Oblomov>
or maybe inside popen the roles are switched?
Garb0 has quit [Ping timeout: 245 seconds]
Garb0 has joined #ruby
<havenwood>
Oblomov: The parent process should have the living Thread and the child process should have the same Thread instance but dead, since the Thread is in another process.
<Oblomov>
havenwood: inside popen too, right?
<havenwood>
It shouldn't die on the main process. Can you fork before spinning up Threads?
<Oblomov>
havenwood: well, for the popen thing no, because it's interactive
<Oblomov>
havenwood: for the daemonization fork, I solved by simply restarting the thread inside the second child once the daemonization is complete
<Oblomov>
(since the main process has long been dead, this is not an issue)
<havenwood>
Oblomov: I just mean preemptively not have this happen. Yeah. Hem, I don't know the mechanism Ruby Processes use to determine the Thread isn't theirs well enough.
<Oblomov>
havenwood: oh
<havenwood>
I think you're running into fallout from how Ruby tries to swing Threads in Processes that don't belong to them.
<havenwood>
The Ruby Thread which is forked is the exact same instance in the child, which I would call unfortunate but it's the way it is. -eregon
<havenwood>
Quote ^
<Oblomov>
ok but after the double fork I create a new thread
<Oblomov>
so I would assume this should not be that much of an issue
<Oblomov>
in the sense that the child is then left with their own thread, which they should know it's their own
<Oblomov>
but now that I look again at the code (sorry, been a long time since I touched this), I see that the issue with popen might not be with thread conflict, but with the shenanigangs we play on stdout/stderr
<Oblomov>
... which would make sense, actually
<Oblomov>
yyyep, std file descriptor shenanigans are to blame
<adam12>
std shenanigans.
<adam12>
the best kind.
<Oblomov>
this does pose me with a bit of a problem though
<Oblomov>
so, when we daemonize, we override the $stdout and $stderr write method to redirect to the logger. it used to be that this didn't affect stdout and stderr for the popen child
<Oblomov>
but obviously for some reason it is doing so in more recent ruby versions
<Oblomov>
or at least with the change to the threaded logger model, hm
Garb0 has quit [Ping timeout: 264 seconds]
nuttingd has joined #ruby
nuttingd has quit [Client Quit]
Garb0 has joined #ruby
rem has joined #ruby
<Oblomov>
OK problem solved, thank you guys so much for being my rubber duck!
SuperLag has quit [Ping timeout: 272 seconds]
SuperLag has joined #ruby
graywolf has quit [Ping timeout: 268 seconds]
graywolf has joined #ruby
Garb0 has quit [Quit: Garb0]
<nakilon>
there should be a #rubberduck channel where people come to tell what they try to solve and responding would be a bannable rules violation
<Oblomov>
lol
<Oblomov>
nakilon: otoh who knows, maybe havenwood's comment triggered something that I wouldn't have looked at otherwise
<jhass>
nakilon: what if I'm rubberducking on the same problem at the same time?
smurfke_ has joined #ruby
<smurfke_>
How can I verify whether a gem is succesfully installed?
<jhass>
smurfke_: gem list should show it usually there's an entry point of the same name, so ruby -e 'require "gem_name"' should not error
<nakilon>
you can check if it's in gem list but it's not a full truth
<jhass>
but I suspect you wouldn't ask this if you didn't have doubts about it being installed successfully, so what's your actual problem?
<nakilon>
it could fail to make native extensions
<nakilon>
and you'll see it only when you require/use the game, unless it provides pure-ruby fallback
drn has joined #ruby
<nakilon>
s/game/gem ffs
<nakilon>
this actually was among the questions I asked on SO -- how to make a game that would fail if making native extensions have failed
* jhass
hands nakilon a box of gems
<nakilon>
yay!
<jhass>
you seem to be running out of those
<jhass>
save your games box for fun times!
* nakilon
hands jhass a box of games instead
<jhass>
oh, thanks, I didn't expect anything in return really!
<smurfke_>
however it errors out on: undefined method `amoeba'
<jhass>
what steps did you take to install it?
<smurfke_>
A couple: I added the gem to my Gemfile, after that ran bundle install
<nakilon>
there is some thing that actually prevents the gem installation process from really knowing if the native extensions build succeed -- I had to append test run to installation but it still has no effect, the gem install just ignores exit codes
<jhass>
great
<smurfke_>
after that I added the github repostiory to my Gemfile but alas. Same error
<smurfke_>
when running the command 'gem list' the amoeba gem is between the list
<smurfke_>
so I'm out of ideas
<jhass>
do you still have the output of the bundle install command in your terminal history by chance? Did it report installing amoeba?
<nakilon>
if you use "bundle install" you should check the result with "bundle exec gem list"
<nakilon>
or I rather mean not that build failed but if your tests failed
<nakilon>
(asking these questions is considered unwelcome on SO and is being clearly deleted)
<smurfke_>
it returns an error but when I run the command like so: ruby -r amoeba -e 'p Amoeba' then it returns Amoeba
<jhass>
oh! What's the error?
<smurfke_>
runtime.rb:319:in `check_for_activated_spec!': You have already activated concurrent-ruby 1.1.4, but your Gemfile requires concurrent-ruby 1.1.3. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
<smurfke_>
I think it is not related
<jhass>
heh, well I guess so. But super weird that a bundle exec command would ever say that
<smurfke_>
yeah lol
<smurfke_>
especially since leaving out bundle exec runs the command just fine
<jhass>
what about bin/rails runner 'p Amoeba'
<smurfke_>
it prints out Amoeba
kinduff3 has joined #ruby
drn has quit [Quit: Konversation terminated!]
kinduff has quit [Ping timeout: 272 seconds]
kinduff3 is now known as kinduff
<jhass>
okay, let's see for bin/rails runner 'p ActiveRecord::Base.singleton_class.ancestors.include? Amoeba::ClassMethods'
<smurfke_>
it returns true
<smurfke_>
:D
kinduff7 has joined #ruby
<smurfke_>
dunno whether that's a good or bad thing
<smurfke_>
I guess it confirms that amoeba gem installed succesfuly?
<jhass>
so it seems installed correctly. Could make extra sure you don't have like a non-breaking space in there or something? Also that you really are in the class scope of something inheriting directly or indirectly from AR::Base, not inside a module/concern, not inside a method
<jhass>
also make sure you fully restarted everything after installing the gem
<smurfke_>
the only thing that is different compared to the example that is given is the fact that my class inherits from ApplicationRecord instead of inheriting directly from ActiveRecord::Base (as in the example)
<jhass>
especially with things like spring there might be an old process lingering around somewhere
kinduff has quit [Ping timeout: 272 seconds]
kinduff7 is now known as kinduff
<smurfke_>
aha jhass: it could be as simple as restarting!
<smurfke_>
let me try that first
<jhass>
wait, you never restarted? :D
<jhass>
should've asked that earlier :D
<smurfke_>
no -__-
<smurfke_>
haha yeah
<smurfke_>
it's computer first aid
<smurfke_>
and I forgot about it myself
<smurfke_>
let me try
<jhass>
Loading gems is part of rails' early boot process, in config/boot.rb or config/application.rb. In the default configuration you can consider everything living outside your app/ directory as not auto-reloading
<smurfke_>
yeah that was it. thanks for the explanation. Will keep it in mind!
<smurfke_>
alsso thanks for guiding me through discovering what was wrong. Learned a few things :-)
<jhass>
hope so! you're welcome!
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
smurfke_ has joined #ruby
Oblomov has left #ruby [Never try an explanation of what comes naturally (The wee Kirkcudbright centipede)]
davidnutting has joined #ruby
davidnutting has quit [Client Quit]
davidnutting has joined #ruby
chonkbit has quit [Ping timeout: 272 seconds]
rem has quit [Quit: Connection closed]
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
smurfke_ has joined #ruby
<smurfke_>
Suddenly there is a 'dump.rdb' file in my ruby project.
<smurfke_>
anyone know what this is
<smurfke_>
nevermind, I googled and it seems to be related to redis. Weird
davidnutting has quit [Quit: WeeChat 3.1]
davidnutting has joined #ruby
bastienleonard has joined #ruby
gearnode has quit [Ping timeout: 272 seconds]
lfalcao has joined #ruby
davidnutting has quit [Quit: WeeChat 3.1]
davidnutting has joined #ruby
davidnutting has quit [Client Quit]
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gearnode has joined #ruby
smurfke_ has joined #ruby
graywolf has quit [Quit: WeeChat 3.1]
<nakilon>
since when did the URI stopped making Kernel#open?
<nakilon>
*open-uri
lfalcao has quit [Ping timeout: 245 seconds]
<havenwood>
nakilon: in 3.0
<gr33n7007h>
nakilon: some time last year i believe
<havenwood>
gr33n7007h: there was previously a warning
<havenwood>
warning: calling URI.open via Kernel#open is deprecated, call URI.open directly or use URI#open
<gr33n7007h>
havenwood: ah, i wasn't sure tbh
<havenwood>
gr33n7007h: technically, Christmas was "some time last year" so you're not wrong
<gr33n7007h>
havenwood: true :)
smurfke_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]