Activity Graph

Page 1 of 4 | Next »


[09:47:35] leftylink: I think I heard rumours of tracepoint being useful in that situation
[09:48:00] leftylink: or perhaps you could redefine the method to first print Kernel#caller then cacll the original method
[20:48:14] leftylink: hmm. I usually use the -d flag for that.


[07:54:03] leftylink: range cover does something I didn't think it would do on some old versions
[07:54:19] leftylink: &22> (1..20).cover?(2..3)
[07:54:25] leftylink: &22>> (1..20).cover?(2..3)
[07:54:32] leftylink: &23>> (1..20).cover?(2..3)
[07:54:36] leftylink: &24>> (1..20).cover?(2..3)
[07:54:54] leftylink: hmm, what *are* these things doing
[07:55:53] leftylink: that's 2.6 only lol
[07:56:05] leftylink: https://bugs.ruby-lang.org/issues/14473
[08:02:12] leftylink: been spoiled too much by new ruby versions...


[23:18:05] leftylink: notice now lines 23 and 31 were exactly the same
[23:18:21] leftylink: which implies that #in_journey? was doing exactly the same thing as #touch_out
[23:18:28] leftylink: which should seem weird.
[23:19:10] leftylink: because as the English description of those two functions went, they should not do the same thing
[23:20:34] leftylink: sure. but if you tap_in, then you are in a journey, right?
[23:21:27] leftylink: hmm. was the rspec idiom of `expect(subject) to be_x` explained in the bootcamp so far?
[23:21:43] leftylink: where `expect(subject).to be_x` calls `subject.x?`
[23:21:55] leftylink: in this case, `subject.in_journey?`
[23:24:33] leftylink: in that case, to the creators of the test I might suggest that it may be better to have the test explicitly say `expect(subject.in_journey?) to eq(true)` or something, instead of `expect(subject).to be_in_journey` . while I understand that they wanted to use the latter to be more... like English speech... it may not immediately be obvious that it is causing `subject.in_journey?` to be called
[23:26:53] leftylink: I guess it is explained in https://relishapp.com/rspec/rspec-expectations/v/3-8/docs/built-in-matchers/predicate-matchers
[23:27:02] leftylink: `For any predicate method, RSpec gives you a corresponding matcher. Simply prefix the
[23:27:05] leftylink: method with be_ and remove the question mark`
[23:28:48] leftylink: so that is the logic behind doing it with `be`. if the creators of the test say that the test must be written with `be_X` then it may be good to link that documentation
[23:30:39] leftylink: if in_journey? is false and you do `expect(subject).to be_in_journey`, then the test will certainly fail. cine it expects `in_journey?` to be true.
[23:31:36] leftylink: s/cine/since/
[23:37:54] leftylink: it seems to me that that is what https://relishapp.com/rspec/rspec-expectations/v/3-8/docs/built-in-matchers/predicate-matchers says. I don't have any particular insight to add here, just what that page says
[23:38:16] leftylink: I see that https://relishapp.com/rspec/rspec-expectations/docs/built-in-matchers mentions using `to` and `not_to`


[18:15:12] leftylink: &24>> end; p :okay; begin
[18:16:23] leftylink: if I wanted to get rid of the nil... maybe I'll use ||
[18:16:31] leftylink: &24>> end || :okay; begin


[15:09:25] leftylink: is it not the case that you are rotating the array?
[15:10:38] leftylink: then you are asking for a cycle.
[15:11:02] leftylink: its name is #cycle
[15:18:25] leftylink: there you go then
[15:18:27] leftylink: exactly what you wanted
[16:40:35] leftylink: ah, that's too bad. but it looks like the matter has been resolved
[19:00:40] leftylink: whhat is this correspondence principle
[19:17:01] leftylink: `return` exits the lexically enclosing function. perhaps I don't know you are interested in something like
[19:17:04] leftylink: &24>> def f(a); a.map { |x| return :actually_the_whole_thing_is_invalid if x == 7; x * 10 } end; p [f([1, 2, 3]), f([1, 4, 7, 10])]
[19:17:20] leftylink: maybe you just really don't like the number 7 for some reason
[19:19:35] leftylink: well, the `x * 10` demonstrates what happens if you don't use the `return` keywordc, doens't it?
[19:19:43] leftylink: &24>> def f(a); a.map { |x| x * 10 } end; p [f([1, 2, 3]), f([1, 4, 7, 10])]
[19:20:01] leftylink: in that case, you do not prematurely exit from `f`
[19:20:12] leftylink: so that is very different
[19:20:58] leftylink: where did 10 and 40 go in theh first example?
[19:20:59] leftylink: where is 100?
[19:21:26] leftylink: why is the result a symbol instead of an array?
[19:31:30] leftylink: note that if you do `return; puts :hello`, hello is not output. therefore, same with `p [1, 2, 3, 4, 5].detect {|number| return number.even?}` , you should not expect that anything was output.
[19:39:08] leftylink: it would be an exception in older versions because top-level return was not added until 2.4, right? https://bugs.ruby-lang.org/issues/4840
[20:49:11] leftylink: interesting. I had thought that for `a.each { |x| ... }` that during the block `x` would surely be defined. I guess I will belearning something new today when thhe reason is figured out.


