Sorting practice exercises?

That script worked perfectly for me on the Vimscript track. I wasn’t quite as thorough as I thought sorting those exercises manually.

1 Like

I’m revisiting an assumption of mine that Resistor Color, Resistor Color Duo, and Resistor Color Trio should always follow one another if implemented on a track even if they’re different difficulties. Is that also common practice elsewhere on Exercism? I’m just curious, and there’s no action on the GHA being requested here.

Do you mean they should be adjacent to one another? Or be in that order? I’ve never put them adjacent to each other. Sorting by difficultly/slug/name usually puts them in the right order, though.

Yeah. One after the other. That sort only works if there’s nothing before R on the second exercise’s difficulty or bucket. I’ve seen at least one track mention giving other easy exercises besides Resistor Color a difficulty of 2 so it can be 3, putting it at the end of the easy exercises. Then Resistor Color Duo can be marked 3 or 4 depending on how the track wants the displayed difficulty. If Duo is 4, then the other medium exercises are marked 5 to maintain sorting by difficulty and then name.

It’s pretty fiddly though so I don’t like it, and I usually just manually sort the Resistor Color exercises together.

If needed, we could probably some sort of exclusion to have the check ignore specific exercises.

2 thoughts on the script:

  1. use update-assignment.

    Instead of

    .exercises.practice = (
      .exercises.practice |
      ...)
    

    use.

    .exercises.practice |= (
      ...)
    
  2. replacing the original file.

    Instead of

    jq ... "$2" > "$tmp" && \
    cat "$tmp" > "$2"
    rm "$tmp"
    

    use mv, it’s atomic.

    jq ... "$2" > "$tmp" && \
    mv "$tmp" "$2"
    

Updated.

That recreates the file, though, resetting create time and file permissions. Using cat preserves file metadata. cat tends to be plenty reliable enough for this use case.

1 Like
  1. in the context of track maintenance, what relies on file create time?
  2. file permissions: use chmod before overwriting the original file
    jq ... "$2" > "tmp && \
    chmod --reference="$2" "$tmp" && \
    mv "$tmp" "$2"
    
    or umask 0022 before invoking jq – if we’re standardizing how to sort the config file, might as well standardize the permissions.

Nothing relies on the create timestamp, but there’s no reason to update that if it’s not needed. The cat approach changes the minimal amount of metadata. Is there a reason not to use it?

spoiler: we’re in argument-for-argument’s-sake mode now.

Let me turn that around: why is minimizing metadata changes the priority? What about minimizing file i/o? It’s just aconfig file, its metadata isn’t that precious

My main point was that mv is the right tool for this job. IMO I guess.

1 Like

You’re making an assumption that the metadata isn’t precious. I’m not making that assumption. Changing the metadata can be unexpected and if your assumption doesn’t hold, it can change things that people aren’t expecting changed.

File IO at this scale is rarely something people care about.

1 Like

can we acknowledge there are assumptions on both sides of this argument?

1 Like

Yes, I believe that’s correct :slightly_smiling_face:

2 Likes

I normally try to avoid internet arguments over minutiae, but this was fun ;)

1 Like