Ad
  • Default User Avatar

    This looked to be fixed.

  • Custom User Avatar
  • Default User Avatar

    If you add random cases I can approve this.

  • Custom User Avatar
  • Custom User Avatar

    Kotlin Translation Kumited! Looking forward to your approval.

  • Custom User Avatar

    It seems like the swift translation may be broken. I get SIGILL for anything I enter.

  • Custom User Avatar

    It seems like the test/setup scripts are broken.. I'm seeing these errors (unrelated to my code):

    /workspace/setup.swift:6:13: error: use of unresolved identifier 'XCTAssertEqual'
                XCTAssertEqual(someInt, arr2[index] as! Int)
                ^~~~~~~~~~~~~~
    /workspace/setup.swift:8:13: error: use of unresolved identifier 'XCTAssertEqual'
                XCTAssertEqual(someIntArray, arr2[index] as! [Int])
                ^~~~~~~~~~~~~~
    /workspace/setup.swift:10:13: error: use of unresolved identifier 'XCTAssertEqual'
                XCTAssertEqual(someBool, arr2[index] as! Bool)
                ^~~~~~~~~~~~~~
    /workspace/setup.swift:12:13: error: use of unresolved identifier 'XCTAssertEqual'
                XCTAssertEqual(someDouble, arr2[index] as! Double)
                ^~~~~~~~~~~~~~
    /workspace/setup.swift:14:13: error: use of unresolved identifier 'XCTAssertEqual'
                XCTAssertEqual(someString, arr2[index] as! String)
                ^~~~~~~~~~~~~~
    /workspace/setup.swift:16:13: error: use of unresolved identifier 'XCTAssertTrue'
                XCTAssertTrue(val == nil && arr2[index] == nil)
                ^~~~~~~~~~~~~
    /workspace/setup.swift:18:13: error: use of unresolved identifier 'XCTFail'
                XCTFail("This data type is not handled in assertArraysOfAnyEqual")
                ^~~~~~~
    /runner/frameworks/swift/xctest/_XCTMain.swift:5:13: note: did you mean '_XCTMain'?
    public func _XCTMain(_ testCases: [XCTestCaseEntry]) -> Never {
                ^
    
  • Custom User Avatar

    I've fixed that initial problem where a move was not returned.
    The Master class handles the collisions between other bots and the boundaries, to make sure you're not cheating.
    The bot knows the boundaries by the set map method where a map will be given showing the position of each bot and the goal.

  • Default User Avatar

    console.log(Master.toString()) - unfortunately this approach only gave partial results for the sloth.

    I started on this Kata because it looks like an awesome challenge. From the get go it's been a struggle. I did a clean reset and pressed "run tests" and it gets the error "bots[key].bot.move is not a function". I added a "move: function () {" to the returned object and it now gets errors from the sloth about index 0 being invalid. It'd be nice if the initial setup would run and give Test failed results.

    You mentoined collisions but the instructions don't talk about that. What does that mean? collisions with other bots?

    How does a bot know the boundaries in which it can randomly move if it doesn't yet have a map? does "return 's';" satisfy random movement? ;)

    This is an awesome idea; I'd love to dig in to more of it.

  • Custom User Avatar

    Definitely needs some more test cases (edge cases?)

  • Custom User Avatar

    map isn't a function, it's a setter and the setMap function on the Master does work correctly.

  • Custom User Avatar

    i'll have a look again and see what's happening but the implementation of the Master is not important, it just checks collisions and checks whether the bots are in their final state or not.

  • Default User Avatar

    The original spec has the same ordering of LHS and RHS. The kata spec references ordering relative to popping the stack, while the original spec references ordering relative to pushing the stack. I can see how that can cause confusion.

    The two additional stack manipulation commands were added by the orginal authors in Whitespace 0.3, as shown in this tutorial, to facilitate the implementation of recursive functions.

    Having zero with a sign and no bit markers was based on my interpretation of the original specification that a number can have any width, and the fact that Haskell interpreter the original authors released accepts a sign without bit markers. There's additional ambiguity in the original spec that I tried to tighten in the kata spec, but that's certainly one of the more notable ones. Another ambiguity where the kata spec differs is that the original doesn't specify what to do when the argument to the slide command being less than zero or greater than the number of items on the stack.

  • Custom User Avatar

    It seems like the map function is never called. Are you sure the setMap function on Master works correctly? Also, it would be nice to know the implementaiton of Master, unless that's too much of a spoiler?

  • Custom User Avatar

    This was an absolute blast to implement, thank you for being so thorough with the test cases and implementation spec. The only issues I had with it were because I focused on the original Whitespace spec here: http://compsoc.dur.ac.uk/whitespace/tutorial.html rather than the minor tweaks you made to the spec. For example: the additional stack manipulation commands, as well as the fact that [space][space][space][lf] can be zero - only a sign and no digits. Also the original spec defines the opposite ordering of the left and right-hand sides of the arithmetic operands. That'll teach me to not stray from the kata description :)

  • Loading more items...