[19:46:40] leftylink: but I thought that `a.map { ... }` always MUST have same number of elements as `a`. so wouldn't it have to be done after the map? for example, perhaps it can `compact`.
[19:48:10] leftylink: when `filter_map` comes out, then maybe that will be better.
[19:48:20] leftylink: but for now.
[20:41:37] leftylink: https://github.com/rubocop-hq/ruby-style-guide#no-and-or-or gives the example of why you would want to use &&
[20:41:44] leftylink: &>> ok = true and false; ok
[20:42:34] leftylink: &>> ok = false or true; ok


[20:54:37] leftylink: so. would it work if you just made them enter a string like '%<title>s' and then you just use % to format it?
[20:54:42] leftylink: &>> '%<title>s' % {title: :arghhh}
[20:54:50] leftylink: then no library is needed, just the default capabilities of the language
[20:54:53] leftylink: &>> '%<title>s' % {title: :arghhh}
[20:57:48] leftylink: if you're really set on not making them remember the exact format of %<title>s, maybe they think the angle brackets and the s are TOO BURDENSOME or something, then maybe you can just make them do <title> and you insert the % and s yourself
[21:02:23] leftylink: also in case you ever came across a suggestion `eval ?" + template + ?"`, I highly recommend against :) since someone will set `template = '"; puts :pwned; "'`
[21:03:34] leftylink: please see the documentation for String#%
[21:03:39] leftylink: &ri String#%
[21:08:53] leftylink: although it is surely the case that the snippet of code `'%<title>s' % {title: :arghhh}` was indeed using String#%, there is no question about that. so the logical place to start looking at documentation is String#%
[21:09:18] leftylink: if it is so the case that the documentation for String#% asks one to look at other documentation, so too should that documentation be looked at.
[21:21:28] leftylink: I can also add as a general point. sometimes it can be hard to tell whether a question would be a bother or not. it would be a shame if a person became too afraid to ask questions. but that is usually okay. people probably notice what I do. there are certain questions to which my answers take the form of "here are general rules that will help a person to know where to find the answer for oneself"
[21:22:21] leftylink: and it is that way because 1. (hopefully) it is helpful whether the asker was a vampire or not, and if they were a vampire I need to give that kind of answer for my own sake anyway. and 2. if I just tell them the answer they learn nothing
[21:23:12] leftylink: my general philosophy is nothing is magic though, so I hope to help allow people to see that it is not magic


