Principal Engineer for Accumulate

  • 7 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle






  • Sorry, I forgot about this. I’ve attached my full configuration at the end. The steps are:

    1. If the container is on a server, SSH to it or whatever.
    2. Execute docker exec --privileged -it container_name bash.
      • --privileged is required to make delve work. I don’t entirely remember why.
      • -it is something like --interactive and --terminal, it’s what you need to get a proper interactive shell.
      • container_name is the name of your container.
      • bash can also be sh or pwsh or whatever shell your container has (hopefully it has one).
    3. Launch delve dlv attach PID --headless --listen=:2345 --accept-multiclient --api-version=2.
      • PID is the ID of the process you want to debug. This should be 1 if you’re debugging the main process of the container.
      • --listen=:2345 says to listen on (TCP) port 2345 on all interfaces (0.0.0.0)
      • The other flags are the one that vscode-go expects.
    4. If the container is on a server, forward ports ssh ${USER}@${SERVER} -NL LOCAL:2345:REMOTE:2345.
      • LOCAL is the local IP to listen on, usually localhost. When a process connects to your local IP, it will be forwarded to the remote.
      • REMOTE is the remote IP to connect to, this should be the IP of your container. When a connection is forwarded from your local machine, this is where it is forwarded to. My containers are set up with --net host so I can use localhost as REMOTE but that’s not the default so you may have to use docker inspect to figure out your container’s IP.

    I also included the path substitution configs I use. I generally debug these by pausing the target, clicking on something in the stack trace, seeing what path it tries to load, then adjusting the substitute path so that it loads the correct file.

    {
      "name": "Attach to a docker container",
      // Get a shell in the container: `docker exec --privileged -it ${NAME} bash`
      // Launch delve:                 `dlv attach 1 --headless --listen=:2345 --accept-multiclient --api-version=2`
      // Forward the port (if remote): `ssh ${USER}@${SERVER} -NL localhost:2345:localhost:2345`
      // Then run this debug config
      "presentation": {
        "group": "99-Miscellaneous",
      },
      "type": "go",
      "request": "attach",
      "mode": "remote",
      "remotePath": "${workspaceFolder}",
      "port": 2345,
      "host": "127.0.0.1",
      "substitutePath": [
        // // Full paths (GitLab Docker build)
        // {
        //   "to": "/go/",
        //   "from": "${env:HOME}/go/", // <-- MODIFY THIS if you're not using the default GOPATH
        // },
        // {
        //   "to": "/root/",
        //   "from": "${workspaceFolder}",
        // },
        // Trimmed paths
        {
          "to": "gitlab.com/accumulatenetwork/accumulate/",
          "from": "${workspaceFolder}/",
        },
        {
          "to": "github.com/AccumulateNetwork/",
          "from": "${env:HOME}/go/pkg/mod/github.com/!accumulate!network/", // <-- MODIFY THIS if you're not using the default GOPATH
        },
        // {
        //   "to": "",
        //   "from": "${env:HOME}/go/pkg/mod/", // <-- MODIFY THIS if you're not using the default GOPATH
        // },
      ],
    }
    


  • Attaching to and debugging a process most certainly does work. I did it yesterday. Your issue is that Go doesn’t have any way of telling the process to pause until a debugger attaches. Which is frustrating but not the same issue.

    Specifically for debugging stdin, by far the easiest way to do that (in VSCode) is "console": "integratedTerminal". Another comment links a stack overflow answer that includes other options.










  • I think the degree of footgun danger depends a lot on the language and the application. I agree that C and C++ are dangerous until you really know what you’re doing, though IMO most of the danger comes down to memory management and that’s a portable skill, once you’ve learned it. That being said, I don’t have a lot of experience with C++. C was my first language so I’m used to plain old normal boring pointers (are those “dumb pointers”?) and I’ve never understood why C++ needs 9 billion types of pointers.

    Go has one particular footgun - loop range variables. Other than that, IMO high-level, garbage collected languages don’t have major footguns like that. My first job was writing a bespoke inventory system for a manufacturing company, and I wrote it in a language I’d never used before - C#. In five years the only major issue that had was due to my inexperience with SQL and had nothing to do with C#. And though I haven’t written nearly as much code, I’d say the same about Java, Ruby, Python, and JavaScript.



  • Counterpoint: knowing a programming language doesn’t matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can’t do that as a intermediate to senior developer, you’re not a competent programmer IMO.

    The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you’re only a skilled developer in the languages you know - if you aren’t capable of pivoting those skills to another language - you aren’t a skilled developer IMO.