The example was was using 'launchCommand' which is not valid according to the schema; it should be 'runCommand'. But also, it never really worked. Vimspector would start the "adapter" (in this case, try and connect to the TCP port) before running the "prepare" commands, wich in this case would actually start debugpy listening. So to solve that we run the prepare commands earlier. Hopefully this won't cause a regression for Java and C++ remote attach, which we don't really have tests for. Finally, due to the way docker works, when you forward a port and nothing is listening on it, docker _accepts_ the connection then immediately drops it. This is _super_ annoying meaning that it looks to vimspector liek the server instantly dies if it takes nonzero time for the remote commands to open the port. So to solve this we add loaunch and attach delays which can be configured in the adapter config. This actually solves a prolem where the java debugger just takes agest to attach on remote launch too. (Finally, finally...) updated the vimspector schema to represent the real launch/attach remote configuration, which was incorrectly spec'd at the adapter level, but it's actually per launch/attach block.
11 lines
165 B
Bash
Executable file
11 lines
165 B
Bash
Executable file
#!/usr/bin/env bash
|
|
|
|
set -e
|
|
|
|
if [ "$1" = "--continue" ]; then
|
|
OPTS=""
|
|
else
|
|
OPTS="--no-cache"
|
|
fi
|
|
|
|
docker build ${OPTS} -t puremourning/vimspector:simple_python .
|