Solutions Workspace (Revised)

[ellnix]

Revising this issue instead of opening a new one, please ignore the Old part.

Revised

Allow for a configurable workspace folder. Started a discussion for the config interface on #61

Allow for saving solution with these goals:

1. Atomic: the solution should be runnable without having to fetch the original clash json
2. Human-readable: A user who remembers a clash solved in the past should be able to navigate the workspace and find it easily
3. Multiple: The workspace should be able to organize multiple solutions for a puzzle
4. Notable: A user should be able to save a solution with a particular in order to cleanly differentiate solutions of a single exercise

Have a command (temporarily solve) which

• creates workspace/{clash-slug}/{lang}_{name}/ (lets call this folder $soldir)
• creates clash gen {lang} > "$soldir/solution.{lang extension}"
• copies the current clash's json to $soldir/puzzle.json

Have a command (temporarily commit) which

• saves the current solution with a name the user provides
• copies the current solution into a new $soldir to allow quick iteration

Make runner commands context-sensitive:

• If you run clash run (or a new porcelain command #60) from inside a $soldir it should auto detect puzzle.json and run the tests against it
• This would make it more convenient for users with integrated terminals in their editors

Slugging clashes and caching JSON

I think the public handle is unreadable as a folder name, it would be better if we slugged the title of the clash.

The rationale behind copying the clash JSON is to make this feature independent of codingame.tools and codingame.com. As long you have this binary and $soldir, you can still solve the puzzle.

Folder structure

I am personally against making a subfolder for each language, I feel like if the language is relevant to the solution it can be part of the solution name (if we name solutions by default like rust_1, js_1, js_2, etc.).

Plus, this tool is flexible enough to allow for solutions that use multiple language (say javascript + webassembly text) solutions.

Old:

Keep every solution in its own folder inside a folder for the clash:

- solutions/
  - {CLASH_ID}/
    - {timestamp}_{custom_solution_name}/
      - .git/
      - sol.rs
      - language # => rust
    - {timestamp}/ # solution without name
      - .git/
      - sol.py
      - language # => python

then allow for browsing solutions sorted by the timestamp with

clash solutions [CLASH_ID]

which would present the user with a select or fzf with the list of solutions for the clash of provided id or current clash if there is no id. Selecting a solution should open it in the default editor.

Scenarios when I think it would be appropriate to create a new solution

• When the clash is changed with clash next or some other command there should be a flag that tells clash run to create a new solution automatically
• With a clash save <name> command which should save a new solution no matter what and set that solution as the current one being tested
• With a clash solve command

Scenarios when I think it would be appropriate to git add and git commit inside a solution:

• When a solution is edited and then tested with clash run, there could be a commit with the PASS/FAIL test status

[Andriamanitra]

Storing the solutions is a good idea, but I think creating a git repository for each is wasteful and it would also add a dependency on git.

The clash solutions command should probably just print the paths to each solution on their own line – the user could then use fzf to pick one if they wish (but they could also easily use them in any other way):

$EDITOR $(clash solutions | fzf)

[Andriamanitra]

One issue I see with generating solutions automatically from clash run is that if you run for example

clash run --command "echo 42"

then there is not any sol.py file to save (and even the language is not clear). It would have to be something more like this to get all the necessary information:

clash save --build-command [BUILD_COMMAND] --command [RUN_COMMAND] --code-file [FILE] --language [LANGUAGE]

[ellnix]

Revised this suggestion, any feedback would be appreciated.

[Andriamanitra]

I think the proposed clash solve command seems reasonable, and making clash run check current directory for puzzle.json is probably acceptable overhead. I don't understand the clash commit command though, wouldn't the solution already be saved in $soldir? And why would someone want a copy instead of just modifying the current one?

[ellnix]

I think the proposed clash solve command seems reasonable, and making clash run check current directory for puzzle.json is probably acceptable overhead.

:+1:

I don't understand the clash commit command though, wouldn't the solution already be saved in $soldir? And why would someone want a copy instead of just modifying the current one?

The purpose of clash commit in my head is to let you iterate quickly. Say you are trying to golf a clash, and you feel like you can no longer remove chars from this type of solution, you just coctus commit ruby_eval_60 and then try a different implementation.

The idea being that it's a quick and easy way to save a working solution if you need to go back to it.

I think my explanation in the first post was a little strange, it's more just making a copy and saving it while you can continue to work on the current solution. Think git branch.