[19:33:26] leftylink: RetroPunk: possible to check whether the right files are getting `require` d ? for example just adding a `puts __FILE__` at the bottom of each file? it would be disastrous if , for example, a stray `-I .` got into the command line flags and caused `bin/tracklist.rb` to require itself instead of `lib/tracklist.rb`...
[19:34:01] leftylink: actually, that's not even a reasonable suggestion for me to make
[19:34:21] leftylink: if bin/tracklist were requiring itself, it would be Tracklist that was undefined, not TrackParser
[19:34:27] leftylink: so my suggestion cannot be correct
[19:41:58] leftylink: with that exact directory structure, one certainly would expect that `ruby -I lib bin/tracklist` would work. so something tricky is going on
[19:44:26] leftylink: `ruby -I` doesn't really care what the gem is called
[19:45:04] leftylink: can someone tell me real quick what the style of art in matz's avatar is called? https://pbs.twimg.com/profile_images/511244255294001152/v5phEU1O.jpeg
[20:02:50] leftylink: bitmoji, that looks like that is te term I was looking for, thank you
[20:10:47] leftylink: maybe it is worth doing `puts $LOADED_FEATURES.grep(/tracklist/)` to see what exactly got `require`d, and see if that matches up w/ expectations
[20:18:58] leftylink: isn't tat inconsistent with the earlier statement tat putting a `puts` in tracklist.rb had no effect?
[20:30:28] leftylink: also TIL `$LOADED_FEATURES` for this express purpose
[20:34:04] leftylink: I thought you already said it yourself - you saw that `-I lib` worked. isn't that the way to go? it's not like Ruby is magic. It's not going to know where to `require` the files from unless explicitly told so
[20:38:07] leftylink: hmm. although maybe it is customary for `bin/` to prepend its own `lib` to the $LOAD_PATH ? I'm not sure what is the convention among gem authors
[20:38:56] leftylink: or maybe it's customary to require_relative ???
[20:39:31] leftylink: those are some options to explore. I cannot advise on wheter that would break some convention that gem authors adhere to, but they are options
[20:40:25] leftylink: eh, the require_relative is mostly unsatisfying since things directly required by `bin/whatever` will be affected, but if we assume that files in `lib` will continue to `require` instead of `require_relative`, then there will be no dice there
[20:43:28] leftylink: random internet person says gems can use require_relative for internals. https://medium.com/@ellishim/understanding-require-vs-require-relative-vs-require-all-80e3b26d89e6 . assuming this random internet stranger isn't completely unjustified, perhaps this is a possible avenue to explore
[20:48:33] leftylink: random internet person in https://www.reddit.com/r/ruby/comments/3341zm/require_best_practices/ preferred the LOAD_PATH way of doing things, and recommended not using require_relative. I wonder why.
[20:49:55] leftylink: aha excellent, they talk about it in https://www.reddit.com/r/ruby/comments/3341zm/require_best_practices/cqi0un7/ .
[20:53:05] leftylink: as I read it, jrochkind's most compelling argument is that if I need to split a gem into two, then suddenly I won't be able to use some of the `require_relative` anymore and will be forced to change them to `require`. that is a fair point, so should be evaluated against te probability of te gem ever having to split in two in the future


[23:32:33] leftylink: note that `what_team_have_win(c1, c2)` is just a 1-to-1 mapping of `c1 <=> c2` . consider if this may be useful.
[23:38:16] leftylink: also consider that lines 50-54 are exactly the same as lines 56-60, except for line 50 and 56 are different.
[23:40:27] leftylink: note that the guessed value of the loser's score is not important. this may lead to questions about whether it is appropriate to even ask for a loser's score as a param. perhaps it is wiser to instead simply take the guessed winner and guessed winning score.
[23:41:34] leftylink: .... okay, actually the actual value of the loser's score is also unimportant. so the same idea applies to those as well.
[23:42:12] leftylink: the loser, I said
[23:42:20] leftylink: of course the actual value is important for the winners.
[23:46:00] leftylink: unverified knee-jerk reaction: t2 and t1 need to be switched.
[23:46:29] leftylink: knee-jerk reaction is wrong
[23:46:41] leftylink: I got schooled
[23:48:21] leftylink: because of me forgetting the polarity of <=>. minus is a good mnemonic for remembering the polarity
[23:48:55] leftylink: and then I must to keep in mind that since team wins looks for the larger, not the smaller
[23:55:39] leftylink: well I was about to write some longer sentences about "some people may dislike `if A; LONG_CODE else return thing end` and prefer `return thing if !A; LONG_CODE` since then one can unindent LONG_CODE
[23:55:46] leftylink: but it looks like that has already been covered.
[23:59:34] leftylink: at some point, one might also consider whether to use a ternary. although I do admit it may make the structure of the code... a bit less balanced


[05:44:22] leftylink: I can't decide which word is better to use in that context, canon (part of the language => has been canonicalised) or cannon (referring to the classic contrast between technology and magic)
[06:05:07] leftylink: it could be really clever
[19:41:59] leftylink: that is interesting. I will note that `s = "abcdefg"; s[(s.index(?b) + 1)..-1]` will leave every character after a `b`. then it would be possible to iterate on that process
[19:42:02] leftylink: &>> s = "abcdefg"; s[(s.index(?b) + 1)..-1]
[19:42:31] leftylink: or, perhaps there can be something clever done with splitting on all periods and doing Array#join with increasingly smaller subarrays
[19:54:31] leftylink: since the `p` isn't being used at all in the gist, one would rather just use .with_index there
[19:54:38] leftylink: if we talk about golf


