11 Matching Annotations
  1. Aug 2020
  2. Jul 2020
    1. These seem to be better reasons to support sub-nanosecond resolution. I think either storing picoseconds or storing sec fraction as 64-bit integer are better approaches than storing a rational. However, either change would be very invasive, and it seems unlikely to be worth the effort.
    1. VII, after the map block, consider arr.each_with_object([]) do |(converted_val, orig_val),uniques|...end.
    2. Creating and calling a default proc is a waste of time, and Cramming everything into one line using tortured constructs doesn't make the code more efficient--it just makes the code harder to understand.

      The nature of this "answer" is a comment in response to another answer. But because of the limitations SO puts on comments (very short length, no multi-line code snippets), comment feature could not actually be used, so this user resorted to "abusing" answer feature to post their comment instead.

      See

  3. Jun 2020
  4. May 2020
    1. Not merge the values of the keys.

      This is one of the biggest limatations of <<: *anchor: it overwrites values of keys. It's too heavy-handed and therefore of limited use. You can only use it if you don't mind keys getting overwritten (such as if you are going to overwrite the keys below the <<:.).

  5. Jan 2020
    1. ssh doesn't let you specify a command precisely, as you have done, as a series of arguments to be passed to execvp on the remote host. Instead it concatenates all the arguments into a string and runs them through a remote shell. This stands out as a major design flaw in ssh in my opinion... it's a well-behaved unix tool in most ways, but when it comes time to specify a command it chose to use a single monolithic string instead of an argv, like it was designed for MSDOS or something!