« Back to channel list

#ruby - 15 September 2018

« Back 1 day Forward 1 day »
[00:12:23] DTZUZO: has joined #ruby
[00:49:47] heinrich5991: has joined #ruby
[00:53:15] madhatter: has joined #ruby
[00:58:40] madhatter: has joined #ruby
[01:01:24] graphene: has joined #ruby
[01:14:31] jokke1: has joined #ruby
[01:23:57] madhatter: has joined #ruby
[01:27:21] graphene: has joined #ruby
[01:28:55] orbyt_: has joined #ruby
[01:35:48] jokke1: has joined #ruby
[01:36:54] lxsameer: has joined #ruby
[01:40:16] heinrich5991: has joined #ruby
[01:43:26] tpendragon: has joined #ruby
[01:52:30] graphene: has joined #ruby
[01:56:00] Tempesta: has joined #ruby
[02:04:29] geckos: has joined #ruby
[02:06:00] geckos: I just installed rails gem but didn't get the raisl command
[02:06:05] geckos: I'm on Fedora
[02:06:56] geckos: I was expecting ~/.gem/ruby/bin to exists, but it doesn't
[02:21:30] havenwood: geckos: How'd you install rails?
[02:21:39] havenwood: geckos: Did you?: gem install rails
[02:21:49] havenwood: geckos: What's your $GEM_HOME?
[02:22:05] havenwood: geckos: printenv GEM_HOME
[02:22:26] havenwood: geckos: What do you get for?: gem env gemdir
[02:22:50] havenwood: geckos: How about?: which -a rails
[02:22:53] geckos: ~/.gem/ruby
[02:23:05] geckos: which: no rails ...
[02:23:19] geckos: I was using ruby from distro packages
[02:23:22] havenwood: geckos: How about?: gem which rails
[02:23:25] geckos: Should I try rvm?
[02:23:34] havenwood: geckos: What package? Just curious.
[02:23:44] havenwood: geckos: I mean, what distro?
[02:24:02] geckos: /home/dhilst/.gem/ruby/gems/railties-5.2.1/lib/rails.rb
[02:24:17] havenwood: geckos: ah, nice
[02:24:51] kapil___: has joined #ruby
[02:25:26] havenwood: geckos: Is there a?: /home/dhilst/.gem/ruby/bin/rails
[02:25:42] geckos: no ~/.gem/ruby/bin :-/
[02:26:36] havenwood: geckos: Still the same after a?: gem pristine rails
[02:26:57] geckos: didnt try pristine
[02:27:22] geckos: no bin, even after pristine
[02:27:33] havenwood: geckos: Normally there's be a: "$(gem env gemdir)/bin/rails"
[02:27:57] havenwood: geckos: sec, sanity checking on Fedora
[02:28:50] geckos: I'll remove ruby form Fedora and install it with rvm
[02:29:02] havenwood: geckos: Or ruby-install + chruby should suffice.
[02:29:22] havenwood: geckos: Development or prod?
[02:29:26] havenwood: geckos: So odd the Rails binary isn't showing up...
[02:29:36] geckos: development
[02:29:41] havenwood: geckos: Anything odd in?: gem env
[02:30:04] havenwood: geckos: What is the?: EXECUTABLE DIRECTORY
[02:30:34] havenwood: gem env | grep "EXECUTABLE DIRECTORY"
[02:31:04] havenwood: geckos: Any odd settings under "GEM CONFIGURATION"?
[02:31:23] geckos: http://sprunge.us/9dgY32
[02:31:29] geckos: ^ gem env
[02:31:35] havenwood: Ah! /home/dhilst/bin
[02:31:55] havenwood: geckos: Is there a?: /home/dhilst/bin/rails
[02:32:03] geckos: There it is!
[02:32:10] havenwood: geckos: np!
[02:32:49] geckos: Would this be a Fedora trap?
[02:33:22] havenwood: geckos: If you feel like having it be the expected dir, you could: export GEM_HOME="$HOME/.gem/ruby"
[02:33:47] havenwood: geckos: On my install, the EXECUTABLE DIRECTORY is: /usr/bin
[02:34:00] havenwood: geckos: Oh, I'm root at the moment.
[02:34:06] havenwood: So yeah. :-P
[02:34:12] geckos: Are you on Fedora too?
[02:35:22] havenwood: geckos: I hopped onto Fedora to sanity check. I usually do use zsh.
[02:35:31] SeepingN: has joined #ruby
[02:35:58] havenwood: geckos: But yeah, no issue here with dnf Ruby with Fedora and zsh.
[02:36:18] havenwood: geckos: which rails #=> /usr/local/bin/rails
[02:36:57] havenwood: geckos: I have in my gem env: "gem" => "--install-dir=/usr/local/share/gems --bindir /usr/local/bin"
[02:37:23] havenwood: geckos: Dunno why our Fedoras are configured differently.
[02:38:23] havenwood: geckos: If you wanted to, you could: echo '"gem" => "--install-dir=/usr/local/share/gems --bindir /usr/local/bin"' >> "$HOME/.gemrc"
[02:38:24] geckos: I my messed everything up. I didn't even remeber when I installed this ruby
[02:38:57] havenwood: geckos: Though my setup assumed root user >.>
[02:39:39] havenwood: geckos: I don't usually use Fedora, but I do like it!
[02:39:39] geckos: Cam you: rpm -qf `which ruby` ?
[02:39:56] havenwood: geckos: rubypick-1.1.1-9.fc29.noarch
[02:40:04] geckos: Same here, thanks!
[02:40:09] geckos: I usually use Linux
[02:40:28] geckos: eita, br detectado
[02:56:56] orbyt_: has joined #ruby
[03:00:40] dviola: has joined #ruby
[03:07:18] zhustec: has joined #ruby
[03:09:39] braincrash: has joined #ruby
[03:10:31] dviola: has joined #ruby
[03:14:32] Xeago_: has joined #ruby
[03:16:00] jdawgaz: has joined #ruby
[03:24:44] elphe: has joined #ruby
[03:36:45] eckhardt: has joined #ruby
[03:38:25] jdawgaz: has joined #ruby
[03:40:05] duderonomy: has joined #ruby
[03:43:17] ciro: has joined #ruby
[03:44:40] jdawgaz: has joined #ruby
[03:50:09] cliluw: has joined #ruby
[03:55:31] tdy: has joined #ruby
[04:03:43] graphene: has joined #ruby
[04:13:56] bkxd: has joined #ruby
[04:13:58] Azure: has joined #ruby
[04:16:05] graphene: has joined #ruby
[04:17:27] bkxd: has left #ruby: ()
[04:31:01] moei: has joined #ruby
[04:41:16] ivanskie: has joined #ruby
[04:47:27] im0nde: has joined #ruby
[04:56:47] tdy: has joined #ruby
[04:58:40] reber: has joined #ruby
[05:00:49] graphene: has joined #ruby
[05:19:44] fredlinhares: has joined #ruby
[05:37:42] Nilium_: has joined #ruby
[05:48:42] Nilium: has joined #ruby
[05:55:36] Dbugger: has joined #ruby
[05:57:10] sauvin: has joined #ruby
[06:34:32] MoritaShinobu: has joined #ruby
[06:52:23] lomex: has joined #ruby
[07:01:14] darkhanb: has joined #ruby
[07:08:51] s2013: has joined #ruby
[07:10:57] dellavg_: has joined #ruby
[07:12:23] ShekharReddy: has joined #ruby
[07:14:47] duderonomy: has joined #ruby
[07:27:10] _whitelogger: has joined #ruby
[07:54:30] clemens3_: has joined #ruby
[07:58:08] xfbs: has joined #ruby
[08:03:14] zhustec: has joined #ruby
[08:06:23] yohji: has joined #ruby
[08:26:36] xfbs: has joined #ruby
[08:27:53] doubledup: has joined #ruby
[08:28:29] Mike11: has joined #ruby
[08:28:32] doubledup: has joined #ruby
[08:33:25] MoritaShinobu: has joined #ruby
[08:35:19] sameerynho: has joined #ruby
[08:41:07] sticaz: has joined #ruby
[08:52:07] lomex: has joined #ruby
[08:57:12] lomex: has joined #ruby
[09:05:20] desperek: has joined #ruby
[09:13:46] rippa: has joined #ruby
[09:15:24] dionysus70: has joined #ruby
[09:21:45] furrymcgee: has left #ruby: ()
[09:22:02] elphe: has joined #ruby
[09:30:42] conta: has joined #ruby
[10:01:10] apg: has joined #ruby
[10:02:42] apg: Hi, how do you prevent a map from returning an item that is taken from a range on Ruby?
[10:04:22] apg: for example a = 1.upto(Float::INFINITY).lazy.map{|x| x}.first(24), I do not want to add x % != 0
[10:04:33] lomex: has joined #ruby
[10:04:35] mitescugd: has left #ruby: ("C-x k")
[10:18:21] Mike11: has joined #ruby
[10:20:30] tristanp: has joined #ruby
[10:22:32] Puffball: has joined #ruby
[10:24:57] n13z: has joined #ruby
[10:26:58] bhaak: has joined #ruby
[10:39:24] apeiros: apg: I don't understand your question. part of that is `x % != 0` seems to be missing something
[10:39:56] apeiros: I'd assume the answer is to add a select before or after the map
[10:58:12] AJA4350: has joined #ruby
[11:01:52] leitz: has joined #ruby
[11:08:48] RougeR: has joined #ruby
[11:09:45] elphe: has joined #ruby
[11:17:21] apg: Sorry, I was mistyped
[11:17:32] apg: I mistyped
[11:18:03] leitz: apg, I missed it, so we're good. :)
[11:18:39] apg: apeiros, thanks. I ended up using select
[11:22:33] Xeago_: has joined #ruby
[11:23:54] leitz: What makes you decide "class" versus "OpenStruct"?
[11:30:12] _whitelogger: has joined #ruby
[11:34:27] amelliaa: has joined #ruby
[11:42:48] thy0: has joined #ruby
[11:58:30] elphe: has joined #ruby
[11:59:03] yohji: has joined #ruby
[11:59:32] apeiros: leitz: simple for me - openstruct only at drafting stage.
[12:00:50] jdawgaz: has joined #ruby
[12:01:29] leitz: apeiros, for me that may be an eternity. I've been trying to learn to code for a while. ;)
[12:02:17] leitz: In this case, I'm thinking of your comment about the character_tools mixin, and how the purpose for it seemed confusing.
[12:03:08] leitz: The "Character" class could be an Ostruct, there are only two or three "standard" methods the class would need, and they can be extracted to whatever class needs them.
[12:04:04] leitz: Since my view of "Character" is fairly organic, OStruct might be better.
[12:06:23] roshanavand: has joined #ruby
[12:08:29] apeiros: leitz: can you enumerate the properties a character has?
[12:10:33] kapil___: has joined #ruby
[12:11:29] leitz: apeiros, "enumerate" as in "explain" or as in "is enumerable"?
[12:11:39] apeiros: the latter
[12:11:57] apeiros: as in "is it a finite number of properties?"
[12:12:19] leitz: Ah, then depending on use case, no.
[12:13:27] leitz: It is a limited number of properties, but different use cases add properties while usually using the core set or properties.
[12:16:44] BrianJ: has joined #ruby
[12:17:36] BrianJ: Is this the right channel to ask for help on factoryBot and associations ? There is no #factorybot channel.. :-/
[12:18:41] FernandoBasso: has joined #ruby
[12:22:12] leitz: apeiros: https://gist.github.com/LeamHall/53609ff097768d6efc7b1e29097a3154
[12:22:48] apeiros: brianj: sure. chances might be better over in #rubyonrails, though, since I'd assume factorybot is most often used in conjunction with rails
[12:22:59] BrianJ: apeiros: ill try there, thanks
[12:23:28] apeiros: leitz: "needs to be able to add properties defined by the end user", ok, that qualifies as infinite
[12:24:04] apeiros: personally I'd still not use ostruct, but ostruct would work
[12:24:38] leitz: The issue I have is the ability to add properties that are undefined.
[12:25:26] leitz: I pulled "Character_Tools" out of "Character" because the tools are only used on creation, not on presentation.
[12:25:46] leitz: Having them combined made for a huge class definition.
[12:26:41] leitz: How would you set the Character class up to add properties not in the original class?
[12:28:09] apeiros: you'd want to avoid collisions, so I'd go via a proxy. i.e. some_character.first_name (as an example for any predefined property), and some_character.custom.userdefined_proprty_here
[12:28:40] apeiros: and for custom, you could use openstruct. (class Character; def initialize; @custom = OpenStruct.new; …)
[12:28:46] leitz: At the moment there are two sets of properties: "Base + Usual" and "Leitz's Expanded which includes Base + Usual".
[12:30:03] leitz: Ah, so the base Character has a "@custom" property?
[12:32:05] lomex: has joined #ruby
[12:33:41] leitz: Would you put the "standard" generation methods in the base class? There are a couple dozen of them. Less if the @custom stuff is pulled out.
[12:37:17] nowhere_man: has joined #ruby
[12:51:37] jackrandom: has joined #ruby
[13:17:25] ZzZombo_: has joined #ruby
[13:18:26] beefjoe: has joined #ruby
[13:48:09] ShekharReddy: has joined #ruby
[13:49:27] apeiros: leitz: sorry, missed your last question. not sure what you understand as "generation methods". but sounds like something which might be class methods.
[14:08:21] jgpawletko: has joined #ruby
[14:08:47] leitz: apeiros, no worries. Class Character can either take an existing hash and convert it to a Character, or it can take an empty hash and generate the data. For the "standard" use of the class, should the generation methods go into the base class? Those things all Characters have?
[14:09:47] apeiros: if I understand you correctly, then yes, those should be class methods of the base class.
[14:10:34] thy0: has joined #ruby
[14:14:35] leitz: Okay, i'm working on understanding it. Slowly...
[14:20:04] graphene: has joined #ruby
[14:26:07] cagomez: has joined #ruby
[14:26:39] ZzZombo: has joined #ruby
[14:30:29] leitz: apeiros, this is what I have so far. https://gist.github.com/LeamHall/d5aed9d0f1cfa0f55e74967310e90d66
[14:30:35] leitz: Critique?
[14:31:27] apeiros: generate belongs into class level (and parts of the code probably into a separate class even)
[14:32:28] apeiros: iirc, upp is a specific set of attributes, I wouldn't use a hash for that. at the very least a struct. and I wouldn't allow manipulation of it by replacing the full hash either (the upp= method)
[14:34:55] apeiros: ah, and stylistic thing: requires belong to the top of the file. even before opening the class.
[14:34:56] leitz: The "separate class" for generate was most of what "Character_Tools" did, I thought you recommended it be in the class?
[14:36:43] apeiros: the only reason I could imagine to recommend keeping it in the same class would be as a temporary thing to grow your code.
[14:37:18] apeiros: as far as I understand your problem domain, generation of characters will become rather complex. keeping that in the same class will put too many responsibilities in the same place.
[14:38:58] leitz: If the generation is pulled out then there are no real methods in the Character class. So back to an Ostruct.
[14:39:18] Azure: has joined #ruby
[14:40:25] leitz: There's a Presenter for different output styles, and I'm building stuff to input from CSV and JSON.
[14:44:00] apeiros: I'm pretty sure there's plenty of things one can do with a character which belong into that class. I doubt it'd just be a data container.
[14:44:40] elphe: has joined #ruby
[14:44:53] apeiros: also providing methods which connect it with generators and presenters can be worthwhile. it means you have a clear and understandable hub.
[14:45:33] apeiros: i.e. while you'd have something like Character::Generator, Character::JsonPresenter etc., you'd still use them via Character::generate and Character#to_json
[15:03:08] lomex: has joined #ruby
[15:04:22] elphe: has joined #ruby
[15:04:47] johnny56: has joined #ruby
[15:05:37] cagomez: has joined #ruby
[15:24:00] elphe: has joined #ruby
[15:30:44] graphene: has joined #ruby
[15:30:53] desperek: has joined #ruby
[15:33:52] elphe: has joined #ruby
[15:39:26] cagomez: has joined #ruby
[15:43:57] beefjoe: has joined #ruby
[15:48:23] cagomez: has joined #ruby
[15:53:32] elphe: has joined #ruby
[15:59:00] MoritaShinobu: has joined #ruby
[15:59:59] yohji: has joined #ruby
[16:03:01] segy: has joined #ruby
[16:13:13] elphe: has joined #ruby
[16:13:13] yxhuvud: has joined #ruby
[16:20:32] sticaz: has joined #ruby
[16:22:26] orbyt_: has joined #ruby
[16:23:09] tristanp: has joined #ruby
[16:32:58] elphe: has joined #ruby
[16:35:47] dviola: has joined #ruby
[16:48:24] elphe: has joined #ruby
[16:55:41] lomex: has joined #ruby
[16:58:45] tdy: has joined #ruby
[17:08:11] elphe_: has joined #ruby
[17:20:11] tristanp: has joined #ruby
[17:27:49] elphe: has joined #ruby
[17:44:35] graphene: has joined #ruby
[17:47:32] elphe: has joined #ruby
[17:54:10] FernandoBasso: has joined #ruby
[18:03:58] reber: has joined #ruby
[18:07:08] elphe: has joined #ruby
[18:11:21] cschneid_: has joined #ruby
[18:23:42] jokester: has joined #ruby
[18:26:51] elphe: has joined #ruby
[18:36:26] graphene: has joined #ruby
[18:36:39] elphe: has joined #ruby
[18:45:27] cd: has joined #ruby
[18:50:32] troulouliou_dev: has joined #ruby
[18:56:20] elphe: has joined #ruby
[18:59:00] yohji: has joined #ruby
[19:00:29] Puffball: has joined #ruby
[19:06:11] elphe: has joined #ruby
[19:16:01] elphe: has joined #ruby
[19:18:11] tolland: has joined #ruby
[19:27:08] xfbs: has joined #ruby
[19:27:56] Puffball: has joined #ruby
[19:35:37] elphe: has joined #ruby
[19:50:46] troulouliou_dev: has joined #ruby
[19:52:31] s2013: has joined #ruby
[19:55:22] elphe: has joined #ruby
[19:55:56] xfbs: has joined #ruby
[20:01:13] sameerynho: has joined #ruby
[20:03:18] lomex: has joined #ruby
[20:07:08] leitz: apeiros, do you know of some code that is structured like that? I'd love to take a look and learn.
[20:07:25] conta: has joined #ruby
[20:12:57] yohji: has joined #ruby
[20:15:02] elphe: has joined #ruby
[20:15:40] orbyt_: has joined #ruby
[20:17:20] marz_d`ghostman: has joined #ruby
[20:26:51] apeiros: eh, no. but I seem to remember that baweaver once wrote a reference implementation for what you wanted to do. he might have used that pattern.
[20:26:59] apeiros: (not really a pattern)
[20:27:32] thy0: has joined #ruby
[20:30:24] marz_d`ghostman: I have a gem mygem-my_util, so in my lib is ./lib/mygem/my_util/util/util.rb How do I describe it in RSpec? I tried Mygem/::Myutil::util::util
[20:31:54] leitz: apeiros, I read baweaver's stuff, can't say that I understand it yet. I sort of scratch my head and say "Nice...I think." ;)
[20:34:14] havenwood: marz_d`ghostman: Kinda odd to have a `.../util/util.rb`. Usually you'd see `/lib/mygem/my_util/util.rb` maybe with `/lib/mygem/my_util/util/something_else.rb`.
[20:34:38] havenwood: marz_d`ghostman: But if there were double utils, like you showed, it'd be: Mygem::MyUtil::Util::Util
[20:35:03] havenwood: marz_d`ghostman: The namespace should mirror the file and directory hierarchy.
[20:35:22] marz_d`ghostman: havenwood: the util.rb is the main class and the util folder will contain the main class along with any modules and classes that needs to be created
[20:35:46] graphene: has joined #ruby
[20:35:57] marz_d`ghostman: havenwood: Do I have to define a require somewhere? cause it's not working though
[20:36:03] herbmillerjr: has joined #ruby
[20:37:05] havenwood: marz_d`ghostman: Here's an example of a similar setup, with digest-sip_hash and Digest::SipHash: https://github.com/havenwood/digest-sip_hash
[20:38:14] havenwood: marz_d`ghostman: In your case, it should be: /lib/mygem/my_util/my_util.rb
[20:38:21] havenwood: marz_d`ghostman: Mygem::MyUtil
[20:39:01] marz_d`ghostman: havenwood: https://gist.github.com/marzdgzmn/ea44b8473fe3f1a7ef0e6bb9760f0882
[20:39:06] havenwood: marz_d`ghostman: It's expected that there'l be a /lib/mygem/my_util/my_util.rb file.
[20:39:21] marz_d`ghostman: It's giving me the error: uninitialized constant Rise::MirrorManager::Sync
[20:40:43] marz_d`ghostman: Tried adding require 'rise/mirror_manager', didn't help though
[20:41:33] havenwood: marz_d`ghostman: your dir structure looks good for: /lib/rise/mirror_manager/
[20:41:53] havenwood: marz_d`ghostman: And it properly then has a:L /lib/rise/mirror_manager.rb
[20:42:13] havenwood: marz_d`ghostman: Why is sync.rb in a sync/ dir?
[20:42:32] havenwood: marz_d`ghostman: I'd expect that not to be nested.
[20:42:50] s2013: has joined #ruby
[20:43:02] havenwood: marz_d`ghostman: /lib/rise/mirror_manager/sync.rb should correspond with Rise::MirrorManager::Sync
[20:43:18] marz_d`ghostman: havenwood: I'm assuming I'll be creating another class for sync purposes or a module perhaps. To organize it, I'll just have all sync related files inside the sync/ dir
[20:44:14] havenwood: marz_d`ghostman: Just like you have /rise/mirror_manager.rb and /rise/mirror_manager/, you'd have /rise/mirror_manager/sync.rb and /rise/mirror_manager/sync/*
[20:44:32] havenwood: marz_d`ghostman: But sync.rb doesn't belong in the sync/ dir, like mirror_manager.rb doesn't belong in the mirror_manager/ dir
[20:44:55] havenwood: marz_d`ghostman: sync.rb and sync/ should both be in /mirror_manager
[20:46:14] havenwood: if you had a sync/brink.rb, it'd be Rise::MirrorManager::Sync::Brink - for example
[20:47:56] marz_d`ghostman_: has joined #ruby
[20:48:04] marz_d`ghostman_: havenwood: I see, so sync.rb should be under mirror_manager
[20:48:53] marz_d`ghostman_: havenwood: moved it, still having the erorr though
[20:49:40] marz_d`ghostman_: https://gist.github.com/marzdgzmn/ea44b8473fe3f1a7ef0e6bb9760f0882
[20:50:20] havenwood: marz_d`ghostman_: In /lib/rise/mirror_manager.rb do you?: require 'mirror_manager/sync'
[20:50:22] elphe: has joined #ruby
[20:50:51] marz_d`ghostman_: havenwood: Oh, so I still have to. Then I'll require rise/mirror_manager on spec-helper
[20:51:56] marz_d`ghostman_: havenwood: Okay, did that, still now working
[20:52:22] havenwood: marz_d`ghostman_: Show the code?
[20:54:00] marz_d`ghostman_: havenwood: https://gist.github.com/marzdgzmn/ea44b8473fe3f1a7ef0e6bb9760f0882
[20:54:33] marz_d`ghostman_: I have a require 'rise/mirror_manager' at the top of spec_helper.rb as well
[20:57:53] thy0: has joined #ruby
[20:59:42] havenwood: marz_d`ghostman_: Does sync_spec.rb require the spec_helper.rb?
[21:00:40] havenwood: marz_d`ghostman_: If the repo is public, it'd be way easier to look at the real code. If not, we could probably tell what the issue is with the requires from the relevant files.
[21:00:41] marz_d`ghostman_: havenwood: It does not
[21:00:55] havenwood: marz_d`ghostman_: The specs will probably each need to require the helper.
[21:01:05] marz_d`ghostman_: havenwood: How do I do that?
[21:02:20] havenwood: marz_d`ghostman_: With your current directory layout: require_relative '../../spec_helper'
[21:03:39] marz_d`ghostman_: havenwood: Haven't seen anything like that before though
[21:04:15] havenwood: marz_d`ghostman_: for example: https://github.com/pry/pry/blob/master/spec/sticky_locals_spec.rb#L1
[21:04:34] havenwood: marz_d`ghostman_: If you look around you'll see that test helpers are there to be required by the tests.
[21:05:02] havenwood: marz_d`ghostman_: or: https://github.com/havenwood/digest-sip_hash/blob/master/spec/runner.rb#L3
[21:05:20] havenwood: marz_d`ghostman_: I can link you to dozens of examples. But all it is is requiring the helper from your tests.
[21:06:09] dviola: has joined #ruby
[21:06:15] havenwood: marz_d`ghostman_: The other way is to setup LOAD_PATH and use require instead of require_relative.
[21:07:37] marz_d`ghostman_: havenwood: This one doesn't https://github.com/marzdgzmn/marz-rsync
[21:07:56] havenwood: marz_d`ghostman_: yes, it does: https://github.com/marzdgzmn/marz-rsync/blob/master/test/marz/rsync_test.rb#L1
[21:08:39] marz_d`ghostman_: havenwood: not the test, the specs
[21:09:27] havenwood: marz_d`ghostman_: They've setup RSpec to do that: https://github.com/marzdgzmn/marz-rsync/blob/a9f0d07cfd023bf45d3ae1760ce70760f6045688/.rspec#L3
[21:09:28] marz_d`ghostman_: havenwood: I mean minitest and rspec looks on their corresponding dirs right?
[21:09:36] havenwood: marz_d`ghostman_: You have to require it, one way or the other.
[21:10:15] leitz: Hey havenwood, in your copious free time (!), can you look at: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L83-L87
[21:10:41] havenwood: marz_d`ghostman_: If you'd like to use the .rspec file to automagically require rather than require_relative, you can totally do that. It's less explicit.
[21:10:54] leitz: I haven't figured out how to use the careers in the module refactor.
[21:11:43] marz_d`ghostman_: havenwood: I tried adding a .rspec file still not working though
[21:12:09] leitz: havenwood, a sample career. https://github.com/makhidkarun/ftl_chargen/blob/master/lib/ftl_chargen/careers/navy.rb
[21:12:10] cschneid_: has joined #ruby
[21:12:25] havenwood: marz_d`ghostman_: I'd suggest explicit require_relative or carefully read RSpec's .rspec file docs.
[21:12:38] marz_d`ghostman_: havenwood: Okay, I'll give it a try thanks
[21:12:42] havenwood: marz_d`ghostman_: np
[21:13:26] havenwood: leitz: So you want to programatically iterate through eh classes that inherit from Career?
[21:13:33] leitz: ACTION thinks if havenwood's help was paid for in libations the poor guy would be drunk for years...
[21:13:52] havenwood: ACTION hiccups
[21:14:05] leitz: havenwood, just one class. The program is called with "bin/chargen -c Navy"
[21:14:47] nfk: has joined #ruby
[21:14:49] s2013: has joined #ruby
[21:15:01] havenwood: leitz: What goes wrong when you run ^ that?
[21:15:09] leitz: Though the career names are put in a list to check. So "bin/chargen -c PoorCoder" would default to a career based on the social standing (:soc) since there is no PoorCoder class.
[21:15:41] havenwood: leitz: Wouldn't capitalizing mess up PoorCoder?: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L84
[21:15:48] leitz: havenwood, it ignores the -c option. Lemme run it real quick and gist it.
[21:15:56] havenwood: >> 'PoorCoder'.capitalize
[21:16:02] ruby[bot]: havenwood: I'm terribly sorry, I could not evaluate your code because of an error: NoMethodError:undefined method `[]' for nil:NilClass
[21:16:02] leitz: PooCoder....yeah, see where there's no class? :P
[21:16:46] havenwood: leitz: reading the surrounding code for context, sec
[21:17:41] leitz: havenwood, example: https://gist.github.com/LeamHall/c3ba5c7aaf16b6417130855aee644e2c
[21:18:14] havenwood: leitz: It looks like you're not adding careers to the options['careers'] when parsing options.
[21:18:37] havenwood: Oh, you're setting 0, hrm. What's that about?
[21:19:03] leitz: havenwood, correct. This broke when I moved things to FTLChargen module. Lemme go find the old code.
[21:19:41] havenwood: leitz: Why the 0 here?: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L42
[21:20:47] havenwood: Oh, you're using that as a kinda meta-data toggle?
[21:20:53] leitz: havenwood, Number of terms in that career.
[21:21:09] leitz: Each term ages the character 4 years, but background careers don't.
[21:21:38] leitz: havenwood, so a -t 5 means 20 years in that career.
[21:22:14] havenwood: leitz: So what's an example of it not working?
[21:22:38] leitz: havenwood, the careers hash might be {'Navy' => 2, 'Citizen' => 1 }
[21:22:49] havenwood: leitz: Oh, you gisted it
[21:23:29] leitz: ACTION backspaces...
[21:24:12] leitz: havenwood, on Line 2 of the gist, "Citizen' is the career, based on Soc.
[21:24:35] havenwood: leitz: Here you probably want to do something more like Rail's #underscore: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L83
[21:25:21] havenwood: leitz: #downcase would only work for constants with a Single capital
[21:25:40] havenwood: leitz: Same problem with #capitalize here: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L84
[21:25:45] leitz: Not familiar with Rails. The careers are in a separate directory to allow the Array to be built from going over the names.
[21:26:05] marz_d`ghostman_: havenwood: got it working now, so every class I make I should prefix with a module Rise module MirrorManager
[21:26:14] havenwood: leitz: You'd want to use something like Rail's #camelize for the latter.
[21:26:18] leitz: havenwood, yeah, hadn't thought of mixed case, so far they are all capitalized.
[21:26:19] havenwood: marz_d`ghostman_: nice, yup
[21:26:29] marz_d`ghostman_: havenwood: thanks for the help man
[21:26:36] havenwood: leitz: Or #constantize.
[21:26:41] havenwood: marz_d`ghostman_: you're welcome
[21:27:28] havenwood: leitz: You probably shouldn't dynamically require like this, if you can avoid it.
[21:27:40] havenwood: leitz: This line should handle the requires: https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L10
[21:28:14] havenwood: leitz: lib/ftl_chargen.rb should require the careers, etc.
[21:28:24] leitz: havenwood, the idea was to allow others to write their own career files. Even have a document for it. :)
[21:28:46] havenwood: leitz: You can require everything in that directory in: ftl_chargen.rb
[21:29:29] leitz: havenwood, can you do it without specifying? That was a design goal, "just plop a career in".
[21:29:52] havenwood: leitz: Yes, in ftl_chargen.rb you can dynamically require each .rb file in that dir.
[21:30:23] havenwood: leitz: Sec, I can find a good example.
[21:30:30] leitz: ACTION goes to google
[21:30:50] leitz: havenwood, this? Dir["/path/to/directory/*.rb"].each {|file| require file }
[21:31:10] apeiros: .glob(path) { |file|
[21:31:13] apeiros: saves you a method call.
[21:31:20] elphe: has joined #ruby
[21:31:23] havenwood: leitz: apeiros' version I ^ is better
[21:31:29] apeiros: ACTION prefers explicit requires, though
[21:31:51] leitz: Should I require all careers even if only one will be used for a program run?
[21:32:19] havenwood: leitz: Probably.
[21:32:40] alem0lars: has joined #ruby
[21:32:51] leitz: ACTION goes to code for a minute.
[21:40:12] leitz: havenwood, apeiros, added the Dir.glob on line 12. Line 88 is giving an uninitialized constant since the constant now has the module prefix. https://github.com/makhidkarun/ftl_chargen/blob/career_refactor/bin/chargen#L88
[21:40:55] leitz: The module prefix is the issue I'm hitting. In the gist, "FTLChargen::Navy" wasn't found in the career array so the Soc was used to make a Citizen.
[21:41:18] apeiros: Dir.glob('../lib/ftl_chargen/careers') should be Dir.glob('ftl_chargen/careers', dir: "../lib")
[21:41:33] apeiros: curious you don't get an exception there
[21:43:20] apeiros: and yes, you do const_get on the module which contains the constant you want
[21:43:35] apeiros: which is almost never Module btw., toplevel is Object.
[21:45:30] apeiros: btw., don't call srand
[21:46:26] LiftLeft: has joined #ruby
[21:47:26] leitz: apeiros, this "Dir.glob('ftl_chargen/careers', dir: "../lib") {|file| require file }" gives "in `glob': unknown keyword: dir (ArgumentError)"
[21:47:29] s2013: has joined #ruby
[21:47:34] leitz: Why not use srand?
[21:49:24] leitz: apeiros, on the "const_get", it used to work before moving everything to the module.
[21:49:47] apeiros: leitz: don't call srand because ruby does that on its own already
[21:49:54] apeiros: sorry, base:, not dir: in glob
[21:50:10] apeiros: and const_get worked coincidentally, not because it was correct :-p
[21:50:47] leitz: apeiros, okay, base works. And I'm a pragmatic guy; "works" is "correct". :)
[21:50:53] apeiros: but I see now that you construct the full constant name. Object.const_get("Full::Constant::Path") will work, if it doesn't, it means you either haven't loaded the code which defines the constant yet, or you constructed the name wrong.
[21:51:31] apeiros: incorrect pragmatism a) will bite you, b) means that you'll not be able to grow, since growing requires a working foundation
[21:51:54] apeiros: (not be able is too harsh - but it'll certainly limit)
[21:52:14] leitz: Harsh is okay, given the amount of help you're providing. :)
[21:52:47] cschneid_: has joined #ruby
[21:58:11] leitz: apeiros, I'm missing how to format the Object.const_get. Tired to remove each section and it still errors. https://github.com/makhidkarun/ftl_chargen/blob/career_refactor/bin/chargen#L87-L91
[21:58:29] leitz: uninitialized constant FTLChargen::Careers (NameError)
[21:59:03] apeiros: well, do you require the file where that constant is defined?
[21:59:42] leitz: Line 13 should have it. https://github.com/makhidkarun/ftl_chargen/blob/career_refactor/bin/chargen#L13
[22:00:15] apeiros: you should probably test what `Dir.glob('../lib/ftl_chargen/careers')` and `Dir.glob('ftl_chargen/careers', base: "../lib")` return
[22:00:27] apeiros: (will be the same as what it yields, but easier to test)
[22:02:02] orbyt_: has joined #ruby
[22:02:36] leitz: Hmm...changing "require" to "puts" gives nothing. Poking it some more.
[22:03:39] apeiros: your glob expression is wrong
[22:03:56] apeiros: in your case, you'll probably want a **/*.rb at the end
[22:06:36] armyriad: has joined #ruby
[22:09:47] leitz: apeiros, Dir.glob("ftl_chargen/careers/*.rb", base: "lib/") {|file| require file }
[22:10:07] apeiros: and which file defines FTLChargen::Careers?
[22:10:48] apeiros: also an important note: having your requires relative to the working directory is a *terrible* idea.
[22:11:05] apeiros: at the very least make it relative to the currently executed file.
[22:12:06] leitz: At the moment I'm focused on the one issue. Even requiring the files doesn't resolve it.
[22:12:19] apeiros: 00:10 apeiros: and which file defines FTLChargen::Careers?
[22:12:39] Sembei: has joined #ruby
[22:14:42] leitz: Interesting, may have it. Not sure why.
[22:16:15] apeiros: weeeeell, if no file defines that constant, obviously you'll get NameError: uninitialized constant
[22:16:33] apeiros: from the name, which file *should* define it?
[22:16:55] leitz: Yup. so the solution is to remove "Careers" since it was never created as a module/namespace.
[22:17:13] apeiros: well, ok, *maybe*.
[22:17:24] hays: I am trying to simply scope a function to a module. what is the way to do this so that its seen within classes of that module
[22:17:26] kapil___: has joined #ruby
[22:17:27] apeiros: it may not be the right solution, though
[22:17:40] apeiros: hays: when you say "scope", what do you understand by that?
[22:17:41] hays: i tried self.fun and that doesn't seem to be in scope
[22:18:07] hays: i can call the function without any references to the module
[22:18:08] leitz: apeiros, it's the level I can understand at the moment.
[22:18:15] leitz: hays, you're in good hands!
[22:19:28] apeiros: leitz: you should still try to answer the question which file should define FTLChargen::Careers, because understanding that is quite crucial.
[22:19:41] hays: https://bpaste.net/show/87caccd1aafd
[22:19:58] apeiros: because the mapping between module/class constants and files *should* be 1:1
[22:20:13] baweaver: ACTION wanders in
[22:20:24] apeiros: hays: ruby doesn't do that at all.
[22:20:59] apeiros: hays: what you can do is define the myfoo method in a module and use `include ThatModule` in your class DEF, and then you can use myfoo in DEF.
[22:21:20] apeiros: but nesting namespaces are never considered for method lookup.
[22:21:25] apeiros: only inheritance.
[22:26:27] elphe: has joined #ruby
[22:29:18] leitz: Hey baweaver, your name was used in vain earlier.
[22:29:32] leitz: I think havenwood wandered off drunk.
[22:30:49] leitz: apeiros, i think the mapping is 1:1, but the Careers namespace is not defined.
[22:31:02] leitz: That is, each career establishes one Constant.
[22:31:33] apeiros: leitz: so then answer the question :) which file *should* define FTLChargen::Careers
[22:32:10] hays: hmm.. ok. i think i can live with that
[22:32:11] leitz: apeiros, and that goes back to the dynamic nature of the career files. On the off chance anyone else ever uses this, I wanted added a career to be easy.
[22:32:29] leitz: ACTION smiles since his tests also pass.
[22:32:53] apeiros: leitz: no. it does not go back to the dynamic nature. there is one clear file which should define FTLChargen::Careers. you can infer it directly from the constant name.
[22:34:43] graphene: has joined #ruby
[22:38:44] ellcs: has joined #ruby
[22:40:06] apeiros: leitz: with your naming style, the rule is simple: downcase and replace :: with /. so FTLChargen::Careers is ftlchargen/careers, so lib/ftlchargen/careers.rb
[22:40:53] apeiros: leitz: from that also follows that if you have lib/ftlchargen/careers/somejob.rb, then that should define FTLChargen::Careers::Somejob
[22:41:47] apeiros: sidenote though: FtlChargen::Careers --> ftl_chargen/careers.rb is nowadays the preferred style (stems from rails). simply because it allows the mapping to be bijective.
[22:44:38] leitz: apeiros, I think I see what you mean. However, there's another issue to fix that's related, it seems. I'm getting "circular requires" and want to fix that before doing any more requires.
[22:45:03] apeiros: circular requires are not an issue.
[22:45:35] leitz: They are killing the Travis tests.
[22:46:36] leitz: Can you see the results here? https://travis-ci.org/makhidkarun/ftl_chargen/builds/429097613
[22:47:30] leitz: hmm...should not call ftl_tools. Gimme a sex.
[22:47:40] apeiros: absolutely not :-p
[22:47:44] leitz: sec...ARGGGHHH!!!!
[22:48:00] apeiros: sorry leitz, I just don't find you that attractive ;-)
[22:50:21] leitz: Me neither.
[22:50:37] leitz: Of course, if havenwood is drunk enough...
[22:51:01] apeiros: shh, we don't talk about that incident.
[22:51:10] leitz: Which one?
[22:52:24] leitz: Okay, travis passes now. I would still like to get rid of the circular require because it's bad form.
[22:53:15] leitz: In theory (a big word), character_tools should not require anything. It should just be mixed in to Character.
[22:53:24] leitz: In practice...
[22:54:21] apeiros: na, somebody at travis needs a serious talking to.
[22:54:31] apeiros: that warning is bull.
[22:54:48] leitz: It comes up in rake, too.
[22:55:01] leitz: Sorry, my rake file just runs tests.
[22:56:02] apeiros: I guess I have to run my code with -w again, might come from there, not travis itself. it's still bull.
[22:57:09] leitz: I'm still chuckling at it being confused about assigned but unused variables. The assignment is the use.
[23:02:57] cschneid_: has joined #ruby
[23:03:20] leitz: Okay, I have some duplicate defs to clean up. While you're awake though. you're saying I should make lib/ftl_chargen/careers.rb do the mass require and put the careers into a Career namespace inside FTLChargen?
[23:07:07] Emmanuel_Chanel: has joined #ruby
[23:07:50] apeiros: in my old style, I'd require everything I need in every file. for the slight special case of careers/*.rb being dynamic, I'd do a glob require in careers.rb, yes.
[23:09:01] elphe: has joined #ruby
[23:10:07] leitz: So take the Dir.glob and put it there, and then just require ftl_chargen/careers?
[23:10:44] agent_white: has joined #ruby
[23:10:59] leitz: ACTION goes to break more stuff.
[23:12:28] apeiros: ACTION goes to rewrite Pawn#checkMove (in JS)
[23:13:12] baweaver: was about to say, apeiros
[23:13:17] baweaver: you're going down a dark path
[23:14:15] apeiros: pawn movement is actually unexpectedly complex. until I started this coding exercise with my wife, I never knew about "en passant" move of the pawn.
[23:14:39] graphene: has joined #ruby
[23:15:22] leitz: ACTION really needs to fix these circular requires.
[23:15:37] apeiros: aaah, heh, yes. javaScript. much camel.
[23:16:48] apeiros: quite honestly, this trips me up quite a bit. ruby_variables, javaScript and css-classes
[23:17:00] apeiros: oh, and of course #css_ids, just because…
[23:17:09] leitz: What's the best way to fix the direct directory reference? https://github.com/makhidkarun/ftl_chargen/blob/master/bin/chargen#L25-L32
[23:17:12] thy0: has joined #ruby
[23:17:37] apeiros: leitz: __dir__
[23:17:54] apeiros: that one is relative to the script file. though, don't use that in the executable.
[23:18:18] apeiros: while lib will usually stay together, bin & lib might not be put in the same dir during installation.
[23:18:19] leitz: I was using the load path.
[23:18:52] apeiros: ah, that's even better.
[23:19:43] leitz: ACTION goes back to breaking stuff.
[23:19:59] graphene: has joined #ruby
[23:23:59] cschneid_: has joined #ruby
[23:24:38] leitz: Okay, I'm done for the day. Thanks for the help apeiros! When havenwood sobers up, tell him thanks too.
[23:27:47] graphene: has joined #ruby
[23:30:31] white_lilies: has joined #ruby
[23:52:53] graphene: has joined #ruby
[23:59:16] s2013: has joined #ruby
[23:59:32] cschneid_: has joined #ruby