Correcting input file path for planners running on WSL

[d-vyd]

Hi Jan,

This is a fantastic extension. Thank you! I've been able to successfully run several planners on my local Windows 11 machine. However, I'm trying to call sgplan5, which is installed in a WSL Ubuntu installation. The problem is that sgplan5 can't access my domain and problem files via the standard Windows path. Right now my JSON looks like:

            "title": "sgplan5",
            "kind": "COMMAND",
            "path": "wsl -d Ubuntu \"/mnt/c/Program Files/PLANNERS/sgplan522/sgplan522\"",
            "syntax": "$(planner) -o $(domain) -f $(problem) $(options) ",
            "canConfigure": true

The planner starts, but complains that it can't find the input files. Instead of C:\Users\dvyd\AppData\Local\Temp\domain--20268-BWwtqkMLvKag-.pddl the domain and problem paths need to look something like /mnt/c/Users/... I think replacing C:\ with /mnt/c/ and then switching the direction of all remaining slashes might do the trick. Is there anyway of accomplishing that in the planner setup?

Thank you,
-david

[jan-dolejsi]

Yes, that is a real problem. I thought we should handle the case, where both the pddl code and the planner are located in the wsl mount.

[d-vyd]

I mostly develop on Windows, but there are a few planners that I could not compile on Windows, so I access them via WSL. My goal was to test the same PDDL files against several different planners to understand strengths and weaknesses. What do you suggest? Put all planners and PDDL files on WSL?

[jan-dolejsi]

Yes. I would clone the repo with the PDDL code onto WSL (where the planners are) and work with it as with a Remote workspace in VS Code. The VS Code extension then loads on the WSL side and should** correctly handle the temp files.

**I yet need to test that myself. But if you find issues, please include details here. That is a workflow that we need to support.

[jan-dolejsi]

I've finally tested the extension on WSL - in the mode where the repository with the PDDL files is cloned inside WSL and opened in VS Code running in Windows using the Remote-WSL: Open Folder in WSL... command.
Once in WSL, add a planner that is local in that distro using the usual facilities on the PDDL Overview Page.
The configuration then sits in the machine settings file (as oppose to user or workspace) that can be viewed using the Preferences: Open Remote Settings (JSON) (WSL: Ubuntu-xx.yy) command.

Under the hood, this is stored in $HOME/.vscode-server/data/Machine/settings.json. Example:

{
    "pddl.planners": [
        {
            "kind": "pddl4j",
            "canConfigure": true,
            "path": "$HOME/c/github/pddl4j/build/libs/pddl4j-3.8.3.jar",
            "title": "pddl4j-3.8.3",
            "syntax": "$(planner) -o $(domain) -f $(problem) $(options)"
        }
    ]
}

This works correctly, because the VS Code extension is loaded on the workspace side (which is inside WSL) and not the UI side (which runs in Windows). The temp files are then correctly placed in the WSL mounted storage.

You are proposing a hybrid scenario, where the only the solver runs in WSL. That is indeed bit more convenient and I can see the merits of it. It would indeed have to be achieved by being able to configure a place, where the input files need to be stored in order to be accessible to the process in WSL. It may have to be configured in a form of a windows file path and the equivalent WSL file path. Possibly by adding two configuration elements:

"localCwd": "\\wsl$\\Ubuntu-20.04\tmp",
"remoteCwd": "/tmp"