Pull request suggestion for issue #158

As I had to make changes for the tests, I ended up creating a new commit for the merge (so, was added in: https://github.com/robocorp/robotframework-lsp/commit/d9199729cf8d6ddda93a334dbdc4902f613d66ca).

jupyterlab-lsp extension is using insertText attribute of the returned CompletionItem and ignoring the text_edit attribute. This is causing the extension to behave unexpectedly with RobotFramework LS

Needed:

Single field addition to returned CompletionItem.

For example: robotframework-ls/src/robotframework_ls/impl/keyword_completions.py

insertText=text_edit.newText

return CompletionItem(
            keyword_found.keyword_name,
            kind=keyword_found.completion_item_kind,
            text_edit=text_edit,
            insertText=text_edit.newText,
            documentation=keyword_found.docs,
            insertTextFormat=InsertTextFormat.Snippet,
            documentationFormat=(
                MarkupKind.Markdown
                if keyword_found.docs_format == "markdown"
                else MarkupKind.PlainText
            ),
        ).to_dict()

i.e.: Something as:

rcc env variables -r robot.yaml -e devdata/env.json

Yes, it should be ok to add. It doesn't break other places as it should actually be ignored -- at least that's what the spec says ;)

Only the tests need to be updated (if it's hard for you to get the env up to date to regenerate the expected files I can update it here).

Tests are failing because the expected data changed.

Most should be related to https://github.com/ESSS/pytest-regressions.

To force the update of the expected files it should be possible to call something as: pytest -n auto --force-regen (it should fail the time it regenerates the expected files and should pass on subsequent runs).

If you want I can update it here...

i.e.: Something as:

rcc env variables -r robot.yaml -e devdata/env.json

Ok, it should be straightforward to add that, still, note that the insertText leaves too much up to interpretation from the client (which may end up not doing what is actually expected on some cases), so, ideally the jupyterlab-lsp extension would be fixed to do the right thing here...

i.e.: Spec (https://microsoft.github.io/language-server-protocol/specification) details on the related fields for CompletionItem

/**
 * A string that should be inserted into a document when selecting
 * this completion. When `falsy` the label is used.
 *
 * The `insertText` is subject to interpretation by the client side.
 * Some tools might not take the string literally. For example
 * VS Code when code complete is requested in this example `con<cursor position>`
 * and a completion item with an `insertText` of `console` is provided it
 * will only insert `sole`. Therefore it is recommended to use `textEdit` instead
 * since it avoids additional client side interpretation.
 */
insertText?: string;

/**
 * An edit which is applied to a document when selecting this completion. When an edit is provided the value of
 * `insertText` is ignored.
 *
 * *Note:* The range of the edit must be a single line range and it must contain the position at which completion
 * has been requested.
 */
textEdit?: TextEdit;

Is your feature request related to a problem? Please describe. Users should not have to restart the language server to turn the logging on/off.

Describe the solution you'd like Create an action to turn the logging on or off just temporarily without having to restart the language server (potentially this would just change a related setting and the language server would start/stop logging instead of having to pass it in the arguments as it is right now).

Moving to maybe later.

Moving to maybe later.

Moving to backlog.

Visual Studio Code and some other IDEs have built in support for linter tools like pylint, pep8 etc that can be configured and run on file save.

It would be awesome to have this with Robot Framework plugin. I'm coauthor of Robocop which can be used to scan robot files. I have general idea where we could put this. According to documentation from Microsoft for LSP server we can use Diagnostic. RF LSP have basic implemention of it under Url but it does only cover missing keywords.

What we need in short? To be able to configure and start our application in LSP startup and then call it with something like scan_file(path) everytime we need analysis. Of course I need to update Robocop to be able to run it continously like that and to return analysis results in format suitable for LSP.

I could also try to raise PR here but it would be good to discuss proposed architecture first.

I'm closing and marking this as maybe later as I won't be getting this myself in the mid-short term (still, feel free to create a pull request and I'll review it or comment more on the issue itself... i.e.: only the issues that I have a plan to tackle in the mid-short term with a higher priority are kept in the open state).

Upon opening the tasks.robot (the first time that the extension is activated) in the .zip file attached the language server initially does an analysis with the wrong python interpreter (instead of already using one based on robot.yaml).

test-robot.zip

This would allow users to launch non-robotframework files with the expected env.

More specifically, what happens is:

...

lsp: 2020-09-28 08:45:58 UTC pid: 10152 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.streams
Writing: {'jsonrpc': '2.0', 'id': 2, 'method': 'textDocument/didOpen', 'params': {'textDocument': {'uri': 'file:///c%3A/temp/test-robot/tasks.robot', 'version': 1, 'text': '*** Settings ***\nDocumentation     An example robot.\nLibrary           RPA.Browser\n\n*** Tasks ***\nMinimal task\n    Open Available Browser    https://greenstep.fi/\n    Click Element When Visible    css:a.cc-allow\n'}}}

... Code analysis started here

lsp: 2020-09-28 08:45:58 UTC pid: 10152 - MainThread - DEBUG - robocorp_ls_core.jsonrpc.streams
Read: {"jsonrpc":"2.0","id":1,"method":"workspace/executeCommand","params":{"command":"robot.addPluginsDir","arguments":["c:\\Users\\fabio\\.vscode\\extensions\\robocorp.robocorp-code-0.0.5\\src\\robocorp_code\\plugins"]}}

... Extension to handle robot.yaml files only added afterwards

Upon opening the tasks.robot (the first time that the extension is activated) in the .zip file attached the language server initially does an analysis with the wrong python interpreter (instead of already using one based on robot.yaml).

test-robot.zip

You should not check how many proposals are there in total (this makes the test brittle as it's very likely it'll change in a new python release).

After testing a bit more I changed the structure to include a description in the exception name too (to hopefully make it even clearer).

Why is conda list being called here?

Issue Type: <b>Bug</b>

Expected behavior: no duplicated tabs opened, for a same file, when debugging

Steps to reproduce:

1. Open VSCode remote session through "Remote - SSH" extension
2. open workspace
3. set launch configuration thusly

            {
                "name": "util.py",
                "type": "python",
                "request": "launch",
                "program": "util.py",
                "console": "integratedTerminal"
            },

(Note: issue not reproducible when running "Python: Current File" default configuration)

            {
                "name": "Python: Current File",
                "type": "python",
                "request": "launch",
                "program": "${file}",
                "console": "integratedTerminal"
            },

4. open file, shows as /home/dario/centerNet-deep-sort/util.py
5. set breakpoint
6. run

Actual behavior: execution stops at breakpoint, but new tab opened of same file showing as in /mnt/home/centerNet-deep-sort/util.py (and breakpoint only visible in /home/centerNet-deep-sort/util.py file)

Extension version: 2020.9.111407 VS Code version: Code 1.49.1 (58bb7b2331731bf72587010e943852e13e6fd3cf, 2020-09-16T23:27:51.792Z) OS version: Windows_NT x64 10.0.19042 Remote OS version: Linux x64 4.15.0-117-generic

<details> <summary>System Info</summary>

</details> <!-- generated by issue reporter -->

Great ;)

It seems that the issue is that the util.py being executed doesn't have the full path frame and resolves to the working directory (that's actually /mnt/home/dario/centerNet-deep-sort and not /home/dario/centerNet-deep-sort).

i.e.: The logs shows the stack as:

  Stack: util.py, <module>, 4
  Stack: /home/dario/anaconda3/envs/CenterNet/lib/python3.6/runpy.py, _run_code, 85
  Stack: /home/dario/anaconda3/envs/CenterNet/lib/python3.6/runpy.py, _run_module_code, 96
  ....

So, it's possible to see that util.py doesn't really have the full path.

And it also says:

File traced: /mnt/home/dario/centerNet-deep-sort/util.py.

So, I think that you should have some pathMapping set to make that translation.

Something like:

            "pathMappings": [
                {
                    "localRoot": "/home/",
                    "remoteRoot": "/mnt/home/"
                }
            ],

(that should be added to the launch configuration)

Please rename the this.condaEnv to this.condaEnvCache (so that it's clear that one is the cached version and the other is the local variable version to avoid name shadowing)

Also, please put this inside of this.activateCondaEnv as you don't need to access it unless you'll really need to use it (access to volatile is slower as it may need to synchronize threads, so, it should be used as little as possible).

Since the condaEnv received is already a temporary, local created variable, you don't to return anything here... Actually, on 2nd thought, this code seems a bit weird to me... I think you shouldn't receive any parameter here for the condaEnv, just create the map inside of this function and return it here.

The caller can then cache the return as needed.

Humm, I think that another option could be installing the debugger from master in the python interpreter you want to use:

i.e.: something as:

pip install https://github.com/microsoft/debugpy/archive/master.zip

(in this case the debugAdapterPath should not be needed)

Have you tested this locally? It seems to have a syntax error there...

<!-- Please search existing issues to avoid creating duplicates. -->

I have first open this bug in https://github.com/microsoft/vscode-python/issues/14098 - but maybe here it's more appropriate.

Environment data

• Version: 1.49.0 (system setup)
• Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
• Date: 2020-09-10T13:22:08.892Z
• Electron: 9.2.1
• Chrome: 83.0.4103.122
• Node.js: 12.14.1
• V8: 8.3.110.13-electron.0
• OS: Windows_NT x64 10.0.19041
• Extension version (available under the Extensions sidebar): v2020.8.109390
• Python version (& distribution if applicable, e.g. Anaconda): 3.8.0
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: none
• Relevant/affected Python-related VS Code extensions and their versions: none
• Value of the python.languageServer setting: Jedi

Expected behaviour

The debugger will break on the breakpoint set in VS Code.

Actual behaviour

The debugger does not break on the breakpoint set.

Steps to reproduce:

1. Clone https://github.com/ido-ran/vscode-python-cthread-debugging
2. Run create-venv.sh once to create venv
3. Run build_thrd.sh to build Cyton extension
4. Open test_threading.py in VS Code
5. Add breakpoint on the print statement in handler function
6. Start debug by pressing F5 or open the Run tab and click Start Debugging

Yeap, using the pydevd api directly should also work for debugpy ;)

p.s.: I'm closing as this is a known issue which is being tracked elsewhere.

I think the only thing missing here is that you actually have the target in the NamedExpr, so, when constructing the Assign you should also pass the target.

i.e.: new Assign(new exprType[] {node.target}, node.value, null)

This is a known issue...

We already tried some approaches and still haven't been able to come up with a good solution to do that in the general case, so, for now, you're required to manually ask for non-python started threads to be traced.

To do that you can use the following api:

import debugpy
debugpy.debug_this_thread()

Thanks for the fix, just merged.

Fix searchExecutable for non Windows systems and the situation where the executable resides below a folder with the same name.

I myself had the issue, that the conda executable to be searchead is located as pymaven/conda/bin/conda. In which situation currently the folder pymaven/conda is returned and then tried to be executed.

The issue appears to be that the debugger currently resolves symlinks and considers a canonical version as it's possible to see that the debugger does:

Request for breakpoint in: /home/dario/nethra-scripts/download_images_from_json.py line: 42
Breakpoint (after path/source mapping) in: /mnt/home/dario/nethra-scripts/download_images_from_json.py line: 42

The latest master version actually had some fixes related on how this is handled internally so that internally we stop in a canonical place (even with symlinks resolved) but it reports the proper absolute (unresolved) path to the outside world.

Can you check with the current master to see if it fixes it for you?

It's something as:

git clone https://github.com/microsoft/debugpy.git
cd debugpy
pwd

Then, in your launch config add:

"debugAdapterPath": "<pwd path>/src/debugpy/adapter"

-- Note: I haven't tested if this works in the SSH case, so, if you have any issues there, please report back.

If it still doesn't work, can you provide the logs you have with the master version?

This doesn't seem ideal... there are a few reasons:

1. You're doing a pre-check on the places to rename, but in case it matches it shouldn't switch the whether to find all parts (it could go on and create the entry directly).
2. You're just visiting top-level imports (so, if there's an import inside a method it won't be gotten by this.

I think that the logic to check the import should be done inside of getLocalOccurrences itself when onlyFirstAttribPart==false (it's visitor structure should already visit children nodes).

environment vs code == 1.49.1(windows) PTVSD == 4.3.2 python ==3.7.5 code environment= ubuntun and docker

When I try to use vs code and ptvsd.py to debug a python code, which included some multiprocessing.py part. The code will timeout when it goes to the multiprocessing part, and report: " Traceback (most recent call last): Error in atexit._run_exitfuncs: RuntimeError: already started" You can see the wrong detail WRONG TWO in the end.

After I saw some old issue, I try to add code multiprocessing.set_start_method('spawn',True) before using multiprocessing part But after I do that the vs code debug shows：“OSError: [Errno 98] Address already in use”

I think there are something wrong when I use both 'multiprocessing.set_start_method('spawn',True)' and ptvsd.enable_attach(address = ('0.0.0.0', 8888)) ptvsd_enable_attach(address) Because when I use vs code and ptvsd to debug a python code, which without multiprocessing everything works. And without vs code &PTVSD, the multiprocessing code works too. You can see the wrong detail WRONG TWO in the end.

____WRONG TWO Traceback (most recent call last):

During handling of the above exception, another exception occurred:

Exception in thread Thread-7: Traceback (most recent call last): File "/usr/lib/python3.7/threading.py", line 926, in _bootstrap_inner self.run() File "/usr/lib/python3.7/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.7/multiprocessing/pool.py", line 412, in _handle_workers pool._maintain_pool() File "/usr/lib/python3.7/multiprocessing/pool.py", line 248, in _maintain_pool self._repopulate_pool() File "/usr/lib/python3.7/multiprocessing/pool.py", line 241, in _repopulate_pool w.start() File "/usr/lib/python3.7/multiprocessing/process.py", line 112, in start self._popen = self._Popen(self) File "/usr/lib/python3.7/multiprocessing/context.py", line 277, in _Popen return Popen(process_obj) File "/usr/lib/python3.7/multiprocessing/popen_fork.py", line 20, in init self._launch(process_obj) File "/usr/lib/python3.7/multiprocessing/popen_fork.py", line 70, in _launch self.pid = os.fork() File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/_pydev_bundle/pydev_monkey.py", line 528, in new_fork _on_forked_process() File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/_pydev_bundle/pydev_monkey.py", line 50, in _on_forked_process pydevd.settrace_forked() File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2427, in settrace_forked patch_multiprocessing=True, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect s = start_client(host, port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/pydevd_hooks.py", line 136, in _start_client return start_client(daemon, h, p) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 62, in <lambda> start_client=(lambda daemon, h, port: start_daemon()), File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 50, in start_daemon _, next_session = daemon.start_server(addr=(host, port)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/daemon.py", line 158, in start_server with self.started(): File "/usr/lib/python3.7/contextlib.py", line 112, in enter return next(self.gen) File "/usr/local/lib/python3.7/dist-packages/ptvsd/daemon.py", line 110, in started self.start() File "/usr/local/lib/python3.7/dist-packages/ptvsd/daemon.py", line 145, in start raise RuntimeError('already started') RuntimeError: already started Unhandled exception in thread started by Unhandled exception in thread started by <_pydev_bundle.pydev_monkey._NewThreadStartupWithTrace object at 0x7efe4d55acd0>

____________WRONG TWO Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.7/multiprocessing/spawn.py", line 105, in spawn_main exitcode = _main(fd) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 114, in _main prepare(preparation_data) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 225, in prepare _fixup_main_from_path(data['init_main_from_path']) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 277, in _fixup_main_from_path run_name="mp_main") File "/usr/lib/python3.7/runpy.py", line 263, in run_path pkg_name=pkg_name, script_name=fname) File "/usr/lib/python3.7/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/dingsh/LightGCN-restart-0826/code/main_dsh.py", line 22, in <module> ptvsd.enable_attach(address = ('0.0.0.0', 8888)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/attach_server.py", line 101, in enable_attach ptvsd_enable_attach(address) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 79, in enable_attach patch_multiprocessing=ptvsd.options.multiprocess) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect s = start_client(host, port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/pydevd_hooks.py", line 136, in _start_client return start_client(daemon, h, p) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 62, in <lambda> start_client=(lambda daemon, h, port: start_daemon()), File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 50, in start_daemon File "/usr/lib/python3.7/multiprocessing/spawn.py", line 277, in _fixup_main_from_path run_name="mp_main") File "/usr/lib/python3.7/runpy.py", line 263, in run_path pkg_name=pkg_name, script_name=fname) File "/usr/lib/python3.7/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/dingsh/LightGCN-restart-0826/code/main_dsh.py", line 22, in <module> ptvsd.enable_attach(address = ('0.0.0.0', 8888)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/attach_server.py", line 101, in enable_attach ptvsd_enable_attach(address) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 79, in enable_attach patch_multiprocessing=ptvsd.options.multiprocess) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect s = start_client(host, port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/pydevd_hooks.py", line 136, in _start_client self._server = create_server(addr.host, addr.port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/socket.py", line 79, in create_server Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.7/multiprocessing/spawn.py", line 105, in spawn_main exitcode = _main(fd) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 114, in _main prepare(preparation_data) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 225, in prepare _fixup_main_from_path(data['init_main_from_path']) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 277, in _fixup_main_from_path run_name="mp_main") File "/usr/lib/python3.7/runpy.py", line 263, in run_path pkg_name=pkg_name, script_name=fname) File "/usr/lib/python3.7/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/dingsh/LightGCN-restart-0826/code/main_dsh.py", line 22, in <module> ptvsd.enable_attach(address = ('0.0.0.0', 8888)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/attach_server.py", line 101, in enable_attach ptvsd_enable_attach(address) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 79, in enable_attach patch_multiprocessing=ptvsd.options.multiprocess) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect s = start_client(host, port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/pydevd_hooks.py", line 136, in _start_client return start_client(daemon, h, p) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 62, in <lambda> File "/usr/lib/python3.7/multiprocessing/spawn.py", line 105, in spawn_main exitcode = _main(fd) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 114, in _main prepare(preparation_data) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 225, in prepare _fixup_main_from_path(data['init_main_from_path']) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 277, in _fixup_main_from_path run_name="mp_main") File "/usr/lib/python3.7/runpy.py", line 263, in run_path pkg_name=pkg_name, script_name=fname) File "/usr/lib/python3.7/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/dingsh/LightGCN-restart-0826/code/main_dsh.py", line 22, in <module> ptvsd.enable_attach(address = ('0.0.0.0', 8888)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/attach_server.py", line 101, in enable_attach ptvsd_enable_attach(address) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 79, in enable_attach patch_multiprocessing=ptvsd.options.multiprocess) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect s = start_client(host, port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/pydevd_hooks.py", line 136, in _start_client File "/usr/lib/python3.7/multiprocessing/spawn.py", line 114, in _main prepare(preparation_data) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 225, in prepare _fixup_main_from_path(data['init_main_from_path']) File "/usr/lib/python3.7/multiprocessing/spawn.py", line 277, in _fixup_main_from_path run_name="mp_main") File "/usr/lib/python3.7/runpy.py", line 263, in run_path pkg_name=pkg_name, script_name=fname) File "/usr/lib/python3.7/runpy.py", line 96, in _run_module_code mod_name, mod_spec, pkg_name, script_name) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/dingsh/LightGCN-restart-0826/code/main_dsh.py", line 22, in <module> ptvsd.enable_attach(address = ('0.0.0.0', 8888)) File "/usr/local/lib/python3.7/dist-packages/ptvsd/attach_server.py", line 101, in enable_attach ptvsd_enable_attach(address) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_remote.py", line 79, in enable_attach patch_multiprocessing=ptvsd.options.multiprocess) File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2179, in settrace wait_for_ready_to_run, File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 2230, in _locked_settrace debugger.connect(host, port) # Note: connect can raise error. File "/usr/local/lib/python3.7/dist-packages/ptvsd/_vendored/pydevd/pydevd.py", line 1060, in connect self._server = create_server(addr.host, addr.port) File "/usr/local/lib/python3.7/dist-packages/ptvsd/socket.py", line 79, in create_server server.bind((host, port)) OSError: [Errno 98] Address already in use

@gil0109 can you provide the logs for this?

To get the logs, set "logToFile": true in the launch.

I'm not sure where it puts them in the WSL case (when running in the terminal the path should appear when DEBUGPY_LOG_DIR is set, or you can print it from the program with: print(os.environ['DEBUGPY_LOG_DIR'])).

@int19h @brettcannon that output shows the venv activation being done at the end.

i.e.:

first command:
/usr/bin/env /mnt/c/git/queue-management/.venv/bin/python3 /home/gillani/.vscode-server/extensions/ms-python.python-2020.9.111407/pythonFiles/lib/python/debugpy/launcher 53413 -- /mnt/c/git/queue-management/.venv/bin/gunicorn wsgi --bind=0.0.0.0:5000 --access-logfile=- --config=/mnt/c/git/queue-management/api/gunicorn_config.py --timeout=9999 

second command:
source /mnt/c/git/queue-management/.venv/bin/activate

This seems backwards. I think that the venv activation is done by vscode-python (and not really debugpy)... right?

@WurmD can you provide the logs for this?

To get the logs, set "logToFile": true in the launch.

I'm not sure where it puts them in the case for the ssh connection (when running in the terminal the path should appear when DEBUGPY_LOG_DIR is set, or you can print it from the program with: print(os.environ['DEBUGPY_LOG_DIR'])).

@int19h @karthiknadig @luabud

What do you think about the results below for this?

-- I'm marking with Current frame the place where the execution is actually stopped in the Call Stack and in the Exception Description to try to make it clear that the exception was raised at one place but the execution was actually stopped at a different frame.

Do you think this is clear? Also I'm showing User Uncaught Exceptions (should I commit that or do you want to roll that out differently?)

You should first put in a local var and then check for isEmpty to avoid racing conditions and then use that same variable in the createEnvWithMap.

Actually I just saw that condaPrefix is already a File, so, you should just do: condaPrefix.exists().

This shouldn't be here... you still have to compute the computedMap, you only want to create a map with the variables inside of this.activateCondaEnv (and then update computedMap with the variables of the condaEnv).

You don't need to create a File here, just use condaPrefix directly.

Humm, I think it should be straightforward as RF already supports creating the AST in-memory (so, let me know if you need any help there as I can point you to the right direction).

i.e.: it doesn't seem it should be difficult to receive - and a --file parameter and return an InMemoryContentsWithPath object in https://github.com/MarketSquare/robotframework-robocop/blob/43ce30905df80db4616782b0267420488b723f70/robocop/run.py#L161 (it'd may need some instance checks later on, but looking at the code it seemed straightforward).

I agree it should recognize it, but I'll just note that that's a pretty strange use of the separator (as far as I know, you should be able to just use / there without any issues as you could just write Resource ../../XXX/XX/resource_XXX_general.robot).

That should work in Windows and Linux...