Jump to content

Use a different IDE.


---
 Share

Recommended Posts

Hi Shain,

 

I've had a bit of success using a shim to launch my script:

import debugpy
from pathlib import Path

debug_script_path = Path('path/to/your/script.py')
with debug_script_path.open('r') as script:
  new_script = compile(source=script.read(), filename=str(debug_script_path), mode='exec')

address = ('127.0.0.1', 5678)
debugpy.listen(address)

debugpy.wait_for_client()
exec(new_script)

This is a simplified version of what I'm using but the basic idea is there.  Then, in vscode, I use this in my launch.json to attach:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Python: Remote Attach",
      "type": "python",
      "request": "attach",
      "connect": {
        "host": "localhost",
        "port": 5678
      },
      "justMyCode": false,
      "pathMappings": [
        {
          "localRoot": "${workspaceFolder}",
          "remoteRoot": "${workspaceFolder}"
        }
      ]
    }
  ]
}

HTH!

Link to comment
Share on other sites

In principle, the local scripts residing in %APPDATA%/gom/<version>/gom_scripts can be edited on disk. But: The external editor will not integrate nicely into the workflow and will not support features like inserting tokens, inserting dialogs or starting an debugging your scripts. So if the internal editor lacks features (which I'm very sure it does), using an external editor with that script folder as a working directory might help. 

With SW2021, we will introduce a way of including external directories containing scripts into the internal editor. So on one hand you can select your own workspace folder and on the other hand working on, e.g., a git administered directory will become easier. A full featured embedded script editor like VSCode is my personal dream, but at the moment far from begin implemented, I'm afraid.

Link to comment
Share on other sites

Please sign in to view this quote.

I have done some editing in the past with a diff ide but like you said there will be some lacking of features such as dialogs and token insertion. I can deal with that as what i really wanted was to utilize some other ide features such as intellisense, auto-complete, and linting. None are necessary but does sometimes reduce the tediousness when dealing with larger scripts. I also wanted to be able to debug as it is nice to have a variables tab like in vscode. This reduces a lot of unnecessary logging or printing statements during debug.

 

Please sign in to view this quote.

I have had success with this approach. Thank you very much Sean. This has allowed me to leverage some of the tools i wanted to. I would like to think of a way to streamline this in vscode. Mabey passing the initial script that waits for the connection as an eval statement to the gom interpreter when launching a debug session?

Link to comment
Share on other sites

Shain,

Your idea of passing the initial script in with an -eval should work, but I've found it worth it to take it a step further.

What I do is render a templated shim into a temporary file using chevron, which allows me to add other things before launching the script (like virtual environment, loading a sample file, logs, etc).  I then launch an instance of the software in whole with the -script option set to that file.  It's pretty involved and somewhat clunky, but this way, I've been able to do some pretty good stuff.

Link to comment
Share on other sites

Sounds like something I'd like to try. I may need to better understand the library a bit better to utilize as you have as i have never used this kind of setup before. Thank you for the direction. I'm excited to see if i can manage a similar approach.

Link to comment
Share on other sites

  • 2 years later...
 Share

×
×
  • Create New...