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>
Without this change install-libs will not install the .so files, and
consequentially the test 'chez/chez033' fails with 'Error: INTERNAL
ERROR: Missing .so:Prelude/Cast.so' when it is run by an installed
executable.
Also add a test-installed makefile target to run the tests using the
installed executable.
* Update version numbers and bootstrap scheme
* Use wall clock time for search timeouts
That was always the intention in any case, rather than the process time.
... instead of `bootstrap` which contains source files. Make it easier to understand
how build works, and in particular, which files are sources and
which files are generated.
This adds a new flag '--inc <backend>' which, if set, compiles all
modules incrementally, and for executables, links the incrementally
compiled modules rather than building the whole program.
Also, adds an environment variable IDRIS2_INC_CGS for providing a comma
separated list of backends to use for incremental builds.
Also, adds '--whole-program', which overrides incremental builds for an
executable.
Incremental builds are much faster if there's nothing to recompile, but
for the Chez backend, generate code which runs at about half the speed.
Currently only works for Chez - other backends ignore the flag.
Also, incremental building of an executable will only work if *all*
required modules have been built incrementally for the backend in use.
Why:
* To implement robust cross-project go-to-definition in LSP
i.e you can jump to definition of any global name coming
from library dependencies, as well as from the local project files.
What it does:
* Modify `FC`s to carry `ModuleIdent` for .idr sources,
file name for .ipkg sources or nothing for interactive runs.
* Add `--install-with-src` to install the source code alongside
the ttc binaries. The source is installed into the same directory
as the corresponding ttc file. Installed sources are made read-only.
* As we install the sources pinned to the related ttc files we gain
the versioning of sources for free.
* Banners for test pools
* Summary with the list of failing tests at the end
* Option to write the list of failing tests to a file
* Option to read the list of tests to run from a file
* Using these two latest features to add a new make target to rerun precisely the tests that failed last time
Rather than tracking how far we are from the project root in the various
Makefile commands, it's much easier to reference the build target with
with an absolute path.
If they're big, they take a long time to instantiate, and if they
consist of a lot of functions, chances are that normalising them will
make them much smaller. This significantly improves type checking
performance for some programs with lots of type level computation going
on.
The threshold is set with %nf_metavar_threshold, but the default value
of 50 is probably fine. Set it to 0 to always normalise metavar
solutions, or something higher than 1000 to essentially never do it.
It's roughly a count of nodes in the typechecked syntax tree under the
first function application.
Written by Volkmar Frinken (@vfrinken). This is intended as a
lightweight (i.e. minimal dependencies) code generator that can be
ported to multiple platforms, especially those with memory constraints.
It shouldn't be expected to be anywhere near as fast as the Scheme back
end, for lots of reasons. The main goal is portability.
