Puzzle types

Puzzle

The puzzle typically takes some input under the form of arguments or input files. Your program must then from those input produce a solution that solves the problem specification. Typically the output of your program must be printed to the standard output (stdout).

Success criteria

The success criteria can be measured in different ways and is typically mentioned in the puzzle description. For example:
  • by default the success criteria is that all tests must pass for a submission to be considered successful
  • another popular success criteria is by passing at least one test, typically in those puzzles, there's a number of points associated with each test case

Debugging

When debugging use stderr to write your messages. Since stderr is always flushed, in case your code gets stuck you will still the messages that were written before.

iPuzzle

An iPuzzle is an interactive puzzle in which typically your solution has to interact with another process through files. Partial information is exchanged between your solution and the puzzle process until the solution is found or the time expires. The iPuzzle simulates the concept of interactivity often required in web development, real time systems and other interactive systems.

Success criteria

In an iPuzzle the success criteria, in addition or in replacement of runtime, can be dependent on the number of messages exchanged.

Communication in an iPuzzle

  • Communication is handled through files. Files are used either as read only or write only.
  • Once the files are opened, they should only be closed when your program has finished its execution or else the iPuzzle process will consider that your program has aborted.
  • A communication message is terminated by a "\n"
  • When reading a message, read it as unbuffered and stop at the first "\n" or your program will be locked. Check for examples of unbuffered read in the forums
Samples

Multi-threading

Often, but not always, multi-threading is the technique of choice to solve the iPuzzles elegantly.

Debugging

When debugging use stderr to write your messages. Since stderr is always flushed, in case your code gets stuck you will still the messages that were written before.
If your program gets stuck, you will typically get a protocol_error message which says that you either tried to read too much data (remember to read in unbuffered or 1 char at time and stop at \n) or that you didn't write enough data to the robot and it still waiting (remember to flush when you write).