ariadne-cps/pronest

Nested property management, to construct and search values inside a tree of properties of a tool

ProNest

ProNest is a library for handling nested properties. It is meant to expose software properties whose values can be defined in a range. The purpose it to be able to obtain the set of all allowed values, to execute the software with multiple values and find the best one according to given metrics.

Building

To build the library from sources in a clean way, it is preferable that you set up a build subdirectory, say:

$ mkdir build && cd build

Then you can prepare the build environment, choosing a Release build for maximum performance:

$ cmake .. -DCMAKE_BUILD_TYPE=Release

At this point, if no error arises, you can build with:

$ cmake --build .

The library is meant to be used as a dependency, in particular by disabling testing as long as the tests target is already defined in an enclosing project.

Contribution guidelines

If you would like to contribute to ProNest, please contact the developer:

• Luca Geretti [email protected]

pronest's Issues

Clarify use of list or set in configuration search space

While the space is constructed from a set, the internal structure is a list. This must be clarified.

Introduce constraints on property values

We should support the definition of constraints across a given configuration, in order to limit the values taken in the search space. As such, we need to import the symbolic module in a dedicated version that supports the Property type and the related basic values.

As a result, we should remove range setting, only relying on setting single value and unsetting it. All ranges would be expressed as constraints instead.

Support heterogeneous property spaces

When the property is a handle or an interface, then different classes can be used each one having different properties. We shall support identifying the search space and validating a generic point in that space.

Allow conversion to be overridden

While a default conversion is necessary (when not the identity), a different conversion might be desired for a specific problem.

Allow construction of converter from lambda

We should allow the construction from a lambda directly. First we need to get rid of conversion from the value domain to the search domain, in order to have only one lambda (the conversion back necessary for the actual configuration).

Allow unbounded values for properties

We should support the case when a property is not bounded on one or both sides. This affects the ability to enumerate all states, so we should be able to extract the finite subspace too.