[20:39:35] leftylink: https://github.com/fxn/i-told-you-it-was-private


[23:31:40] leftylink: I guess they just had to make a decision. in the expression `f y { :hello }`, does f get the block, or does y? and it so turns out that it is y
[23:31:50] leftylink: &>> def y; yield end; def f a; a end; f y { :hello }
[23:32:00] leftylink: a decision had to be made one way or the other


[01:04:42] leftylink: then, once an exception has been rescued, one is able to refer to it using tne name `e`
[01:04:48] leftylink: &>> begin 1/0; rescue Exception => e; puts "hello. #{e.class} - #{e.message}" end


[20:56:59] leftylink: I see that https://github.com/rubygems-trust hasn't updated their copyies of the respective repos in more than 6 years. perhaps that means the efforts (if still existing) moved elsewhere


[10:45:09] leftylink: q: can I make my struct's `new` take kwargs instead... a: turns out I can, in 2.5 and later (`keyword_init: true` to Struct.new)
[11:35:21] leftylink: yeah dunno what anyone could expect from that. there's stilly stuff like [(a if b), (c if d), (e if f)].join.html_safe (don't even need to `compact`!) but I see no advantage provided by this
[11:36:14] leftylink: or there's "{a if b}{c if d}{e if f}".html_safe but I don't like how that looks on multiple lines
[11:36:32] leftylink: the list at least looks decent on multiple lines, one line per element
[15:43:10] leftylink: probably somewhere in syntax
[17:10:33] leftylink: if there was ay doubt about the name of yield_with_arguments, note that it is indeed because there are args being given to `yield`
[17:13:39] leftylink: that's how the person who wrote the code decided it should be
[17:14:48] leftylink: but args being given to a function don't necessarily have any relation with args being given to a block
[17:16:24] leftylink: that is true
[17:17:36] leftylink: it is not syntactically possible to pass more than one block. however one might consider passing multiple procs or lambdas as regular arguments
[17:20:00] leftylink: &>> def f(a, b) a[]; b[]; yield end; f(-> { puts :foo }, -> { puts :bar }) { puts :baz }
[17:21:54] leftylink: but didn't you just mention &block ? because of &block, I don't think it's true that `yield` is the only way to access a block
[17:22:23] leftylink: &>> def f(&b) b[] end; f { puts :foo }
[17:22:45] leftylink: then you shoudl try it.
[17:24:00] leftylink: because why should I let others tell me what is possible and what is not?
[17:25:53] leftylink: I should let the language tell me and see it with my own eyes
[17:32:35] leftylink: def f(a) yield end; f(p) { puts :hello }
[17:32:39] leftylink: &>> def f(a) yield end; f(p) { puts :hello }
[17:33:12] leftylink: f took an arg, did absolutely nothing with it, and called the block
[18:16:42] leftylink: in situations like this, it may be useful to know that ruby-doc.org has "click to toggle source". however, some results may be dsappointing as many of them may be implemented in C.
[18:16:52] leftylink: &ri Array#each


[01:39:40] leftylink: ruby story without obvious use
[01:40:14] leftylink: I was once trying to debug who was calling String#+, so I made it print self and its arg. and of course I would test that in irb first
[01:40:21] leftylink: but doing it wrong will just crash irb
[01:40:35] leftylink: I meant to do `class String; def +(s); puts "adding #{self} and #{s}"; "#{self}#{s}"; end end`
[01:40:58] leftylink: but instead I did `class String; def +(s); puts "adding #{self} and #{s}"; "#{self}{s}"; end end` and irb just crashed immediately
[07:12:53] leftylink: one would hope I do not have to reach for such old versions of ruby, but if I wanted to know which version of ruby made Array#shift and Array#unshift amortised constant...
[07:13:11] leftylink: looks like it was 2.0. okay. I am pretty sure nobody will make me use a ruby that is older than that
[07:13:14] leftylink: or even close
[07:19:51] leftylink: very specifically shift and unshift
[07:19:54] leftylink: as https://stackoverflow.com/questions/8353026/what-is-the-run-time-of-shift-unshift-in-a-ruby-array/47683752#47683752 states
[19:15:39] leftylink: I think the question has to specify what its behaviour should be on inputs other than 'true' or 'false'. if the conversion can do whatever it wants on other inputs and only needs to convert 'true' and 'false' then I'd too easily suggest something like `s == 'true'` or `s[0] == ?t`


