Announcing Elm-reduce

Hi! I’ve made a topic about Elm-reduce before, in which I’ve been looking for projects to test Elm-reduce on, now it’s ready for release!

This project helps you create bug reports in case the compiler crashes by removing irrelevant source code from your project until a small test case that reproduces the bug you have remains.

There is more info about this project in the readme on gitlab:

If you want a more detailed look at Elm-reduce, you can look at the thesis I wrote about it: (there is a pdf download link on that site)

Please try it out on the next bug that crashes any Elm tool :wink:

Also: I think we could really improve the Elm compiler’s robustness and tooling by fuzz testing the compiler. Elm-reduce is one of the pieces necessary for that: It would reduce the fuzzed test cases that triggered a bug in the compiler. The other piece, the fuzzer, is still missing. Other languages achieve great results by fuzz-testing their compilers: for C or for javascript (testing V8 at google)

What do you think?


I was checking over the repo just yesterday, didn’t realise you were so close to release!

Just built and ran it against the floorplan example repo I gave you a while back, but hit a snag before it finished:

elm-reduce: Module Not Found: SumAnimateTransform
CallStack (from HasCallStack):
error, called at src/Language/Elm/ModuleDependencies.hs:81:13 in elm-reduce-

Is that something I’m missing on my end, or is this something that was accidentally omitted from the install script?

What is the output of elm make for your project? It seems like it can’t resolve the “SumAnimateTransform” module, I guess it exists :smiley: If you could create an issue in the repository with a zip of your test case that would be awesome! :slight_smile:

> elm make src/Main.elm --output=elm.js
Success! Compiled 1 module.        

Sure thing! I’ll write that up now.

Ah. Found why it’s happening:


It’s trying to pull in an example file. Not sure how to overcome this, but we’ll move this conversation to the issue.

1 Like

Obviously this is a bug I have to fix, but you can still check out an example if you want to test the project by skipping the vendoring pass via the --no-vendoring flag.

Yep, that runs! But reduces to practically nothing since the Map! error I’m playing with here comes from a package.

1 Like

True. It should just be a Main function with a single import and a referred opaque type. That is one of the test Casey that reproduce the Map.! bug.

Even if you enabled vendoring, the library likely couldn’t be added to the source-directory as the bug would then stop reproducing.

I’ll try to fix the bug and we’ll see how it goes! :slight_smile: