If you were willing to “spend” a difficulty level, you could have resistor-color-expert at a difficulty one above the others, and adjust the difficulty of unrelated exercises so none appear between.
1 Like
We can sort it automatically just this once, make our exception, and then manually insert alphabetically after this, I guess.
Or go with Ultimate, Virtuoso, or Wizard. Any opinions?
It’s true, but I’m not sure this last one is really medium-level difficulty (in any language).
So we’re talking about multiple bash scripts — the ones Jeremy made plus my student-specific one. I guess multiple would need to be rewritten in PowerShell: my test-local-gdscript-solution.sh depends on run.sh; if we support docker for students as well, run-in-docker.sh will also need a PowerShell version (and we’d need a corresponding option in test-local-gdscript-solution.sh or separate test-local-gdscript-solution-in-docker.sh for students to run that would then call run-in-docker.sh).
Mine could be merged into run-tests.sh since it does duplicate a bit of the logic; on the other hand, it’s much more specific to the student testing context, so I’m OK with this slight duplication. @IsaacG , do you have any thoughts on that bash-specific aspect? Would it make sense for run-tests.sh to become run-test.sh (defaulting to the student’s current exercise if given no arguments, and behaving like the current run-tests.sh if given the argument --all)?
And can you @IsaacG and @Meatball both confirm whether Docker support is important? I can see that our audience is unlikely to have it installed, in which case we need only support it for track maintainers/contributors, and just have bash and PS versions of run.sh and test-local-gdscript-solution.sh (unless it’s merged into run-tests.sh.)
If you can run the exercises on native Windows you only need the bash versions for docker (and don’t have to make docker user-friendly).
run-tests.sh is a script for testing the test runner itself against the tests located in the tests folder in the test runner repo. So you don’t have to have a run-all option or a run-tests script at all for students. You only have to have a script to run the tests for a specific exercise available to the student.
1 Like
Code duplication is bad. Put common code into functions in a common file. Source the common file and reuse functions 
Does it benefit the student/track to implement multiple versions of the exercise if the difficulties are the same? More isn’t always better; exercises should be exploring something new (concept, difficultly). Otherwise, it might be worth asking if it makes sense to drop one.
1 Like
Yeah, a variety of topics and difficulties is what the docs suggest so there’s likely something for everybody at launch. You can always fill in the other exercises later as desired. Not all exercises will make sense for all tracks. Several historically haven’t implemented reverse-string since their language’s standard library allows you to easily reverse a string.
1 Like
I’m not sure which way you are implying, @BNAndras . Cut or keep?
If there are no other opinions, can I go with Ultimate and make the changes already? Or if @IsaacG and @BNAndras are both wanting to cut this, does this mean it will be cut from Python as well? And is @Meatball OK with this cut? Who actually gets to decide? I really just came here with a simple question about exercise order, on this front ;)
Not sure what you mean. We still need a local/student/single-exercise test runner for Windows, in two versions (docker vs. not), right?
Edit: Sorry, I’d totally misread you @Meatball . I see what you mean now. @IsaacG , my request didn’t make sense — the logic duplication isn’t even slight, it’s not there at all (between run-tests.sh and my student addition.)
About the jq dependency (for students not running Docker), I see now that the JSON requirement comes from exercism itself. But, handily, GDScript has JSON support built-in. So if we really want, we can ditch jq in favor of a GDScript script. Do you both agree?
And do you both agree that I PR Add script for students' local Linux testing · exercism/gdscript-test-runner@6108272 · GitHub since there isn’t any duplication? Yes, it uses jq, but having this would at least provide a baseline to manually test before swapping out jq for something else (if that’s what we land on).
I wasn’t advocating for either. The exercises in question are already added, and we can only mark existing exercises as deprecated. Deprecation means the exercises remain in the system but are only available for students who started the exercise before that point…
You can freely change Resistor Color Expert’s name, but don’t change the UUID. You might be able to also change the slug to match the new name, but I haven’t done that before.
1 Like
If there are no other opinions, can I go with Ultimate and make the changes already? Or if @IsaacG and @BNAndras are both wanting to cut this, does this mean it will be cut from Python as well? And is @Meatball OK with this cut? Who actually gets to decide? I really just came here with a simple question about exercise order, on this front ;)
I am biased in this question, mostly because I co-wrote that exercise (original version is on the Python track). Personally, if the exercise hasn’t changed in any meaningful way, I would prefer that the name stays the same. But also if the exercise is ever attended to be expanded to problem spec it would make it more difficult if various tracks have used different namings.
1 Like
About the jq dependency (for students not running Docker), I see now that the JSON requirement comes from exercism itself. But, handily, GDScript has JSON support built-in. So if we really want, we can ditch jq in favor of a GDScript script. Do you both agree?
Yeah if Json could be handeld through Gdscript would that be preferable. Alternativly Powershell can do JSON parsing, so an option if that doesn’t work would be to use: bash with jq and Powershell. And there is jq for Windows as well.
And do you both agree that I PR Add script for students’ local Linux testing · exercism/gdscript-test-runner@6108272 · GitHub since there isn’t any duplication? Yes, it uses jq, but having this would at least provide a baseline to manually test before swapping out jq for something else (if that’s what we land on).
Looks good
1 Like
True, it hasn’t changed, but its naming presented a problem with ordering already. You’re right that it would make it more difficult with other tracks, but solving the order problem with their names with benefit them as well — i.e., I propose that an alphabetical naming here should be the standard if this ever makes it to problem spec. (And given what @IsaacG said earlier about considering dropping it, I’m not sure how probable that is anyway.) The reason I think that that’s feasible is that presumably not many tracks would need to change anything retroactively, and those that would, as @BNAndras seemed to imply just now, would only have to change the name and slug (if we can show that that doesn’t break anything, which we could try out right now).
But if not, I will just order them manually on this track.
Super, I will work on the JSON-in-GDScript front. 
You may want to run bash scripts through shellcheck to ensure best practices are followed.
1 Like
Good point. Will do.
So…upon closer inspection, this seems to already be implemented, actually. At some point the jq dependency in the Docker setup was removed, yet stayed on its installation list. I think we can remove all trace of jq since we already have what we need inside the GDScript end of the test runner.
The easiest solution I can see would be:
- Call
godot --headlessdirectly from the local test runner script instead of via run.sh, since run.sh’s exports aren’t needed outside Docker. (I.e., on my system, replacing the local test runner’srun.shline with a directgodot --headless -s bin/test_runner.gd 2>/tmp/stderr --works fine.) - Let the GDScript test runner, which currently requires 3 params, have the 3rd (the JSON output directory) be optional; if not supplied, it can, instead of writing JSON to a file, output test results to stdout (as JSON or something even prettier).
- To this end, rename
file_utils.write_results_fileto a more genericoutput_resultsand have it likewise have an optional 3rd param.
@Meatball are you OK with this approach?
(Either way, I’d then run shellcheck on the final bash script.)
@Meatball I PR’d this removal if you want to run any tests before merging, but the CI uses the Dockerfile directly, so given that it didn’t break, I think we’re OK: Remove jq from Dockerfile since its only use was removed by codingthat · Pull Request #53 · exercism/gdscript-test-runner · GitHub
Sounds good