« Back to channel list

#ruby - 14 May 2019

« Back 1 day Forward 1 day »
[00:07:56] jeremycw: has joined #ruby
[00:10:27] m_antis: has joined #ruby
[00:11:09] skryking: has joined #ruby
[00:15:00] r3m: has joined #ruby
[00:25:06] orbyt_: has joined #ruby
[00:31:59] budonyc: has joined #ruby
[00:36:11] altious: has joined #ruby
[00:36:56] djellemah: has joined #ruby
[00:38:44] haxx0r: has joined #ruby
[00:49:17] psyton: has joined #ruby
[01:00:59] cnsvc: has joined #ruby
[01:01:32] psyton: has joined #ruby
[01:30:19] Exuma: has joined #ruby
[01:35:27] altigraph: has joined #ruby
[01:36:07] Exuma: Does anyone know how I can use Digest::MD5.hexdigest in AES 128 CBC key+iv? It keeps telling me its not 16 bytes :/
[01:37:55] espinet: has joined #ruby
[01:41:30] mad_al: Post a code sample
[01:42:32] Exuma: @mad_al https://dpaste.de/TL50
[01:43:15] havenwood: Exuma: https://github.com/havenwood/encrypt/blob/master/lib/encrypt.rb#L5-L9
[01:44:00] Exuma: havenwood they require me to use a specific MD5 hash of a string they give me, not a random key. does that matter?
[01:45:07] havenwood: Exuma: you *can* do that, but you'd want to use #digest not #hexdigest, to get 16 bytes
[01:46:11] Exuma: havenwood so weird, im looking at their gem from 2014 and theyre using hexidigest. now that it hink about it, its probably just truncating it because i saw a GH issue about that (whereas now it raises)
[01:46:18] Exuma: which is hilarious that their own gem doesnt do that correct
[01:46:25] havenwood: Exuma: ooops!
[01:46:44] Exuma: havenwood what is 'non-repudiation'? theyre making me jump through all these hoops to do this
[01:46:53] Exuma: it seems stupid (it is for payment processing, similar to stripe token flow)
[01:47:13] havenwood: Exuma: that bug is a pretty big security flow ¯\_(ツ)_/¯
[01:47:48] ur5us: has joined #ruby
[01:47:52] havenwood: Exuma: bytes for hex characters is a small subset of bytes
[01:48:08] mad_al: "if the key is to be derived from a password, you should rely on PBKDF2 functionality provided by OpenSSL::PKCS5."
[01:48:40] mad_al: Might be a better option
[01:49:22] havenwood: Exuma: they used just 16 numbers, 16 times - rather than 256 numbers, 16 times
[01:50:03] Exuma: hahaha wow.. thats so bad. i think i saw it here: https://gist.github.com/rhenium/b81355fe816dcfae459cc5eadfc4f6f9
[01:51:08] havenwood: Exuma: ECB mode also leaks data
[01:51:34] Exuma: yeah, I'm not an expert at security but a lot of what I have to do for these payment processing gateways and whatnot seems extremely antiquated
[01:51:51] Exuma: like they have 10 pages devoted to this stupid encryption mumbo jumbo before sending it over an SSL connection
[01:51:51] havenwood: Exuma: hrmm
[01:51:57] Exuma: they said its because of "non repudiation"
[01:52:11] Exuma: and its funny because on their site, the password is on a different form submit than their username in the name of "security"
[01:52:26] Exuma: and the whole page is unstyled html (like 20 lines of css)
[01:52:32] Exuma: so Im like................. mmmmm ok, whatever you say
[01:52:33] havenwood: Exuma: I'd call that "signing"
[01:52:42] havenwood: But that's a super weird way to sign ¯\_(ツ)_/¯
[01:53:07] Exuma: The interface requires that much of the data submitted is encrypted. This is in addition to SSL encryption that exists
[01:53:07] Exuma: for all of the parameters. The purpose of this extra encryption is NOT to secure the data in transit (we trust SSL/TLS for that, and in fact the most
[01:53:08] Exuma: sensitive data is not encrypted by anything else.) Instead, this extra encryption is used to establish non-repudiation for the transaction, and to
[01:53:08] Exuma: protect SPI users from the potential that a response from the SPI might be ‘spoofed.’
[01:53:10] havenwood: Exuma: They should just use ed25519
[01:53:10] Exuma: oops sorry
[01:53:47] havenwood: https://gist.github.com/havenwood/e51db7a7fdb05b57100de17e5cf5ee84
[01:54:26] Mia: has joined #ruby
[01:54:26] Mia: has joined #ruby
[01:54:55] havenwood: JWTs are nice as a standard around signing.
[01:55:51] havenwood: https://gist.github.com/havenwood/e18de5fa23ec1c49e3feab493d579909
[01:58:55] i1nfusion: has joined #ruby
[02:02:09] dsmythe: has joined #ruby
[02:02:31] Exuma: havenwood ok thanks ill look at thees
[02:06:49] fphilipe_: has joined #ruby
[02:08:48] tdy1: has joined #ruby
[02:11:27] i1nfusion: has joined #ruby
[02:13:44] i1nfusion: has joined #ruby
[02:18:18] i1nfusion: has joined #ruby
[02:25:42] bambanx: has joined #ruby
[02:26:05] cnsvc: has joined #ruby
[02:33:38] crankharder: has joined #ruby
[02:33:42] cnsvc: has joined #ruby
[02:52:21] brool: has joined #ruby
[02:55:49] giraffe: has joined #ruby
[02:56:18] tpendragon: has joined #ruby
[02:58:42] djellemah: has joined #ruby
[03:00:02] esrse: has joined #ruby
[03:00:08] regedit: has joined #ruby
[03:10:59] braincrash: has joined #ruby
[03:20:50] Fusl: has joined #ruby
[03:25:40] doodlebug: has joined #ruby
[03:31:40] doodlebug: has joined #ruby
[03:32:26] syndikate: Is it a good practice to make use of lambdas and process in a big codebase? Apparently it's rails. I wanted to make some chained method calls look concise so I am declaring a lambda and passing it to one of the maps
[03:32:56] syndikate: But I am not sure how generally it is perceived, the codebase I am on doesn't have any lambda/proc usage as such.
[03:33:03] syndikate: Except for some builtin rails stuff
[03:37:40] doodlebug: has joined #ruby
[03:39:56] crankharder: has joined #ruby
[03:43:26] haxx0r76: has joined #ruby
[03:43:40] doodlebug: has joined #ruby
[03:49:40] doodlebug: has joined #ruby
[03:51:10] marz_d`ghostman: has joined #ruby
[03:52:27] ltd: has joined #ruby
[03:52:37] marz_d`ghostman: I have model say Customer, with initialize() parameters of (id, first_name, last_name, email, organization, phone, notes) but rubocop is saying I shouldn't have more than 5 parameters. What's the best way to refactor this?
[03:53:17] marz_d`ghostman: Calls to the initialize/.new() gives the ABC error from rubocop
[03:55:39] doodlebug: has joined #ruby
[03:59:06] rhuang_: has joined #ruby
[03:59:50] fphilipe_: has joined #ruby
[04:01:40] doodlebug: has joined #ruby
[04:07:40] doodlebug: has joined #ruby
[04:13:19] rhuang_: has joined #ruby
[04:13:46] doodlebug: has joined #ruby
[04:18:23] rhuang_: has joined #ruby
[04:18:28] doodlebug: has joined #ruby
[04:18:55] doodlebug: has joined #ruby
[04:19:20] doodlebug: has joined #ruby
[04:19:47] doodlebug: has joined #ruby
[04:20:17] doodlebug: has joined #ruby
[04:20:46] doodlebug: has joined #ruby
[04:21:15] doodlebug: has joined #ruby
[04:33:42] dellavg_: has joined #ruby
[04:39:46] tdy1: has joined #ruby
[04:41:15] haengma: has joined #ruby
[04:41:33] kapilp: has joined #ruby
[04:47:41] jenrzzz: has joined #ruby
[04:52:30] rhuang_: has joined #ruby
[04:52:36] dsmythe: has joined #ruby
[05:12:19] FancyEagle: has joined #ruby
[05:13:17] rhuang_: has joined #ruby
[05:16:59] espinet: has joined #ruby
[05:24:44] conta: has joined #ruby
[05:30:00] rhuang_: has joined #ruby
[05:30:00] cgfbee: has joined #ruby
[05:34:40] sauvin: has joined #ruby
[05:35:09] ur5us: has joined #ruby
[05:35:32] FancyEagle: has joined #ruby
[05:37:31] havenwood: syndikate: I'm curious about the details of the lambda.
[05:38:18] havenwood: syndikate: It may just be the first case in this codebase for this abstraction. Or maybe they're choosing to be more repetitive but explicit. I think it depends on the lambda.
[05:38:52] havenwood: marz_d`ghostman: Are they keyword arguments or regular arguments?
[05:39:24] FancyEagle: has joined #ruby
[05:39:31] havenwood: marz_d`ghostman: Definitely use keyword arguments.
[05:40:16] aupadhye: has joined #ruby
[05:40:27] duderonomy: has joined #ruby
[05:41:00] marz_d`ghostman: havenwood: I'm using keyword arguments, hence: item_id: name:, etc., but it's more than 5 parameters, is there an idiomatic way for it in ruby?
[05:41:45] havenwood: marz_d`ghostman: That is the idiomatic way. RuboCop has some rules that are like wishful thinking, that a domain never be so annoyingly complex.
[05:42:19] marz_d`ghostman: havenwood: Ah I see, thanks I'll just ignore it then, including the ABC warning hehe
[05:42:45] havenwood: marz_d`ghostman: You can always choose to set that data in a block or after initialization, but that's not _better_.
[05:43:31] marz_d`ghostman: Out of topic, I've stumbled upon this language: Elixir, which is very ruby-like. Are you into that as well?
[05:43:42] havenwood: Yes, I like Elixir.
[05:44:31] havenwood: marz_d`ghostman: Here's a silly project i did to implement some of the Elixir stdlib in Ruby: https://github.com/havenwood/elixir.rb
[05:44:32] syndikate: havenwood, here -> https://dpaste.de/7G00
[05:45:20] marz_d`ghostman: havenwood: Ah, nice. You're trying to integrate Elixir's power into Ruby, hehe
[05:46:19] marz_d`ghostman: I'm not that very efficient with Ruby, but I've tried it and it's a bit challenging to think in a functional paradigm. I haven't delved deep into it, but I already like it as well haha
[05:46:25] havenwood: syndikate: You could refactor `the_method` to avoid the `result_array`: activerecord_object.relations.map.with_index
[05:47:22] havenwood: syndikate: or you can do it the other way around: activerecord_object.relations.each_with_index.map
[05:48:01] havenwood: syndikate: I would probably extract `mainipulation_lambda` there to a constant.
[05:48:43] vondruch: has joined #ruby
[05:48:52] syndikate: havenwood, yeah okay. I just opted for the latter for now but I think the first looks more concise. How and why a constant havenwood ?
[05:48:53] haengma: has joined #ruby
[05:49:03] havenwood: syndikate: oh, that's the same method! i'm slow on the uptake...
[05:50:10] havenwood: syndikate: The how is easy, just declare it outside the mthod: MANIPULATION_LAMBDA = ->(x,y) { #multline, same definition }.freeze
[05:51:04] havenwood: syndikate: The why is to avoid creating the lambda each time you call the method. Instead of many lambda objects churning for many method calls, they can all use the single lambda constant that was instanciated only once.
[05:51:39] havenwood: syndikate: A block handily never instanciates an object.
[05:51:52] al2o3-cr: syndikate: why not just: activerecord_object.relations.map.with_index { |x, i| manipulation_method(x, i) }
[05:52:02] havenwood: syndikate: that ^
[05:52:44] syndikate: Oh, okay. I thought so. I didn't get this part "A block handily never instanciates an object".
[05:53:22] syndikate: al2o3-cr, havenwood I could do that. I changed that to this, this felt a little more concise for me, maybe coz I was taking some elixir lessons.
[05:53:34] syndikate: I wasn't sure if I should go down this route actually, that's why I thought to ask :D
[05:54:38] havenwood: syndikate: A `proc {` or `->{` proc or lambda creates a new instance of a Proc object. The reason for a block is to have a similar function but never allocate an object.
[05:55:05] rubydoc: # => #<Proc:0x00005632915de1b0@-e:2 (lambda)> (https://carc.in/#/r/6wy3)
[05:55:22] al2o3-cr: ACTION can't believe he's still up watching netflix
[05:56:16] syndikate: OH, okay. havenwood so even if I make it a constant and define it outside, would it still have the issue or allocation objects again?
[05:56:44] reber: has joined #ruby
[05:57:02] havenwood: syndikate: A single proc or lambda is no big deal at all. The reason to make it constant is to just ensure there's only one of them, no unnecessary copies.
[05:57:50] havenwood: syndikate: If the method is called a million times, no reason to create a million procs that you destroy each time the method call is over
[05:58:04] havenwood: syndikate: You can just call a proc constant a million times. One proc, reused.
[05:59:20] syndikate: Yeah okay. I will make it a constant outside the method at the class level so that one lambda is instantiated when the object is instantiated and will be called in the map
[05:59:52] syndikate: Then again, is it okay if I go down this route in ruby code? I mean for me it makes the whole .map.with_index looks better havenwood
[06:01:02] havenwood: syndikate: You can .map.with_index either way. The question then is whether to use a block, or a lambda constant. The block is appealing, unless you want to dry up that same block being reused. Then, a lambda constant is a nice way.
[06:01:20] havenwood: syndikate: Do multiple methods share the block?
[06:01:23] dsmythe: has joined #ruby
[06:01:30] havenwood: syndikate: If not, just use a block.
[06:03:13] syndikate: havenwood, no it doesn't, but what am trying to do is reduce the number of methods with all this. Right now I could remove one method if I make this chained call concise with lambda and move the call upto the parent method
[06:04:41] syndikate: I think am at borderline overdoing stuff
[06:05:04] havenwood: syndikate: https://dpaste.de/8KHk
[06:06:35] IanMalcolm: has joined #ruby
[06:06:38] havenwood: syndikate: It looks like you're heading down the right path for refactoring. From what you've shown though, it should probably just be a block.
[06:07:05] havenwood: syndikate: It doesn't look like there's a good reason to extract a lambda.
[06:07:23] rhuang_: has joined #ruby
[06:07:33] jenrzzz: has joined #ruby
[06:07:48] syndikate: Ah okay, gotcha. Yeah, the only reason for lambda is for the syntactic sugar of being able to call it like (&lambda_name)
[06:08:22] havenwood: syndikate: The & will pass the lambda as a block, instead of as an argument
[06:08:42] havenwood: syndikate: it also calls #to_proc (which just returns the lambda itself)
[06:09:22] havenwood: syndikate: but it's why you can do: &:a_symbol
[06:10:11] havenwood: &>> :abs2.to_proc.call 42
[06:10:12] rubydoc: # => 1764 (https://carc.in/#/r/6wy4)
[06:10:23] havenwood: &>> [1, 2, 3].map &:abs2
[06:10:23] rubydoc: # => [1, 4, 9] (https://carc.in/#/r/6wy5)
[06:10:33] d^sh: has joined #ruby
[06:11:02] havenwood: syndikate: The block is the special form, where no object is allocated. That's the usual case.
[06:11:46] havenwood: syndikate: The lambda is when you want to allocate an object. If you're reusing a block between many methods, you may want to do that to dry things up. Also, a lambda can be passed around as an argument. You can have multiple lambda arguments, etc.
[06:12:06] DTZUZO: has joined #ruby
[06:12:15] havenwood: You can only have one block.
[06:13:55] al2o3-cr: syndikate: in ruby 2.7 you can do: activerecord_object.relations.map.with_index(&.:manipulation_method))
[06:14:32] al2o3-cr: if you are using methods
[06:15:03] FancyEagle: has joined #ruby
[06:15:39] i1nfusion: has joined #ruby
[06:17:06] al2o3-cr: havenwood: is that syntax right?
[06:17:37] havenwood: al2o3-cr: that'd be: the &method(:manipulation_method)
[06:17:58] al2o3-cr: havenwood: no, i mean for ruby 2.7?
[06:18:26] havenwood: al2o3-cr: the `.` in `.:` is only shorthand for `.method()`
[06:19:01] havenwood: al2o3-cr: self.:puts #=> #<Method: main.puts>
[06:19:12] havenwood: identical to: self.method(:puts)
[06:19:26] al2o3-cr: havenwood: yeah, just looked wrong to me for a minute then
[06:21:02] havenwood: al2o3-cr: (self).:<=>.(self) #=> 0
[06:21:10] havenwood: but yeah, funny the `.` just means `.method`
[06:21:24] havenwood: i thought it should mean `.public_method`, but a little more flexible this way
[06:21:35] marz_d`ghostman: Is there a different scope for controllers in Rails? I have something initialized during bootup, but it appears it isn't when it comes to the controller.
[06:22:01] al2o3-cr: havenwood: ah, yeah. didn't think of that.
[06:22:41] marz_d`ghostman: I have it initialized under config/initializers/ https://gist.github.com/marzdgzmn/e1b979f19cf6b1b4f66f04cf31c354fe. My models can access it, but it's nil when accessing via controllers.
[06:23:33] al2o3-cr: havenwood: (self).:<=>.(self) why is that return 0
[06:24:18] havenwood: al2o3-cr: self <=> self #=> 0
[06:24:41] havenwood: &>> self.method(:<=>).(self)
[06:24:42] rubydoc: # => 0 (https://carc.in/#/r/6wy6)
[06:24:52] al2o3-cr: oh yeah, silly me
[06:24:59] al2o3-cr: couldn't see it then
[06:25:01] havenwood: &>> self <=> self
[06:25:02] rubydoc: # => 0 (https://carc.in/#/r/6wy7)
[06:25:15] al2o3-cr: i see it now
[06:25:38] al2o3-cr: short hand call
[06:28:39] syndikate: havenwood, bit detailed (sorry) but here is what exactly am doing - https://dpaste.de/AyQZ#L1
[06:29:11] havenwood: marz_d`ghostman: Dunno why the initializer wouldn't seem to have run from a controller? What's the controller code that's not working as expected?
[06:30:27] marz_d`ghostman: havenwood: So in initializer I have that code. Then under controller I tried to `puts` to test it's connection via Podio.connection.nil? and it is nil. I did the same thing under initializer where I `puts` the same thing and it isn't in there
[06:32:12] havenwood: syndikate: You could actually put your lambda in a `def manipulation_lambda`, but unlike a constant, that would create a new lambda each time you called the method. If that doesn't make sense, I can show examples.
[06:33:02] havenwood: syndikate: I do think you can get away with a block: .with_index { |x, y| x.abstracted_method(y) }
[06:33:54] havenwood: &>> def double; -> n { n * 2 } end; [1, 2, 3].map &double # for example, a method works
[06:33:54] syndikate: havenwood, yeah the block makes much more sense here. I was just going through the code again. The reason why I opted for lambda first of all is because I could do that &method here. I can't do that if defined a method as def method; end.
[06:33:55] rubydoc: # => [2, 4, 6] (https://carc.in/#/r/6wy8)
[06:33:56] al2o3-cr: no, they'd have inject
[06:34:38] syndikate: But that's again defining a method which has a lambda inside it right? As you said this is gonna create a lambda every time - there is not advantage to this right?
[06:34:40] nowhere_man: has joined #ruby
[06:35:07] havenwood: syndikate: right, you don't want to do that, typically - you want to reduce unnecessary object creation
[06:35:36] havenwood: syndikate: anything you can declare up front and freeze, do it!
[06:36:10] havenwood: MANIPULATION_LAMBDA = ->(x,y) { x.abstracted_method(y) }.freeze
[06:36:27] syndikate: The only advantage of lambda for me here is the syntactic sugar
[06:36:43] syndikate: Ah okay, yeah noted the point regarding freeze.
[06:37:02] havenwood: syndikate: What advantage does it have though over a block?
[06:37:32] havenwood: syndikate: .with_index { |x, y| x.abstracted_method(y) }
[06:38:12] syndikate: Yeah I am changing to this, I can prevent a lambda creation here ^
[06:38:17] havenwood: syndikate: +1
[06:39:17] havenwood: syndikate: An advantage of extracting the lambda might be being able to name that operation. This is just what blocks are for though, so it's a good use here.
[06:40:45] syndikate: Ah okay, but if I am abstracting it out to the model then the lambda has no much use case, right?
[06:41:13] havenwood: syndikate: Usually blocks suffice nicely.
[06:41:58] rhuang_: has joined #ruby
[06:43:07] nowhereman: has joined #ruby
[06:43:23] FancyEagle: has joined #ruby
[06:43:53] lxsameer: has joined #ruby
[06:43:59] havenwood: marz_d`ghostman: The Podio #connection checks #client, which is a fiber-local variable: https://github.com/podio/podio-rb/blob/master/lib/podio.rb#L23
[06:44:46] havenwood: marz_d`ghostman: Maybe a different thread is handling the connection?
[06:45:56] syndikate: Yeah, so if I am not moving that abstraction to the model, i.e keeping that manipulation method definition in the current class itself maybe I could have a named lambda and re-use it. Now that I have moved it I guess a block is good enough. Is my understanding correct havenwood ?
[06:46:38] fphilipe_: has joined #ruby
[06:47:38] havenwood: syndikate: A block is typically best. It's the common case that has a special syntax, a block with no need for a discrete object. The lambda is more of an edge case, where you would need to pass a block around or need more than one block, etc.
[06:47:55] havenwood: syndikate: blocks are usually what you turn to first
[06:48:27] FancyEagle: has joined #ruby
[06:49:50] marz_d`ghostman: havenwood: I don't think so, I just have this on my controller: https://gist.github.com/marzdgzmn/b96ec27971e789da60a55e2ce48b5f29
[06:51:13] havenwood: marz_d`ghostman: The problem is that when you initialize Podio, it sets itself up _only_ on the current thread.
[06:51:33] havenwood: marz_d`ghostman: From a second thread, it's not setup.
[06:52:01] havenwood: marz_d`ghostman: Assuming you're using a multithreaded webserver, like Puma.
[06:52:15] conta: has joined #ruby
[06:52:30] havenwood: marz_d`ghostman: Podio is literally setting up its connection on the current Thread only.
[06:52:44] marz_d`ghostman: havenwood: Ah, yeah, I'm using Puma
[06:53:24] havenwood: marz_d`ghostman: It'd work if you were in single threaded mode, but with multiple threads the Podio setup isn't affecting any thread other than the one it was initialized on
[06:53:24] marz_d`ghostman: havenwood: Is there a way for me to cascade that initialized Podio to every thread created to handle requests?
[06:53:32] syndikate: Ah okay. So I should see it as more of a requirement for a first class citizen to be passed around.
[06:53:38] marz_d`ghostman: havenwood: I just got it, so Puma creates a different thread for every request received.
[06:54:10] havenwood: marz_d`ghostman: It uses a thread pool by default, so any thread in that pool might handle a request.
[06:54:21] hightower3: has joined #ruby
[06:54:37] havenwood: marz_d`ghostman: https://github.com/puma/puma/blob/master/lib/puma/thread_pool.rb
[06:55:29] marz_d`ghostman: havenwood: Is there a way to cascade the initialized Podio out to the threads?
[06:55:37] havenwood: marz_d`ghostman: Podio is actually using a Fiber-local variable, not even a Thread-local variable, but the issue is the same - only seeing it from the current Thread.
[06:57:22] havenwood: marz_d`ghostman: One way would be to switch the Podio gem over to a nice connection pool setup instead, but that might be more work than you want to do. An easy way would be to setup the connection when you find there isn't one.
[06:58:36] marz_d`ghostman: havenwood: Wouldn't that be slow, given multiple requests. It will always try setting up the connection each time a request is received
[06:59:03] havenwood: marz_d`ghostman: Podio.connection.yield_self { |connection| connection || Podio.setup.connection }
[06:59:15] marz_d`ghostman: havenwood: fiber-local, now that's a new term for me. Have to search for that :)
[06:59:47] havenwood: &>> Thread.current[:hidden]; Fiber.new { Thread.current[:hidden] }.resume
[06:59:48] rubydoc: # => nil (https://carc.in/#/r/6wym)
[07:01:21] havenwood: I failed with that example. Failed to set the variable >.>
[07:01:24] havenwood: &>> Thread.current[:hidden] = 42; Fiber.new { Thread.current[:hidden] }.resume
[07:01:25] rubydoc: # => nil (https://carc.in/#/r/6wyn)
[07:01:51] havenwood: A thread local variable, on the other hand, can be seen from a fiber on the same thread:
[07:01:53] havenwood: &>> Thread.current.thread_variable_set(:fibers_can_see, 42); Fiber.new { Thread.current.thread_variable_get(:fibers_can_see) }.resume
[07:01:54] rubydoc: # => 42 (https://carc.in/#/r/6wyo)
[07:02:31] havenwood: But not from another thread:
[07:02:33] havenwood: &>> Thread.current.thread_variable_set(:fibers_can_see, 42); Thread.new { Thread.current.thread_variable_get(:fibers_can_see) }.value
[07:02:34] rubydoc: stderr: playpen: application terminated abnormally with signal 31 (Bad system call) (https://carc.in/#/r/6wyp)
[07:02:59] al2o3-cr: havenwood: because it's thread-local
[07:03:16] havenwood: marz_d`ghostman: Yeah: Podio.connection || Podio.setup.connection
[07:03:35] havenwood: al2o3-cr: Folk often conflate thread/fiber local.
[07:03:49] havenwood: al2o3-cr: Usually thinking fiber local is thread local ¯\_(ツ)_/¯
[07:04:18] havenwood: the syntax, i mean - often see fiber local get called thread local
[07:04:44] al2o3-cr: oh, sure. i've seen plenty of that about.
[07:05:12] yqt: has joined #ruby
[07:05:19] havenwood: al2o3-cr: it's one way to punt on those pesky multi-threaded connection problems!
[07:05:44] havenwood: if only one thread can see the connection, no other thread is going to cause chaos
[07:06:45] havenwood: by doing something unexpected, out of order, right in the middle of the request
[07:13:46] rhuang_: has joined #ruby
[07:14:25] al2o3-cr: havenwood: how did it work in 1.8 then?
[07:15:06] al2o3-cr: mind you, they were only green threads
[07:15:56] al2o3-cr: i try to keep well away from multi-threading :p
[07:16:14] cnsvc: has joined #ruby
[07:17:34] havenwood: al2o3-cr: fibers didn't exist back then, so green thread local only
[07:18:44] Ai9zO5AP: has joined #ruby
[07:18:53] kyrylo: has joined #ruby
[07:20:54] andikr: has joined #ruby
[07:22:05] al2o3-cr: havenwood: 👍
[07:25:13] jefffrails35: has joined #ruby
[07:27:04] giraffe: has joined #ruby
[07:27:08] tpendragon: has joined #ruby
[07:44:47] ovnimancer: has joined #ruby
[07:44:57] teclator: has joined #ruby
[07:55:29] za1b1tsu: has joined #ruby
[07:56:05] mikecmpbll: has joined #ruby
[07:56:05] crankharder: has joined #ruby
[08:01:56] marz_d`ghostman: havenwood: thanks, I'll try that.
[08:22:23] doodlebug: has joined #ruby
[08:22:50] doodlebug: has joined #ruby
[08:23:19] doodlebug: has joined #ruby
[08:23:48] doodlebug: has joined #ruby
[08:24:18] doodlebug: has joined #ruby
[08:24:44] doodlebug: has joined #ruby
[08:24:51] jenrzzz: has joined #ruby
[08:29:39] alem0lars: has joined #ruby
[08:39:23] zenspider: has joined #ruby
[08:39:29] rhuang_: has joined #ruby
[08:39:35] brendan-: has joined #ruby
[09:00:40] ramfjord: has joined #ruby
[09:01:24] dhollin3: has joined #ruby
[09:04:48] Mia: has joined #ruby
[09:04:49] Mia: has joined #ruby
[09:06:53] gloscombe: has joined #ruby
[09:07:27] alem0lars: has joined #ruby
[09:11:01] cnsvc: has joined #ruby
[09:26:20] NL3limin4t0r: has joined #ruby
[09:28:32] jefffrails35: has joined #ruby
[09:43:51] crankharder: has joined #ruby
[09:53:04] hightower3: has joined #ruby
[09:55:57] BH23: has joined #ruby
[09:56:42] Cthulu201: has joined #ruby
[10:06:30] cnsvc: has joined #ruby
[10:08:37] rhuang_: has joined #ruby
[10:12:12] sphenxes: has joined #ruby
[10:17:41] marz_d`ghostman: What's the best architecture for an app to constantly receive updates from another app? Does redis pub/sub a good fit?
[10:25:05] jenrzzz: has joined #ruby
[10:29:00] RedSnarf: has joined #ruby
[10:35:15] AJA4350: has joined #ruby
[10:39:57] GodFather_: has joined #ruby
[10:40:04] GodFather: has joined #ruby
[10:41:20] valadares: has joined #ruby
[10:48:29] Omnilord: has joined #ruby
[10:49:59] conta: has joined #ruby
[10:57:42] funnel: has joined #ruby
[11:00:00] BH23: has joined #ruby
[11:00:40] Cthulu201: has joined #ruby
[11:05:16] mrtyr: has joined #ruby
[11:06:19] cnsvc: has joined #ruby
[11:30:37] cd: has joined #ruby
[11:34:49] Jonopoly: has joined #ruby
[11:37:02] laaron: has joined #ruby
[11:38:25] AJA4350: has joined #ruby
[11:40:08] yqt: has joined #ruby
[11:51:08] Swyper: has joined #ruby
[11:51:28] i1nfusion: has joined #ruby
[11:58:50] jefffrails35: has joined #ruby
[11:59:18] dviola: has joined #ruby
[12:03:55] wald0: has joined #ruby
[12:03:57] vondruch: has joined #ruby
[12:09:44] rhuang_: has joined #ruby
[12:11:16] cnsvc: has joined #ruby
[12:16:36] za1b1tsu: has joined #ruby
[12:23:41] griffindy: has joined #ruby
[12:25:23] jenrzzz: has joined #ruby
[12:26:08] doodlebug: has joined #ruby
[12:26:52] doodlebug: has joined #ruby
[12:28:23] doodlebug: has joined #ruby
[12:28:52] doodlebug: has joined #ruby
[12:29:52] doodlebug: has joined #ruby
[12:30:38] doodlebug: has joined #ruby
[12:31:33] agent_white: has joined #ruby
[12:50:15] vondruch: has joined #ruby
[12:54:47] z64: marz_d`ghostman redis is indeed one way to do this over something like pub/sub. plenty of other options to weigh though that depends on your use case; there's also services like rabbitmq, or you could roll something simple with a local unix socket, etc.
[12:56:13] nakuku: has joined #ruby
[12:56:49] mnemon: yeah, event queues like rabbitmq and kafka are pretty much made for that
[12:58:19] nakuku: Hello, How do i get just the time zone name from a string? get_timezone("2012-02-01T18:00:00-09:00") => -09:00 or Alaska
[13:06:39] alem0lars_: has joined #ruby
[13:14:10] Emmanuel_Chanel: has joined #ruby
[13:14:38] cnsvc: has joined #ruby
[13:27:48] doodlebug: has joined #ruby
[13:28:06] doodlebug: has joined #ruby
[13:46:45] andikr: has joined #ruby
[13:48:36] SeepingN: has joined #ruby
[14:08:24] jefffrails35: has joined #ruby
[14:13:15] hightower3: has joined #ruby
[14:13:41] cnsvc: has joined #ruby
[14:18:21] rhuang_: has joined #ruby
[14:20:54] dviola: has joined #ruby
[14:27:20] jeremycw: has joined #ruby
[14:31:19] tdy1: has joined #ruby
[14:31:54] laaron: has joined #ruby
[14:34:53] Dbugger: has joined #ruby
[14:39:53] cthulchu: has joined #ruby
[14:49:55] apparition: has joined #ruby
[14:53:31] dviola: has joined #ruby
[14:53:40] chromis: has joined #ruby
[15:01:50] valadares: has joined #ruby
[15:02:12] polishdub: has joined #ruby
[15:04:57] marz_d`ghostman: z64: Ah kafka seems nice. I'm not that familiar with unix sockets though
[15:05:07] octos: has joined #ruby
[15:06:14] yoshida: has joined #ruby
[15:19:26] dsmythe: has joined #ruby
[15:20:42] nima_m: has joined #ruby
[15:21:43] cnsvc: has joined #ruby
[15:24:35] altious2: has joined #ruby
[15:24:51] wald0: has joined #ruby
[15:26:47] dsmythe: has joined #ruby
[15:39:14] Exuma: has joined #ruby
[15:41:40] tdy: has joined #ruby
[15:42:19] tf2ftw2: has joined #ruby
[15:43:19] dhuey: has joined #ruby
[15:48:01] bsdbandit: has joined #ruby
[15:48:31] Exuma: has joined #ruby
[15:50:36] clemens3: has joined #ruby
[15:52:54] reber: has joined #ruby
[15:56:23] ep4sh2k__: has joined #ruby
[16:03:36] brool: has joined #ruby
[16:04:40] laaron: has joined #ruby
[16:05:29] haengma: has joined #ruby
[16:06:29] haengma: has joined #ruby
[16:22:18] sidekiqfail: has joined #ruby
[16:22:43] sidekiqfail: https://github.com/mperham/sidekiq/issues/4168
[16:22:53] sidekiqfail: does anybbody know why my sidekiq won't work?
[16:24:20] cnsvc: has joined #ruby
[16:25:54] jenrzzz: has joined #ruby
[16:25:58] Jello_Raptor: has joined #ruby
[16:31:51] doodlebug: has joined #ruby
[16:36:59] rippa: has joined #ruby
[16:38:39] AJA4351: has joined #ruby
[16:41:26] havenwood: side, okay then
[16:41:34] rhuang_: has joined #ruby
[16:42:07] phaul: they just changed name, now they are haxx0r
[16:42:15] moei: has joined #ruby
[16:42:28] havenwood: phaul: ahh, i silence all the name noise - oops!
[16:42:57] havenwood: haxx0r: What part of it doesn't work? Why are you making and calling a lambda?
[16:43:57] havenwood: haxx0r: It'd be the same result if you just removed the lambda: top = Sms.otp_from_ref(ref)
[16:44:09] havenwood: haxx0r: What's the lambda meant to be doing there? I'm confused.
[16:49:14] ovnimancer: has joined #ruby
[17:00:25] rhuang: has joined #ruby
[17:03:15] octos: has joined #ruby
[17:05:02] kapilp: has joined #ruby
[17:07:39] zxq2: is there a TLS implementation written in ruby? it doesn't matter if it's minimal. obviously openssl is not a candidate since there are bindings.
[17:08:13] zxq2: searched around, didn't see anything
[17:09:24] doodleb86: has joined #ruby
[17:12:46] jenrzzz: has joined #ruby
[17:13:11] duderonomy: has joined #ruby
[17:20:43] valadares: has joined #ruby
[17:21:24] tdy: has joined #ruby
[17:25:20] duderonomy: has joined #ruby
[17:27:41] tdy: has joined #ruby
[17:30:17] cnsvc: has joined #ruby
[17:31:55] darix: zxq2: why not use the openssl bindings?
[17:32:08] darix: zxq2: I dont think there are production ready pure ruby implementations
[17:33:23] doodlebug: has joined #ruby
[17:34:00] Zinefer: has joined #ruby
[17:35:10] Zinefer: i am working inside a rails task (so there's no class) and i have defined a method that accepts a block ... everything works fine until i define a lamba or proc and pass that into the method as a block ... the proc gets called but it seems like all method calls inside that proc get a nil appended onto the end of the method arguments
[17:35:28] Zinefer: this is preventing me from calling any method that cares about how many arguments are passed to it
[17:37:09] Zinefer: my hunch is that nil is some reference to a non-existent self
[17:39:24] doodlebug: has joined #ruby
[17:40:05] Zinefer: https://dpaste.de/zLVK
[17:40:07] dhuey: has joined #ruby
[17:43:44] gix: has joined #ruby
[17:45:24] doodlebug: has joined #ruby
[17:45:41] dsmythe: has joined #ruby
[17:48:25] sameerynho: has joined #ruby
[17:51:25] doodlebug: has joined #ruby
[17:55:14] GodFather: has joined #ruby
[17:55:44] GodFather_: has joined #ruby
[17:57:24] doodlebug: has joined #ruby
[17:59:26] ramfjord: has joined #ruby
[18:01:08] cow[moo]: has joined #ruby
[18:03:08] haengma: has joined #ruby
[18:05:58] dhuey: has joined #ruby
[18:06:32] teclator_: has joined #ruby
[18:12:11] tdy: has joined #ruby
[18:20:42] gix-: has joined #ruby
[18:20:56] cnsvc: has joined #ruby
[18:23:29] jenrzzz: has joined #ruby
[18:32:47] adam12: zinefer: The exception is on that Trip.create! line you annotated?
[18:33:44] Xeago_: has joined #ruby
[18:34:02] haengma: has joined #ruby
[18:38:22] tf2ftw: has joined #ruby
[18:40:28] adam12: zinefer: I digested it down into something runnable and it works as expected. https://gist.github.com/5ca0263e205ae4aecbdde7cc5ada0f42 Maybe it's something else specific to your setup.
[18:40:31] adam12: tf2ftw: o/
[18:49:31] yqt: has joined #ruby
[18:50:51] jeremycw: has joined #ruby
[18:51:10] teclator__: has joined #ruby
[18:51:24] [Butch]: has joined #ruby
[18:55:46] teclator_: has joined #ruby
[18:55:47] teclator__: has joined #ruby
[18:55:56] zapata: has joined #ruby
[18:58:49] mikecmpbll: has joined #ruby
[19:06:45] espinet: has joined #ruby
[19:09:38] jenrzzz: has joined #ruby
[19:14:50] haengma: has joined #ruby
[19:28:44] lypsis: has joined #ruby
[19:30:16] lypsis: has joined #ruby
[19:31:02] tf2ftw: Is there a way to generate a Tempfile path without creating a Tempfile?
[19:31:51] octos: has joined #ruby
[19:32:01] griffindy: has joined #ruby
[19:33:59] ovnimancer: has joined #ruby
[19:39:36] reber: has joined #ruby
[19:44:05] dsmythe: has joined #ruby
[19:47:00] AJA4350: has joined #ruby
[19:47:45] adam12: tf2ftw: Would you rather a normal File? Fairly sure the premise of Tempfile is that it's created when requested, since if not there could be a potential race condition if the new filename could be predicted.
[19:49:42] Zinefer: adam12: sorry for the slow reply, i went to lunch :( checking out your gist now
[19:50:06] tf2ftw: I'm mostly interested in tapping into the System's temp source. That being said, I _could_ just create a Tempfile then close it right away but that's not my desire.
[19:50:27] adam12: tf2ftw: If you just need some sort of random looking filename like Tempfile would produce, you could probably recreate it yourself by pairing Dir.tmpdir + $$ + something else?
[19:50:59] adam12: &>> require "tmpdir"; File.join(Dir.tmpdir, "yourapp", $$)
[19:51:05] rubydoc: stderr: playpen: timeout triggered! (https://carc.in/#/r/6x16)
[19:51:26] tf2ftw: Ahh.. require 'tmpdir
[19:51:34] tf2ftw: Excellent. Thank you adam12
[19:52:05] adam12: &>> require "tmpdir"; File.join(Dir.tmpdir, "yourapp.#{$$}")
[19:52:06] rubydoc: # => "/tmp/yourapp.1" (https://carc.in/#/r/6x17)
[19:52:19] adam12: tf2ftw: Yeah. It's tucked away.
[19:52:54] tf2ftw: I was surprised to not see Tempdir.path or the like.. but happy to know about tmpdir now!
[19:53:30] adam12: tf2ftw: Kinda surprised myself tbh, but there's probably a ton of legacy behind why it was placed where it was.
[19:54:06] phaul: as a side note predictable temp file names are security hole. and $$ is predictable
[19:55:05] phaul: depends on your needs, for a single user desktop and one user script it doesn't matter.
[19:55:07] adam12: phaul: Good point.
[19:55:39] doodleb32: has joined #ruby
[19:55:50] adam12: I like knowing which pid created what, so adding another bit of entropy to the string wouldn't hurt. SecureRandom.alphanumeric(8) or something.
[19:57:12] tf2ftw: My use case is someone uploads a CSV and the backend does some "magic" which eventually saves a zip containing the csv. I'm intercepting the uploaded file and replacing it with the zip after its temporarily created. Not sure if that makes sense but that's the situation.
[19:57:48] kyrylo: has joined #ruby
[19:59:20] tf2ftw: I need the file to persist long enough to not be GCed during that process.
[19:59:46] tf2ftw: Correct me if I'm wrong but the system will clean up the temp dir for me right?
[20:00:10] Zinefer: adam12: you are right, the error is only thrown when the activerecord is involved
[20:00:45] Zinefer: i thought of a way to solve this in a better way with just a loop over lunch so i don't think i am going to pursue this further, i very much appreciate your help though
[20:01:10] adam12: zinefer: yw.
[20:01:32] adam12: tf2ftw: I believe Ruby will prune Tempfile instances on exit.
[20:01:43] adam12: tf2ftw: And of course, some OS's ship with a tmp cleaner.
[20:02:25] adam12: tf2ftw: If you want to guarantee persistence, maybe look at storing it somewhere you can control and make the filename obtuse. Hash the file and split into a namespace, etc. Probably many ways to do it.
[20:02:38] haengma: has joined #ruby
[20:03:53] tf2ftw: Ruby will GC once the Tempfile loses scope (which is nice) but doesn't help when returning as an object.
[20:06:37] nima_m: has joined #ruby
[20:06:48] gix: has joined #ruby
[20:11:41] RiPuk: has joined #ruby
[20:16:23] i1nfusion: has joined #ruby
[20:22:39] sgen: has joined #ruby
[20:22:58] altious: has joined #ruby
[20:25:39] doodlebug: has joined #ruby
[20:26:52] Kestrel-029: has joined #ruby
[20:30:50] fphilipe_: has joined #ruby
[20:31:40] doodlebug: has joined #ruby
[20:37:40] doodlebug: has joined #ruby
[20:41:41] Nicmavr: has joined #ruby
[20:43:40] doodlebug: has joined #ruby
[20:44:50] yqt: has joined #ruby
[20:46:21] haengma: has joined #ruby
[20:49:40] doodlebug: has joined #ruby
[20:49:54] jenrzzz: has joined #ruby
[20:50:45] klaas: has joined #ruby
[20:51:55] zxq2: darix, because i need to work with the internals of the TLS impl. in ruby. that's why i cannot use the openssl bindings.
[20:52:05] zxq2: thanks anyway
[20:52:32] nowhereman: has joined #ruby
[20:52:35] ur5us: has joined #ruby
[20:53:32] zxq2: darix, they don't need to be production ready. they can be minimal/experimental.
[20:55:40] doodlebug: has joined #ruby
[20:56:59] nowhere_man: has joined #ruby
[20:57:58] zacts: has joined #ruby
[21:01:40] doodlebug: has joined #ruby
[21:07:25] fphilipe_: has joined #ruby
[21:07:40] doodlebug: has joined #ruby
[21:10:09] haengma: has joined #ruby
[21:11:20] ellcs: has joined #ruby
[21:12:17] ellcs: has joined #ruby
[21:13:08] haengma: has joined #ruby
[21:13:13] ellcs: has joined #ruby
[21:13:40] doodlebug: has joined #ruby
[21:13:42] ellcs: has joined #ruby
[21:15:15] tdy1: has joined #ruby
[21:16:11] AJA4350: has joined #ruby
[21:19:40] doodlebug: has joined #ruby
[21:25:40] doodlebug: has joined #ruby
[21:26:05] cnsvc: has joined #ruby
[21:26:41] Nicmavr: has joined #ruby
[21:28:33] jenrzzz: has joined #ruby
[21:31:40] doodlebug: has joined #ruby
[21:33:19] sgen_: has joined #ruby
[21:34:36] altious2: has joined #ruby
[21:37:37] cloaked1: has joined #ruby
[21:37:40] doodlebug: has joined #ruby
[21:41:37] Kestrel-029: has joined #ruby
[21:43:41] doodlebug: has joined #ruby
[21:43:57] houhoulis: has joined #ruby
[21:48:35] robotcars: has joined #ruby
[21:56:10] tdy1: has joined #ruby
[22:06:19] code_zombie: has joined #ruby
[22:07:10] pwnd_nsfw: has joined #ruby
[22:07:40] doodlebug: has joined #ruby
[22:11:36] Nicmavr: has joined #ruby
[22:13:40] doodlebug: has joined #ruby
[22:19:40] doodlebug: has joined #ruby
[22:24:40] AJA4351: has joined #ruby
[22:25:40] doodlebug: has joined #ruby
[22:31:40] doodlebug: has joined #ruby
[22:37:41] doodlebug: has joined #ruby
[22:43:39] doodlebug: has joined #ruby
[22:49:40] doodlebug: has joined #ruby
[22:55:40] doodlebug: has joined #ruby
[22:55:49] espinet: has joined #ruby
[22:56:41] Nicmavr: has joined #ruby
[23:01:40] doodlebug: has joined #ruby
[23:07:40] doodlebug: has joined #ruby
[23:11:37] Kestrel-029: has joined #ruby
[23:13:41] doodlebug: has joined #ruby
[23:17:49] Tempesta: has joined #ruby
[23:19:41] doodlebug: has joined #ruby
[23:19:50] postmodern: has joined #ruby
[23:25:40] doodlebug: has joined #ruby
[23:31:41] doodlebug: has joined #ruby
[23:35:10] jenrzzz: has joined #ruby
[23:37:32] haengma: has joined #ruby
[23:37:36] ramfjord: has joined #ruby
[23:37:40] doodlebug: has joined #ruby
[23:39:22] haengma: has joined #ruby
[23:43:14] jenrzzz_: has joined #ruby
[23:43:40] doodlebug: has joined #ruby
[23:49:40] doodlebug: has joined #ruby
[23:52:21] weteamsteve: has joined #ruby
[23:55:40] doodlebug: has joined #ruby
[23:59:27] Swyper: has joined #ruby