Sometimes the output of a command is not important, in these cases
`doctest` complains nonetheless. This commit introduces a
`IGNORE_OUTPUT` option which still allows checking that the command
executes correctly but skips the checking of the output with the
expected one. In addition to this the `test_docs` command now can parse
a `ignoreoutput` option in the python block which will:
* if numbers are specified (e.g. `ignoreoutput=1,2`): the specified
line numbers will have `# doctest: +IGNORE_OUTPUT` added at the end
of the specified line numbers.
* Without numbers (e.g. `{python ignoreoutput}`) then all lines will
have a `# doctest: +IGNORE_OUTPUT` appended.
Add a python interface (`revng.profile`) for interacting with the rev.ng
infrastructure as a whole; either through the CLI (`CLIProject`) or the
GraphQL API (`DaemonProject`).
The logic of the `revng ptml` command was too tightly coupled with the
parsing of the xml. Overhaul the structure of the ptml code and split it
in two locations:
* `revng.ptml`: this module contains functions that allow easy
manipulation of PTML, both for printing it and for obtaining the split
metadata/text version.
* `revng.internal.cli._commands.ptml`: this implements the actual `revng
ptml` command. This leverages the new logic in the `revng.ptml` module
while maintaining the same functionality.
Implement a downstream load/save handler in `revng.internal.api.Manager`
class which handles loading and saving files from a local directory to
a s3 server.
Package revng's python code in two wheels: `revng` and `revng_internal`.
The revng wheel contains the
`revng.{pipeline_description,model,tupletree}` modules, while the
`revng_internal` one everything under `revng.internal`.
Add the PipelineDescription object that describes the structure of a
pipeline. This will be used by all the downstream users instead of
pipeline accessor methods via PipelineC.
Add support for tracing onto the PipelineC. This is done by:
1. Creating wrapper functions for each PipelineC function with the
script in `scripts/PipelineC_add_tracing.py`. These will call a
special function called `wrap` which will ultimately call a method
with a `_` prepended to the name
2. Conversion of all PipelineC methods in `PipelineC.cpp` to `static`
and their rename with a `_` in front, in order for them to work with
the wrapper function in (1)
3. Generation of 2 additional include files, one for types and one for
functions, to be used by users of tracing files in order to have
introspection.
These steps allow the creation of a trace file with the use of the
`REVNG_C_API_TRACE_PATH` environment variable. The traces can then be
used in conjunction with the `revng trace run` and `revng trace
inspect` commands.
This new command will, given an executable, try to produce all
artifacts. By default it will run `revng daemon`, however an external
address can be provided to test remote daemons, e.g. running inside a
container.
This Oython tool will be used to easily work with PTML.
It currently features two subcommands:
* `cat` prints a PTML to the terminal, with color formatting if
possible;
* `strip` will strip a file of the PTML markup;
Add the possibility of passing a list of FIFOs to `revng daemon`. These
can be used to notify an external program when a non-reproducible change
(binary, context) has occurred.
Splits the module in 2:
* static_handlers: as the name suggests this is where handlers for
static endpoints (e.g. not dependent on the pipeline) are implemented
* schema_generator: this is where the schema is generated from a
manager's pipeline definition, together with the handler for the
autogenerated endpoint
`revng.api` now autodetects files (libraries, pipeline yamls) for
initialization via the same mechanism used by `revng.cli`. This removes
the need to pass them via environment variables from `revng daemon`
and allows easy interaction with python's C API.
This commit adds the newly implemented functionality in PipelineC both
in revng.api and the graphql api, allowing:
* retrieval of global variable names
* unwrapping of a single target
* execution of analyses
In the future we will need to use GraphQL subscriptions. This is done
via websockets and is supported in Ariadne. However this support is
limited to ASGI frameworks, which Flask isn't a part of.
Startlette is a direct depencency of Ariadne, and all of Ariadne's
features are fully integrated with Starlette, so the switch allows to
drop some Flask integration cruft and streamline the revng.daemon
package.
Starlette does not have a built-in development server, instead
Hypercorn, which is an ASGI-compliant HTTP server, is used in place of
Flask's Werkzeug/Gunicorn for both the development and production
server roles.
This commit introduces the `revng.daemon` Python module, a Flask-powered
web application that exposes the functionality from `revng.api` across a
GraphQL API
Giacomo Vercesi