The problem happens with the test for 1+ when run in docker.
With this test included I get your error message when running in docker. Without this test, docker runs the suite just fine and all other tests pass.
Since this test works just fine when run outside docker, I think the problem lies with the serialization of the test results.
If I add (define incr 1+) and replace 1+ in the test case with incr, docker handles the test cases fine, too.
hmm… maybe I should have looked not only at chez’ output, but also at guile’s intermediate output.
While I could not figure out how the weird representation of 1+ as \x31;+ would cause the error, look what appears in guile’s output: ... (unquote #{1+}#) ..., which is much closer to the error message.
So I removed the guile invocation and now the original test suite (running only in chez scheme) passes in docker, too.
According to guile’s documentation of this extended reader syntax, “widespread usage of it is discouraged because it is not portable and not very readable”.
If I understand the call sequences correctly, a chez-scheme script runs the submitted code in both chez and guile, reading their output … and then failing to handle guile’s reader extension. So the chez-error-message is caused by unparseable guile-syntax.
The incr hack above avoids the unportable syntax and all is well.
For the record, I have also noticed this problem on (in addition to the Accumulate exercise)
And there may be more, but I did several exercises from the Scheme track with the in-browser editor on my phone while I was hiding from social interaction at my in-laws, and I’m pretty sure this doesn’t happen there. Just kidding, this totally happens there, too.
For what it’s worth, I’m using Guile 3.0.5 on Debian Bullseye (but, like I said, this also happens when using the in-browser editor).
Okay, thanks, but it turns out I’m just dumb.
I just had some debugging output printing that I didn’t notice because when you run the tests locally it swallows up stdout. I removed them and now everything works for me except Accumulate.
Sorry for reanimating zombie.
However, I suspect that the original issue mentioned in this post isn’t resolved (or reoccurred)
I still got the error An error occurred while running your tests. on accumulator exercise.
encountered same error here. still got the error when testing on the website:
An error occurred while running your tests. This might mean that there was an issue in our infrastructure, or it might mean that you have something in your code that’s causing our systems to break. …
As there’s no obvious clue for bugs, I copy all the test codes to my local machine, including “test.scm” and “test-util.ss”, only to find my solution passed all the test smoothly, weird.
Thank you for this post. I have run into the same issue with the online editor. Your post caused me to set up the CLI, and there were no issues.
I have also got into the same problem. I even tried
(define accumulate map)
to no avail. swsch seems to have analyzed the problem in depth about two years ago. Is there any plan to incorporate his finding into the exercise?
Exercism is volunteer-built and maintained. We’re currently between Scheme track maintainers so if you’re up to it, I’d suggest making the proposed changes.
It seems to me that the easiest thing we can do is to change the third test that uses the 1+ procedure. We could define the same procedure with a different name, say incr, and use it in the third test. Should I submit a PR along this line?
I don’t speak Scheme, but I think that sounds reasonable. Maybe give it a day or two in case someone else more knowledgeable can chime in?
That’s a good idea. I’ll wait for a couple of days.
Currently, the CI doesn’t test the accumulate exercise so that’ll need to be fixed. The track builds itself using Scheme source code, and it seems the CI tests the generated files from the source code. However, this exercise doesn’t have source code files in input/exercises so those will need to be added first and tested by the CI before we make any changes to the test suite. That way, we’re good to go when you make your PR and the CI passes.
I see. I happened to find an issue for the Scheme track you brought up at github. It says that “accumulate” should be replaced with “list-ops”. Interestingly, scheme/exercises/practice/list-ops exists but is not listed among the scheme track practices. In addition, just like accumulate, there is no scheme/input/exercises/list-ops. I am wondering if it Is difficult to remove accumulate from the practice list of scheme. It is not nice to have students work on the broken problem. We can then try adding list-ops to the scheme track.
When a track marks an exercise as deprecated, it is unavailable to new students - any students that have not already started the exercise.
When problem-specifications marks an exercise as deprecated, this is a recommendation to track maintainers to not implement the exercise, or to mark the exercise as deprecated in their track.
We could deprecate accumulate. That solves part of the problem, but the CI still should be fixed before we add another exercise like list-ops. Also, that exercise is a bit more involved than accumulate so it’s not like it’d be a drop-in replacement. The C# track kept accumulate after implementing list-ops so that students can try solving the easier accumulate before tackling the harder list-ops.
Keiraville and BNAndras,
So, it sounds that things are up to the track maintainer. And I have just noticed that the github repository of the scheme track is tagged “unmaintained” and “community-contributions-paused”. Does this really mean that the scheme track has no maintainer?
Borderite
P.S. list-ops is not difficult to solve in the Lisp family of languages including scheme.
Correct. There is no scheme maintainer. There are members of the community that have the ability to approve PRs across unmaintained and/or all Exercism repos, though. Those tend to be rather passive/reactive, though, opposed to active maintenance.
Lacking a dedicated maintainer, that choice tends to land with whomever can make a compelling argument and convince the more senior Exercism maintainers 
Oops, I missed that when I made that issue. I had checked on the Exercism website whether List Ops was available, but it wasn’t there. I assumed it meant List Ops hadn’t been implemented, but it had been.
List Ops is marked as deprecated, and I’m not sure why. I couldn’t find a related GH PR. The exercise was added in 2015 before canonical test cases were available in 2017. So if we deprecate Accumulate and turn List Ops back on, we should sync that test suite sooner or later.
However, since it’s not in the input/exercises folder, the CI currently isn’t testing that exercise either. So unless we just completely overhaul the CI, either Accumulate or List Ops should be added to input/exercises. I wouldn’t bother adding the one that’ll be deprecated going forward.
Thanks for your patience. There’s a lot going on with this repository that I’m not accustomed to with my own tracks. This track had a long-term maintainer, but they’ve been inactive for a while so this is a bit of an adventure for us too.
Thanks for your detailed explanation. I have just finished all practices in Scheme. 
Please let me know if I can be any help.