Kristoffer Carlsson
Kristoffer Carlsson
+1 for this suggestion. The argument about that this package is easy to explain to a class doesn't hold much water to me. A small `DualNumbersEducation.jl` package could be made...
I think we should definitely try to keep the git history for these files.
One thing that could be done is to do the compilation in `__init__` instead and use https://github.com/JuliaPackaging/Scratch.jl to store the resulting files (instead of storing them inside the package folder)....
Use Scratch space as a cache and serialize it during runtime to a folder based on the julia version?
You can just prefix the scratch folder with the julia version for example.
I think the goal is to make the dual numbers take the same code path as the a real with the same real value would.
In my view, it would be surprising if you got a different number of iterations until the algorithm exits when using reals or dual numbers.
FWIW, 0.7 should make this PR not needed since the inlining heuristics are greatly improved. However, that doesn't help 0.6 so...
Well, it depends on what you mean with "intended". The code in PackageCompiler is written to do this, yes, but whether this is a good idea if there should be...
Perhaps better to make a small PR to PackageCompiler that has an `include_lazy_artifacts` option instead of messing around too much with the package based on (perhaps) bad defaults in PackageCompiler.