profile
viewpoint
Pavel Minaev int19h Microsoft North Bend, WA, USA

int19h/aow-patch 11

Unofficial patch for Age of Wonders

int19h/WarBender 10

WarBender: a Mount & Blade: Warband save game editor

int19h/csx 3

C# scripting for Mount & Blade 2: Bannerlord

int19h/warbend 3

WarBend: a Python library to read and write Mount & Blade: Warband saved games

int19h/cpython 0

The Python programming language

int19h/debugpy 0

An implementation of the Debug Adapter Protocol for Python

int19h/django 0

The Web framework for perfectionists with deadlines.

int19h/FirearmDeathRate 0

Use regression tree to predict firearm death rate with firearm law & CDC firearm death rate data.

int19h/kiwix-tools 0

Command Kiwix tools: kiwix-serve, kiwix-install, kiwix-manage, ...

int19h/mb_warband_module_system 0

Mount & Blade: Warband module system (mirror)

push eventint19h/debugpy

Pavel Minaev

commit sha 57ec4c4f65f9bd324872aea0cfe3e04ba84e9e91

Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits. On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits. Improve process tree autokill tests to actually check whether the child process has exited.

view details

push time in 7 hours

issue commentmicrosoft/debugpy

Importing opencv fails with "ImportError: /lib/x86_64-linux-gnu/libstdc++.so.6: cannot allocate memory in static TLS block"

This sounds like https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/1890170 - from the various reports there, it looks like cv2 might have some conflicts with other packages employing native code?

emdioh

comment created time in 10 hours

issue closedmicrosoft/vscode-python

[Doc] Debug configuration options `python` doesn't seem to be valid

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

Environment data

  • VS Code version: 1.47.3
  • Extension version (available under the Extensions sidebar): v2020.7.96456
  • OS and version: Windows 10

The doc of debug configuration has changed pythonPath to python in https://github.com/microsoft/vscode-docs/pull/3560, but python doesn't seem to be valid:

image

