« Back to channel list

#ruby - 08 June 2018

« Back 1 day Forward 1 day »
[00:04:47] ramfjord_: has joined #ruby
[00:07:15] Creatornator: has joined #ruby
[00:09:18] akem2: has joined #ruby
[00:12:21] ramfjord: has joined #ruby
[00:17:57] Scriptonaut: has joined #ruby
[00:18:16] Scriptonaut: hey all, I was curious, are there any good terminal interface libraries other than ncurses?
[00:18:43] Scriptonaut: I have always found ncurses to be pretty unintuitive, and figured by now there must be some other good quailty gems for writing terminal applications
[00:29:17] ciscam: has joined #ruby
[00:30:17] eckhardt_: has joined #ruby
[00:31:18] nertzy: has joined #ruby
[00:37:44] BlopMonster: has joined #ruby
[00:40:33] kmurphy4_: has joined #ruby
[00:47:28] chamar: has joined #ruby
[00:50:07] cconstantine: has joined #ruby
[00:53:37] pabs: has joined #ruby
[00:54:36] ur5us: has joined #ruby
[01:05:03] gizmore: has joined #ruby
[01:11:28] zapata: has joined #ruby
[01:12:23] dendazen: has joined #ruby
[01:18:30] chamar: has joined #ruby
[01:19:47] dendazen: has joined #ruby
[01:29:42] beefjoe: has joined #ruby
[01:32:47] Mike11: has joined #ruby
[01:44:41] jrafanie: has joined #ruby
[01:49:38] matthewd: has joined #ruby
[01:53:22] syndikate: has joined #ruby
[01:55:10] jready: has joined #ruby
[02:01:50] shinnya: has joined #ruby
[02:05:01] t0xik: has joined #ruby
[02:06:19] karapetyan: has joined #ruby
[02:21:53] ciscam: has joined #ruby
[02:25:50] bmurt: has joined #ruby
[02:38:50] BlopMonster: has joined #ruby
[02:41:22] duderonomy: has joined #ruby
[03:00:08] cadillac_: has joined #ruby
[03:00:44] darkhanb: has joined #ruby
[03:00:57] dreamthese: has joined #ruby
[03:10:20] braincrash: has joined #ruby
[03:22:24] duderonomy: has joined #ruby
[03:54:01] tdy: has joined #ruby
[03:59:13] za1b1tsu: has joined #ruby
[04:07:52] karapetyan: has joined #ruby
[04:16:39] bipul: has joined #ruby
[04:26:09] TheBetrayer: has joined #ruby
[04:28:00] Sonia: has joined #ruby
[04:36:59] Creatornator: has joined #ruby
[04:39:30] ciscam: has joined #ruby
[04:46:29] BlopMonster: has joined #ruby
[04:53:22] dminuoso: Who here is familiar with STM?
[04:54:19] havenwood: dminuoso: Who isn't?!
[04:54:38] dminuoso: Hah. Too few it seems.
[04:54:51] dminuoso: havenwood: Care to look at something for me? I cant read ruby code.
[04:55:19] havenwood: dminuoso: Aye, I'd like more STM. Sure I'll read.
[04:55:19] dminuoso: havenwood: https://github.com/ruby-concurrency/concurrent-ruby/blob/master/lib/concurrent/tvar.rb#L230-L240
[04:55:23] dminuoso: Does this look weird to you?
[04:55:37] havenwood: dminuoso: Here was my stab at getting at STM in Ruby ;-P https://gist.github.com/havenwood/5654484
[04:56:03] havenwood: It's fancy how easy it is to get at Clojure from JRuby.
[04:56:22] dminuoso: havenwood: Ive started to greatly appreciate coordinating threads with nothing but TQueue and TVar's
[04:56:38] dminuoso: Even things like consumer/producer become so mindboggingly trivial, fast and safe...
[04:57:32] dminuoso: havenwood: I mean the whole TVar implementation is weird. (Who calls retrying a transaction "aborting")
[04:57:47] havenwood: dminuoso: hah
[05:00:19] havenwood: dminuoso: this method is hard to read...
[05:00:38] dminuoso: I know right?
[05:02:25] amar: has joined #ruby
[05:03:50] dminuoso: havenwood: As far as I can make it out, it tries to detect whether there have been uncommitted writes to any versions that have been read.
[05:04:52] havenwood: dminuoso: https://gist.github.com/havenwood/d1d3226d4637b0abd8ecd3cbbe73e9fb
[05:05:30] dminuoso: havenwood: That doesn't look right. Should be .any
[05:05:48] havenwood: dminuoso: isn't it false if any?
[05:05:48] dminuoso: Or you need to flip the condition
[05:05:53] havenwood: i think flip
[05:05:55] dviola: will jit be enabled by default in 2.6? I think it requires passing -jit right now
[05:06:09] dminuoso: dviola: It's experimental for now.
[05:06:19] dviola: dminuoso: we'll have to specify -jit in 2.6 also?
[05:06:23] dviola: ok, I see
[05:06:51] dviola: any benchmarks?
[05:06:51] havenwood: dviola: --jit, two dashes
[05:07:03] dviola: havenwood: I see, thanks
[05:07:21] havenwood: dviola: https://medium.com/square-corner-blog/rubys-new-jit-91a5c864dd10
[05:07:48] havenwood: It's faster yet in recent benchmarks :-D
[05:08:15] havenwood: still slow with Rails
[05:08:28] dviola: I got confused because of the use of this dash here: –jit
[05:08:30] dviola: https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/
[05:09:06] dviola: hrm, looking...
[05:09:09] dminuoso: havenwood: In Ruby everything is slow.
[05:11:24] shinnya: has joined #ruby
[05:12:58] dviola: I'll have to compile preview2 to see it for myself
[05:13:19] havenwood: dviola: Yup
[05:13:28] dviola: but it looks neat so far
[05:13:43] dminuoso: havenwood: By the way, Ive been thinking about rigging a compiler optimization pass into Ruby.
[05:13:53] dminuoso: One that would require a small bit of code analysis
[05:13:58] dviola: will it be like python that we'll get a lot of pyc files when executing code? :P
[05:14:04] dviola: well, rbc in this case
[05:14:10] dminuoso: Imagine you could write lambda literals, to_proc them - and gain the efficiency of blocks!
[05:14:28] dminuoso: Sadly the existence of ObjectSpace makes this impossible.
[05:15:42] sauvin: has joined #ruby
[05:15:52] dminuoso: And this is ultra sad, because you'd think that `pred = -> a { ... }; arr.filter(&pred)` could optimize the lambda away *statically*
[05:16:34] cgfbee: has joined #ruby
[05:18:41] havenwood: dviola: Tools like yomikomu and bootsnap have options for locally cached ir, but both use a central default location. They'd be the ones creating .rbc files, precompiling Ruby code to intermediate representation.
[05:19:09] havenwood: dviola: The JIT actually uses /tmp for .c and .so files.
[05:19:19] havenwood: dviola: /tmp is in-memory on Linux
[05:19:20] dviola: havenwood: nice
[05:19:25] dviola: right, tmpfs
[05:22:24] dviola: reading your blog post, havenwood
[05:22:53] za1b1tsu: has joined #ruby
[05:26:50] reber: has joined #ruby
[05:33:53] dviola: very nice, I need to try optcarrot
[05:34:59] eam: all reads and writes are potentially in memory on linux, until you flush a cache
[05:35:29] anisha: has joined #ruby
[05:37:33] dminuoso: all writes are potentially in a cache line, until you evict it
[05:37:38] dminuoso: ACTION pokes eam with further pedantry
[05:42:56] venmx: has joined #ruby
[05:46:11] pabs: has joined #ruby
[05:48:17] reber: has joined #ruby
[05:51:48] aupadhye: has joined #ruby
[05:52:35] aupadhye_: has joined #ruby
[06:09:20] karapetyan: has joined #ruby
[06:16:00] ciscam: has joined #ruby
[06:17:59] biberu: has joined #ruby
[06:19:10] amar: has joined #ruby
[06:20:59] andikr: has joined #ruby
[06:23:15] kliq: has joined #ruby
[06:26:24] za1b1tsu: has joined #ruby
[06:29:06] schleppel: has joined #ruby
[06:34:04] yohji: has joined #ruby
[06:40:01] dminuoso: havenwood: I just realized that this implementation is garbage.
[06:40:13] dminuoso: It's such a cheap and bad implementation
[06:40:54] dminuoso: It produces space leaks, has weird edge cases where TVar users spin in a loop
[06:41:14] dminuoso: "abort_transaction"
[06:41:17] dminuoso: I shouldn't have been surprised.
[06:55:03] wkoszek2: has joined #ruby
[06:59:14] dreamthese: has joined #ruby
[07:03:27] clemens3_: has joined #ruby
[07:04:12] sysvalve: has joined #ruby
[07:08:24] mtkd: has joined #ruby
[07:11:59] Xiti`: has joined #ruby
[07:19:15] clemens3: has joined #ruby
[07:19:48] burgestrand: has joined #ruby
[07:21:07] vondruch: has joined #ruby
[07:24:58] snickers: has joined #ruby
[07:29:31] dionysus69: has joined #ruby
[07:32:32] Nussi: has joined #ruby
[07:33:51] Mia: has joined #ruby
[07:33:51] Mia: has joined #ruby
[07:34:16] za1b1tsu: has joined #ruby
[07:35:03] claudiuinberlin: has joined #ruby
[07:41:25] aeontech: has joined #ruby
[07:48:43] canton7: has joined #ruby
[07:53:56] tAn: has joined #ruby
[07:55:33] paul0: has joined #ruby
[07:57:07] dr3wo: has joined #ruby
[07:57:35] pabs: has joined #ruby
[07:57:42] amar: has joined #ruby
[07:57:47] arne: dminuoso: can you elaborate on the TVar from yesterday? what would it do?
[07:57:55] arne: how would i write my own version of that thingie
[07:58:22] dminuoso: arne: do you want a buffer of keys or is a single key enough?
[07:58:56] arne: uhm, buffer means multiple values, that get "hold back" and single key means 1, right?
[07:59:36] dminuoso: well you can switch out the solution later it doesnt matter
[07:59:41] dminuoso: so lets focus on a single value because its easier
[07:59:46] arne: well buffer would be cooler, ofcourse
[08:00:45] arne: do people still use rubinius? im just reading the tvar article of concurrent-ruby
[08:01:31] arne: and rubinius is listed in the graphs
[08:01:59] dminuoso: arne: so with a single item you'd just use an mvar like this:
[08:03:11] dminuoso: arne: https://gist.github.com/dminuoso/06fd82538491d1ab7fa944f52145b395
[08:03:13] amar: has joined #ruby
[08:03:56] dminuoso: arne: the cool trick here is that MVar *blocks* when you try to take from an empty mvar or put into a filled mvar.
[08:03:56] arne: oh well, i meant without concurrent-ruby
[08:04:20] arne: well it makes for a not so readable code, does it?
[08:04:21] Sylario: has joined #ruby
[08:04:30] dminuoso: what doesnt?
[08:04:35] arne: doesn't it*
[08:05:06] arne: well, fuck it, i add concurrent-ruby to the gemfile, could you show me a buffer version?
[08:05:47] arne: and how is this any different from Queue.pop.. that one blocks, too?
[08:06:04] dminuoso: arne: the problem is controlling the flow
[08:06:59] dminuoso: arne: You'd need a full fledged TQueue
[08:07:19] arne: but a normal queue would block too if there is nothin gin there
[08:07:22] dminuoso: Imo concurrent-ruby should have a TQueue, if you want a bit Ill submit a PR to concurrent-ruby providing for one
[08:07:39] dminuoso: arne: the producer cant stop producing, thats the problem
[08:07:55] arne: well it can check the length of the queue, but that is pretty busy, so yeah
[08:08:12] dminuoso: with a TQueue you can write the code as if it looks busy, but it *blocks*
[08:08:31] arne: yeh, i see the beauty in there
[08:09:28] arne: having a producer thread like that wouldn't be expensive at all then, i guess even in ruby
[08:09:32] arne: since it sleeps all the time
[08:09:49] arne: but one question remains for me: the software architecture of this project im working on
[08:09:58] arne: has 8 programs.. using the same models
[08:10:00] dminuoso: if you had a TQueue you'd just check the length and retry the transaction if its too long
[08:10:14] arne: if i was to tell every program, to pre-buffer 8 rsa keys, for usage
[08:10:23] arne: it would peck my cpu at 100% for quite a while
[08:10:25] dminuoso: and because of how stm works the transaction will block until there's any write recorded to the tvars you have *read* until you retried
[08:10:42] arne: how would one tackle that problem?
[08:11:08] dminuoso: and the really awesome thing with STM is
[08:11:15] omth: has joined #ruby
[08:11:16] dminuoso: you could spin up 8 threads that all push into that queue
[08:11:30] dminuoso: (but oh well. hello GVL)
[08:13:58] dminuoso: arne: https://gist.github.com/dminuoso/5efaebc1f85547f4971711b92aeef5fd
[08:14:32] NL3limin4t0r: has joined #ruby
[08:15:13] dminuoso: that thing probably needs some `peekTQueue` or equivalent for the producer to know the size
[08:16:01] grilix: has joined #ruby
[08:17:30] dminuoso: This implementation uses 2 internal buffers to decrease contention, allowing writers and readers to not affect each other
[08:19:33] tvw: has joined #ruby
[08:19:58] dminuoso: arne: wait a second, let me make this better
[08:20:01] dminuoso: because we should make this a bounded queue
[08:22:02] yaewa: has joined #ruby
[08:27:40] arne: dminuoso: i don't want to steal time from your job :o
[08:27:46] mikecmpbll: has joined #ruby
[08:28:03] arne: what are you doing btw, if i may ask
[08:28:22] dminuoso: arne: Implementing a TBQueue in Ruby real quick.
[08:28:30] dminuoso: Its fine because I want one for my project anyway, so its no waste
[08:28:36] arne: i mean for a living
[08:28:40] ciscam: has joined #ruby
[08:30:26] aeontech: has joined #ruby
[08:30:43] dminuoso: arne: https://gist.github.com/dminuoso/066090b0da2432bd26ded03cfb0cea22
[08:31:09] dminuoso: arne: updated, reload for an example at the bottom
[08:31:33] dminuoso: You cant write simpler code than that (under the assumption that TBQueue is provided of course)
[08:32:24] dminuoso: you can have multiple producers as well as multiple consumers too
[08:32:31] barq: has joined #ruby
[08:32:31] barq: has joined #ruby
[08:35:41] arne: that is cool, thank you
[08:36:54] arne: aren't short variable names like t,xss,r non-ruby-idiomatic?
[08:38:16] dminuoso: arne: it makes sense in a local sense
[08:38:41] dminuoso: arne: Im refactoring the renaming slightly, give me a moment
[08:38:49] dminuoso: (this is just a raw haskell stm clone)
[08:46:07] ur5us: has joined #ruby
[08:48:00] dminuoso: arne: https://gist.github.com/dminuoso/9f1553de67a933410239c702a5b8b4f7
[08:48:10] BlopMonster: has joined #ruby
[08:51:59] arne: thanks alot, i will tell you how good this performs
[08:52:46] dminuoso: arne: I discovered a bug in concurrent ruby that will cause a consumer to go hot until you've written to this at least once, just something to keep in mind
[08:52:55] jottr: has joined #ruby
[08:53:38] dminuoso: (so if that ever becomes an issue, you can simply. atomically { pool.unget(nil); pool.read } during setup
[08:54:02] arne: well, there will be written to it, i gues
[08:54:16] arne: dminuoso: but what do i do with the following problem
[08:54:24] arne: let's say i do a queue of 8 8192-length rsa keys
[08:54:34] arne: this code will start on ~8 processes
[08:54:45] arne: which results in 8*8 8192-length rsa keys being created on startup
[08:56:05] amar_: has joined #ruby
[08:57:07] dminuoso: Oh I should add a note you aught to read up on how STM works probably. There's some subtleties that are not obvious, for example the code inside `atomically` blocks need to be pure (no side effects)
[08:57:22] dminuoso: (Because may be retried)
[08:59:25] arne: well, not for me , i understand the code, kinda :)
[08:59:33] arne: but will this be part of concurrent ruby? then you maybe should
[09:00:26] Beams: has joined #ruby
[09:02:51] venmx: has joined #ruby
[09:05:51] dminuoso: arne: is there a question by the way? I dont see what the problem is
[09:07:02] conta: has joined #ruby
[09:08:36] arne: dminuoso: well... startup would be super expensive.. if 8 programs do fill this queue
[09:08:46] arne: there is no clever way to tackle this.. is there?
[09:10:50] dminuoso: arne: across different processes?
[09:12:12] arne: pls don't say redis or database
[09:12:14] pabs: has joined #ruby
[09:12:50] dminuoso: arne: there's a wonderful solution here that relies soley on TQueues now.
[09:13:38] dminuoso: arne: you could write a small server that has a TBQueue and serves RSA keys from it to requests
[09:13:52] dminuoso: perhaps a miniature sinatra server listening on a unix domain socket
[09:14:11] dminuoso: and then each process has a "producer" that fetches from that server
[09:14:17] dminuoso: and uses a local TBQueue
[09:14:53] dminuoso: or perhaps you do some other form of IPC, maybe pipes
[09:16:19] dminuoso: (transactional queues are such a wonderful method of synchronization)
[09:17:08] Zarthus: has joined #ruby
[09:17:20] dminuoso: arne: but I dont know whether you gain any advantage from that
[09:17:29] dminuoso: 10:54 arne | which results in 8*8 8192-length rsa keys being created on startup
[09:17:36] dminuoso: this will happen in separate threads though
[09:17:48] arne: yeah but still, thats a lot of calculations
[09:18:03] arne: causes some lag in other proccesses
[09:18:13] dminuoso: not as much other processes but your ruby app
[09:18:14] arne: mini-IPC i wonder how you would do that
[09:18:19] dminuoso: like I said.
[09:18:28] dminuoso: you have one small server with a TBQueue
[09:18:31] arne: but i guess not possible, since each process is a docker container :/
[09:18:52] dminuoso: arne: you can use network
[09:18:53] arne: well it would be tcpip.. and would need a stupid complexity for such simple task
[09:19:05] arne: well then i would just use the database as IPC
[09:19:14] dminuoso: you dont need complexity thats the point
[09:19:47] dminuoso: arne: Pool = TBQueue.20; Thread.new { loop do; key = generate_key; Concurrent.atomically { Pool.write key } }.join
[09:20:06] dminuoso: and then you write a miniature sinatra server that just does
[09:20:34] dminuoso: get '/key' do; key = nil; Concurrent.atomically { key = Pool.read }; answer_with_key; end
[09:21:04] dminuoso: arne: and each process then does some:
[09:21:58] dminuoso: Pool = TBQueue.new 4; Thread.new { loop do; key = http.get('blabla/key'); Concurrent.atomically { Pool.write key } }.join
[09:22:42] dminuoso: and when each process needs to serve an RSA key then just atomically read from the local pool
[09:22:59] dminuoso: arne: you could then have that sinatra server maybe delegate the RSA generation to a native extension
[09:24:26] arne: well i am sorry, usually you have really good ideas but that sounds like a terrible idea :D
[09:24:32] arne: even if i was about to do that
[09:24:38] arne: why not just do it with TCP/IP?
[09:24:47] arne: Socket.write "#{some_)ey}"
[09:24:54] arne: why would i have sinatra including rack for it
[09:25:01] dminuoso: arne: the point was not sinatra.
[09:27:52] dminuoso: arne: fairness is going to be a big problem though. I think each server doing its own generation might be wiser
[09:28:19] dminuoso: arne: unrelatedly, is RSA forced on you? Is ECDSA an option?
[09:28:34] arne: in this case it's DKIM keys cor e-mail signage
[09:28:43] arne: s/cor/for
[09:28:50] arne: so yes, it's rsa
[09:29:24] dminuoso: arne: is there dedicated hardware for key generation?
[09:29:58] arne: well, my startup is going to bankrupt this next few month (maybe, maybe not)
[09:30:08] arne: this would be way to sophisticated
[09:30:38] arne: working on a dead project as of now, but i still get paid so what
[09:31:06] dminuoso: arne: regarding your initial problem
[09:32:09] dminuoso: you could control the rate of key generation and scale it up after server start
[09:33:17] dminuoso: that way starting the services up wont be as brutal
[09:33:37] marius: has joined #ruby
[09:33:42] dminuoso: (it may also be possible to resize the queue, but Id have to think about that)
[09:35:55] arne: dminuoso: yeah something like that, sounds good
[09:36:06] dminuoso: arne: Oh yeah thats actually trivial
[09:38:21] dminuoso: arne: https://gist.github.com/dminuoso/8be273ff2472bea943dba28714218195
[09:39:10] burgestrand: I'd probably just use a SizedQueue from core, as opposed to a TVar, what's your thinking on that dminuoso?
[09:40:58] arne: something like that works :o?
[09:41:03] arne: exists*?
[09:41:14] dminuoso: Burgestrand: I like STM because I can reason about that.
[09:41:16] burgestrand: >> SizedQueue.new(5)
[09:41:17] ruby[bot]: Burgestrand: # => #<Thread::SizedQueue:0x40a89c84> (https://eval.in/1017448)
[09:41:23] dminuoso: Burgestrand: And I can seamlessly integrate it into concurrent code.
[09:41:27] arne: uhh and that thing blocks when it's full?
[09:41:31] dminuoso: SizedQueue wont go well
[09:41:37] dminuoso: Burgestrand: But yeah, I didnt know about that.
[09:41:47] dminuoso: Burgestrand: Id prefer the TBQueue still.
[09:41:55] burgestrand: dminuoso How so?
[09:42:02] arne: i wonder about that one too
[09:43:17] dminuoso: Burgestrand: Because `atomically`?
[09:43:43] burgestrand: SizedQueue is documented to be thread-safe for both push and pop
[09:43:52] burgestrand: (same as Queue)
[09:44:03] dminuoso: Concurrent.atomically { b = someQueue.read; a = someTvar.read; someOtherQueue.write(a + b) }
[09:44:12] dminuoso: Voila. SizedQueue no longer works for this kind of thing.
[09:44:23] dminuoso: You end up with crazy locking mechanics if you do anything non trivial with SizedQueue
[09:45:28] dminuoso: with STM you talk in terms of transactions and consistent views of memory
[09:47:02] burgestrand: Yeah, I agree, when you start coordinating multiple pieces of mutable state then locking becomes prone to a bunch of problems that you don't really have with STM.
[09:47:16] burgestrand: Although in this case it feels like using a nuke to open an egg when a spoon is sufficient >D
[09:48:02] burgestrand: … although, to be fair, in the case of generating expensive resources you want to spread that across multiple machines anyway so neither approach is actually useful
[09:48:09] dminuoso: Burgestrand: Ive grown accustomed to defaulting to STM because I found that I have fewer issues in the long run.
[09:48:25] dminuoso: Because at some point you may decide to "make a little tweak" and then you end up wasting weeks of debugging race conditions
[09:48:56] dminuoso: Also I can trivially reason about STM. I cant trivially reason about SizedQueue without fully diving into its implementation.
[09:49:06] burgestrand: Absolutely. I used STM in haskell quite extensively, I like it, especially when the type system helps you even further to make it impossible to attempt to use it where it doesn't make sense.
[09:49:30] dminuoso: Burgestrand: btw its funny that the haskell implementation and my code line up exactly.. :D
[09:49:33] lupine: I bought hardware on the strength of it having hardware transactional memory
[09:49:39] lupine: but then they disabled it in a microcode update :'(
[09:50:01] burgestrand: dminuoso I'm not surprised you brought up STM with your recent (well, a year or two) interest in type theory and functional programming
[09:50:43] burgestrand: dminuoso sorry, that sounded way more douchy than I realized at first, I apologize!
[09:51:14] dminuoso: Burgestrand: All good. I read it as "it seemed like a logical consequence"
[09:51:46] burgestrand: dminuoso Indeed, it's been interesting to read your explanations on all the advanced stuff you've been teaching in here :)
[09:54:52] pabs: has joined #ruby
[09:55:32] dminuoso: Burgestrand: By the way, SizedQueue might be substantially slower
[09:55:42] dminuoso: The reason is that uses a single mutex protected queue
[09:56:01] dminuoso: The double buffering in my TBQueue makes concurrent accesses possible without conflict
[09:56:18] dminuoso: (as long as the read buffer still has resources left of course)
[09:57:09] burgestrand: dminuoso I admit I didn't read the entire TBQueue implementation, but I assume it holds true no matter the number of producers/consumers or speed of production/consumption?
[09:57:11] apeiros_: has joined #ruby
[09:57:12] karapetyan: has joined #ruby
[09:58:01] dminuoso: Burgestrand: Right. My TBQueue internally has two tvar buffers: An in buffer and an out buffer. Reads are served from the in buffer, writes are served to the out buffer
[09:58:08] dminuoso: if the read buffer is empty, the write buffer is flushed into the read buffer
[09:58:41] dminuoso: err.. switch in and out in that sentence =)
[09:59:06] dminuoso: though I suppose if the producer is really slow it wont really matter
[10:02:36] ellcs: has joined #ruby
[10:04:41] burgestrand: dminuoso My memory is a bit foggy, I recall the transaction is only retried if the initial state of accessed memory is changed from the conditions you entered the transaction in, i.e. it's not gonna spin forever if the circumstances don't change?
[10:06:02] dminuoso: Burgestrand: right
[10:06:10] dminuoso: Burgestrand: STM keeps a log on all writes and logs on each transaction
[10:06:29] burgestrand: (because otherwise we'd end up in a case where the consumers could starve the producers of resources if they keep polling while the queue is empty)
[10:06:42] dminuoso: Burgestrand: so every `t.read` I do is recorded. If I retry the transaction, it will block until any tvar I've read has been changed
[10:07:26] dminuoso: Burgestrand: https://gist.github.com/dminuoso/8be273ff2472bea943dba28714218195#file-tbqueue-rb-L54
[10:07:27] burgestrand: Aye-aye, that makes sense, since the requirement is that the update is pure
[10:07:44] burgestrand: dminuoso Indeed, that's the retry I was referring to
[10:07:51] dminuoso: on that note...
[10:07:56] dminuoso: arne: I have a massive bug!
[10:08:33] dminuoso: arne: https://gist.github.com/dminuoso/8be273ff2472bea943dba28714218195
[10:12:14] dminuoso: Burgestrand: so much for the type system preventing me from doing IO inside STM transactions :D
[10:13:09] dminuoso: Burgestrand: now if only we could do something like
[10:13:28] dminuoso: atomically (waitSTM async1 <|> waitSTM async2 <|> takeTMVar someVar >>= putTMVar resultVar)
[10:13:52] burgestrand: dminuoso Liking type systems (e.g. haskell, or more recently swift) AND dynamic non-typed systems (e.g. ruby) alike is a constant battle of mine, it doesn't make sense to me but it's there nonetheless
[10:14:29] dminuoso: Burgestrand: The more I get into type theory, the more I realize that "no type system" (there is *no such thing* as a dynamic type system) have very few to no benefits.
[10:15:05] dminuoso: No type systems gain the ability to express certain good programs (according to your operational model) that a type system might prevent. But with good habits this will very rarely be the case.
[10:15:38] dminuoso: Burgestrand: Why do you like lack of types?
[10:16:09] burgestrand: Yeah, I try to avoid the labels of what to call the different type systems, I try to stick to providing concrete examples of implementations instead :)
[10:16:26] burgestrand: (mainly because I don't know what terminology to use, and even if I did I'm not sure my audience does either)
[10:16:32] karapetyan: has joined #ruby
[10:16:40] dminuoso: Burgestrand: ruby has no type system to begin with.
[10:17:24] burgestrand: dminuoso I probably like it because all explicitly typed systems I've come across so far has lacked expressiveness in one way or the other, which causes a bunch of boilerplate that makes things (feel) unecessarily difficult to implement
[10:17:52] dminuoso: Burgestrand: Many programmers conflate runtime object tagging and types. They are somewhat related, but types are not about the former.
[10:18:01] dminuoso: And you cant do the former to do the latter *at all*
[10:18:11] burgestrand: e.g. my gripe with haskell started as I was writing a network protocol parser and the only acceptable path forward was Template Haskell, and at the time that wasn't really a nice compromise either
[10:18:32] dminuoso: TH is quite a bag, what kind of problem did you have?
[10:20:51] burgestrand: I'm not sure I can do the specifics justice to justify it today, but I had the luck of having a handful of haskell core members around me to ask for advice at the time that verified my approach, i.e. put up with the boilerplate or use template haskell. I wish I had a better answer than "trust me", because honestly I don't think that's a good argument :)
[10:21:35] dminuoso: Burgestrand: No I get it. Im writing a protocol implementation and I have to use TH for one part of it (but thats really just boilerplate reduction) as well.
[10:22:00] dminuoso: Burgestrand: In most cases you *could* still escape into the value world (like you would do in Ruby anyhow)
[10:22:03] burgestrand: Aye, it wasn't something that couldn't be solved in regular haskell, it just required A LOT of typing, it was essentially turning a stream of bytes into a stream of records
[10:22:32] karapetyan: has joined #ruby
[10:22:48] burgestrand: s/records/packet data types/
[10:23:24] dminuoso: Burgestrand: But I like TH for the fact that I get to do meta programming before the type checker runs.
[10:23:26] cdunklau: dminuoso: when you say "type" what do you mean
[10:23:35] cdunklau: like, type theory type?
[10:23:43] Mike11: has joined #ruby
[10:23:46] dminuoso: cdunklau: what other types are there?
[10:24:04] cdunklau: dminuoso: it's a massively overloaded term
[10:24:22] dminuoso: cdunklau: if you implement a type system, its really not
[10:24:38] dminuoso: cdunklau: its just programmers that dont understand it well/at all that have a bajillion ideas what a type might be
[10:24:48] dminuoso: cdunklau: https://ro-che.info/ccc/17
[10:24:59] leah2: anyone know if Eric Wong is on irc?
[10:25:48] plexigras: has joined #ruby
[10:26:30] dminuoso: cdunklau: the probably best universally accepted definition arises from TaPL: "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute"
[10:26:50] cdunklau: dminuoso: okay
[10:27:10] cdunklau: dminuoso: i was mostly just wondering what you meant by type there, semantically
[10:27:41] cdunklau: dminuoso: thanks for the link, i was looking for a rabbit hole to dive into :)
[10:30:13] dminuoso: cdunklau: There's a lot of depth in that definition by the way, and it might hint at what Im trying to say.
[10:30:47] dminuoso: a "type-safe" language, is that that ties types to a certain operational model
[10:30:55] dminuoso: *is a language that
[10:31:05] cdunklau: dminuoso: oh i meant the link that your link gave https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
[10:31:14] dminuoso: cdunklau: ah yeah its a nice little read :)
[10:32:15] cdunklau: dminuoso: i never had a formal CS education (or math beyond linear algebra), so getting tidbits like this is as frusterating as it is astonishing :)
[10:32:46] cdunklau: dminuoso: i suppose what i'm trying to say is "i have no idea what you're saying"
[10:33:08] dminuoso: cdunklau: Let me give you an example:
[10:33:36] cdunklau: if you want. i'm not confident i'll be able to understand it, fair warning :)
[10:33:48] dminuoso: cdunklau: Type safe means: "Within some model, a well-typed program will not perform a set of *bad* behaviors"
[10:34:20] dminuoso: cdunklau: On Java that set of bad behaviors includes "not seg faulting"
[10:34:33] dminuoso: Which is to say: If a Java program type checks, you are guaranteed to not have seg faults.
[10:36:31] burgestrand: dminuoso I guess my opinion stems from the common one, i.e. I'm okay with trading correctness (better type system) for convenience (and in effect, higher risk of bugs)
[10:36:46] burgestrand: Which is why I like both ruby… and not ruby :)
[10:36:49] dminuoso: Burgestrand: but what convenience do you get?
[10:36:50] burgestrand: Anyway, lunch time!
[10:37:07] burgestrand: dminuoso I do believe it's more convenient to not have to think about the types in such a rigid fashion
[10:37:10] cdunklau: dminuoso: clearly, the freedom of lunchtime
[10:37:21] burgestrand: I'll be back later to elaborate if necessary
[10:38:05] dminuoso: Burgestrand: foo.bar.quux[10] ... "It's okay to not think too hard what `quux` actually is. Maybe its an array, or maybe it's an Integer.. but its beneficial that this is accepted and crashes instead"
[10:38:16] dminuoso: This is what Im getting from you :P
[10:38:28] dminuoso: *`foo.bar.quux`
[10:38:45] AJA4350: has joined #ruby
[10:39:11] dminuoso: We programmers tend to think a lot about types implicitly. When we write code, we always have some intuition about how to use results further - we have some intuition about what state the data is in.
[10:39:17] dminuoso: We have some intuition about some of the invariants we have
[10:39:33] dminuoso: Here's one proof that you do think about types:
[10:41:18] amar_: has joined #ruby
[10:41:58] dminuoso: 1.puts({ nil.nil.nil => raise "This is nonsense" })
[10:42:04] cadillac_: has joined #ruby
[10:42:38] dminuoso: This would make any ruby programmer scream.
[10:42:44] cdunklau: dminuoso: can you translate that to a language i know? :P
[10:42:49] dminuoso: Thats ruby.
[10:42:50] cdunklau: say, python, or javascript
[10:42:56] cdunklau: i know, i'm new here :)
[10:43:01] dminuoso: cdunklau: Oh.
[10:43:14] cdunklau: i assume the arg to puts() is a hash?
[10:43:29] dminuoso: cdunklau: 1.puts({ (nil.nil.nil): throw "this is nonsense" })
[10:43:30] cdunklau: or is => a different thing
[10:43:43] dminuoso: equivalent in JavaScript
[10:44:04] cdunklau: well that's a syntax error isn't it?
[10:44:16] dminuoso: Oh I think I may have to use
[10:44:22] dminuoso: 1.puts({ [nil.nil.nil]: throw "this is nonsense" })
[10:44:31] dminuoso: maybe some more parens for throw?
[10:44:36] dminuoso: 1.puts({ [nil.nil.nil]: throw("this is nonsense") })
[10:45:04] dminuoso: cdunklau: we constantly think in terms of contracts, what we can do with things, and what we get back
[10:45:56] cdunklau: dminuoso: 1.puts({ nil.nil.nil => raise "This is nonsense" }) is a syntax error in ruby too
[10:46:20] cdunklau: dminuoso: for the sake of discussion, can i just assume that `raise "this is nonsense"` is supposed to be an expression that throws an exception?
[10:46:22] dminuoso: 1.puts({ nil.nil.nil => raise("This is nonsense") })
[10:46:29] dminuoso: cdunklau: Yes.
[10:47:27] dminuoso: cdunklau: Here's the following contracts I broke: puts is not a (public) method of Integer. I probably meant `Kernel#puts` but who knows.
[10:47:42] dminuoso: nil.nil.nil is a silly thing to do
[10:47:53] karapetyan: has joined #ruby
[10:48:00] marius: has joined #ruby
[10:48:06] dminuoso: and Im putting a `raise` in a spot where a value is expected
[10:48:27] cdunklau: dminuoso: ok, i have to step away for a few minutes, but please continu
[10:49:08] dminuoso: if you write: console.log.log("foo") in javascript this would obviously be wrong too. the reason for that, is that you mentally know that `console.log` does not give you something back, that has .log in its prototype.
[10:49:35] dminuoso: even when you type `console.log` you make the implicit assumption that `console` has a prototype that provides `log`
[10:49:55] dminuoso: when you write: `a + b` you already have the thought lingering in your head "a" and "b" are numbers
[10:50:13] chat: has joined #ruby
[10:51:45] dminuoso: cdunklau: https://gist.github.com/dminuoso/f552b4ddebaf64ca64d7b4ffb46f538c when you read this, does this look right to you?
[10:52:40] Beams: has joined #ruby
[10:54:58] aufi_: has joined #ruby
[10:55:33] rr4: has joined #ruby
[10:55:49] Beams__: has joined #ruby
[10:56:42] zapata_: has joined #ruby
[10:58:00] karapetyan: has joined #ruby
[10:59:51] cdunklau: dminuoso: no, because add doesn't return something callable
[11:01:16] dminuoso: cdunklau: would you accidentally write it? or would you think about what add returns when you use it?
[11:03:09] cdunklau: dminuoso: i would think that add returns a number, so calling the result would not make sense
[11:03:28] oxx16: has left #ruby: ()
[11:03:36] cdunklau: and presumably i'd have a unit test for add() that would catch that it doesn't return the result
[11:04:25] dminuoso: cdunklau: so this would trigger a certain bad behavior: A runtime error "blablabl is not a function" right?
[11:05:03] dminuoso: flow for example, wrt to the operational model of JavaScript, classifies "is not a function" as bad behaviors.
[11:05:21] dminuoso: cdunklau: and it does the same thing that you did in your head.
[11:05:53] cdunklau: flow is the typescripty thing right?
[11:06:01] dminuoso: its a great example of what type systems are about.
[11:06:17] dminuoso: its just a stand alone program. you give it some JS code, and it will either "type check" or "not"
[11:06:36] jrafanie: has joined #ruby
[11:06:38] dminuoso: it does so soley based on syntactic elements
[11:06:47] dminuoso: it "stares at the code" and says "this doesnt make sense"
[11:06:51] dminuoso: just what you did.
[11:07:05] dminuoso: except it doesnt justify by guessing, but by employing an automated theorem solver
[11:07:56] dminuoso: its particularly a good example because it shows that type checking and compilation/runtime are not necessarily related in any way
[11:08:40] dminuoso: now the value from type checkers stems from the fact that they prove the absence of certain behaviors.
[11:08:40] karapetyan: has joined #ruby
[11:10:15] schleppel: has joined #ruby
[11:10:39] dminuoso: flow doesnt provide a particularly useful type system *in that sense* because there exist escape hatches that basically invalidate most such proofs.
[11:10:50] dminuoso: its still valuable in a different sense
[11:11:16] dminuoso: but in Haskell and Java the type system *proves* (amongst other things) the absence of segmentation faults.
[11:11:39] dminuoso: which means you can get rid of all tests that assert segfaults dont happen, because you have 100% complete provable coverage for that behavior.
[11:12:53] dminuoso: Haskell too has escape hatches (which means it's not *as provable* as one might hope), that is there's certain primitives I can use to provoke a segfault.
[11:13:12] dminuoso: So again, it's not that useful to make that particular claim.
[11:14:56] Zaab1t: has joined #ruby
[11:15:42] ramfjord: has joined #ruby
[11:16:53] dminuoso: but they prove the absence of many other properties too. rich type systems allow you to specify such properties within the type system, so you can codify arbitrary "bad properties", and have the type system *prove* their absence to you
[11:18:02] dminuoso: For example you might have some type `InputString a` parameterized over another type. If you then consume only `InputString Sanitized` in the database, and produce `InputString Unsanitized` from the userinput, then the type system will prove that no unsanitized string enters your database,.
[11:20:19] burgestrand: dminuoso your original interpretation sounds about right :)
[11:22:45] Beams: has joined #ruby
[11:31:10] hays: has joined #ruby
[11:32:07] cadillac_: has joined #ruby
[11:32:09] burgestrand: dminuoso in theory I guess there could be a perfect type system and perfect type inference, but I'm not aware of any such implementation today
[11:32:32] arne: wow, you're still going
[11:32:33] dionysus69: has joined #ruby
[11:35:20] burgestrand: arne Well, lunch is over, and I got a question :)
[11:35:29] ldnunes: has joined #ruby
[11:35:55] burgestrand: arne or, well, it felt like an implied question!
[11:36:02] yokel: has joined #ruby
[11:37:37] cadillac_: has joined #ruby
[11:44:22] cdunklau: dminuoso: out of curiosity, what languages do you enjoy using?
[11:45:14] psychicist__: has joined #ruby
[11:45:20] cdunklau: dminuoso: let me be more specific
[11:45:22] fmcgeough: has joined #ruby
[11:46:42] cdunklau: what languages do you enjoy using to write useful software
[11:46:57] cdunklau: i'm not sure there's a difference, but just in case :)
[11:49:08] tvw: has joined #ruby
[11:50:52] ur5us: has joined #ruby
[12:00:01] chamar: has joined #ruby
[12:00:52] Nuve: has left #ruby: ("✌")
[12:02:19] synthroid: has joined #ruby
[12:02:51] whowantstolivefo: has joined #ruby
[12:03:43] jcalla: has joined #ruby
[12:05:38] karapetyan: has joined #ruby
[12:05:50] ellcs: has joined #ruby
[12:15:33] llua`: has joined #ruby
[12:16:12] cyberg: has joined #ruby
[12:22:37] karapetyan: has joined #ruby
[12:26:29] k0mpa: has joined #ruby
[12:26:29] c0ncealed1: has joined #ruby
[12:28:35] ellcs: has joined #ruby
[12:29:29] reber__: has joined #ruby
[12:29:58] dminuoso: Burgestrand: Actually it's been shown that a perfect type system cant exist.
[12:30:25] dminuoso: Burgestrand: Id have to dig but there are proofs that demonstrate that type systems always filter out *some* good programs.
[12:30:40] burgestrand: dminuoso Oh, cool, I didn't know that
[12:31:40] ramfjord: has joined #ruby
[12:33:30] jottr: has joined #ruby
[12:34:19] dminuoso: Burgestrand: Just asked some friends. Rice's theorem is the foundation.
[12:35:29] cdunklau: my intuition tells me that's probably related to Gödel's incompleteness theorem
[12:36:52] tcopeland: has joined #ruby
[12:37:31] ellcs: has left #ruby: ()
[12:39:10] dminuoso: cdunklau: http://tunes.org/~nef/logs/haskell/18.06.08 near the bottom.
[12:39:42] wkoszek2: has joined #ruby
[12:43:14] cdunklau: dminuoso: see i do know stuff! i just can't prove it :P
[12:49:28] BlopMonster: has joined #ruby
[12:50:11] karapetyan: has joined #ruby
[13:00:18] micutzu: has joined #ruby
[13:00:23] synthroid: has joined #ruby
[13:03:40] karapetyan: has joined #ruby
[13:05:21] griffindy: has joined #ruby
[13:07:42] karapetyan: has joined #ruby
[13:07:50] mudwaf: has joined #ruby
[13:08:56] mudwaf: Is this the right place to ask about a problem I'm having with ruby + Sequel / SQLite?
[13:09:35] burgestrand: mudwaf Give it a try, if it isn't somebody is hopefully helpful enough to point you to a better place :)
[13:09:57] dminuoso: cdunklau: I like SQL very much.
[13:10:17] cdunklau: dminuoso: ooooh
[13:10:25] dminuoso: It's declarative, pure.. and its an algebra.
[13:10:32] cdunklau: dminuoso: have you been nerd-sniped by https://www.schemaverse.com/ yet?
[13:10:59] apparition: has joined #ruby
[13:11:29] dminuoso: cdunklau: I cant access it, it appears
[13:12:00] cdunklau: dminuoso: tl;dr it's a simple space fleet combat game implemented entirely in a postgres DB
[13:12:15] dminuoso: cdunklau: with or without PL/...?
[13:12:27] cdunklau: multiplayer. the only UI you get is psql or whatever client you want
[13:12:36] cdunklau: dminuoso: you can use the normal PL/s
[13:12:50] dminuoso: https://github.com/Abstrct/Schemaverse
[13:12:52] dminuoso: There we goi
[13:13:08] dminuoso: cdunklau: Ah shoot, that's far less boring.
[13:13:38] cdunklau: but iirc there's a limiting factor for scripts
[13:13:55] cdunklau: like you can only have a certain number of "fleet scripts"
[13:14:00] dminuoso: cdunklau: but to answer your original question I enjoy Haskell a lot these days. Rust is also quite fine, PureScript is on my list as well as Idris.
[13:14:25] jamesaxl: has joined #ruby
[13:14:45] dminuoso: Probably should learn more OCaml as well.
[13:15:11] mudwaf: Well, the program starts out by opening a SQLite database read-only, and reading in many rows. It then forks many processes (based on the data read in), but when those processes attempt to use the database, some of them sometimes raise an exception: `SQLite3::CorruptException: database disk image is malformed`. The database is not actually corrupted and it works fine if the children processes execute serially. It's not consistently at a single spot
[13:15:11] mudwaf: in the child process code, so I'm thinking it has to do with the code being parallel, though Sequel claims to be fully "Thread safe." Has anyone here run into something similar?
[13:15:14] cdunklau: dminuoso: if you're curious about schemaverse maybe poke them in #schemaverse to tell them about it
[13:15:31] dminuoso: cdunklau: Nah. With PL/.. stuff its boring.
[13:15:40] cdunklau: dminuoso: you don't have to use PL/
[13:15:48] cdunklau: the game is what you make it ;)
[13:15:58] dminuoso: cdunklau: I actually know of one major "business" company that makes million on a grand software consisting of literalls tens of thousands of *triggers*
[13:16:19] dminuoso: They encoded a whole identity managemer, transitions, rule engine - all with triggers.
[13:16:38] cdunklau: dminuoso: i'm not a good enough DBA to grasp the implications of that, but i can't imagine it's good
[13:16:43] dminuoso: You have to run this on a MSSQL server with 64GiB of RAM to perform well.
[13:17:15] dminuoso: At first I thougth it was a joke when the guy was telling me about it in amazement.
[13:18:20] cdunklau: dminuoso: i haven't gotten deep into many languages. my python is on point, i'm decent with JS, but i can't claim more than passing familiarity with any other languages
[13:18:48] cdunklau: dminuoso: i'm here because i'm considering a job that uses Java, Groovy, PHP, and Ruby
[13:19:04] dminuoso: Sounds horrid!
[13:19:28] cdunklau: java is... eh. dunno about groovy. PHP is clearly awful. ruby looks niceish though
[13:19:40] cdunklau: dminuoso: eh, devops
[13:19:53] dminuoso: devops with Java, Groovy and PHP?
[13:20:12] epochwolf|2: has joined #ruby
[13:20:15] cdunklau: that's just "languages our company uses", not necessarily what devops uses
[13:20:34] cdunklau: i suspect a lot of the job would be messing around with puppet and such
[13:21:47] synthroid: has joined #ruby
[13:21:58] dminuoso: ACTION can already see cdunklau ending up in a dark cellar being locked away with ancient cruft PHP scripts invoking `ldapsearch` to pump information from one place to the next
[13:22:05] dminuoso: ACTION ... and it being called devops
[13:22:18] cdunklau: the thing that gets me excited about it the possibility of working with people more experienced with me. right now i'm doing QA-ish automation stuff, and nobody else knows wtf they're doing
[13:22:27] donofrio: has joined #ruby
[13:22:32] cdunklau: that's not *really* a fair assessment, but it's the feeling i have
[13:22:40] pabs: has joined #ruby
[13:22:54] cdunklau: dminuoso: jesus don't put that poison in my brain! :D
[13:25:14] rippa: has joined #ruby
[13:25:51] hobbes_: has joined #ruby
[13:27:05] chamar: has joined #ruby
[13:27:44] Creatornator: has joined #ruby
[13:29:35] mrBen2k2k2k: has joined #ruby
[13:30:15] TomyWork: has joined #ruby
[13:30:40] hays_: has joined #ruby
[13:30:40] hays_: has joined #ruby
[13:33:16] karapetyan: has joined #ruby
[13:37:55] cdunklau: dminuoso: what do you like about rust?
[13:43:28] dminuoso: cdunklau: It has a type system that is somewhat expressive.
[13:43:36] Azure: has joined #ruby
[13:44:05] dminuoso: cdunklau: In a lot of ways it's built on first principles and has managed to avoid a lot of the issues of many mainstream languages.
[13:47:42] Rapture: has joined #ruby
[13:48:31] Jeff_D: has joined #ruby
[13:49:23] chat_: has joined #ruby
[13:54:08] karapetyan: has joined #ruby
[13:57:56] Jeff_D: Can anybody answer, or point me to where I can find answered, questions about running capybara-webkit tests from `rake` inside a Docker container? I understand that I need to run within the context of Xvfb. `docker-compose exec web xvfb-run -a ruby path/to/some_spec.rb` works, but `docker-compose exec web xvfb-run -a bin/rake` has a failure in `some_spec.rb` because a Capybara match fails. I'm pulling my hair out here, and I really don't have a lot to start
[13:58:27] kliq: has joined #ruby
[14:00:07] nowhere_man: has joined #ruby
[14:02:10] ciscam: has joined #ruby
[14:06:43] jottr: has joined #ruby
[14:12:12] ciscam: has joined #ruby
[14:17:40] Jeff_D: hmmmm...anybody awake?
[14:18:45] dendazen: has joined #ruby
[14:21:14] Creatornator: has joined #ruby
[14:21:45] rsh: has joined #ruby
[14:25:46] jrafanie: has joined #ruby
[14:29:12] gnufied: has joined #ruby
[14:30:24] flips: I'm afraid being awake is not enough, I have no idea about capybara/docker stuff ...
[14:34:52] Jeff_D: well, thanks anyway. I'll keep beating my head against this until one or the other breaks, or until massive expenditures of Google-fu start showing less whimsical returns
[14:37:36] amar_: has joined #ruby
[14:38:15] akaiiro: has joined #ruby
[14:41:06] [Butch]: has joined #ruby
[14:43:13] Axy: has joined #ruby
[14:43:13] Axy: has joined #ruby
[14:46:46] mikecmpbll: has joined #ruby
[14:48:10] snickers: has joined #ruby
[14:50:48] Megamos: has joined #ruby
[14:51:43] jinie: has joined #ruby
[14:53:29] yorickpeterse: has joined #ruby
[14:59:40] za1b1tsu: has joined #ruby
[15:02:10] shinnya: has joined #ruby
[15:22:59] karapetyan: has joined #ruby
[15:25:00] jinie: has joined #ruby
[15:27:13] Creatornator: has joined #ruby
[15:30:48] suukim: has joined #ruby
[15:32:24] nowhere_man: has joined #ruby
[15:37:00] akaiiro: has joined #ruby
[15:38:33] chouhoulis: has joined #ruby
[15:51:53] cam27: has joined #ruby
[15:55:06] dmgk: has joined #ruby
[15:57:15] pabs: has joined #ruby
[16:06:30] karapetyan: has joined #ruby
[16:07:58] jottr: has joined #ruby
[16:08:28] karapetyan: has joined #ruby
[16:10:23] pabs: has joined #ruby
[16:10:59] jcarl43: has joined #ruby
[16:11:54] Creatornator: has joined #ruby
[16:13:09] Immune: has joined #ruby
[16:15:03] amarks: has joined #ruby
[16:22:24] darkhanb: has joined #ruby
[16:24:10] cthulchu: has joined #ruby
[16:24:17] Immune: has left #ruby: ("WeeChat 2.1")
[16:24:18] amar_: has joined #ruby
[16:28:10] cyberg: has left #ruby: ("Leaving")
[16:28:25] jinie: has joined #ruby
[16:30:20] bbobb: has joined #ruby
[16:31:31] FernandoBasso: has joined #ruby
[16:32:41] chopin: has joined #ruby
[16:33:06] DTZUZO: has joined #ruby
[16:33:58] biberu: has joined #ruby
[16:34:32] chopin: Any time I run rspec "x86_64-darwin-17" is added to my Gemfile.lock under the PLATFORMS heading. Any ideas why that is / how to stop it?
[16:35:01] pabs: has joined #ruby
[16:43:20] amarks: has joined #ruby
[16:43:20] eckhardt_: has joined #ruby
[16:49:33] psychicist__: has joined #ruby
[16:50:59] BlopMonster: has joined #ruby
[16:52:16] sanscoeur: has joined #ruby
[16:56:51] jyaworski: has joined #ruby
[16:57:54] chouhoulis: has joined #ruby
[16:58:09] ldepandis: has joined #ruby
[16:58:54] chouhoul_: has joined #ruby
[17:00:00] chouhoul_: has joined #ruby
[17:01:08] chouhoul_: has joined #ruby
[17:03:17] chouchen_: has joined #ruby
[17:04:19] chouhoulis: has joined #ruby
[17:05:31] chouhoul_: has joined #ruby
[17:06:41] chouhoul_: has joined #ruby
[17:08:52] chouhoul_: has joined #ruby
[17:09:57] chouhoulis: has joined #ruby
[17:11:01] chouhoul_: has joined #ruby
[17:12:03] millerti: has joined #ruby
[17:12:13] chouhoul_: has joined #ruby
[17:13:12] chouhoul_: has joined #ruby
[17:14:23] chouhoul_: has joined #ruby
[17:15:25] chouhoulis: has joined #ruby
[17:16:28] chouhoul_: has joined #ruby
[17:17:37] chouhoul_: has joined #ruby
[17:17:51] tAn: has joined #ruby
[17:18:43] chouhoul_: has joined #ruby
[17:19:53] chouhoul_: has joined #ruby
[17:20:52] chouhoulis: has joined #ruby
[17:22:03] chouhoul_: has joined #ruby
[17:25:16] chouhoul_: has joined #ruby
[17:26:23] chouhoulis: has joined #ruby
[17:27:31] chouhoul_: has joined #ruby
[17:28:36] chouhoul_: has joined #ruby
[17:29:37] chouhoul_: has joined #ruby
[17:30:44] chouhoul_: has joined #ruby
[17:31:21] jinie: has joined #ruby
[17:31:49] chouhoulis: has joined #ruby
[17:33:03] chouhoul_: has joined #ruby
[17:33:11] mikecmpbll: has joined #ruby
[17:33:20] Mike11: has joined #ruby
[17:34:02] chouhoul_: has joined #ruby
[17:35:12] chouhoul_: has joined #ruby
[17:35:55] [Butch]: has joined #ruby
[17:36:18] chouhoul_: has joined #ruby
[17:36:48] jottr: has joined #ruby
[17:37:21] chouhoulis: has joined #ruby
[17:39:54] Paraxial: has joined #ruby
[17:41:21] nowhere_man: has joined #ruby
[17:43:42] Lytol: has joined #ruby
[17:46:30] Paraxial: has joined #ruby
[17:48:51] Cavallari: has joined #ruby
[17:49:02] npgm: has joined #ruby
[17:49:56] mtkd: has joined #ruby
[17:59:11] ramfjord: has joined #ruby
[17:59:39] amatas: has joined #ruby
[18:01:31] RougeR: has joined #ruby
[18:01:31] RougeR: has joined #ruby
[18:02:28] amatas_: has joined #ruby
[18:03:40] dviola: has joined #ruby
[18:05:20] bmurt: has joined #ruby
[18:06:55] amatas_: has joined #ruby
[18:07:57] karapetyan: has joined #ruby
[18:08:31] za1b1tsu: has joined #ruby
[18:08:50] amatas: has joined #ruby
[18:10:18] mtkd: has joined #ruby
[18:13:59] TomyLobo: has joined #ruby
[18:14:59] pabs: has joined #ruby
[18:17:00] chatts: has joined #ruby
[18:17:38] Paraxial: has joined #ruby
[18:18:14] jottr: has joined #ruby
[18:28:11] Paraxial: has joined #ruby
[18:33:20] micutzu: has joined #ruby
[18:34:01] mtkd: has joined #ruby
[18:36:28] Paraxial: has joined #ruby
[18:40:37] orbyt_: has joined #ruby
[18:41:51] Paraxial: has joined #ruby
[18:43:36] \void: has joined #ruby
[18:49:00] izaac: has joined #ruby
[18:54:29] jenrzzz: has joined #ruby
[18:54:29] jenrzzz: has joined #ruby
[18:58:15] dionysus69: has joined #ruby
[19:02:03] cadillac_: has joined #ruby
[19:02:32] lethan: has joined #ruby
[19:04:06] kapil___: has joined #ruby
[19:11:47] moei: has joined #ruby
[19:18:33] tanema: has joined #ruby
[19:19:09] Paraxial: has joined #ruby
[19:28:24] agent_white: has joined #ruby
[19:35:00] Paraxial: has joined #ruby
[19:36:23] cthulchu: folks, how do we execute_script having the @selenium_wrapper
[19:36:56] tanema: has joined #ruby
[19:37:00] mtkd: has joined #ruby
[19:38:22] cthulchu: or @driver_wrapper
[19:42:21] cthulchu_: has joined #ruby
[19:50:47] dminuoso: arne: Hah okay. So it turns out the Ruby implementation of TVar is way too naive to pull this off.
[19:53:00] pabs: has joined #ruby
[19:56:18] tanema: has joined #ruby
[19:56:48] tdy1: has joined #ruby
[20:02:08] amar: has joined #ruby
[20:05:36] tAn: has joined #ruby
[20:09:39] karapetyan: has joined #ruby
[20:12:16] tanema: has joined #ruby
[20:13:50] dionysus69: has joined #ruby
[20:13:54] tdy1: has joined #ruby
[20:18:04] grilix: has joined #ruby
[20:19:11] jottr: has joined #ruby
[20:20:47] cthu|: has joined #ruby
[20:20:53] Megamos: has joined #ruby
[20:24:41] venmx: has joined #ruby
[20:28:50] tanema: has joined #ruby
[20:30:29] beefjoe: has joined #ruby
[20:32:23] Megamos: has joined #ruby
[20:37:43] tAn: has joined #ruby
[20:41:16] weaksauce: has joined #ruby
[20:42:37] tdy1: has joined #ruby
[20:44:27] akem: has joined #ruby
[20:45:22] edwardly: has joined #ruby
[20:45:23] edwardly: has joined #ruby
[20:47:36] micutzu: has joined #ruby
[20:52:38] BlopMonster: has joined #ruby
[20:59:38] orbyt_: has joined #ruby
[21:01:43] lunarkitty7: has joined #ruby
[21:01:59] yellowman: has joined #ruby
[21:03:52] yellowman: Hi, I'm trying to use Builder::XmlMarkup, and over here https://github.com/jimweirich/builder#version-200-compatibility-changes it says I have to use symbol values to not escape the XML. How do I pass a string value contained in a hash as a symbol?
[21:10:21] pabs: has joined #ruby
[21:12:23] yellowman: Never mind, that is for attributes only. I figured it out.
[21:12:57] t0xik: has joined #ruby
[21:13:15] beefjoe: has joined #ruby
[21:13:23] chouhoul_: has joined #ruby
[21:15:28] mjolnird: has joined #ruby
[21:27:54] beefjoe: Why is this not working
[21:28:02] beefjoe: `JSON.generate({ :result => res) })`
[21:28:15] beefjoe: says syntax error
[21:28:23] beefjoe: res is a variable
[21:29:08] Zarthus: look at the )
[21:29:13] Zarthus: there's two of them.
[21:29:20] Zarthus: But the number of ( I See is only one.
[21:29:48] Zarthus: ..by using your eyes.
[21:29:52] Zarthus: I'm not sure what to tell you.
[21:31:05] edwardly: has joined #ruby
[21:31:05] edwardly: has joined #ruby
[21:36:16] amar_: has joined #ruby
[21:39:10] za1b1tsu: has joined #ruby
[21:39:29] planigan: has joined #ruby
[21:40:47] karapetyan: has joined #ruby
[21:41:39] eckhardt_: has joined #ruby
[21:42:28] nowhere_man: has joined #ruby
[21:43:58] ramfjord: has joined #ruby
[21:45:07] micutzu: has joined #ruby
[21:45:48] Anthony_Bourdain: has joined #ruby
[21:46:33] karapetyan: has joined #ruby
[21:46:53] cthulchu_: has joined #ruby
[21:48:55] sonOfRa: has joined #ruby
[21:49:19] karapety_: has joined #ruby
[21:49:56] ramfjord: has joined #ruby
[21:52:10] eckhardt_: has joined #ruby
[21:55:57] ramfjord: has joined #ruby
[22:00:15] beefjoe: has joined #ruby
[22:01:41] ramfjord: has joined #ruby
[22:05:31] cliluw: has joined #ruby
[22:07:46] eckhardt_: has joined #ruby
[22:08:06] Paraxial: has joined #ruby
[22:13:01] jenrzzz: has joined #ruby
[22:13:02] jenrzzz: has joined #ruby
[22:17:45] knight33: has joined #ruby
[22:20:21] jottr: has joined #ruby
[22:21:55] sameerynho: has joined #ruby
[22:24:16] Puffball: has joined #ruby
[22:24:52] postmodern: has joined #ruby
[22:32:36] cthulchu_: folks, I have a question about instance variables
[22:32:51] havenwood: cthulchu_: ask away
[22:33:19] cthulchu_: if we extend a class that has @a. We extend it by creating another class. How do we refer to that @a in the child class? just @a?
[22:33:39] apeiros: cthulchu_: you can't
[22:33:55] apeiros: instance variables belong to a single object
[22:34:08] apeiros: and in the case of it belonging to a class, it belongs to that class alone.
[22:34:53] cthulchu_: I don't understand why can't I
[22:35:12] apeiros: lets see whether you understand it for "normal" instances
[22:36:01] apeiros: >> class Foo; def initialize(x); @x = x; end; attr_reader :x; end; a = Foo.new(:ivar_of_a); b = Foo.new(:ivar_of_b); {a: a.x, b: b.x}
[22:36:02] ruby[bot]: apeiros: # => {:a=>:ivar_of_a, :b=>:ivar_of_b} (https://eval.in/1017991)
[22:36:33] apeiros: cthulchu_: ^ you understand why a.x and b.x are different, and that a can't access b's @x directly?
[22:38:43] cthulchu_: I have a class "living being" with variable @height. I extend it with a class "dog". Can I use @height in dogs?
[22:39:25] apeiros: yes. but the values in LivingBeing will not be the same as in Dogs.
[22:39:39] cthulchu_: I didn't ask if the values in living being will be the same
[22:39:59] apeiros: yes, but your question was also vague.
[22:40:39] apeiros: but I'll note that you want strictly just answers to what you've asked. I hope you're prepared to deal with potential confusion then :-p
[22:40:58] cthulchu_: yes, it'd be faster :)
[22:41:20] amar: has joined #ruby
[22:43:23] shinnya: has joined #ruby
[22:44:41] cthulchu_: so just like in other languages, if I create a dog, it implicitly creates a living being
[22:44:58] cthulchu_: and all the @ variables defined in living being are now can be used in dog
[22:45:00] apeiros: that's not how I'd phrase it.
[22:45:12] apeiros: that's also strictly not accurate.
[22:45:15] cthulchu_: it's just I'm tring to read this code properly
[22:45:23] cthulchu_: ok, what's not accurate?
[22:45:43] apeiros: you don't define variables in ruby. first assignment vivifies them.
[22:46:16] apeiros: code running in the context of an object has access to ivars of that object
[22:46:41] apeiros: i.e. a superclass' method running on an object has access because it runs in the context of a subclass' instance.
[22:46:59] cthulchu_: interesting
[22:47:14] apeiros: and classes are objects. their ivars obey the same rules.
[22:47:19] cthulchu_: so we can use ivars of a subclass in a superclass' method?
[22:47:34] apeiros: and vice versa.
[22:47:40] cthulchu_: anyhow, why then do this? https://i.imgur.com/0TGcDa3.png
[22:47:51] apeiros: because "ivars of a class" is wrong
[22:47:55] apeiros: it's "ivars of an object"
[22:47:59] cthulchu_: right right
[22:48:12] apeiros: code as an image? srsly? :D
[22:48:21] cthulchu_: well it's in a VNC here
[22:48:26] cthulchu_: hard to copy from there
[22:48:36] apeiros: you'd have to ask the author. I do it to make it clear which variables will be used in a class.
[22:48:47] apeiros: i.e. I'll always initialize all ivars in #initialize
[22:48:52] apeiros: but it's not required.
[22:49:31] apeiros: ivars and globals are special in that they can also autovivify on first read (they'll automatically be assigned nil)
[22:50:10] apeiros: >> class Foo; attr_accessor :x; end; foo = Foo.new; p before: foo.instance_variables; foo.x; p after: foo.instance_variables # check the link
[22:50:11] ruby[bot]: apeiros: # => {:before=>[]} ...check link for more (https://eval.in/1017993)
[22:50:34] apeiros: that's interesting. probably an optimization
[22:50:47] cthulchu_: if I have a thing -> living being -> dog -> saint bernard structure and I have a saint bernard object. Can I access methods of a thing directly from my lovely saint bernard?
[22:51:31] cthulchu_: oh, one more thing. there's no protection?
[22:51:52] cthulchu_: I don't see private, public, protected, etc
[22:51:58] apeiros: wow, apparently that has changed a long time ago already.
[22:52:03] cthulchu_: so all is public?
[22:52:21] havenwood: apeiros: Fixed: http://gif-in-gif.com/images/1528498300-3604344.gif
[22:52:30] apeiros: you can mark methods as private or protected. but it's not the same as in java.
[22:52:42] apeiros: also it's more like "advisory", it can be bypassed.
[22:52:57] apeiros: havenwood: 👍🏻
[22:53:05] apeiros: cthulchu_: and the mechanics for protected are iirc also different.
[22:54:08] cthulchu_: so I can access any superclass' method from any representative of any of its subclasses
[22:54:41] apeiros: hm, it seems I misremembered this. ok, so reading does not actually add them to the ivar table.
[22:55:07] apeiros: cthulchu_: in general, yes.
[22:55:25] apeiros: there are a couple of "but"s
[22:55:42] cthulchu_: seems like a pretty relaxed language
[22:55:57] apeiros: it is. if you want to aim a rocket launcher at your foot, ruby will gladly let you.
[22:56:22] apeiros: it does provide you with tools to give you a hint that it might not be a good idea :)
[22:59:44] zenspider: has joined #ruby
[23:02:33] BigRonnieRon: has joined #ruby
[23:02:47] cthulchu_: and so we also can do something like @object1.@object2?
[23:02:51] RougeR: has joined #ruby
[23:02:52] RougeR: has joined #ruby
[23:03:42] cthulchu_: we can't do that
[23:03:46] cthulchu_: okay, it's weird
[23:03:48] FernandoBasso: What do the cool people use for unicode string manipulation in ruby?
[23:04:26] cthulchu_: I have this awesome method (probably Object's method) that is instance_variables
[23:04:44] cthulchu_: so I can do @selenium_wrapper.instance_variables
[23:04:59] cthulchu_: and get a list of them when I puts them
[23:05:19] cthulchu_: one of the thing I get in the output is the @driver
[23:05:46] cthulchu_: how do I refer to that driver? @selenium_wrapper.driver doesn't work, to my surprise.
[23:05:56] cthulchu_: @selenium_wrapper.@driver doesn't work either
[23:06:58] Zarthus: cthulchu_: what's the output of the puts
[23:07:03] cthulchu_: it says undefined method driver
[23:07:06] cthulchu_: but it's not a method
[23:07:16] cthulchu_: and I don't ask for .driver()
[23:07:20] cthulchu_: I ask for .driver
[23:07:36] ramfjord: has joined #ruby
[23:08:26] Zarthus: irb(main):021:0> A.new.instance_variables[0] => :@x
[23:08:33] Zarthus: this doesn't return the value, just the name
[23:08:40] Zarthus: you want to add getter/setter methods.
[23:09:10] cthulchu_: I also investigated. I found the class of my selenium_wrapper and make sure that it's the class I get when puts selenium_wrapper.class
[23:09:22] cthulchu_: and that class looks good and driver is there
[23:09:30] micutzu: has joined #ruby
[23:09:45] zenspider: has joined #ruby
[23:10:40] cthulchu_: there's .instance_variable_get("@#{name}")
[23:11:03] cthulchu_: this is very unusual, but I guess Ruby had a reason to complicate things like so
[23:12:09] Zarthus: *shrug* i would still use a getter
[23:12:44] Zarthus: i haven't really got the ruby expertise for it, but just because something exists doesn't mean it should be used :P
[23:12:44] cthulchu_: sure, a getter... even Java has easier access to them and it can enforce the use of getters
[23:13:12] amar: has joined #ruby
[23:13:30] cthulchu_: oh! it worked
[23:13:37] ogres: has joined #ruby
[23:13:52] cthulchu_: hell I wouldn't expect something so trivial to be so difficult, but cool! I have the driver! ha! congrats!
[23:14:55] cthulchu_: ahahahah, and now I see that there actually is a get_driver
[23:15:19] cthulchu_: but it's good to know I can get stuff I need when I need it
[23:16:49] venmx: has joined #ruby
[23:17:24] apeiros: cthulchu_: are you using pry?
[23:17:36] apeiros: if so, try `ls @selenium_wrapper`
[23:17:52] cthulchu_: I don't know what pry is.
[23:17:58] apeiros: do you know irb?
[23:18:19] cthulchu_: no. It's not my framework. I'm just studying it to inject my testing in existing tests
[23:18:35] cthulchu_: they test frontend functionality and I'm injecting analytics testing in there
[23:18:36] apeiros: trying to find common ground here… do you know what a repl is?
[23:19:02] apeiros: ok, I guess best thing is you just try it. in your shell, type `irb` and hit enter.
[23:19:23] apeiros: you're in an interactive ruby env there. every line you type is executed and the result shown.
[23:19:29] apeiros: repl = read eval print loop
[23:19:34] apeiros: irb ships with ruby
[23:19:46] cthulchu_: that I have
[23:19:48] apeiros: pry = a better irb, but doesn't ship with ruby (`gem install pry` to get it)
[23:20:02] tAn: has joined #ruby
[23:20:03] cthulchu_: why do I need irb though?
[23:20:16] apeiros: to quickly test things
[23:20:29] cthulchu_: but I won't be able to test my classes there
[23:20:34] apeiros: if you have pry installed, you can put `binding.pry` anywhere in your code and it'll drop you into a pry session when that line hits
[23:20:38] cthulchu_: only basic Ruby functionality
[23:20:45] apeiros: you can load any code into irb
[23:20:56] apeiros: also binding.pry is more what I wanted to tell you about
[23:21:06] apeiros: it makes it easy to poke around
[23:21:09] cthulchu_: let me play with it first
[23:21:49] apeiros: another note: if @selenium_wrapper.driver does not exist (and hence does not return @driver), it usually means that the author did not want users to access @driver
[23:22:41] eelster: has joined #ruby
[23:22:55] apeiros: since classes are open, you can always patch it in live in a session. @selenium_wrapper.class.class_eval do attr_accessor :driver end
[23:23:02] cthulchu_: should I require it first maybe?
[23:23:21] cthulchu_: how do I require it after I installed it?
[23:23:29] apeiros: sorry, some things become obvious at some point and one forgets to mention them.
[23:23:33] apeiros: require 'pry'
[23:23:45] apeiros: if your project uses a Gemfile, you have to add it there
[23:24:37] cthulchu_: no, require 'pry' doesn't work
[23:25:01] cthulchu_: says can't cannot load such file -- pry (LoadError)
[23:25:31] agent_white: has joined #ruby
[23:26:14] cthulchu_: and it's installed. weird
[23:26:32] chat: has joined #ruby
[23:27:27] cthulchu_: gemfile thenn
[23:27:33] Zarthus: if it's a literal wrapper, it makes sense it's called get_driver
[23:27:44] Zarthus: but a good wrapper would make it use rubyisms.
[23:27:57] lupine: mm, rename it to chunky_bacon
[23:27:58] tAn: has joined #ruby
[23:28:12] cthulchu_: hooooooooly coooow!
[23:28:27] cthulchu_: this is like a debugging heaven
[23:28:40] cthulchu_: my QA friends will be so happy to learn about it
[23:28:42] Zarthus: it's uh.. pretty normal.
[23:28:54] Zarthus: are you not a ruby developer by trade?
[23:29:02] cthulchu_: I wonder if JS has it
[23:29:04] cthulchu_: gonna go ask
[23:29:11] Zarthus: your colleagues don't really do teamwork huh :P
[23:29:28] Zarthus: it's called a "REPL", and nodejs has one
[23:30:28] cthulchu_: oh, good then
[23:30:30] Zarthus: pry is by far one of the most pleasant ones to use though.
[23:30:56] cthulchu_: and I have two bloody computer science higher educations
[23:31:08] cthulchu_: why don't they teach it
[23:31:09] Zarthus: they don't teach kids useful things in school ;)
[23:31:18] agent_white: A cozy cottage of code creations cushioning comfortably conjunctively.
[23:35:20] apeiros: cthulchu_: eh, higher eds are supposed to learn about the "lower level stuff" themselves ;-p
[23:36:38] Zarthus: apeiros: Lower level stuff, like SQL injections and upgrading your PHP version from old, EOL versions ;)
[23:37:13] apeiros: "here's some books, read them". or actually even just: "there are books, you should pick some and read them"
[23:37:33] apeiros: oh well, I'm old
[23:37:44] apeiros: today it's probably just "eh, you know how google works, right?"
[23:37:45] Zarthus: apeiros: Not kidding, they used php5.2 and `ext-mysql` (which doesn't support prepared statements, only "real_escape_string", even that wasn't taught) in the first year of college. In 2016 or so.
[23:37:57] Zarthus: for the record, php5.2 was created in 2006 or so
[23:38:23] apeiros: I know. I used php5.2, one of the last versions I used before I found ruby.
[23:38:25] cthulchu_: we used php of 2013 version in my college.
[23:38:29] cthulchu_: it had issues with chaining
[23:38:37] cthulchu_: and ternaries
[23:38:37] apeiros: lolwut? still?
[23:38:45] apeiros: I remember php4 could not chain at all.
[23:38:55] cthulchu_: it could, but not always
[23:38:56] apeiros: $foo->bar()->baz() was a syntax error
[23:38:56] Zarthus: php 2013 shouldn't have any problems with either of those.
[23:39:22] apeiros: more like: I'm not aware of a situation where it could. you had to assign to temp variables to chain.
[23:39:31] Zarthus: would be nice if most colleges would just brush up on their modernisation a little bit, anyhow.
[23:39:46] cthulchu_: I ended up having temporary vars
[23:39:51] cthulchu_: completely unneded otherwise
[23:39:55] Zarthus: php4 was terrible, php5 (later versions, 5.4+) was OK, php7+ is nice.
[23:39:55] apeiros: yeah. same.
[23:40:10] apeiros: I came to php4 from perl. always considered it a downgrade.
[23:40:21] Zarthus: sounds about right.
[23:40:32] cthulchu_: after so much disappointment with php, I rewrote all my php stuff into node
[23:40:40] cthulchu_: I embrased callbacks
[23:41:36] Zarthus: we use nodejs at work for a small application made by one node fanatic which has since left the company. None of us want to really learn it
[23:41:49] Zarthus: we're competent enough to write javascript, though.
[23:42:04] lupine: just transpile it to C
[23:42:18] lupine: get your own back
[23:42:29] cthulchu_: node is js. very convenient to work with web
[23:43:01] Zarthus: i'm sure there's specific things to nodejs that we don't learn/care about.
[23:43:03] cthulchu_: although I must admit, I enhoy ruby's syntax a lot more than JS'
[23:43:09] Zarthus: we just treat it as vanilla js
[23:50:04] apeiros: transpile… unword of the year 2016…
[23:50:18] FernandoBasso: Damn php killed perl.
[23:50:21] apeiros: (it's compile)
[23:50:46] FernandoBasso: People stopped using perl for web because php was the new shiny cute thing.
[23:50:56] FernandoBasso: (well, not cute, and not shiny)
[23:51:02] cthulchu_: yes! it worked!
[23:51:08] apeiros: FernandoBasso: right. polished turd.
[23:51:21] cthulchu_: I managed to get JS objects from Selenium into here
[23:51:33] apeiros: cthulchu_: 👍🏻
[23:51:40] cthulchu_: how do we work with JS objects in Ruby though?
[23:51:57] Zarthus: i imagine it involves reading the documentation.
[23:52:29] apeiros: cthulchu_: depends on how the integration layer works. the objects are probably bridged. at least if it uses libv8 or something similar.
[23:52:54] cthulchu_: https://i.imgur.com/c1ZjItm.png
[23:53:02] cthulchu_: I'm getting that large Json object
[23:53:17] cthulchu_: in JS I can cast json into object and work with it very conveniently
[23:53:23] apeiros: ?jsonobject
[23:53:23] ruby[bot]: there is no such thing as a JSON object. You either have a String containing serialized JSON, or you have ruby objects (usually Hashes/Arrays/Strings). Which is it?
[23:53:35] apeiros: and from your image, I'd say you have a ruby object
[23:53:47] apeiros: (array of hashes & stuff)
[23:54:16] apeiros: I *can* be mistaken. you can verify by asking for its class.
[23:54:25] cthulchu_: I will then
[23:55:23] apeiros: re json object not existing: in other languages, it'll of course be objects of that language instead of "ruby objects". e.g. in javascript it'll be javascript arrays, objects, strings etc.
[23:57:09] cajone: has left #ruby: ()
[23:58:00] cthulchu_: the type is array
[23:58:04] cthulchu_: which is perfect
[23:58:13] cthulchu_: it's how I work with it in the browser console