I'm trying to use NetBeans 8.1 with Cygwin to write, compile and debug a C program. I knew nothing about C when I started this, and somehow found my way to fixing all the compiler errors. But when it came time to debug there was no debugger! Long story short, there's no gdb.exe in the Cygwin/bin directory and even a fresh install of Cygwin didn't produce one.
I tried another gcc compiler that did have gdb, but Netbeans won't use it.
I really don't know anything about debugging C in Netbeans with Cygwin. All I wanted to do was just bash my way through this one C program because I need to access a C library.
Alternatively, does anyone know if and how to run a C subroutine in python? (A vastly superior language to C/C++, in my opinion.)
I would be delighted to get access to this C library from either NetBeans or rewrite my access code in python.
Cygwin setup can install ~ 4000 packages.GDB is one of them.
Why do you think GDB should be installed by default ?
Please read:
https://cygwin.com/cygwin-ug-net/setup-net.html#setup-packages
(I wrote this before I saw matzeri's response. I still may try extending python to run code from the C library, but getting the C code I've already written to work would be vastly preferable.)
I have no idea what's going on with Cygwin's gdb, but after getting over my frustration I answered my alternative question. Turns out you can indeed call a C function from python. Extending Python with C or C++
I'll try it tomorrow and I see caveats, but if python.org has a section on it, I'm betting it can be done.
Related
I would like to know if I am going in the right direction.
I wrote a script in python and was able to run it through Matlab.
Now I would like to make it available for potential other Matlab users who do not have python installed.
I wanted to make sure that I can do such a thing by compiling my python file.
Also, the compilation in python does not seem straightforward (for example, making a dll How to compile a Python package to a dll extending python with C) and potentially, there are some other solutions to my problem that I would be happy to investigate.
thank you for your help
ps : if it matters, my python script is using TensorFlow, sklearn, numpy, scipy, pandas
Sorry for that, I think I'm really mistaking in something simple because I could not even find someone with a similar problem after some googling.
I firstly got the error when I tried to use fireplace's :Connect.
Apparently it is installed (but not corretly, because :help fireplace doesn't work) but it returns Python interface not working.
Again, sorry for this newbie question.
Read the documentation:
The only external dependency is that you have either a Vim with Python support compiled in, or python in your path.
There you have it. Make sure you have Python in your path (typing python on the command-line brings up a Python interpreter), or install a Vim with Python support (in Vim, :echo has('python') returns 1). You can find many many questions and answers with the details for both of these on Stack Overflow.
I've been writing C extensions to Python for a while, but have been on other tasks for the past year or so. It looks like I'm going to come back to this soon, but in the meantime I've upgraded my Mac to Mavericks. And of course, suddenly, EEK! GDB is gone! And I can't find a startup file for LLDB (like the existing GDB version in Misc/gdbinit) that knows how to reach into the CPython interpreter and tell me about objects. (Or any easy Emacs-LLDB integration like I had with GDB.)
What's the consensus on the best way to debug C extensions now? Go build a custom GDB? Learn LLDB and write my own integration? Use some IDE that 'just does' all this? Just stop trying to do this on a Mac and do it in Linux instead?
(Just to make things even more fun, I need to do this in Python 2.6 to be compatible with our existing RHEL installations... which means I also need to fix the readline bug that causes Python 2.6 to crash on Mavericks -- and that's how I discovered these issues. Sigh.)
complete Python noob here (and rusty in C).
I am using a Mac with Lion OS. Trying to use NFCpy, which uses USBpy, which uses libUSB. libUSB is crashing due to a null pointer but I have no idea how to debug that since there are so many parts involved.
Right now I am using xcode to view the code highlighted but I run everything from bash. I can switch to Windows or Linux if this is going to be somehow easier with a different environment.
Any suggestions on how to debug this would be much appreciated ;-)
PS: It would be just fine if I could see the prints I put in C in the bash where I run the Python script
You should see your printf() you put in C in your terminal, something is already wrong here. Are you sure that you're using the latest compiled library? To be sure, instead of print, you can use use assert(0) (you need to include assert.h).
Anyway, you can debug your software using gdb:
gdb --args python yourfile.py
# type "run" to start the program
# if you put assert() in your code, gdb will stop at the assert, or you can put
# manual breakpoint by using "b filename:lineno" before "run"
Enable core dumps (ulimit -Sc unlimited) and crash the program to produce a core file. Examine the core file with gdb to learn more about the conditions leading up to the crash. Inspect the functions and local variables on the call stack for clues.
Or run the program under gdb to begin with and inspect the live process after it crashes and gdb intercepts the signal (SIGSEGV, SIGBUS, whatever).
Both of these approaches will be easier if you make sure all relevant native code (Python, libUSB, etc) have debugging symbols available.
Isolating the problem in a program which is as small as you can manage to make it, as Tio suggested, will also make this process easier.
PS: It would be just fine if I could see the prints I put in C in the bash where I run the Python script
You didn't mention anything about adding prints "in C" elsewhere in your question. Did you modify libUSB to add debugging prints? If so, did you rebuild it? What steps did you take to ensure that your new build would be used instead of the previously available libUSB? You may need to adjust your dylib-related environment variables to get the dynamic linker to prefer your version over the system version. If you did something else, explain what. :)
I'm wanting to use an extension for Python that I found here, but I'm using Python 3.1 and when I attempt to compile the C extension included in the package (_wincon), it does not compile due to all the syntax errors. Unfortunately, it was written for 2.x versions of Python and as such includes methods such as PyMember_Get and PyMember_Set, which are no longer part of Python. My problem is that I have not gotten around to learning C and as such have not been able to figure out how to modify the code to use syntax that is still valid in Python 3.1. (There were also a couple macros such as staticforward that need fixing, but I'm assuming those just need to be changed to static.) Therefore: how do I go about fixing this?
(Note that I have indeed looked into various other Windows console interfaces for Python such as the win32con extension in PyWin32), but none of them fit my needs as much as this one appears to.)
I don't believe there is any magic bullet to make the C sources for a Python extension coded for some old-ish version of Python 2, into valid C sources for one coded for Python 3 -- it takes understanding of C and of how the C API has changed, and of what exactly the extension is doing in each part of its code. Believe me, if we had known of some magic bullet way to do it susbtantially without such human knowledge and understanding, we'd have included a "code generator" (like 2to3 for Python sources -- and even that has substantial limitations!) for such C code translation.
In practice, even though Python 3.1 is per se a mature and production-ready language, you should not yet migrate your code (or write a totally new app) in Python 3.1 if you need some Python 2.* extension that you're unable to port -- stick with 2.6 until the extensions you require are available (or you have learned enough C to port them yourself -- or rewrite them in Cython, which DOES smoothly support Python 2.* and 3.*, with, I believe, just a modicum of care on the programmer's part).