Skip to content

[fud2] Planners resolve filename ambiguities arbitrarily #2612

@jku20

Description

@jku20

Context on how the SAT planner works at the top of this file

Currently the op_list_converter function is used to assign file names. This function does a bad job: it can't nicely handle the case where multiple files have the same state. For example, if there is file f1.state1 and f2.state1 and an op taking a file in state1, the planners do not know which file to provide to the op

There is no way for planners to resolve the ambiguity of how to assign filenames to states on its own. Here are some ideas for solutions:

  • Add another way for the user to add constraints on which op outputs are used as inputs to other ops. This constraint can then be encoded in a planner. Here's an ill-formed idea for the SAT planner. The filename selection itself can be encoded in a similar way to how op names are encoded (these are effectively the same problem as two ops can have the same signature, the extra constraints corresponding to the through arg fud2 takes). This technique requires the number of filenames for a given state to be known up front when creating an instance. Choosing some reasonable constant is maybe okay here. I haven't fully thought through this idea and this technique might not work or be really complicated.
  • Add another way for the user to add constraints as above, but do some post processing file renaming step based on these constraints which is more cleaver than the current op_list_converter.
  • Make the mapping from filenames to states unambiguous by adding constraints on which ops can exist. One way to do this is by adding a new type of op argument, a "set of a state argument". This lets that op take in an unordered list of files in a given state (for example, maybe the op is gcc and it's set argument is an unordered list of C files, files with the "C" state). If the planner includes the constraint that if an op in a plan has a return value or argument of state "s", there can be no other ops with a return value an argument of state set of "s", then the file mapping can be made unambiguously (as the set is unordered).

I personally like the last idea the best, though unlike the other two, it requires work across fud2's stack (the scripting language frontend and the backend). The second idea is likely the easier and the first is probably the hardest. Maybe there are more ideas I'm missing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C: fud2experimental driver

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions