00:10 <rg> there's concurrent-ruby as well: https://github.com/ruby-concurrency/concurrent-ruby . The EM model is not for everyone, and if you want to use threads safely concurrent-ruby seems good although you could learn thread safe programming as well.

00:13 <rg> there's also of course Ractors now, in ruby3. i still havent used them.

00:37 <weaksauce> yeah concurrent-ruby was the first link ;)

00:38 <weaksauce> EM tends to work well for bots i think

00:38 <havenwood> BinaryVixen899: The Async gem is a good Ruby 3 way to do I/O.

00:40 <havenwood> See async-http for a great HTTP client using Fibers rather than Threads under the hood. https://github.com/socketry/async-http

00:41 <havenwood> Or see the example from the Ruby release notes. https://gist.github.com/havenwood/81e299ee2fddf7f5cf87be4af0c14b9d

00:42 <havenwood> Ractors are for parallel processing. They’re as heavy weight as a Thread and Async is a better choice for I/O.

00:42 <rg> weaksauce: sorry i missed that link

00:43 <havenwood> Async uses a pool of Fibers under the hood and can even suspend Falcon Fibers while they’re out for I/O.

00:43 <havenwood> Typhoeus is a solid HTTP client if you want concurrent I/O and HTTP/2 via more conventional measures (libcurl).

00:44 <havenwood> The async-http gem also supports HTTP/2 and is lower memory overhead if you don’t mind bleeding edge.

00:45 <havenwood> Here’s a spreadsheet I keep roughly up to date showing a number of HTTP client features for the sake of comparison. https://docs.google.com/spreadsheets/d/1vPlk6nMIFa3sI5ISl7zZ5r6lDNpVQX6Jxi3ksXCyVbs/edit?usp=sharing

00:45 <rg> net/http is still my go to.

00:45 <havenwood> Async gives net/http new legs.

00:45 <rg> cool

00:46 <havenwood> Just wrap it in a couple `Async do` blocks and you get Fiber-backed concurrency. Fancy!

00:46 <havenwood> The Ruby 3 Thread Scheduler is also by ioquatix, the author of Falcon and Async.

00:47 <havenwood> And the Fiber assembly implementations, the libio bindings, the Fiber pool, etc, etc.

00:47 <havenwood> Ioquatix is… impressive.

00:47 <rg> cool, tip my hat

00:51 <weaksauce> seems to really like concurrency

00:52 <rg> and ruby :D

01:52 <viole> I've been searching for a way to do column name translation in Sequel. I'm dealing with some fugly legaly DB that have unspeakable horrors I want to hide away behind a sanitized library where I serialize content and translate column names. I'm trying to do this with Sequel since I consider it to have the right balance between fancy stuff and control. So far I got serialization working, but I'm still

01:52 <viole> trying to get it to translate column names. Anyone has experience with this? I haven't found such a thing in the docs. Been browsing the gem codebase but still haven't found any plugin to do this

10:13 <keyvan> viole: i read all that and have been doing ruby programming since 2009 but ayyy i dunno what the hell you saying

10:34 <sagax> hi all

10:34 <sagax> why this do false?

10:34 <gr33n7007h> o/

10:34 <sagax> >> case String; when String; puts "TRUE"; else; puts "WRONG"; end

10:35 <sagax> do "wrong" way

10:35 <sagax> i know that String === String it's false, but how i can compare String and String with `case`?

10:45 <aesthetikx> sagax I have always wondered this myself

10:48 <aesthetikx> sagax looks like a trick is to do

10:48 <aesthetikx> case [String]

10:48 <aesthetikx> when [String]

10:48 <aesthetikx> wrapping it in an array tricks ===

10:49 <aesthetikx> or, use case whatever.to_s when 'String'

10:54 <aesthetikx> viole so are you saying that you want like DB[:cases] to use some horrible table name that is like 'legalDistrictCasesTable'?

11:15 <keyvan> gr33n7007h: o7

11:16 <keyvan> horruuuble

11:27 <adam12> viole: Might be worth posting to the sequel-talk mailing list.

13:06 <Na_Klar> I have a performance issue with my script: I str.each_byte two strings and compare the individual bytes with each others and store the result in a new string. The problem is, the longer the two string are the slower the process gets. Like the first MB runs very fast and with every further MB one MB needs more and more time. I checked the loop and there is no redundancy which could slow down. Everything runs in the memory and the bytesize of t

15:45 <jidar> aesthetikx: is there any reason you require the use of '===' over, say, '==' for comparing the values?

16:32 <nakilon> dude is gone. maybe the slow part in where he "stores results" on each iteration

17:43 <jidar> I was also thinking Na_Klar could use some computed hash for a set of 1/2 of the str.length

17:43 <jidar> but he'd need to understand data structures to make good use

20:04 <Guest51> #ruby-ru

20:34 <nakilon> hm, I swear that's not me, lol

20:35 <nakilon> probably having hard time learning how to IRC