generic-random
generic-random copied to clipboard
Fix inspection tests
They got broken since last time I looked at this repository, no idea why, I haven't investigated yet.
It's something to do with splitmix which I thought I just fixed but actually still no.
- The inspection tests pass with a local copy of splitmix
- The inspection tests fail when I get splitmix from Hackage
Somehow cabal compiles local dependencies differently?
Repro:
git clone https://github.com/Lysxia/generic-random
git clone https://github.com/phadej/splitmix
cd generic-random
# With local splitmix
echo "packages: . ../splitmix" > cabal.project
cabal test --flags="enable-inspect"
# PASS
# With remote splitmix
echo "packages: ." > cabal.project
cabal test --flags="enable-inspect"
# FAIL
The tests also pass if I add splitmix as a git dependency.
Haven't tried stack.
I don't know what's different.
Version information
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library
The Glorious Glasgow Haskell Compilation System, version 8.10.1
Following these instructions
git clone https://github.com/Lysxia/generic-random
git clone https://github.com/phadej/splitmix
cd generic-random
# With local splitmix
echo "packages: . ../splitmix" > cabal.project
cabal test --flags="enable-inspect"
# PASS
# With remote splitmix
echo "packages: ." > cabal.project
cabal test --flags="enable-inspect"
# FAIL
I get the expected result (pass locally, fail from hackage)
Does cabal perhaps use different flags when compiling locally vs from hackage?
There is no diff between the uploaded Hackage .cabal and the one you get from cloning the package.
Thanks!
I think I found it, the build using local splitmix is also using random-1.1 whereas the build using remote splitmix is using random-1.2. Forcing random-1.1 in that case makes the tests pass.
(Sorry if it's obvious) Is it a problem of splitmix w/random-1.2 or this project? I am currently disabling tests for Arch.
This only concerns this project.
I see, thanks!
The current status is that, using newer the random 1.2 package, there is a subtle difference, from a lack of inlining, in the generated Core between what generic-random gives you and a reference "manual" implementation. That's "good enough" for virtually all practical purposes, but it's just unfortunate that regressions in this area can currently be caught only by routinely reenabling the test and manually comparing the Core.