Unison tests keep failing saying the "tests timed out"

I had solved the alergies exercise but when i try submitting the code the tests time out even though my solution doesn’t have any performance bottlenecks, at least as far as i can tell. I do use recursion, though i don’t expect it to be a problem.

Here is my solution

allergies.allergicTo : Text -> Nat -> Boolean
allergies.allergicTo allergen score =
  List.contains allergen (allergies.list score)

allergies.list : Nat -> [Text]
allergies.list = cases
  x | x >= 256 -> 
        match x 
          |> Nat.toFloat
          |> Float.logBase 2.0
          |> Float.floor
          |> Float.pow 2.0
          |> Float.toNat with
        Some y -> list (x - y)
        None -> []

  x | x >= 128 -> "cats" +: list (x - 128)
  x | x >= 64 -> "pollen" +: list (x - 64)
  x | x >= 32 -> "chocolate" +: list (x - 32)
  x | x >= 16 -> "tomatoes" +: list (x - 16)
  x | x >= 8 -> "strawberries" +: list (x - 8)
  x | x >= 4 -> "shellfish" +: list (x - 4)
  x | x >= 2 -> "peanuts" +: list (x - 2)
  x | x >= 1 -> "eggs" +: list (x - 1)
  _ -> []

I have tested the code locally and all of the tests pass

I am using the exercism cli to submit my answers.

So is my solution really slow or is the unison test runner unreliable?
Thanks in advance for anybody willing to answer.

(cc @rlmark :slight_smile:)

1 Like

I had a similar problem. If you haven’t already, try submitting your solution again with an extended timeout?

exercism submit --timeout 100

The --timeout flag doesn’t change the test runner timeout.

» exercism submit --help
Submit your solution to an Exercism exercise.

...

Global Flags:
      --timeout int    override the default HTTP timeout (seconds)

Thanks @IsaacG. I suggested --timeout because it appears to work for me.

I’ll post again when I’ve submitted a few more Unison exercises with and without the extended timeout.

I’ve submitted enough Unison exercises now to confirm that it was beginners luck and --timeout doesn’t affect whether tests time out.

I had the same happen on the Hello, World! example, so I don’t think it’s related to the content of the submissions themselves?

With hello world, it is unlikely that it is caused by the contents. It’ll be the tool that we use to run tests (the test runner). @rlmark are there avenues for improvement we can use? For example upgrading to later versions?

Hmm, apologies for the delay; I was not getting email pings before. I’ll likely have some more time to look at the timeout issue next week. Upgrading the Exercism track to a new version of Unison is definitely a thing we can try!

2 Likes

I’m having the same problem.

The tests for Hello World passed fine first time, but for my Acronym solution they’ve timed out three times in a row.

When I run the Acronym tests locally, the individual cases complete, but the load command itself doesn’t, and I have to restart ucm. The output looks like this:

exercism/main> load acronym.test.uym.test.u

  Loading changes detected in acronym.test.u.


  + acronym.test.allCapsWord                  : [Result]
  + acronym.test.apostrophes                  : [Result]
  + acronym.test.basic                        : [Result]
  + acronym.test.consecutiveDelimiters        : [Result]
  + acronym.test.lowercaseWords               : [Result]
  + acronym.test.punctuation                  : [Result]
  + acronym.test.punctuationWithoutWhitespace : [Result]
  + acronym.test.underscoreEmphasis           : [Result]
  + acronym.test.veryLongAbbreviation         : [Result]
  + acronym.tests                             : [Result]
  
  Run `update` to apply these changes to your codebase.

Oops, I’ve just realised I was misinterpreting the local test output and thinking that it was telling me my solution was good. What I now realise is that my solution appears to be non-terminating on one or more cases.

Ignore me, sorry!

2 Likes