Also the default value is now ${command:python.interpreterPath} (https://github.com/microsoft/vscode-python/issues/11789#issuecomment-631413067) instead of ${config:python.pythonPath} provided in the doc.

Using ${config:python.pythonPath} will give error when start debugging:

image

At the same time, using ${command:python.interpreterPath} is inconsistent with "python.pythonPath" in workspace's settings.json.

closed time in 10 hours

jiasli

issue commentmicrosoft/vscode-python

[Doc] Debug configuration options `python` doesn't seem to be valid

Duplicate of #12462

jiasli

comment created time in 10 hours

issue commentmicrosoft/vscode-python

[Doc] Debug configuration options `python` doesn't seem to be valid

The docs are correct in this case, but the extension doesn't reflect it in the schema.

It also needs changes to all code paths in the extension that get or set "pythonPath" in the debug configuration.

jiasli

comment created time in 10 hours

issue closedmicrosoft/vscode-python

Run Python Debug Console in Existing Terminal

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

<!-- Describe the feature you'd like. -->

When I use the debugger on a Python file (via F5), the Python Debug Console opens in a new terminal. It would be great to have the option to have the Python Debug Console open in an existing active terminal. The reason for this is that I use Remote to develop on a shared cluster. My workflow is: I request a machine for an interactive job, so my terminal is attached to a specific machine. However when I run the debug command, the Python Debug Console opens a new terminal on the main node of the cluster rather than on the machine I'm using for the interactive job. Thank you!

closed time in 10 hours

keyonvafa

issue closedmicrosoft/vscode-python

Debugging highlights the wrong line on stop when word-wrap is enabled and occurs higher up in the file

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

<!-- Done!! -->

Environment data

VSCode Help copy:

  • Version: 1.46.1 (system setup)
  • Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
  • Date: 2020-06-17T21:13:20.174Z
  • Electron: 7.3.1
  • Chrome: 78.0.3904.130
  • Node.js: 12.8.1
  • V8: 7.8.279.23-electron.0
  • OS: Windows_NT x64 10.0.18362- VS Code version: XXX

Other

  • Extension version (available under the Extensions sidebar): 2020.6.91350
  • Python version (& distribution if applicable, e.g. Anaconda): 3.7.6 (Win 64-vit)
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
  • Relevant/affected Python packages and their versions: all
  • Relevant/affected Python-related VS Code extensions and their versions: python and maybe all?
  • Value of the python.languageServer setting: microsoft

Expected behaviour

When debugger stops, it highlights the line it is actually stopped at.

Actual behaviour

Debugger stops at the same line the breakpoint is at, but it appears to be at a different line in the code, but only when word wrap is enabled, and there are lines that have word-wrapped higher up in the file. It does appear that the number of lines that the highlighting is off by increases with more lines word-wrapping above that point (the effect is somehow cumulative).

Steps to reproduce:

Please see this vscode issue for more details. They requested logging this for the Python extension since that's where I found the issue. I have detailed screenshots of a specific example, etc.

  1. Enable word wrap (set option to 'on', see other issue for details)
  2. Create a python script with some lines that force wordwrap, and have some for loops with if/elif/else in them (to be able to notice the highlighting being on the wrong rows as you step through the loop, etc.)
  3. Ensure that many lines cause a wordwrap on the screen (make the editor narrow enough and/or a few lines long enough (just add comments?)
  4. Set a breakpoint and debug the code. The initial debug will appear to stop at the location of the breakpoint, but may not actually be there.
  5. step through the code, especially through some if/else and for loop blocks. The highlight will appear to be on the wrong line when jumping from the end of the loop to the start, or moving through the if/else blocks.

More details at the vscode issue linked above.

<!-- Note: If you think a GIF of what is happening would be helpful, consider tools like https://www.cockos.com/licecap/, https://github.com/phw/peek or https://www.screentogif.com/ . -->

closed time in 10 hours

LightCC

issue commentmicrosoft/vscode-python

Debugging highlights the wrong line on stop when word-wrap is enabled and occurs higher up in the file

Please re-open if it turns out to be a distinct issue.

LightCC

comment created time in 10 hours

issue closedmicrosoft/debugpy

Debugging Doesn't Work If File Is On Virtual/Network Drive

Issue Type: <b>Bug</b>

I recently started using Cryptomator to encrypt my files locally before they are uploaded to the cloud (so if someone somehow gains access to my could storage, they still won't be able to access the actual files). This works by storing the files inside a "vault" mounted on some drive letter (e.g. V:). If I understand correctly, that drive is considered a network drive by the OS. The files on that vault are then automatically encrypted and saved in the folder used by the cloud service.

I noticed that if a Python program is located anywhere on this virtual drive V:, then VS Code cannot debug it. I set breakpoints, but the execution never actually breaks on those breakpoints; it simply runs the whole program from beginning to end without breaking.

Steps to reproduce:

  1. Using VS Code, open any Python program stored on the local disk. (The content of the program itself doesn't seem to matter. For concreteness let's go with "print(2+2)".)
  2. Set a breakpoint with F9 and press F5. The execution will break at that point.
  3. Close VS Code.
  4. Copy that same program to a folder on the Cryptomator vault (drive V:) and open it using VS Code.
  5. Set a breakpoint with F9 and press F5. Now the execution will NOT break at that point.

Note: I also tried debugging a C++ program in the same folder, and had no issues; this problem seems to be specific to Python.

Python version: 3.8.5 64-bit Extension version: 2020.7.96456 VS Code version: Code 1.47.3 (91899dcef7b8110878ea59626991a18c8a6a1b3e, 2020-07-23T13:12:49.994Z) OS version: Windows_NT x64 10.0.19041

closed time in 11 hours

bshoshany

issue commentmicrosoft/debugpy

Debugging Doesn't Work If File Is On Virtual/Network Drive

Closing as duplicate of #200 - we'll track any further work on this there.

bshoshany

comment created time in 11 hours

issue commentmicrosoft/debugpy

Debugging Doesn't Work If File Is On Virtual/Network Drive

That's basically what #200 is about. But it's not quite so trivial, because individual folders can be case-sensitive (and their subfolders can, in turn, be case-insensitive) - fixing it properly means that the debugger can no longer case-normalize paths as a whole, but needs to do so separately for every path step, so there are perf implications, as well.

bshoshany

comment created time in 11 hours

issue commentmicrosoft/debugpy

"Timed out waiting for debuggee to spawn"

The latter one is the expected behavior (it can't find the IDE side, but that's okay).

Does C:\Program Files\ArcGIS\Pro\bin\Python\envs\dev\python.exe work for you in general when used manually, e.g. to run a simple hello world type script?

Also, judging by the path, this is actually a conda environment - these usually require activation via conda activate before they can be used. I'm not entirely sure how this applies to ArcGIS, though (i.e. where the conda command is located). But if you can figure it out, try running VSCode itself from a terminal where conda activate succeeded.

eykamp

comment created time in a day

issue commentmicrosoft/debugpy

"Timed out waiting for debuggee to spawn"

It's interesting that it didn't produce a server log. What happens if you manually run this in the terminal?

'C:\\Program Files\\ArcGIS\\Pro\\bin\\Python\\envs\\dev\\python.exe' 'c:\\Users\\eykampC\\.vscode\\extensions\\ms-python.python-2020.7.96456\\pythonFiles\\lib\\python\\debugpy' '--connect' '127.0.0.1:63737' '--configure-qt' 'auto' '--adapter-access-token' '64123f9f109fb4c0d3243e365fd401c6b6b24c019445608c6c15552c8f25e6a0' 'c:\\dev\\PIMS - dev\\delme2.py'
    
eykamp

comment created time in a day

issue commentmicrosoft/debugpy

"Timed out waiting for debuggee to spawn"

Those old issues from the ptvsd repo shouldn't be relevant here. But it probably does have something to do with ArcGIS Python. We'll need the logs to figure that out, though. Can you please add this:

"logToFile": true

to your debug config, and then look for debugpy*.log in c:\Users\eykampC.vscode\extensions\ms-python.python-2020.7.96456?

eykamp

comment created time in a day

issue commentmicrosoft/debugpy

"Timed out waiting for debuggee to spawn"

What's the command line like in the terminal?

If you're using "console": "internalConsole" in launch.json, change to "console": "integratedTerminal" and try like that.

eykamp

comment created time in a day

issue commentmicrosoft/debugpy

Debugging Doesn't Work If File Is On Virtual/Network Drive

@fabioz, is this fundamentally the same as #200, or was there something else special about network drives?

bshoshany

comment created time in a day

issue closedmicrosoft/debugpy

Debugger does not kill all processes when terminated

Environment data

  • VS Code version: 1.47.2
  • Extension version (available under the Extensions sidebar): v2020.7.94776
  • OS and version: MacOS 10.15.5
  • Python version (& distribution if applicable, e.g. Anaconda): Anaconda 3.6
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

Expected behaviour

All process are killed when debugger is stopped / terminated.

Actual behaviour

Not all processes are stopped when debugger is terminated. I observed this pattern only when debugging multiprocess application like Flask, Celery. It leaves one zombie process running behind. I'll have to manually kill this process.

Steps to reproduce:

  1. Code
from flask import Flask
app = Flask(__name__)
app.run(host="0.0.0.0", port=5000, threaded=True, debug=True)
  1. launch.json
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "subProcess": true,
        },
  1. Start the debugger and terminate after it starts. The below process is left behind:
501 46232     1   0  9:52PM ??         0:11.50 xxxx/bin/python xxxx/.vscode/extensions/ms-python.python-2020.7.94776/pythonFiles/lib/python/debugpy/_vendored/pydevd/pydevd.py --module --port 50912 --ppid 46228 --client 127.0.0.1 --client-access-token xxxx --multiprocess --json-dap-http --file test_debugpy
  1. When you try to debug the same file again without killing the zombie process, you will get Address in use exception.
  2. This happens when debugging other multiprocessing applications/libraries like celery.

closed time in a day

jahan01

issue commentmicrosoft/debugpy

Debugger does not kill all processes when terminated

https://github.com/microsoft/debugpy/pull/359 should take care of this, as well.

jahan01

comment created time in a day

created tagmicrosoft/debugpy

tagv1.0.0rc1

An implementation of the Debug Adapter Protocol for Python

created time in a day

release microsoft/debugpy

v1.0.0rc1

released time in a day

issue commentmicrosoft/vscode-python

Debugging Doesn't Work If File Is On Virtual/Network Drive

If you compare it to the path for the breakpoint (in the Breakpoints pane), are there any obvious differences, e.g. in variable case? We've seen some issues in the past that were caused by VFS on Windows breaking the usual case-insensitive path behavior.

bshoshany

comment created time in a day

issue commentmicrosoft/vscode-python

VS Code python breakpoints do not work in files under certain folder

Is this specific to OneDrive, or are you also seeing it with non-Latin paths elsewhere on the filesystem?

Also, when you use "stopOnEntry": true, and it breaks, what does the path look like in the Call Stack pane?

gtzedaki

comment created time in a day

issue commentmicrosoft/vscode-python

Debugging Doesn't Work If File Is On Virtual/Network Drive

If you use breakpoint(), does it stop? And if so, what is the path to the file that you see in the Call Stack pane?

bshoshany

comment created time in a day

issue commentmicrosoft/debugpy

Why are multiple debugging threads being started in integrated Python-debugging of VS Code?

The important part is calling main() from under the guard - freeze_support() is just a part of the standard verbiage that's written to be as platform-independent as possible.

Linux does indeed fork by default, but it can also use spawn via set_start_method(). Your call stack above - the one with multiprocessing/spawn.py in it - indicates that to be the case.

AndreasLuckert

comment created time in a day

delete branch int19h/debugpy

delete branch : 125

delete time in a day

push eventmicrosoft/debugpy

Pavel Minaev

commit sha 57ec4c4f65f9bd324872aea0cfe3e04ba84e9e91

Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits. On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits. Improve process tree autokill tests to actually check whether the child process has exited.

view details

push time in a day

issue closedmicrosoft/debugpy

Stop Debugging in a "noDebug" session doesn't kill subprocesses

VSCode Version: 1.42.1

OS Version: Ubuntu 18.04

Steps to Reproduce:

  • Comment "--noreload" in launch.json
  • Press Ctrl + F5 to run the django process.
  • Click "stop(Shift + F5)" button to stop all django processes.
  • But there is still a process (pid 23069) that has not been closed.
  • And its parent process become 1 from 23064

closed time in a day

kenmillar253

issue openedmicrosoft/debugpy

Tests fail due to missing "process" event

This happens sporadically, and can affect any test for which the debuggee process exits quickly. In some cases, it can exit before the adapter gets a chance to report the "process" event. The adapter sends "terminated" in this case, but the tests always wait for "process" first, and so time out.

created time in 2 days

PR opened microsoft/debugpy

Reviewers
Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses

On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits.

On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits.

Improve process tree autokill tests to actually check whether the child process has exited.

+233 -10

0 comment

5 changed files

pr created time in 2 days

push eventint19h/debugpy

Pavel Minaev

commit sha ccbb2258cdee4996053b5af19bd23b1dc3c872e5

Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits. On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits. Improve process tree autokill tests to actually check whether the child process has exited.

view details

push time in 2 days

create barnchint19h/debugpy

branch : 125

created branch time in 2 days

push eventint19h/debugpy

Pavel Minaev

commit sha 4069c670bd022e9e0a429813e75d60a6e95f02f0

Fix #314: Occasional missing response to "configurationDone" Actually handle missing response to "configurationDone". Fix comment for handling missing responses to "launch" and "attach".

view details

Fabio Zadrozny

commit sha 1bef8e5ffb293eea1e19802b869e1fd1dc47f80d

Improve dealing with blocking evaluate requests. Fixes #157

view details

Fabio Zadrozny

commit sha 499bbb2a1ec0f8a7c97d4c0869a63915b7eb926b

Don't patch stdin on debugpy. Fixes #296

view details

Fabio Zadrozny

commit sha ad3ade8e8456f84124b78eb67e5c711bf19b6ad3

Show user traceback for errors raised in the debug console. Fixes #328

view details

Pavel Minaev

commit sha 32ec4ba31b33ad32db940aab30458fba59d3371f

Fix type of PROCESS_SPAWN_TIMEOUT and PROCESS_EXIT_TIMEOUT

view details

Fabio Zadrozny

commit sha 09142fb34ddd5def1e2fe26ecce7139d2cbf4eb9

Fix issue with frame eval mode and multiple breakpoints in generator. Fixes #348

view details

Pavel Minaev

commit sha 2c524faacdceeb7e44ab2b26317defec197cbc85

Fix #305: Add "pythonArgs" config property for interpreter arguments Expose "pythonArgs" to clients. Make "python" usable in tests in lieu of "pythonPath", and make the runners use it. Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

view details

push time in 2 days

push eventint19h/debugpy

Pavel Minaev

commit sha 6fe5fb050eb0c2bb25c8623715a06f1962e11e70

Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses On Windows, run the debuggee in a separate Win32 job, and terminate the job when launcher exits. On POSIX, run the debuggee in a separate process group (PGID), and kill the entire group when launcher exits.

view details

push time in 2 days

issue commentmicrosoft/debugpy

Why are multiple debugging threads being started in integrated Python-debugging of VS Code?

It should generally be at the end of your script, and all top-level code that's not already in a function should be inside main(). The reason is that your script is going to be imported as a module in every subprocess that multiprocessing spawns, so any top-level code will run many times without the guard. But only the instance that's directly started as a script will have __name__ == "__main__".

AndreasLuckert

comment created time in 2 days

issue commentmicrosoft/debugpy

debugger not finding venv's standard library location properly?

Can you show more of the call stack and/or error traceback? I'm curious as to what was calling into runpy - normally you wouldn't call it with a path pointing into site-packages.

demospace

comment created time in 3 days

delete branch int19h/vscode-python

delete branch : 13264

delete time in 5 days

push eventmicrosoft/vscode-python

Pavel Minaev

commit sha 8aa91d15949e172f80491d0f82a184a8d3e41a85

Revert "Fix #11678: Add "argsExpansion" debug property to launch.json schema (#12445)" (#13336) Removing "argsExpansion" due to #13264.

view details

push time in 5 days

PR merged microsoft/vscode-python

Revert "Fix #11678: Add "argsExpansion" debug property to launch.json schema (#12445)" skip news

Removing "argsExpansion" due to #13264.

+0 -8

2 comments

1 changed file

int19h

pr closed time in 5 days

push eventint19h/debugpy

Pavel Minaev

commit sha f497ddaffa3baefa1b30465beca05a08e3d101f7

.

view details

push time in 5 days

push eventint19h/debugpy

Pavel Minaev

commit sha dfbc7f93f5ea38555e3cbc17ff391c71249ac008

.

view details

Pavel Minaev

commit sha cbfaf0447432fab0d0029720d13ca7bbda4bae56

.

view details

Pavel Minaev

commit sha 6c2d1c58968408f5aa5e71247f55fb8494780722

.

view details

Pavel Minaev

commit sha d60cc8f60d449eadc342cc8406d21565b48898a1

.

view details

Pavel Minaev

commit sha cf131c03fabc4b02848cf286389525366f59bbae

.

view details

Pavel Minaev

commit sha d11b88234c4fe47339c397221a12a56d6b72d92c

.

view details

Pavel Minaev

commit sha 7a5e687baa6672021e57c2088c6c4152618426f8

.

view details

Pavel Minaev

commit sha 5b2ef8a64ccd29619893ffcf0495ba671a90c045

.

view details

Pavel Minaev

commit sha 3b365f4dc58e75c0d8414f8450815552f44592cd

.

view details

Pavel Minaev

commit sha 78746eb76eafe6138a4f35136f28f9f3ead235b7

.

view details

push time in 5 days

PR opened microsoft/vscode-python

Revert "Fix #11678: Add "argsExpansion" debug property to launch.json schema (#12445)"

Removing "argsExpansion" due to #13264.

+0 -8

0 comment

1 changed file

pr created time in 6 days

create barnchint19h/vscode-python

branch : 13264

created branch time in 6 days

push eventint19h/debugpy

Pavel Minaev

commit sha 76c554944b2cc1155059a193cce7f936ba606c41

Fix #125: Stop Debugging in a "noDebug" session doesn't kill subprocesses On Win32, use job objects to tie the lifetime of debuggee and its subprocesses to that of the launcher process. On POSIX, run the launcher and its children in a separate process group (PGID), and kill the entire group when launcher exits.

view details

push time in 6 days

issue commentmicrosoft/debugpy

Debugger appears to skip breakpoints with the PtvsdWheels37 experiment

Possibly another manifestation of #346 - note that this is also Python 3.7.

iutlu

comment created time in 6 days

issue closedmicrosoft/debugpy

Does this support calling bash script which then calls python script?

Im trying to do something like

command: -c "pip3 install debugpy -t /tmp && python3 /tmp/debugpy --wait-for-client --listen 0.0.0.0:5678 -c </glue/bin/gluesparksubmit /opt/src/main.py>"

I see in file https://github.com/microsoft/debugpy/blob/4331cf54c0156338d5179b8f5f54126035d448c5/src/debugpy/server/cli.py#L320 - there is a 'run_code' method that might be the general idea of what i am trying to achieve but not sure this is intended use.

closed time in 6 days

dwbelliston

pull request commentmicrosoft/ptvsd

tox.ini: Add Python 3.8 and remove 3.4 and 3.5

Yep, there's an outstanding PR for that - we just need to coordinate a few more things for it to go in.

cclauss

comment created time in 6 days

issue closedmicrosoft/vscode-docs

[Python] Document launch.json "argsExpansion" property

(https://github.com/microsoft/vscode-python/issues/11678)

The "argsExpansion" property allows the user to enable or disable shell expansion of arguments passed to the debuggee via the "args" property. Valid values are "none" and "shell".

If set to "shell" (default), when the app is run in integrated or external terminal, the arguments are passed via shell in that terminal, and various glob and substitution patterns (*, ? globs, $... variable expansion etc) are applied by that shell. For example, assuming Linux+bash, this:

"args": ["/bin/*sh"],
"argsExpansion": "shell" // or omitted

would result in the debugged app seeing something like this in sys.argv:

["/bin/bash", "/bin/dash", "/bin/rbash", "/bin/rzsh", "/bin/sh", "/bin/zsh"]

If set to "none", the arguments are passed directly, circumventing the shell. Thus, in the example above, the app will see ["/bin/*sh"] in sys.argv.

The latter is useful for apps that do their own glob expansion - usually when the arguments are not meant to be filenames. For example, the standard unittest module allows matching tests by class/function name with a glob: -k test_*bar will match test_foobar. But if shell expansion is enabled, then the shell itself will try to expand that * as if it were a filename, and fail because there are no files matching the pattern.

closed time in 6 days

int19h

issue commentmicrosoft/vscode-docs

[Python] Document launch.json "argsExpansion" property

The feature itself has been regressed due to recent VSCode changes, and it's unclear whether we can implement it. It's not going to be surfaced in the Python extension for now, so it shouldn't be doc'd. I'll reopen if we find a way to light it up again.

int19h

comment created time in 6 days

PR closed microsoft/ptvsd

Reviewers
tox.ini: Add Python 3.8 and remove 3.4 and 3.5

https://devguide.python.org/#status-of-python-branches https://devguide.python.org/devcycle/#end-of-life-branches # Python 3.5 EOLs in one month.

+1 -1

1 comment

1 changed file

cclauss

pr closed time in 6 days

pull request commentmicrosoft/ptvsd

tox.ini: Add Python 3.8 and remove 3.4 and 3.5

We're not accepting any more changes to ptvsd; https://github.com/microsoft/debugpy is the new hotness.

But in any case, we do not strictly follow the official EOL dates. They are taken into consideration, but it's not the most important thing. Even if something is EOL'd, but still has a lot of users - e.g. Python 2.7 - we keep supporting it.

cclauss

comment created time in 6 days

push eventint19h/vscode-python

Ian Huff

commit sha a7b023e28dc8b00d2a65589e0e87d02d6f66cd33

bandit warnings pass 1 (#13194)

view details

Dylan Gregersen

commit sha f001bd1ba6521f2b1fa4602e4fef2d5575690fef

Issue 12414 python interactive cell editing shortcuts (#12529) * refactored ICellRange definition to type.ts since it's now used across multiple modules * add command insertCellBelowPosition * add method insertCell to CodeWatcher which inserts at current line * add method insertCellBelowPosition which inserts below current selection * link insertCellBelowPosition to command python.datascience.insertCellBelowPosition * add command insertCellBelow * add method insertCellBelow to the CodeWatcher * link insertCellBelow to python.datascience.insertCellBelow This will insert a cell below the last cell of the current selection * add command insertCellAbove * add method insertCellAbove to the CodeWatcher * link insertCellAbove to python.datascience.insertCellAbove * will insert cell above the top cell of the current selection * add deleteCells command * add deleteCells method to CodeWatcher * link deleteCells to python.datascience.deleteCells * add selectCell command * add selectCell method to CodeWatcher * link selectCell to python.datascience.selectCell * add selectCellContents command * add selectCellContents method to CodeWatcher * link selectCellContents to python.datascience.selectCellContents * modify selectCell to maintain previous orientation of selection anchor and active * fix detection of anchor and active position direction * add extendSelectionByCellAbove * Works similar to excell extend selection by one cell above * Linked command to python.datascience.extendSelectionByCellAbove * add extendSelectionByCellBelow * Works similar to excell extend selection by one cell below * Linked command to python.datascience.extendSelectionByCellBelow * add moveCellsUp * Command to take selected cells and move them one cell up * linked command to python.datascience.moveCellsUp * add moveCellsDown * Moves selected cells one cell down * Linked to python.datascience.moveCellsDown * added news file for enhancement changes being added * add changeCellToMarkdown * command will use selected cell and if cell_type is not markdown will convert to markdown * linked to python.datascience.changeCellToMarkdown * add changeCellToCode * command will use selected cell and if cell_type is not code then it'll convert to code * linked to python.datascience.changeCellToCode * Remove cell edit commands from context menu * Use the insertCell method to insert a cell when RunCellAndAdvance reaches the last cell * Use the insertCell method to insert cell within addEmptyCellToBottom * Add telemetry for cell edit commands in interactive python * Add codeLensFactory.getCodeLensCacheData and abstracted the cell range creation Abstracts the cells behind a method on codeLensFactory. Consolidates storage into the single cached data store on the codeLensFactory though it requires updating again on the codeWatcher. * clean up async and promises within codewatcher.ts * clean up unnecessary Promise.resolve() * refactor unnecessary async functions to sync functions * added unit tests for move cells down * change the when for commands to display when the python file has cells Co-authored-by: earthastronaut <>

view details

Don Jayamanne

commit sha 62a8194d2cde7386d0298ed45da51f65039cd38e

Rename get to getOrCreateModel (#13243)

view details

Don Jayamanne

commit sha e08825bad8c1a3d28ee3e64b4479258e8c0510db

Remove work arounds for SaveAs of Native Notebooks (#13236)

view details

Pavel Minaev

commit sha e7d30e6951c4ebb18a66e52a04efec51a4b8a95d

Fix #13218: Add "pythonArgs" debug property to launch.json schema (#13219)

view details

Ian Huff

commit sha 00451e15ab2a78d5509b83fed942ed059498aa17

Nightly Tests Use Raw for default (#13239)

view details

Don Jayamanne

commit sha d3245b7b9211653dd559303d5497b1919b1625e6

Dispose notebook on close of VSC Notebooks (#13244)

view details

Kim-Adeline Miguel

commit sha 60ef1bdac0ad181cd90390dee750eff184807d98

Add ESLint rules to the repo without enabling them (#13226) * Initial eslint config (+ ts update) * More rule adjustments * Separate eslint config for build/ * More rule adjustments * Newlines

view details

Jake Bailey

commit sha 0b2d404535bc53618fc578936ba5521c123f6b76

Add restart language server command (#12952)

view details

Mikhail Arkhipov

commit sha 047d66749722951954ccb48374861ad4c02f07c5

Limit `python.languageServer` setting scope to `window` (#13246) * Fix path * Actually fix settings * Add news * Add test * Format * Suppress 'jediEnabled' removal * Drop survey first launch threshold * Limit LS to window

view details

Ian Huff

commit sha 30af20ac9c1eca8283cb7a49589c060f9862cdcc

Nightly.variable and interactive window test fixes (#13272) * variable and interactive window test fixes * review cleanup Co-authored-by: Ian Huff <ianhuff@ravikun-dev2.redmond.corp.microsoft.com>

view details

Rich Chiodo

commit sha fdc7d7b9a67ca817489a11c64fbec714c0e61c40

Keep jupyter connections open and allow for expirations (#13267) * Idea for refresh -expiration date * Add expiration functional test * Fixup after merge * Add news entry * Fix sonar problem. * Fix unit test compilation * Fix other unit test compile failure * Dispose timeouts * Try to get test to pass

view details

Joyce Er

commit sha 98f5b496bacc8b093bd81b54645e96202431ab64

Fix when clauses for new interactive cell shortcuts (#13273)

view details

push time in 8 days

pull request commentmicrosoft/vscode-python

Insert rather replace sys.path[0] to preserve PYTHONPATH configuration in .env file

The debugger itself doesn't handle envfiles; it only understands "env". The extension processes "envFile" before the debug session begins, and converts it to "env" entries. In particular, it merges PATH and PYTHONPATH, rather than replacing them.

But also, I don't see why it'd matter? Regardless of what's in PYTHONPATH, sys.path[0] always be the entry dynamically created by Python when launching a script file, and should be the directory in which that script file is located. So, for python .../pythonFiles/testlauncher.py, it should always be .../pythonFiles. If it's something else, I think we need to figure out why that's happening.

I'd start by printing out sys.args, os.getcwd(), and os.environ in the test launcher, to see what the difference is between the debug and the non-debug case.

rajpdus

comment created time in 8 days

GollumEvent
GollumEvent

issue openedmicrosoft/debugpy

"argsExpansion" does not do what it says in VSCode

See https://github.com/microsoft/vscode-python/issues/13264

The option might still be useful for other clients, but the issue highlights the fact that its current name is very client-behavior-specific, and doesn't accurately represent what it does: whether pass the arguments to the debuggee directly, or via the terminal. It should be called something like "argsFormat" or "argsPassing" instead.

Until that's decided, the option as is should not be considered stable, and the docs should reflect that.

created time in 8 days

issue openedmicrosoft/vscode-python

"argsExpansion" debug property is not working anymore

It always behaves as "none" now, because VSCode started escaping arguments in "runInTerminal" request: https://github.com/microsoft/vscode/issues/98471

There's no way for debugpy to work around this, so until VSCode provides the functionality necessary to do it, we should disable the property in the extension (i.e. remove it from the launch.json schema).

created time in 8 days

issue commentmicrosoft/vscode

Autoescaping characters in launch.json args

With respect to "runInTerminal" shell being an implementation detail - I don't think users see it that way. They see the terminal and the shell during launch, and they know that it uses the default shell they configured in the settings, so there's no obvious reason as to why access to features of that shell is so restricted.

If the launch command were passed to the shell as an argument (bash -c ... etc), instead of "typed" as input in the terminal, such that the command is not visible at all, I think that would truly make the shell an implementation detail, and lower those expectations. That would also mean that the terminal automatically exits once debug session is over, however. From our perspective, this is actually preferable, because those leftover debug terminals end up confusing the users (they often don't even notice that it's a new terminal, different from the one they were using before for manual CLI work, and just continue to use it as such).

abhijeetviswa

comment created time in 9 days

issue commentmicrosoft/vscode

Autoescaping characters in launch.json args

My apologies for a belated follow-up!

This issue has an interesting history. Originally, our implementation of the debug adapter propagated debuggee arguments via command line, and thus VSCode's lack of escaping resulted in shell expansion for them. It was not really an intended decision on our part, but our users have discovered it, and started using it as such, as we later found out.

When we rewrote the debug adapter, one of the changes was argument handling - now they were propagated as raw JSON from the "launch" request via a socket. This disabled shell escaping, and we got user complaints about this, e.g. https://github.com/microsoft/debugpy/issues/86 (also an example of a scenario that this feature inadvertently enabled).

Since the change was technically breaking, and we knew that we had users relying on past behavior, we re-implemented argument passing again. But because we already ran into a scenario where shell quoting was not desirable, this time it was made configurable - by default, we reverted back to old behavior of using the shell to pass them, but users could say "argsExpansion": "none" in launch.json to circumvent the shell.

Unfortunately, this change on VSCode side effectively broke our setting, since now it doesn't matter anymore whether the arguments are passed via the shell or not. Which also means that the bug linked above has to be re-opened, since it has been regressed - but we no longer have the means to fix it.

I think it's reasonable to not have shell expansion by default - it can be confusing to users who are unfamiliar with it, and are just trying to pass a string to their app, not to mention being shell-specific; and, on the other hand, the scenarios where it's useful are advanced ones, and so the user can be reasonably expected to know (or read the docs to find out) that they need to enable it. But as it is, we're basically breaking a bunch of launch.json setups that worked fine before, and for which there's no different way to do what they were doing - there are no workarounds here, so far as I can see.

So, my suggestion is to provide some way to reflect this configurability in the "runInTerminal" request, so that debug adapters can make use of it to request escaping if needed, and surface it in their "launch" request schema. It would be even better if it can be done on an argument-by-argument basis, instead of the setup that we had, where the setting applied to all arguments at once. If it all goes into "args", it would be easier for debug adapters to use, as well, since they could just marshal the config setting as is (i.e. wouldn't have to figure out the syntax and semantics for their own setting), with only such additions as the adapter needs to launch the debuggee.

abhijeetviswa

comment created time in 9 days

push eventmicrosoft/vscode-python

Pavel Minaev

commit sha e7d30e6951c4ebb18a66e52a04efec51a4b8a95d

Fix #13218: Add "pythonArgs" debug property to launch.json schema (#13219)

view details

push time in 9 days

issue closedmicrosoft/vscode-python

Add "pythonArgs" debug property to launch.json schema

Corresponding to https://github.com/microsoft/debugpy/issues/305.

closed time in 9 days

int19h

PR merged microsoft/vscode-python

Reviewers
Fix #13218: Add "pythonArgs" debug property to launch.json schema

For #13218

  • [x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
  • [x] Title summarizes what is changing.
  • [x] Has a news entry file (remember to thank yourself!).
  • [x] ~Appropriate comments and documentation strings in the code.~
  • [x] ~Has sufficient logging.~
  • [x] ~Has telemetry for enhancements.~
  • [x] ~Unit tests & system/integration tests are added/updated.~
  • [x] ~Test plan is updated as appropriate.~
  • [x] ~package-lock.json has been regenerated by running npm install (if dependencies have changed).~
  • [x] ~The wiki is updated with any design decisions/details.~
+10 -1

2 comments

2 changed files

int19h

pr closed time in 9 days

push eventint19h/vscode-python

Pavel Minaev

commit sha 6301514f59f739de1d2799e506780a7eb19262e7

Fix #13218: Add "pythonArgs" debug property to launch.json schema

view details

push time in 9 days

push eventmicrosoft/debugpy

Pavel Minaev

commit sha 2c524faacdceeb7e44ab2b26317defec197cbc85

Fix #305: Add "pythonArgs" config property for interpreter arguments Expose "pythonArgs" to clients. Make "python" usable in tests in lieu of "pythonPath", and make the runners use it. Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

view details

push time in 9 days

issue closedmicrosoft/debugpy

Add "pythonArgs" config property for interpreter arguments

There's currently no way to specify interpreter command line arguments without also specifying the interpreter binary - both are done via "python". When used with VSCode, this means that there's no easy and obvious way to use the current selected interpreter in the IDE, but add some arguments to it - one needs to know about ${command:python.interpreterPath} (and I'm not sure this is even guaranteed to not get renamed or removed in future versions?).

We can enable this scenario by providing a separate property to specify just the arguments, similar to "args" for the debuggee itself, and "debugpyArgs" for injected debugpy; the obvious name would be "pythonArgs".

This should work in conjunction with existing semantics for "python" to maintain compatibility - if "python" is an array, and "pythonArgs" is also present, then we just concatenate them in that order to obtain the final value.

closed time in 9 days

int19h

PR merged microsoft/debugpy

Fix #305: Add "pythonArgs" config property for interpreter arguments

Expose "pythonArgs" to clients.

Make "python" usable in tests in lieu of "pythonPath", and make the runners use it.

Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

+32 -13

1 comment

4 changed files

int19h

pr closed time in 9 days

Pull request review commentmicrosoft/vscode-python

Fix #13218: Add "pythonArgs" debug property to launch.json schema

                                 "description": "Path (fully qualified) to python executable. Defaults to the value in settings",                                 "default": "${command:python.interpreterPath}"                             },+                            "pythonArgs": {+                                "type": "array",+                                "description": "Command-line arguments passed to the Python interpreter.",

@luabud I can also edit the description for "pythonPath" to be consistent. :)

int19h

comment created time in 11 days

issue commentmicrosoft/debugpy

Remote breakpoints are not triggered

Since you're debugging a library installed into site-packages, you need to set "justMyCode": false - does that help?

glisignoli

comment created time in 11 days

Pull request review commentmicrosoft/vscode-python

Fix #13218: Add "pythonArgs" debug property to launch.json schema

                                 "description": "Path (fully qualified) to python executable. Defaults to the value in settings",                                 "default": "${command:python.interpreterPath}"                             },+                            "pythonArgs": {+                                "type": "array",+                                "description": "Command-line arguments passed to the Python interpreter.",

Keep in mind that they'll see "args" in the list first, long before they get to this one. I don't think it's very likely that someone will get confused by the tooltip alone... and we always have docs for the detailed descriptions.

int19h

comment created time in 12 days

Pull request review commentmicrosoft/debugpy

Fix issue with frame eval mode and multiple breakpoints in generator. Fixes #348

 from types import CodeType from _pydev_bundle import pydev_log from _pydevd_bundle.pydevd_constants import IS_PY38_OR_GREATER+from os.path import os

This looks like it should just be import os?

fabioz

comment created time in 12 days

Pull request review commentmicrosoft/vscode-python

Fix #13218: Add "pythonArgs" debug property to launch.json schema

                                 "description": "Path (fully qualified) to python executable. Defaults to the value in settings",                                 "default": "${command:python.interpreterPath}"                             },+                            "pythonArgs": {+                                "type": "array",+                                "description": "Command-line arguments passed to the Python interpreter.",

@luabud Please check the wording. I wasn't sure what the most appropriate term to use here, because "pythonPath" description says "executable", but then we seem to be using "interpreter" elsewhere a lot - more consistently so in more recent additions to the extension.

int19h

comment created time in 13 days

PR opened microsoft/vscode-python

Fix #13218: Add "pythonArgs" debug property to launch.json schema

For #13218

  • [x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
  • [x] Title summarizes what is changing.
  • [x] Has a news entry file (remember to thank yourself!).
  • [x] ~Appropriate comments and documentation strings in the code.~
  • [x] ~Has sufficient logging.~
  • [x] ~Has telemetry for enhancements.~
  • [x] ~Unit tests & system/integration tests are added/updated.~
  • [x] ~Test plan is updated as appropriate.~
  • [x] ~package-lock.json has been regenerated by running npm install (if dependencies have changed).~
  • [x] ~The wiki is updated with any design decisions/details.~
+10 -1

0 comment

2 changed files

pr created time in 13 days

create barnchint19h/vscode-python

branch : 13218

created branch time in 13 days

push eventint19h/vscode-python

Don Jayamanne

commit sha 5070438bf2eb58914e50d647f1ba0d90ff996d68

Update workspace file to support debugging multiple extensions (#13207) For #13206

view details

David Kutugata

commit sha 96044d960a3fb913d12cc6ab6b1fa177a31ea274

set kernelspec on the gathered notebook metadata (#13208)

view details

Joyce Er

commit sha 0db8f7c8ca2135d9701f51bcbc8acc91f25578f8

Delete backing ipynbs as soon as remote session is created (#13209)

view details

Joyce Er

commit sha 30b3035999a0d369d4dbad10a7be61e6522dfed9

Rename "Count" column in variable explorer to "Size" (#13211)

view details

push time in 13 days

issue commentmicrosoft/vscode-python

Update launch.json schema to add "python" and remove "pythonPath"

#13218 is now intended as the one and only way of supplying arguments to the interpreter, so "python": [...] shouldn't be exposed in the extension - only scalar string values.

(debugpy will still support the array syntax for backwards compatibility)

int19h

comment created time in 13 days

issue openedmicrosoft/vscode-python

Add "pythonArgs" debug property to launch.json schema

Corresponding to https://github.com/microsoft/debugpy/issues/305.

created time in 13 days

PR opened microsoft/debugpy

Reviewers
Fix #305: Add "pythonArgs" config property for interpreter arguments

Expose "pythonArgs" to clients.

Make "python" usable in tests in lieu of "pythonPath", and make the runners use it.

Add tests for all combinations of "python"/"pythonPath" and "pythonArgs".

+32 -13

0 comment

4 changed files

pr created time in 13 days

create barnchint19h/debugpy

branch : 305

created branch time in 13 days

issue commentmicrosoft/vscode-python

`${workspaceFolder}` & `.` not being resolved in settings in some cases

The real problem here is command line escaping, or lack thereof. Briefly, in cmd.exe, for historical reasons, the following is valid:

dir/s/q

and is the same as:

dir /s /q

There are many convoluted rules there that affect this behavior, and it's not really worthwhile trying to figure them all out. We should just avoid APIs like exec() that take command line argument as a single string - those should do appropriate quoting.

So, basically, always either execFile() or spawn() (with shell: true if needed - it defaults to false for both). But exec() should be an extremely rare case - I doubt we have any scenarios where it's necessary. Any scenario that does justify it, also justifies a lengthy code comment explaining why it's needed :)

And shell: true should only be set if needed, because it's expensive to spawn them, and they introduce more moving bits that can potentially fail. Like, in this case, it would be needed because we're running a batch script on Windows (but perhaps we can avoid that?).

karrtikr

comment created time in 13 days

push eventint19h/vscode-python

Rich Chiodo

commit sha 8bb3ddf71e61bb33ce06c0dc91250e0fd82e98f6

Add package name to output (#12683)

view details

Don Jayamanne

commit sha 0ac275750dce0d83bdf59770fafb69734a51dd0b

Register notebook with VSC only in Insiders (#12681) For #10496 If the API changes, and user is not using the VSC Notebooks or insiders, then swallow errors. Do not register API against stable version of VSCode. Also fixed a test. Basically we need to ensure VSC works when using this API and not crash if the API changes.

view details

Joyce Er

commit sha 21fcb0b21086d302b7f01f012cee3b0c18ac2494

DS: Fixes for trusted notebooks UI (#12685) * Prompt to trust notebook should be error message * Fix apparent bug with markdown editor styling This was causing the markdown cells to jut out 2 pixels to the right of the middle content bar * Refactor readOnly markdown props for consistency * Sign up for keydown / up events when props.readOnly changes

view details

Kartik Raj

commit sha 678e016c86079abc557e6a1a6daab20ba05295ed

Log time taken by pytest hook and increase timeout (#12682)

view details

Eric Snow

commit sha 53e6fcebae17c582367013a0575c7b0b7d9e0087

Move remaining "virtual"-env-related code to the py-envs component tree. (#12516) This change is part of the work to isolate a "component" for Python environments. The focus here is on pulling over the remaining significant sections of code belonging to the "discovery" portion of the py-envs component. There are a few pieces here and there but we'll get those pulled over in later phases. For those most part this PR only moves code between files. In some cases this involves refactoring code so that part of it can be moved.

view details

Rich Chiodo

commit sha 2ac130e64993790bb8500e3227c0808487149213

Fix variable flash when using run by line (#12687) * Add refresh count where appropriate * More refresh cases * Fix run by line test. * Add news entry

view details

Nicolas Kruchten

commit sha ab1eadfb5f846d84969e4ae401f308a337c58b00

Bump plotly.js to 1.54.5 (#12609) * Bump plotly.js to 1.54.5 * update lockfile

view details

Rich Chiodo

commit sha 7c6d40a458ead2083533a784f1501029160dfc5e

Give restarts a chance when running debugger tests (#12696)

view details

Rich Chiodo

commit sha 3a926e25c4499ab85b9604ca3e65aa3186048e09

Refactor ipywidget tests to use real kernel to wait for idle (#12695)

view details

Don Jayamanne

commit sha 05d9e4125bd2e39fea0235792495682ddaa18eaf

Add icon to restart kernel for VSC Notebooks (#12686) For #10496 Existing icon used for restart icon

view details

Peter Law

commit sha 58220ca200dadbdc19f616bfc44b4022f1e54c3b

Update to Jedi 0.17.1 (#12471) * Update to Jedi 0.17.1 This brings completions for Django (via django-stubs, which is now included in Jedi) as well as support for Python 3.9 and various bugfixes (mostly around generic type annotations). * Rename news entry to match GitHub issue

view details

Rich Chiodo

commit sha 744cb928d258a494f9797075fcb6baee0801ce01

Fix export from the interactive window (#12704) * Fix export from the interactive window * Make sure to reset flag at beginning of every test. * Potential fix for linxu

view details

Karthik Nadig

commit sha f8a31a3cea8721eaa4abb5bc9bed317a7b0b701f

Merge back release into master (#12701)

view details

Don Jayamanne

commit sha ea4026367449aca9a0e966514ac4c4801fbfa074

Tests for opening multiple notebooks and toggling (#12703)

view details

Pavel Minaev

commit sha 306885efdae1d316e28e6c69e34a7afd893f247b

Fix #12705: Tests broken due to Prospector / Python 2.7 incompatibility (#12707) Pin prospector to 1.2.0 in test-requirements.txt.

view details

Mikhail Arkhipov

commit sha 7d2d03654595f1935a2ab7586647254ab7c47d3c

Remove language server survey (#12677) * Fix path * Actually fix settings * Add news * Add test * Format * Suppress 'jediEnabled' removal * Drop survey first launch threshold * Remove LS surver * More removal * One more * Typo * Remove unused

view details

Joyce Er

commit sha a067a95315aae8fa862dc602529f06c4293e6307

Add link to python.dataScience.alwaysTrustNotebooks setting (#12702)

view details

Rich Chiodo

commit sha 09625065242c9e4865c9b7c84feabfe11ea34145

Special case failure for windows (#12714)

view details

Don Jayamanne

commit sha 08a0538e450dfcd5a9f1e7b95cd3f7fad2afd09a

Add some logging to a flaky test (#12711) For #12690 Added some logging to see whats causing the tests to fail.

view details

Brett Cannon

commit sha 9c338d4a81ff2c5a0bdcb1c84a1a21b107d88e5e

Drop Developer Tools from the bug issue template

view details

push time in 13 days

pull request commentmicrosoft/vscode-python

Ensure terminal is not shown or activated if hideFromUser is set to true

Sorry, looks like I messed up the notification settings for the repo.

karrtikr

comment created time in 15 days

push eventmicrosoft/debugpy

Pavel Minaev

commit sha 32ec4ba31b33ad32db940aab30458fba59d3371f

Fix type of PROCESS_SPAWN_TIMEOUT and PROCESS_EXIT_TIMEOUT

view details

push time in 16 days

issue closedmicrosoft/debugpy

Interactive prompt

I would like the option of an interactive prompt after a debug run completes. Like when running a script with the "-i" parameter: "python.exe -i myscript.py"

I tried adding "-i" as an argument in the launch.json, but the parameter does not seem to work with the debugger, it causes multiple errors and the script does not run.

closed time in 16 days

Hypernut

issue commentmicrosoft/debugpy

Interactive prompt

If you're adding the argument directly to "pythonPath" in launch.json, i.e. something like "python -i", that won't work - it is treated as a path to the Python binary in its entirety, including any spaces etc, so those are not argument delimiters.

To be able to do this with VSCode, you'll have to wait until we implement https://github.com/microsoft/debugpy/issues/305.

Hypernut

comment created time in 16 days

issue commentmicrosoft/debugpy

Code work well but debugger returns a mistake.

@wuyudi, please try the workaround in https://github.com/microsoft/debugpy/issues/346#issuecomment-663803934 while we investigate.

wuyudi

comment created time in 16 days

issue commentmicrosoft/debugpy

Code work well but debugger returns a mistake.

@fabioz, this might be another manifestation of the root cause #346 - repros in VSCode on 3.7 (i.e. with native bits), but not on 3.8.

Furthermore, repro does depend on where exactly breakpoints are set - in my experiments, it requires breakpoints on lines 2 and 3, but having it on 3 alone works fine. So I think there's some interaction between those two that causes the conditional logic behind the iterator to take a wrong path somewhere.

wuyudi

comment created time in 16 days

issue commentmicrosoft/debugpy

Why are multiple debugging threads being started in integrated Python-debugging of VS Code?

Debugger does spawn background threads - that's an unavoidable part of the implementation. However, you wouldn't see those threads in the Call Stack window. They are also not running your code, so "executing the same code several times simultaneously" does not apply. Same thing goes for subprocesses.

This behavior doesn't reproduce for me on any simple app, so we'll need some more information to repro. Most likely, this has more to do with the code being debugged, or with the libraries that it uses.

In addition, I'm curious as to what lead you to conclude that those threads execute the same code. Did you try pausing and inspecting the call stacks in other threads to see what code is running there? If not, doing that might shed some light on what's spawning the threads.

AndreasLuckert

comment created time in 16 days

issue commentmicrosoft/debugpy

Debugger Heisenbug where integer comparison appears to fail within a specific context

The crucial requirement for the repro is Python 3.7, although I suspect this has more to do with us only shipping Cython binaries for that.

dddvision

comment created time in 16 days

issue commentmicrosoft/debugpy

Debugger Heisenbug where integer comparison appears to fail within a specific context

@fabioz, can you take a look? It might be a rare corner case, but changing behavior of running code like that is very concerning.

dddvision

comment created time in 17 days

issue commentmicrosoft/debugpy

Difficult to resolve various import issues

The problem with such features is that if they try to be too smart, they end up doing the wrong thing that kinda sorta works, until it doesn't. I suspect that this is exactly how you ended up with those from nw ... imports - because PyCharm helpfully "corrected" your code (which didn't need correction!).

valhuber

comment created time in 18 days

issue commentmicrosoft/debugpy

Debugger Heisenbug where integer comparison appears to fail within a specific context

It would probably be easiest to just set it as a global environment variable - that way it'll also apply to "attach" sessions.

dddvision

comment created time in 18 days

issue commentmicrosoft/vscode-python

Activating to run Jupyter failed

The error message "stdin: is not a tty" does not originate from conda. It originates from bash, or rather more specifically, from a common (and, arguably, broken) bash setup that tries to run mesg without checking whether the shell is running in a tty context or not first. Here is a lengthy explanation - note that there's no Python in the picture at all.

But anyway, the message is actually a warning. The problem is that it's printed to stderr, and it looks like the code that's invoking exec() here treats any stderr output as a fatal error. If it simply ignored that message, I think activation would have worked just fine.

opoloko

comment created time in 19 days

issue commentmicrosoft/vscode-python

Can't expand to check the data of a Variable when debugging pytorch code

Infinite expansion is not an issue with the debugger - it just faithfully reports what attributes the object has; and in this case, the data attribute seems to be recursively referencing itself.

rardz

comment created time in 19 days

issue commentmicrosoft/debugpy

Difficult to resolve various import issues

This is by design of Python itself - specifically, how it handles sys.path.

As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter.

Or, in other words, when you do:

python ./nw/build_view_file.py

the first entry on sys.path isn't going to be . - it's ./nw. Thus, when you later do:

from nw.build_views import build_views

it won't be able to find package nw, because you're inside the directory that constitutes said package.

In other words, if you're running a Python file as a script, and it expects to import modules and packages, those modules and packages should be located alongside the script. In this case, since build_view_file.py uses nw as a package, it needs to be in the workspace folder itself.

Although I don't think nw is intended as a package, given that it's missing __init__.py, and given that you're importing app and app.models directly in the same Python script without trying to qualify them with nw. In which case, that line should properly read:

from build_views import build_views

(and you also need to do the same with all your other scripts that do import nw or from nw ...).

Note that this all has nothing to do with the debugger. The only thing to be aware of is that "file": ".../foo.py" in your launch.json behaves exactly as python .../foo.py would, including wrt sys.path.

valhuber

comment created time in 19 days

issue commentmicrosoft/debugpy

Attach to local process assumes i386 architecture?

I think this one is about reporting the error clearly at this point.

Those other issues are separate, because the debugger itself already works on ARM platforms, just not the native bits like attach-to-PID. So there's no reason why we shouldn't be running CI on ARM today already, if we could easily do that.

okz

comment created time in 19 days

issue commentmicrosoft/debugpy

Debugger Heisenbug where integer comparison appears to fail within a specific context

Can you try setting PYDEVD_USE_FRAME_EVAL=NO in environment variables, and see if that helps? Since you're launching the program using the debugger, you should be able to set it via "env" in launch.json.

dddvision

comment created time in 19 days

issue commentmicrosoft/debugpy

Shell expansion is not working in "args"

It looks like https://github.com/microsoft/vscode/issues/98471 regressed this on VSCode side. Need to clarify if this is the intended behavior.

llabusch93

comment created time in 20 days

issue commentmicrosoft/vscode-python

Certain strings set in the launch.json "args" will not be passed to python as arguments

We don't have clear evidence that one or the other is preferable by default. There was one beta of debugpy which didn't do any expansion, and there were bugs filed about it, as well. We're sticking to pre-existing behavior on the basis that it's at least what more users are familiar with, whether they prefer it or not.

jebdev1

comment created time in 20 days

issue commentmicrosoft/vscode-python

Debugger Heisenbug where integer comparison appears to fail within a specific context

I couldn't readily repro it with these steps, unfortunately. It might be that there's some hidden variable at play here....

Can you check something on your repro? When you step through the program, if you have the Run view open, you should be seeing line numbers in the Call Stack section. Do they reflect the highlighted line in the editor? Or are they correct, but the editor is highlighting the wrong line?

dddvision

comment created time in 20 days

issue commentmicrosoft/vscode-python

Terminal opens on any output

@willwhitney I think you're hitting https://github.com/microsoft/vscode-remote-release/issues/2806

willwhitney

comment created time in 20 days

more