Issue619

Title get rid of need to list plugin types manually (otherwise --help crashes for core compilations)
Priority bug Status resolved
Superseder Nosy List florian, jendrik, malte, silvan
Assigned To jendrik Keywords
Optional summary
Part of issue588.

Created on 2016-01-08.15:11:39 by silvan, last changed by jendrik.

Summary
Part of issue588.
Messages
msg6351 (view) Author: jendrik Date: 2017-05-07.18:10:50
Merged and pushed.
msg6348 (view) Author: malte Date: 2017-05-07.17:52:16
Yes, looks good!
msg6346 (view) Author: jendrik Date: 2017-05-07.17:40:20
I took care of your comments. Can we merge this?
msg6344 (view) Author: malte Date: 2017-05-07.15:18:10
I made some more comments.

I think one reviewer is indeed enough given that you already verified the
output, and in any case if anything goes seriously wrong here, the build bot is
likely to let us know about it.
msg6343 (view) Author: jendrik Date: 2017-05-07.14:51:46
If you're happy with the changes, Malte, maybe Silvan doesn't need to take a look 
after all?
msg6342 (view) Author: jendrik Date: 2017-05-07.14:50:55
Thanks, I hope my commit takes care of your comments.
msg6341 (view) Author: malte Date: 2017-05-07.13:22:19
I've had a look and made a few comments.
msg6338 (view) Author: silvan Date: 2017-05-05.10:39:51
I can have a look at it, but don't know when yet (likely not today, and likely
earliest on Monday).
msg6337 (view) Author: jendrik Date: 2017-05-05.10:34:56
I made a pull request at 
https://bitbucket.org/jendrikseipp/downward/pull-requests/69

The help output is identical with the only difference being that now we sort the 
plugin type names alphabetically. Previously they were not sorted.

Any volunteers for reviewing it?
msg6329 (view) Author: jendrik Date: 2017-05-03.10:00:55
I'll try to find a solution for this. Changed the title to reflect the main change 
in this issue.
msg5063 (view) Author: malte Date: 2016-01-08.23:21:57
This makes sense. I forgot that these are still explicitly referenced by the
option parser code. So this one will go away automatically once we finish what
we started with the option parser. I don't think it's worth doing anything about
this in the meantime, but perhaps someone wants to take this as extra motivation
to contribute to the ongoing option parser effort. :-)

> By the way, the first occurrence of this bug was for Synergy, whose type plugin
> is defined in landmarks/lama_synergy.cc. I think it should be in
> options/synergy.cc instead. This isn't a solution for the overall problem, but I
> think it makes more sense to have the plugin definition next to the class
> definition, not next to its usage.

Synergy is special in some ways to the option parser because it returns two
things, and things leads to additional ugliness in the current code. I suggest
we also ignore this because we want to get rid of synergies in the long run.
(They are not actually needed; the same thing can be achieved without the
double-assignment option syntax with a wee bit of trickery that I didn't think
of when we first added this.)
msg5062 (view) Author: florian Date: 2016-01-08.22:18:51
I ran this in gdb and found the reason, but I don't know what to do about it.

If files that define PluginTypePlugins are disabled, then the help generation
for those classes will crash because it will try to access information about
those plugins.

If we get rid of the need to explicitly specify types for the help output in
issue588, this would fix the issue. Until then, I don't know how to avoid this.
Would it be problematic to leave it like this for now?


By the way, the first occurrence of this bug was for Synergy, whose type plugin
is defined in landmarks/lama_synergy.cc. I think it should be in
options/synergy.cc instead. This isn't a solution for the overall problem, but I
think it makes more sense to have the plugin definition next to the class
definition, not next to its usage.
msg5049 (view) Author: silvan Date: 2016-01-08.15:11:39
When compiling with only
PLUGIN_BLIND_SEARCH_HEURISTIC_ and
PLUGIN_EAGER_SEARCH_ENABLED
enabled, ./fast-downward.py --help crashes.
History
Date User Action Args
2017-05-07 18:10:50jendriksetstatus: reviewing -> resolved
messages: + msg6351
2017-05-07 17:52:16maltesetmessages: + msg6348
2017-05-07 17:40:20jendriksetmessages: + msg6346
2017-05-07 15:18:10maltesetmessages: + msg6344
2017-05-07 14:51:46jendriksetstatus: in-progress -> reviewing
messages: + msg6343
2017-05-07 14:50:55jendriksetmessages: + msg6342
2017-05-07 13:22:19maltesetmessages: + msg6341
2017-05-05 10:39:51silvansetmessages: + msg6338
2017-05-05 10:34:56jendriksetmessages: + msg6337
2017-05-03 10:00:55jendriksetstatus: deferred -> in-progress
title: ./fast-downward.py --help crashes when using a core compilation -> get rid of need to list plugin types manually (otherwise --help crashes for core compilations)
nosy: + jendrik
messages: + msg6329
summary: Deferred until we fix issue588. -> Part of issue588.
assignedto: jendrik
2016-01-09 11:32:54floriansetstatus: chatting -> deferred
summary: Deferred until we fix issue588.
2016-01-08 23:21:57maltesetmessages: + msg5063
2016-01-08 22:18:51floriansetstatus: unread -> chatting
messages: + msg5062
2016-01-08 15:16:28floriansetnosy: + florian
2016-01-08 15:11:39silvancreate