panda-planner-dev / pandaPIparser

The parser of the pandaPI planning system
BSD 3-Clause "New" or "Revised" License
13 stars 10 forks source link

Parser SHOP format output contains illegal method names #19

Closed rpgoldman closed 1 year ago

rpgoldman commented 1 year ago

When I use the --shop output option, I get method names with pipe characters ("|") in them. I'm not sure what exactly is the syntax of HDDL names, but SHOP names cannot contain pipe characters (which are illegal characters in lisp symbol names).

I believe this could be fixed in the definition of the sanitize function by simply substituting "-" for "|"

rpgoldman commented 1 year ago

I was wrong. I added a line (copied from your replace(in.begin(),in.end(),'_','-'); to replace '|' with '-' but there are still pipe characters in the output. For now I pipe the output file through a perl filter that does the substitution, but it would be nice if this was changed.

galvusdamor commented 1 year ago

The | symbol gets added by some of the compilations processes that the parser performs.

The code line should be replace(in.begin(),in.end(),'|','-'); - so that any | symbol gets replaced with a -. I've already added a commit to address this issue. Can you check whether this works for you?

rpgoldman commented 1 year ago

I don't think this works yet. I updated to the latest version of pandaPIparser and then translated a rovers problem: domain.hddl.txt and p01.hddl.txt.

pandaPIparser --shop domain.hddl p01.hddl

In the output I still see some pipe characters:

  (:method (__method_precondition_check-for-all-goals-done)
    _method_for_multiple_expansions_of___method_precondition_check-for-all-goals-done|instance_1
    (

      (type_sort_for_colour ?m_0) (type_sort_for_high_res ?m_1) (type_sort_for_low_res ?m_2) (type_sort_for_objective0 ?o_3) (type_sort_for_objective1 ?o_4) (type_sort_for_waypoint0 ?w_0) (type_sort_for_waypoint1 ?w_1) (type_sort_for_waypoint2 ?w_2) (type_sort_for_waypoint3 ?w_3)

    )
    ()
  )
rpgoldman commented 1 year ago

I'm not sure if these special methods for precondition checks are emitted the same way other methods are. Normal methods all seem to be emitted correctly. When I do this:

fgrep '|' /tmp/parser.out | grep -v method_precondition_check-for-all-goals-done

I get nothing back, indicating that all the pipe characters are in methods of this form: _method_for_multiple_expansions_of___method_precondition_check-for-all-goals-done|instance_XXXXXX

It looks like somehow these are emitted in a way that avoids the invocation of the sanitise function, but to be honest, I can't figure out where they are emitted. If it's in the loop over methods here it looks like sanitise should be called on the method name in this line. 🤷‍♂️

galvusdamor commented 1 year ago

I think I solved the riddle. The problem was here. Apparently I assumed that SHOP2 allowed for the pipe symbol (and other things), but SHOP did not. If I remember correctly I tried this with JSHOP2 at the time - which might behave differently. Anyhow: The sanitation worked, but only if you run the translator in SHOP1 mode - which is not what you want.

To solve this issue, I just commented out the affected line, which now does not produce any more | symbols in the output.

Looking at the output, I discovered another issue: the method preconditions were not correctly written to the output. The code assumed that for every method precondition, there is only one instance (i.e. no disjunctive method preconditions) - which is not the case in this type of implies domain. I've added code that should fix this problem - if such disjunctive method preconditions arise, I keep the "fake"/artificial abstract task and its decomposition s.t. the method-precondition is actually there.

On a related note, apparently for this domain the translator did not output any method preconditions at all, which as also a bug that should now be fixed.

rpgoldman commented 1 year ago

@galvusdamor Thanks! This looks good now!