We Keep Coding

Xcode can't attach to PyCharm debugging process

I have a c++ library that I can debug in Xcode.
This library is 'bridged' to python via SWIG. I have some python code running, making calls to the library. In PyCharm I can debug the python version.
I would like to debug the c++ code that is called by the python function, using the Attach to Process feature of Xcode, in order to
check that the python call is correct, and
the arguments are passed as expected.
So, I start debugging the Python code from PyCharm, stop at a breakpoint (early) in the python code, identify the Python PID using os.getpid(), then in Xcode I try to attach to that process. However I get an error:
"error: attach by pid '61889' failed -- attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries when the attached failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)"
In the console I can't see any message about why it was denied.
Any idea? Is it a setting in PyCharm? In Xcode? In the system?
My setting: Mac OS 10.15, Xcode 12.4, PyCharm 2020.1; Python 3.7

Runaway Jedi Language task in VSCode

Every time I close VSCode (after running some Python script) I have a Python task that lingers in my terminal running 90-100% CPU on my M1 MacBook Air, and I have to manually kill it every time. I ran the following on the PID:
ps aux | grep <PID>
and it returns the same thing every time...
Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/Resources/Python.app/Contents/MacOS/Python /Users/<user>/.vscode/extensions/ms-python.python-2021.2.625869727/pythonFiles/runJediLanguageServer.py
I checked my VSCode extensions, and I don't have any "Jedi" ones installed, but maybe it's a lingering task from some other extension.
Any ideas how to fix this?

The solution as provided in the link Valy provided above is to:
Open the command palette (View > Command Palette...)
Run the "Preferences: Open Settings (JSON)" command. This will open the user settings in VS code
Paste the following line in the settings file:
"python.experiments.optOutFrom": ["pythonJediLSP"]
Reload the window (either by closing VS Code and opening it again or running the "Developer: Reload Window" command from the command palette)
reference: Rogue Python Processes with High CPU Consumption issue #15586

I had the same issue as apparently VSC is experimenting with a new feature. Another user helped me find the solution, which can be found here: https://github.com/microsoft/vscode-python/issues/15586#issuecomment-792360066

When using python in VS Code, it requires us to install the "python" extension, and it will automatically load the corresponding language service to better identify and analyze the code.
"Visual Studio Code provides smart editing features for different programming languages through Language Extensions. VS Code doesn't provide built-in language support but offers a set of APIs that enable rich language features."
We can use different python language services: Jedi, Microsoft, Pylance, and so on, and VS Code uses Jedi by default:
Reference:Language Server Extension Guide and Language Extensions Overview.

Debugging from PyCharm to Visual Studio C++ code

I'm currently trying to debug issues in Caffe for Windows PyCaffe.
Because of a bug in Python Tools for Visual Studio, PTVS doesn't work so I'm using PyCharm and trying to attach to PyCaffe's process through Visual Studio 2013. That is, I'm running PyCharm debugger on a Python script with a breakpoint set at the point where I call the Python entry point into PyCaffe.
I debug the Python script in PyCharm which calls modules written in C++ in VS. I want to debug those modules in C++. So I'm trying to attach to the PyCharm or Python processes with breakpoints set in VS.
The problem is that the breakpoint isn't firing at the entry point in PyCaffe in the Visual Studio C++ code.
Has anyone successfully gotten this kind of thing to work or is there an alternative way of doing this?

I faced a similar problem a few years ago, trying to
debug a user-mode driver wish was loading automatically from a RPC, the solution I found was:
Download Debugging Tool for Windows (depending on your system x86 or x64), wish is free,from the Microsoft Download.
Add "__asm int 3"(this is asm instruction for a hardware breakpoint) in the place on the C code where you whant to the break point to take effect.
Compile the C program, nomally with debug info (this part is important,because help the Debugger to find the source file), this should not make any problems.
Attach the Debugger to the running process (in my case was the explorer process), in your case should be the process that make first call to the library, for example if PyCharm create a process for the new python code, the debugger need to be attached to that process(you can manage this by setting a breakpoint in python, wish will give you time for doing the attach process), the easy way for me to figure this out was to let the process crash, because "__asm int 3" cause a process crash if a debugger is not attach, you can take advantage of this waiting for the crash and when windows shows you the screen "Process ... has detected a problem an need to be closed", you know who is the process that you are looking for.
This could be painful the first time but for me quite effective, because you
can see the data flow from one program to another,

We attach to one process and allow to set breakpoints within code that has not started from the VS debugger. But one important issue is that we often debug/run the app in the VS, for example, we debug the Web code that runs under IIS, we will attach to the IIS process or others.
Your project is different from the above sample, you run/debug your app in Pycharm (not the VS), but you want use the VS Attach to process function, so it would have a limitation. As you said that you debug script in PyCharm, and want to call C++, so you would check that whether the PyCharm supports a similar feature like the attach tool in VS.

Invoking 64-bit console from 32-bit python

I'm attempting to write a script that will gather the output of a few basic windows commands into a set of files, and am finding my vssadmin commands frustrating. The command is a relatively simple
os.system('vssadmin list writers>> x:\foo\vss.txt')
The problem is that I'm writing in python 32-bit and want to make sure this will function on 64-bit Windows. When executing this, the return is:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line
tool (C) Copyright 2001-2005 Microsoft Corp.
Error: A Volume Shadow Copy Service component encountered an
unexpected error. Check the Application event log for more
information.
Can I invoke a 64-bit command line from 32-bit python and decide whether to invoke it with a bit-depth detecting function, or is there another more elegant solution?
Follow-up: using MBu as a jumping off point I found that the following command does the trick:
os.system('%systemroot%\\sysnative\\cmd.exe /c vssadmin list writers > x:\\foo\\vss.txt')

Under Windows 2008 or newer you can launch c:\Windows\Sysnative\vssadmin.exe. Under Windows 2003 a hotfix is needed, but you can also create a filesystem junction to reach the 64-bit system file from 32-bit applications. For details see my answer to this question. While it was about launching 64-bit cmd.exe from 32-bit cmd.exe, the rules stay the same for all applications.

Launch C:\Windows\SysWOW64\vssadmin.exe explicitly to always get the 64-bit version.

How to get input from gdb in emacs (with python script)

I want to use python to create some interactive script for gdb. It works well in gdb, but it doesn't work if I invoke gdb from emacs.
For example, the python script (test.py) is like below. It simply print what it gets.
def testInput():
n = raw_input('(gdb) ')
print n
It works in gdb:
% gdb
GNU gdb (GDB) 7.2.50.20110217
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) source test.py
(gdb) python testInput()
(gdb) 1
1
(gdb) q
But in emacs, it will just hang in "raw_input" and could never get the input:
(gdb) source test.py
(gdb) python testInput()
(gdb) 1
2
...
Is there anyway to make it work just as in gdb?

Invoking gdb with M-x gud-gdb solved the problem for me. For further details confer chapter 27 of the Emacs manual.
Hope this is still helpful after two years...

When using an interactive external process in an emacs buffer, the mode needs to be able to recognize from the buffer when the external process is prompting the user for input so that it knows it need to allow the user to input something. Otherwise, emacs will just wait forever for the process to output something it recognizes and the process will be waiting forever for input. Since your python script uses a different prompt, the emacs gdb mode never recognizes that input is being solicited.
Try modifying the value of gdb-prompt-name-regexp. Here's the default value from gdb-mi.el:
(defvar gdb-prompt-name-regexp "value=\"\\(.*?\\)\"")