00:03 <o0x1eef> Hm it looks like Ruby is setup to handle signals exclusively on the main thread as well. Not gonna lie I think that makes life easier.

06:15 <kjetilho> ehh. now I actually tested my suggestion, and IO.select will resume the select in the same way as kernel.sleep :-(

06:17 <kjetilho> o0x1eef: I sort of agree - the libc interface is that both sleep() and select() return the remaining time if it was interrupted, but that information is not available in Ruby - you have to time it yourself.

06:19 <kjetilho> and as you demonstrated, you have to handle the exception rather than install a signal handler.

07:33 <o0x1eef> Good morning :D

07:39 <o0x1eef> My two cents: the purpose of IO.select is not to sleep. The purpose of IO.select is determine the state of a given set of IO objects over a period of time. Like any system call that can block, it can interrupted with EINTR. But it is not really designed to put a thread to sleep IMO. For that we have a specific system call: sleep, nanosleep, etc.

07:48 <kjetilho> yes, but select is traditionally used in an event loop, and then it makes sense for it to return on signals, too. of course a single-threaded event loop is old-fashioned today, but it surprises me that the IO.select primitive doesn't support this use case

07:52 <o0x1eef> It returns an array of arrays (the IO objects) or potentially nil if none matched, because that's what it is usually used for. Otherwise it would have to return some type of object that represented all of that info, and for a use-case that seems niche and with alternatives, that seems overkill

08:18 <kjetilho> "usually"? that's your opinion. having access to the timing information without explicit gettimeofday is very useful.

08:20 <o0x1eef> It's my opinion, sure but also more or less how Ruby core usually works. It rarely returns "rich" objects. It returns basic objects.

08:21 <o0x1eef> At best it might return a hash

08:21 <kjetilho> it wouldn't be so strange if a function which takes 4 arguments also returned 4 values - like the underlying API does

08:22 <kjetilho> anyway. it won't change :)

08:23 <o0x1eef> Agreed. And I agree again, a fourth value could be a nice simple way to do it.

17:06 <havenwood> <3 keyword arguments. This type of `thingy(nil, nil, nil, 3.14)` is exactly what makes me want backporting `thingy(seconds: 3.14)` to historic methods.

18:45 <o0x1eef> Generally agree. But as a rule of thumb I never mix them with positional args. IME that's when things can get weird.

18:49 <johnjaye> o0x1eef: i'm always torn as to whether i should learn more of perl, python, or ruby

18:49 <johnjaye> everytime i think i should learn one i think but what if i could learn more with the other one

18:49 <johnjaye> ruby is so elegant it's hard to quit though

18:52 <o0x1eef> IME it is hard to learn multiple languages at the same time. But you could do something like: 3 months of ruby, 3 months of python, 3 months of perl. Then when you have a foundation, it's easier to switch between them, and learn multiple at the same time.

18:52 <johnjaye> that's a very wise answer.

19:03 <o0x1eef> At the moment I want to learn Rust

19:04 <johnjaye> someone told me the rustlings github is useful for that.

19:04 <johnjaye> (this person claimed to be a rust programmer)

19:15 <o0x1eef> Good to know! I have no shortage of books on the topic :D I just lack discipline. It's easier to pick up Ruby or JavaScript when you know them reasonably well, versus pick up a language you barely know at all.

19:28 <o0x1eef> It's also cool to learn about the idioms of other languages. Even though Python + Ruby are similar, the Python mindset is different, and it can interesting to explore and then apply the good ideas. Similar for JavaScript, etc. I definitely suggest keeping your mind open to multiple languages.

23:00 <nakilon> I wish there were nested methods in an object

23:00 <nakilon> i.e. my_object.some_methods.method1()

23:10 <nakilon> if I do my_object.class.Some_methods_module.method1(), it won't know my object attributes

23:20 <nakilon> maybe I can do something like... def some_methods ; self.class.Some_methods.public_methods(false).map{ |m| m.curry[self] } ; end