[02:59:29] leftylink: oh, can probably figure this out by redefining the operator
[03:04:27] leftylink: actually, don't even need to redefine
[03:04:32] leftylink: just doing it with strings is enough to see why it doesn't work
[03:04:51] leftylink: &>> a = ?a; b = ?b; a += b += a += b
[03:05:41] leftylink: that makes it obvious why the ^= chain didn't work and also the minimum change needed to make it work
[03:05:56] leftylink: &>> a = 3; b = 5; b ^= a ^= b; a ^= b; [a, b]
[09:18:38] leftylink: I guess if the hash doesn't have a name I'll also throw in `.tap { |h| h.delete(:a) }` as an option
[10:06:59] leftylink: non serious answer https://thedailywtf.com/articles/Divine-by-Zero


[03:43:30] leftylink: the first thing in a collection that matches a block? that would be Enumerable#find
[03:44:44] leftylink: please note carefully the instructions on how to use Array#sort! but also keep in mind that Array#sort_by is available
[03:44:49] leftylink: &ri Array#sort!
[03:49:59] leftylink: reversing a sort order is achieved by telling the sorting algorithm to always make the opposite decision. if the original sort order would have said A is smaller than B, instead the new sort order says B is smaller than A.
[03:53:43] leftylink: also note that for numbers, if a < b then certainly -b < -a
[03:54:06] leftylink: this fact may be taken advantage of with Array#sort_by .
[03:57:18] leftylink: since there is both a condition (implying Enumerable#select) and a transformation (implying Enumerable#map), then one would infer from that that two reasonable chocies are either to use select and map in either order, or to map to either a value or nil and then use Array#compact
[08:08:23] leftylink: woo hoo LENSES!!!
[08:08:29] leftylink: now *that* is a difficult search term to get results for
[08:08:46] leftylink: lenses ruby just gets you... well
[08:54:15] leftylink: trace is pretty wild


[06:49:08] leftylink: interesting. well we can start by saying a range is written `a..b`
[06:50:38] leftylink: but I'm not sure what should be done with the other numbers. perhaps they should all be in an array? then one may be able to splat the range in as an element of the array, or simply construct the arrays piecemeal and concatenate them like any other arrays
[06:52:38] leftylink: if it can be written as a:b then that will be teaching me something new. note that `a: b` would usually be a key/value pair in a ruby hash
[06:54:59] leftylink: well I don't want to discourage others from taking an opportunity to teach me something new


[15:19:11] leftylink: hey, for all I know, everyone here except me is from stripe
[15:19:14] leftylink: so maybe it works out
[15:19:22] leftylink: s/is/could have been/
[15:20:02] leftylink: it could have just been an unspoken rule but everyone agreed not to talk about it


[20:02:39] leftylink: surely they would have added transform_values before transform_keys
[20:03:13] leftylink: transform_values is more aplpicable and requires less care than transform_keys (for the latter, one has to think about what happens if you map two former keys to the same new key)
[20:49:54] leftylink: https://github.com/search?q=language%3Aruby
[20:51:44] leftylink: counterexample, https://github.com/rails/rails is certainly written in ruby and was certainly updated more recently than september 27
[21:01:01] leftylink: out of curiosity I also looked at rubinius. then I saw its readme says it doesn't supprot refinements. guess I can't use it then, DOH


[10:17:45] leftylink: I found https://stackoverflow.com/questions/9211813/is-there-a-way-to-access-method-arguments-in-ruby , shrug
[10:18:28] leftylink: there's also **args but then there is no longer the way to make some required and/or error if an extra one is passed... unless maybe you make index_data_validator do that
[10:19:21] leftylink: wasn't ready to hit enter on that
[10:20:41] leftylink: &>> def g(a: 5, b:) a.is_a?(Integer) end; def f(**a) g(**a) ? a : :no end; f
[10:20:47] leftylink: &>> def g(a: 5, b:) a.is_a?(Integer) end; def f(**a) g(**a) ? a : :no end; f(b: :yes)
[10:21:57] leftylink: will need to merge the default values back in somehow too, that is too bad
[22:14:32] leftylink: ah, too bad, it was set up to be a good "what do you call a fish without an eye" joke
[22:14:36] leftylink: except s/fish/lisp/
[23:01:32] leftylink: morenoh11: run it on %w(a s d f)


[11:21:18] leftylink: `foo.whatever` acts on whatever `foo` returned. whereas `foo { some_block }` gives a block to `foo`, which `foo` might or might not choose to `yield` things to. expecting `whatever` to be able to affect `some_block` before `foo` can `yield` to it seems to imply time travel
[11:23:49] leftylink: if it must be a one-liner (well, I'm not going to judge, maybe there is a code golf contest going on, or maybe the widescreen monitor is broken and there's just 1 very very long line and you wouldn't be able to see the program if it was on two lines)
[11:24:01] leftylink: then I guess you can do some shit with ||=
[11:25:26] leftylink: &>> def foo; (1..5).each { |i| yield i } end; foo { |i| @argh ||= [] << i }; @argh
[11:26:00] leftylink: we'll ignore the fact that you would get yelled at if you actually wrote that code in a code review
[11:26:15] leftylink: excuse my bad language
[11:27:29] leftylink: the thought of the code I was about to write to demonstrate got me putting too low effort into my words
[11:31:08] leftylink: ... also I forgot parentheses
[11:31:17] leftylink: &>> def foo; (1..5).each { |i| yield i } end; foo { |i| (@argh ||= []) << i }; @argh
[11:35:47] leftylink: may strike `.each`, `with_object` already accepts block
[11:38:46] leftylink: &ri Enumerator#new
[11:38:56] leftylink: &ri Enumerator::new
[11:39:00] leftylink: &ri Enumerator.new
[19:19:54] leftylink: is that Regexp.union ?


[21:26:38] leftylink: is the question just about using the keyword `raise` ? or is it about signalling to some static analysis sytem that a function might raise? (answer to second question will depend on exactly what static analysis system)
[21:30:31] leftylink: then doesn't that mean your question is in fact about the `raise` keyword?


[11:26:29] leftylink: &>> print 1, 2, 3
[11:26:51] leftylink: &>> print 1, " ", 2
[11:26:53] leftylink: that's all it's doing


[08:28:03] leftylink: :var is a symbol literal. its only possible value is :var. var is a variable. its value depends on what is bound to var in the relevant context
[08:29:41] leftylink: &>> var = 'it is possible to assign values to variables'
[08:29:51] leftylink: &>> :var = 'it is not possible to assign values to symbols'


[16:15:43] leftylink: indeed they take on the same form at the call site. as a logical consequence of this, it also means that at the call site, even `:sym => v` is substitutable for `sym: v`
[16:15:53] leftylink: &>> def f(a: :adef, b: :bdef) p [a, b] end; f(:a => :world, :b => :world)
[16:17:12] leftylink: keys to hashes can be whatever you want. {5 => 1, ?a => 2} is a hash with a number and a string as keys
[16:42:52] leftylink: 16:24:16 < Norrin> I&>> def test
[16:43:07] leftylink: as is reasonable, it would only respond if &>> is the firs tthing. it would not work if there is an I before the &
[16:44:38] leftylink: of course that is no different than if it had been 22 => "a string"
[16:48:10] leftylink: the "as long as" does not apply
[16:48:21] leftylink: actually, I guess kind of
[16:49:44] leftylink: it really does not matter what syntax was used at the call site, as can be seen in the `def f(a: :adef, b: :bdef) p [a, b] end; f(:a => :hello, :b => :world)` example.


[11:18:46] leftylink: IIRC, and from what I see on http://sinatrarb.com/ , require 'sinatra' runs a sinatra app w/ any `get` (and others) that are called on the top level. there are zero such calls, therefore the sinatra app knows no routes and therefore "doesn't know this ditty". it is true that there is an application `crew` that got created, but that `crew` isn't doing anything. that CrewGen is a
[11:18:51] leftylink: https://www.rubydoc.info/gems/sinatra#Sinatra__Base_-_Middleware__Libraries__and_Modular_Apps , and reading that corresponding section will be helpful


[03:39:01] leftylink: which is pretty unintuitive if you think about it
[12:37:04] leftylink: ah so 2.6.0 and 2.6.1. good knowledge of relevant ruby issues, thank you
[12:45:38] leftylink: by the rules of https://docs.ruby-lang.org/en/trunk/syntax/methods_rdoc.html , "When mixing keyword arguments and positional arguments, all positional arguments must appear before any keyword arguments."