Created on 2017-12-21.13:49:58 by guillem, last changed by florian.
Related issues:
* issue526 (consistent use of shared pointers for plugins)
* issue740 (configurable output file of translator)
* issue509 (introduces the task class, in particular issue700
will get rid of a lot of global variables)
|
msg6801 (view) |
Author: florian |
Date: 2018-02-09.17:39:38 |
|
I added the related issues to the summary (and added issue509) where it's easier
to keep track of them and possible to update the list.
Also, FYI: if you just write issueXYZ for an issue number XYZ, the tracker will
create links and tool tips for you.
|
msg6798 (view) |
Author: guillem |
Date: 2018-02-09.16:18:36 |
|
Just for the (mostly my own) record, I'm listing here a few issues the closing of which will be good for this project. I'll keep updating this list:
* http://issues.fast-downward.org/issue526 (having shared_ptr used consistently in those objects that we want to expose to the Python module, such as the heuristic, would simplify memory ownership issues)
* http://issues.fast-downward.org/issue740 (not a big thing, but will make the Python module initialization code slightly cleaner)
|
msg6762 (view) |
Author: guillem |
Date: 2017-12-22.11:17:27 |
|
Sure, could be helpful as a starting / comparison point.
|
msg6761 (view) |
Author: florian |
Date: 2017-12-21.15:01:49 |
|
We developed an interface from PSVN to Fast Downward as part of a project once.
In that interface, PSVN used Fast Downward as a library. It wasn't super
efficient because the changes to the task class were not ready then.
But if it helps I can dig up the source code and the documentation from the project.
|
msg6760 (view) |
Author: florian |
Date: 2017-12-21.14:51:17 |
|
(Moved from summary field)
We'd like to offer the user the possibility of interacting "programmatically"
with the planer. This is a high-level issue / wishlist of features that could
be
related to this goal, and which could include, for instance,
(1) Offering a Python interface (i.e. creating one or more Python modules with
well-designed interfaces that bind with the C++ library) for creating planning
problems programmatically.
(2) Offering a Python / C++ interface for easily specifying the options of the
different plugins, in a way alleviating the need for complex command-line
option
parsing.
(3) Offering the possibility of subclassing certain interfaces in order to
specify (in a possibly domain-dependent manner) the desired search behaviour,
or
additional control information.
(4) Offering the possibility of using symbols whose denotation is defined
through
C++ / Python functions.
(5) ...
Good examples/inspiration for some/all of the above points could include for
instance:
(A) The Gecode CSP solver (http://www.gecode.org/doc-latest/MPG.pdf), which
beyond the ability to process problems specified in declarative languages such
as
flatzinc, offers different ways to declare CSP problems by extending the
appropriate C++ classes, etc., as well as to control the solving process.
(B) The z3 SMT solver, which offers an elegant Python API to declare SMT
problems, instantiate solvers with different options, and solve the problems
(simple example:
https://github.com/Z3Prover/z3/blob/master/examples/python/socrates.py)
|
|
Date |
User |
Action |
Args |
2018-02-09 17:39:38 | florian | set | messages:
+ msg6801 summary: Related issues:
* issue526 (consistent use of shared pointers for plugins)
* issue740 (configurable output file of translator)
* issue509 (introduces the task class, in particular issue700
will get rid of a lot of global variables) |
2018-02-09 16:18:36 | guillem | set | messages:
+ msg6798 |
2018-01-04 14:17:22 | silvan | set | nosy:
+ silvan |
2017-12-22 11:17:28 | guillem | set | messages:
+ msg6762 |
2017-12-22 11:16:52 | guillem | set | nosy:
+ guillem |
2017-12-21 15:01:49 | florian | set | messages:
+ msg6761 |
2017-12-21 14:51:17 | florian | set | nosy:
+ florian messages:
+ msg6760 summary: We'd like to offer the user the possibility of interacting "programmatically"
with the planer. This is a high-level issue / wishlist of features that could
be
related to this goal, and which could include, for instance,
(1) Offering a Python interface (i.e. creating one or more Python modules with
well-designed interfaces that bind with the C++ library) for creating planning
problems programmatically.
(2) Offering a Python / C++ interface for easily specifying the options of the
different plugins, in a way alleviating the need for complex command-line
option
parsing.
(3) Offering the possibility of subclassing certain interfaces in order to
specify (in a possibly domain-dependent manner) the desired search behaviour,
or
additional control information.
(4) Offering the possibility of using symbols whose denotation is defined
through
C++ / Python functions.
(5) ...
Good examples/inspiration for some/all of the above points could include for
instance:
(A) The Gecode CSP solver (http://www.gecode.org/doc-latest/MPG.pdf), which
beyond the ability to process problems specified in declarative languages such
as
flatzinc, offers different ways to declare CSP problems by extending the
appropriate C++ classes, etc., as well as to control the solving process.
(B) The z3 SMT solver, which offers an elegant Python API to declare SMT
problems, instantiate solvers with different options, and solve the problems
(simple example:
https://github.com/Z3Prover/z3/blob/master/examples/python/socrates.py) -> (no value) |
2017-12-21 14:17:25 | jendrik | set | nosy:
+ jendrik summary: We'd like to offer the user the possibility of interacting "programmatically"
with the planer. This is a high-level issue / wishlist of features that could be
related to this goal, and which could include, for instance,
(1) Offering a Python interface (i.e. creating one or more Python modules with
well-designed interfaces that bind with the C++ library) for creating planning
problems programmatically.
(2) Offering a Python / C++ interface for easily specifying the options of the
different plugins, in a way alleviating the need for complex command-line option
parsing.
(3) Offering the possibility of subclassing certain interfaces in order to
specify (in a possibly domain-dependent manner) the desired search behaviour, or
additional control information.
(4) Offering the possibility of using symbols whose denotation is defined through
C++ / Python functions.
(5) ...
Good examples/inspiration for some/all of the above points could include for
instance:
(A) The Gecode CSP solver (http://www.gecode.org/doc-latest/MPG.pdf), which
beyond the ability to process problems specified in declarative languages such as
flatzinc, offers different ways to declare CSP problems by extending the
appropriate C++ classes, etc., as well as to control the solving process.
(B) The z3 SMT solver, which offers an elegant Python API to declare SMT
problems, instantiate solvers with different options, and solve the problems
(simple example:
https://github.com/Z3Prover/z3/blob/master/examples/python/socrates.py) -> We'd like to offer the user the possibility of interacting "programmatically"
with the planer. This is a high-level issue / wishlist of features that could
be
related to this goal, and which could include, for instance,
(1) Offering a Python interface (i.e. creating one or more Python modules with
well-designed interfaces that bind with the C++ library) for creating planning
problems programmatically.
(2) Offering a Python / C++ interface for easily specifying the options of the
different plugins, in a way alleviating the need for complex command-line
option
parsing.
(3) Offering the possibility of subclassing certain interfaces in order to
specify (in a possibly domain-dependent manner) the desired search behaviour,
or
additional control information.
(4) Offering the possibility of using symbols whose denotation is defined
through
C++ / Python functions.
(5) ...
Good examples/inspiration for some/all of the above points could include for
instance:
(A) The Gecode CSP solver (http://www.gecode.org/doc-latest/MPG.pdf), which
beyond the ability to process problems specified in declarative languages such
as
flatzinc, offers different ways to declare CSP problems by extending the
appropriate C++ classes, etc., as well as to control the solving process.
(B) The z3 SMT solver, which offers an elegant Python API to declare SMT
problems, instantiate solvers with different options, and solve the problems
(simple example:
https://github.com/Z3Prover/z3/blob/master/examples/python/socrates.py) |
2017-12-21 13:49:58 | guillem | create | |
|