A minor nit is that my color blindness simulator was showing the blue and green lines fairly similarly when testing deficient vision for blue or green. You indicated from your own experience that the color is less important, but I wonder if we should swap the red and green colors so it’s blue → red → green → orange. The blue and green segments would still look the same, but they’re visually separated.
+1 from me with or without that change
I dunno. From a colorblind perspective, the fact that the line bends 90 degrees is plenty of differentiation.
With my eyes, it’s the green and red that are the most similar. I had those points mixed up and it took me a few iterations to notice.
It’s a +1 from me. I would prefer slightly thicker lines, but given where this will display, it works.
From the perspective of someone who stares at a monochrome terminal all day and has a monochrome website, if the colors are tricky, do the arrows need to be different colors? Making them thicker and adding a slight gap at the ends might work equally well.
Feel free to disregard my feedback as I clearly don’t appreciate color and design.
Agree Bethany, I made the lines and points chubbier
Looks good to me. Do we have a third for the graph being PRed?
Third-ed here :)
(Draft) PR for the Prism instructions:
@BethanyG I took guidance from the Python Leap exercise performance article, linking to the “-light.svg” file. I’m assuming the theme selects the dark one as appropriate.
Merged by Erik. I have merge permissions but I’m not sure if I’m supposed to 
excellent. The problem-spec PR is out of draft.
Lots of lychee errors. I’ll PR that separately.
Here’s a PR for one of the two issues (a redirect).
Most of the Lychee errors are GitHub rate limiting.
Killer Sudoku needs a new link; I’ve looked before and didn’t find anything I like.
And Lychee has docs about that: Rate Limits | Docs
I would add --cache and --accept 200,429 to the lychee invocation at
Thanks for looking into this!
This adds those flags though the 429 could potentially hide broken links. I think it’s fine to ignore them as we’d probably eventually pick up broken links when we don’t hit the limit.
I’m implementing this exercise in the Roc track, it’s pretty cool.
I was wondering about loops and I found your comment suggesting to avoid them. I’m wondering why? It’s not that hard to detect loops, and I find it quite instructive.
Tracks could decide whether or not to add tests for them.
One question is how to treat loops: should it be treated like an error, or should the target sequence contain all the encountered prisms up to the first prism that’s visited twice from the same angle? The former is probably simpler, but the second has the advantage that tracks that have already added this exercise can add the new tests without changing the API.
Loops adds another dimension that distracts from the unique aspects of this problem.
This exercise proposal has been accepted and implemented. Are you proposing modifications to this exercise? If so, would you mind starting a new thread to lay out your proposal to discuss?
Yes, I’m suggesting a change. I’ve already implemented the exercise in the Roc track, but as I was implementing the solution, I thought that the question of loops really comes up naturally, I’m not sure it’s distracting, as avoiding infinite loops is common in games. I’ll open a new thread with this suggestion.