I'm managing my Isabelle installation with the Nix package manager. Each time I update, Isabelle decides to rebuild the heap images for Pure and HOL. I suspect that this might be because the path to the isabelle installation changes each time, but I don't understand why that would affect this - Isabelle ships with heap images in the tarball, and they get picked up regardless of the installation directory. How can I debug this?
(the reason this is quite annoying for me is that the build takes so much RAM that I cannot simply run it in the background. Is the required RAM an intrinsic property of the process, or could it be reduced by, for example, reducing the parallelism or something?)
https://arxiv.org/pdf/1805.07195.pdf the remote_build tools makes it possible to compile remotely. So I don't believe that the path is important
How drastic is your nix setup? Do you use the default components or do you also use the nix-provided version of the components?
(I believe that at least the polyml version is included in the heap, so a change in that wll cause a new compilation)
re: remote_build
- interesting, is it possible to set up jedit so that the heap builds it starts use remote_build
too?
I'm using the package from nixpkgs, not sure whether they pin the polyml
I don't think so, but I have never used remote_build
but usually you know what sessions you use (because you start the session every day)
however, both the old and new heaps are in ~/.isabelle/Isabelle2020/heaps/polyml-5.8.1_x86_64-linux
, so the polyml version seems to match
Sadly, I don't use nix. Could you try isabelle env
before and after your next update and see if there is any difference (for example by git diff --no-index old new
)?
If you use https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/logic/isabelle/default.nix, then Nix is really using its own components. So the only person who understands the low-level isabelle part will tell you to use the nicely packaged isabelle version
The problem with that is that the packaged Isabelle doesn't work as-is because the dynamic libraries don't exist at the expected locations :D
Got an isabelle env diff, only some paths changed their hash
I am also using nix without problems. I maintain my own nix expression (forked from the one in nixpkgs), though. See here: https://github.com/lukasstevens/dotfiles/blob/master/nix/isabelle/default.nix
You will also need an updated version of polyml: https://github.com/lukasstevens/dotfiles/blob/master/nix/polyml/default.nix
Those expressions are still up to date (Isabelle2020)
One could improve the expressions by also managing the isabelle settings and preferences
I don't see any relevant differences between your expression and the one in nixpkgs...
it also seems that the polyml in nixpkgs is newer
Yeah, back when I created those it was outdated in nixpkgs.
And some minor changes where necessary from Isabelle2019 -> Isabelle2020
The polyml version is the version that Isabelle2020 is shipped with.
the one on my plain-old-Debian computer is also using 5.8.1, you seem to be using 5.8
You can reduce RAM usage by setting ML_OPTIONS="--maxheap 8G"
in ~/.isabelle/Isabelle2020/etc/settings
. Although for large sessions this won't help you much and the process will just be killed.
what's the default maxheap?
Not really sure. I think as much as possible.
But since Linux deals with OOM situations badly that backfires often.
I don't think I would recommend using your own version of components (JDK, PolyML, etc.) instead of the ones that Isabelle ships with.
Conceptually, it is better to do that, though.
AFAICS nixpkgs matches the versions used by the actual release
I don't think it does for z3
This often leads to broken smt proofs. Thats my hunch on why that happens for me anyways
I just remember all kinds of problems arising from this kind of repackaging. People ask on the mailing list because something crashes or doesn't work and after some interrogation it transpires it's because of some repackaging issue and Makarius gets really annoyed by this because he wasted time tracking down an issue that only arises because people did something he specifically advises against.
Lukas Stevens said:
This often leads to broken smt proofs. Thats my hunch on why that happens for me anyways
It didn't earlier, now does
and it does fix some smt proofs
Manuel Eberl said:
I just remember all kinds of problems arising from this kind of repackaging. People ask on the mailing list because something crashes or doesn't work and after some interrogation it transpires it's because of some repackaging issue and Makarius gets really annoyed by this because he wasted time tracking down an issue that only arises because people did something he specifically advises against.
On has to say that this approach to packaging is not really sustainable (at least if many applications would do it).
It would be quite easy to pin the versions with nix on the other hand.
Thanks for making me aware. I am now using Isabelle from nixpkgs again.
oh well, I guess one day this will annoy me enough for me to figure out how and where to put the printfs to debug this further
Manuel Eberl said:
I just remember all kinds of problems arising from this kind of repackaging. People ask on the mailing list because something crashes or doesn't work and after some interrogation it transpires it's because of some repackaging issue and Makarius gets really annoyed by this because he wasted time tracking down an issue that only arises because people did something he specifically advises against.
Even further it is just not possible to run Isabelle on NixOS without patching it up first (at least not without ugly workarounds like FHSuserenv). Of course, the nix package also replaces some dependencies by their system versions (which may cause problems).
Do you also need to rebuild the heap images if the Isabelle or PolyML version do not change? It seems weird to me because I never had the problem before and the paths should not change as well when the hash stays the same.
I mean, the hash changes quite often because the dependency graph is quite deep
Ok, maybe it was just because I didn't pay much attention to it.
I just stumbled upon the line external_file "$POLYML_EXE"
in ML_Bootstrap.thy. Does this mean that the hash of the PolyML binary is a dependency?
Stupid question: isn't polyml saving structure (used to save heaps), version-dependent? (Independently of what external_file
does)
yes, but the polyml version in question wasn't changing - just some paths embedded in the polyml binary
Last updated: Dec 30 2024 at 16:22 UTC