protektwar has quit [Quit: No Ping reply in 180 seconds.]
protektwar has joined #ruby
protektwar has quit [Changing host]
protektwar has joined #ruby
jpn has joined #ruby
s-liao-2000 has quit [Quit: Client closed]
jpn has quit [Ping timeout: 246 seconds]
dionysus69 has quit [Ping timeout: 264 seconds]
Aminda has quit [Remote host closed the connection]
Aminda has joined #ruby
dionysus69 has joined #ruby
CalimeroTeknik has joined #ruby
CalimeroTeknik has quit [Changing host]
mjacob has quit [Ping timeout: 240 seconds]
mjacob has joined #ruby
RickHull has joined #ruby
Ziyan has joined #ruby
<depesz>
hi. in some ruby script I have: $LOAD_PATH.unshift(Pathname.new( __FILE__ ).realpath.parent + 'lib')
<depesz>
this works, but rubocop is saying: "C: [Correctable] Style/StringConcatenation: Prefer string interpolation to string concatenation."
<depesz>
tbh, i think this is wrong, because I'm not concatenating strings - i'm issuing + method on pathname. is there good solution to this problem?
<Ziyan>
depesz interesting point
<depesz>
I changed it to .join('lib') - but pathname itself says that + '...' is the correct way.
<Ziyan>
depesz you new to Ruby?
<depesz>
that depends. I'm using it for couple of years now, but it's not my daily driver.
<depesz>
i'm dba first. ruby is on distant third place.
jpn has joined #ruby
<Ziyan>
Don't worry about this stuff too much... Rubocop enforces a style. You can have your own style. Some organizations have their own style. For example, the first company I worked for had a style to go closely with their other languages. That way they similarity in styles of different languages.
<Ziyan>
Rubocop enforces one such style, which you can update.
<depesz>
well, the thing is that we want to have consistent style, so we are passing all our ruby scripts through rubocop.
<depesz>
over the years we accumulated many things in ruby, but they were never consistent. and now we're (kinda slowly) fixing this.
<depesz>
so, while I know I can make rubocop ignore Style/StringConcatenation error, i'd like to know why it shows this as a problem when I'm *not* dealing with strings.
<Ziyan>
You aid 'correct way', its that many prefer another way. You see standard libraries and find many Rubocop violations. You generate a Rails project, there will be many violations IIRC.
<depesz>
what would *you* do in this case?
<depesz>
we want to get to the place where all our ruby code passes rubocop (perhaps withsome custom config, that's fair game).
<depesz>
but *one*, *common* config of rubocop.
Ziyan has quit [Ping timeout: 248 seconds]
Ziyan has joined #ruby
<Ziyan>
depesz How I personally handle the code is I would build the path before (interpolation) and then use a variable with `$LOAD_PATH.unshift(path)`
<depesz>
Ziyan: and how would you build this path variable?
<depesz>
because it will complain that I do + for strings
s-liao-2000 has joined #ruby
rvalue has quit [Ping timeout: 248 seconds]
rvalue has joined #ruby
<Ziyan>
In your case, I would probably interpolate... there are times I need to build a path as I go, then I would just add Pathname objects... If you see the source code, it actually creates a new pathname object for the string you give and then `add` it to keep Rubocop off my tail 🚔
<havenwood>
ox1eef_: Yeah, they nest quite nicely: Process < Ractor < Thread < Fiber
<havenwood>
A Process with many Ractors, each Ractor with many Threads, each Thread with many Fibers.
<havenwood>
Webservers like Falcon already have that model.
<havenwood>
ox1eef_: At least the GVL is a Ractor-wide rather than Process-wide limit now.
<havenwood>
Actually, Falcon doesn't use Ractors — but otherwise shows the hierarchy.
<newton>
are there any good tuts/articles on using the combination? made me think of going through the elixir tut and I feel like they did a good job illustrating the difference and combination of processes/agents/etc
<newton>
wish I worked on anything that even required the knowledge, but like to have the stuff in my pocket
cek has joined #ruby
cek has left #ruby [#ruby]
<RickHull>
most times, you aren't using all 4. you have a process no matter what. if you want concurrency, reach for something below it. Fiber-shaped problems could just use Fibers directly. you might not want threads. you might not need Ractors. that's my guess anyway, barely having used Fibers or Ractors
<RickHull>
i'm curious what Fiber- and Ractor- shaped problems look like
ivanf has joined #ruby
ivanf has quit [Client Quit]
jpn has joined #ruby
<havenwood>
RickHull: Sharing ownership of things like ENV is problematic for Ractor. Ractors just aren't quite baked.
<havenwood>
It's not a "Global VM" lock anymore, so GVL isn't quite right. It's Ractor-wide, so maybe Ractor-Wide Lock ("RWL")? Just RL?
<havenwood>
We went from GIL to GVL over interpreter versus VM so really feels we should update for Ractors, heh.
<ox1eef_>
yes, probably, it often changes. at first it was GIL, then GVL, and now who knows what term will win.
<havenwood>
Nobody has coined a term for the new paradigm AFAIK.
<havenwood>
I think RWL.
<havenwood>
GWL?
<havenwood>
I mean, GRL.
<havenwood>
Global Ractor Lock.
<ox1eef_>
the discussions brings to mind, how cool it might be to have a concept of multiple VMs in one process
<havenwood>
It's not really even global, just to the Ractor, so "G" seems odd.
<havenwood>
I guess it's global to the Ractor, but uhg.
<havenwood>
ox1eef_: Isn't that what Ractors are?
<havenwood>
Ish.
<ox1eef_>
i'm in no position to say, i thought they were more coined on the Actor model.
<ox1eef_>
conceptually it seems easier to reason about multiple VMs, in a process, and a state going between the VMs -but then, a VM is probably very different. they wouldn't even have the same namespace, or methods available.
<ox1eef_>
a process is probably closest, when you fork you now have two VMs
<havenwood>
ox1eef_: The Ruby implementation feels a ton like multiple VMs in a single process though, with a bit of data sharing logic on top.
<ox1eef_>
sounds nice
<havenwood>
The docs even describe it like it's multiple VMs, and each has a GVL.
<havenwood>
"On CRuby (the default implementation), Global Virtual Machine Lock (GVL) is held per ractor, so ractors are performed in parallel without locking each other."
<havenwood>
ox1eef_: To me, that ^ suggests each Ractor is a VM to have its own Global VM Lock.
<ox1eef_>
a refactor itself is thread-based, though right ? each ractor being a thread ?
<havenwood>
If you consider a Ractor a VM, it makes sense to keep GVL, which is why I think there hasn't been a new term coined.
<ox1eef_>
my God, i can't stop misspelling it as refactor
<havenwood>
ox1eef_: No. Each Ractor VM has a main Thread, like each Process does.
<ox1eef_>
but, it's not a process? or it is?
<havenwood>
The Thread is within the Ractor, not the other way around.
<havenwood>
ox1eef_: A single process must have a minimum of a single Ractor, which has a single Thread.
<havenwood>
Each Ractor must have a main Thread.
<havenwood>
Each Process must have a main Ractor.
<ox1eef_>
so it's almost like a process, but technically it is not an OS process
<havenwood>
Yup.
<havenwood>
Like a green process.
<ox1eef_>
interesting
<havenwood>
And that's kinda very Actor model.
<havenwood>
Erlang Processes, etc.
<havenwood>
They do green processes.
<havenwood>
Funny that Fibers are green Threads and Ractors are green Processses.
<havenwood>
Then we make nested dolls.
<ox1eef_>
sounds promising, indeed
<havenwood>
I think it is. It's interesting that Ruby split its processing and I/O narratives.
<havenwood>
I think an Async- and Ractor-based alternative to the Thread- and Process-based Parallels gem is called for.
<havenwood>
Lighter weight on both counts.
<havenwood>
I guess we could update the existing gem too to account for the new paradigms.
<ox1eef_>
i can't deny a part of me thinks that some of this is rooted in rubyists not wanting to face tough problems, such as threaded or IPC programming, the roots for all this are already there but the knowledge is usually not.
dionysus69 has joined #ruby
<ox1eef_>
nice gist btw
dionysus69 has quit [Ping timeout: 248 seconds]
<ox1eef_>
havenwood: does it work with other Enumerable methods, like map?
<ox1eef_>
i think it might be interesting to have: PEnumerable (Parallel), AEnumerable (Async) for creating Enumerable collections that are automatically async or parallel when iterated over, then prepend/include them into things like Struct, Hash, Array, etc
michigan has quit [Quit: Connection closed for inactivity]
mixfix41 has joined #ruby
<havenwood>
ox1eef_: yeah, it does work with other Enumerable methods
<havenwood>
agreed the interface needs improvements. more explicit would be nice.
<havenwood>
also making it chainable.
<ox1eef_>
that's nice, very cool idea, i'm expermenting with it now too
bit4bit has quit [Quit: Leaving]
giorgian has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 240 seconds]
Rounin has quit [Ping timeout: 240 seconds]
<ox1eef_>
havenwood: btw looks like Parallel gem has added Ractor support