I was going to fork this kata and update the description to one which makes the author's intent the only valid interpretation, but I can't think of how to do so without taking away the "puzzle" aspect of the kata.

I agree that the description is definitely vague and requires a lot of "guess what the author was thinking", which really isn't great. There are many other possible solutions (such as your suggested three-fold technique), and they can produce valid arrangements which use fewer hooks. A curtain with length 240 and hooks spaced apart at most 80 units would require 5 hooks according to the author, but your technique only uses 4 while satisfying the constraints, for example.

This is a terrible problem statement to inflict on beginners. We're told not to use any kind of measurement, but we're not given any indication of what moves we are allowed to use. The author just assumes that their solution is canonical and that anyone can be expected to reach the same conclusion. Personally, I would hold one end of the curtain in my left hand, loop it around some fingers of my right hand, then back around the fingers of my left, then grasp the other end in my right hand, and pull them taut so that the curtain is exactly tripled over. In principle, this procedure could be repeated until the folded length is small enough. But that's not the intended solution, so it's "wrong".

Since the requested changes are already incorporated in the current Python version I will reject this fork.

Awesome kata! Although I think that the code size constraint should be more tight.

Could you:

• Remove the comments from the top of the sample tests
• Update to use the new python test framework for 3.8 (with describe/it blocks)

Then I will approve

works perfect. Now I'll have to compct my ouput... xo

Ooh, I get it. The runBFBF function creates and runs each output*.bf in one fell swoop, so you never get a chance to see it if everything crashes.

I split up that function in the Preload and changed the "few selected bytes" section of the Sample Tests to read

  Test.it("Works for a few selected bytes", function () {
      runBFToOutput(0)
      console.log('0: ' + String.fromCharCode(...execSync("cat /workspace/output0.bf")))
      runBFToOutput(1)
      console.log('1: ' + String.fromCharCode(...execSync("cat /workspace/output1.bf")))
      runBFToOutput(12)
      console.log('12: ' + String.fromCharCode(...execSync("cat /workspace/output12.bf")))
      runBFToOutput(123)
      console.log('123: ' + String.fromCharCode(...execSync("cat /workspace/output123.bf")))
      runBFToOutput(255)
      console.log('255: ' + String.fromCharCode(...execSync("cat /workspace/output255.bf")))
      Test.assertEquals(runBFOutput(0), 0)
      Test.assertEquals(runBFOutput(1), 1)
      Test.assertEquals(runBFOutput(12), 12)
      Test.assertEquals(runBFOutput(123), 123)
      Test.assertEquals(runBFOutput(255), 255)
  });

This allows the player at least to see the output code before the crash.

I've republished the kata with the changes. Due to issue #144/#106, you may not see the updated Sample Tests until you resubmit a solution, but the issue should be resolved for new players.

• first point: mmmh... Might be I messed up somehting else, yes. Forget that part.
• second point: no, what I mean is that nothing is shown at all, if the output code is an invalid BF program. So the user doesn't get any feedback t all, in that case.Here is what the user can get:

     Your Metanumerics program
    Works for a few selected bytes
    Test Passed: Value == 0
    Log
    .
    
    Error: Command failed: bf -c29999 /workspace/solution.txt > /workspace/output1.bf
    Error: Out of range! Youwanted to '<' below the first cell.
    To solve, add some '>'s at the beginning, for example.
    
        at checkExecSyncError
        at execSync
        at runBFBF
        at /home/codewarrior/test.js:14:25
        at begin
        at Object.it
        at /home/codewarrior/test.js:11:8
        at /runner/frameworks/javascript/cw-2.js:152:11
        at Promise._execute
        at Promise._resolveFromExecutor
        at new Promise
        at Object.describe
    
    Completed in 48ms

So nothing useful at this step. To see what the actual output code is before it's executed by the interpreter sounds like a minimum to provide to the user (like, I totally messed up my first program and didn't have the least idea I was outputting non command characters).

This kata does use the usual bf interpreter, and the comment-loop trick is working for me. Can you give me a specific example of code that causes the incorrect behavior?

To your second point, the example test cases do console.log the program's output code in the "few selected bytes" section. You can see them by clicking the triangle for that section in the Output pane. If you want to see other outputs, you can see how to modify the test cases even without knowledge of Javascript.

hi,

• it seems you do not use the usual BF interpreter: I constently got errors because of bf commands that weren't supposed to be executed (in a loop used to put comments at the beginning of the code). That's pretty confusing, while the code was actually running well in my usual environnement (And it worked on cw after I removed that loop/comment)
• the current setup is pretty undebugable: you should print the code produced by the user before executing it. Currently, it's totaly impossible to solve the kata only on cw.

hi,

Is that normal that the ref solution along with the random string generation take more than 10s on their own, in python? How much of this is taken by the random generator?

When I try to edit it, it runs into the issue

https://github.com/Codewars/codewars.com/issues/1134

So I tried forking it here:

https://www.codewars.com/kumite/5b8957fc979532035500010c?sel=5bd486507645b91db500003f

It appears to be awaiting approval.

No worries! I'll be around whenever you get the chance, just let me know!

Hi. I'm afraid it will take longer than expected, because my computer died :(
Sorry for the delay...