Yes, from a users perspective in current julia yes. I was talking about it from the point of view that the @assert macro in Base would work like this. For this cases I think it would be better to have a startup option with two different sysimg and precompilation directories. The downside being that you can’t toggle it in a session.
1 Like
For this cases I think it would be better to have a startup option with two different sysimg and precompilation directories.
Even the bit-polishing performance-obsessed me is thinking this could
be a bit of an overkill for @assert, XD. If we grouped all training
wheels and/or non-essentials (@assert, bound checking, TimerOutputs,
etc…), then maybe having this infrastructure to run the code with or
without them would be justified. Maybe.
Is ToggleableAsserts.jl still the state-of-the-art to use assertions in high-performance-code?
2 Likes
Check out ArgCheck.jl and OptionalArgChecks.jl.
1 Like
Very interesting. If I am in need of this kind of check again, I will
maybe try to update the package to make them work again.
Great solution.
I ended up adding something like the following to my module’s __init__() function:
@eval asserting() = get(ENV, "ENABLE_ASSERTS", "0") == "1"
Why does that need to be in the __init__ function (and use @eval 
)?
2 Likes
Well, I put it in init to get the value of the env var at runtime, and not at precompilation. And @eval is necessary when you redefine a function from inside another function.
But I eventually discarded this solution because I randomly got this error:
ERROR: LoadError: InitError: Evaluation into the closed module MyModule breaks incremental compilation because the side effects will not be permanent. This is likely due to some other module mutating SCEngine with eval during precompilation - don’t do this.