Ad
  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Yeah. No clue why they decided to approve this kata...

  • Custom User Avatar

    Ah, the kata you linked is (marginally) newer than this one--it didn't exist when I created this one. Indeed, probably makes more sense to go with that one instead.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    I removed the triple-spaces from it (replacing them with double-spaces). Try again, hopefully the new testcases kick in automagically.

  • Custom User Avatar

    Oh, huh. That didn't show up for me when I searched for "morse" before writing this up... odd.
    Yeah, they do look quite similar, but as you pointed out this one is slightly simpler with the requirements, so in the end I think we can keep both. I guess this should be given a lower level and Morse Encoding a higher one, to reflect the difference in difficulty.

  • Custom User Avatar

    Hm. I was about to edit the description but on second thought it's probably better to modify the test instead in order to keep the kata focused on Morse rather than messing with whitespace. I removed the triple-spaces from the test case.

  • Custom User Avatar

    Voting clever, because it is. Definitely not best practice: spec-wise, the order of keys in an object is undefined, so it's only by chance that V8's Object.keys happens to return the keys in order of definition. I love the hack, just want to point that out so that people don't rely on this for "actual" code.

  • Custom User Avatar

    There's supposed to be a device.encode defined (you cannot see the definition--it is a black box and it is your task to figure out how it works). It works for me as of today, at least; not sure why it'd be undefined for you. It might've gotten fixed since you tried the kata.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Not quite. You receive a message that you are supposed to transfer reliably to the other side by invoking the sendFunction. The trick is that sendFunction itself isn't reliable--you need to implement the reliability on top of it.
    You are supposed to come up with a (simple) "protocol", and implement an encoder in send and a decoder in recv, so that each message passed to send is received on the receiving end only once.
    Note that there might well be a test that tries to send multiple messages in a row using send, that all look exactly the same.