#ruby - 16 September 2017
« Back 1 day Forward 1 day »
[00:11:23] Radar: Don't know why you'd want to do that. The dependency may be a dependency of another gem.
[00:11:59] imode: Radar: it's not, because I didn't realize heroku's gem CLI was deprecated. it pulled its own dependencies.
[00:14:14] imode: guess I'll just have to be careful. it's all clean now, but that's mildly infuriating.
[00:19:32] havenwood: imode: With how RubyGems currently works it's not possible to tell which can be removed without borking other things.
[00:20:29] matthewd: To be fair, most system package managers only grew that ability relatively recently
[00:20:48] havenwood: yeah, those and others have the concept of explicitly-installed versus installed as a dependency.
[00:24:28] havenwood: imode: It's an interesting idea to add to RubyGems. I think the first step would be differentiating explicitly-installed gems somehow.
[00:25:13] havenwood: different directories seem problematic because many would be in both categories
[00:27:41] havenwood: also note many of the package managers can show packages without dependants but not those that have been manually installed
[00:32:28] havenwood: i guess you could do a RubyGems uninstall feature that uninstalled packages that are and the dependency tree of something that lost a dependant in the unintsall. It's not straightforward.
[00:36:55] Radar: Weird to be talking about Heroku CLI like it's a Rubygem. I thought the latest version was a node.js package.
[00:37:31] havenwood: Radar: I think it's even mostly Go, unsure. The API parts oddly seem to still be Node.js.
[00:37:36] havenwood: They seem to be working on it quite a bit, because there are frequent releases.
[02:26:57] havenwood: What's a good name for an auto-scheduled fiber? There's got to be something better than "Thriber"...
[02:32:33] Salmonidae: i dunno if the emphasis on thread is worth it. not really up to date with the issue. but sounds like a Fiber that schedules itself autoatically. that's not really very similar to a thread.
[02:43:08] Salmonidae: `thriber: green threads implemented using fibers`. i think commit message says a lot.
[02:51:43] veex: Salmonidae, I like thriber too, it's catchy. thought about `fibert` but a quick search yields it's a family name :)
[02:52:45] Salmonidae: `Yields` as class name is bit strange. i guess. i think Thriber is fine too. Fred might be a bit too much. but i'd accept FredFlinstone.
[02:55:45] veex: Me neither as you already know, saw someone asking for suggestion and thought I'd contribute too!
[03:04:54] veex: I'm not a fan either but some episodes to make me lol. Trying to practice equal distribution for laughter, lol.
[08:03:45] teatime: hmm... these aren't equivalent, are they? (10 - (x % 10)) % 10 and 10 - x % 10 % 10
[08:11:15] teatime: that leading unary - would be easy for a reader to miss, but not worth changing it to -( )
[11:09:06] maesitos: Hello I'm at the 14th chapter of The grounded Rubyist and there's something I don't understand. Could anybody take a look at this example and let me know why one works while the other doesn't? https://pastebin.com/raw/mh16Kspj
[11:09:07] ruby[bot]: maesitos: we in #ruby do not like pastebin.com, it loads slowly for most, has ads which are distracting and has terrible formatting. Please use https://gist.github.com
[11:37:37] mistnim: how do I run a system command so that if my ruby script exits it will continue to run?
[11:40:52] Papierkorb: mistnim: There's the `daemons` gem. But instead, consider using a daemon process manager, like systemd (which you probably already use on your linux box), instead of rolling this yourself.
[11:41:24] Salmonidae: probably you need to rethink what you're doing. what Papierkorb said sounds right.
[11:41:48] Papierkorb: mistnim: You get monitoring, easy access, permission management, and much more for free this way. On top of that, this knowledge isn't bound to ruby, you can use it with anything you like :)
[11:42:12] Salmonidae: but not systemd. im not sure. sounds overkill. maybe a ruby daemon that can spawn processes for you. script that can exit be its client
[11:42:39] Papierkorb: Systemd is perfectly fine if you already use it anyway. It's the de facto standard
[11:42:45] teatime: (pid = fork) ? Process.detach(pid) : exec("foo") <-- this seems concise and correct?
[11:49:43] teatime: Salmonidae: I think it is, that seems to be the purpose of it. It can hold the exit value in Ruby waiting for you to maybe eventually join the thread, but it looks like it goes ahead and waitpid's your child immediately so that it can leave the process table upon termination.
[11:50:21] Salmonidae: im not sure if that is what mistnim wants or not. Thread#join implies waiting.
[11:50:45] teatime: mistnim: also, if the parent script is short-lived / expected to terminate, the children will be inherited by init (PID 1), and it will waitpid/clear them. The children can only be zombies while your parent script is running.
[11:51:42] teatime: Salmonidae: If you don't care about the return value, just never join the thread, right? that's what I gathered from the docs. I will happily defer to your mad Ruby skillz, though, for I am a n00b.
[11:52:43] Salmonidae: i am saying that. the question is: "how do I run a system command so that if my ruby script exits it will continue to run?". if you Thread#join, you don't exit.
[12:01:26] teatime: Salmonidae: I tried it out; seems to work (ruby script can exit immediately, if it does not exit subprocess does not become defunct, if it does exit subprocess is inherited by init)
[12:04:10] Salmonidae: dunno if it is the approach i'd take. i would rather another ruby process taking responsibility of "init". but for this use case it's most likely fine
[12:07:03] Salmonidae: another process allows you query state of spawned processes, and so on. you could use `Process.detach` there too, then just the threads.
[12:08:10] teatime: I do agree that if what you need a process supervisor, you should probably use a good, existing one, esp. since there's already one running on the box (systemd)
[12:11:25] Salmonidae: dunno if they can spawn via IPC though. i think you describe processes first and then it manages them. so not quite the same.
[13:34:03] mustmodify: I'm doing a presentation about Rails to a developer meetup. Hard to understand, but I've repeatedly had people ask me "What is Rails?" I thought I'd devote half my time to Ruby and half to Rails. I know a ton about Ruby. I love Ruby. But I'm having a hard time thinking of exactly how to express what I love about Ruby in small examples that will be digestable to non-Ruby devs. Obviously blocks are a big thing. The actual classes, unlike js, php etc. Classes
[13:37:07] Salmonidae: Proc, exhibit closure-behaviour. dynamic method dispatch (method_missing). dynamic constant dispatch (const_missing/const_get). monkey patching. modify code at runtime. meta programming.
[13:37:41] teatime: mustmodify: perhaps some examples of tight-but-clear expressions/oneliners.. the kinds of things Perl does well, Ruby does also
[13:37:58] mustmodify: yeah, what would be a good, simple example of method missing that didn't make me seem like frankenstein?
[13:38:01] Salmonidae: not sure what else. oh. x = Object.new; def x.bar(); end; this method of programming as opposed to classical.
[13:38:14] mustmodify: I mean, I love method missing. But I worry people would be like, "You can't just do that... "
[13:38:33] Salmonidae: sure. i thought that too. all those features make ruby slow. so know your audience a little bit.
[13:39:16] mustmodify: I think I can do about half an hour on that stuff. Makes me want to do a full presentation on Ruby. :)
[15:12:12] bougyman: anyone know why curl would work on a box but ruby (rest-client) gives SSL Verify Fail?
[16:30:12] RedNifre: bougyman I was to lazy to figure out what the problem is so I just did `curl ...` instead.
[16:38:33] havenwood: bougyman: probably needed to dynamically link against your new openssl, and you do need to rebuild for that
[18:25:51] haylon: Well, I want to make a gem that I could require into a Rakefile and have it populate tasks. I'm not sure exactly I need
[21:59:17] baweaver: Found a new metaphor for TDD: It's a maze. You start at the outside (acceptance tests) and work your way inwards (integration, unit), discovering the implementation as you go until you reach the center (the application)
[22:27:35] Slinky_Pete: how do I stop test/unit from exiting after a flunk, shouldn't it notice the flunk and run the next line?
[22:28:53] Slinky_Pete: Ex. assert_equal(true, false, flunk) after it is exiting without running further tests
[22:31:12] baweaver: tamouse__: More of that you start at the outside of your app (API / UI) and discover it as you get in deeper. You have to discover the outer API before you can know how you expect parts to integrate before you know how the individual units of it will work
[22:32:25] baweaver: I've noticed that the less I know what it is I'm trying to make the more of a mess I make in the interim
[22:33:01] baweaver: The outside would be something like I expect when I click this button it'll give me a cookie
[22:33:17] baweaver: As to how that happens, that's not quite relevant until I know what I expect it to do at a top level
[22:33:57] baweaver: It may be a bit more abstracted from it. More of rubber-ducking random musings at this point
[22:35:54] tamouse__: i'm still a bit partial to the notion of levels, shells, and particls/atoms/molecules/organisms
[22:39:51] tamouse__: well, levels, like we used to talk about in top-down design you start at the top and work your way down through levels, spreading out
[22:41:58] tamouse__: the lattermore organic, you have a organism to test, and then it's "organs", suborgans, the molecules, the atoms, and particls that make that all up
[22:44:24] baweaver: trying to refine some ideas. Teaching an entire RSpec course at work and the first segment is on Thursday.
[22:45:02] tamouse__: hmm, maybe a suggestion: use a few metaphors without really trying to explaikn them overmuch
[22:47:17] baweaver: I'll probably just start with unit testing, getting guard running, and keeping functions simple
[22:50:25] baweaver: You know how tests are usually a pyramid diagram of Unit > Integration > Acceptance?
[22:52:52] baweaver: Take that pyramid and extrude it into a circle with Acceptance > Integration > Unit > Application
[22:54:02] tamouse__: i think that lines up with teh notion of "shells". that's what i thought of when reading the cucumber book ages ago
[22:55:00] baweaver: So you see all three groups of tests executing as children of the next level up
[22:56:01] baweaver: e.x. Scenario click button to get a cookie > button triggers dispenser & dispenser fetches cookie & factory gives cookie to dispenser > factory makes cookie....
[22:56:24] baweaver: So you can see it like a tree where certain tests are natural descendants of their parents
[22:57:16] baweaver: Why it'd be useful: You broke a unit so it'll point to the broken scenario and red flag the entire path down to it, isolating where the break happens and what it got up the chain
[22:59:22] baweaver: pods being a frontend concept where the component, route, model, and other pieces of a single concept are in one folder, like User Menu