profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/int19h/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Pavel Minaev int19h Microsoft North Bend, WA, USA

int19h/aow-patch 15

Unofficial patch for Age of Wonders

int19h/WarBender 11

WarBender: a Mount & Blade: Warband save game editor

int19h/Bannerlord.CSharp.Scripting 6

C# scripting for Mount & Blade 2: Bannerlord

int19h/warbend 3

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

int19h/nwn-2da-tlk-editor 1

A mirror of https://archive.codeplex.com/?p=nwn2datlkeditor, with project and solution files updated for VS 2017

int19h/Bannerlord.NoRelation 0

No Relation mod for Mount & Blade Ⅱ: Bannerlord

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.

issue commentmicrosoft/pylance-release

Incorrect parsing Python r-string containing left parenthesis

Turns out this isn't a bug at all, but rather by design. The Textmate Python grammar assumes that r"" literals are mostly used for regex, and so it tries to highlight its contents as such; hence why the parentheses are of different color. If you put (?#foo) somewhere in the string, you'll see that it will be highlighted as a comment etc.

vsfeedback

comment created time in 2 days

PullRequestReviewEvent

issue commentmicrosoft/debugpy

notification like "Failed launch debugger for child process xxxx".

Thing is, child processes aren't supposed to start running anything until there's a debugger connection to them that has gone through the entire initialization stage (otherwise breakpoints might be skipped etc). So either the pool killing processes due to some kind of timeout, before they even had a chance to run anything; or there's some bug in how subprocesses are resumed.

liheyi360

comment created time in 2 days

issue commentmicrosoft/debugpy

When debugging stops in a "Subprocess", code is navigated to a strange read-only version of the current file

For "Attach to Process", you shouldn't need to import debugpy etc at all in your process - the whole point of that feature is that it injects the debugger without requiring the process to cooperate.

But once injected, it works the same as regular remote, so I don't think it'd make a difference in this case.

munael

comment created time in 2 days

PullRequestReviewEvent

issue commentmicrosoft/debugpy

Python extension sends "setPydevdSourceMap" when a ms-vscode.cpptools debugger is attached

This is not a debugpy issue, since debugpy doesn't send this message - only receives and processes it. The bug is in the code that sends it.

I left a comment on the original issue in vscode-jupyter with more details.

tjahn

comment created time in 3 days

issue closedmicrosoft/debugpy

Python extension sends "setPydevdSourceMap" when a ms-vscode.cpptools debugger is attached

Hello,

some time ago I started to experience a problme when debugging my C++ / Python project with VSCodes C++ debugger (sadly I do not know, when this problem arose). I already brought the bug up in microsoft/vscode-cpptools#8115 and microsoft/vscode-jupyter#7480, but both maintainers do not think that the bug is on their side.

Description

VSCode interactive Python crashes when trying to run cells after attaching the ms-vscode.cpptools C++ debugger to the Python process.

I develop a Python extension in C++. For debugging I start my python script with vscode using the interactive cell mode, attach the C++ debugger from the ms-vscode.cpptools extension to the process and then start calling cells. This worked until some weeks ago (though I do not know which extension versions I used back then).

Expected behaviour

I should be able to connect the C++ debugger from the microsoft/vscode-cpptools extension and use breakpoints etc in my C++ module, even when running it in the interactive Python process started by vscode.

Actual behaviour

As soon as the next interactive Python cell is run from vscode the interactive Python session crashes. The attached C++ debugger also crashes with the following message in VSCodes Debug Console:

Stopping due to fatal error: InvalidOperationException: No handler registered for request of type 'setPydevdSourceMap'!

I only found this message type in the microsoft/debugy repository and its predecessor.

Steps to reproduce:

  • Install the extensions ms-python.python and ms-vscode.cpptools.
  • create a Python script
# %% first run this cell to start the Python process and get its PID
import os
print(os.getpid())
# %% after attaching the debugger run this cell to trigger the error
print("test")
  • execute the first cell of the Python script in vscode interactively
  • attach you debugger to the printed pid using the following launch.json entry { "name": "(lldb) Attach Debugger", "type": "cppdbg", "request": "attach", "program": "/proc/${command:pickProcess}/exe", "processId": "${command:pickProcess}", "MIMode": "lldb", },
  • try executing the second cell after the debugger attached

Environment data

  • VSCode 1.60.0 on MacOS Big Sur 11.5.2
  • remote SSH server is an OpenSuse 15.2
  • ms-python.python@v2021.9.1191016588
  • ms-vscode.cpptools@v1.6.0.
  • debugpy version: 1.4.3 (in the .vscode-server/extensions/ms-python.*/...... directory)

closed time in 3 days

tjahn

issue commentmicrosoft/vscode-jupyter

Cant connect C++ debugger to interactive python session anymore

This is, indeed, a custom DAP message that debugpy handles. However, it is not sent by debugpy; it is sent by vscode-jupyter:

https://github.com/microsoft/vscode-jupyter/blob/38962619f8952b06b19b7932ec4380786e3c9ee9/src/client/datascience/jupyter/jupyterDebugger.ts#L94-L106

Thus the bug is that vscode-jupyter sends the message to the incorrect debug session - the C++ one, in this case.

