Proposals

[guicho271828]

• machine-readable specification of each generator, e.g. a json file for each generator, documenting the type, name, range of each argument, and the number of arguments
• refactoring: same filename / directory hierarchy for every executable
• refactoring: output name standardization

[haz]

Couldn't we accomplish the same for 2/3 if 1 included specification of the running/generation?

Reason I ask is because this will likely be nestled in planutils on its way to a remote service -- the json manifest will require the parameters, how to run, what is produced, etc. All in machine readable format (since it will be exposed automatically by the planning-as-a-service server).

[jendrikseipp]

I think all three points would be nice to have, though 1 is definitely higher-priority than 2 and 3. And I agree with Christian that probably it's easiest to put everything into the specification.

[haz]

Ya, so give us a chance to take a crack at the sophisticated manifest, and see how much of 1-2-3 we can knock off.

@jendrikseipp : What's the easiest way to start plugging away at 1? Just check into the source for things like this?

[jendrikseipp]

For our benchmarks generation paper, we have looked into parameter ranges a bit and I think Alvaro added some notes to README files. We'll try to integrate those soon. This should make it a bit easier to get started with some domains. But apart from that, yes, invoking the generator without arguments and hoping it prints a help message :-)

[jendrikseipp]

I started a project with similar goals: https://github.com/rleap-project/batch-pddl-generator It allows to define parameter ranges and then generate the Cartesian product of PDDL files. Importantly, the specification of each domain uses Python code. This allows to programmatically check for valid parameter combinations.

[guicho271828]

Importantly, the specification of each domain uses Python code.

I would much prefer one that is language-agnostic.