* [ fix ] .ipkg install dir
* [ test ] .ipkg install dir
* [ doc ] update CHECKLIST
* [ doc ] add explanation to pkg016 test
* [ cleanup ] no need to clutter CHECKLIST
* [ admin ] Update CHANGELOG and CONTRIBUTORS
We really need to do a release at some point...
* [ ci ] Don't check capitalised proper names in links and code
Sometimes hyperlinks and code-blocks just don't use the "proper"
capitalisation (e.g. `.html` vs `.HTML`), and that's okay.
(or even critical as links may not be found without "incorrect" format)
* [ ci ] Don't check terminology in links and code-blocks
Hopefully this is the right fix for the problem in #2703
* [ ci ] 3rd attempt at fixing nl linter
* [ ci ] Attempt no. 4 at fixing nl linter
* [ ci ] Point NL linter at YAML config file
Was that actually it??
* Update CHANGELOG.md
* Add note about forward declaration of records
* [ admin ] Add PR template with CHANGELOG reminder
To hopefully help mitigate big crawl-throughs of what's changed,
à la #2703.
* [ admin ] Reflow CHANGELOG to 80 characters where possible
Only done for the "next version" changes for the sake of diff size.
(Personally, I'd want to have the linter enforce this, but that might be
too extreme; there's already a note in the CI config complaining about
line length...)
* [ admin ] Make linter happy
It never ends...
Co-authored-by: Joel Berkeley <16429957+joelberkeley@users.noreply.github.com>
Co-authored-by: Steve Dunham <dunhamsteve@gmail.com>
A common issue for users is that the behaviour of the various repl
commands are not documented anywhere despite some of them having complex
behaviour (e.g. `:set` which accepts a specific set of options). This
implements the ability to call `:?|:h|:help` on repl commands to request
detailed help for a specific repl command, while preserving the
behaviour that calling the help command without any arguments prints the
general help text.
Generic help is defined as the first line of the help text.
Detailed help is defined as the entire help text.
This means that `:help :t`, for example, does not error (there is no
detailed help) but instead just prints the single line of help text.
* [ repl ] Use unlines for detailed help (see #2087)
Ideally, the lines affected should be multiline strings. But for some
arcane reason, newlines in those get swallowed in Nix and Windows
**CI** only Ô.o
This was already documented in issue #2087.
* [ new ] --except for golden testing lib
To allow CI to pass despite #2087
Co-authored-by: Guillaume Allais <guillaume.allais@ens-lyon.org>
I don't think there's a good solution at least until we start
parsing these comments so let's just keep them as they were written
by the library writer.
This completes the implementation of the examples in the paper
"Applications of Applicative Proof Search" (Liam O'Connor, 2016).
Unfortunately, the final example is an example of something that _can_
be expressed, but _cannot_ be model-checked by the approach in the
paper.
(Side note on `petersonsCorrect`: The paper mentions that it checks in
~3 minutes on a 2013 MacBook Pro. Assuming they mean "type-checks", this
is roughly consistent with our observations of just short of 2 minutes.
I doubt that they evaluated it, since an attempt at doing this on a
reasonably modern server (Intel Xeon Gold 5220R, 502 GB of RAM) was
killed after just over 3 hours, producing the following resource log:
Command exited with non-zero status 255
Time: 11320.46s user, 35.12s system, 3h09m46s elapsed, 99%CPU
Memory: 57644016 Kbytes RAM
)
On average across 10 runs on an Intel Core i7-8750H with 15.2GB of
available system memory (16GB installed in system), type-checking
`libs/papers/Search/GCL.idr` WITH `petersonsCorrect` takes:
* 1 minute 48.7 seconds, consuming 3.92GB of RAM
By contrast, commenting `petersonsCorrect` out results in type-checking
taking on average (same #runs, same config):
* 0 minutes 1.2 seconds, consuming 0.25GB of RAM
And good luck trying to evaluate the thing!
(This might be a good performance test at some point, but uh, we're not
there yet...)
