From makarius at sketis.net Tue Feb 6 21:47:08 2024 From: makarius at sketis.net (Makarius) Date: Tue, 6 Feb 2024 21:47:08 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 Message-ID: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning that there is a nightly "isabelle build -a" on a virtual server (from Netcup). The Admin/build_release now works on Linux ARM64, and can produce logic images for Linux ARM64. Thus regular repository snapshots (and release candidates) support that platform by default, e.g. see https://isatest.sketis.net/devel/release_snapshot Still missing (to be investigated further) are the following external tools: * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on https://isatest.sketis.net/devel/build_status/index.html * cvc4 (or rather cvc5) * nunchaku * smbc * ocaml / opam Makarius From makarius at sketis.net Tue Feb 13 12:36:38 2024 From: makarius at sketis.net (Makarius) Date: Tue, 13 Feb 2024 12:36:38 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: On 06/02/2024 21:47, Makarius wrote: > With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning > that there is a nightly "isabelle build -a" on a virtual server (from Netcup). > > Still missing (to be investigated further) are the following external tools: > >   * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux > binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on > current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on > https://isatest.sketis.net/devel/build_status/index.html I've spent a lot of time experimenting with z3 4.4.0pre (0482e7fe727c), but did not succeed so far (as of Isabelle/6e5f40cfa877): The session HOL-SMT_Examples fails with timeout, due to non-terminating invocations of z3 on arm64-linux. For verit there was a similar problem, but rebuilding it from source (with "docker run -it ubuntu:18.04 bash") made it work; see also see Isabelle/b14c4cb37d99. For z3 the build instructions are as follows, using the attached z3.patch, which is based on the Debian package and changes found in the z3 repository: """ docker run -it ubuntu:16.04 bash apt-get update && apt-get upgrade -y && apt autoremove -y apt install -y curl less libfontconfig1 libgomp1 openssh-client perl pwgen rlwrap make g++ python mkdir z3-4.4.0pre cd z3-4.4.0pre curl --location https://github.com/Z3Prover/z3/archive/0482e7fe727c.tar.gz | tar --strip-components=1 -xz -f - #inline z3.patch below patch -p1 < From jasmin.blanchette at ifi.lmu.de Wed Feb 14 08:47:05 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Wed, 14 Feb 2024 08:47:05 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: Hi Makarius, Thanks for investigating this. The binary components are always a special source of worry. From what I understand, HOL-SMT_Examples will continue working thanks to the certificate caching mechanism that is used there. The mechanism isn't used in the AFP, though, which means arm64-linux users won't be able to load many AFP entries due to "smt" calls to Z3 in there. If this is too much of an issue, we could consider either of two solutions: 1. Replace the "smt" calls. Most of them could use the "(verit)" option instead, and for the others, we'd have to come up with alternative proofs. This possibly entails a lot of work, but it could be done by a "task force". 2. Use certificates for the AFP (and require their use in the future). Certificates take the form of low-level (SMT input, SMT output) pairs, so that when "smt" generates a given SMT input in the cache, the SMT output is used directly instead of running the SMT solver. Best, Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 13. Feb 2024, at 12:36, Makarius wrote: > > On 06/02/2024 21:47, Makarius wrote: >> With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning that there is a nightly "isabelle build -a" on a virtual server (from Netcup). >> Still missing (to be investigated further) are the following external tools: >> * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on https://isatest.sketis.net/devel/build_status/index.html > > I've spent a lot of time experimenting with z3 4.4.0pre (0482e7fe727c), but did not succeed so far (as of Isabelle/6e5f40cfa877): The session HOL-SMT_Examples fails with timeout, due to non-terminating invocations of z3 on arm64-linux. > > For verit there was a similar problem, but rebuilding it from source (with "docker run -it ubuntu:18.04 bash") made it work; see also see Isabelle/b14c4cb37d99. > > > For z3 the build instructions are as follows, using the attached z3.patch, which is based on the Debian package and changes found in the z3 repository: > > """ > docker run -it ubuntu:16.04 bash > apt-get update && apt-get upgrade -y && apt autoremove -y > apt install -y curl less libfontconfig1 libgomp1 openssh-client perl pwgen rlwrap make g++ python > > mkdir z3-4.4.0pre > cd z3-4.4.0pre > curl --location https://github.com/Z3Prover/z3/archive/0482e7fe727c.tar.gz | tar --strip-components=1 -xz -f - > > #inline z3.patch below > patch -p1 < ... > EOF > > python scripts/mk_make.py > cd build && make > """ > > > That is minor progress, because the build works at all, by using ubuntu:16.04 instead of our official ubuntu:18.04 baseline. > > For the planned release of Isabelle2024 (May 2024), I tend to disable z3 on arm64-linux by default (via etc/settings of the component), and no longer pretend that we have something working, see also https://isabelle-dev.sketis.net/rISABELLE796ae338eb9d > > > Makarius > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From jasmin.blanchette at ifi.lmu.de Wed Feb 14 09:08:42 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Wed, 14 Feb 2024 09:08:42 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: <891785DC-3150-4AF0-BD4D-291F07DF2741@ifi.lmu.de> Hi Makarius, > Still missing (to be investigated further) are the following external tools: > > * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on https://isatest.sketis.net/devel/build_status/index.html See my previous email. > * cvc4 (or rather cvc5) CVC4 would be nice to have, but it's not critical in the same way as Z3. cvc5 used to crash on Mac, but I'm told by Clark Barrett that with version 1.1.0 they've solved many Mac-specific bugs. I can experiment with it on my Mac and if it seems to work well, we could upgrade to that. > * nunchaku > > * smbc Nunchaku (and its backend SMBC) never left the experimental stage. Maybe we could move them out of "HOL" and mark them more clearly as experimental? I haven't given up all hopes of developing Nunchaku further and indeed just this week I was talking with a candidate about doing this, but it shouldn't block Isabelle releases. > * ocaml / opam Thankfully somebody else's concern. :) Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 6. Feb 2024, at 21:47, Makarius wrote: > > With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning that there is a nightly "isabelle build -a" on a virtual server (from Netcup). > > > The Admin/build_release now works on Linux ARM64, and can produce logic images for Linux ARM64. Thus regular repository snapshots (and release candidates) support that platform by default, e.g. see https://isatest.sketis.net/devel/release_snapshot > > > > Makarius > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From lp15 at cam.ac.uk Wed Feb 14 11:42:29 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Wed, 14 Feb 2024 10:42:29 +0000 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: <02C9249B-A5D3-439D-9660-4BBC4957681E@cam.ac.uk> Somewhat to my surprise, there seem to be 1004 occurrences of “smt(z3" in the libraries and repository (I've never allowed it personally). It is outnumbered by verit more than 3 to 1, again a surprisingly low ratio. Getting rid of them all would be a tedious business. One day we might consider automated tools to crawl over old the proofs and get rid of ugly things. Larry > On 14 Feb 2024, at 07:47, Jasmin Blanchette wrote: > > 1. Replace the "smt" calls. Most of them could use the "(verit)" option instead, and for the others, we'd have to come up with alternative proofs. This possibly entails a lot of work, but it could be done by a "task force". > From jasmin.blanchette at ifi.lmu.de Wed Feb 14 13:09:46 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Wed, 14 Feb 2024 13:09:46 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <02C9249B-A5D3-439D-9660-4BBC4957681E@cam.ac.uk> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <02C9249B-A5D3-439D-9660-4BBC4957681E@cam.ac.uk> Message-ID: <84E41903-0A5D-4F29-BFF8-1DB66FF0F9B5@ifi.lmu.de> Hi Larry, "smt(z3" occurs seldom because z3 is the default for "smt", so often it's omitted. (I believe it used to be omitted and now it's explicit.) Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 14. Feb 2024, at 11:42, Lawrence Paulson wrote: > > Somewhat to my surprise, there seem to be 1004 occurrences of “smt(z3" in the libraries and repository (I've never allowed it personally). It is outnumbered by verit more than 3 to 1, again a surprisingly low ratio. > > Getting rid of them all would be a tedious business. One day we might consider automated tools to crawl over old the proofs and get rid of ugly things. > > Larry > >> On 14 Feb 2024, at 07:47, Jasmin Blanchette wrote: >> >> 1. Replace the "smt" calls. Most of them could use the "(verit)" option instead, and for the others, we'd have to come up with alternative proofs. This possibly entails a lot of work, but it could be done by a "task force". >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From lp15 at cam.ac.uk Wed Feb 14 13:23:00 2024 From: lp15 at cam.ac.uk (Lawrence Paulson) Date: Wed, 14 Feb 2024 12:23:00 +0000 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <84E41903-0A5D-4F29-BFF8-1DB66FF0F9B5@ifi.lmu.de> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <02C9249B-A5D3-439D-9660-4BBC4957681E@cam.ac.uk> <84E41903-0A5D-4F29-BFF8-1DB66FF0F9B5@ifi.lmu.de> Message-ID: <6EC8F9C2-715F-4200-8C67-15254CDD489D@cam.ac.uk> That picks up a further 428 occurrences Larry > On 14 Feb 2024, at 12:09, Jasmin Blanchette wrote: > > "smt(z3" occurs seldom because z3 is the default for "smt", so often it's omitted. (I believe it used to be omitted and now it's explicit.) > From makarius at sketis.net Thu Feb 15 10:03:48 2024 From: makarius at sketis.net (Makarius) Date: Thu, 15 Feb 2024 10:03:48 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <891785DC-3150-4AF0-BD4D-291F07DF2741@ifi.lmu.de> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <891785DC-3150-4AF0-BD4D-291F07DF2741@ifi.lmu.de> Message-ID: <87f7013b-fabd-4e31-817e-4d1ace6c5556@sketis.net> On 14/02/2024 09:08, Jasmin Blanchette wrote: > >>  * nunchaku >> >>  * smbc > > Nunchaku (and its backend SMBC) never left the experimental stage. Maybe we > could move them out of "HOL" and mark them more clearly as experimental? I > haven't given up all hopes of developing Nunchaku further and indeed just this > week I was talking with a candidate about doing this, but it shouldn't block > Isabelle releases. I would say we just leave the status-quo for the Isabelle2024 release, i.e. these tools are implicitly "experimental" and there is no arm64-linux support. Makarius From jasmin.blanchette at ifi.lmu.de Thu Feb 15 14:50:54 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Thu, 15 Feb 2024 14:50:54 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> Hi Makarius, Concerning cvc5: I tried downloading and running cvc5 1.1.1 for arm64 from https://github.com/cvc5/cvc5/releases/ and I still get errors in Isabelle. For example, adding the line sledgehammer[cvc5, mepo, slices=4] before line 318 of the file "$AFP/thys/Given_Clause_Loops/DISCOUNT_Loop.thy" produces this output (nondeterministically): Sledgehammering... cvc5 found a proof... cvc5 found a proof... cvc5 found a proof... cvc5 found a proof... /tmp/isabelle-jasminblanchette/bash_script1894380443147744112: line 1: 30873 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --decision\=internal --simplification\=none --full-saturate-quant --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 219 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904226 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904228 2>&1 /tmp/isabelle-jasminblanchette/bash_script936180679870508119: line 1: 30876 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --trigger-sel\=max --full-saturate-quant --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 222 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904284 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904286 2>&1 /tmp/isabelle-jasminblanchette/bash_script2386389454125518978: line 1: 30882 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --full-saturate-quant --inst-when\=full-last-call --inst-no-entail --term-db-mode\=relevant --multi-trigger-linear --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 221 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904420 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904422 2>&1 cvc5: Try this: by (metis P0A_add_y_formula PYA_add_active_formula state.simps) (130 ms) cvc5: Duplicate proof cvc5: Duplicate proof cvc5: Duplicate proof Done I don't know what the "Abort trap" warnings mean, because the prover seems to succeed nevertheless. I need to investigate. But I don't get these errors with CVC4. Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 6. Feb 2024, at 21:47, Makarius wrote: > > With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning that there is a nightly "isabelle build -a" on a virtual server (from Netcup). > > > The Admin/build_release now works on Linux ARM64, and can produce logic images for Linux ARM64. Thus regular repository snapshots (and release candidates) support that platform by default, e.g. see https://isatest.sketis.net/devel/release_snapshot > > > Still missing (to be investigated further) are the following external tools: > > * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on https://isatest.sketis.net/devel/build_status/index.html > > * cvc4 (or rather cvc5) > > * nunchaku > > * smbc > > * ocaml / opam > > > Makarius > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From jasmin.blanchette at ifi.lmu.de Fri Feb 16 15:10:01 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Fri, 16 Feb 2024 15:10:01 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> Message-ID: <2A5A3BAD-F89A-4B20-B8B7-6149F65CB508@ifi.lmu.de> Hi all, I've investigated further. The issue is hard to debug. It seems to arise only when minimizing proofs (where we call the solver repeatedly on often unprovable problems) and only when at least two solvers are run in parallel (i.e., when invoking Sledgehammer with "slices=2" or above). I thought I might make some progress by replacing the "cvc5" binary with this script: #!/bin/bash cp ${!#} "$(mktemp /tmp/foo.XXXXXXXXX).smt" /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5.bin $@ where "cvc5.bin" is the ARM64 Darwin cvc5 binary. But then the issue doesn't arise anymore! As far as I can tell, the issue only arises with unprovable (sat) problems anyway, and it happens in such a way that it doesn't affect the workings of Sledgehammer. What's annoying is the yellow warning message in Isabelle/jEdit. It looks like we can suppress the yellow message by writing a small wrapper script like the above (but using the proper idiom for retrieving the path of "cvc5.bin"). Is that what we should do? It would be great to leave CVC4 behind and to move to cvc5. Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 15. Feb 2024, at 14:50, Jasmin Blanchette wrote: > > Hi Makarius, > > Concerning cvc5: I tried downloading and running cvc5 1.1.1 for arm64 from > > https://github.com/cvc5/cvc5/releases/ > > and I still get errors in Isabelle. For example, adding the line > > sledgehammer[cvc5, mepo, slices=4] > > before line 318 of the file "$AFP/thys/Given_Clause_Loops/DISCOUNT_Loop.thy" produces this output (nondeterministically): > > Sledgehammering... > cvc5 found a proof... > cvc5 found a proof... > cvc5 found a proof... > cvc5 found a proof... > /tmp/isabelle-jasminblanchette/bash_script1894380443147744112: line 1: 30873 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --decision\=internal --simplification\=none --full-saturate-quant --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 219 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904226 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904228 2>&1 > /tmp/isabelle-jasminblanchette/bash_script936180679870508119: line 1: 30876 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --trigger-sel\=max --full-saturate-quant --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 222 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904284 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904286 2>&1 > /tmp/isabelle-jasminblanchette/bash_script2386389454125518978: line 1: 30882 Abort trap: 6 /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5 --full-saturate-quant --inst-when\=full-last-call --inst-no-entail --term-db-mode\=relevant --multi-trigger-linear --proof-format-mode\=alethe --proof-granularity\=dsl-rewrite --no-stats --sat-random-seed\=1 --lang\=smt2 --tlimit 221 /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904420 > /tmp/isabelle-jasminblanchette/process10570530194278022654/cache-io-9904422 2>&1 > cvc5: Try this: by (metis P0A_add_y_formula PYA_add_active_formula state.simps) (130 ms) > cvc5: Duplicate proof > cvc5: Duplicate proof > cvc5: Duplicate proof > Done > > I don't know what the "Abort trap" warnings mean, because the prover seems to succeed nevertheless. I need to investigate. But I don't get these errors with CVC4. > > Jasmin > > -- > Prof. Dr. Jasmin Blanchette > Chair of Theoretical Computer Science and Theorem Proving > Ludwig-Maximilians-Universität München > Oettingenstr. 67, 80538 München, Germany > Tel.: +49 (0)89 2180 9337 > Email: jasmin.blanchette at ifi.lmu.de > Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > > >> On 6. Feb 2024, at 21:47, Makarius wrote: >> >> With Isabelle/37e57ac55559 we now have proven support for Linux ARM64, meaning that there is a nightly "isabelle build -a" on a virtual server (from Netcup). >> >> >> The Admin/build_release now works on Linux ARM64, and can produce logic images for Linux ARM64. Thus regular repository snapshots (and release candidates) support that platform by default, e.g. see https://isatest.sketis.net/devel/release_snapshot >> >> >> Still missing (to be investigated further) are the following external tools: >> >> * z3: stuck at the rather old version 4.4.0, which lacks arm64-linux binaries; the 4.4.1 arm64 package from ancient Debian is somewhat unstable on current Ubuntu 20.04, see also failure of HOL-SMT_Examples recorded on https://isatest.sketis.net/devel/build_status/index.html >> >> * cvc4 (or rather cvc5) >> >> * nunchaku >> >> * smbc >> >> * ocaml / opam >> >> >> Makarius >> _______________________________________________ >> isabelle-dev mailing list >> isabelle-dev at in.tum.de >> https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev > > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From makarius at sketis.net Fri Feb 16 15:33:40 2024 From: makarius at sketis.net (Makarius) Date: Fri, 16 Feb 2024 15:33:40 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <2A5A3BAD-F89A-4B20-B8B7-6149F65CB508@ifi.lmu.de> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> <2A5A3BAD-F89A-4B20-B8B7-6149F65CB508@ifi.lmu.de> Message-ID: <5554748f-a468-443d-ae93-0a3bd249a7e4@sketis.net> On 16/02/2024 15:10, Jasmin Blanchette wrote: > > I thought I might make some progress by replacing the "cvc5" binary with this > script: > > #!/bin/bash > cp ${!#} "$(mktemp /tmp/foo.XXXXXXXXX).smt" > /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5.bin $@ > > where "cvc5.bin" is the ARM64 Darwin cvc5 binary. But then the issue doesn't > arise anymore! That could be some odd effect from switching between Intel and ARM on macOS, maybe caused by our bash_process wrapper (which is for Intel in Isabelle/0f01c575ff3e). Apart from that, are you satisfied with cvc5-1.1.1? Does everything work with the current Intel setup? If so, I will see how to change our process wrappers such that everything works again on all platforms. Makarius From florian.haftmann at informatik.tu-muenchen.de Sat Feb 17 09:47:27 2024 From: florian.haftmann at informatik.tu-muenchen.de (Florian Haftmann) Date: Sat, 17 Feb 2024 09:47:27 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> Message-ID: Hi all, > 1. Replace the "smt" calls. Most of them could use the "(verit)" option > instead, and for the others, we'd have to come up with alternative > proofs. This possibly entails a lot of work, but it could be done by a > "task force". > > 2. Use certificates for the AFP (and require their use in the future). > Certificates take the form of low-level (SMT input, SMT output) pairs, > so that when "smt" generates a given SMT input in the cache, the SMT > output is used directly instead of running the SMT solver. just my 5 cent: the certificates are helpful, but strictly relying on them in distribution or AFP rules out people having no access to certain provers to do work requiring potentially pervasive maintenance of proofs. Cheers, Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xA707172232CFA4E9.asc Type: application/pgp-keys Size: 19161 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From jasmin.blanchette at ifi.lmu.de Mon Feb 19 12:50:42 2024 From: jasmin.blanchette at ifi.lmu.de (Jasmin Blanchette) Date: Mon, 19 Feb 2024 12:50:42 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <5554748f-a468-443d-ae93-0a3bd249a7e4@sketis.net> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> <2A5A3BAD-F89A-4B20-B8B7-6149F65CB508@ifi.lmu.de> <5554748f-a468-443d-ae93-0a3bd249a7e4@sketis.net> Message-ID: Hi Makarius, I'm very satisfied with cvc5. I ran an evaluation on hundreds of goals from the AFP and the success rate went up from 52% for CVC4 to 64% for cvc5. Jasmin -- Prof. Dr. Jasmin Blanchette Chair of Theoretical Computer Science and Theorem Proving Ludwig-Maximilians-Universität München Oettingenstr. 67, 80538 München, Germany Tel.: +49 (0)89 2180 9337 Email: jasmin.blanchette at ifi.lmu.de Web: https://www.tcs.ifi.lmu.de/mitarbeiter/jasmin-blanchette_de.html > On 16. Feb 2024, at 15:33, Makarius wrote: > > On 16/02/2024 15:10, Jasmin Blanchette wrote: >> I thought I might make some progress by replacing the "cvc5" binary with this script: >> #!/bin/bash >> cp ${!#} "$(mktemp /tmp/foo.XXXXXXXXX).smt" >> /Users/jasminblanchette/.isabelle/contrib/cvc5-1.1.1/arm64-darwin/cvc5.bin $@ >> where "cvc5.bin" is the ARM64 Darwin cvc5 binary. But then the issue doesn't arise anymore! > > That could be some odd effect from switching between Intel and ARM on macOS, maybe caused by our bash_process wrapper (which is for Intel in Isabelle/0f01c575ff3e). > > Apart from that, are you satisfied with cvc5-1.1.1? Does everything work with the current Intel setup? > > If so, I will see how to change our process wrappers such that everything works again on all platforms. > > > Makarius > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4674 bytes Desc: not available URL: From makarius at sketis.net Thu Feb 29 10:38:29 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 10:38:29 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ Message-ID: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> An odd (unexplained) change has occurred on AFP: changeset: 14197:ddf90847bfa5 user: immler date: Tue Feb 27 15:10:13 2024 +0100 files: thys/Ordinary_Differential_Equations/Ex/Lorenz/C1/Lorenz_C1.thy thys/Ordinary_Differential_Equations/ROOT description: enable proof in session Lorenz_C1 Looking briefly into the history reveals this evidence: changeset: 8561:13b3e24a71b0 user: wenzelm date: Mon Nov 20 07:50:03 2017 +0100 files: thys/Ordinary_Differential_Equations/Ex/Lorenz/Lorenz_C1.thy thys/Ordinary_Differential_Equations/ROOT description: adapted to timing on lxcisa0 with threads=8: (8:08:58 elapsed time, 47:18:51 cpu time, factor 5.81); Although lxcisa0 has grown old, it is still representative for the performance baseline of testing. Yesterday, I've started the session on more current hardware to see how it works now, but that is still running. Maybe something else is wrong on that machine. Further note that the standard nightly build (isabelle_cronjob) is affected: it will probably terminate within 1-3 more days. See also lrzcloud2 on https://isatest.sketis.net/devel/cronjob-main.log So what is the reasoning behind the change ddf90847bfa5? The log does not say anything tangible. Of course it is better to check things formally, instead of having them commented-out. So far, I thought that Lorenz_C0 was there to be tested properly, and Lorenz_C1 an untested add-on example that is unlikely to fail on its own account. If huge and heavy things like Lorenz_C1 should get a more formal status in AFP, we probably need a session group "very_very_slow" or alternatively "untested" to say that it is not tested regularly. Makarius From makarius at sketis.net Thu Feb 29 11:01:50 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 11:01:50 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: <73d21d3c-7a61-469e-bd64-fdd3539b7b82@sketis.net> On 29/02/2024 10:38, Makarius wrote: > An odd (unexplained) change has occurred on AFP: > > changeset:   14197:ddf90847bfa5 > user:        immler I've sent this with CC to immler.emails.immler_email according to AFP/38e4f6bce76e metadata, but that address did not work. Makarius From makarius at sketis.net Thu Feb 29 11:24:40 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 11:24:40 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: On 29/02/2024 10:38, Makarius wrote: > > Looking briefly into the history reveals this evidence: > > changeset:   8561:13b3e24a71b0 > user:        wenzelm > date:        Mon Nov 20 07:50:03 2017 +0100 > files:       thys/Ordinary_Differential_Equations/Ex/Lorenz/Lorenz_C1.thy > thys/Ordinary_Differential_Equations/ROOT > description: > adapted to timing on lxcisa0 with threads=8: (8:08:58 elapsed time, 47:18:51 > cpu time, factor 5.81); > > Although lxcisa0 has grown old, it is still representative for the performance > baseline of testing. > > Yesterday, I've started the session on more current hardware to see how it > works now, but that is still running. Maybe something else is wrong on that > machine. It has now terminated as follows (on of1.proof.cit.tum.de): Finished Lorenz_C1 (11:29:26 elapsed time, 67:46:46 cpu time, factor 5.90) That is something to be investigated. Either there is something odd in the machine configuration, or this bulky test now takes much longer than in 2017. Makarius From nipkow at in.tum.de Thu Feb 29 11:29:26 2024 From: nipkow at in.tum.de (Tobias Nipkow) Date: Thu, 29 Feb 2024 11:29:26 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <73d21d3c-7a61-469e-bd64-fdd3539b7b82@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> <73d21d3c-7a61-469e-bd64-fdd3539b7b82@sketis.net> Message-ID: <31113918-8fda-4bb8-8a8f-cb9800d68e9b@in.tum.de> I have forwarded your email to a working email address. Tobias On 29/02/2024 11:01, Makarius wrote: > On 29/02/2024 10:38, Makarius wrote: >> An odd (unexplained) change has occurred on AFP: >> >> changeset:   14197:ddf90847bfa5 >> user:        immler > > I've sent this with CC to immler.emails.immler_email according to > AFP/38e4f6bce76e metadata, but that address did not work. > > >     Makarius > > _______________________________________________ > isabelle-dev mailing list > isabelle-dev at in.tum.de > https://mailman46.in.tum.de/mailman/listinfo/isabelle-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4950 bytes Desc: S/MIME Cryptographic Signature URL: From huch at in.tum.de Thu Feb 29 11:33:40 2024 From: huch at in.tum.de (Fabian Huch) Date: Thu, 29 Feb 2024 11:33:40 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: On 2/29/24 10:38, Makarius wrote: > An odd (unexplained) change has occurred on AFP: > > changeset:   14197:ddf90847bfa5 > user:        immler > date:        Tue Feb 27 15:10:13 2024 +0100 > files: thys/Ordinary_Differential_Equations/Ex/Lorenz/C1/Lorenz_C1.thy > thys/Ordinary_Differential_Equations/ROOT > description: > enable proof in session Lorenz_C1 > I heard from Fabian that nowadays the session runs reasonably fast (6 hrs -- Flyspec-Tame-computation is nearly 5 hrs). But this does not seem to fit with your results. > > Looking briefly into the history reveals this evidence: > > changeset:   8561:13b3e24a71b0 > user:        wenzelm > date:        Mon Nov 20 07:50:03 2017 +0100 > files: thys/Ordinary_Differential_Equations/Ex/Lorenz/Lorenz_C1.thy > thys/Ordinary_Differential_Equations/ROOT > description: > adapted to timing on lxcisa0 with threads=8: (8:08:58 elapsed time, > 47:18:51 cpu time, factor 5.81); > > Although lxcisa0 has grown old, it is still representative for the > performance baseline of testing. > > Yesterday, I've started the session on more current hardware to see > how it works now, but that is still running. Maybe something else is > wrong on that machine. > > > Further note that the standard nightly build (isabelle_cronjob) is > affected: it will probably terminate within 1-3 more days. See also > lrzcloud2 on https://isatest.sketis.net/devel/cronjob-main.log If it should be nightly we really need high-end hardware here (not 1/4 slice of a Xeon 4316) -- we won't have free access to these machines for much longer anyway. > > So what is the reasoning behind the change ddf90847bfa5? The log does > not say anything tangible. > > Of course it is better to check things formally, instead of having > them commented-out. So far, I thought that Lorenz_C0 was there to be > tested properly, and Lorenz_C1 an untested add-on example that is > unlikely to fail on its own account. > > If huge and heavy things like Lorenz_C1 should get a more formal > status in AFP, we probably need a session group "very_very_slow" or > alternatively "untested" to say that it is not tested regularly. Im am in favor of having an "untested" groups vs. commenting out proofs. Fabian From makarius at sketis.net Thu Feb 29 11:55:24 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 11:55:24 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: On 29/02/2024 11:33, Fabian Huch wrote: > > On 2/29/24 10:38, Makarius wrote: >> An odd (unexplained) change has occurred on AFP: >> >> changeset:   14197:ddf90847bfa5 >> user:        immler >> date:        Tue Feb 27 15:10:13 2024 +0100 >> files: thys/Ordinary_Differential_Equations/Ex/Lorenz/C1/Lorenz_C1.thy >> thys/Ordinary_Differential_Equations/ROOT >> description: >> enable proof in session Lorenz_C1 >> > I heard from Fabian that nowadays the session runs reasonably fast (6 hrs -- > Flyspec-Tame-computation is nearly 5 hrs). But this does not seem to fit with > your results. On which hardware precisely? This question also touches Intel vs. ARM: the native ARM Poly/ML is incredibly fast in most applications, but can be slower in some of these computations. I did not investigate this systematically so far. Presently we are testing Intel only. >> Of course it is better to check things formally, instead of having them >> commented-out. So far, I thought that Lorenz_C0 was there to be tested >> properly, and Lorenz_C1 an untested add-on example that is unlikely to fail >> on its own account. >> >> If huge and heavy things like Lorenz_C1 should get a more formal status in >> AFP, we probably need a session group "very_very_slow" or alternatively >> "untested" to say that it is not tested regularly. Concerning the unequal, but related brothers Lorenz_C0 and Lorenz_C1, I have now collected all available timing information since 2017. The command-line for that is "isabelle build_status -S Lorenz_C0 -l 10000", but it requires access to a non-public PostgreSQL server. The result is in the attached .csv: nothing special to be seen here, looks fine. Makarius -------------- next part -------------- A non-text attachment was scrubbed... Name: Lorenz_C0.csv Type: text/csv Size: 137119 bytes Desc: not available URL: From makarius at sketis.net Thu Feb 29 13:04:13 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 13:04:13 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: <6b793612-fbc0-4dc9-9b66-e7339d449c59@sketis.net> On 29/02/2024 11:24, Makarius wrote: > On 29/02/2024 10:38, Makarius wrote: > > It has now terminated as follows (on of1.proof.cit.tum.de): > > Finished Lorenz_C1 (11:29:26 elapsed time, 67:46:46 cpu time, factor 5.90) > > That is something to be investigated. Either there is something odd in the > machine configuration, or this bulky test now takes much longer than in 2017. I now recall, that "slow" and "very_slow" tests are traditionally understood in the context of ML_system_64 = true, and that the Lorenz computations were slow in the default 64_32 model. So everything looks like it has always been since 2017. Makarius From fabian.immler at gmail.com Thu Feb 29 16:23:21 2024 From: fabian.immler at gmail.com (Fabian Immler) Date: Thu, 29 Feb 2024 16:23:21 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: On Thu, Feb 29, 2024 at 10:39 Makarius wrote: > So what is the reasoning behind the change ddf90847bfa5? The log does not > say > anything tangible. You are right, unfortunately that ended up as a „parrot“ commit message. > > Of course it is better to check things formally, instead of having them > commented-out. That is the motovation for the change: it is better to check things formally. Talking to Fabian Huch, I got the impression that now there are more compute resources than five or six years ago. So far, I thought that Lorenz_C0 was there to be tested > properly, and Lorenz_C1 an untested add-on example that is unlikely to > fail on > its own account. Mathematically, Lorenz_C0 is of not much value. Lorenz_C1 is a formal proof for the computational part of Tucker‘s proof of Smale‘s 14th problem. So Lorenz_C1 is of actual value and worth testing „regularly“. „Regularly“ could also be weekly, monthly, or even just once for every Isabelle release. It probably makes sense to reflect that in a new session group „very_very_slow“ or the like. On Thu, Feb 29, 2024 at 11:55 Makarius wrote: On 29/02/2024 11:33, Fabian Huch wrote: > I heard from Fabian that nowadays the session runs reasonably fast (6 hrs -- > Flyspec-Tame-computation is nearly 5 hrs). But this does not seem to fit with > your results. On which hardware precisely? That must have been an Apple M1 Pro, and I believe the run time was about 6-7 hrs, but I did not measure it exactly. But as I said, Lorenz_C1 does not need to run on a daily basis, so it also does not need to run on the latest hardware. Fabian (Immler) -------------- next part -------------- An HTML attachment was scrubbed... URL: From makarius at sketis.net Thu Feb 29 17:30:04 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 17:30:04 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> Message-ID: <2feb1530-ef9e-4288-909f-09d0947eb3e2@sketis.net> On 29/02/2024 16:23, Fabian Immler wrote: > > Of course it is better to check things formally, instead of having them > commented-out. > > That is the motovation for the change: it is better to check things formally. > Talking to Fabian Huch, I got the impression that now there are more compute > resources than five or six years ago. There are indeed a few more hardware resources, and hopefully more to come very soon, but right now the production test environment is rather underpowered. I am speaking here of the official isabelle_cronjob nightly build with repeatable performance measurements. Although many people don't know about that, it is the main way to oversee Isabelle/AFP resource requirements. If that does not work properly, we are "flying blind" --- we used to do that over several years around 2015 +/-. That build environment defines what can be active as "slow" or "very_slow". Starting with April 2024 there will be a new situation, hopefully with some new hardware somewhere. That is necessary, because the LRZ will shut down its experimental free-as-in-beer Linux cluster. I do hope that within a few weeks there will be regular AFP tests on good hardware. Here is an example timing on the super high-end consumer hardware organized by Fabian Huch: AFP/ddf90847bfa5 Host of1.proof.cit.tum.de ML_PLATFORM="x86_64-linux" ML_HOME="/u/home/wenzelm/.isabelle/contrib/polyml-5.9.1/x86_64-linux" ML_SYSTEM="polyml-5.9.1" ML_OPTIONS="--minheap 1500" threads=8 Finished HOL (0:01:58 elapsed time, 0:06:19 cpu time, factor 3.21) Finished HOL-Analysis (0:04:03 elapsed time, 0:19:05 cpu time, factor 4.70) Finished Ordinary_Differential_Equations (0:01:02 elapsed time, 0:03:43 cpu time, factor 3.59) Finished Lorenz_C0 (0:05:06 elapsed time, 0:29:38 cpu time, factor 5.80) Finished Lorenz_C1 (3:17:28 elapsed time, 19:25:10 cpu time, factor 5.90) 3:34:09 elapsed time, 21:06:14 cpu time, factor 5.91 Not bad. But also note that ARM is much slower: the analogous test on Mac Studio M1 from some hours ago is still running, here are some results so far: Finished HOL (0:02:08 elapsed time, 0:07:09 cpu time, factor 3.33) Finished HOL-Analysis (0:04:34 elapsed time, 0:21:46 cpu time, factor 4.77) Finished Ordinary_Differential_Equations (0:01:06 elapsed time, 0:04:11 cpu time, factor 3.81) Finished Lorenz_C0 (0:17:58 elapsed time, 1:45:23 cpu time, factor 5.86) > So far, I thought that Lorenz_C0 was there to be tested > properly, and Lorenz_C1 an untested add-on example that is unlikely to > fail on > its own account. > > Mathematically, Lorenz_C0 is of not much value. Lorenz_C1 is a formal proof > for the computational part of Tucker‘s proof of Smale‘s 14th problem. So > Lorenz_C1 is of actual value and worth testing „regularly“. > > „Regularly“ could also be weekly, monthly, or even just once for every > Isabelle release. It probably makes sense to reflect that in a new session > group „very_very_slow“ or the like. OK, lets see what will emerge rather soon. Right now Lorenz_C1 needs to remain inactive to avoid bombing the isabelle_cronjob AFP test: Today it actually failed due to file-system shortage, so it did not bump into the next day. Makarius From makarius at sketis.net Thu Feb 29 23:11:27 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 23:11:27 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> <2A5A3BAD-F89A-4B20-B8B7-6149F65CB508@ifi.lmu.de> <5554748f-a468-443d-ae93-0a3bd249a7e4@sketis.net> Message-ID: <073043b0-8d6e-4667-92f5-55eea5970a21@sketis.net> On 19/02/2024 12:50, Jasmin Blanchette wrote: > > I'm very satisfied with cvc5. I ran an evaluation on hundreds of goals from > the AFP and the success rate went up from 52% for CVC4 to 64% for cvc5. >> Apart from that, are you satisfied with cvc5-1.1.1? Does everything work >> with the current Intel setup? >> >> If so, I will see how to change our process wrappers such that everything >> works again on all platforms. OK, so here is the cvc5-1.1.1 component for further testing: https://isabelle-dev.sketis.net/rISABELLEf8fb4384180e I only made some basic tests with sledgehammer in src/HOL/Metis_Examples/Big_O.thy --- it looks fine so far on all platforms. Note that arm64-linux is still missing from https://github.com/cvc5/cvc5/releases/tag/cvc5-1.1.1 They claim that ARM64 is supported via cross compilation here: https://github.com/cvc5/cvc5/blob/main/INSTALL.rst --- but they don't provide binaries for download. Maybe you can motivate the cvc5 guys to complete their set of downloads --- to avoid "debianization" of this otherwise great tool --- meaning bad builds that appear to work superficially. Makarius From makarius at sketis.net Thu Feb 29 23:23:24 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 23:23:24 +0100 Subject: [isabelle-dev] Proven support for Linux ARM64 In-Reply-To: <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> References: <1f678ce4-cd48-4316-aa42-ef3d07a622a0@sketis.net> <1AC0C7D1-1D34-4524-9F71-B1E9DA67DC03@ifi.lmu.de> Message-ID: <8cd747e4-1a19-46a5-be79-db092c91fef6@sketis.net> On 15/02/2024 14:50, Jasmin Blanchette wrote: > > Concerning cvc5: I tried downloading and running cvc5 1.1.1 for arm64 from > > https://github.com/cvc5/cvc5/releases/ > > and I still get errors in Isabelle. For example, adding the line > >     sledgehammer[cvc5, mepo, slices=4] > > before line 318 of the file "$AFP/thys/Given_Clause_Loops/DISCOUNT_Loop.thy" > produces this output (nondeterministically): > /tmp/isabelle-jasminblanchette/bash_script1894380443147744112: line 1: 30873 > Abort trap: 6 > > I don't know what the "Abort trap" warnings mean, because the prover seems to > succeed nevertheless. I need to investigate. But I don't get these errors with > CVC4. Now I've found the problem report, that I was looking for, but too late: The cvc5 distribution of Isabelle/f8fb4384180e has the same problem (it uses the "static" versions). I've also updated all bash_process executables already in a861b0df74b4, now with native arm64-darwin. This does not help here. Makarius From makarius at sketis.net Thu Feb 29 23:36:01 2024 From: makarius at sketis.net (Makarius) Date: Thu, 29 Feb 2024 23:36:01 +0100 Subject: [isabelle-dev] AFP: "enable proof in session Lorenz_C1"^ In-Reply-To: <2feb1530-ef9e-4288-909f-09d0947eb3e2@sketis.net> References: <4e57f247-85df-4fb0-8ff8-8ecc4cb31c7b@sketis.net> <2feb1530-ef9e-4288-909f-09d0947eb3e2@sketis.net> Message-ID: <15bb9976-cfe8-4561-94a8-c45444c22606@sketis.net> On 29/02/2024 17:30, Makarius wrote: > > note that ARM is much slower: the analogous test on Mac > Studio M1 from some hours ago is still running, here are some results so far: > >       Finished HOL (0:02:08 elapsed time, 0:07:09 cpu time, factor 3.33) >       Finished HOL-Analysis (0:04:34 elapsed time, 0:21:46 cpu time, factor > 4.77) >       Finished Ordinary_Differential_Equations (0:01:06 elapsed time, 0:04:11 > cpu time, factor 3.81) >       Finished Lorenz_C0 (0:17:58 elapsed time, 1:45:23 cpu time, factor 5.86) I've now killed that test after it had accumulated > 60h CPU time without terminating. See further AFP/fd41e17fc7bd, where we are back to sanity for now. Makarius