jmjrawlings/minizinc.net

MiniZinc ↔ .NET

minizinc.net's Issues

Support dot access for tuples and records

MRE:

record(int: a, int: b): x;
constraint x.a = 1;

A dzn specific parser

The --json-stream solution messages contain dzn syntax of the solution variables.

While the full model parser could certainly handle this we should instead make a specialised parser optimised for only these "name = expr" assignments.

Parsing dzn from file/string is worthwhile

Support CancellationToken while solving

There is a time limit command line argument MiniZinc but we should also allow CancellationToken to support instance where, for example, a GUI user wants to cancel a solve in progress.

This probably replaces the need to use the CLI arg entirely as it is much more flexible.

Copy included models when solving

client.Solve fails when solving a model with an included .mzn file.

We need to either update include statements to point to an absolute filepath, or more appropriately just copy the included model into the working directory

Use TestSuites for `Model.Tests`

Support array slicing with `..`

Example in record_var_ite.mzn

Achieve libminizinc 100% parser test coverage

Support writing indexed arrays

Allow certain tests to only run for certain minizinc versions

For instance record tests should only run when client is v2.7.*

Merge/combine models

We need the capabilty to combine or merge two or more separate Models.

This is a generally useful thing to be able to do, but more specifically it would provide a direct way to handle include statements. We could simply Model.parseFile the included mzn, then combine the two models.

Obvious error cases here are binding conflicts between the two models so some options are required:

• Use binding from left model
• Use binding from right model
• Use a custom function that takes both

Infer correct `Inst` value based on records/tuples/array etc

Consider the two:

array[1..3] of record(var bool: a): x;

array[1..3] of var record(bool: b): y;

Only the second example would have Inst = Inst.Var in the AST.

We want this information at the top level to correctly identify decision variables without having to traverse the whole ast.

Client integration tests from libminizinc

A client integration test would be the following:

• Parse the test file
• Solve the test model using options specific
• Compare solutions to expected test case results

Achieve 100% libminizinc client test coverage

Handle comments inside parser

Currently we strip out line and block comments before feeding the normalised source into the parser. It would be better to do it all in one parse, now that I have a better handle on creating low level parsers it should be fairly straightforward.

Solver specific clients

Different solver backends have different features and flags. It would be nice to surface these in a native way so the user can avoid dealing with command line flags. Something like GecodeClient :> IMiniZincClient would be great.

Knowing what statistics are returned by which solver is very valuable as well, so a client should be strong typed on its inputs and outputs.

Models solved using the solver specific client would naturally have the --solver flag appended.

We should aim for gecode, cbc and chuffed for a v1.0 release.

A compile step before solving

There are quite a few things to take care of before solving a model:

• Ensure par variables must all have been assigned
• Identify all var solution variables
• Serialize the model to a string
• Write the model to an .mzn file

To separate concerns a bit better we should perform the above in a compilation step, and that way the various solve methods can operate on a nicely type CompiledModel

Support Annotations

Supported indexed 2D array literals

Handle line and block comments inside the parser directly

Currently we feed models through the parseComments function to strip them of all comments before proceeding to the main parser. This is error prone (eg: it doesn't properly handle '%' inside of quoted string). It also means we are iterating over each file twice which is not ideal. Handling of comments should be integrated directly into the fparsec parser, possibly through some custom whitespace parser

Detect which `includes` are builtin, and which are external

Included models that are part of the standard library eg: "globals.mzn" do not need to be saved alongside our generated model so we need a way of identifying them

Support anonymous enums

Support `--model-interface-only` in Client

Create solver test suite from libminizinc test suite

Convert MiniZinc types to .NET types

Given the minizinc types from the AST we want to translate directly to .NET types where possible. Technically we could implement our own algebra on top of the AST but this seems like total overkill.

Best case scenario here is being able to directly convert 1d/2d array etc to .NET array types and back again.

Parse included models

for models reference via the include statement eg: includes "battleships.mzn" the parsing process should be able to follow these links if desired.

This is an important feature as it is the primary means of composition in minizinc

Parser performance profiling

I would like to know the performance characteristics of the parser so any code changes can have their effect on performance quantified. I also want insight into any bottlenecks to focus on.

The usual suspects are of interest:

• elapsed time
• memory
• allocations

Support complex enum constructors

Encode <-> Parse roundtrip tests

parse a model
encode the model
parse it again
models should be equivalent

Solve libminizinc test suites with Client

Model equality

If we roundtrip from Mzn -> Model -> Mzn -> Mzn, we need a way to determine if the models are equivalent. String comparison is not a good option, some sort of comparison between AST seems necessary.

Support `++` in declarations

tuple(int, float) ++ tuple(bool): con1 ::output = (1, 2.0) ++ (true,);

We should just flatten the above into a tuple(int, float, bool) = (1, 2.0, true) to avoid unnecessary complexity in the Expr union

Supported indexed 1D array literals

https://www.minizinc.org/doc-2.7.3/en/spec.html#indexed-array-literals

Parse test suite from embedded yaml

Included in the test specs from the official repository there are solutions and expected results. These are perfect test cases if we can parse the comments properly.

Example:

/***
!Test
expected:
- !Result
  solution: !Solution
    a:
    - [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    - [0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0]
    - [0, 1, 0, 0, 0, 0, 0, 0, 2, 0, 0]
    - [0, 2, 0, 0, 0, 1, 0, 0, 3, 0, 0]
    - [0, 0, 0, 1, 0, 2, 0, 0, 0, 0, 0]
    - [0, 0, 0, 2, 0, 0, 0, 0, 0, 1, 0]
    - [0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0]
    - [0, 1, 0, 0, 0, 0, 1, 2, 3, 4, 0]
    - [0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    - [0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0]
    - [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
    col_sums: [4, 0, 3, 2, 2, 2, 1, 4, 2]
    row_sums: [2, 2, 3, 2, 2, 1, 5, 1, 2]
***/

Model integration tests from libminizinc

A model integration test is the following pseudocode:

model1 = parse(input)
string1 = encode(model)
model2 = parse(string1)
string2 = encode(model2)

assert model1 == model2
assert string1 == string2 (unlikely to pass, optional)

Suport `--model-types-only` in client

Publish release via build project script

Support 3D Arrays

MRE:

array[Index, Index, Index] of int: matrix = [| | | |];

Infer model inputs from AST

Give the model AST we want to know which variable have already been assigned or which variable still need assignment. Those variables requiring assignment becomes parameters for the model

Encode models to mzn string

Serialize a model as an Mzn string

Resolve variable assignment in nested contexts

Currently the model combines declare and assign items in a global context. This will not work if, for instance, varaible X is declared on the top level and then assigned inside of a let block. That would erroneously be a conflicted binding.

Ensure spawned minizinc processes are properly disposed

Not sure how to do this honestly a bit of research required