And I'm not sure whether this has anything to do with the C++ session debugging the same process as the Python session. VSCode has a workflow where the user can start multiple unrelated but concurrent debug sessions. If this issue also repros in that scenario, it is a genuine bug - unrelated debug sessions shouldn't interfere with each other.

(Note, however, that even with that fix, it still wouldn't work, because debuggers generally need to assume full control of the process being debugged. So having two of them trying to independently control the same process will result in all kinds of breakage, possibly unreported.)

tjahn

comment created time in 3 days

push eventint19h/debugpy

Fabio Zadrozny

commit sha fdd1f4dc38342d6d2b3d5daf76db8dfa8e4cec99

When possible collect try..except information from source and not bytecode.

view details

Pavel Minaev

commit sha 7cb12bed8bff4c8b7f54daee0375f2c670c323ec

Fix versioneer not updating _version.py.

view details

Daniel Gerigk

commit sha 5dc21d67b3928dd2d393e22203c1e100ba56c256

Don't interrupt debugger on flask reload (#721)

view details

Steve Kowalik

commit sha 9d8bb3fa3c9492dc9a7386a08a6e2adf635659a3

Correct pthread library name in find_library() ctypes.util.find_library() does not require the "lib" prefix, and may throw an exception depending on the environment, so drop the prefix when finding it.

view details

Fabio Zadrozny

commit sha 869babbd9370cd5b5a4f4683f6d5460af33906c8

Python 3.10: support for cython and frame eval mode.

view details

push time in 4 days

issue commentmicrosoft/debugpy

Debugpy output is not localized

To fix this, debugpy (and pydevd) would have to start respecting the "locale" property of the "initialize" DAP request.

Aside from the logs - which are used for debugging and diagnostics only, and are not normally exposed to the users - debugpy has relatively few strings that would need to be localized; mostly, it's error messages. I believe there's more in pydevd, but also not too many.

@fabioz, are there any outstanding localization plans for pydevd?

AdamYoblick

comment created time in 4 days

issue commentmicrosoft/debugpy

Support `post_mortem` debugging

Yep, we decided to enable the option with the current wording.

TauPan

comment created time in 4 days

issue commentmicrosoft/debugpy

Autocomplete does not work in debug console of the first debugging session

I can't repro this, on Anaconda or otherwise. Can you please share a step-by-step repro, including your launch.json, directory layout, and source code?

serend1p1ty

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmicrosoft/PTVS

Fix component governance bugs

         {             "Component": {                 "Type": "pip",-                "pip": { "Name": "debugpy", "Version": "1.0.0rc2" }+                "pip": { "Name": "debugpy", "Version": "1.2.0" }

This version is almost one year old by now. Should this be 1.4.3?

AdamYoblick

comment created time in 5 days

PullRequestReviewEvent

pull request commentmicrosoft/debugpy

Update pydevd_process_net_command_json.py

@fabioz Can you take a look?

Daniel-DI

comment created time in 12 days

created tagint19h/Bannerlord.CSharp.Scripting

tagv1.1.1

C# scripting for Mount & Blade 2: Bannerlord

created time in 13 days

push eventint19h/Bannerlord.CSharp.Scripting

int19h

commit sha cc012b9a5ec7469aaca70a2a718798443808910d

Fix crash when starting a new game. Update version number.

view details

push time in 13 days

created tagint19h/Bannerlord.CSharp.Scripting

tagv1.1.0

C# scripting for Mount & Blade 2: Bannerlord

created time in 14 days

push eventint19h/Bannerlord.CSharp.Scripting

int19h

commit sha 7aaf77e43f769d94caa2abd2c0d84b02c893fcfc

Update documentation.

view details

push time in 14 days

push eventint19h/Bannerlord.CSharp.Scripting

int19h

commit sha 0f63f2ee57b580e374586b8ebe9ca099793b268f

Update version number.

view details

int19h

commit sha 94dadf3965f406bceafb47c92629177a6ba552eb

Don't generate #defines for 1.5.x

view details

push time in 14 days

push eventint19h/Bannerlord.CSharp.Scripting

int19h

commit sha 2df4ad9f47ffab18162ba3265fd8b61940a51911

Ignore type and member visibility in scripts.

view details

int19h

commit sha 8dc5860e29d531d31a9a56da8f5642fc47a983e7

Add helpers to ignore visibility at runtime.

view details

int19h

commit sha 7ace4bc4ad8c982bb10a9d25f24c836e21f408ac

Add more lookup tables, and fix existing ones for 1.6.

view details

int19h

commit sha 94be8c72aa778120fa2809ed7cafacf612df2149

Add class invoker (WIP, disabled).

view details

int19h

commit sha 1bb5f771bc2e52575db6ac59d7330b4181db8042

Add OnGameStart hook.

view details

int19h

commit sha 89b9e94c92e0daba4286a07e797da9a12bdaaf5a

Fix scripts for 1.6.x

view details

push time in 14 days

delete tag microsoft/debugpy

delete tag : v1.4.2

delete time in 16 days

release microsoft/debugpy

v1.4.3

released time in 16 days

created tagmicrosoft/debugpy

tagv1.4.3

An implementation of the Debug Adapter Protocol for Python

created time in 16 days

created tagmicrosoft/debugpy

tagv1.4.2

An implementation of the Debug Adapter Protocol for Python

created time in 16 days