diff --git a/Admin/components/components.sha1 b/Admin/components/components.sha1 --- a/Admin/components/components.sha1 +++ b/Admin/components/components.sha1 @@ -1,478 +1,479 @@ 59a71e08c34ff01f3f5c4af00db5e16369527eb7 Haskabelle-2013.tar.gz 23a96ff4951d72f4024b6e8843262eda988bc151 Haskabelle-2014.tar.gz eccff31931fb128c1dd522cfc85495c9b66e67af Haskabelle-2015.tar.gz ed740867925dcf58692c8d3e350c28e3b4d4a60f Isabelle_app-20210126.tar.gz 8ee375cfc38972f080dbc78f07b68dac03efe968 ProofGeneral-3.7.1.1.tar.gz 847b52c0676b5eb0fbf0476f64fc08c2d72afd0c ProofGeneral-4.1.tar.gz 8e0b2b432755ef11d964e20637d1bc567d1c0477 ProofGeneral-4.2-1.tar.gz 51e1e0f399e934020565b2301358452c0bcc8a5e ProofGeneral-4.2-2.tar.gz 8472221c876a430cde325841ce52893328302712 ProofGeneral-4.2.tar.gz +ce750fb7f26f6f51c03c6e78096a57b8eaf11d21 apache-commons-20211211.tar.gz fbe83b522cb37748ac1b3c943ad71704fdde2f82 bash_process-1.1.1.tar.gz bb9ef498cd594b4289221b96146d529c899da209 bash_process-1.1.tar.gz 81250148f8b89ac3587908fb20645081d7f53207 bash_process-1.2.1.tar.gz 97b2491382130a841b3bbaebdcf8720c4d4fb227 bash_process-1.2.2.tar.gz 5c5b7c18cc1dc2a4d22b997dac196da09eaca868 bash_process-1.2.3-1.tar.gz 48b01bd9436e243ffcb7297f08b498d0c0875ed9 bash_process-1.2.3.tar.gz 11815d5f3af0de9022e903ed8702c136591f06fe bash_process-1.2.4-1.tar.gz 729486311833e4eff0fbf2d8041dddad520ca88c bash_process-1.2.4-2.tar.gz 7ae9ec8aab2d8a811842d9dc67d8bf6c179e11ee bash_process-1.2.4.tar.gz 9e21f447bfa0431ae5097301d553dd6df3c58218 bash_process-1.2.tar.gz a65ce644b6094d41e9f991ef851cf05eff5dd0a9 bib2xhtml-20171221.tar.gz 4085dd6060a32d7e0d2e3f874c463a9964fd409b bib2xhtml-20190409.tar.gz f92cff635dfba5d4d77f469307369226c868542c cakeml-2.0.tar.gz e7ffe4238b61a3c1ee87aca4421e7a612e09b836 ci-extras-1.tar.gz e880f31f59bd403fb72fcd3b5afb413c3831a21c csdp-6.1-1.tar.gz 2659100ba8e28e7cb0ecb554178ee5315d4a87f5 csdp-6.1.1.tar.gz a2bd94f4f9281dc70dfda66cf28016c2ffef7ed7 csdp-6.1.tar.gz ec17080269737e4a97b4424a379924c09b338ca2 csdp-6.2.0.tar.gz 70105fd6fbfd1a868383fc510772b95234325d31 csdp-6.x.tar.gz 2f6417b8e96a0e4e8354fe0f1a253c18fb55d9a7 cvc3-2.4.1.tar.gz d70bfbe63590153c07709dea7084fbc39c669841 cvc4-1.5-1.tar.gz 541eac340464c5d34b70bb163ae277cc8829c40f cvc4-1.5-2.tar.gz 1a44895d2a440091a15cc92d7f77a06a2e432507 cvc4-1.5-3.tar.gz c0d8d5929b00e113752d8bf5d11241cd3bccafce cvc4-1.5-4.tar.gz ffb0d4739c10eb098eb092baef13eccf94a79bad cvc4-1.5-5.tar.gz 3682476dc5e915cf260764fa5b86f1ebdab57507 cvc4-1.5.tar.gz a5e02b5e990da4275dc5d4480c3b72fc73160c28 cvc4-1.5pre-1.tar.gz 4d9658fd2688ae8ac78da8fdfcbf85960f871b71 cvc4-1.5pre-2.tar.gz b01fdb93f2dc2b8bcfd41c6091d91b37d6e240f9 cvc4-1.5pre-3.tar.gz 76ff6103b8560f0e2778bbfbdb05f5fa18f850b7 cvc4-1.5pre-4.tar.gz 03aec2ec5757301c9df149f115d1f4f1d2cafd9e cvc4-1.5pre.tar.gz e99560d0b7cb9bafde2b0ec1a3a95af315918a25 cvc4-1.8.tar.gz 842d9526f37b928cf9e22f141884365129990d63 cygwin-20130110.tar.gz cb3b0706d208f104b800267697204f6d82f7b48a cygwin-20130114.tar.gz 3b44cca04855016d5f8cfb5101b2e0579ab80197 cygwin-20130117.tar.gz 1fde9ddf0fa4f398965113d0c0c4f0e97c78d008 cygwin-20130716.tar.gz a03735a53c2963eb0b453f6a7282d3419f28bf38 cygwin-20130916.tar.gz 7470125fc46e24ee188bdaacc6d560e01b6fa839 cygwin-20140520.tar.gz db4dedae026981c5f001be283180abc1962b79ad cygwin-20140521.tar.gz acbc4bf161ad21e96ecfe506266ccdbd288f8a6f cygwin-20140530.tar.gz 3dc680d9eb85276e8c3e9f6057dad0efe2d5aa41 cygwin-20140626.tar.gz 8e562dfe57a2f894f9461f4addedb88afa108152 cygwin-20140725.tar.gz 238d8e30e8e22495b7ea3f5ec36e852e97fe8bbf cygwin-20140813.tar.gz 629b8fbe35952d1551cd2a7ff08db697f6dff870 cygwin-20141024.tar.gz ce93d0b3b2743c4f4e5bba30c2889b3b7bc22f2c cygwin-20150410.tar.gz fa712dd5ec66ad16add1779d68aa171ff5694064 cygwin-20151210.tar.gz 056b843d5a3b69ecf8a52c06f2ce6e696dd275f9 cygwin-20151221.tar.gz 44f3a530f727e43a9413226c2423c9ca3e4c0cf5 cygwin-20161002.tar.gz dd56dd16d861fc6e1a008bf5e9da6f33ed6eb820 cygwin-20161022.tar.gz d9ad7aae99d54e3b9813151712eb88a441613f04 cygwin-20161024.tar.gz f8eb6a0f722e3cfe3775d1204c5c7063ee1f008e cygwin-20170828.tar.gz c22048912b010a5a0b4f2a3eb4d318d6953761e4 cygwin-20170930.tar.gz 5a3919e665947b820fd7f57787280c7512be3782 cygwin-20180604.tar.gz 2aa049170e8088de59bd70eed8220f552093932d cygwin-20190320.tar.gz fb898e263fcf6f847d97f564fe49ea0760bb453f cygwin-20190322.tar.gz cd01fac0ab4fdb50a2bbb6416da3f15a4d540da1 cygwin-20190524.tar.gz caa616fbab14c1fce790a87db5c4758c1322cf28 cygwin-20200116.tar.gz f053a9ab01f0be9cb456560f7eff66a8e7ba2fd2 cygwin-20200323.tar.gz 0107343cd2562618629f73b2581168f0045c3234 cygwin-20201002.tar.gz a3d481401b633c0ee6abf1da07d75da94076574c cygwin-20201130.tar.gz 5b1820b87b25d8f2d237515d9854e3ce54ee331b cygwin-20211002.tar.gz 5dff30be394d88dd83ea584fa6f8063bdcdc21fd cygwin-20211004.tar.gz fffaae24da4d274d34b8dc79a76b478b87ec31dd cygwin-20211007.tar.gz 0fe549949a025d65d52d6deca30554de8fca3b6e e-1.5.tar.gz 2e293256a134eb8e5b1a283361b15eb812fbfbf1 e-1.6-1.tar.gz e1919e72416cbd7ac8de5455caba8901acc7b44d e-1.6-2.tar.gz b98a98025d1f7e560ca6864a53296137dae736b4 e-1.6.tar.gz c11b25c919e2ec44fe2b6ac2086337b456344e97 e-1.8.tar.gz a895a96ec7e6fcc275114bb9b4c92b20fac73dba e-2.0-1.tar.gz 2ebd7e3067a2cdae3cb8b073345827013978d74b e-2.0-2.tar.gz fac44556dd16f666a2c186be30aa6d8c67228bb9 e-2.0-3.tar.gz 5d36fb62912cfcff7f3b99a6266c578aafc288b7 e-2.0-4.tar.gz 3223c51c0b16fe00ced4ae903041fff858e61742 e-2.0-5.tar.gz 6b962a6b4539b7ca4199977973c61a8c98a492e8 e-2.0.tar.gz 66449a7b68b7d85a7189e10735a81069356123b6 e-2.5-1.tar.gz 813b66ca151d7a39b5cacb39ab52acabc2a54845 e-2.5.tar.gz 6e63f9f354b8c06035952845b987080699a12d55 e-2.6-1.tar.gz a3bebab5df4294dac2dd7fd2065a94df00e0b3ff e-2.6.tar.gz 6d34b18ca0aa1e10bab6413045d079188c0e2dfb exec_process-1.0.1.tar.gz 8b9bffd10e396d965e815418295f2ee2849bea75 exec_process-1.0.2.tar.gz e6aada354da11e533af2dee3dcdd96c06479b053 exec_process-1.0.3.tar.gz ae7ee5becb26512f18c609e83b34612918bae5f0 exec_process-1.0.tar.gz 7a4b46752aa60c1ee6c53a2c128dedc8255a4568 flatlaf-0.46-1.tar.gz ed5cbc216389b655dac21a19e770a02a96867b85 flatlaf-0.46.tar.gz d37b38b9a27a6541c644e22eeebe9a339282173d flatlaf-1.0-rc1.tar.gz dac46ce81cee10fb36a9d39b414dec7b7b671545 flatlaf-1.0-rc2.tar.gz d94e6da7299004890c04a7b395a3f2d381a3281e flatlaf-1.0-rc3.tar.gz 7ca3e6a8c9bd837990e64d89e7fa07a7e7cf78ff flatlaf-1.0.tar.gz 9908e5ab721f1c0035c0ab04dc7ad0bd00a8db27 flatlaf-1.2.tar.gz 9534b721b7b78344f3225067ee4df28a5440b87e flatlaf-1.6.4.tar.gz 212a0f1f867511722024cc60156fd71872a16f92 flatlaf-1.6.tar.gz f339234ec18369679be0095264e0c0af7762f351 gnu-utils-20210414.tar.gz 71259aa46134e6cf2c6473b4fc408051b3336490 gnu-utils-20211030.tar.gz 683acd94761ef460cca1a628f650355370de5afb hol-light-bundle-0.5-126.tar.gz 989234b3799fe8750f3c24825d1f717c24fb0214 idea-icons-20210508.tar.gz 20b53cfc3ffc5b15c1eabc91846915b49b4c0367 isabelle_fonts-20151021.tar.gz 736844204b2ef83974cd9f0a215738b767958c41 isabelle_fonts-20151104.tar.gz 9502c1aea938021f154adadff254c5c55da344bd isabelle_fonts-20151106.tar.gz f5c63689a394b974ac0d365debda577c6fa31c07 isabelle_fonts-20151107.tar.gz 812101680b75f7fa9ee8e138ea6314fa4824ea2d isabelle_fonts-20151229.tar.gz 2730e1475c7d655655882e75743e0b451725a274 isabelle_fonts-20151231.tar.gz 1f004a6bf20088a7e8f1b3d4153aa85de6fc1091 isabelle_fonts-20160101.tar.gz 379d51ef3b71452dac34ba905def3daa8b590f2e isabelle_fonts-20160102.tar.gz 878536aab1eaf1a52da560c20bb41ab942971fa3 isabelle_fonts-20160227.tar.gz 8ff0eedf0191d808ecc58c6b3149a4697f29ab21 isabelle_fonts-20160812-1.tar.gz 9283e3b0b4c7239f57b18e076ec8bb21021832cb isabelle_fonts-20160812.tar.gz 620cffeb125e198b91a716da116f754d6cc8174b isabelle_fonts-20160830.tar.gz b70690c85c05d0ca5bc29287abd20142f6ddcfb0 isabelle_fonts-20171222.tar.gz c17c482e411bbaf992498041a3e1dea80336aaa6 isabelle_fonts-20171230.tar.gz 3affbb306baff37c360319b21cbaa2cc96ebb282 isabelle_fonts-20180113.tar.gz bee32019e5d7cf096ef2ea1d836c732e9a7628cc isabelle_fonts-20181124.tar.gz f249bc2c85bd2af9eee509de17187a766b74ab86 isabelle_fonts-20181129.tar.gz 928b5320073d04d93bcc5bc4347b6d01632b9d45 isabelle_fonts-20190210.tar.gz dfcdf9a757b9dc36cee87f82533b43c58ba84abe isabelle_fonts-20190309.tar.gz 95e3acf038df7fdeeacd8b4769930e6f57bf3692 isabelle_fonts-20190406.tar.gz dabcf5085d67c99159007007ff0e9bf775e423d1 isabelle_fonts-20190409.tar.gz 76827987c70051719e117138858930d42041f57d isabelle_fonts-20190717.tar.gz abc8aea3ae471f9313917008ac90e5c1c99e17da isabelle_fonts-20210317.tar.gz 3ff9195aab574fc75ca3b77af0adb33f9b6d7b74 isabelle_fonts-20210318.tar.gz b166b4bd583b6442a5d75eab06f7adbb66919d6d isabelle_fonts-20210319.tar.gz 9467ad54a9ac10a6e7e8db5458d8d2a5516eba96 isabelle_fonts-20210321.tar.gz 1f7a0b9829ecac6552b21e995ad0f0ac168634f3 isabelle_fonts-20210322.tar.gz 667000ce6dd6ea3c2d11601a41c206060468807d isabelle_fonts-20211004.tar.gz 916adccd2f40c55116b68b92ce1eccb24d4dd9a2 isabelle_setup-20210630.tar.gz c611e363287fcc9bdd93c33bef85fa4e66cd3f37 isabelle_setup-20210701.tar.gz a0e7527448ef0f7ce164a38a50dc26e98de3cad6 isabelle_setup-20210709.tar.gz e413706694b0968245ee15183af2d464814ce0a4 isabelle_setup-20210711.tar.gz d2c9fd7b73457a460111edd6eb93a133272935fb isabelle_setup-20210715.tar.gz a5f478ba1088f67c2c86dc2fa7764b6d884e5ae5 isabelle_setup-20210716-1.tar.gz 79fad009cb22aa5e7cb4aed3c810ad5f61790293 isabelle_setup-20210716.tar.gz 692a39f716998e556ec9559c9ca362fc8fc9d5b6 isabelle_setup-20210717-1.tar.gz 7322d6d84d75c486a58ed36630431db4499e3232 isabelle_setup-20210717-2.tar.gz 14f8508bcae9140815bb23e430e26d2cbc504b81 isabelle_setup-20210717.tar.gz ca801d5c380ea896ee32b309ff19ae5f34538963 isabelle_setup-20210718.tar.gz ac9739e38e4fbbfce1a71a0987a57b22f83922d3 isabelle_setup-20210724-1.tar.gz 4554679cc8ea31e539655810a14d14216b383d0e isabelle_setup-20210724-2.tar.gz 127a75ae33e97480d352087fcb9b47a632d77169 isabelle_setup-20210724.tar.gz 309909ec6d43ae460338e9af54c1b2a48adcb1ec isabelle_setup-20210726.tar.gz a14ce46c62c64c3413f3cc9239242e33570d0f3d isabelle_setup-20210922.tar.gz b22066a9dcde6f813352dcf6404ac184440a22df isabelle_setup-20211109.tar.gz 0b2206f914336dec4923dd0479d8cee4b904f544 jdk-11+28.tar.gz e12574d838ed55ef2845acf1152329572ab0cc56 jdk-11.0.10+9.tar.gz 3e05213cad47dbef52804fe329395db9b4e57f39 jdk-11.0.2+9.tar.gz 06ac8993b5bebd02c70f1bd18ce13075f01115f3 jdk-11.0.3+7.tar.gz e7e3cc9b0550c1e5d71197ad8c30f92b622d7183 jdk-11.0.4+11.tar.gz 49007a84a2643a204ce4406770dfd574b97880d9 jdk-11.0.5+10.tar.gz 3c250e98eb82f98afc6744ddc9170d293f0677e1 jdk-11.0.6+10.tar.gz 76cf7a141e15db30bd975089c65c833b58092aa7 jdk-11.0.9+11.tar.gz 71d19df63816e9be1c4c5eb44aea7a44cfadb319 jdk-11.tar.gz 72455a2fdb6cced9cd563f4d5d6134f7a6c34913 jdk-15.0.1+9.tar.gz e8ae300e61b0b121018456d50010b555bc96ce10 jdk-15.0.2+7.tar.gz a426a32ad34014953c0f7d4cc6f44199572e1c38 jdk-17+35.tar.gz 85707cfe369d0d32accbe3d96a0730c87e8639b5 jdk-17.0.1+12.tar.gz 8d83e433c1419e0c0cc5fd1762903d11b4a5752c jdk-6u31.tar.gz 38d2d2a91c66714c18430e136e7e5191af3996e6 jdk-7u11.tar.gz d765bc4ad2f34d494429b2a8c1563c49db224944 jdk-7u13.tar.gz 13a265e4b706ece26fdfa6fc9f4a3dd1366016d2 jdk-7u21.tar.gz 5080274f8721a18111a7f614793afe6c88726739 jdk-7u25.tar.gz dd24d63afd6d17b29ec9cb2b2464d4ff2e02de2c jdk-7u40.tar.gz ec740ee9ffd43551ddf1e5b91641405116af6291 jdk-7u6.tar.gz 71b629b2ce83dbb69967c4785530afce1bec3809 jdk-7u60.tar.gz e119f4cbfa2a39a53b9578d165d0dc44b59527b7 jdk-7u65.tar.gz d6d1c42989433839fe64f34eb77298ef6627aed4 jdk-7u67.tar.gz b66039bc6dc2bdb2992133743005e1e4fc58ae24 jdk-7u72.tar.gz d980055694ddfae430ee001c7ee877d535e97252 jdk-7u76.tar.gz baa6de37bb6f7a104ce5fe6506bca3d2572d601a jdk-7u80.tar.gz 7d5b152ac70f720bb9e783fa45ecadcf95069584 jdk-7u9.tar.gz baf275a68d3f799a841932e4e9a95a1a604058ae jdk-8u102.tar.gz 5442f1015a0657259be0590b04572cd933431df7 jdk-8u11.tar.gz 741de6a4a805a0f9fb917d1845409e99346c2747 jdk-8u112.tar.gz ae7df8bd0c18eb40237cf54cc28933f4893b9c92 jdk-8u121.tar.gz 51531a3a0c16e180ed95cb7d2bd680c2ec0aa553 jdk-8u131.tar.gz e45edcf184f608d6f4a7b966d65a5d3289462693 jdk-8u144.tar.gz 264e806b9300a4fb3b6e15ba0e2c664d4ea698c8 jdk-8u152.tar.gz 84b04d877a2ea3a4e2082297b540e14f76722bc5 jdk-8u162.tar.gz 87303a0de3fd595aa3857c8f7cececa036d6ed18 jdk-8u172.tar.gz 9ae0338a5277d8749b4b4c7e65fc627319d98b27 jdk-8u181.tar.gz cfecb1383faaf027ffbabfcd77a0b6a6521e0969 jdk-8u20.tar.gz 44ffeeae219782d40ce6822b580e608e72fd4c76 jdk-8u31.tar.gz c95ebf7777beb3e7ef10c0cf3f734cb78f9828e4 jdk-8u5.tar.gz 4132cf52d5025bf330d53b96a5c6466fef432377 jdk-8u51.tar.gz 74df343671deba03be7caa49de217d78b693f817 jdk-8u60.tar.gz dfb087bd64c3e5da79430e0ba706b9abc559c090 jdk-8u66.tar.gz 2ac389babd15aa5ddd1a424c1509e1c459e6fbb1 jdk-8u72.tar.gz caa0cf65481b6207f66437576643f41dabae3c83 jdk-8u92.tar.gz 778fd85c827ec49d2d658a832d20e63916186b0d jedit-20210715.tar.gz beb99f2cb0bd4e595c5c597d3970c46aa21616e4 jedit-20210717.tar.gz 33dd96cd83f2c6a26c035b7a0ee57624655224c5 jedit-20210724.tar.gz 0e4fd4d66388ddc760fa5fbd8d4a9a3b77cf59c7 jedit-20210802.tar.gz 258d527819583d740a3aa52dfef630eed389f8c6 jedit-20211019.tar.gz f4f3fcbd54488297a5d2fcd23a2595912d5ba80b jedit-20211103.tar.gz 44775a22f42a9d665696bfb49e53c79371c394b0 jedit_build-20111217.tar.gz a242a688810f2bccf24587b0062ce8027bf77fa2 jedit_build-20120304.tar.gz 4c948dee53f74361c097c08f49a1a5ff9b17bd1d jedit_build-20120307.tar.gz 9c221fe71af8a063fcffcce21672a97aea0a8d5b jedit_build-20120313.tar.gz ed72630f307729df08fdedb095f0af8725f81b9c jedit_build-20120327.tar.gz 6425f622625024c1de27f3730d6811f6370a19cd jedit_build-20120414.tar.gz 7b012f725ec1cc102dc259df178d511cc7890bba jedit_build-20120813.tar.gz 8e1d36f5071e3def2cb281f7fefe9f52352cb88f jedit_build-20120903.tar.gz 8fa0c67f59beba369ab836562eed4e56382f672a jedit_build-20121201.tar.gz 06e9be2627ebb95c45a9bcfa025d2eeef086b408 jedit_build-20130104.tar.gz c85c0829b8170f25aa65ec6852f505ce2a50639b jedit_build-20130628.tar.gz 5de3e399be2507f684b49dfd13da45228214bbe4 jedit_build-20130905.tar.gz 87136818fd5528d97288f5b06bd30c787229eb0d jedit_build-20130910.tar.gz c63189cbe39eb8104235a0928f579d9523de78a9 jedit_build-20130925.tar.gz 65cc13054be20d3a60474d406797c32a976d7db7 jedit_build-20130926.tar.gz 30ca171f745adf12b65c798c660ac77f9c0f9b4b jedit_build-20131106.tar.gz 054c1300128f8abd0f46a3e92c756ccdb96ff2af jedit_build-20140405.tar.gz 4a963665537ea66c69de4d761846541ebdbf69f2 jedit_build-20140511.tar.gz a9d637a30f6a87a3583f265da51e63e3619cff52 jedit_build-20140722.tar.gz f29391c53d85715f8454e1aaa304fbccc352928f jedit_build-20141018.tar.gz d7206d4c9d14d3f4c8115422b7391ffbcc6e80b4 jedit_build-20141026.tar.gz f15d36abc1780875a46b6dbd4568e43b776d5db6 jedit_build-20141104.tar.gz 14ce124c897abfa23713928dc034d6ef0e1c5031 jedit_build-20150228.tar.gz b5f7115384c167559211768eb5fe98138864473b jedit_build-20151023.tar.gz 8ba7b6791be788f316427cdcd805daeaa6935190 jedit_build-20151124.tar.gz c70c5a6c565d435a09a8639f8afd3de360708e1c jedit_build-20160330.tar.gz d4e1496c257659cf15458d718f4663cdd95a404e jedit_build-20161024.tar.gz d806c1c26b571b5b4ef05ea11e8b9cf936518e06 jedit_build-20170319.tar.gz 7bcb202e13358dd750e964b2f747664428b5d8b3 jedit_build-20180417.tar.gz 23c8a05687d05a6937f7d600ac3aa19e3ce59c9c jedit_build-20180504.tar.gz 9c64ee0705e5284b507ca527196081979d689519 jedit_build-20181025.tar.gz cfa65bf8720b9b798ffa0986bafbc8437f44f758 jedit_build-20181026.tar.gz 847492b75b38468268f9ea424d27d53f2d95cef4 jedit_build-20181203.tar.gz 536a38ed527115b4bf2545a2137ec57b6ffad718 jedit_build-20190120.tar.gz 58b9f03e5ec0b85f8123c31f5d8092dae5803773 jedit_build-20190130.tar.gz ec0aded5f2655e2de8bc4427106729e797584f2f jedit_build-20190224.tar.gz 1e53598a02ec8d8736b15f480cbe2c84767a7827 jedit_build-20190508.tar.gz b9c6f49d3f6ebe2e85a50595ce7412d01a4314ac jedit_build-20190717.tar.gz 1c753beb93e92e95e99e8ead23a68346bd1af44a jedit_build-20200610.tar.gz 533b1ee6459f59bcbe4f09e214ad2cb990fb6952 jedit_build-20200908.tar.gz f9966b5ed26740bb5b8bddbfe947fcefaea43d4d jedit_build-20201223.tar.gz 0bdbd36eda5992396e9c6b66aa24259d4dd7559c jedit_build-20210201.tar.gz a0744f1948abdde4bfb51dd4769b619e7444baf1 jedit_build-20210510-1.tar.gz 837d6c8f72ecb21ad59a2544c69aadc9f05684c6 jedit_build-20210510.tar.gz 7bdae3d24b10261f6cb277446cf9ecab6062bd6f jedit_build-20210708.tar.gz 0bd2bc2d9a491ba5fc8dd99df27c04f11a72e8fa jfreechart-1.0.14-1.tar.gz 8122526f1fc362ddae1a328bdbc2152853186fee jfreechart-1.0.14.tar.gz d911f63a5c9b4c7335bb73f805cb1711ce017a84 jfreechart-1.5.0.tar.gz d84b7d8ef273afec55284327fca7dd20f5ecb77a jfreechart-1.5.1.tar.gz 6fa0c221ef55919b684449f0111a8112358e94ff jfreechart-1.5.3.tar.gz c8a19a36adf6cefa779d85f22ded2f4654e68ea5 jortho-1.0-1.tar.gz 2155e0bdbd29cd3d2905454de2e7203b9661d239 jortho-1.0-2.tar.gz ffe179867cf5ffaabbb6bb096db9bdc0d7110065 jortho-1.0.tar.gz 6c737137cc597fc920943783382e928ea79e3feb kodkodi-1.2.16.tar.gz afb04f4048a87bb888fe7b05b0139cb060c7925b kodkodi-1.5.2-1.tar.gz 5f95c96bb99927f3a026050f85bd056f37a9189e kodkodi-1.5.2.tar.gz 0634a946b216f7f07f1a0f7e28cf345daa28828f kodkodi-1.5.3.tar.gz 52e95b3493d71902f9df89d0bb59d0046a5f0c63 kodkodi-1.5.4-1.tar.gz 267189c637de26cf304d699cfa95389da002b250 kodkodi-1.5.4.tar.gz 3ecdade953bb455ed2907952be287d7e5cf6533b kodkodi-1.5.5.tar.gz 8aa939f5127290eb9a99952d375be9ffbf90c43b kodkodi-1.5.6-1.tar.gz 6b12bf3f40b16fae8ff22aa39171fa018d107cb3 kodkodi-1.5.6.tar.gz c8b2e632f3ab959a4e037833a45e6360c8b72a99 kodkodi-1.5.7.tar.gz 377e36efb8608e6c828c7718d890e97fde2006a4 linux_app-20131007.tar.gz 759848095e2ad506083d92b5646947e3c32f27a0 linux_app-20191223.tar.gz 1a449ce69ac874e21804595d16aaaf5a0d0d0c10 linux_app-20200110.tar.gz 0aab4f73ff7f5e36f33276547e10897e1e56fb1d macos_app-20130716.tar.gz ad5d0e640ce3609a885cecab645389a2204e03bb macos_app-20150916.tar.gz 400af57ec5cd51f96928d9de00d077524a6fe316 macos_app-20181205.tar.gz 3bc42b8e22f0be5ec5614f1914066164c83498f8 macos_app-20181208.tar.gz 5fb1a2d21b220d0e588790c0203ac87c10ed0870 minisat-2.2.1-1.tar.gz ae76bfaade3bf72ff6b2d3aafcd52fa45609fcd1 minisat-2.2.1.tar.gz eda10c62da927a842c0a8881f726eac85e1cb4f7 naproche-20210122.tar.gz edcb517b7578db4eec1b6573b624f291776e11f6 naproche-20210124.tar.gz d858eb0ede6aea6b8cc40de63bd3a17f8f9f5300 naproche-20210129.tar.gz 810ee0f35adada9bf970c33fd80b986ab2255bf3 naproche-20210201.tar.gz 37bb6d934cfaf157efcadb349a0244d145ce15b0 naproche-20211211.tar.gz d098dd0873b1720a77dc4e060267f9a6c93f341a naproche-2d99afe5c349.tar.gz 4a4e56fd03b7ba4edd38046f853873a90cf55d1a naproche-4ad61140062f.tar.gz 77252e0b40f89825b9b5935f9f0c4cd5d4e7012a naproche-6d0d76ce2f2a.tar.gz 9c02ecf93863c3289002c5e5ac45a83e2505984c naproche-755224402e36.tar.gz e1b34e8f54e7e5844873612635444fed434718a1 naproche-7d0947a91dd5.tar.gz 26df569cee9c2fd91b9ac06714afd43f3b37a1dd nunchaku-0.3.tar.gz e573f2cbb57eb7b813ed5908753cfe2cb41033ca nunchaku-0.5.tar.gz 3d7b7690dfd09e25ad56e64b519f61f06e3ab706 old_vampire-4.2.2.tar.gz fe57793aca175336deea4f5e9c0d949a197850ac opam-1.2.2.tar.gz eb499a18e7040ca0fe1ca824c9dcb2087c47c9ba opam-2.0.3-1.tar.gz 002f74c9e65e650de2638bf54d7b012b8de76c28 opam-2.0.3.tar.gz ddb3b438430d9565adbf5e3d913bd52af8337511 opam-2.0.6.tar.gz fc66802c169f44511d3be30435eb89a11e635742 opam-2.0.7.tar.gz 108e947d17e9aa6170872614492d8f647802f483 opam-2.1.0.tar.gz 1c8cb6a8f4cbeaedce2d6d1ba8fc7e2ab3663aeb polyml-5.4.1.tar.gz a3f9c159a0ee9a63b7a5d0c835ed9c2c908f8b56 polyml-5.5.0-1.tar.gz 7d604a99355efbfc1459d80db3279ffa7ade3e39 polyml-5.5.0-2.tar.gz b3d776e6744f0cd2773d467bc2cfe1de3d1ca2fd polyml-5.5.0-3.tar.gz 1812e9fa6d163f63edb93e37d1217640a166cf3e polyml-5.5.0.tar.gz 36f5b8224f484721749682a3655c796a55a2718d polyml-5.5.1-1.tar.gz 36f78f27291a9ceb13bf1120b62a45625afd44a6 polyml-5.5.1.tar.gz a588640dbf5da9ae15455b02ef709764a48637dc polyml-5.5.2-1.tar.gz 4b690390946f7bfb777b89eb16d6f08987cca12f polyml-5.5.2-2.tar.gz 5b31ad8556e41dfd6d5e85f407818be399aa3d2a polyml-5.5.2-3.tar.gz 532f6e8814752aeb406c62fabcfd2cc05f8a7ca8 polyml-5.5.2.tar.gz 1c53f699d35c0db6c7cf4ea51f2310adbd1d0dc5 polyml-5.5.3-20150820.tar.gz b4b624fb5f34d1dc814fb4fb469fafd7d7ea018a polyml-5.5.3-20150908.tar.gz b668e1f43a41608a8eb365c5e19db6c54c72748a polyml-5.5.3-20150911.tar.gz 1f5cd9b1390dab13861f90dfc06d4180cc107587 polyml-5.5.3-20150916.tar.gz f78896e588e8ebb4da57bf0c95210b0f0fa9e551 polyml-5.6-1.tar.gz 21fa0592b7dfd23269063f42604438165630c0f0 polyml-5.6-2.tar.gz 03ba81e595fa6d6df069532d67ad3195c37d9046 polyml-5.6-20151123.tar.gz 822f489c18e38ce5ef979ec21dccce4473e09be6 polyml-5.6-20151206.tar.gz bd6a448f0e0d5787747f4f30ca661f9c1868e4a7 polyml-5.6-20151223.tar.gz 5b70c12c95a90d858f90c1945011289944ea8e17 polyml-5.6-20160118.tar.gz 5b19dc93082803b82aa553a5cfb3e914606c0ffd polyml-5.6.tar.gz 80b923fca3533bf291ff9da991f2262a98b68cc4 polyml-5.7-20170217.tar.gz 381a70cecf0fdee47f6842e2bdb5107ed52adab6 polyml-5.7.1-1.tar.gz 39dac33b569ac66f76126b8f4edc6d9227bd8a63 polyml-5.7.1-2.tar.gz 0b896ccc35bd3f2541cd55e6f0ed14637ed9fc68 polyml-5.7.1-4.tar.gz 262450ac9966abebae2e1d4f9ae703cfe0f5d8d9 polyml-5.7.1-5.tar.gz 1aeb57877d694db7fe4d4395287cddf3bc77710b polyml-5.7.1-6.tar.gz e3e7e20b1e0e5d5d68df4cd4caa1e1a7410d46b6 polyml-5.7.1-7.tar.gz 1430533c09b17f8be73798a47a5f409d43a04cf4 polyml-5.7.1-8.tar.gz 171b5783b88522a35e4822b19ef8ba838c04f494 polyml-5.7.1.tar.gz 5fbcab1da2b5eb97f24da2590ece189d55b3a105 polyml-5.7.tar.gz 51e024225b460900da5279f0b91b217085f98cf9 polyml-5.8-20190220.tar.gz 20a83fa58d497b533150defe39bcd4540529b25f polyml-5.8-20190306.tar.gz 9f0e9cd10df4c3383b063eb076e8b698ca50c3d0 polyml-5.8.1-20191101.tar.gz f46deb909d645ac8c140968e4d32b5763beb9add polyml-5.8.1-20191113.tar.gz 36a40a981b57daae0463d14940a8edf6fa1af179 polyml-5.8.1-20191114.tar.gz 525b05536b08c11a1eae943fe6818a8622326084 polyml-5.8.1-20191124.tar.gz 9043828803483ca14df64488dff014ad050a6d34 polyml-5.8.1-20200228.tar.gz 1186607e2c43b77db86731f12fbedb531ca50a21 polyml-5.8.1-20200708.tar.gz 22ae16bf7850e73b903d2ca8eb506da05b441cf3 polyml-5.8.1.tar.gz cb8e85387315f62dcfc6b21ec378186e58068f76 polyml-5.8.2.tar.gz d1fd6eced69dc1df7226432fcb824568e0994ff2 polyml-5.8.tar.gz fb40145228f84513a9b083b54678a7d61b9c34c4 polyml-5.9-5d4caa8f7148.tar.gz 0f1c903b043acf7b221821d8b6374b3f943a122b polyml-5.9-610a153b941d.tar.gz 5f00a47b8f5180b33e68fcc6c343b061957a0a98 polyml-5.9-960de0cd0795.tar.gz 7056b285af67902b32f5049349a064f073f05860 polyml-5.9-cc80e2b43c38.tar.gz 0c396bd6b46ff11a2432b91aab2be0248bd9b0a4 polyml-5.9.tar.gz 49f1adfacdd6d29fa9f72035d94a31eaac411a97 polyml-test-0a6ebca445fc.tar.gz 2a8c4421e0a03c0d6ad556b3c36c34eb11568adb polyml-test-1236652ebd55.tar.gz 8e83fb5088cf265902b8da753a8eac5fe3f6a14b polyml-test-159dc81efc3b.tar.gz a0064c157a59e2706e18512a49a6dca914fa17fc polyml-test-1b2dcf8f5202.tar.gz 4e6543dbbb2b2aa402fd61428e1c045c48f18b47 polyml-test-79534495ee94.tar.gz 853ab0e9ff2b73790cc80a2d36cbff8b03e50a8e polyml-test-7a7b742897e9.tar.gz 85bfda83d138e936fdafd68ed3627b1058e5c2c3 polyml-test-7e49fce62e3d.tar.gz c629cd499a724bbe37b962f727e4ff340c50299d polyml-test-8529546198aa.tar.gz 7df4857d73dbc9edda25a6ad329e47639e70fadf polyml-test-8fda4fd22441.tar.gz 2b7c02b67feb2f44dda6938a7244f4257e7c580c polyml-test-905dae2ebfda.tar.gz 3dfdc58e5d9b28f038a725e05c9c2f2ce0bb2632 polyml-test-a3cfdf648da-1.tar.gz e2f075b0cc709f4f7f6492b725362f9010b2c6d1 polyml-test-a3cfdf648da-2.tar.gz 33568f69ce813b7405386ddbefa14ad0342bb8f0 polyml-test-a3cfdf648da.tar.gz 4bedaac4f1fb9a9199aa63695735063c47059003 polyml-test-a444f281ccec.tar.gz f3031692edcc5d8028a42861e4e40779f0f9d3e1 polyml-test-b68438d33c69.tar.gz cb2318cff6ea9293cd16a4435a4fe28ad9dbe0b8 polyml-test-cf46747fee61.tar.gz 67ffed2f98864721bdb1e87f0ef250e4c69e6160 polyml-test-d68c6736402e.tar.gz b4ceeaac47f3baae41c2491a8368b03217946166 polyml-test-e7a662f8f9c4.tar.gz 609c7d09d3ed01156ff91261e801e2403ff93729 polyml-test-e8d82343b692.tar.gz b6d87466e9b44e8ef4a2fac74c96b139080a506a polyml-test-f54aa41240d0.tar.gz d365f3fc11c2427cafc62b3c79951880a1476ebb polyml-test-f86ae3dc1686.tar.gz a619177143fea42a464f49bb864665407c07a16c polyml-test-fb4f42af00fa.tar.gz 53123dc011b2d4b4e8fe307f3c9fa355718ad01a postgresql-42.1.1.tar.gz 3a5d31377ec07a5069957f5477a4848cfc89a594 postgresql-42.1.4.tar.gz 7d6ef4320d5163ceb052eb83c1cb3968f099a422 postgresql-42.2.18.tar.gz e7cd5c7955e9eb5ce8cd07feb97230b23d2eec40 postgresql-42.2.2.tar.gz 1aaa38429dc9aa7b1095394d9a7ba3465f8d6e04 postgresql-42.2.24.tar.gz 231b33c9c3c27d47e3ba01b399103d70509e0731 postgresql-42.2.5.tar.gz 6335fbc0658e447b5b9bc48c9ad36e33a05bb72b postgresql-42.2.9.tar.gz f132329ca1045858ef456cc08b197c9eeea6881b postgresql-9.4.1212.tar.gz 0885e1f1d8feaca78d2f204b6487e6eec6dfab4b scala-2.10.0.tar.gz f7dc7a4e1aea46408fd6e44b8cfacb33af61afbc scala-2.10.1.tar.gz 207e4916336335386589c918c5e3f3dcc14698f2 scala-2.10.2.tar.gz 21c8ee274ffa471ab54d4196ecd827bf3d43e591 scala-2.10.3.tar.gz d4688ddaf83037ca43b5bf271325fc53ae70e3aa scala-2.10.4.tar.gz 44d12297a78988ffd34363535e6a8e0d94c1d8b5 scala-2.11.0.tar.gz 14f20de82b25215a5e055631fb147356400625e6 scala-2.11.1.tar.gz 4fe9590d08e55760b86755d3fab750e90ac6c380 scala-2.11.2.tar.gz 27a296495b2167148de06314ed9a942f2dbe23fe scala-2.11.4.tar.gz 4b24326541161ce65424293ca9da3e7c2c6ab452 scala-2.11.5.tar.gz e7cf20e3b27c894c6127c7a37042c1667f57385e scala-2.11.6.tar.gz 4810c1b00719115df235be1c5991aa6ea7186134 scala-2.11.7.tar.gz 3eca4b80710996fff87ed1340dcea2c5f6ebf4f7 scala-2.11.8.tar.gz 0004e53f885fb165b50c95686dec40d99ab0bdbd scala-2.12.0.tar.gz 059cbdc58d36e3ac1fffcccd9139ecd34f271882 scala-2.12.10.tar.gz 82056106aa6fd37c159ea76d16096c20a749cccd scala-2.12.11.tar.gz fe7ff585acffaad7f0dd4a1d079134d15c26ed0d scala-2.12.12.tar.gz 74a8c3dab3a25a87357996ab3e95d825dc820fd0 scala-2.12.2.tar.gz d66796a68ec3254b46b17b1f8ee5bcc56a93aacf scala-2.12.3.tar.gz 1636556167dff2c191baf502c23f12e09181ef78 scala-2.12.4.tar.gz 8171f494bba54fb0d01c887f889ab8fde7171c2a scala-2.12.5.tar.gz 54c1b06fa2c5f6c2ab3d391ef342c0532cd7f392 scala-2.12.6.tar.gz 02358f00acc138371324b6248fdb62eed791c6bd scala-2.12.7.tar.gz 201c05ae9cc382ee6c08af49430e426f6bbe0d5a scala-2.12.8.tar.gz a0622fe75c3482ba7dc3ce74d58583b648a1ff0d scala-2.13.4-1.tar.gz ec53cce3c5edda1145ec5d13924a5f9418995c15 scala-2.13.4.tar.gz f51981baf34c020ad103b262f81796c37abcaa4a scala-2.13.5.tar.gz 0a7cab09dec357dab7819273f2542ff1c3ea0968 scala-2.13.6.tar.gz 1f8532dba290c6b2ef364632f3f92e71da93baba scala-2.13.7.tar.gz b447017e81600cc5e30dd61b5d4962f6da01aa80 scala-2.8.1.final.tar.gz 5659440f6b86db29f0c9c0de7249b7e24a647126 scala-2.9.2.tar.gz abe7a3b50da529d557a478e9f631a22429418a67 smbc-0.4.1.tar.gz cbd491c0feba1d21019d05564e76dd04f592ccb4 spass-3.8ds-1.tar.gz edaa1268d82203067657aabcf0371ce7d4b579b9 spass-3.8ds-2.tar.gz 43b5afbcad575ab6817d2289756ca22fd2ef43a9 spass-3.8ds.tar.gz b016a785f1f78855c00d351ff598355c3b87450f sqlite-jdbc-3.18.0-1.tar.gz b85b5bc071a59ef2a8326ceb1617d5a9a5be41cf sqlite-jdbc-3.18.0.tar.gz e56117a67ab01fb24c7fc054ede3160cefdac5f8 sqlite-jdbc-3.20.0.tar.gz 27aeac6a91353d69f0438837798ac4ae6f9ff8c5 sqlite-jdbc-3.23.1.tar.gz 4d17611857fa3a93944c1f159c0fd2a161967aaf sqlite-jdbc-3.27.2.1.tar.gz 806be457eb79408fcc5a72aeca3f64b2d89a6b63 sqlite-jdbc-3.30.1.tar.gz cba2b194114216b226d75d49a70d1bd12b141ac8 sqlite-jdbc-3.32.3.2.tar.gz 29306acd6ce9f4c87032b2c271c6df035fe7d4d3 sqlite-jdbc-3.34.0.tar.gz 8a2ca4d02cfedbfe4dad4490f1ed3ddba33a009a sqlite-jdbc-3.36.0.3.tar.gz 8d20968603f45a2c640081df1ace6a8b0527452a sqlite-jdbc-3.8.11.2.tar.gz 2369f06e8d095f9ba26df938b1a96000e535afff ssh-java-20161009.tar.gz a2335d28b5b95d8d26500a53f1a9303fc5beaf36 ssh-java-20190323.tar.gz fdc415284e031ee3eb2f65828cbc6945736fe995 stack-1.9.1.tar.gz 6e19948ff4a821e2052fc9b3ddd9ae343f4fcdbb stack-1.9.3.tar.gz f969443705aa8619e93af5b34ea98d15cd7efaf1 stack-2.1.3.tar.gz ebd0221d038966aa8bde075f1b0189ff867b02ca stack-2.5.1.tar.gz fa2d882ec45cbc8c7d2f3838b705a8316696dc66 stack-2.7.3.tar.gz 1f4a2053cc1f34fa36c4d9d2ac906ad4ebc863fd sumatra_pdf-2.1.1.tar.gz 601e08d048d8e50b0729429c8928b667d9b6bde9 sumatra_pdf-2.3.2.tar.gz 14d46c2eb1a34821703da59d543433f581e91df3 sumatra_pdf-2.4.tar.gz 44d67b6742919ce59a42368fc60e2afa210a3e42 sumatra_pdf-2.5.2.tar.gz 89719a13bc92810730a430973684629426ed1b2a sumatra_pdf-3.0.tar.gz f5afcc82f8e734665d38867e99475d3ad0d5ed15 sumatra_pdf-3.1.1.tar.gz a45eca5c1277f42f87bb8dc12a3074ccf5488221 sumatra_pdf-3.1.2-1.tar.gz 3b3239b2e6f8062b90d819f3703e30a50f4fa1e7 sumatra_pdf-3.1.2-2.tar.gz 8486387f61557147ec06b1f637117c017c8f0528 sumatra_pdf-3.1.2.tar.gz e8648878f908e93d64a393231ab21fdac976a9c2 sumatra_pdf-3.3.3.tar.gz 869ea6d8ea35c8ba68d7fcb028f16b2b7064c5fd vampire-1.0.tar.gz 399f687b56575b93e730f68c91c989cb48aa34d8 vampire-4.2.2.tar.gz 0402978ca952f08eea73e483b694928ac402a304 vampire-4.5.1-1.tar.gz 26d9d171e169c6420a08aa99eda03ef5abb9c545 vampire-4.5.1.tar.gz 4571c042efd6fc3097e105a528826959acd888a3 vampire-4.6.tar.gz 98c5c79fef7256db9f64c8feea2edef0a789ce46 verit-2016post.tar.gz 52ba18a6c96b53c5ae9b179d5a805a0c08f1da6d verit-2020.10-rmx-1.tar.gz b6706e74e20e14038e9b38f0acdb5639a134246a verit-2020.10-rmx.tar.gz d33e1e36139e86b9e9a48d8b46a6f90d7863a51c verit-2021.06-rmx-1.tar.gz c11d1120fcefaec79f099fe2be05b03cd2aed8b9 verit-2021.06-rmx.tar.gz b576fd5d89767c1067541d4839fb749c6a68d22c verit-2021.06.1-rmx.tar.gz 19c6e5677b0a26cbc5805da79d00d06a66b7a671 verit-2021.06.2-rmx.tar.gz 81d21dfd0ea5c58f375301f5166be9dbf8921a7a windows_app-20130716.tar.gz fe15e1079cf5ad86f3cbab4553722a0d20002d11 windows_app-20130905.tar.gz e6a43b7b3b21295853bd2a63b27ea20bd6102f5f windows_app-20130906.tar.gz 8fe004aead867d4c82425afac481142bd3f01fb0 windows_app-20130908.tar.gz d273abdc7387462f77a127fa43095eed78332b5c windows_app-20130909.tar.gz c368908584e2bca38b3bcb20431d0c69399fc2f0 windows_app-20131130.tar.gz c3f5285481a95fde3c1961595b4dd0311ee7ac1f windows_app-20131201.tar.gz 14807afcf69e50d49663d5b48f4b103f30ae842b windows_app-20150821.tar.gz ed106181510e825bf959025d8e0a2fc3f78e7a3f windows_app-20180417.tar.gz e809e4ab0d33cb413a7c47dd947e7dbdfcca1c24 windows_app-20181002.tar.gz 9e96ba128a0617a9020a178781df49d48c997e19 windows_app-20181006.tar.gz 1c36a840320dfa9bac8af25fc289a4df5ea3eccb xz-java-1.2-1.tar.gz 2ae13aa17d0dc95ce254a52f1dba10929763a10d xz-java-1.2.tar.gz c22196148fcace5443a933238216cff5112948df xz-java-1.5.tar.gz 4368ee09154dff42666a8c87e072261745619e51 xz-java-1.6.tar.gz 63f5fa09e92a895cb9aea27d7142abc86c487d25 xz-java-1.8.tar.gz a06875bdadd653627a68d2083c5178c1264d8fc6 xz-java-1.9.tar.gz 4530a1aa6f4498ee3d78d6000fa71a3f63bd077f yices-1.0.28.tar.gz 3a8f77822278fe9250890e357248bc678d8fac95 z3-3.2-1.tar.gz 12ae71acde43bd7bed1e005c43034b208c0cba4c z3-3.2.tar.gz d94a716502c8503d63952bcb4d4176fac8b28704 z3-4.0.tar.gz 86e721296c400ada440e4a9ce11b9e845eec9e25 z3-4.3.0.tar.gz a8917c31b31c182edeec0aaa48870844960c8a61 z3-4.3.2pre-1.tar.gz 06b30757ff23aefbc30479785c212685ffd39f4d z3-4.3.2pre.tar.gz ed37c451b9b748901295898bf713b24d22cc8c17 z3-4.4.0_4.4.1.tar.gz 93e7e4bddc6afcf87fe2b6656cfcb1b1acd0a4f8 z3-4.4.0pre-1.tar.gz b1bc411c2083fc01577070b56b94514676f53854 z3-4.4.0pre-2.tar.gz 4c366ab255d2e9343fb635d44d4d55ddd24c76d0 z3-4.4.0pre-3.tar.gz 517ba7b94c1985416c5b411c8ae84456367eb231 z3-4.4.0pre.tar.gz 6e5d7a65757cac970eb5ad28cd62130c99f42c23 z3-4.4.1.tar.gz aa20745f0b03e606b1a4149598e0c7572b63c657 z3-4.8.3.tar.gz 9dfeb39c87393af7b6a34118507637aa53aca05e zipperposition-2.0-1.tar.gz b884c60653002a7811e3b652ae0515e825d98667 zipperposition-2.0.tar.gz b129ec4f8a4474953ec107536298ee08a01fbebc zipperposition-2.1-1.tar.gz 5f53a77efb5cbe9d0c95d74a1588cc923bd711a7 zipperposition-2.1.tar.gz diff --git a/Admin/components/main b/Admin/components/main --- a/Admin/components/main +++ b/Admin/components/main @@ -1,32 +1,33 @@ #main components for repository clones or release bundles gnu-utils-20211030 +apache-commons-20211211 bash_process-1.2.4-2 bib2xhtml-20190409 csdp-6.1.1 cvc4-1.8 e-2.6-1 flatlaf-1.6.4 idea-icons-20210508 isabelle_fonts-20211004 isabelle_setup-20211109 jdk-17.0.1+12 jedit-20211103 jfreechart-1.5.3 jortho-1.0-2 kodkodi-1.5.7 minisat-2.2.1-1 nunchaku-0.5 opam-2.0.7 polyml-5.9 postgresql-42.2.24 scala-2.13.5 smbc-0.4.1 spass-3.8ds-2 sqlite-jdbc-3.36.0.3 ssh-java-20190323 stack-2.7.3 vampire-4.6 verit-2021.06.2-rmx xz-java-1.9 z3-4.4.0_4.4.1 zipperposition-2.1-1 diff --git a/src/Doc/JEdit/JEdit.thy b/src/Doc/JEdit/JEdit.thy --- a/src/Doc/JEdit/JEdit.thy +++ b/src/Doc/JEdit/JEdit.thy @@ -1,2244 +1,2244 @@ (*:maxLineLen=78:*) theory JEdit imports Base begin chapter \Introduction\ section \Concepts and terminology\ text \ Isabelle/jEdit is a Prover IDE that integrates \<^emph>\parallel proof checking\ @{cite "Wenzel:2009" and "Wenzel:2013:ITP"} with \<^emph>\asynchronous user interaction\ @{cite "Wenzel:2010" and "Wenzel:2012:UITP-EPTCS" and "Wenzel:2014:ITP-PIDE" and "Wenzel:2014:UITP"}, based on a document-oriented approach to \<^emph>\continuous proof processing\ @{cite "Wenzel:2011:CICM" and "Wenzel:2012" and "Wenzel:2018:FIDE" and "Wenzel:2019:MKM"}. Many concepts and system components are fit together in order to make this work. The main building blocks are as follows. \<^descr>[Isabelle/ML] is the implementation and extension language of Isabelle, see also @{cite "isabelle-implementation"}. It is integrated into the logical context of Isabelle/Isar and allows to manipulate logical entities directly. Arbitrary add-on tools may be implemented for object-logics such as Isabelle/HOL. \<^descr>[Isabelle/Scala] is the system programming language of Isabelle. It extends the pure logical environment of Isabelle/ML towards the outer world of graphical user interfaces, text editors, IDE frameworks, web services, SSH servers, SQL databases etc. Special infrastructure allows to transfer algebraic datatypes and formatted text easily between ML and Scala, using asynchronous protocol commands. \<^descr>[PIDE] is a general framework for Prover IDEs based on Isabelle/Scala. It is built around a concept of parallel and asynchronous document processing, which is supported natively by the parallel proof engine that is implemented in Isabelle/ML. The traditional prover command loop is given up; instead there is direct support for editing of source text, with rich formal markup for GUI rendering. \<^descr>[jEdit] is a sophisticated text editor\<^footnote>\\<^url>\http://www.jedit.org\\ implemented in Java\<^footnote>\\<^url>\https://adoptopenjdk.net\\. It is easily extensible by plugins written in any language that works on the JVM. In the context of Isabelle this is always Scala\<^footnote>\\<^url>\https://www.scala-lang.org\\. \<^descr>[Isabelle/jEdit] is the main application of the PIDE framework and the default user-interface for Isabelle. It targets both beginners and experts. Technically, Isabelle/jEdit consists of the original jEdit code base with minimal patches and a special plugin for Isabelle. This is integrated as a desktop application for the main operating system families: Linux, Windows, macOS. End-users of Isabelle download and run a standalone application that exposes jEdit as a text editor on the surface. Thus there is occasionally a tendency to apply the name ``jEdit'' to any of the Isabelle Prover IDE aspects, without proper differentiation. When discussing these PIDE building blocks in public forums, mailing lists, or even scientific publications, it is particularly important to distinguish Isabelle/ML versus Standard ML, Isabelle/Scala versus Scala, Isabelle/jEdit versus jEdit. \ section \The Isabelle/jEdit Prover IDE\ text \ \begin{figure}[!htb] \begin{center} \includegraphics[width=\textwidth]{isabelle-jedit} \end{center} \caption{The Isabelle/jEdit Prover IDE} \label{fig:isabelle-jedit} \end{figure} Isabelle/jEdit (\figref{fig:isabelle-jedit}) consists of some plugins for the jEdit text editor, while preserving its overall look-and-feel. The main plugin is called ``Isabelle'' and has its own menu \<^emph>\Plugins~/ Isabelle\ with access to several actions and add-on panels (see also \secref{sec:dockables}), as well as \<^emph>\Plugins~/ Plugin Options~/ Isabelle\ (see also \secref{sec:options}). The options allow to specify a logic session name, but the same selector is also accessible in the \<^emph>\Theories\ panel (\secref{sec:theories}). After startup of the Isabelle plugin, the selected logic session image is provided automatically by the Isabelle build tool @{cite "isabelle-system"}: if it is absent or outdated wrt.\ its sources, the build process updates it within the running text editor. Prover IDE functionality is fully activated after successful termination of the build process. A failure may require changing some options and restart of the Isabelle plugin or application. Changing the logic session requires a restart of the whole application to take effect. \<^medskip> The main job of the Prover IDE is to manage sources and their changes, taking the logical structure as a formal document into account (see also \secref{sec:document-model}). The editor and the prover are connected asynchronously without locking. The prover is free to organize the checking of the formal text in parallel on multiple cores, and provides feedback via markup, which is rendered in the editor via colors, boxes, squiggly underlines, hyperlinks, popup windows, icons, clickable output etc. Using the mouse together with the modifier key \<^verbatim>\CONTROL\ (Linux, Windows) or \<^verbatim>\COMMAND\ (macOS) exposes formal content via tooltips and/or hyperlinks (see also \secref{sec:tooltips-hyperlinks}). Output (in popups etc.) may be explored recursively, using the same techniques as in the editor source buffer. Thus the Prover IDE gives an impression of direct access to formal content of the prover within the editor, but in reality only certain aspects are exposed, according to the possibilities of the prover and its add-on tools. \ subsection \Documentation\ text \ The \<^emph>\Documentation\ panel of Isabelle/jEdit provides access to some example theory files and the standard Isabelle documentation. PDF files are opened by regular desktop operations of the underlying platform. The section ``Original jEdit Documentation'' contains the original \<^emph>\User's Guide\ of this sophisticated text editor. The same is accessible via the \<^verbatim>\Help\ menu or \<^verbatim>\F1\ keyboard shortcut, using the built-in HTML viewer of Java/Swing. The latter also includes \<^emph>\Frequently Asked Questions\ and documentation of individual plugins. Most of the information about jEdit is relevant for Isabelle/jEdit as well, but users need to keep in mind that defaults sometimes differ, and the official jEdit documentation does not know about the Isabelle plugin with its support for continuous checking of formal source text: jEdit is a plain text editor, but Isabelle/jEdit is a Prover IDE. \ subsection \Plugins\ text \ The \<^emph>\Plugin Manager\ of jEdit allows to augment editor functionality by JVM modules (jars) that are provided by the central plugin repository, which is accessible via various mirror sites. Connecting to the plugin server-infrastructure of the jEdit project allows to update bundled plugins or to add further functionality. This needs to be done with the usual care for such an open bazaar of contributions. Arbitrary combinations of add-on features are apt to cause problems. It is advisable to start with the default configuration of Isabelle/jEdit and develop a sense how it is meant to work, before loading too many other plugins. \<^medskip> The \<^emph>\Isabelle\ plugin is responsible for the main Prover IDE functionality of Isabelle/jEdit: it manages the prover session in the background. A few additional plugins are bundled with Isabelle/jEdit for convenience or out of necessity, notably \<^emph>\Console\ with its \<^emph>\Scala\ sub-plugin (\secref{sec:scala-console}) and \<^emph>\SideKick\ with some Isabelle-specific parsers for document tree structure (\secref{sec:sidekick}). The \<^emph>\Navigator\ plugin is particularly important for hyperlinks within the formal document-model (\secref{sec:tooltips-hyperlinks}). Further plugins (e.g.\ \<^emph>\ErrorList\, \<^emph>\Code2HTML\) are included to saturate the dependencies of bundled plugins, but have no particular use in Isabelle/jEdit. \ subsection \Options \label{sec:options}\ text \ Both jEdit and Isabelle have distinctive management of persistent options. Regular jEdit options are accessible via the dialogs \<^emph>\Utilities~/ Global Options\ or \<^emph>\Plugins~/ Plugin Options\, with a second chance to flip the two within the central options dialog. Changes are stored in \<^path>\$JEDIT_SETTINGS/properties\ and \<^path>\$JEDIT_SETTINGS/keymaps\. Isabelle system options are managed by Isabelle/Scala and changes are stored in \<^path>\$ISABELLE_HOME_USER/etc/preferences\, independently of other jEdit properties. See also @{cite "isabelle-system"}, especially the coverage of sessions and command-line tools like @{tool build} or @{tool options}. Those Isabelle options that are declared as \<^verbatim>\public\ are configurable in Isabelle/jEdit via \<^emph>\Plugin Options~/ Isabelle~/ General\. Moreover, there are various options for rendering document content, which are configurable via \<^emph>\Plugin Options~/ Isabelle~/ Rendering\. Thus \<^emph>\Plugin Options~/ Isabelle\ in jEdit provides a view on a subset of Isabelle system options. Note that some of these options affect general parameters that are relevant outside Isabelle/jEdit as well, e.g.\ @{system_option threads} or @{system_option parallel_proofs} for the Isabelle build tool @{cite "isabelle-system"}, but it is possible to use the settings variable @{setting ISABELLE_BUILD_OPTIONS} to change defaults for batch builds without affecting the Prover IDE. The jEdit action @{action_def isabelle.options} opens the options dialog for the Isabelle plugin; it can be mapped to editor GUI elements as usual. \<^medskip> Options are usually loaded on startup and saved on shutdown of Isabelle/jEdit. Editing the generated \<^path>\$JEDIT_SETTINGS/properties\ or \<^path>\$ISABELLE_HOME_USER/etc/preferences\ manually while the application is running may cause lost updates! \ subsection \Keymaps\ text \ Keyboard shortcuts are managed as a separate concept of \<^emph>\keymap\ that is configurable via \<^emph>\Global Options~/ Shortcuts\. The \<^verbatim>\imported\ keymap is derived from the initial environment of properties that is available at the first start of the editor; afterwards the keymap file takes precedence and is no longer affected by change of default properties. Users may modify their keymap later, but this can lead to conflicts with \<^verbatim>\shortcut\ properties in \<^file>\$JEDIT_HOME/properties/jEdit.props\. The action @{action_def "isabelle.keymap-merge"} helps to resolve pending Isabelle keymap changes wrt. the current jEdit keymap; non-conflicting changes are applied implicitly. This action is automatically invoked on Isabelle/jEdit startup. \ section \Command-line invocation \label{sec:command-line}\ text \ Isabelle/jEdit is normally invoked as a single-instance desktop application, based on platform-specific executables for Linux, Windows, macOS. It is also possible to invoke the Prover IDE on the command-line, with some extra options and environment settings. The command-line usage of @{tool_def jedit} is as follows: @{verbatim [display] \Usage: isabelle jedit [OPTIONS] [FILES ...] Options are: -A NAME ancestor session for option -R (default: parent) -D NAME=X set JVM system property -J OPTION add JVM runtime option (default $JEDIT_JAVA_SYSTEM_OPTIONS $JEDIT_JAVA_OPTIONS) -R NAME build image with requirements from other sessions -b build only -d DIR include session directory -f fresh build -i NAME include session in name-space of theories -j OPTION add jEdit runtime option (default $JEDIT_OPTIONS) -l NAME logic image name -m MODE add print mode for output -n no build of session image on startup -p CMD ML process command prefix (process policy) -s system build mode for session image (system_heaps=true) -u user build mode for session image (system_heaps=false) Start jEdit with Isabelle plugin setup and open FILES (default "$USER_HOME/Scratch.thy" or ":" for empty buffer).\} The \<^verbatim>\-l\ option specifies the session name of the logic image to be used for proof processing. Additional session root directories may be included via option \<^verbatim>\-d\ to augment the session name space (see also @{cite "isabelle-system"}). By default, the specified image is checked and built on demand, but option \<^verbatim>\-n\ bypasses the implicit build process for the selected session image. Options \<^verbatim>\-s\ and \<^verbatim>\-u\ override the default system option @{system_option system_heaps}: this determines where to store the session image of @{tool build}. The \<^verbatim>\-R\ option builds an auxiliary logic image with all theories from other sessions that are not already present in its parent; it also opens the session \<^verbatim>\ROOT\ entry in the editor to facilitate editing of the main session. The \<^verbatim>\-A\ option specifies and alternative ancestor session for option \<^verbatim>\-R\: this allows to restructure the hierarchy of session images on the spot. The \<^verbatim>\-i\ option includes additional sessions into the name-space of theories: multiple occurrences are possible. The \<^verbatim>\-m\ option specifies additional print modes for the prover process. Note that the system option @{system_option_ref jedit_print_mode} allows to do the same persistently (e.g.\ via the \<^emph>\Plugin Options\ dialog of Isabelle/jEdit), without requiring command-line invocation. The \<^verbatim>\-J\ and \<^verbatim>\-j\ options pass additional low-level options to the JVM or jEdit, respectively. The defaults are provided by the Isabelle settings environment @{cite "isabelle-system"}, but note that these only work for the command-line tool described here, and not the desktop application. The \<^verbatim>\-D\ option allows to define JVM system properties; this is passed directly to the underlying \<^verbatim>\java\ process. The \<^verbatim>\-b\ and \<^verbatim>\-f\ options control the self-build mechanism of Isabelle/Scala/PIDE/jEdit. This is only relevant for building from sources, the official Isabelle release already includes a pre-built version of Isabelle/jEdit. \<^bigskip> It is also possible to connect to an already running Isabelle/jEdit process via @{tool_def jedit_client}: @{verbatim [display] \Usage: isabelle jedit_client [OPTIONS] [FILES ...] Options are: -c only check presence of server -n only report server name -s NAME server name (default "Isabelle") Connect to already running Isabelle/jEdit instance and open FILES\} The \<^verbatim>\-c\ option merely checks the presence of the server, producing a process return-code. The \<^verbatim>\-n\ option reports the server name, and the \<^verbatim>\-s\ option provides a different server name. The default server name is the official distribution name (e.g.\ \<^verbatim>\Isabelle2021-1\). Thus @{tool jedit_client} can connect to the Isabelle desktop application without further options. The \<^verbatim>\-p\ option allows to override the implicit default of the system option @{system_option_ref ML_process_policy} for ML processes started by the Prover IDE, e.g. to control CPU affinity on multiprocessor systems. The JVM system property \<^verbatim>\isabelle.jedit_server\ provides a different server name, e.g.\ use \<^verbatim>\isabelle jedit -Disabelle.jedit_server=\\name\ and \<^verbatim>\isabelle jedit_client -s\~\name\ to connect later on. \ section \GUI rendering\ text \ Isabelle/jEdit is a classic Java/AWT/Swing application: its GUI rendering usually works well, but there are technical side-conditions on the Java window system and graphics engine. When researching problems and solutions on the Web, it often helps to include other well-known Swing applications, notably IntelliJ IDEA and Netbeans. \ subsection \Portable and scalable look-and-feel\ text \ In the past, \<^emph>\system look-and-feels\ tried hard to imitate native GUI elements on specific platforms (Windows, macOS/Aqua, Linux/GTK+), but many technical problems have accumulated in recent years (e.g.\ see \secref{sec:problems}). In 2021, we are de-facto back to \<^emph>\portable look-and-feels\, which also happen to be \emph{scalable} on high-resolution displays: \<^item> \<^verbatim>\FlatLaf Light\ is the default for Isabelle/jEdit on all platforms. It generally looks good and adapts itself pretty well to high-resolution displays. \<^item> \<^verbatim>\FlatLaf Dark\ is an alternative, but it requires further changes of editor colors by the user (or by the jEdit plugin \<^verbatim>\Editor Scheme\). Also note that Isabelle/PIDE has its own extensive set of rendering options that need to be revisited. \<^item> \<^verbatim>\Metal\ still works smoothly, although it is stylistically outdated. It can accommodate high-resolution displays via font properties (see below). Changing the look-and-feel in \<^emph>\Global Options~/ Appearance\ often updates the GUI only partially: a full restart of Isabelle/jEdit is required to see the true effect. \ subsection \Adjusting fonts\ text \ The preferred font family for Isabelle/jEdit is \<^verbatim>\Isabelle DejaVu\: it is used by default for the main text area and various GUI elements. The default font sizes attempt to deliver a usable application for common display types, such as ``Full HD'' at $1920 \times 1080$ and ``Ultra HD'' at $3840 \times 2160$. \<^medskip> Isabelle/jEdit provides various options to adjust font sizes in particular GUI elements. Here is a summary of all relevant font properties: \<^item> \<^emph>\Global Options / Text Area / Text font\: the main text area font, which is also used as reference point for various derived font sizes, e.g.\ the \<^emph>\Output\ (\secref{sec:output}) and \<^emph>\State\ (\secref{sec:state-output}) panels. \<^item> \<^emph>\Global Options / Gutter / Gutter font\: the font for the gutter area left of the main text area, e.g.\ relevant for display of line numbers (disabled by default). \<^item> \<^emph>\Global Options / Appearance / Button, menu and label font\ as well as \<^emph>\List and text field font\: this specifies the primary and secondary font for the \<^emph>\Metal\ look-and-feel. \<^item> \<^emph>\Plugin Options / Isabelle / General / Reset Font Size\: the main text area font size for action @{action_ref "isabelle.reset-font-size"}, e.g.\ relevant for quick scaling like in common web browsers. \<^item> \<^emph>\Plugin Options / Console / General / Font\: the console window font, e.g.\ relevant for Isabelle/Scala command-line. \ chapter \Augmented jEdit functionality\ section \Dockable windows \label{sec:dockables}\ text \ In jEdit terminology, a \<^emph>\view\ is an editor window with one or more \<^emph>\text areas\ that show the content of one or more \<^emph>\buffers\. A regular view may be surrounded by \<^emph>\dockable windows\ that show additional information in arbitrary format, not just text; a \<^emph>\plain view\ does not allow dockables. The \<^emph>\dockable window manager\ of jEdit organizes these dockable windows, either as \<^emph>\floating\ windows, or \<^emph>\docked\ panels within one of the four margins of the view. There may be any number of floating instances of some dockable window, but at most one docked instance; jEdit actions that address \<^emph>\the\ dockable window of a particular kind refer to the unique docked instance. Dockables are used routinely in jEdit for important functionality like \<^emph>\HyperSearch Results\ or the \<^emph>\File System Browser\. Plugins often provide a central dockable to access their main functionality, which may be opened by the user on demand. The Isabelle/jEdit plugin takes this approach to the extreme: its plugin menu provides the entry-points to many panels that are managed as dockable windows. Some important panels are docked by default, e.g.\ \<^emph>\Documentation\, \<^emph>\State\, \<^emph>\Theories\ \<^emph>\Output\, \<^emph>\Query\. The user can change this arrangement easily and persistently. Compared to plain jEdit, dockable window management in Isabelle/jEdit is slightly augmented according to the the following principles: \<^item> Floating windows are dependent on the main window as \<^emph>\dialog\ in the sense of Java/AWT/Swing. Dialog windows always stay on top of the view, which is particularly important in full-screen mode. The desktop environment of the underlying platform may impose further policies on such dependent dialogs, in contrast to fully independent windows, e.g.\ some window management functions may be missing. \<^item> Keyboard focus of the main view vs.\ a dockable window is carefully managed according to the intended semantics, as a panel mainly for output or input. For example, activating the \<^emph>\Output\ (\secref{sec:output}) or State (\secref{sec:state-output}) panel via the dockable window manager returns keyboard focus to the main text area, but for \<^emph>\Query\ (\secref{sec:query}) or \<^emph>\Sledgehammer\ \secref{sec:sledgehammer} the focus is given to the main input field of that panel. \<^item> Panels that provide their own text area for output have an additional dockable menu item \<^emph>\Detach\. This produces an independent copy of the current output as a floating \<^emph>\Info\ window, which displays that content independently of ongoing changes of the PIDE document-model. Note that Isabelle/jEdit popup windows (\secref{sec:tooltips-hyperlinks}) provide a similar \<^emph>\Detach\ operation as an icon. \ section \Isabelle symbols \label{sec:symbols}\ text \ Isabelle sources consist of \<^emph>\symbols\ that extend plain ASCII to allow infinitely many mathematical symbols within the formal sources. This works without depending on particular encodings and varying Unicode standards.\<^footnote>\Raw Unicode characters within formal sources compromise portability and reliability in the face of changing interpretation of special features of Unicode, such as Combining Characters or Bi-directional Text.\ See @{cite "Wenzel:2011:CICM"}. For the prover back-end, formal text consists of ASCII characters that are grouped according to some simple rules, e.g.\ as plain ``\<^verbatim>\a\'' or symbolic ``\<^verbatim>\\\''. For the editor front-end, a certain subset of symbols is rendered physically via Unicode glyphs, to show ``\<^verbatim>\\\'' as ``\\\'', for example. This symbol interpretation is specified by the Isabelle system distribution in \<^file>\$ISABELLE_HOME/etc/symbols\ and may be augmented by the user in \<^path>\$ISABELLE_HOME_USER/etc/symbols\. The appendix of @{cite "isabelle-isar-ref"} gives an overview of the standard interpretation of finitely many symbols from the infinite collection. Uninterpreted symbols are displayed literally, e.g.\ ``\<^verbatim>\\\''. Overlap of Unicode characters used in symbol interpretation with informal ones (which might appear e.g.\ in comments) needs to be avoided. Raw Unicode characters within prover source files should be restricted to informal parts, e.g.\ to write text in non-latin alphabets in comments. \ paragraph \Encoding.\ text \Technically, the Unicode interpretation of Isabelle symbols is an \<^emph>\encoding\ called \<^verbatim>\UTF-8-Isabelle\ in jEdit (\<^emph>\not\ in the underlying JVM). It is provided by the Isabelle Base plugin and enabled by default for all source files in Isabelle/jEdit. Sometimes such defaults are reset accidentally, or malformed UTF-8 sequences in the text force jEdit to fall back on a different encoding like \<^verbatim>\ISO-8859-15\. In that case, verbatim ``\<^verbatim>\\\'' will be shown in the text buffer instead of its Unicode rendering ``\\\''. The jEdit menu operation \<^emph>\File~/ Reload with Encoding~/ UTF-8-Isabelle\ helps to resolve such problems (after repairing malformed parts of the text). If the loaded text already contains Unicode sequences that are in conflict with the Isabelle symbol encoding, the fallback-encoding UTF-8 is used and Isabelle symbols remain in literal \<^verbatim>\\\ form. The jEdit menu operation \<^emph>\Utilities~/ Buffer Options~/ Character encoding\ allows to enforce \<^verbatim>\UTF-8-Isabelle\, but this will also change original Unicode text into Isabelle symbols when saving the file! \ paragraph \Font.\ text \Correct rendering via Unicode requires a font that contains glyphs for the corresponding codepoints. There are also various unusual symbols with particular purpose in Isabelle, e.g.\ control symbols and very long arrows. Isabelle/jEdit prefers its own font collection \<^verbatim>\Isabelle DejaVu\, with families \<^verbatim>\Serif\ (default for help texts), \<^verbatim>\Sans\ (default for GUI elements), \<^verbatim>\Mono Sans\ (default for text area). This ensures that all standard Isabelle symbols are shown on the screen (or printer) as expected. Note that a Java/AWT/Swing application can load additional fonts only if they are not installed on the operating system already! Outdated versions of Isabelle fonts that happen to be provided by the operating system prevent Isabelle/jEdit to use its bundled version. This could lead to missing glyphs (black rectangles), when the system version of a font is older than the application version. This problem can be avoided by refraining to ``install'' a copy of the Isabelle fonts in the first place, although it might be tempting to use the same font in other applications. HTML pages generated by Isabelle refer to the same Isabelle fonts as a server-side resource. Thus a web-browser can use that without requiring a locally installed copy. \ paragraph \Input methods.\ text \In principle, Isabelle/jEdit could delegate the problem to produce Isabelle symbols in their Unicode rendering to the underlying operating system and its \<^emph>\input methods\. Regular jEdit also provides various ways to work with \<^emph>\abbreviations\ to produce certain non-ASCII characters. Since none of these standard input methods work satisfactorily for the mathematical characters required for Isabelle, various specific Isabelle/jEdit mechanisms are provided. This is a summary for practically relevant input methods for Isabelle symbols. \<^enum> The \<^emph>\Symbols\ panel: some GUI buttons allow to insert certain symbols in the text buffer. There are also tooltips to reveal the official Isabelle representation with some additional information about \<^emph>\symbol abbreviations\ (see below). \<^enum> Copy/paste from decoded source files: text that is already rendered as Unicode can be re-used for other text. This also works between different applications, e.g.\ Isabelle/jEdit and some web browser or mail client, as long as the same Unicode interpretation of Isabelle symbols is used. \<^enum> Copy/paste from prover output within Isabelle/jEdit. The same principles as for text buffers apply, but note that \<^emph>\copy\ in secondary Isabelle/jEdit windows works via the keyboard shortcuts \<^verbatim>\C+c\ or \<^verbatim>\C+INSERT\, while jEdit menu actions always refer to the primary text area! \<^enum> Completion provided by the Isabelle plugin (see \secref{sec:completion}). Isabelle symbols have a canonical name and optional abbreviations. This can be used with the text completion mechanism of Isabelle/jEdit, to replace a prefix of the actual symbol like \<^verbatim>\\\, or its name preceded by backslash \<^verbatim>\\lambda\, or its ASCII abbreviation \<^verbatim>\%\ by the Unicode rendering. The following table is an extract of the information provided by the standard \<^file>\$ISABELLE_HOME/etc/symbols\ file: \<^medskip> \begin{tabular}{lll} \<^bold>\symbol\ & \<^bold>\name with backslash\ & \<^bold>\abbreviation\ \\\hline \\\ & \<^verbatim>\\lambda\ & \<^verbatim>\%\ \\ \\\ & \<^verbatim>\\Rightarrow\ & \<^verbatim>\=>\ \\ \\\ & \<^verbatim>\\Longrightarrow\ & \<^verbatim>\==>\ \\[0.5ex] \\\ & \<^verbatim>\\And\ & \<^verbatim>\!!\ \\ \\\ & \<^verbatim>\\equiv\ & \<^verbatim>\==\ \\[0.5ex] \\\ & \<^verbatim>\\forall\ & \<^verbatim>\!\ \\ \\\ & \<^verbatim>\\exists\ & \<^verbatim>\?\ \\ \\\ & \<^verbatim>\\longrightarrow\ & \<^verbatim>\-->\ \\ \\\ & \<^verbatim>\\and\ & \<^verbatim>\&\ \\ \\\ & \<^verbatim>\\or\ & \<^verbatim>\|\ \\ \\\ & \<^verbatim>\\not\ & \<^verbatim>\~\ \\ \\\ & \<^verbatim>\\noteq\ & \<^verbatim>\~=\ \\ \\\ & \<^verbatim>\\in\ & \<^verbatim>\:\ \\ \\\ & \<^verbatim>\\notin\ & \<^verbatim>\~:\ \\ \end{tabular} \<^medskip> Note that the above abbreviations refer to the input method. The logical notation provides ASCII alternatives that often coincide, but sometimes deviate. This occasionally causes user confusion with old-fashioned Isabelle source that use ASCII replacement notation like \<^verbatim>\!\ or \<^verbatim>\ALL\ directly in the text. On the other hand, coincidence of symbol abbreviations with ASCII replacement syntax syntax helps to update old theory sources via explicit completion (see also \<^verbatim>\C+b\ explained in \secref{sec:completion}). \ paragraph \Control symbols.\ text \There are some special control symbols to modify the display style of a single symbol (without nesting). Control symbols may be applied to a region of selected text, either using the \<^emph>\Symbols\ panel or keyboard shortcuts or jEdit actions. These editor operations produce a separate control symbol for each symbol in the text, in order to make the whole text appear in a certain style. \<^medskip> \begin{tabular}{llll} \<^bold>\style\ & \<^bold>\symbol\ & \<^bold>\shortcut\ & \<^bold>\action\ \\\hline superscript & \<^verbatim>\\<^sup>\ & \<^verbatim>\C+e UP\ & @{action_ref "isabelle.control-sup"} \\ subscript & \<^verbatim>\\<^sub>\ & \<^verbatim>\C+e DOWN\ & @{action_ref "isabelle.control-sub"} \\ bold face & \<^verbatim>\\<^bold>\ & \<^verbatim>\C+e RIGHT\ & @{action_ref "isabelle.control-bold"} \\ emphasized & \<^verbatim>\\<^emph>\ & \<^verbatim>\C+e LEFT\ & @{action_ref "isabelle.control-emph"} \\ reset & & \<^verbatim>\C+e BACK_SPACE\ & @{action_ref "isabelle.control-reset"} \\ \end{tabular} \<^medskip> To produce a single control symbol, it is also possible to complete on \<^verbatim>\\sup\, \<^verbatim>\\sub\, \<^verbatim>\\bold\, \<^verbatim>\\emph\ as for regular symbols. The emphasized style only takes effect in document output (when used with a cartouche), but not in the editor. \ section \Scala console \label{sec:scala-console}\ text \ The \<^emph>\Console\ plugin manages various shells (command interpreters), e.g.\ \<^emph>\BeanShell\, which is the official jEdit scripting language, and the cross-platform \<^emph>\System\ shell. Thus the console provides similar functionality than the Emacs buffers \<^verbatim>\*scratch*\ and \<^verbatim>\*shell*\. Isabelle/jEdit extends the repertoire of the console by \<^emph>\Scala\, which is the regular Scala toplevel loop running inside the same JVM process as Isabelle/jEdit itself. This means the Scala command interpreter has access to the JVM name space and state of the running Prover IDE application. The default environment imports the full content of packages \<^verbatim>\isabelle\ and \<^verbatim>\isabelle.jedit\. For example, \<^verbatim>\PIDE\ refers to the Isabelle/jEdit plugin object, and \<^verbatim>\view\ to the current editor view of jEdit. The Scala expression \<^verbatim>\PIDE.snapshot(view)\ makes a PIDE document snapshot of the current buffer within the current editor view: it allows to retrieve document markup in a timeless~/ stateless manner, while the prover continues its processing. This helps to explore Isabelle/Scala functionality interactively. Some care is required to avoid interference with the internals of the running application. \ section \Physical and logical files \label{sec:files}\ text \ File specifications in jEdit follow various formats and conventions according to \<^emph>\Virtual File Systems\, which may be also provided by plugins. This allows to access remote files via the \<^verbatim>\https:\ protocol prefix, for example. Isabelle/jEdit attempts to work with the file-system model of jEdit as far as possible. In particular, theory sources are passed from the editor to the prover, without indirection via the file-system. Thus files don't need to be saved: the editor buffer content is used directly. \ subsection \Local files and environment variables \label{sec:local-files}\ text \ Local files (without URL notation) are particularly important. The file path notation is that of the Java Virtual Machine on the underlying platform. On Windows the preferred form uses backslashes, but happens to accept forward slashes like Unix/POSIX as well. Further differences arise due to Windows drive letters and network shares: thus relative paths (with forward slashes) are portable, but absolute paths are not. File paths in Java are distinct from Isabelle; the latter uses POSIX notation with forward slashes on \<^emph>\all\ platforms. Isabelle/ML on Windows uses Unix-style path notation, with drive letters according to Cygwin (e.g.\ \<^verbatim>\/cygdrive/c\). Environment variables from the Isabelle process may be used freely, e.g.\ \<^file>\$ISABELLE_HOME/etc/symbols\ or \<^file>\$POLYML_HOME/README\. There are special shortcuts: \<^dir>\~\ for \<^dir>\$USER_HOME\ and \<^dir>\~~\ for \<^dir>\$ISABELLE_HOME\. \<^medskip> Since jEdit happens to support environment variables within file specifications as well, it is natural to use similar notation within the editor, e.g.\ in the file-browser. This does not work in full generality, though, due to the bias of jEdit towards platform-specific notation and of Isabelle towards POSIX. Moreover, the Isabelle settings environment is not accessible when starting Isabelle/jEdit via the desktop application wrapper, in contrast to @{tool jedit} run from the command line (\secref{sec:command-line}). Isabelle/jEdit imitates important system settings within the Java process environment, in order to allow easy access to these important places from the editor: \<^verbatim>\$ISABELLE_HOME\, \<^verbatim>\$ISABELLE_HOME_USER\, \<^verbatim>\$JEDIT_HOME\, \<^verbatim>\$JEDIT_SETTINGS\. The file browser of jEdit also includes \<^emph>\Favorites\ for these locations. \<^medskip> Path specifications in prover input or output usually include formal markup that turns it into a hyperlink (see also \secref{sec:tooltips-hyperlinks}). This allows to open the corresponding file in the text editor, independently of the path notation. If the path refers to a directory, it is opened in the jEdit file browser. Formally checked paths in prover input are subject to completion (\secref{sec:completion}): partial specifications are resolved via directory content and possible completions are offered in a popup. \ subsection \PIDE resources via virtual file-systems\ text \ The jEdit file browser is docked by default. It provides immediate access to the local file-system, as well as important Isabelle resources via the \<^emph>\Favorites\ menu. Environment variables like \<^verbatim>\$ISABELLE_HOME\ are discussed in \secref{sec:local-files}. Virtual file-systems are more special: the idea is to present structured information like a directory tree. The following URLs are offered in the \<^emph>\Favorites\ menu, or by corresponding jEdit actions. \<^item> URL \<^verbatim>\isabelle-export:\ or action @{action_def "isabelle-export-browser"} shows a toplevel directory with theory names: each may provide its own tree structure of session exports. Exports are like a logical file-system for the current prover session, maintained as Isabelle/Scala data structures and written to the session database eventually. The \<^verbatim>\isabelle-export:\ URL exposes the current content according to a snapshot of the document model. The file browser is \<^emph>\not\ updated continuously when the PIDE document changes: the reload operation needs to be used explicitly. A notable example for exports is the command @{command_ref export_code} @{cite "isabelle-isar-ref"}. \<^item> URL \<^verbatim>\isabelle-session:\ or action @{action_def "isabelle-session-browser"} show the structure of session chapters and sessions within them. What looks like a file-entry is actually a reference to the session definition in its corresponding \<^verbatim>\ROOT\ file. The latter is subject to Prover IDE markup, so the session theories and other files may be browsed quickly by following hyperlinks in the text. \ section \Indentation\ text \ Isabelle/jEdit augments the existing indentation facilities of jEdit to take the structure of theory and proof texts into account. There is also special support for unstructured proof scripts (\<^theory_text>\apply\ etc.). \<^descr>[Syntactic indentation] follows the outer syntax of Isabelle/Isar. Action @{action "indent-lines"} (shortcut \<^verbatim>\C+i\) indents the current line according to command keywords and some command substructure: this approximation may need further manual tuning. Action @{action "isabelle.newline"} (shortcut \<^verbatim>\ENTER\) indents the old and the new line according to command keywords only: leading to precise alignment of the main Isar language elements. This depends on option @{system_option_def "jedit_indent_newline"} (enabled by default). Regular input (via keyboard or completion) indents the current line whenever an new keyword is emerging at the start of the line. This depends on option @{system_option_def "jedit_indent_input"} (enabled by default). \<^descr>[Semantic indentation] adds additional white space to unstructured proof scripts via the number of subgoals. This requires information of ongoing document processing and may thus lag behind when the user is editing too quickly; see also option @{system_option_def "jedit_script_indent"} and @{system_option_def "jedit_script_indent_limit"}. The above options are accessible in the menu \<^emph>\Plugins / Plugin Options / Isabelle / General\. A prerequisite for advanced indentation is \<^emph>\Utilities / Buffer Options / Automatic indentation\: it needs to be set to \<^verbatim>\full\ (default). \ section \SideKick parsers \label{sec:sidekick}\ text \ The \<^emph>\SideKick\ plugin provides some general services to display buffer structure in a tree view. Isabelle/jEdit provides SideKick parsers for its main mode for theory files, ML files, as well as some minor modes for the \<^verbatim>\NEWS\ file (see \figref{fig:sidekick}), session \<^verbatim>\ROOT\ files, system \<^verbatim>\options\, and Bib{\TeX} files (\secref{sec:bibtex}). \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{sidekick} \end{center} \caption{The Isabelle NEWS file with SideKick tree view} \label{fig:sidekick} \end{figure} The default SideKick parser for theory files is \<^verbatim>\isabelle\: it provides a tree-view on the formal document structure, with section headings at the top and formal specification elements at the bottom. The alternative parser \<^verbatim>\isabelle-context\ shows nesting of context blocks according to \<^theory_text>\begin \ end\ structure. \<^medskip> Isabelle/ML files are structured according to semi-formal comments that are explained in @{cite "isabelle-implementation"}. This outline is turned into a tree-view by default, by using the \<^verbatim>\isabelle-ml\ parser. There is also a folding mode of the same name, for hierarchic text folds within ML files. \<^medskip> The special SideKick parser \<^verbatim>\isabelle-markup\ exposes the uninterpreted markup tree of the PIDE document model of the current buffer. This is occasionally useful for informative purposes, but the amount of displayed information might cause problems for large buffers. \ chapter \Prover IDE functionality \label{sec:document-model}\ section \Document model \label{sec:document-model}\ text \ The document model is central to the PIDE architecture: the editor and the prover have a common notion of structured source text with markup, which is produced by formal processing. The editor is responsible for edits of document source, as produced by the user. The prover is responsible for reports of document markup, as produced by its processing in the background. Isabelle/jEdit handles classic editor events of jEdit, in order to connect the physical world of the GUI (with its singleton state) to the mathematical world of multiple document versions (with timeless and stateless updates). \ subsection \Editor buffers and document nodes \label{sec:buffer-node}\ text \ As a regular text editor, jEdit maintains a collection of \<^emph>\buffers\ to store text files; each buffer may be associated with any number of visible \<^emph>\text areas\. Buffers are subject to an \<^emph>\edit mode\ that is determined from the file name extension. The following modes are treated specifically in Isabelle/jEdit: \<^medskip> \begin{tabular}{lll} \<^bold>\mode\ & \<^bold>\file name\ & \<^bold>\content\ \\\hline \<^verbatim>\isabelle\ & \<^verbatim>\*.thy\ & theory source \\ \<^verbatim>\isabelle-ml\ & \<^verbatim>\*.ML\ & Isabelle/ML source \\ \<^verbatim>\sml\ & \<^verbatim>\*.sml\ or \<^verbatim>\*.sig\ & Standard ML source \\ \<^verbatim>\isabelle-root\ & \<^verbatim>\ROOT\ & session root \\ \<^verbatim>\isabelle-options\ & & Isabelle options \\ \<^verbatim>\isabelle-news\ & & Isabelle NEWS \\ \end{tabular} \<^medskip> All jEdit buffers are automatically added to the PIDE document-model as \<^emph>\document nodes\. The overall document structure is defined by the theory nodes in two dimensions: \<^enum> via \<^bold>\theory imports\ that are specified in the \<^emph>\theory header\ using concrete syntax of the @{command_ref theory} command @{cite "isabelle-isar-ref"}; \<^enum> via \<^bold>\auxiliary files\ that are included into a theory by \<^emph>\load commands\, notably @{command_ref ML_file} and @{command_ref SML_file} @{cite "isabelle-isar-ref"}. In any case, source files are managed by the PIDE infrastructure: the physical file-system only plays a subordinate role. The relevant version of source text is passed directly from the editor to the prover, using internal communication channels. \ subsection \Theories \label{sec:theories}\ text \ The \<^emph>\Theories\ panel (see also \figref{fig:theories}) provides an overview of the status of continuous checking of theory nodes within the document model. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{theories} \end{center} \caption{Theories panel with an overview of the document-model, and jEdit text areas as editable views on some of the document nodes} \label{fig:theories} \end{figure} Theory imports are resolved automatically by the PIDE document model: all required files are loaded and stored internally, without the need to open corresponding jEdit buffers. Opening or closing editor buffers later on has no direct impact on the formal document content: it only affects visibility. In contrast, auxiliary files (e.g.\ from @{command ML_file} commands) are \<^emph>\not\ resolved within the editor by default, but the prover process takes care of that. This may be changed by enabling the system option @{system_option jedit_auto_resolve}: it ensures that all files are uniformly provided by the editor. \<^medskip> The visible \<^emph>\perspective\ of Isabelle/jEdit is defined by the collective view on theory buffers via open text areas. The perspective is taken as a hint for document processing: the prover ensures that those parts of a theory where the user is looking are checked, while other parts that are presently not required are ignored. The perspective is changed by opening or closing text area windows, or scrolling within a window. The \<^emph>\Theories\ panel provides some further options to influence the process of continuous checking: it may be switched off globally to restrict the prover to superficial processing of command syntax. It is also possible to indicate theory nodes as \<^emph>\required\ for continuous checking: this means such nodes and all their imports are always processed independently of the visibility status (if continuous checking is enabled). Big theory libraries that are marked as required can have significant impact on performance! The \<^emph>\Purge\ button restricts the document model to theories that are required for open editor buffers: inaccessible theories are removed and will be rechecked when opened or imported later. \<^medskip> Formal markup of checked theory content is turned into GUI rendering, based on a standard repertoire known from mainstream IDEs for programming languages: colors, icons, highlighting, squiggly underlines, tooltips, hyperlinks etc. For outer syntax of Isabelle/Isar there is some traditional syntax-highlighting via static keywords and tokenization within the editor; this buffer syntax is determined from theory imports. In contrast, the painting of inner syntax (term language etc.)\ uses semantic information that is reported dynamically from the logical context. Thus the prover can provide additional markup to help the user to understand the meaning of formal text, and to produce more text with some add-on tools (e.g.\ information messages with \<^emph>\sendback\ markup by automated provers or disprovers in the background). \ subsection \Auxiliary files \label{sec:aux-files}\ text \ Special load commands like @{command_ref ML_file} and @{command_ref SML_file} @{cite "isabelle-isar-ref"} refer to auxiliary files within some theory. Conceptually, the file argument of the command extends the theory source by the content of the file, but its editor buffer may be loaded~/ changed~/ saved separately. The PIDE document model propagates changes of auxiliary file content to the corresponding load command in the theory, to update and process it accordingly: changes of auxiliary file content are treated as changes of the corresponding load command. \<^medskip> As a concession to the massive amount of ML files in Isabelle/HOL itself, the content of auxiliary files is only added to the PIDE document-model on demand, the first time when opened explicitly in the editor. There are further tricks to manage markup of ML files, such that Isabelle/HOL may be edited conveniently in the Prover IDE on small machines with only 8\,GB of main memory. Using \<^verbatim>\Pure\ as logic session image, the exploration may start at the top \<^file>\$ISABELLE_HOME/src/HOL/Main.thy\ or the bottom \<^file>\$ISABELLE_HOME/src/HOL/HOL.thy\, for example. It is also possible to explore the Isabelle/Pure bootstrap process (a virtual copy) by opening \<^file>\$ISABELLE_HOME/src/Pure/ROOT.ML\ like a theory in the Prover IDE. Initially, before an auxiliary file is opened in the editor, the prover reads its content from the physical file-system. After the file is opened for the first time in the editor, e.g.\ by following the hyperlink (\secref{sec:tooltips-hyperlinks}) for the argument of its @{command ML_file} command, the content is taken from the jEdit buffer. The change of responsibility from prover to editor counts as an update of the document content, so subsequent theory sources need to be re-checked. When the buffer is closed, the responsibility remains to the editor: the file may be opened again without causing another document update. A file that is opened in the editor, but its theory with the load command is not, is presently inactive in the document model. A file that is loaded via multiple load commands is associated to an arbitrary one: this situation is morally unsupported and might lead to confusion. \<^medskip> Output that refers to an auxiliary file is combined with that of the corresponding load command, and shown whenever the file or the command are active (see also \secref{sec:output}). Warnings, errors, and other useful markup is attached directly to the positions in the auxiliary file buffer, in the manner of standard IDEs. By using the load command @{command SML_file} as explained in \<^file>\$ISABELLE_HOME/src/Tools/SML/Examples.thy\, Isabelle/jEdit may be used as fully-featured IDE for Standard ML, independently of theory or proof development: the required theory merely serves as some kind of project file for a collection of SML source modules. \ section \Output \label{sec:output}\ text \ Prover output consists of \<^emph>\markup\ and \<^emph>\messages\. Both are directly attached to the corresponding positions in the original source text, and visualized in the text area, e.g.\ as text colours for free and bound variables, or as squiggly underlines for warnings, errors etc.\ (see also \figref{fig:output}). In the latter case, the corresponding messages are shown by hovering with the mouse over the highlighted text --- although in many situations the user should already get some clue by looking at the position of the text highlighting, without seeing the message body itself. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{output} \end{center} \caption{Multiple views on prover output: gutter with icon, text area with popup, text overview column, \<^emph>\Theories\ panel, \<^emph>\Output\ panel} \label{fig:output} \end{figure} The ``gutter'' on the left-hand-side of the text area uses icons to provide a summary of the messages within the adjacent text line. Message priorities are used to prefer errors over warnings, warnings over information messages; other output is ignored. The ``text overview column'' on the right-hand-side of the text area uses similar information to paint small rectangles for the overall status of the whole text buffer. The graphics is scaled to fit the logical buffer length into the given window height. Mouse clicks on the overview area move the cursor approximately to the corresponding text line in the buffer. The \<^emph>\Theories\ panel provides another course-grained overview, but without direct correspondence to text positions. The coloured rectangles represent the amount of messages of a certain kind (warnings, errors, etc.) and the execution status of commands. The border of each rectangle indicates the overall status of processing: a thick border means it is \<^emph>\finished\ or \<^emph>\failed\ (with color for errors). A double-click on one of the theory entries with their status overview opens the corresponding text buffer, without moving the cursor to a specific point. \<^medskip> The \<^emph>\Output\ panel displays prover messages that correspond to a given command, within a separate window. The cursor position in the presently active text area determines the prover command whose cumulative message output is appended and shown in that window (in canonical order according to the internal execution of the command). There are also control elements to modify the update policy of the output wrt.\ continued editor movements: \<^emph>\Auto update\ and \<^emph>\Update\. This is particularly useful for multiple instances of the \<^emph>\Output\ panel to look at different situations. Alternatively, the panel can be turned into a passive \<^emph>\Info\ window via the \<^emph>\Detach\ menu item. Proof state is handled separately (\secref{sec:state-output}), but it is also possible to tick the corresponding checkbox to append it to regular output (\figref{fig:output-including-state}). This is a globally persistent option: it affects all open panels and future editor sessions. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{output-including-state} \end{center} \caption{Proof state display within the regular output panel} \label{fig:output-including-state} \end{figure} \<^medskip> Following the IDE principle, regular messages are attached to the original source in the proper place and may be inspected on demand via popups. This excludes messages that are somehow internal to the machinery of proof checking, notably \<^emph>\proof state\ and \<^emph>\tracing\. In any case, the same display technology is used for small popups and big output windows. The formal text contains markup that may be explored recursively via further popups and hyperlinks (see \secref{sec:tooltips-hyperlinks}), or clicked directly to initiate certain actions (see \secref{sec:auto-tools} and \secref{sec:sledgehammer}). \<^medskip> Alternatively, the subsequent actions (with keyboard shortcuts) allow to show tooltip messages or navigate error positions: \<^medskip> \begin{tabular}[t]{l} @{action_ref "isabelle.tooltip"} (\<^verbatim>\CS+b\) \\ @{action_ref "isabelle.message"} (\<^verbatim>\CS+m\) \\ \end{tabular}\quad \begin{tabular}[t]{l} @{action_ref "isabelle.first-error"} (\<^verbatim>\CS+a\) \\ @{action_ref "isabelle.last-error"} (\<^verbatim>\CS+z\) \\ @{action_ref "isabelle.next-error"} (\<^verbatim>\CS+n\) \\ @{action_ref "isabelle.prev-error"} (\<^verbatim>\CS+p\) \\ \end{tabular} \<^medskip> \ section \Proof state \label{sec:state-output}\ text \ The main purpose of the Prover IDE is to help the user editing proof documents, with ongoing formal checking by the prover in the background. This can be done to some extent in the main text area alone, especially for well-structured Isar proofs. Nonetheless, internal proof state needs to be inspected in many situations of exploration and ``debugging''. The \<^emph>\State\ panel shows exclusively such proof state messages without further distraction, while all other messages are displayed in \<^emph>\Output\ (\secref{sec:output}). \Figref{fig:output-and-state} shows a typical GUI layout where both panels are open. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{output-and-state} \end{center} \caption{Separate proof state display (right) and other output (bottom).} \label{fig:output-and-state} \end{figure} Another typical arrangement has more than one \<^emph>\State\ panel open (as floating windows), with \<^emph>\Auto update\ disabled to look at an old situation while the proof text in the vicinity is changed. The \<^emph>\Update\ button triggers an explicit one-shot update; this operation is also available via the action @{action "isabelle.update-state"} (keyboard shortcut \<^verbatim>\S+ENTER\). On small screens, it is occasionally useful to have all messages concatenated in the regular \<^emph>\Output\ panel, e.g.\ see \figref{fig:output-including-state}. \<^medskip> The mechanics of \<^emph>\Output\ versus \<^emph>\State\ are slightly different: \<^item> \<^emph>\Output\ shows information that is continuously produced and already present when the GUI wants to show it. This is implicitly controlled by the visible perspective on the text. \<^item> \<^emph>\State\ initiates a real-time query on demand, with a full round trip including a fresh print operation on the prover side. This is controlled explicitly when the cursor is moved to the next command (\<^emph>\Auto update\) or the \<^emph>\Update\ operation is triggered. This can make a difference in GUI responsibility and resource usage within the prover process. Applications with very big proof states that are only inspected in isolation work better with the \<^emph>\State\ panel. \ section \Query \label{sec:query}\ text \ The \<^emph>\Query\ panel provides various GUI forms to request extra information from the prover, as a replacement of old-style diagnostic commands like @{command find_theorems}. There are input fields and buttons for a particular query command, with output in a dedicated text area. The main query modes are presented as separate tabs: \<^emph>\Find Theorems\, \<^emph>\Find Constants\, \<^emph>\Print Context\, e.g.\ see \figref{fig:query}. As usual in jEdit, multiple \<^emph>\Query\ windows may be active at the same time: any number of floating instances, but at most one docked instance (which is used by default). \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{query} \end{center} \caption{An instance of the Query panel: find theorems} \label{fig:query} \end{figure} \<^medskip> The following GUI elements are common to all query modes: \<^item> The spinning wheel provides feedback about the status of a pending query wrt.\ the evaluation of its context and its own operation. \<^item> The \<^emph>\Apply\ button attaches a fresh query invocation to the current context of the command where the cursor is pointing in the text. \<^item> The \<^emph>\Search\ field allows to highlight query output according to some regular expression, in the notation that is commonly used on the Java - platform.\<^footnote>\\<^url>\https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html\\ + platform.\<^footnote>\\<^url>\https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html\\ This may serve as an additional visual filter of the result. \<^item> The \<^emph>\Zoom\ box controls the font size of the output area. All query operations are asynchronous: there is no need to wait for the evaluation of the document for the query context, nor for the query operation itself. Query output may be detached as independent \<^emph>\Info\ window, using a menu operation of the dockable window manager. The printed result usually provides sufficient clues about the original query, with some hyperlink to its context (via markup of its head line). \ subsection \Find theorems\ text \ The \<^emph>\Query\ panel in \<^emph>\Find Theorems\ mode retrieves facts from the theory or proof context matching all of given criteria in the \<^emph>\Find\ text field. A single criterion has the following syntax: \<^rail>\ ('-'?) ('name' ':' @{syntax name} | 'intro' | 'elim' | 'dest' | 'solves' | 'simp' ':' @{syntax term} | @{syntax term}) \ See also the Isar command @{command_ref find_theorems} in @{cite "isabelle-isar-ref"}. \ subsection \Find constants\ text \ The \<^emph>\Query\ panel in \<^emph>\Find Constants\ mode prints all constants whose type meets all of the given criteria in the \<^emph>\Find\ text field. A single criterion has the following syntax: \<^rail>\ ('-'?) ('name' ':' @{syntax name} | 'strict' ':' @{syntax type} | @{syntax type}) \ See also the Isar command @{command_ref find_consts} in @{cite "isabelle-isar-ref"}. \ subsection \Print context\ text \ The \<^emph>\Query\ panel in \<^emph>\Print Context\ mode prints information from the theory or proof context, or proof state. See also the Isar commands @{command_ref print_context}, @{command_ref print_cases}, @{command_ref print_term_bindings}, @{command_ref print_theorems}, described in @{cite "isabelle-isar-ref"}. \ section \Tooltips and hyperlinks \label{sec:tooltips-hyperlinks}\ text \ Formally processed text (prover input or output) contains rich markup that can be explored by using the \<^verbatim>\CONTROL\ modifier key on Linux and Windows, or \<^verbatim>\COMMAND\ on macOS. Hovering with the mouse while the modifier is pressed reveals a \<^emph>\tooltip\ (grey box over the text with a yellow popup) and/or a \<^emph>\hyperlink\ (black rectangle over the text with change of mouse pointer); see also \figref{fig:tooltip}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{popup1} \end{center} \caption{Tooltip and hyperlink for some formal entity} \label{fig:tooltip} \end{figure} Tooltip popups use the same rendering technology as the main text area, and further tooltips and/or hyperlinks may be exposed recursively by the same mechanism; see \figref{fig:nested-tooltips}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{popup2} \end{center} \caption{Nested tooltips over formal entities} \label{fig:nested-tooltips} \end{figure} The tooltip popup window provides some controls to \<^emph>\close\ or \<^emph>\detach\ the window, turning it into a separate \<^emph>\Info\ window managed by jEdit. The \<^verbatim>\ESCAPE\ key closes \<^emph>\all\ popups, which is particularly relevant when nested tooltips are stacking up. \<^medskip> A black rectangle in the text indicates a hyperlink that may be followed by a mouse click (while the \<^verbatim>\CONTROL\ or \<^verbatim>\COMMAND\ modifier key is still pressed). Such jumps to other text locations are recorded by the \<^emph>\Navigator\ plugin, which is bundled with Isabelle/jEdit and enabled by default. There are usually navigation arrows in the main jEdit toolbar. Note that the link target may be a file that is itself not subject to formal document processing of the editor session and thus prevents further exploration: the chain of hyperlinks may end in some source file of the underlying logic image, or within the ML bootstrap sources of Isabelle/Pure. \ section \Formal scopes and semantic selection\ text \ Formal entities are semantically annotated in the source text as explained in \secref{sec:tooltips-hyperlinks}. A \<^emph>\formal scope\ consists of the defining position with all its referencing positions. This correspondence is highlighted in the text according to the cursor position, see also \figref{fig:scope1}. Here the referencing positions are rendered with an additional border, in reminiscence to a hyperlink. A mouse click with \<^verbatim>\C\ modifier, or the action @{action_def "isabelle.goto-entity"} (shortcut \<^verbatim>\CS+d\) jumps to the original defining position. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{scope1} \end{center} \caption{Scope of formal entity: defining vs.\ referencing positions} \label{fig:scope1} \end{figure} The action @{action_def "isabelle.select-entity"} (shortcut \<^verbatim>\CS+ENTER\) supports semantic selection of all occurrences of the formal entity at the caret position, with a defining position in the current editor buffer. This facilitates systematic renaming, using regular jEdit editing of a multi-selection, see also \figref{fig:scope2}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{scope2} \end{center} \caption{The result of semantic selection and systematic renaming} \label{fig:scope2} \end{figure} By default, the visual feedback on scopes is restricted to definitions within the visible text area. The keyboard modifier \<^verbatim>\CS\ overrides this: then all defining and referencing positions are shown. This modifier may be configured via option @{system_option jedit_focus_modifier}; the default coincides with the modifier for the above keyboard actions. The empty string means to disable this additional visual feedback. \ section \Completion \label{sec:completion}\ text \ Smart completion of partial input is the IDE functionality \<^emph>\par excellance\. Isabelle/jEdit combines several sources of information to achieve that. Despite its complexity, it should be possible to get some idea how completion works by experimentation, based on the overview of completion varieties in \secref{sec:completion-varieties}. The remaining subsections explain concepts around completion more systematically. \<^medskip> \<^emph>\Explicit completion\ is triggered by the action @{action_ref "isabelle.complete"}, which is bound to the keyboard shortcut \<^verbatim>\C+b\, and thus overrides the jEdit default for @{action_ref "complete-word"}. \<^emph>\Implicit completion\ hooks into the regular keyboard input stream of the editor, with some event filtering and optional delays. \<^medskip> Completion options may be configured in \<^emph>\Plugin Options~/ Isabelle~/ General~/ Completion\. These are explained in further detail below, whenever relevant. There is also a summary of options in \secref{sec:completion-options}. The asynchronous nature of PIDE interaction means that information from the prover is delayed --- at least by a full round-trip of the document update protocol. The default options already take this into account, with a sufficiently long completion delay to speculate on the availability of all relevant information from the editor and the prover, before completing text immediately or producing a popup. Although there is an inherent danger of non-deterministic behaviour due to such real-time parameters, the general completion policy aims at determined results as far as possible. \ subsection \Varieties of completion \label{sec:completion-varieties}\ subsubsection \Built-in templates\ text \ Isabelle is ultimately a framework of nested sub-languages of different kinds and purposes. The completion mechanism supports this by the following built-in templates: \<^descr> \<^verbatim>\`\ (single ASCII back-quote) or \<^verbatim>\"\ (double ASCII quote) support \<^emph>\quotations\ via text cartouches. There are three selections, which are always presented in the same order and do not depend on any context information. The default choice produces a template ``\\\\\'', where the box indicates the cursor position after insertion; the other choices help to repair the block structure of unbalanced text cartouches. \<^descr> \<^verbatim>\@{\ is completed to the template ``\@{\}\'', where the box indicates the cursor position after insertion. Here it is convenient to use the wildcard ``\<^verbatim>\__\'' or a more specific name prefix to let semantic completion of name-space entries propose antiquotation names. With some practice, input of quoted sub-languages and antiquotations of embedded languages should work smoothly. Note that national keyboard layouts might cause problems with back-quote as dead key, but double quote can be used instead. \ subsubsection \Syntax keywords\ text \ Syntax completion tables are determined statically from the keywords of the ``outer syntax'' of the underlying edit mode: for theory files this is the syntax of Isar commands according to the cumulative theory imports. Keywords are usually plain words, which means the completion mechanism only inserts them directly into the text for explicit completion (\secref{sec:completion-input}), but produces a popup (\secref{sec:completion-popup}) otherwise. At the point where outer syntax keywords are defined, it is possible to specify an alternative replacement string to be inserted instead of the keyword itself. An empty string means to suppress the keyword altogether, which is occasionally useful to avoid confusion, e.g.\ the rare keyword @{command simproc_setup} vs.\ the frequent name-space entry \simp\. \ subsubsection \Isabelle symbols\ text \ The completion tables for Isabelle symbols (\secref{sec:symbols}) are determined statically from \<^file>\$ISABELLE_HOME/etc/symbols\ and \<^path>\$ISABELLE_HOME_USER/etc/symbols\ for each symbol specification as follows: \<^medskip> \begin{tabular}{ll} \<^bold>\completion entry\ & \<^bold>\example\ \\\hline literal symbol & \<^verbatim>\\\ \\ symbol name with backslash & \<^verbatim>\\\\<^verbatim>\forall\ \\ symbol abbreviation & \<^verbatim>\ALL\ or \<^verbatim>\!\ \\ \end{tabular} \<^medskip> When inserted into the text, the above examples all produce the same Unicode rendering \\\ of the underlying symbol \<^verbatim>\\\. A symbol abbreviation that is a plain word, like \<^verbatim>\ALL\, is treated like a syntax keyword. Non-word abbreviations like \<^verbatim>\-->\ are inserted more aggressively, except for single-character abbreviations like \<^verbatim>\!\ above. Completion via abbreviations like \<^verbatim>\ALL\ or \<^verbatim>\-->\ depends on the semantic language context (\secref{sec:completion-context}). In contrast, backslash sequences like \<^verbatim>\\forall\ \<^verbatim>\\\ are always possible, but require additional interaction to confirm (via popup). This is important in ambiguous situations, e.g.\ for Isabelle document source, which may contain formal symbols or informal {\LaTeX} macros. Backslash sequences also help when input is broken, and thus escapes its normal semantic context: e.g.\ antiquotations or string literals in ML, which do not allow arbitrary backslash sequences. Special symbols like \<^verbatim>\\\ or control symbols like \<^verbatim>\\<^cancel>\, \<^verbatim>\\<^latex>\, \<^verbatim>\\<^binding>\ can have an argument: completing on a name prefix offers a template with an empty cartouche. Thus completion of \<^verbatim>\\co\ or \<^verbatim>\\ca\ allows to compose formal document comments quickly.\<^footnote>\It is customary to put a space between \<^verbatim>\\\ and its argument, while control symbols do \<^emph>\not\ allow extra space here.\ \ subsubsection \User-defined abbreviations\ text \ The theory header syntax supports abbreviations via the \<^theory_text>\abbrevs\ keyword @{cite "isabelle-isar-ref"}. This is a slight generalization of built-in templates and abbreviations for Isabelle symbols, as explained above. Examples may be found in the Isabelle sources, by searching for ``\<^verbatim>\abbrevs\'' in \<^verbatim>\*.thy\ files. The \<^emph>\Symbols\ panel shows the abbreviations that are available in the current theory buffer (according to its \<^theory_text>\imports\) in the \<^verbatim>\Abbrevs\ tab. \ subsubsection \Name-space entries\ text \ This is genuine semantic completion, using information from the prover, so it requires some delay. A \<^emph>\failed name-space lookup\ produces an error message that is annotated with a list of alternative names that are legal. The list of results is truncated according to the system option @{system_option_ref completion_limit}. The completion mechanism takes this into account when collecting information on the prover side. Already recognized names are \<^emph>\not\ completed further, but completion may be extended by appending a suffix of underscores. This provokes a failed lookup, and another completion attempt (ignoring the underscores). For example, in a name space where \<^verbatim>\foo\ and \<^verbatim>\foobar\ are known, the input \<^verbatim>\foo\ remains unchanged, but \<^verbatim>\foo_\ may be completed to \<^verbatim>\foo\ or \<^verbatim>\foobar\. The special identifier ``\<^verbatim>\__\'' serves as a wild-card for arbitrary completion: it exposes the name-space content to the completion mechanism (truncated according to @{system_option completion_limit}). This is occasionally useful to explore an unknown name-space, e.g.\ in some template. \ subsubsection \File-system paths\ text \ Depending on prover markup about file-system paths in the source text, e.g.\ for the argument of a load command (\secref{sec:aux-files}), the completion mechanism explores the directory content and offers the result as completion popup. Relative path specifications are understood wrt.\ the \<^emph>\master directory\ of the document node (\secref{sec:buffer-node}) of the enclosing editor buffer; this requires a proper theory, not an auxiliary file. A suffix of slashes may be used to continue the exploration of an already recognized directory name. \ subsubsection \Spell-checking\ text \ The spell-checker combines semantic markup from the prover (regions of plain words) with static dictionaries (word lists) that are known to the editor. Unknown words are underlined in the text, using @{system_option_ref spell_checker_color} (blue by default). This is not an error, but a hint to the user that some action may be taken. The jEdit context menu provides various actions, as far as applicable: \<^medskip> \begin{tabular}{l} @{action_ref "isabelle.complete-word"} \\ @{action_ref "isabelle.exclude-word"} \\ @{action_ref "isabelle.exclude-word-permanently"} \\ @{action_ref "isabelle.include-word"} \\ @{action_ref "isabelle.include-word-permanently"} \\ \end{tabular} \<^medskip> Instead of the specific @{action_ref "isabelle.complete-word"}, it is also possible to use the generic @{action_ref "isabelle.complete"} with its default keyboard shortcut \<^verbatim>\C+b\. \<^medskip> Dictionary lookup uses some educated guesses about lower-case, upper-case, and capitalized words. This is oriented on common use in English, where this aspect is not decisive for proper spelling (in contrast to German, for example). \ subsection \Semantic completion context \label{sec:completion-context}\ text \ Completion depends on a semantic context that is provided by the prover, although with some delay, because at least a full PIDE protocol round-trip is required. Until that information becomes available in the PIDE document-model, the default context is given by the outer syntax of the editor mode (see also \secref{sec:buffer-node}). The semantic \<^emph>\language context\ provides information about nested sub-languages of Isabelle: keywords are only completed for outer syntax, and antiquotations for languages that support them. Symbol abbreviations only work for specific sub-languages: e.g.\ ``\<^verbatim>\=>\'' is \<^emph>\not\ completed in regular ML source, but is completed within ML strings, comments, antiquotations. Backslash representations of symbols like ``\<^verbatim>\\foobar\'' or ``\<^verbatim>\\\'' work in any context --- after additional confirmation. The prover may produce \<^emph>\no completion\ markup in exceptional situations, to tell that some language keywords should be excluded from further completion attempts. For example, ``\<^verbatim>\:\'' within accepted Isar syntax looses its meaning as abbreviation for symbol ``\\\''. \ subsection \Input events \label{sec:completion-input}\ text \ Completion is triggered by certain events produced by the user, with optional delay after keyboard input according to @{system_option jedit_completion_delay}. \<^descr>[Explicit completion] works via action @{action_ref "isabelle.complete"} with keyboard shortcut \<^verbatim>\C+b\. This overrides the shortcut for @{action_ref "complete-word"} in jEdit, but it is possible to restore the original jEdit keyboard mapping of @{action "complete-word"} via \<^emph>\Global Options~/ Shortcuts\ and invent a different one for @{action "isabelle.complete"}. \<^descr>[Explicit spell-checker completion] works via @{action_ref "isabelle.complete-word"}, which is exposed in the jEdit context menu, if the mouse points to a word that the spell-checker can complete. \<^descr>[Implicit completion] works via regular keyboard input of the editor. It depends on further side-conditions: \<^enum> The system option @{system_option_ref jedit_completion} needs to be enabled (default). \<^enum> Completion of syntax keywords requires at least 3 relevant characters in the text. \<^enum> The system option @{system_option_ref jedit_completion_delay} determines an additional delay (0.5 by default), before opening a completion popup. The delay gives the prover a chance to provide semantic completion information, notably the context (\secref{sec:completion-context}). \<^enum> The system option @{system_option_ref jedit_completion_immediate} (enabled by default) controls whether replacement text should be inserted immediately without popup, regardless of @{system_option jedit_completion_delay}. This aggressive mode of completion is restricted to symbol abbreviations that are not plain words (\secref{sec:symbols}). \<^enum> Completion of symbol abbreviations with only one relevant character in the text always enforces an explicit popup, regardless of @{system_option_ref jedit_completion_immediate}. \ subsection \Completion popup \label{sec:completion-popup}\ text \ A \<^emph>\completion popup\ is a minimally invasive GUI component over the text area that offers a selection of completion items to be inserted into the text, e.g.\ by mouse clicks. Items are sorted dynamically, according to the frequency of selection, with persistent history. The popup may interpret special keys \<^verbatim>\ENTER\, \<^verbatim>\TAB\, \<^verbatim>\ESCAPE\, \<^verbatim>\UP\, \<^verbatim>\DOWN\, \<^verbatim>\PAGE_UP\, \<^verbatim>\PAGE_DOWN\, but all other key events are passed to the underlying text area. This allows to ignore unwanted completions most of the time and continue typing quickly. Thus the popup serves as a mechanism of confirmation of proposed items, while the default is to continue without completion. The meaning of special keys is as follows: \<^medskip> \begin{tabular}{ll} \<^bold>\key\ & \<^bold>\action\ \\\hline \<^verbatim>\ENTER\ & select completion (if @{system_option jedit_completion_select_enter}) \\ \<^verbatim>\TAB\ & select completion (if @{system_option jedit_completion_select_tab}) \\ \<^verbatim>\ESCAPE\ & dismiss popup \\ \<^verbatim>\UP\ & move up one item \\ \<^verbatim>\DOWN\ & move down one item \\ \<^verbatim>\PAGE_UP\ & move up one page of items \\ \<^verbatim>\PAGE_DOWN\ & move down one page of items \\ \end{tabular} \<^medskip> Movement within the popup is only active for multiple items. Otherwise the corresponding key event retains its standard meaning within the underlying text area. \ subsection \Insertion \label{sec:completion-insert}\ text \ Completion may first propose replacements to be selected (via a popup), or replace text immediately in certain situations and depending on certain options like @{system_option jedit_completion_immediate}. In any case, insertion works uniformly, by imitating normal jEdit text insertion, depending on the state of the \<^emph>\text selection\. Isabelle/jEdit tries to accommodate the most common forms of advanced selections in jEdit, but not all combinations make sense. At least the following important cases are well-defined: \<^descr>[No selection.] The original is removed and the replacement inserted, depending on the caret position. \<^descr>[Rectangular selection of zero width.] This special case is treated by jEdit as ``tall caret'' and insertion of completion imitates its normal behaviour: separate copies of the replacement are inserted for each line of the selection. \<^descr>[Other rectangular selection or multiple selections.] Here the original is removed and the replacement is inserted for each line (or segment) of the selection. Support for multiple selections is particularly useful for \<^emph>\HyperSearch\: clicking on one of the items in the \<^emph>\HyperSearch Results\ window makes jEdit select all its occurrences in the corresponding line of text. Then explicit completion can be invoked via \<^verbatim>\C+b\, e.g.\ to replace occurrences of \<^verbatim>\-->\ by \\\. \<^medskip> Insertion works by removing and inserting pieces of text from the buffer. This counts as one atomic operation on the jEdit history. Thus unintended completions may be reverted by the regular @{action undo} action of jEdit. According to normal jEdit policies, the recovered text after @{action undo} is selected: \<^verbatim>\ESCAPE\ is required to reset the selection and to continue typing more text. \ subsection \Options \label{sec:completion-options}\ text \ This is a summary of Isabelle/Scala system options that are relevant for completion. They may be configured in \<^emph>\Plugin Options~/ Isabelle~/ General\ as usual. \<^item> @{system_option_def completion_limit} specifies the maximum number of items for various semantic completion operations (name-space entries etc.) \<^item> @{system_option_def jedit_completion} guards implicit completion via regular jEdit key events (\secref{sec:completion-input}): it allows to disable implicit completion altogether. \<^item> @{system_option_def jedit_completion_select_enter} and @{system_option_def jedit_completion_select_tab} enable keys to select a completion item from the popup (\secref{sec:completion-popup}). Note that a regular mouse click on the list of items is always possible. \<^item> @{system_option_def jedit_completion_context} specifies whether the language context provided by the prover should be used at all. Disabling that option makes completion less ``semantic''. Note that incomplete or severely broken input may cause some disagreement of the prover and the user about the intended language context. \<^item> @{system_option_def jedit_completion_delay} and @{system_option_def jedit_completion_immediate} determine the handling of keyboard events for implicit completion (\secref{sec:completion-input}). A @{system_option jedit_completion_delay}~\<^verbatim>\> 0\ postpones the processing of key events, until after the user has stopped typing for the given time span, but @{system_option jedit_completion_immediate}~\<^verbatim>\= true\ means that abbreviations of Isabelle symbols are handled nonetheless. \<^item> @{system_option_def completion_path_ignore} specifies ``glob'' patterns to ignore in file-system path completion (separated by colons), e.g.\ backup files ending with tilde. \<^item> @{system_option_def spell_checker} is a global guard for all spell-checker operations: it allows to disable that mechanism altogether. \<^item> @{system_option_def spell_checker_dictionary} determines the current dictionary, taken from the colon-separated list in the settings variable @{setting_def JORTHO_DICTIONARIES}. There are jEdit actions to specify local updates to a dictionary, by including or excluding words. The result of permanent dictionary updates is stored in the directory \<^path>\$ISABELLE_HOME_USER/dictionaries\, in a separate file for each dictionary. \<^item> @{system_option_def spell_checker_include} specifies a comma-separated list of markup elements that delimit words in the source that is subject to spell-checking, including various forms of comments. \<^item> @{system_option_def spell_checker_exclude} specifies a comma-separated list of markup elements that disable spell-checking (e.g.\ in nested antiquotations). \ section \Automatically tried tools \label{sec:auto-tools}\ text \ Continuous document processing works asynchronously in the background. Visible document source that has been evaluated may get augmented by additional results of \<^emph>\asynchronous print functions\. An example for that is proof state output, if that is enabled in the Output panel (\secref{sec:output}). More heavy-weight print functions may be applied as well, e.g.\ to prove or disprove parts of the formal text by other means. Isabelle/HOL provides various automatically tried tools that operate on outermost goal statements (e.g.\ @{command lemma}, @{command theorem}), independently of the state of the current proof attempt. They work implicitly without any arguments. Results are output as \<^emph>\information messages\, which are indicated in the text area by blue squiggles and a blue information sign in the gutter (see \figref{fig:auto-tools}). The message content may be shown as for other output (see also \secref{sec:output}). Some tools produce output with \<^emph>\sendback\ markup, which means that clicking on certain parts of the text inserts that into the source in the proper place. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{auto-tools} \end{center} \caption{Result of automatically tried tools} \label{fig:auto-tools} \end{figure} \<^medskip> The following Isabelle system options control the behavior of automatically tried tools (see also the jEdit dialog window \<^emph>\Plugin Options~/ Isabelle~/ General~/ Automatically tried tools\): \<^item> @{system_option_ref auto_methods} controls automatic use of a combination of standard proof methods (@{method auto}, @{method simp}, @{method blast}, etc.). This corresponds to the Isar command @{command_ref "try0"} @{cite "isabelle-isar-ref"}. The tool is disabled by default, since unparameterized invocation of standard proof methods often consumes substantial CPU resources without leading to success. \<^item> @{system_option_ref auto_nitpick} controls a slightly reduced version of @{command_ref nitpick}, which tests for counterexamples using first-order relational logic. See also the Nitpick manual @{cite "isabelle-nitpick"}. This tool is disabled by default, due to the extra overhead of invoking an external Java process for each attempt to disprove a subgoal. \<^item> @{system_option_ref auto_quickcheck} controls automatic use of @{command_ref quickcheck}, which tests for counterexamples using a series of assignments for free variables of a subgoal. This tool is \<^emph>\enabled\ by default. It requires little overhead, but is a bit weaker than @{command nitpick}. \<^item> @{system_option_ref auto_sledgehammer} controls a significantly reduced version of @{command_ref sledgehammer}, which attempts to prove a subgoal using external automatic provers. See also the Sledgehammer manual @{cite "isabelle-sledgehammer"}. This tool is disabled by default, due to the relatively heavy nature of Sledgehammer. \<^item> @{system_option_ref auto_solve_direct} controls automatic use of @{command_ref solve_direct}, which checks whether the current subgoals can be solved directly by an existing theorem. This also helps to detect duplicate lemmas. This tool is \<^emph>\enabled\ by default. Invocation of automatically tried tools is subject to some global policies of parallel execution, which may be configured as follows: \<^item> @{system_option_ref auto_time_limit} (default 2.0) determines the timeout (in seconds) for each tool execution. \<^item> @{system_option_ref auto_time_start} (default 1.0) determines the start delay (in seconds) for automatically tried tools, after the main command evaluation is finished. Each tool is submitted independently to the pool of parallel execution tasks in Isabelle/ML, using hardwired priorities according to its relative ``heaviness''. The main stages of evaluation and printing of proof states take precedence, but an already running tool is not canceled and may thus reduce reactivity of proof document processing. Users should experiment how the available CPU resources (number of cores) are best invested to get additional feedback from prover in the background, by using a selection of weaker or stronger tools. \ section \Sledgehammer \label{sec:sledgehammer}\ text \ The \<^emph>\Sledgehammer\ panel (\figref{fig:sledgehammer}) provides a view on some independent execution of the Isar command @{command_ref sledgehammer}, with process indicator (spinning wheel) and GUI elements for important Sledgehammer arguments and options. Any number of Sledgehammer panels may be active, according to the standard policies of Dockable Window Management in jEdit. Closing such windows also cancels the corresponding prover tasks. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{sledgehammer} \end{center} \caption{An instance of the Sledgehammer panel} \label{fig:sledgehammer} \end{figure} The \<^emph>\Apply\ button attaches a fresh invocation of @{command sledgehammer} to the command where the cursor is pointing in the text --- this should be some pending proof problem. Further buttons like \<^emph>\Cancel\ and \<^emph>\Locate\ help to manage the running process. Results appear incrementally in the output window of the panel. Proposed proof snippets are marked-up as \<^emph>\sendback\, which means a single mouse click inserts the text into a suitable place of the original source. Some manual editing may be required nonetheless, say to remove earlier proof attempts. \ chapter \Isabelle document preparation\ text \ The ultimate purpose of Isabelle is to produce nicely rendered documents with the Isabelle document preparation system, which is based on {\LaTeX}; see also @{cite "isabelle-system" and "isabelle-isar-ref"}. Isabelle/jEdit provides some additional support for document editing. \ section \Document outline\ text \ Theory sources may contain document markup commands, such as @{command_ref chapter}, @{command_ref section}, @{command subsection}. The Isabelle SideKick parser (\secref{sec:sidekick}) represents this document outline as structured tree view, with formal statements and proofs nested inside; see \figref{fig:sidekick-document}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{sidekick-document} \end{center} \caption{Isabelle document outline via SideKick tree view} \label{fig:sidekick-document} \end{figure} It is also possible to use text folding according to this structure, by adjusting \<^emph>\Utilities / Buffer Options / Folding mode\ of jEdit. The default mode \<^verbatim>\isabelle\ uses the structure of formal definitions, statements, and proofs. The alternative mode \<^verbatim>\sidekick\ uses the document structure of the SideKick parser, as explained above. \ section \Markdown structure\ text \ Document text is internally structured in paragraphs and nested lists, using notation that is similar to Markdown\<^footnote>\\<^url>\https://commonmark.org\\. There are special control symbols for items of different kinds of lists, corresponding to \<^verbatim>\itemize\, \<^verbatim>\enumerate\, \<^verbatim>\description\ in {\LaTeX}. This is illustrated in for \<^verbatim>\itemize\ in \figref{fig:markdown-document}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{markdown-document} \end{center} \caption{Markdown structure within document text} \label{fig:markdown-document} \end{figure} Items take colour according to the depth of nested lists. This helps to explore the implicit rules for list structure interactively. There is also markup for individual items and paragraphs in the text: it may be explored via mouse hovering with \<^verbatim>\CONTROL\ / \<^verbatim>\COMMAND\ as usual (\secref{sec:tooltips-hyperlinks}). \ section \Citations and Bib{\TeX} entries \label{sec:bibtex}\ text \ Citations are managed by {\LaTeX} and Bib{\TeX} in \<^verbatim>\.bib\ files. The Isabelle session build process and the @{tool document} tool @{cite "isabelle-system"} are smart enough to assemble the result, based on the session directory layout. The document antiquotation \@{cite}\ is described in @{cite "isabelle-isar-ref"}. Within the Prover IDE it provides semantic markup for tooltips, hyperlinks, and completion for Bib{\TeX} database entries. Isabelle/jEdit does \<^emph>\not\ know about the actual Bib{\TeX} environment used in {\LaTeX} batch-mode, but it can take citations from those \<^verbatim>\.bib\ files that happen to be open in the editor; see \figref{fig:cite-completion}. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{cite-completion} \end{center} \caption{Semantic completion of citations from open Bib{\TeX} files} \label{fig:cite-completion} \end{figure} Isabelle/jEdit also provides IDE support for editing \<^verbatim>\.bib\ files themselves. There is syntax highlighting based on entry types (according to standard Bib{\TeX} styles), a context-menu to compose entries systematically, and a SideKick tree view of the overall content; see \figref{fig:bibtex-mode}. Semantic checking with errors and warnings is performed by the original \<^verbatim>\bibtex\ tool using style \<^verbatim>\plain\: different Bib{\TeX} styles may produce slightly different results. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{bibtex-mode} \end{center} \caption{Bib{\TeX} mode with context menu, SideKick tree view, and semantic output from the \<^verbatim>\bibtex\ tool} \label{fig:bibtex-mode} \end{figure} Regular document preview (\secref{sec:document-preview}) of \<^verbatim>\.bib\ files approximates the usual {\LaTeX} bibliography output in HTML (using style \<^verbatim>\unsort\). \ section \Document preview and printing \label{sec:document-preview}\ text \ The action @{action_def isabelle.preview} opens an HTML preview of the current document node in the default web browser. The content is derived from the semantic markup produced by the prover, and thus depends on the status of formal processing. Action @{action_def isabelle.draft} is similar to @{action isabelle.preview}, but shows a plain-text document draft. Both actions show document sources in a regular Web browser, which may be also used to print the result in a more portable manner than the Java printer dialog of the jEdit @{action_ref print} action. \ chapter \ML debugging within the Prover IDE\ text \ Isabelle/ML is based on Poly/ML\<^footnote>\\<^url>\https://www.polyml.org\\ and thus benefits from the source-level debugger of that implementation of Standard ML. The Prover IDE provides the \<^emph>\Debugger\ dockable to connect to running ML threads, inspect the stack frame with local ML bindings, and evaluate ML expressions in a particular run-time context. A typical debugger session is shown in \figref{fig:ml-debugger}. ML debugging depends on the following pre-requisites. \<^enum> ML source needs to be compiled with debugging enabled. This may be controlled for particular chunks of ML sources using any of the subsequent facilities. \<^enum> The system option @{system_option_ref ML_debugger} as implicit state of the Isabelle process. It may be changed in the menu \<^emph>\Plugins / Plugin Options / Isabelle / General\. ML modules need to be reloaded and recompiled to pick up that option as intended. \<^enum> The configuration option @{attribute_ref ML_debugger}, with an attribute of the same name, to update a global or local context (e.g.\ with the @{command declare} command). \<^enum> Commands that modify @{attribute ML_debugger} state for individual files: @{command_ref ML_file_debug}, @{command_ref ML_file_no_debug}, @{command_ref SML_file_debug}, @{command_ref SML_file_no_debug}. The instrumentation of ML code for debugging causes minor run-time overhead. ML modules that implement critical system infrastructure may lead to deadlocks or other undefined behaviour, when put under debugger control! \<^enum> The \<^emph>\Debugger\ panel needs to be active, otherwise the program ignores debugger instrumentation of the compiler and runs unmanaged. It is also possible to start debugging with the panel open, and later undock it, to let the program continue unhindered. \<^enum> The ML program needs to be stopped at a suitable breakpoint, which may be activated individually or globally as follows. For ML sources that have been compiled with debugger support, the IDE visualizes possible breakpoints in the text. A breakpoint may be toggled by pointing accurately with the mouse, with a right-click to activate jEdit's context menu and its \<^emph>\Toggle Breakpoint\ item. Alternatively, the \<^emph>\Break\ checkbox in the \<^emph>\Debugger\ panel may be enabled to stop ML threads always at the next possible breakpoint. Note that the state of individual breakpoints \<^emph>\gets lost\ when the coresponding ML source is re-compiled! This may happen unintentionally, e.g.\ when following hyperlinks into ML modules that have not been loaded into the IDE before. \begin{figure}[!htb] \begin{center} \includegraphics[scale=0.333]{ml-debugger} \end{center} \caption{ML debugger session} \label{fig:ml-debugger} \end{figure} The debugger panel (\figref{fig:ml-debugger}) shows a list of all threads that are presently stopped. Each thread shows a stack of all function invocations that lead to the current breakpoint at the top. It is possible to jump between stack positions freely, by clicking on this list. The current situation is displayed in the big output window, as a local ML environment with names and printed values. ML expressions may be evaluated in the current context by entering snippets of source into the text fields labeled \Context\ and \ML\, and pushing the \Eval\ button. By default, the source is interpreted as Isabelle/ML with the usual support for antiquotations (like @{command ML}, @{command ML_file}). Alternatively, strict Standard ML may be enforced via the \<^emph>\SML\ checkbox (like @{command SML_file}). The context for Isabelle/ML is optional, it may evaluate to a value of type \<^ML_type>\theory\, \<^ML_type>\Proof.context\, or \<^ML_type>\Context.generic\. Thus the given ML expression (with its antiquotations) may be subject to the intended dynamic run-time context, instead of the static compile-time context. \<^medskip> The buttons labeled \<^emph>\Continue\, \<^emph>\Step\, \<^emph>\Step over\, \<^emph>\Step out\ recommence execution of the program, with different policies concerning nested function invocations. The debugger always moves the cursor within the ML source to the next breakpoint position, and offers new stack frames as before. \ chapter \Miscellaneous tools\ section \Timing and monitoring\ text \ Managed evaluation of commands within PIDE documents includes timing information, which consists of elapsed (wall-clock) time, CPU time, and GC (garbage collection) time. Note that in a multithreaded system it is difficult to measure execution time precisely: elapsed time is closer to the real requirements of runtime resources than CPU or GC time, which are both subject to influences from the parallel environment that are outside the scope of the current command transaction. The \<^emph>\Timing\ panel provides an overview of cumulative command timings for each document node. Commands with elapsed time below the given threshold are ignored in the grand total. Nodes are sorted according to their overall timing. For the document node that corresponds to the current buffer, individual command timings are shown as well. A double-click on a theory node or command moves the editor focus to that particular source position. It is also possible to reveal individual timing information via some tooltip for the corresponding command keyword, using the technique of mouse hovering with \<^verbatim>\CONTROL\~/ \<^verbatim>\COMMAND\ modifier (\secref{sec:tooltips-hyperlinks}). Actual display of timing depends on the global option @{system_option_ref jedit_timing_threshold}, which can be configured in \<^emph>\Plugin Options~/ Isabelle~/ General\. \<^medskip> The jEdit status line includes a monitor widget for the current heap usage of the Isabelle/ML process; this includes information about ongoing garbage collection (shown as ``ML cleanup''). A double-click opens a new instance of the \<^emph>\Monitor\ panel, as explained below. There is a similar widget for the JVM: a double-click opens an external Java monitor process with detailed information and controls for the Java process underlying Isabelle/Scala/jEdit (this is based on \<^verbatim>\jconsole\). \<^medskip> The \<^emph>\Monitor\ panel visualizes various data collections about recent activity of the runtime system of Isabelle/ML and Java. There are buttons to request a full garbage collection and sharing of live data on the ML heap. The display is continuously updated according to @{system_option_ref editor_chart_delay}. Note that the painting of the chart takes considerable runtime itself --- on the Java Virtual Machine that runs Isabelle/Scala, not Isabelle/ML. \ section \Low-level output\ text \ Prover output is normally shown directly in the main text area or specific panels like \<^emph>\Output\ (\secref{sec:output}) or \<^emph>\State\ (\secref{sec:state-output}). Beyond this, it is occasionally useful to inspect low-level output channels via some of the following additional panels: \<^item> \<^emph>\Protocol\ shows internal messages between the Isabelle/Scala and Isabelle/ML side of the PIDE document editing protocol. Recording of messages starts with the first activation of the corresponding dockable window; earlier messages are lost. Display of protocol messages causes considerable slowdown, so it is important to undock all \<^emph>\Protocol\ panels for production work. \<^item> \<^emph>\Raw Output\ shows chunks of text from the \<^verbatim>\stdout\ and \<^verbatim>\stderr\ channels of the prover process. Recording of output starts with the first activation of the corresponding dockable window; earlier output is lost. The implicit stateful nature of physical I/O channels makes it difficult to relate raw output to the actual command from where it was originating. Parallel execution may add to the confusion. Peeking at physical process I/O is only the last resort to diagnose problems with tools that are not PIDE compliant. Under normal circumstances, prover output always works via managed message channels (corresponding to \<^ML>\writeln\, \<^ML>\warning\, \<^ML>\Output.error_message\ in Isabelle/ML), which are displayed by regular means within the document model (\secref{sec:output}). Unhandled Isabelle/ML exceptions are printed by the system via \<^ML>\Output.error_message\. \<^item> \<^emph>\Syslog\ shows system messages that might be relevant to diagnose problems with the startup or shutdown phase of the prover process; this also includes raw output on \<^verbatim>\stderr\. Isabelle/ML also provides an explicit \<^ML>\Output.system_message\ operation, which is occasionally useful for diagnostic purposes within the system infrastructure itself. A limited amount of syslog messages are buffered, independently of the docking state of the \<^emph>\Syslog\ panel. This allows to diagnose serious problems with Isabelle/PIDE process management, outside of the actual protocol layer. Under normal situations, such low-level system output can be ignored. \ chapter \Known problems and workarounds \label{sec:problems}\ text \ \<^item> \<^bold>\Problem:\ Keyboard shortcuts \<^verbatim>\C+PLUS\ and \<^verbatim>\C+MINUS\ for adjusting the editor font size depend on platform details and national keyboards. \<^bold>\Workaround:\ Rebind keys via \<^emph>\Global Options~/ Shortcuts\. \<^item> \<^bold>\Problem:\ The macOS key sequence \<^verbatim>\COMMAND+COMMA\ for application \<^emph>\Preferences\ is in conflict with the jEdit default keyboard shortcut for \<^emph>\Incremental Search Bar\ (action @{action_ref "quick-search"}). \<^bold>\Workaround:\ Rebind key via \<^emph>\Global Options~/ Shortcuts\ according to the national keyboard layout, e.g.\ \<^verbatim>\COMMAND+SLASH\ on English ones. \<^item> \<^bold>\Problem:\ On macOS with native Apple look-and-feel, some exotic national keyboards may cause a conflict of menu accelerator keys with regular jEdit key bindings. This leads to duplicate execution of the corresponding jEdit action. \<^bold>\Workaround:\ Disable the native Apple menu bar via Java runtime option \<^verbatim>\-Dapple.laf.useScreenMenuBar=false\. \<^item> \<^bold>\Problem:\ macOS system fonts sometimes lead to character drop-outs in the main text area. \<^bold>\Workaround:\ Use the default \<^verbatim>\Isabelle DejaVu\ fonts. \<^item> \<^bold>\Problem:\ On macOS the Java printer dialog sometimes does not work. \<^bold>\Workaround:\ Use action @{action isabelle.draft} and print via the Web browser. \<^item> \<^bold>\Problem:\ Antialiased text rendering may show bad performance or bad visual quality, notably on Linux/X11. \<^bold>\Workaround:\ The property \<^verbatim>\view.antiAlias\ (via menu item Utilities / Global Options / Text Area / Anti Aliased smooth text) has the main impact on text rendering, but some related properties may also change the behaviour. The default is \<^verbatim>\view.antiAlias=subpixel HRGB\: it can be much faster than \<^verbatim>\standard\, but occasionally causes problems with odd color shades. An alternative is to have \<^verbatim>\view.antiAlias=standard\ and set a Java system property like this:\<^footnote>\See also \<^url>\https://docs.oracle.com/javase/10/troubleshoot/java-2d-pipeline-rendering-and-properties.htm\.\ @{verbatim [display] \isabelle jedit -Dsun.java2d.opengl=true\} If this works reliably, it can be made persistent via @{setting JEDIT_JAVA_OPTIONS} within \<^path>\$ISABELLE_HOME_USER/etc/settings\. For the Isabelle desktop ``app'', there is a corresponding file with Java runtime options in the main directory (name depends on the OS platform). \<^item> \<^bold>\Problem:\ Some Linux/X11 input methods such as IBus tend to disrupt key event handling of Java/AWT/Swing. \<^bold>\Workaround:\ Do not use X11 input methods. Note that environment variable \<^verbatim>\XMODIFIERS\ is reset by default within Isabelle settings. \<^item> \<^bold>\Problem:\ Some Linux/X11 window managers that are not ``re-parenting'' cause problems with additional windows opened by Java. This affects either historic or neo-minimalistic window managers like \<^verbatim>\awesome\ or \<^verbatim>\xmonad\. \<^bold>\Workaround:\ Use a regular re-parenting X11 window manager. \<^item> \<^bold>\Problem:\ Various forks of Linux/X11 window managers and desktop environments (like Gnome) disrupt the handling of menu popups and mouse positions of Java/AWT/Swing. \<^bold>\Workaround:\ Use suitable version of Linux desktops. \<^item> \<^bold>\Problem:\ Full-screen mode via jEdit action @{action_ref "toggle-full-screen"} (default keyboard shortcut \<^verbatim>\F11\ or \<^verbatim>\S+F11\) works robustly on Windows, but not on macOS or various Linux/X11 window managers. For the latter platforms, it is approximated by educated guesses on the window size (excluding the macOS menu bar). \<^bold>\Workaround:\ Use native full-screen control of the macOS window manager. \<^item> \<^bold>\Problem:\ Heap space of the JVM may fill up and render the Prover IDE unresponsive, e.g.\ when editing big Isabelle sessions with many theories. \<^bold>\Workaround:\ Increase JVM heap parameters by editing platform-specific files (for ``properties'' or ``options'') that are associated with the main app bundle. \ end diff --git a/src/Doc/System/Server.thy b/src/Doc/System/Server.thy --- a/src/Doc/System/Server.thy +++ b/src/Doc/System/Server.thy @@ -1,1109 +1,1109 @@ (*:maxLineLen=78:*) theory Server imports Base begin chapter \The Isabelle server\ text \ An Isabelle session requires at least two processes, which are both rather heavy: Isabelle/Scala for the system infrastructure and Isabelle/ML for the logic session (e.g.\ HOL). In principle, these processes can be invoked directly on the command-line, e.g.\ via @{tool java}, @{tool scala}, @{tool process}, @{tool console}, but this approach is inadequate for reactive applications that require quick responses from the prover. In contrast, the Isabelle server exposes Isabelle/Scala as a ``terminate-stay-resident'' application that manages multiple logic \<^emph>\sessions\ and concurrent tasks to use \<^emph>\theories\. This provides an analogous to \<^ML>\Thy_Info.use_theories\ in Isabelle/ML, but with full concurrency and Isabelle/PIDE markup. The client/server arrangement via TCP sockets also opens possibilities for remote Isabelle services that are accessed by local applications, e.g.\ via an SSH tunnel. \ section \Command-line tools\ subsection \Server \label{sec:tool-server}\ text \ The @{tool_def server} tool manages resident server processes: @{verbatim [display] \Usage: isabelle server [OPTIONS] Options are: -L FILE logging on FILE -c console interaction with specified server -l list servers (alternative operation) -n NAME explicit server name (default: isabelle) -p PORT explicit server port -s assume existing server, no implicit startup -x exit specified server (alternative operation) Manage resident Isabelle servers.\} The main operation of \<^verbatim>\isabelle server\ is to ensure that a named server is running, either by finding an already running process (according to the central database file \<^path>\$ISABELLE_HOME_USER/servers.db\) or by becoming itself a new server that accepts connections on a particular TCP socket. The server name and its address are printed as initial output line. If another server instance is already running, the current \<^verbatim>\isabelle server\ process will terminate; otherwise, it keeps running as a new server process until an explicit \<^verbatim>\shutdown\ command is received. Further details of the server socket protocol are explained in \secref{sec:server-protocol}. Other server management operations are invoked via options \<^verbatim>\-l\ and \<^verbatim>\-x\ (see below). \<^medskip> Option \<^verbatim>\-n\ specifies an alternative server name: at most one process for each name may run, but each server instance supports multiple connections and logic sessions. \<^medskip> Option \<^verbatim>\-p\ specifies an explicit TCP port for the server socket (which is always on \<^verbatim>\localhost\): the default is to let the operating system assign a free port number. \<^medskip> Option \<^verbatim>\-s\ strictly assumes that the specified server process is already running, skipping the optional server startup phase. \<^medskip> Option \<^verbatim>\-c\ connects the console in/out channels after the initial check for a suitable server process. Also note that the @{tool client} tool (\secref{sec:tool-client}) provides a command-line editor to interact with the server. \<^medskip> Option \<^verbatim>\-L\ specifies a log file for exceptional output of internal server and session operations. \<^medskip> Operation \<^verbatim>\-l\ lists all active server processes with their connection details. \<^medskip> Operation \<^verbatim>\-x\ exits the specified server process by sending it a \<^verbatim>\shutdown\ command. \ subsection \Client \label{sec:tool-client}\ text \ The @{tool_def client} tool provides console interaction for Isabelle servers: @{verbatim [display] \Usage: isabelle client [OPTIONS] Options are: -n NAME explicit server name -p PORT explicit server port Console interaction for Isabelle server (with line-editor).\} This is a wrapper to \<^verbatim>\isabelle server -s -c\ for interactive experimentation, which uses @{setting ISABELLE_LINE_EDITOR} if available. The server name is sufficient for identification, as the client can determine the connection details from the local database of active servers. \<^medskip> Option \<^verbatim>\-n\ specifies an explicit server name as in @{tool server}. \<^medskip> Option \<^verbatim>\-p\ specifies an explicit server port as in @{tool server}. \ subsection \Examples\ text \ Ensure that a particular server instance is running in the background: @{verbatim [display] \isabelle server -n test &\} The first line of output presents the connection details:\<^footnote>\This information may be used in other TCP clients, without access to Isabelle/Scala and the underlying database of running servers.\ @{verbatim [display] \server "test" = 127.0.0.1:4711 (password "XYZ")\} \<^medskip> List available server processes: @{verbatim [display] \isabelle server -l\} \<^medskip> Connect the command-line client to the above test server: @{verbatim [display] \isabelle client -n test\} Interaction now works on a line-by-line basis, with commands like \<^verbatim>\help\ or \<^verbatim>\echo\. For example, some JSON values may be echoed like this: @{verbatim [display] \echo 42 echo [1, 2, 3] echo {"a": "text", "b": true, "c": 42}\} Closing the connection (via CTRL-D) leaves the server running: it is possible to reconnect again, and have multiple connections at the same time. \<^medskip> Exit the named server on the command-line: @{verbatim [display] \isabelle server -n test -x\} \ section \Protocol messages \label{sec:server-protocol}\ text \ The Isabelle server listens on a regular TCP socket, using a line-oriented protocol of structured messages. Input \<^emph>\commands\ and output \<^emph>\results\ (via \<^verbatim>\OK\ or \<^verbatim>\ERROR\) are strictly alternating on the toplevel, but commands may also return a \<^emph>\task\ identifier to indicate an ongoing asynchronous process that is joined later (via \<^verbatim>\FINISHED\ or \<^verbatim>\FAILED\). Asynchronous \<^verbatim>\NOTE\ messages may occur at any time: they are independent of the main command-result protocol. For example, the synchronous \<^verbatim>\echo\ command immediately returns its argument as \<^verbatim>\OK\ result. In contrast, the asynchronous \<^verbatim>\session_build\ command returns \<^verbatim>\OK {"task":\\id\\<^verbatim>\}\ and continues in the background. It will eventually produce \<^verbatim>\FINISHED {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ or \<^verbatim>\FAILED {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ with the final result. Intermediately, it may emit asynchronous messages of the form \<^verbatim>\NOTE {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ to inform about its progress. Due to the explicit task identifier, the client can show these messages in the proper context, e.g.\ a GUI window for this particular session build job. \medskip Subsequently, the protocol message formats are described in further detail. \ subsection \Byte messages \label{sec:byte-messages}\ text \ The client-server connection is a raw byte-channel for bidirectional communication, but the Isabelle server always works with messages of a particular length. Messages are written as a single chunk that is flushed immediately. Message boundaries are determined as follows: \<^item> A \<^emph>\short message\ consists of a single line: it is a sequence of arbitrary bytes excluding CR (13) and LF (10), and terminated by CR-LF or just LF. \<^item> A \<^emph>\long message\ starts with a single that consists only of decimal digits: these are interpreted as length of the subsequent block of arbitrary bytes. A final line-terminator (as above) may be included here, but is not required. Messages in JSON format (see below) always fit on a single line, due to escaping of newline characters within string literals. This is convenient for interactive experimentation, but it can impact performance for very long messages. If the message byte-length is given on the preceding line, the server can read the message more efficiently as a single block. \ subsection \Text messages\ text \ Messages are read and written as byte streams (with byte lengths), but the content is always interpreted as plain text in terms of the UTF-8 encoding.\<^footnote>\See also the ``UTF-8 Everywhere Manifesto'' \<^url>\https://utf8everywhere.org\.\ Note that line-endings and other formatting characters are invariant wrt. UTF-8 representation of text: thus implementations are free to determine the overall message structure before or after applying the text encoding. \ subsection \Input and output messages \label{sec:input-output-messages}\ text \ Server input and output messages have a uniform format as follows: \<^item> \name argument\ such that: \<^item> \name\ is the longest prefix consisting of ASCII letters, digits, ``\<^verbatim>\_\'', ``\<^verbatim>\.\'', \<^item> the separator between \name\ and \argument\ is the longest possible sequence of ASCII blanks (it could be empty, e.g.\ when the argument starts with a quote or bracket), \<^item> \argument\ is the rest of the message without line terminator. \<^medskip> Input messages are sent from the client to the server. Here the \name\ specifies a \<^emph>\server command\: the list of known commands may be retrieved via the \<^verbatim>\help\ command. \<^medskip> Output messages are sent from the server to the client. Here the \name\ specifies the \<^emph>\server reply\, which always has a specific meaning as follows: \<^item> synchronous results: \<^verbatim>\OK\ or \<^verbatim>\ERROR\ \<^item> asynchronous results: \<^verbatim>\FINISHED\ or \<^verbatim>\FAILED\ \<^item> intermediate notifications: \<^verbatim>\NOTE\ \<^medskip> The \argument\ format is uniform for both input and output messages: \<^item> empty argument (Scala type \<^verbatim>\Unit\) \<^item> XML element in YXML notation (Scala type \<^verbatim>\XML.Elem\) \<^item> JSON value (Scala type \<^verbatim>\JSON.T\) JSON values may consist of objects (records), arrays (lists), strings, numbers, bools, null.\<^footnote>\See also the official specification \<^url>\https://www.json.org\ and unofficial explorations ``Parsing JSON is a Minefield'' \<^url>\http://seriot.ch/parsing_json.php\.\ Since JSON requires explicit quotes and backslash-escapes to represent arbitrary text, the YXML notation for XML trees (\secref{sec:yxml-vs-xml}) works better for large messages with a lot of PIDE markup. Nonetheless, the most common commands use JSON by default: big chunks of text (theory sources etc.) are taken from the underlying file-system and results are pre-formatted for plain-text output, without PIDE markup information. This is a concession to simplicity: the server imitates the appearance of command-line tools on top of the Isabelle/PIDE infrastructure. \ subsection \Initial password exchange\ text \ Whenever a new client opens the server socket, the initial message needs to be its unique password as a single line, without length indication (i.e.\ a ``short message'' in the sense of \secref{sec:byte-messages}). The server replies either with \<^verbatim>\OK\ (and some information about the Isabelle version) or by silent disconnection of what is considered an illegal connection attempt. Note that @{tool client} already presents the correct password internally. Server passwords are created as Universally Unique Identifier (UUID) in Isabelle/Scala and stored in a per-user database, with restricted file-system access only for the current user. The Isabelle/Scala server implementation is careful to expose the password only on private output channels, and not on a process command-line (which is accessible to other users, e.g.\ via the \<^verbatim>\ps\ command). \ subsection \Synchronous commands\ text \ A \<^emph>\synchronous command\ corresponds to regular function application in Isabelle/Scala, with single argument and result (regular or error). Both the argument and the result may consist of type \<^verbatim>\Unit\, \<^verbatim>\XML.Elem\, \<^verbatim>\JSON.T\. An error result typically consists of a JSON object with error message and potentially further result fields (this resembles exceptions in Scala). These are the protocol exchanges for both cases of command execution: \begin{center} \begin{tabular}{rl} \<^bold>\input:\ & \command argument\ \\ (a) regular \<^bold>\output:\ & \<^verbatim>\OK\ \result\ \\ (b) error \<^bold>\output:\ & \<^verbatim>\ERROR\ \result\ \\ \end{tabular} \end{center} \ subsection \Asynchronous commands\ text \ An \<^emph>\asynchronous command\ corresponds to an ongoing process that finishes or fails eventually, while emitting arbitrary notifications in between. Formally, it starts as synchronous command with immediate result \<^verbatim>\OK\ giving the \<^verbatim>\task\ identifier, or an immediate \<^verbatim>\ERROR\ that indicates bad command syntax. For a running task, the termination is indicated later by \<^verbatim>\FINISHED\ or \<^verbatim>\FAILED\, together with its ultimate result value. These are the protocol exchanges for various cases of command task execution: \begin{center} \begin{tabular}{rl} \<^bold>\input:\ & \command argument\ \\ immediate \<^bold>\output:\ & \<^verbatim>\OK {"task":\\id\\<^verbatim>\}\ \\ intermediate \<^bold>\output:\ & \<^verbatim>\NOTE {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ \\ (a) regular \<^bold>\output:\ & \<^verbatim>\FINISHED {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ \\ (b) error \<^bold>\output:\ & \<^verbatim>\FAILED {"task":\\id\\<^verbatim>\,\\\\\<^verbatim>\}\ \\[3ex] \<^bold>\input:\ & \command argument\ \\ immediate \<^bold>\output:\ & \<^verbatim>\ERROR\~\\\ \\ \end{tabular} \end{center} All asynchronous messages are decorated with the task identifier that was revealed in the immediate (synchronous) result. Thus the client can invoke further asynchronous commands and still dispatch the resulting stream of asynchronous messages properly. The synchronous command \<^verbatim>\cancel {"task":\~\id\\<^verbatim>\}\ tells the specified task to terminate prematurely: usually causing a \<^verbatim>\FAILED\ result, but this is not guaranteed: the cancel event may come too late or the running process may just ignore it. \ section \Types for JSON values \label{sec:json-types}\ text \ In order to specify concrete JSON types for command arguments and result messages, the following type definition language shall be used: \<^rail>\ @{syntax type_def}: @'type' @{syntax name} '=' @{syntax type} ; @{syntax type}: @{syntax name} | @{syntax value} | 'any' | 'null' | 'bool' | 'int' | 'long' | 'double' | 'string' | '[' @{syntax type} ']' | '{' (@{syntax field_type} ',' *) '}' | @{syntax type} '\' @{syntax type} | @{syntax type} '|' @{syntax type} | '(' @{syntax type} ')' ; @{syntax field_type}: @{syntax name} ('?'?) ':' @{syntax type} \ This is a simplified variation of TypeScript interfaces.\<^footnote>\\<^url>\https://www.typescriptlang.org/docs/handbook/interfaces.html\\ The meaning of these types is specified wrt. the Isabelle/Scala implementation as follows. \<^item> A \name\ refers to a type defined elsewhere. The environment of type definitions is given informally: put into proper foundational order, it needs to specify a strongly normalizing system of syntactic abbreviations; type definitions may not be recursive. \<^item> A \value\ in JSON notation represents the singleton type of the given item. For example, the string \<^verbatim>\"error"\ can be used as type for a slot that is guaranteed to contain that constant. \<^item> Type \any\ is the super type of all other types: it is an untyped slot in the specification and corresponds to \<^verbatim>\Any\ or \<^verbatim>\JSON.T\ in Isabelle/Scala. \<^item> Type \null\ is the type of the improper value \null\; it corresponds to type \<^verbatim>\Null\ in Scala and is normally not used in Isabelle/Scala.\<^footnote>\See also ``Null References: The Billion Dollar Mistake'' by Tony Hoare \<^url>\https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare\.\ \<^item> Type \bool\ is the type of the truth values \<^verbatim>\true\ and \<^verbatim>\false\; it corresponds to \<^verbatim>\Boolean\ in Scala. \<^item> Types \int\, \long\, \double\ are specific versions of the generic \number\ type, corresponding to \<^verbatim>\Int\, \<^verbatim>\Long\, \<^verbatim>\Double\ in Scala, but \<^verbatim>\Long\ is limited to 53 bit precision.\<^footnote>\Implementations of JSON typically standardize \number\ to \<^verbatim>\Double\, which can absorb \<^verbatim>\Int\ faithfully, but not all of \<^verbatim>\Long\.\ \<^item> Type \string\ represents Unicode text; it corresponds to type \<^verbatim>\String\ in Scala. \<^item> Type \[t]\ is the array (or list) type over \t\; it corresponds to \<^verbatim>\List[t]\ in Scala. The list type is co-variant as usual (i.e.\ monotonic wrt. the subtype relation). \<^item> Object types describe the possible content of JSON records, with field names and types. A question mark after a field name means that it is optional. In Scala this could refer to an explicit type \<^verbatim>\Option[t]\, e.g.\ \{a: int, b?: string}\ corresponding to a Scala case class with arguments \<^verbatim>\a: Int\, \<^verbatim>\b: Option[String]\. Alternatively, optional fields can have a default value. If nothing else is specified, a standard ``empty value'' is used for each type, i.e.\ \<^verbatim>\0\ for the number types, \<^verbatim>\false\ for \bool\, or the empty string, array, object etc. Object types are \<^emph>\permissive\ in the sense that only the specified field names need to conform to the given types, but unspecified fields may be present as well. \<^item> The type expression \t\<^sub>1 \ t\<^sub>2\ only works for two object types with disjoint field names: it is the concatenation of the respective @{syntax field_type} specifications taken together. For example: \{task: string} \ {ok: bool}\ is the equivalent to \{task: string, ok: bool}\. \<^item> The type expression \t\<^sub>1 | t\<^sub>2\ is the disjoint union of two types, either one of the two cases may occur. \<^item> Parentheses \(t)\ merely group type expressions syntactically. These types correspond to JSON values in an obvious manner, which is not further described here. For example, the JSON array \<^verbatim>\[1, 2, 3]\ conforms to types \[int]\, \[long]\, \[double]\, \[any]\, \any\. Note that JSON objects require field names to be quoted, but the type language omits quotes for clarity. Thus the object \<^verbatim>\{"a": 42, "b": "xyz"}\ conforms to the type \{a: int, b: string}\, for example. \<^medskip> The absence of an argument or result is represented by the Scala type \<^verbatim>\Unit\: it is written as empty text in the message \argument\ (\secref{sec:input-output-messages}). This is not part of the JSON language. Server replies have name tags like \<^verbatim>\OK\, \<^verbatim>\ERROR\: these are used literally together with type specifications to indicate the particular name with the type of its argument, e.g.\ \<^verbatim>\OK\~\[string]\ for a regular result that is a list (JSON array) of strings. \<^bigskip> Here are some common type definitions, for use in particular specifications of command arguments and results. \<^item> \<^bold>\type\~\position = {line?: int, offset?: int, end_offset?: int, file?: string, id?: long}\ describes a source position within Isabelle text. Only the \line\ and \file\ fields make immediate sense to external programs. Detailed \offset\ and \end_offset\ positions are counted according to Isabelle symbols, see \<^ML_type>\Symbol.symbol\ in Isabelle/ML @{cite "isabelle-implementation"}. The position \id\ belongs to the representation of command transactions in the Isabelle/PIDE protocol: it normally does not occur in externalized positions. \<^item> \<^bold>\type\~\message = {kind: string, message: string, pos?: position}\ where the \kind\ provides some hint about the role and importance of the message. The main message kinds are \<^verbatim>\writeln\ (for regular output), \<^verbatim>\warning\, \<^verbatim>\error\. \<^item> \<^bold>\type\~\error_message = {kind:\~\<^verbatim>\"error"\\, message: string}\ refers to error messages in particular. These occur routinely with \<^verbatim>\ERROR\ or \<^verbatim>\FAILED\ replies, but also as initial command syntax errors (which are omitted in the command specifications below). \<^item> \<^bold>\type\~\theory_progress = {kind:\~\<^verbatim>\"writeln"\\, message: string, theory: string, session: string, percentage?: int}\ reports formal progress in loading theories (e.g.\ when building a session image). Apart from a regular output message, it also reveals the formal theory name (e.g.\ \<^verbatim>\"HOL.Nat"\) and session name (e.g.\ \<^verbatim>\"HOL"\). Note that some rare theory names lack a proper session prefix, e.g.\ theory \<^verbatim>\"Main"\ in session \<^verbatim>\"HOL"\. The optional percentage has the same meaning as in \<^bold>\type\~\node_status\ below. \<^item> \<^bold>\type\~\timing = {elapsed: double, cpu: double, gc: double}\ refers to common Isabelle timing information in seconds, usually with a precision of three digits after the point (whole milliseconds). \<^item> \<^bold>\type\~\uuid = string\ refers to a Universally Unique Identifier (UUID) as plain text.\<^footnote>\See \<^url>\https://www.ietf.org/rfc/rfc4122.txt\ and - \<^url>\https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/UUID.html\.\ Such + \<^url>\https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/UUID.html\.\ Such identifiers are created as private random numbers of the server and only revealed to the client that creates a certain resource (e.g.\ task or session). A client may disclose this information for use in a different client connection: this allows to share sessions between multiple connections. Client commands need to provide syntactically wellformed UUIDs: this is trivial to achieve by using only identifiers that have been produced by the server beforehand. \<^item> \<^bold>\type\~\task = {task: uuid}\ identifies a newly created asynchronous task and thus allows the client to control it by the \<^verbatim>\cancel\ command. The same task identification is included in all messages produced by this task. \<^item> \<^bold>\type\ \session_id = {session_id: uuid}\ identifies a newly created PIDE session managed by the server. Sessions are independent of client connections and may be shared by different clients, as long as the internal session identifier is known. \<^item> \<^bold>\type\ \node = {node_name: string, theory_name: string}\ represents the internal node name of a theory. The \node_name\ is derived from the canonical theory file-name (e.g.\ \<^verbatim>\"~~/src/HOL/Examples/Seq.thy"\ after normalization within the file-system). The \theory_name\ is the session-qualified theory name (e.g.\ \<^verbatim>\HOL-Examples.Seq\). \<^item> \<^bold>\type\ \node_status = {ok: bool, total: int, unprocessed: int, running: int, warned: int, failed: int, finished: int, canceled: bool, consolidated: bool, percentage: int}\ represents a formal theory node status of the PIDE document model as follows. \<^item> Fields \total\, \unprocessed\, \running\, \warned\, \failed\, \finished\ account for individual commands within a theory node; \ok\ is an abstraction for \failed = 0\. \<^item> The \canceled\ flag tells if some command in the theory has been spontaneously canceled (by an Interrupt exception that could also indicate resource problems). \<^item> The \consolidated\ flag indicates whether the outermost theory command structure has finished (or failed) and the final \<^theory_text>\end\ command has been checked. \<^item> The \percentage\ field tells how far the node has been processed. It ranges between 0 and 99 in normal operation, and reaches 100 when the node has been formally consolidated as described above. \ section \Server commands and results\ text \ Here follows an overview of particular Isabelle server commands with their results, which are usually represented as JSON values with types according to \secref{sec:json-types}. The general format of input and output messages is described in \secref{sec:input-output-messages}. The relevant Isabelle/Scala source files are: \<^medskip> \begin{tabular}{l} \<^file>\$ISABELLE_HOME/src/Pure/Tools/server_commands.scala\ \\ \<^file>\$ISABELLE_HOME/src/Pure/Tools/server.scala\ \\ \<^file>\$ISABELLE_HOME/src/Pure/General/json.scala\ \\ \end{tabular} \ subsection \Command \<^verbatim>\help\\ text \ \begin{tabular}{ll} regular result: & \<^verbatim>\OK\ \[string]\ \\ \end{tabular} \<^medskip> The \<^verbatim>\help\ command has no argument and returns the list of server command names. This is occasionally useful for interactive experimentation (see also @{tool client} in \secref{sec:tool-client}). \ subsection \Command \<^verbatim>\echo\\ text \ \begin{tabular}{ll} argument: & \any\ \\ regular result: & \<^verbatim>\OK\ \any\ \\ \end{tabular} \<^medskip> The \<^verbatim>\echo\ command is the identity function: it returns its argument as regular result. This is occasionally useful for testing and interactive experimentation (see also @{tool client} in \secref{sec:tool-client}). The Scala type of \<^verbatim>\echo\ is actually more general than given above: \<^verbatim>\Unit\, \<^verbatim>\XML.Elem\, \<^verbatim>\JSON.T\ work uniformly. Note that \<^verbatim>\XML.Elem\ might be difficult to type on the console in its YXML syntax (\secref{sec:yxml-vs-xml}). \ subsection \Command \<^verbatim>\shutdown\\ text \ \begin{tabular}{ll} regular result: & \<^verbatim>\OK\ \\ \end{tabular} \<^medskip> The \<^verbatim>\shutdown\ command has no argument and result value. It forces a shutdown of the connected server process, stopping all open sessions and closing the server socket. This may disrupt pending commands on other connections! \<^medskip> The command-line invocation \<^verbatim>\isabelle server -x\ opens a server connection and issues a \<^verbatim>\shutdown\ command (see also \secref{sec:tool-server}). \ subsection \Command \<^verbatim>\cancel\\ text \ \begin{tabular}{ll} argument: & \task\ \\ regular result: & \<^verbatim>\OK\ \\ \end{tabular} \<^medskip> The command \<^verbatim>\cancel {"task":\~\id\\<^verbatim>\}\ attempts to cancel the specified task. Cancellation is merely a hint that the client prefers an ongoing process to be stopped. The command always succeeds formally, but it may get ignored by a task that is still running; it might also refer to a non-existing or no-longer existing task (without producing an error). Successful cancellation typically leads to an asynchronous failure of type \<^verbatim>\FAILED {\\task: uuid, message:\~\<^verbatim>\"Interrupt"}\. A different message is also possible, depending how the task handles the event. \ subsection \Command \<^verbatim>\session_build\ \label{sec:command-session-build}\ text \ \begin{tabular}{lll} argument: & \session_build_args\ \\ immediate result: & \<^verbatim>\OK\ \task\ \\ notifications: & \<^verbatim>\NOTE\ \task \ (theory_progress | message)\ \\ regular result: & \<^verbatim>\FINISHED\ \task \ session_build_results\ \\ error result: & \<^verbatim>\FAILED\ \task \ error_message \ session_build_results\ \\[2ex] \end{tabular} \begin{tabular}{lll} \<^bold>\type\ \session_build_args =\ \\ \quad\{session: string,\ \\ \quad~~\preferences?: string,\ & \<^bold>\default:\ server preferences \\ \quad~~\options?: [string],\ \\ \quad~~\dirs?: [string],\ \\ \quad~~\include_sessions: [string],\ \\ \quad~~\verbose?: bool}\ \\[2ex] \end{tabular} \begin{tabular}{ll} \<^bold>\type\ \session_build_result =\ \\ \quad\{session: string,\ \\ \quad~~\ok: bool,\ \\ \quad~~\return_code: int,\ \\ \quad~~\timeout: bool,\ \\ \quad~~\timing: timing}\ \\[2ex] \<^bold>\type\ \session_build_results =\ \\ \quad\{ok: bool,\ \\ \quad~~\return_code: int,\ \\ \quad~~\sessions: [session_build_result]}\ \\ \end{tabular} \ text \ The \<^verbatim>\session_build\ command prepares a session image for interactive use of theories. This is a limited version of command-line tool @{tool build} (\secref{sec:tool-build}), with specific options to request a formal context for an interactive PIDE session. The build process is asynchronous, with notifications that inform about the progress of loaded theories. Some further informative messages are output as well. Coordination of independent build processes is at the discretion of the client (or end-user), just as for @{tool build} and @{tool jedit}. There is no built-in coordination of conflicting builds with overlapping hierarchies of session images. In the worst case, a session image produced by one task may get overwritten by another task! \ subsubsection \Arguments\ text \ The \session\ field specifies the target session name. The build process will produce all required ancestor images according to the overall session graph. \<^medskip> The environment of Isabelle system options is determined from \preferences\ that are augmented by \options\, which is a list individual updates of the form the \name\\<^verbatim>\=\\value\ or \name\ (the latter abbreviates \name\\<^verbatim>\=true\); see also command-line option \<^verbatim>\-o\ for @{tool build}. The preferences are loaded from the file \<^path>\$ISABELLE_HOME_USER/etc/preferences\ by default, but the client may provide alternative contents for it (as text, not a file-name). This could be relevant in situations where client and server run in different operating-system contexts. \<^medskip> The \dirs\ field specifies additional directories for session ROOT and ROOTS files (\secref{sec:session-root}). This augments the name space of available sessions; see also option \<^verbatim>\-d\ in @{tool build}. \<^medskip> The \include_sessions\ field specifies sessions whose theories should be included in the overall name space of session-qualified theory names. This corresponds to a \<^bold>\sessions\ specification in ROOT files (\secref{sec:session-root}). It enables the \<^verbatim>\use_theories\ command (\secref{sec:command-use-theories}) to refer to sources from other sessions in a robust manner, instead of relying on directory locations. \<^medskip> The \verbose\ field set to \<^verbatim>\true\ yields extra verbosity. The effect is similar to option \<^verbatim>\-v\ in @{tool build}. \ subsubsection \Intermediate output\ text \ The asynchronous notifications of command \<^verbatim>\session_build\ mainly serve as progress indicator: the output resembles that of the session build window of Isabelle/jEdit after startup @{cite "isabelle-jedit"}. For the client it is usually sufficient to print the messages in plain text, but note that \theory_progress\ also reveals formal \theory\ and \session\ names directly. \ subsubsection \Results\ text \ The overall \session_build_results\ contain both a summary and an entry \session_build_result\ for each session in the build hierarchy. The result is always provided, independently of overall success (\<^verbatim>\FINISHED\ task) or failure (\<^verbatim>\FAILED\ task). The \ok\ field tells abstractly, whether all required session builds came out as \ok\, i.e.\ with zero \return_code\. A non-zero \return_code\ indicates an error according to usual POSIX conventions for process exit. The individual \session_build_result\ entries provide extra fields: \<^item> \timeout\ tells if the build process was aborted after running too long, \<^item> \timing\ gives the overall process timing in the usual Isabelle format with elapsed, CPU, GC time. \ subsubsection \Examples\ text \ Build of a session image from the Isabelle distribution: @{verbatim [display] \session_build {"session": "HOL-Algebra"}\} Build a session image from the Archive of Formal Proofs: @{verbatim [display] \session_build {"session": "Coinductive", "dirs": ["$AFP_BASE/thys"]}\} \ subsection \Command \<^verbatim>\session_start\ \label{sec:command-session-start}\ text \ \begin{tabular}{lll} argument: & \session_build_args \ {print_mode?: [string]}\ \\ immediate result: & \<^verbatim>\OK\ \task\ \\ notifications: & \<^verbatim>\NOTE\ \task \ (theory_progress | message)\ \\ regular result: & \<^verbatim>\FINISHED\ \task \ session_id \ {tmp_dir: string}\ \\ error result: & \<^verbatim>\FAILED\ \task \ error_message\ \\[2ex] \end{tabular} \<^medskip> The \<^verbatim>\session_start\ command starts a new Isabelle/PIDE session with underlying Isabelle/ML process, based on a session image that it produces on demand using \<^verbatim>\session_build\. Thus it accepts all \session_build_args\ and produces similar notifications, but the detailed \session_build_results\ are omitted. The session build and startup process is asynchronous: when the task is finished, the session remains active for commands, until a \<^verbatim>\session_stop\ or \<^verbatim>\shutdown\ command is sent to the server. Sessions are independent of client connections: it is possible to start a session and later apply \<^verbatim>\use_theories\ on different connections, as long as the internal session identifier is known: shared theory imports will be used only once (and persist until purged explicitly). \ subsubsection \Arguments\ text \ Most arguments are shared with \<^verbatim>\session_build\ (\secref{sec:command-session-build}). \<^medskip> The \print_mode\ field adds identifiers of print modes to be made active for this session. For example, \<^verbatim>\"print_mode": ["ASCII"]\ prefers ASCII replacement syntax over mathematical Isabelle symbols. See also option \<^verbatim>\-m\ in @{tool process} (\secref{sec:tool-process}). \ subsubsection \Results\ text \ The \session_id\ provides the internal identification of the session object within the sever process. It can remain active as long as the server is running, independently of the current client connection. \<^medskip> The \tmp_dir\ field refers to a temporary directory that is specifically created for this session and deleted after it has been stopped. This may serve as auxiliary file-space for the \<^verbatim>\use_theories\ command, but concurrent use requires some care in naming temporary files, e.g.\ by using sub-directories with globally unique names. As \tmp_dir\ is the default \master_dir\ for commands \<^verbatim>\use_theories\ and \<^verbatim>\purge_theories\, theory files copied there may be used without further path specification. \ subsubsection \Examples\ text \ Start a default Isabelle/HOL session: @{verbatim [display] \session_start {"session": "HOL"}\} Start a session from the Archive of Formal Proofs: @{verbatim [display] \session_start {"session": "Coinductive", "dirs": ["$AFP_BASE/thys"]}\} \ subsection \Command \<^verbatim>\session_stop\\ text \ \begin{tabular}{ll} argument: & \session_id\ \\ immediate result: & \<^verbatim>\OK\ \task\ \\ regular result: & \<^verbatim>\FINISHED\ \task \ session_stop_result\ \\ error result: & \<^verbatim>\FAILED\ \task \ error_message \ session_stop_result\ \\[2ex] \end{tabular} \begin{tabular}{l} \<^bold>\type\ \session_stop_result = {ok: bool, return_code: int}\ \end{tabular} \<^medskip> The \<^verbatim>\session_stop\ command forces a shutdown of the identified PIDE session. This asynchronous tasks usually finishes quickly. Failure only happens in unusual situations, according to the return code of the underlying Isabelle/ML process. \ subsubsection \Arguments\ text \ The \session_id\ provides the UUID originally created by the server for this session. \ subsubsection \Results\ text \ The \ok\ field tells abstractly, whether the Isabelle/ML process has terminated properly. The \return_code\ field expresses this information according to usual POSIX conventions for process exit. \ subsection \Command \<^verbatim>\use_theories\ \label{sec:command-use-theories}\ text \ \begin{tabular}{ll} argument: & \use_theories_arguments\ \\ immediate result: & \<^verbatim>\OK\ \task\ \\ regular result: & \<^verbatim>\FINISHED\ \use_theories_results\ \\ \end{tabular} \begin{tabular}{ll} \<^bold>\type\ \use_theories_arguments =\ \\ \quad\{session_id: uuid,\ \\ \quad~~\theories: [string],\ \\ \quad~~\master_dir?: string,\ & \<^bold>\default:\ session \tmp_dir\ \\ \quad~~\pretty_margin?: double,\ & \<^bold>\default:\ \<^verbatim>\76\ \\ \quad~~\unicode_symbols?: bool,\ \\ \quad~~\export_pattern?: string,\ \\ \quad~~\check_delay?: double,\ & \<^bold>\default:\ \<^verbatim>\0.5\ \\ \quad~~\check_limit?: int,\ \\ \quad~~\watchdog_timeout?: double,\ & \<^bold>\default:\ \<^verbatim>\600.0\ \\ \quad~~\nodes_status_delay?: double}\ & \<^bold>\default:\ \<^verbatim>\-1.0\ \\ \end{tabular} \begin{tabular}{ll} \<^bold>\type\ \export =\ \\ \quad~~\{name: string, base64: bool, body: string}\ \\ \<^bold>\type\ \node_results =\ \\ \quad~~\{status: node_status, messages: [message], exports: [export]}\ \\ \<^bold>\type\ \nodes_status =\ \\ \quad~~\[node \ {status: node_status}]\ \\ \<^bold>\type\ \use_theories_results =\ \\ \quad\{ok: bool,\ \\ \quad~~\errors: [message],\ \\ \quad~~\nodes: [node \ node_results]}\ \\ \end{tabular} \<^medskip> The \<^verbatim>\use_theories\ command updates the identified session by adding the current version of theory files to it, while dependencies are resolved implicitly. The command succeeds eventually, when all theories have status \<^emph>\terminated\ or \<^emph>\consolidated\ in the sense of \node_status\ (\secref{sec:json-types}). Already used theories persist in the session until purged explicitly (\secref{sec:command-purge-theories}). This also means that repeated invocations of \<^verbatim>\use_theories\ are idempotent: it could make sense to do that with different values for \pretty_margin\ or \unicode_symbols\ to get different formatting for \errors\ or \messages\. \<^medskip> A non-empty \export_pattern\ means that theory \exports\ are retrieved (see \secref{sec:tool-export}). An \export\ \name\ roughly follows file-system standards: ``\<^verbatim>\/\'' separated list of base names (excluding special names like ``\<^verbatim>\.\'' or ``\<^verbatim>\..\''). The \base64\ field specifies the format of the \body\ string: it is true for a byte vector that cannot be represented as plain text in UTF-8 encoding, which means the string needs to be decoded as in \<^verbatim>\java.util.Base64.getDecoder.decode(String)\. \<^medskip> The status of PIDE processing is checked every \check_delay\ seconds, and bounded by \check_limit\ attempts (default: 0, i.e.\ unbounded). A \check_limit > 0\ effectively specifies a global timeout of \check_delay \ check_limit\ seconds. \<^medskip> If \watchdog_timeout\ is greater than 0, it specifies the timespan (in seconds) after the last command status change of Isabelle/PIDE, before finishing with a potentially non-terminating or deadlocked execution. \<^medskip> A non-negative \nodes_status_delay\ enables continuous notifications of kind \nodes_status\, with a field of name and type \nodes_status\. The time interval is specified in seconds; by default it is negative and thus disabled. \ subsubsection \Arguments\ text \ The \session_id\ is the identifier provided by the server, when the session was created (possibly on a different client connection). \<^medskip> The \theories\ field specifies theory names as in theory \<^theory_text>\imports\ or in ROOT \<^bold>\theories\. \<^medskip> The \master_dir\ field specifies the master directory of imported theories: it acts like the ``current working directory'' for locating theory files. This is irrelevant for \theories\ with an absolute path name (e.g.\ \<^verbatim>\"~~/src/HOL/Examples/Seq.thy"\) or session-qualified theory name (e.g.\ \<^verbatim>\"HOL-Examples.Seq"\). \<^medskip> The \pretty_margin\ field specifies the line width for pretty-printing. The default is suitable for classic console output. Formatting happens at the end of \<^verbatim>\use_theories\, when all prover messages are exported to the client. \<^medskip> The \unicode_symbols\ field set to \<^verbatim>\true\ renders message output for direct output on a Unicode capable channel, ideally with the Isabelle fonts as in Isabelle/jEdit. The default is to keep the symbolic representation of Isabelle text, e.g.\ \<^verbatim>\\\ instead of its rendering as \\\. This means the client needs to perform its own rendering before presenting it to the end-user. \ subsubsection \Results\ text \ The \ok\ field indicates overall success of processing the specified theories with all their dependencies. When \ok\ is \<^verbatim>\false\, the \errors\ field lists all errors cumulatively (including imported theories). The messages contain position information for the original theory nodes. \<^medskip> The \nodes\ field provides detailed information about each imported theory node. The individual fields are as follows: \<^item> \node_name\: the canonical name for the theory node, based on its file-system location; \<^item> \theory_name\: the logical theory name; \<^item> \status\: the overall node status, e.g.\ see the visualization in the \Theories\ panel of Isabelle/jEdit @{cite "isabelle-jedit"}; \<^item> \messages\: the main bulk of prover messages produced in this theory (with kind \<^verbatim>\writeln\, \<^verbatim>\warning\, \<^verbatim>\error\). \ subsubsection \Examples\ text \ Process some example theory from the Isabelle distribution, within the context of an already started session for Isabelle/HOL (see also \secref{sec:command-session-start}): @{verbatim [display] \use_theories {"session_id": ..., "theories": ["~~/src/HOL/Examples/Seq"]}\} \<^medskip> Process some example theories in the context of their (single) parent session: @{verbatim [display] \session_start {"session": "HOL-Library"} use_theories {"session_id": ..., "theories": ["~~/src/HOL/Unix/Unix"]} session_stop {"session_id": ...}\} \<^medskip> Process some example theories that import other theories via session-qualified theory names: @{verbatim [display] \session_start {"session": "HOL", "include_sessions": ["HOL-Unix"]} use_theories {"session_id": ..., "theories": ["HOL-Unix.Unix"]} session_stop {"session_id": ...}\} \ subsection \Command \<^verbatim>\purge_theories\ \label{sec:command-purge-theories}\ text \ \begin{tabular}{ll} argument: & \purge_theories_arguments\ \\ regular result: & \<^verbatim>\OK\ \purge_theories_result\ \\ \end{tabular} \begin{tabular}{lll} \<^bold>\type\ \purge_theories_arguments =\ \\ \quad\{session_id: uuid,\ \\ \quad~~\theories: [string],\ \\ \quad~~\master_dir?: string,\ & \<^bold>\default:\ session \tmp_dir\ \\ \quad~~\all?: bool}\ \\[2ex] \end{tabular} \begin{tabular}{ll} \<^bold>\type\ \purge_theories_result = {purged: [string]}\ \\ \end{tabular} \<^medskip> The \<^verbatim>\purge_theories\ command updates the identified session by removing theories that are no longer required: theories that are used in pending \<^verbatim>\use_theories\ tasks or imported by other theories are retained. \ subsubsection \Arguments\ text \ The \session_id\ is the identifier provided by the server, when the session was created (possibly on a different client connection). \<^medskip> The \theories\ field specifies theory names to be purged: imported dependencies are \<^emph>\not\ completed. Instead it is possible to provide the already completed import graph returned by \<^verbatim>\use_theories\ as \nodes\ / \node_name\. \<^medskip> The \master_dir\ field specifies the master directory as in \<^verbatim>\use_theories\. This is irrelevant, when passing fully-qualified theory node names (e.g.\ \node_name\ from \nodes\ in \use_theories_results\). \<^medskip> The \all\ field set to \<^verbatim>\true\ attempts to purge all presently loaded theories. \ subsubsection \Results\ text \ The \purged\ field gives the theory nodes that were actually removed. \<^medskip> The \retained\ field gives the remaining theory nodes, i.e.\ the complement of \purged\. \ end diff --git a/src/Pure/Admin/isabelle_cronjob.scala b/src/Pure/Admin/isabelle_cronjob.scala --- a/src/Pure/Admin/isabelle_cronjob.scala +++ b/src/Pure/Admin/isabelle_cronjob.scala @@ -1,652 +1,652 @@ /* Title: Pure/Admin/isabelle_cronjob.scala Author: Makarius Main entry point for administrative cronjob at TUM. */ package isabelle import java.nio.file.Files import scala.annotation.tailrec object Isabelle_Cronjob { /* global resources: owned by main cronjob */ val backup = "lxbroy10:cronjob" val main_dir: Path = Path.explode("~/cronjob") val main_state_file: Path = main_dir + Path.explode("run/main.state") val current_log: Path = main_dir + Path.explode("run/main.log") // owned by log service val cumulative_log: Path = main_dir + Path.explode("log/main.log") // owned by log service val isabelle_repos: Path = main_dir + Path.explode("isabelle") val afp_repos: Path = main_dir + Path.explode("AFP") val mailman_archives_dir = Path.explode("~/cronjob/Mailman") val build_log_dirs = List(Path.explode("~/log"), Path.explode("~/afp/log"), Path.explode("~/cronjob/log")) /** logger tasks **/ sealed case class Logger_Task(name: String = "", body: Logger => Unit) /* init and exit */ def get_rev(): String = Mercurial.repository(isabelle_repos).id() def get_afp_rev(): String = Mercurial.repository(afp_repos).id() val init: Logger_Task = Logger_Task("init", logger => { Isabelle_Devel.make_index() Mercurial.setup_repository(Isabelle_System.isabelle_repository.root, isabelle_repos) Mercurial.setup_repository(Isabelle_System.afp_repository.root, afp_repos) File.write(logger.log_dir + Build_Log.log_filename("isabelle_identify", logger.start_date), Build_Log.Identify.content(logger.start_date, Some(get_rev()), Some(get_afp_rev()))) Isabelle_System.bash( """rsync -a --include="*/" --include="plain_identify*" --exclude="*" """ + Bash.string(backup + "/log/.") + " " + File.bash_path(main_dir) + "/log/.").check if (!Isabelle_Devel.cronjob_log.is_file) Files.createSymbolicLink(Isabelle_Devel.cronjob_log.java_path, current_log.java_path) }) val exit: Logger_Task = Logger_Task("exit", logger => { Isabelle_System.bash( "rsync -a " + File.bash_path(main_dir) + "/log/." + " " + Bash.string(backup) + "/log/.") .check }) /* Mailman archives */ val mailman_archives: Logger_Task = Logger_Task("mailman_archives", logger => { - Mailman.isabelle_users.download(mailman_archives_dir) - Mailman.isabelle_dev.download(mailman_archives_dir) + Mailman.Isabelle_Users.download(mailman_archives_dir) + Mailman.Isabelle_Dev.download(mailman_archives_dir) }) /* build release */ val build_release: Logger_Task = Logger_Task("build_release", logger => { Isabelle_Devel.release_snapshot(logger.options, get_rev(), get_afp_rev()) }) /* remote build_history */ sealed case class Item( known: Boolean, isabelle_version: String, afp_version: Option[String], pull_date: Date) { def unknown: Boolean = !known def versions: (String, Option[String]) = (isabelle_version, afp_version) def known_versions(rev: String, afp_rev: Option[String]): Boolean = known && rev != "" && isabelle_version == rev && (afp_rev.isEmpty || afp_rev.get != "" && afp_version == afp_rev) } def recent_items(db: SQL.Database, days: Int, rev: String, afp_rev: Option[String], sql: SQL.Source): List[Item] = { val afp = afp_rev.isDefined val select = Build_Log.Data.select_recent_versions( days = days, rev = rev, afp_rev = afp_rev, sql = "WHERE " + sql) db.using_statement(select)(stmt => stmt.execute_query().iterator(res => { val known = res.bool(Build_Log.Data.known) val isabelle_version = res.string(Build_Log.Prop.isabelle_version) val afp_version = if (afp) proper_string(res.string(Build_Log.Prop.afp_version)) else None val pull_date = res.date(Build_Log.Data.pull_date(afp)) Item(known, isabelle_version, afp_version, pull_date) }).toList) } def unknown_runs(items: List[Item]): List[List[Item]] = { val (run, rest) = Library.take_prefix[Item](_.unknown, items.dropWhile(_.known)) if (run.nonEmpty) run :: unknown_runs(rest) else Nil } sealed case class Remote_Build( description: String, host: String, actual_host: String = "", user: String = "", port: Int = 0, proxy_host: String = "", proxy_user: String = "", proxy_port: Int = 0, self_update: Boolean = false, historic: Boolean = false, history: Int = 0, history_base: String = "build_history_base", java_heap: String = "", options: String = "", args: String = "", afp: Boolean = false, bulky: Boolean = false, more_hosts: List[String] = Nil, detect: SQL.Source = "", active: Boolean = true) { def ssh_session(context: SSH.Context): SSH.Session = context.open_session(host = host, user = user, port = port, actual_host = actual_host, proxy_host = proxy_host, proxy_user = proxy_user, proxy_port = proxy_port, permissive = proxy_host.nonEmpty) def sql: SQL.Source = Build_Log.Prop.build_engine.toString + " = " + SQL.string(Build_History.engine) + " AND " + SQL.member(Build_Log.Prop.build_host.ident, host :: more_hosts) + (if (detect == "") "" else " AND " + SQL.enclose(detect)) def profile: Build_Status.Profile = Build_Status.Profile(description, history = history, afp = afp, bulky = bulky, sql = sql) def pick( options: Options, rev: String = "", filter: Item => Boolean = _ => true): Option[(String, Option[String])] = { val afp_rev = if (afp) Some(get_afp_rev()) else None val store = Build_Log.store(options) using(store.open_database())(db => { def pick_days(days: Int, gap: Int): Option[(String, Option[String])] = { val items = recent_items(db, days, rev, afp_rev, sql).filter(filter) def runs = unknown_runs(items).filter(run => run.length >= gap) if (historic || items.exists(_.known_versions(rev, afp_rev))) { val longest_run = runs.foldLeft(List.empty[Item]) { case (item1, item2) => if (item1.length >= item2.length) item1 else item2 } if (longest_run.isEmpty) None else Some(longest_run(longest_run.length / 2).versions) } else if (rev != "") Some((rev, afp_rev)) else runs.flatten.headOption.map(_.versions) } pick_days(options.int("build_log_history") max history, 2) orElse pick_days(200, 5) orElse pick_days(2000, 1) }) } def build_history_options: String = " -h " + Bash.string(host) + " " + (java_heap match { case "" => "" case h => "-e 'ISABELLE_TOOL_JAVA_OPTIONS=\"$ISABELLE_TOOL_JAVA_OPTIONS -Xmx" + h + "\"' " }) + options } val remote_builds_old: List[Remote_Build] = List( Remote_Build("Linux A", "i21of4", user = "i21isatest", proxy_host = "lxbroy10", proxy_user = "i21isatest", self_update = true, options = "-m32 -M1x4,2,4" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_MLTON=mlton" + " -e ISABELLE_SMLNJ=sml" + " -e ISABELLE_SWIPL=swipl", args = "-a -d '~~/src/Benchmarks'"), Remote_Build("Linux A", "lxbroy9", java_heap = "2g", options = "-m32 -B -M1x2,2", args = "-N -g timing"), Remote_Build("Linux Benchmarks", "lxbroy5", historic = true, history = 90, java_heap = "2g", options = "-m32 -B -M1x2,2 -t Benchmarks" + " -e ISABELLE_GHC=ghc -e ISABELLE_MLTON=mlton -e ISABELLE_OCAML=ocaml" + " -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAMLFIND=ocamlfind -e ISABELLE_SMLNJ=sml" + " -e ISABELLE_SWIPL=swipl", args = "-N -a -d '~~/src/Benchmarks'", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("Benchmarks")), Remote_Build("macOS 10.14 Mojave (Old)", "lapnipkow3", options = "-m32 -M1,2 -e ISABELLE_GHC_SETUP=true -p pide_session=false", self_update = true, args = "-a -d '~~/src/Benchmarks'"), Remote_Build("AFP old bulky", "lrzcloud1", self_update = true, proxy_host = "lxbroy10", proxy_user = "i21isatest", options = "-m64 -M6 -U30000 -s10 -t AFP", args = "-g large -g slow", afp = true, bulky = true, detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("AFP")), Remote_Build("AFP old", "lxbroy7", args = "-N -X large -X slow", afp = true, detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("AFP")), Remote_Build("Poly/ML 5.7 Linux", "lxbroy8", history_base = "37074e22e8be", options = "-m32 -B -M1x2,2 -t polyml-5.7 -i 'init_component /home/isabelle/contrib/polyml-5.7'", args = "-N -g timing", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("polyml-5.7") + " AND " + Build_Log.Settings.ML_OPTIONS + " <> " + SQL.string("-H 500")), Remote_Build("Poly/ML 5.7.1 Linux", "lxbroy8", history_base = "a9d5b59c3e12", options = "-m32 -B -M1x2,2 -t polyml-5.7.1-pre2 -i 'init_component /home/isabelle/contrib/polyml-test-905dae2ebfda'", args = "-N -g timing", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("polyml-5.7.1-pre1") + " OR " + Build_Log.Prop.build_tags + " = " + SQL.string("polyml-5.7.1-pre2")), Remote_Build("Poly/ML 5.7 macOS", "macbroy2", history_base = "37074e22e8be", options = "-m32 -B -M1x4,4 -t polyml-5.7 -i 'init_component /home/isabelle/contrib/polyml-5.7'", args = "-a", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("polyml-5.7")), Remote_Build("Poly/ML 5.7.1 macOS", "macbroy2", history_base = "a9d5b59c3e12", options = "-m32 -B -M1x4,4 -t polyml-5.7.1-pre2 -i 'init_component /home/isabelle/contrib/polyml-test-905dae2ebfda'", args = "-a", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("polyml-5.7.1-pre1") + " OR " + Build_Log.Prop.build_tags + " = " + SQL.string("polyml-5.7.1-pre2")), Remote_Build("macOS", "macbroy2", options = "-m32 -M8" + " -e ISABELLE_GHC=ghc -e ISABELLE_MLTON=mlton -e ISABELLE_OCAML=ocaml" + " -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_OPAM_ROOT=\"$ISABELLE_HOME/opam\"" + " -e ISABELLE_SMLNJ=/home/isabelle/smlnj/110.85/bin/sml" + " -p pide_session=false", args = "-a", detect = Build_Log.Prop.build_tags.undefined, history_base = "2c0f24e927dd"), Remote_Build("macOS, quick_and_dirty", "macbroy2", options = "-m32 -M8 -t quick_and_dirty -p pide_session=false", args = "-a -o quick_and_dirty", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("quick_and_dirty"), history_base = "2c0f24e927dd"), Remote_Build("macOS, skip_proofs", "macbroy2", options = "-m32 -M8 -t skip_proofs -p pide_session=false", args = "-a -o skip_proofs", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("skip_proofs"), history_base = "2c0f24e927dd"), Remote_Build("Poly/ML test", "lxbroy8", options = "-m32 -B -M1x2,2 -t polyml-test -i 'init_component /home/isabelle/contrib/polyml-5.7-20170217'", args = "-N -g timing", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("polyml-test")), Remote_Build("macOS 10.12 Sierra", "macbroy30", options = "-m32 -M2 -p pide_session=false", args = "-a", detect = Build_Log.Prop.build_start.toString + " > date '2017-03-03'"), Remote_Build("macOS 10.10 Yosemite", "macbroy31", options = "-m32 -M2 -p pide_session=false", args = "-a"), Remote_Build("macOS 10.8 Mountain Lion", "macbroy30", options = "-m32 -M2", args = "-a", detect = Build_Log.Prop.build_start.toString + " < date '2017-03-03'")) ::: { for { (n, hosts) <- List(1 -> List("lxbroy6"), 2 -> List("lxbroy8", "lxbroy5")) } yield { Remote_Build("AFP old", host = hosts.head, more_hosts = hosts.tail, options = "-m32 -M1x2 -t AFP -P" + n + " -e ISABELLE_GHC=ghc" + " -e ISABELLE_MLTON=mlton" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAMLFIND=ocamlfind" + " -e ISABELLE_SMLNJ=sml", args = "-N -X large -X slow", afp = true, detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("AFP")) } } val remote_builds1: List[List[Remote_Build]] = { List( List(Remote_Build("Linux A", "augsburg1", options = "-m32 -B -M4" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAMLFIND=ocamlfind" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_MLTON=mlton" + " -e ISABELLE_SMLNJ=sml" + " -e ISABELLE_SWIPL=swipl", self_update = true, args = "-a -d '~~/src/Benchmarks'")), List(Remote_Build("Linux B", "lxbroy10", historic = true, history = 90, options = "-m32 -B -M1x4,2,4,6", args = "-N -g timing")), List(Remote_Build("macOS 10.13 High Sierra", "lapbroy68", options = "-m32 -B -M1,2,4 -e ISABELLE_GHC_SETUP=true -p pide_session=false", self_update = true, args = "-a -d '~~/src/Benchmarks'")), List( Remote_Build("macOS 11 Big Sur", "mini1", options = "-m32 -B -M1x2,2,4 -p pide_session=false" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_MLTON=/usr/local/bin/mlton" + " -e ISABELLE_SMLNJ=/usr/local/smlnj/bin/sml" + " -e ISABELLE_SWIPL=/usr/local/bin/swipl", self_update = true, args = "-a -d '~~/src/Benchmarks'")), List( Remote_Build("macOS 10.14 Mojave", "mini2", options = "-m32 -B -M1x2,2,4 -p pide_session=false" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_MLTON=/usr/local/bin/mlton" + " -e ISABELLE_SMLNJ=/usr/local/smlnj/bin/sml" + " -e ISABELLE_SWIPL=/usr/local/bin/swipl", self_update = true, args = "-a -d '~~/src/Benchmarks'"), Remote_Build("macOS, quick_and_dirty", "mini2", options = "-m32 -M4 -t quick_and_dirty -p pide_session=false", self_update = true, args = "-a -o quick_and_dirty", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("quick_and_dirty")), Remote_Build("macOS, skip_proofs", "mini2", options = "-m32 -M4 -t skip_proofs -p pide_session=false", args = "-a -o skip_proofs", detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("skip_proofs"))), List(Remote_Build("macOS 10.15 Catalina", "laramac01", user = "makarius", proxy_host = "laraserver", proxy_user = "makarius", self_update = true, options = "-m32 -M4 -e ISABELLE_GHC_SETUP=true -p pide_session=false", args = "-a -d '~~/src/Benchmarks'")), List( Remote_Build("Windows", "vmnipkow9", historic = true, history = 90, self_update = true, options = "-m32 -M4" + " -C /cygdrive/d/isatest/contrib" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_SMLNJ=/usr/local/smlnj-110.81/bin/sml", args = "-a", detect = Build_Log.Settings.ML_PLATFORM.toString + " = " + SQL.string("x86-windows") + " OR " + Build_Log.Settings.ML_PLATFORM + " = " + SQL.string("x86_64_32-windows")), Remote_Build("Windows", "vmnipkow9", historic = true, history = 90, self_update = true, options = "-m64 -M4" + " -C /cygdrive/d/isatest/contrib" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAML_SETUP=true" + " -e ISABELLE_GHC_SETUP=true" + " -e ISABELLE_SMLNJ=/usr/local/smlnj-110.81/bin/sml", args = "-a", detect = Build_Log.Settings.ML_PLATFORM.toString + " = " + SQL.string("x86_64-windows")))) } val remote_builds2: List[List[Remote_Build]] = List( List( Remote_Build("AFP", "lrzcloud2", actual_host = "10.195.4.41", self_update = true, proxy_host = "lxbroy10", proxy_user = "i21isatest", java_heap = "8g", options = "-m32 -M1x6 -t AFP" + " -e ISABELLE_GHC=ghc" + " -e ISABELLE_MLTON=mlton" + " -e ISABELLE_OCAML=ocaml -e ISABELLE_OCAMLC=ocamlc -e ISABELLE_OCAMLFIND=ocamlfind" + " -e ISABELLE_SMLNJ=sml", args = "-a -X large -X slow", afp = true, detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("AFP")), Remote_Build("AFP", "lrzcloud2", actual_host = "10.195.4.41", self_update = true, proxy_host = "lxbroy10", proxy_user = "i21isatest", java_heap = "8g", options = "-m64 -M8 -U30000 -s10 -t AFP", args = "-g large -g slow", afp = true, bulky = true, detect = Build_Log.Prop.build_tags.toString + " = " + SQL.string("AFP")))) def remote_build_history(rev: String, afp_rev: Option[String], i: Int, r: Remote_Build) : Logger_Task = { val task_name = "build_history-" + r.host Logger_Task(task_name, logger => { using(r.ssh_session(logger.ssh_context))(ssh => { val results = Build_History.remote_build_history(ssh, isabelle_repos, isabelle_repos.ext(r.host), isabelle_identifier = "cronjob_build_history", self_update = r.self_update, rev = rev, afp_rev = afp_rev, options = " -N " + Bash.string(task_name) + (if (i < 0) "" else "_" + (i + 1).toString) + " -R " + Bash.string(Components.default_component_repository) + " -C '$USER_HOME/.isabelle/contrib' -f " + r.build_history_options, args = "-o timeout=10800 " + r.args) for ((log_name, bytes) <- results) { logger.log(Date.now(), log_name) Bytes.write(logger.log_dir + Path.explode(log_name), bytes) } }) }) } val build_status_profiles: List[Build_Status.Profile] = (remote_builds_old :: remote_builds1 ::: remote_builds2).flatten.map(_.profile) /** task logging **/ object Log_Service { def apply(options: Options, progress: Progress = new Progress): Log_Service = new Log_Service(SSH.init_context(options), progress) } class Log_Service private(val ssh_context: SSH.Context, progress: Progress) { current_log.file.delete private val thread: Consumer_Thread[String] = Consumer_Thread.fork("cronjob: logger", daemon = true)( consume = (text: String) => { // critical File.append(current_log, text + "\n") File.append(cumulative_log, text + "\n") progress.echo(text) true }) def shutdown(): Unit = { thread.shutdown() } val hostname: String = Isabelle_System.hostname() def log(date: Date, task_name: String, msg: String): Unit = if (task_name != "") thread.send( "[" + Build_Log.print_date(date) + ", " + hostname + ", " + task_name + "]: " + msg) def start_logger(start_date: Date, task_name: String): Logger = new Logger(this, start_date, task_name) def run_task(start_date: Date, task: Logger_Task): Unit = { val logger = start_logger(start_date, task.name) val res = Exn.capture { task.body(logger) } val end_date = Date.now() val err = res match { case Exn.Res(_) => None case Exn.Exn(exn) => Output.writeln("Exception trace for " + quote(task.name) + ":") exn.printStackTrace() val first_line = split_lines(Exn.message(exn)).headOption getOrElse "exception" Some(first_line) } logger.log_end(end_date, err) } def fork_task(start_date: Date, task: Logger_Task): Task = new Task(task.name, run_task(start_date, task)) } class Logger private[Isabelle_Cronjob]( val log_service: Log_Service, val start_date: Date, val task_name: String) { def ssh_context: SSH.Context = log_service.ssh_context def options: Options = ssh_context.options def log(date: Date, msg: String): Unit = log_service.log(date, task_name, msg) def log_end(end_date: Date, err: Option[String]): Unit = { val elapsed_time = end_date.time - start_date.time val msg = (if (err.isEmpty) "finished" else "ERROR " + err.get) + (if (elapsed_time.seconds < 3.0) "" else " (" + elapsed_time.message_hms + " elapsed time)") log(end_date, msg) } val log_dir = Isabelle_System.make_directory(main_dir + Build_Log.log_subdir(start_date)) log(start_date, "started") } class Task private[Isabelle_Cronjob](name: String, body: => Unit) { private val future: Future[Unit] = Future.thread("cronjob: " + name) { body } def is_finished: Boolean = future.is_finished } /** cronjob **/ def cronjob(progress: Progress, exclude_task: Set[String]): Unit = { /* soft lock */ val still_running = try { Some(File.read(main_state_file)) } catch { case ERROR(_) => None } still_running match { case None | Some("") => case Some(running) => error("Isabelle cronjob appears to be still running: " + running) } /* log service */ val log_service = Log_Service(Options.init(), progress = progress) def run(start_date: Date, task: Logger_Task): Unit = log_service.run_task(start_date, task) def run_now(task: Logger_Task): Unit = run(Date.now(), task) /* structured tasks */ def SEQ(tasks: List[Logger_Task]): Logger_Task = Logger_Task(body = _ => for (task <- tasks.iterator if !exclude_task(task.name) || task.name == "") run_now(task)) def PAR(tasks: List[Logger_Task]): Logger_Task = Logger_Task(body = _ => { @tailrec def join(running: List[Task]): Unit = { running.partition(_.is_finished) match { case (Nil, Nil) => case (Nil, _ :: _) => Time.seconds(0.5).sleep(); join(running) case (_ :: _, remaining) => join(remaining) } } val start_date = Date.now() val running = for (task <- tasks if !exclude_task(task.name)) yield log_service.fork_task(start_date, task) join(running) }) /* repository structure */ val hg = Mercurial.repository(isabelle_repos) val hg_graph = hg.graph() def history_base_filter(r: Remote_Build): Item => Boolean = { val base_rev = hg.id(r.history_base) val nodes = hg_graph.all_succs(List(base_rev)).toSet (item: Item) => nodes(item.isabelle_version) } /* main */ val main_start_date = Date.now() File.write(main_state_file, main_start_date.toString + " " + log_service.hostname) run(main_start_date, Logger_Task("isabelle_cronjob", logger => run_now( SEQ(List( init, PAR(List(mailman_archives, build_release)), PAR( List(remote_builds1, remote_builds2).map(remote_builds => SEQ(List( PAR(remote_builds.map(_.filter(_.active)).map(seq => SEQ( for { (r, i) <- (if (seq.length <= 1) seq.map((_, -1)) else seq.zipWithIndex) (rev, afp_rev) <- r.pick(logger.options, hg.id(), history_base_filter(r)) } yield remote_build_history(rev, afp_rev, i, r)))), Logger_Task("jenkins_logs", _ => Jenkins.download_logs(logger.options, Jenkins.build_log_jobs, main_dir)), Logger_Task("build_log_database", logger => Isabelle_Devel.build_log_database(logger.options, build_log_dirs)), Logger_Task("build_status", logger => Isabelle_Devel.build_status(logger.options)))))), exit))))) log_service.shutdown() main_state_file.file.delete } /** command line entry point **/ def main(args: Array[String]): Unit = { Command_Line.tool { var force = false var verbose = false var exclude_task = Set.empty[String] val getopts = Getopts(""" Usage: Admin/cronjob/main [OPTIONS] Options are: -f apply force to do anything -v verbose -x NAME exclude tasks with this name """, "f" -> (_ => force = true), "v" -> (_ => verbose = true), "x:" -> (arg => exclude_task += arg)) val more_args = getopts(args) if (more_args.nonEmpty) getopts.usage() val progress = if (verbose) new Console_Progress() else new Progress if (force) cronjob(progress, exclude_task) else error("Need to apply force to do anything") } } } diff --git a/src/Pure/General/date.scala b/src/Pure/General/date.scala --- a/src/Pure/General/date.scala +++ b/src/Pure/General/date.scala @@ -1,106 +1,122 @@ /* Title: Pure/General/date.scala Author: Makarius Date and time, with time zone. */ package isabelle import java.util.Locale import java.time.{Instant, ZonedDateTime, LocalTime, ZoneId, OffsetDateTime} import java.time.format.{DateTimeFormatter, DateTimeParseException} import java.time.temporal.TemporalAccessor import scala.annotation.tailrec +import scala.math.Ordering object Date { /* format */ object Format { def make(fmts: List[DateTimeFormatter], tune: String => String = s => s): Format = { require(fmts.nonEmpty, "no date formats") new Format { def apply(date: Date): String = fmts.head.format(date.rep) def parse(str: String): Date = new Date(ZonedDateTime.from(Formatter.try_variants(fmts, tune(str)))) } } def apply(pats: String*): Format = make(pats.toList.map(Date.Formatter.pattern)) val default: Format = Format("dd-MMM-uuuu HH:mm:ss xx") val date: Format = Format("dd-MMM-uuuu") val time: Format = Format("HH:mm:ss") val alt_date: Format = Format("uuuuMMdd") } abstract class Format private { def apply(date: Date): String def parse(str: String): Date def unapply(str: String): Option[Date] = try { Some(parse(str)) } catch { case _: DateTimeParseException => None } } object Formatter { def pattern(pat: String): DateTimeFormatter = DateTimeFormatter.ofPattern(pat) def variants(pats: List[String], locs: List[Locale] = Nil): List[DateTimeFormatter] = pats.flatMap(pat => { val fmt = pattern(pat) if (locs.isEmpty) List(fmt) else locs.map(fmt.withLocale) }) @tailrec def try_variants(fmts: List[DateTimeFormatter], str: String, last_exn: Option[DateTimeParseException] = None): TemporalAccessor = { fmts match { case Nil => throw last_exn.getOrElse(new DateTimeParseException("Failed to parse date", str, 0)) case fmt :: rest => try { ZonedDateTime.from(fmt.parse(str)) } catch { case exn: DateTimeParseException => try_variants(rest, str, Some(exn)) } } } } + /* ordering */ + + object Ordering extends scala.math.Ordering[Date] + { + def compare(date1: Date, date2: Date): Int = + date1.instant.compareTo(date2.instant) + } + + object Rev_Ordering extends scala.math.Ordering[Date] + { + def compare(date1: Date, date2: Date): Int = + date2.instant.compareTo(date1.instant) + } + + /* date operations */ def timezone_utc: ZoneId = ZoneId.of("UTC") def timezone_berlin: ZoneId = ZoneId.of("Europe/Berlin") def timezone(): ZoneId = ZoneId.systemDefault def now(zone: ZoneId = timezone()): Date = new Date(ZonedDateTime.now(zone)) def instant(t: Instant, zone: ZoneId = timezone()): Date = new Date(ZonedDateTime.ofInstant(t, zone)) def apply(t: Time, zone: ZoneId = timezone()): Date = instant(t.instant, zone) } sealed case class Date(rep: ZonedDateTime) { def midnight: Date = new Date(ZonedDateTime.of(rep.toLocalDate, LocalTime.MIDNIGHT, rep.getZone)) def to(zone: ZoneId): Date = new Date(rep.withZoneSameInstant(zone)) def unix_epoch: Long = rep.toEpochSecond def instant: Instant = Instant.from(rep) def time: Time = Time.instant(instant) def timezone: ZoneId = rep.getZone def format(fmt: Date.Format = Date.Format.default): String = fmt(this) override def toString: String = format() } diff --git a/src/Pure/General/mailman.scala b/src/Pure/General/mailman.scala --- a/src/Pure/General/mailman.scala +++ b/src/Pure/General/mailman.scala @@ -1,101 +1,393 @@ /* Title: Pure/General/mailman.scala Author: Makarius Support for Mailman list servers. */ package isabelle import java.net.URL +import scala.annotation.tailrec import scala.util.matching.Regex +import scala.util.matching.Regex.Match object Mailman { - /* mailing list archives */ - - def archive(url: URL, msg_format: Msg_Format, name: String = ""): Archive = - { - val list_url = - Url(Library.take_suffix[Char](_ == '/', Url.trim_index(url).toString.toList)._1.mkString + "/") + /* mailing list messages */ - val html = Url.read(list_url) - val title = - """The ([^</>]*) Archives""".r.findFirstMatchIn(html).map(_.group(1)) - val hrefs_text = - """href="([^"]+\.txt(?:\.gz)?)"""".r.findAllMatchIn(html).map(_.group(1)).toList - - val list_name = - (proper_string(name) orElse title).getOrElse(error("Failed to determine mailing list name")) - new Archive(list_url, list_name, msg_format, hrefs_text) + sealed case class Message( + name: String, + date: Date, + title: String, + author_name: String, + author_address: String, + body: String) + { + override def toString: String = name + def print: String = + name + "\n" + date + "\n" + title + "\n" + + quote(author_name) + "\n" + "<" + author_address + ">\n" } - abstract class Msg_Format + private class Message_Chunk(bg: String = "", en: String = "") { - def regex: Regex + def unapply(lines: List[String]): Option[List[String]] = + { + val res1 = + if (bg.isEmpty) Some(lines) + else { + lines.dropWhile(_ != bg) match { + case Nil => None + case _ :: rest => Some(rest) + } + } + if (en.isEmpty) res1 + else { + res1 match { + case None => None + case Some(lines1) => + val lines2 = lines1.takeWhile(_ != en) + if (lines1.drop(lines2.length).isEmpty) None else Some(lines2) + } + } + } + + def get(lines: List[String]): List[String] = + unapply(lines) getOrElse + error("Missing delimiters:" + + (if (bg.nonEmpty) " " else "") + bg + + (if (en.nonEmpty) " " else "") + en) } - class Archive private[Mailman]( - val list_url: URL, - val list_name: String, - msg_format: Msg_Format, - hrefs_text: List[String]) + + /* integrity check */ + + def check_messages(msgs: List[Message]): Unit = { + val msgs_sorted = msgs.sortBy(_.date)(Date.Ordering) + val msgs_proper = + msgs_sorted.filter(msg => msg.author_name.nonEmpty && msg.author_address.nonEmpty) + + val address_name = Multi_Map.from(msgs_proper.map(msg => (msg.author_address, msg.author_name))) + val name_address = Multi_Map.from(msgs_proper.map(msg => (msg.author_name, msg.author_address))) + + def print_dup(a: String, bs: List[String]): String = + " * " + a + bs.mkString("\n ", "\n ", "") + + def print_dups(title: String, m: Multi_Map[String, String]): Unit = + { + val dups = m.iterator_list.filter(p => p._2.length > 1).toList + if (dups.nonEmpty) { + Output.writeln(cat_lines(title :: dups.map(p => print_dup(p._1, p._2)))) + } + } + + print_dups("duplicate names:", address_name) + print_dups("duplicate addresses:", name_address) + + def get_name(msg: Message): Option[String] = + proper_string(msg.author_name) orElse address_name.get(msg.author_address) + + val unnamed = + msgs_sorted.flatMap(msg => if (get_name(msg).isEmpty) Some(msg.author_address) else None) + .toSet.toList.sorted + + if (unnamed.nonEmpty) { + Output.writeln(("unnamed:" :: unnamed).mkString("\n", "\n ", "")) + } + } + + + /* mailing list archives */ + + abstract class Archive( + url: URL, + name: String = "", + tag: String = "") + { + def message_regex: Regex + def message_content(name: String, lines: List[String]): Message + + def message_match(lines: List[String], re: Regex): Option[Match] = + lines.flatMap(re.findFirstMatchIn(_)).headOption + + def make_name(str: String): String = str.replaceAll("""\s+""", " ") + + def make_address(s: String): String = HTML.input(s).replace(" at ", "@") + + def make_body(lines: List[String]): String = + cat_lines(Library.take_suffix[String](_.isEmpty, lines)._1) + + private val main_url: URL = + Url(Library.take_suffix[Char](_ == '/', Url.trim_index(url).toString.toList)._1.mkString + "/") + + private val main_html = Url.read(main_url) + + val list_name: String = + { + val title = + """The ([^</>]*) Archives""".r.findFirstMatchIn(main_html).map(_.group(1)) + (proper_string(name) orElse title).getOrElse(error("Failed to determine mailing list name")) + } override def toString: String = list_name - private def hrefs_msg: List[String] = + def full_name(href: String): String = list_name + "/" + href + + def list_tag: String = proper_string(tag).getOrElse(list_name) + + def read_text(href: String): String = Url.read(new URL(main_url, href)) + + def hrefs_text: List[String] = + """href="([^"]+\.txt(?:\.gz)?)"""".r.findAllMatchIn(main_html).map(_.group(1)).toList + + def hrefs_msg: List[String] = (for { - href <- """href="([^"]+)/date.html"""".r.findAllMatchIn(Url.read(list_url)).map(_.group(1)) - html = Url.read(new URL(list_url, href + "/date.html")) - msg <- msg_format.regex.findAllMatchIn(html).map(_.group(1)) + href <- """href="([^"]+)/date.html"""".r.findAllMatchIn(main_html).map(_.group(1)) + html = read_text(href + "/date.html") + msg <- message_regex.findAllMatchIn(html).map(_.group(1)) } yield href + "/" + msg).toList def get(target_dir: Path, href: String, progress: Progress = new Progress): Option[Path] = { val dir = target_dir + Path.basic(list_name) val path = dir + Path.explode(href) - val url = new URL(list_url, href) + val url = new URL(main_url, href) val connection = url.openConnection try { val length = connection.getContentLengthLong val timestamp = connection.getLastModified val file = path.file if (file.isFile && file.length == length && file.lastModified == timestamp) None else { Isabelle_System.make_directory(path.dir) progress.echo("Getting " + url) val bytes = using(connection.getInputStream)(Bytes.read_stream(_, hint = length.toInt max 1024)) Bytes.write(file, bytes) file.setLastModified(timestamp) Some(path) } } finally { connection.getInputStream.close() } } def download_text(target_dir: Path, progress: Progress = new Progress): List[Path] = hrefs_text.flatMap(get(target_dir, _, progress = progress)) def download_msg(target_dir: Path, progress: Progress = new Progress): List[Path] = hrefs_msg.flatMap(get(target_dir, _, progress = progress)) def download(target_dir: Path, progress: Progress = new Progress): List[Path] = download_text(target_dir, progress = progress) ::: download_msg(target_dir, progress = progress) + + def make_title(str: String): String = + { + val Trim1 = ("""\s*\Q[""" + list_tag + """]\E\s*(.*)""").r + val Trim2 = """(?i:(?:re|fw|fwd)\s*:\s*)(.*)""".r + val Trim3 = """\[\s*(.*?)\s*\]""".r + @tailrec def trim(s: String): String = + s match { + case Trim1(s1) => trim(s1) + case Trim2(s1) => trim(s1) + case Trim3(s1) => trim(s1) + case _ => s + } + trim(str) + } + + def get_messages(): List[Message] = + for (href <- hrefs_msg) yield message_content(href, split_lines(read_text(href))) + + def find_messages(dir: Path): List[Message] = + { + for { + file <- File.find_files(dir.file, file => file.getName.endsWith(".html")) + rel_path <- File.relative_path(dir, File.path(file)) + } + yield { + val name = full_name(rel_path.implode) + message_content(name, split_lines(File.read(file))) + } + } } /* Isabelle mailing lists */ - def isabelle_users: Archive = - archive(Url("https://lists.cam.ac.uk/pipermail/cl-isabelle-users"), name = "isabelle-users", - msg_format = - new Msg_Format { val regex: Regex = """
  • """.r }) + object Isabelle_Users extends Archive( + Url("https://lists.cam.ac.uk/pipermail/cl-isabelle-users"), + name = "isabelle-users", tag = "isabelle") + { + override def message_regex: Regex = """
  • """.r - def isabelle_dev: Archive = - archive(Url("https://mailmanbroy.in.tum.de/pipermail/isabelle-dev"), - new Msg_Format { val regex: Regex = """
  • """.r }) + private object Head extends + Message_Chunk(bg = "", en = "") + + private object Body extends + Message_Chunk(bg = "", en = "") + + private object Date_Format + { + private val Trim1 = """\w+,\s*(.*)""".r + private val Trim2 = """(.*?)\s*\(.*\)""".r + private val Format = + Date.Format( + "d MMM uuuu H:m:s Z", + "d MMM uuuu H:m:s z", + "d MMM yy H:m:s Z", + "d MMM yy H:m:s z") + def unapply(s: String): Option[Date] = + { + val s0 = s.replaceAll("""\s+""", " ") + val s1 = + s0 match { + case Trim1(s1) => s1 + case _ => s0 + } + val s2 = + s1 match { + case Trim2(s2) => s2 + case _ => s1 + } + Format.unapply(s2) + } + } + + override def make_name(str: String): String = + { + val Trim = """(.*?)\s*via\s+Cl-isabelle-users""".r + super.make_name(str) match { + case Trim(s) => s + case s => s + } + } + + override def make_address(str: String): String = + { + val s = super.make_address(make_name(str)) + if (s == "cl-isabelle-users@lists.cam.ac.uk") "" else s + } + + object Address + { + private def anchor(s: String): String = """""" + s + """""" + private def angl(s: String): String = """<""" + s + """>""" + private def quot(s: String): String = """"""" + s + """"""" + private def paren(s: String): String = """\(""" + s + """\)""" + private val adr = """([^<>]*? at [^<>]*?)""" + private val any = """([^<>]*?)""" + private val spc = """\s*""" + + private val Name1 = quot(anchor(any)).r + private val Name2 = quot(any).r + private val Name_Adr1 = (quot(anchor(any)) + spc + angl(anchor(adr))).r + private val Name_Adr2 = (quot(any) + spc + angl(anchor(adr))).r + private val Name_Adr3 = (anchor(any) + spc + angl(anchor(adr))).r + private val Name_Adr4 = (any + spc + angl(anchor(adr))).r + private val Adr_Name1 = (angl(anchor(adr)) + spc + paren(any)).r + private val Adr_Name2 = (anchor(adr) + spc + paren(any)).r + private val Adr1 = angl(anchor(adr)).r + private val Adr2 = anchor(adr).r + + def unapply(s: String): Option[(String, String)] = + s match { + case Name1(a) => Some((make_address(a), "")) + case Name2(a) => Some((make_address(a), "")) + case Name_Adr1(a, b) => Some((make_address(a), make_address(b))) + case Name_Adr2(a, b) => Some((make_address(a), make_address(b))) + case Name_Adr3(a, b) => Some((make_address(a), make_address(b))) + case Name_Adr4(a, b) => Some((make_address(a), make_address(b))) + case Adr_Name1(b, a) => Some((make_address(a), make_address(b))) + case Adr_Name2(b, a) => Some((make_address(a), make_address(b))) + case Adr1(a) => Some(("", make_address(a))) + case Adr2(a) => Some(("", make_address(a))) + case _ => None + } + } + + override def message_content(name: String, lines: List[String]): Message = + { + def err(msg: String = ""): Nothing = + error("Malformed message: " + name + (if (msg.isEmpty) "" else "\n" + msg)) + + val (head, body) = + try { (Head.get(lines), make_body(Body.get(lines))) } + catch { case ERROR(msg) => err(msg) } + + val date = + message_match(head, """
  • Date:\s*(.*?)\s*
    • """.r) + .map(m => HTML.input(m.group(1))) match + { + case Some(Date_Format(d)) => d + case Some(s) => err("Malformed Date: " + quote(s)) + case None => err("Missing Date") + } + + val title = + make_title( + HTML.input(message_match(head, """
  • Subject:\s*(.*)
    • """.r) + .getOrElse(err("Missing Subject")).group(1))) + + val (author_name, author_address) = + message_match(head, """
  • From:\s*(.*?)\s*
    • """.r) match { + case None => err("Missing From") + case Some(m) => + val (a, b) = Address.unapply(m.group(1)) getOrElse err("Malformed From") + (if (a == b) "" else a, b) + } + + Message(name, date, title, author_name, author_address, body) + } + } + + object Isabelle_Dev extends Archive(Url("https://mailmanbroy.in.tum.de/pipermail/isabelle-dev")) + { + override def message_regex: Regex = """
  • """.r + + private object Head extends Message_Chunk(en = "") + private object Body extends Message_Chunk(bg = "", en = "") + + private object Date_Format + { + val Format = Date.Format("E MMM d H:m:s z uuuu") + def unapply(s: String): Option[Date] = Format.unapply(s.replaceAll("""\s+""", " ")) + } + + override def message_content(name: String, lines: List[String]): Message = + { + def err(msg: String = ""): Nothing = + error("Malformed message: " + name + (if (msg.isEmpty) "" else "\n" + msg)) + + val (head, body) = + try { (Head.get(lines), make_body(Body.get(lines))) } + catch { case ERROR(msg) => err(msg) } + + val date = + message_match(head, """\s*(.*)""".r).map(m => HTML.input(m.group(1))) match { + case Some(Date_Format(d)) => d + case Some(s) => err("Malformed Date: " + quote(s)) + case None => err("Missing Date") + } + + val (title, author_address) = + { + message_match(head, """TITLE="([^"]+)">(.*)""".r) match { + case Some(m) => (make_title(HTML.input(m.group(1))), make_address(HTML.input(m.group(2)))) + case None => err("Missing TITLE") + } + } + + val author_name = + message_match(head, """\s*(.*)""".r) match { + case None => err("Missing author") + case Some(m) => make_name(HTML.input(m.group(1))) + } + + Message(name, date, title, author_name, author_address, body) + } + } } diff --git a/src/Pure/Thy/html.scala b/src/Pure/Thy/html.scala --- a/src/Pure/Thy/html.scala +++ b/src/Pure/Thy/html.scala @@ -1,441 +1,447 @@ /* Title: Pure/Thy/html.scala Author: Makarius HTML presentation elements. */ package isabelle object HTML { /* attributes */ class Attribute(val name: String, value: String) { def xml: XML.Attribute = name -> value def apply(elem: XML.Elem): XML.Elem = elem + xml } def id(s: String): Attribute = new Attribute("id", s) def class_(name: String): Attribute = new Attribute("class", name) def width(w: Int): Attribute = new Attribute("width", w.toString) def height(h: Int): Attribute = new Attribute("height", h.toString) def size(w: Int, h: Int)(elem: XML.Elem): XML.Elem = width(w)(height(h)(elem)) val entity_def: Attribute = class_("entity_def") val entity_ref: Attribute = class_("entity_ref") /* structured markup operators */ def text(txt: String): XML.Body = if (txt.isEmpty) Nil else List(XML.Text(txt)) val break: XML.Body = List(XML.elem("br")) val nl: XML.Body = List(XML.Text("\n")) class Operator(val name: String) { def apply(body: XML.Body): XML.Elem = XML.elem(name, body) def apply(att: Attribute, body: XML.Body): XML.Elem = att(apply(body)) def apply(c: String, body: XML.Body): XML.Elem = apply(class_(c), body) } class Heading(name: String) extends Operator(name) { def apply(txt: String): XML.Elem = super.apply(text(txt)) def apply(att: Attribute, txt: String): XML.Elem = super.apply(att, text(txt)) def apply(c: String, txt: String): XML.Elem = super.apply(c, text(txt)) } val div = new Operator("div") val span = new Operator("span") val pre = new Operator("pre") val par = new Operator("p") val sub = new Operator("sub") val sup = new Operator("sup") val emph = new Operator("em") val bold = new Operator("b") val code = new Operator("code") val item = new Operator("li") val list = new Operator("ul") val `enum` = new Operator("ol") val descr = new Operator("dl") val dt = new Operator("dt") val dd = new Operator("dd") val title = new Heading("title") val chapter = new Heading("h1") val section = new Heading("h2") val subsection = new Heading("h3") val subsubsection = new Heading("h4") val paragraph = new Heading("h5") val subparagraph = new Heading("h6") def itemize(items: List[XML.Body]): XML.Elem = list(items.map(item(_))) def enumerate(items: List[XML.Body]): XML.Elem = `enum`(items.map(item(_))) def description(items: List[(XML.Body, XML.Body)]): XML.Elem = descr(items.flatMap({ case (x, y) => List(dt(x), dd(y)) })) def link(href: String, body: XML.Body): XML.Elem = XML.Elem(Markup("a", List("href" -> href)), if (body.isEmpty) text(href) else body) def link(path: Path, body: XML.Body): XML.Elem = link(path.implode, body) def image(src: String, alt: String = ""): XML.Elem = XML.Elem(Markup("img", List("src" -> src) ::: proper_string(alt).map("alt" -> _).toList), Nil) def source(body: XML.Body): XML.Elem = pre("source", body) def source(src: String): XML.Elem = source(text(src)) def style(s: String): XML.Elem = XML.elem("style", text(s)) def style_file(href: String): XML.Elem = XML.Elem(Markup("link", List("rel" -> "stylesheet", "type" -> "text/css", "href" -> href)), Nil) def style_file(path: Path): XML.Elem = style_file(Url.print_file(path.file)) def script(s: String): XML.Elem = XML.elem("script", text(s)) def script_file(href: String): XML.Elem = XML.Elem(Markup("script", List("src" -> href)), Nil) def script_file(path: Path): XML.Elem = script_file(Url.print_file(path.file)) /* output text with control symbols */ private val control: Map[Symbol.Symbol, Operator] = Map( Symbol.sub -> sub, Symbol.sub_decoded -> sub, Symbol.sup -> sup, Symbol.sup_decoded -> sup, Symbol.bold -> bold, Symbol.bold_decoded -> bold) private val control_block_begin: Map[Symbol.Symbol, Operator] = Map( Symbol.bsub -> sub, Symbol.bsub_decoded -> sub, Symbol.bsup -> sup, Symbol.bsup_decoded -> sup) private val control_block_end: Map[Symbol.Symbol, Operator] = Map( Symbol.esub -> sub, Symbol.esub_decoded -> sub, Symbol.esup -> sup, Symbol.esup_decoded -> sup) def is_control(sym: Symbol.Symbol): Boolean = control.isDefinedAt(sym) def is_control_block_begin(sym: Symbol.Symbol): Boolean = control_block_begin.isDefinedAt(sym) def is_control_block_end(sym: Symbol.Symbol): Boolean = control_block_end.isDefinedAt(sym) def is_control_block_pair(bg: Symbol.Symbol, en: Symbol.Symbol): Boolean = { val bg_decoded = Symbol.decode(bg) val en_decoded = Symbol.decode(en) bg_decoded == Symbol.bsub_decoded && en_decoded == Symbol.esub_decoded || bg_decoded == Symbol.bsup_decoded && en_decoded == Symbol.esup_decoded } def check_control_blocks(body: XML.Body): Boolean = { var ok = true var open = List.empty[Symbol.Symbol] for { XML.Text(text) <- body; sym <- Symbol.iterator(text) } { if (is_control_block_begin(sym)) open ::= sym else if (is_control_block_end(sym)) { open match { case bg :: rest if is_control_block_pair(bg, sym) => open = rest case _ => ok = false } } } ok && open.isEmpty } def output(s: StringBuilder, text: String, control_blocks: Boolean, hidden: Boolean, permissive: Boolean): Unit = { def output_string(str: String): Unit = XML.output_string(s, str, permissive = permissive) def output_hidden(body: => Unit): Unit = if (hidden) { s ++= ""; body; s ++= "" } def output_symbol(sym: Symbol.Symbol): Unit = if (sym != "") { control_block_begin.get(sym) match { case Some(op) if control_blocks => output_hidden(output_string(sym)) XML.output_elem(s, Markup(op.name, Nil)) case _ => control_block_end.get(sym) match { case Some(op) if control_blocks => XML.output_elem_end(s, op.name) output_hidden(output_string(sym)) case _ => if (hidden && Symbol.is_control_encoded(sym)) { output_hidden(output_string(Symbol.control_prefix)) s ++= "" output_string(Symbol.control_name(sym).get) s ++= "" output_hidden(output_string(Symbol.control_suffix)) } else output_string(sym) } } } var ctrl = "" for (sym <- Symbol.iterator(text)) { if (is_control(sym)) { output_symbol(ctrl); ctrl = sym } else { control.get(ctrl) match { case Some(op) if Symbol.is_controllable(sym) => output_hidden(output_symbol(ctrl)) XML.output_elem(s, Markup(op.name, Nil)) output_symbol(sym) XML.output_elem_end(s, op.name) case _ => output_symbol(ctrl) output_symbol(sym) } ctrl = "" } } output_symbol(ctrl) } def output(text: String): String = { val control_blocks = check_control_blocks(List(XML.Text(text))) Library.make_string(output(_, text, control_blocks = control_blocks, hidden = false, permissive = true)) } /* output XML as HTML */ private val structural_elements = Set("head", "body", "meta", "div", "pre", "p", "title", "h1", "h2", "h3", "h4", "h5", "h6", "ul", "ol", "dl", "li", "dt", "dd") def output(s: StringBuilder, xml: XML.Body, hidden: Boolean, structural: Boolean): Unit = { def output_body(body: XML.Body): Unit = { val control_blocks = check_control_blocks(body) body foreach { case XML.Elem(markup, Nil) => XML.output_elem(s, markup, end = true) case XML.Elem(markup, ts) => if (structural && structural_elements(markup.name)) s += '\n' XML.output_elem(s, markup) output_body(ts) XML.output_elem_end(s, markup.name) if (structural && structural_elements(markup.name)) s += '\n' case XML.Text(txt) => output(s, txt, control_blocks = control_blocks, hidden = hidden, permissive = true) } } output_body(xml) } def output(body: XML.Body, hidden: Boolean, structural: Boolean): String = Library.make_string(output(_, body, hidden, structural), capacity = XML.text_length(body) * 2) def output(tree: XML.Tree, hidden: Boolean, structural: Boolean): String = output(List(tree), hidden, structural) + /* input text */ + + def input(text: String): String = + org.apache.commons.text.StringEscapeUtils.unescapeHtml4(text) + + /* messages */ // background val writeln_message: Attribute = class_("writeln_message") val warning_message: Attribute = class_("warning_message") val error_message: Attribute = class_("error_message") // underline val writeln: Attribute = class_("writeln") val warning: Attribute = class_("warning") val error: Attribute = class_("error") /* tooltips */ def tooltip(item: XML.Body, tip: XML.Body): XML.Elem = span(item ::: List(div("tooltip", tip))) def tooltip_errors(item: XML.Body, msgs: List[XML.Body]): XML.Elem = HTML.error(tooltip(item, msgs.map(msg => error_message(pre(msg))))) /* GUI elements */ object GUI { private def optional_value(text: String): XML.Attributes = proper_string(text).map(a => "value" -> a).toList private def optional_name(name: String): XML.Attributes = proper_string(name).map(a => "name" -> a).toList private def optional_title(tooltip: String): XML.Attributes = proper_string(tooltip).map(a => "title" -> a).toList private def optional_submit(submit: Boolean): XML.Attributes = if (submit) List("onChange" -> "this.form.submit()") else Nil private def optional_checked(selected: Boolean): XML.Attributes = if (selected) List("checked" -> "") else Nil private def optional_action(action: String): XML.Attributes = proper_string(action).map(a => "action" -> a).toList private def optional_onclick(script: String): XML.Attributes = proper_string(script).map(a => "onclick" -> a).toList private def optional_onchange(script: String): XML.Attributes = proper_string(script).map(a => "onchange" -> a).toList def button(body: XML.Body, name: String = "", tooltip: String = "", submit: Boolean = false, script: String = ""): XML.Elem = XML.Elem( Markup("button", List("type" -> (if (submit) "submit" else "button"), "value" -> "true") ::: optional_name(name) ::: optional_title(tooltip) ::: optional_onclick(script)), body) def checkbox(body: XML.Body, name: String = "", tooltip: String = "", submit: Boolean = false, selected: Boolean = false, script: String = ""): XML.Elem = XML.elem("label", XML.elem( Markup("input", List("type" -> "checkbox", "value" -> "true") ::: optional_name(name) ::: optional_title(tooltip) ::: optional_submit(submit) ::: optional_checked(selected) ::: optional_onchange(script))) :: body) def text_field(columns: Int = 0, text: String = "", name: String = "", tooltip: String = "", submit: Boolean = false, script: String = ""): XML.Elem = XML.elem(Markup("input", List("type" -> "text") ::: (if (columns > 0) List("size" -> columns.toString) else Nil) ::: optional_value(text) ::: optional_name(name) ::: optional_title(tooltip) ::: optional_submit(submit) ::: optional_onchange(script))) def parameter(text: String = "", name: String = ""): XML.Elem = XML.elem( Markup("input", List("type" -> "hidden") ::: optional_value(text) ::: optional_name(name))) def form(body: XML.Body, name: String = "", action: String = "", http_post: Boolean = false) : XML.Elem = XML.Elem( Markup("form", optional_name(name) ::: optional_action(action) ::: (if (http_post) List("method" -> "post") else Nil)), body) } /* GUI layout */ object Wrap_Panel { object Alignment extends Enumeration { val left, right, center = Value } def apply(contents: List[XML.Elem], name: String = "", action: String = "", alignment: Alignment.Value = Alignment.right): XML.Elem = { val body = Library.separate(XML.Text(" "), contents) GUI.form(List(div(body) + ("style" -> ("text-align: " + alignment))), name = name, action = action) } } /* document */ val header: String = XML.header + """ """ val footer: String = """""" val head_meta: XML.Elem = XML.Elem(Markup("meta", List("http-equiv" -> "Content-Type", "content" -> "text/html; charset=utf-8")), Nil) def output_document(head: XML.Body, body: XML.Body, css: String = "isabelle.css", hidden: Boolean = true, structural: Boolean = true): String = { cat_lines( List( header, output( XML.elem("head", head_meta :: (if (css == "") Nil else List(style_file(css))) ::: head), hidden = hidden, structural = structural), output(XML.elem("body", body), hidden = hidden, structural = structural), footer)) } /* fonts */ val fonts_path: Path = Path.explode("fonts") def init_fonts(dir: Path): Unit = { val fonts_dir = Isabelle_System.make_directory(dir + HTML.fonts_path) for (entry <- Isabelle_Fonts.fonts(hidden = true)) Isabelle_System.copy_file(entry.path, fonts_dir) } def fonts_dir(prefix: String)(ttf_name: String): String = prefix + "/" + ttf_name def fonts_url(): String => String = (for (entry <- Isabelle_Fonts.fonts(hidden = true)) yield (entry.path.file_name -> Url.print_file(entry.path.file))).toMap def fonts_css(make_url: String => String = fonts_url()): String = { def font_face(entry: Isabelle_Fonts.Entry): String = cat_lines( List( "@font-face {", " font-family: '" + entry.family + "';", " src: url('" + make_url(entry.path.file_name) + "') format('truetype');") ::: (if (entry.is_bold) List(" font-weight: bold;") else Nil) ::: (if (entry.is_italic) List(" font-style: italic;") else Nil) ::: List("}")) ("/* Isabelle fonts */" :: Isabelle_Fonts.fonts(hidden = true).map(font_face)) .mkString("", "\n\n", "\n") } def fonts_css_dir(prefix: String = ""): String = { val prefix1 = if (prefix.isEmpty || prefix.endsWith("/")) prefix else prefix + "/" fonts_css(fonts_dir(prefix1 + fonts_path.implode)) } /* document directory context (fonts + css) */ def relative_prefix(dir: Path, base: Option[Path]): String = base match { case None => "" case Some(base_dir) => val path = File.path(dir.absolute.java_path.relativize(base_dir.absolute.java_path).toFile) if (path.is_current) "" else path.implode + "/" } def isabelle_css: Path = Path.explode("~~/etc/isabelle.css") def write_document(dir: Path, name: String, head: XML.Body, body: XML.Body, base: Option[Path] = None, css: String = isabelle_css.file_name, hidden: Boolean = true, structural: Boolean = true): Unit = { Isabelle_System.make_directory(dir) val prefix = relative_prefix(dir, base) File.write(dir + isabelle_css.base, fonts_css_dir(prefix) + "\n\n" + File.read(isabelle_css)) File.write(dir + Path.basic(name), output_document(head, body, css = css, hidden = hidden, structural = structural)) } }