pythonloc is a drop in replacement for python that automatically recognizes a __pypackages__ directory and prefers importing packages installed in this location over user or global site-packages.
If you are familiar with node, it is similar to node_modules.
I've been using Stator[0] which uses a global JavaScript object with get(), set(), and connectComponentState() methods that selectively call setState() on components that connect to the global state.
It has worked really well for me on a 5k+ LOC frontend to gdb called gdbgui[1]. It's performant, but perhaps more importantly, it matches my mental model of how the code works (essentially a global setState, can log changes to the console, do type checking, etc.) so I can work more efficiently. Stator was originally part of gdbgui, but since the pattern worked so well for me I extracted it into its own library.
Just wanted to mention gdbgui, a new front end to gdb that I developed which is similar to Chrome's debugger, has a gdb terminal which you can fall back to if you want to run gdb commands, and data structure/value plotting and visualizations similar to ddd.
Awesome! Does it support gdb startup scripts? I.e. the gdb -x option which instructs gdb to read and execute commands from a file and then drops you off in the normal prompt. I regularly use that, because it lets me keep and organise startup options for the programs I work on. I really don't want to have to type all the "set environment" &c stuff that's necessary for the programs I want to debug.
Does it (can it) work with the gdb pretty-print API? On the console I can define pretty printers for my data types using python, so I can examine them easily. I almost never want to explore a struct by expanding its fields, I just have a bunch of python scripts that extract a summary of what's important. E.g. for a 3-component vector type I don't need or want something like
{
x = ...
y = ...
z = ...
}
I just have a pretty-printer that spits out "MY::Vector(x, y, z)". Similarly for a whole bunch of other classes. I especially don't want to look at STL objects by field, that's just insane.
Honestly, after a couple of years of using GDB, the console interface isn't really a problem for me, and I've become quite attached to the many customisation and automation features it offers. While the commands and syntax are all kinds of gnarly, I don't think I can ever go back to a debugger where I have to do everything manually via direct control. Better, faster, more intuitive direct control is always a good thing, but I don't want it if it's at the expense of the programmability of the debugger.
This looks great! Did you know that you can also use Chrome's debugger to debug Node? I wonder how difficult it would be to use Chrome's debugger as a front end for gdb.
Never tried, but pygdbmi would probably get you halfway there. It uses python to parse structured data (key/value pairs) from gdb output. Gdbgui uses it on its backend. (Disclaimer: I am the developer)
I recently added data structure visualization to a gdb frontend called gdbgui, which might be of interest to people trying to debug their algorithms. https://github.com/cs01/gdbgui
I'm trying to add support for lldb to a gdb frontend (https://github.com/cs01/gdbgui/), and need a gdb-mi compatible interface to do it.
lldb-mi exists, but its compatibility with gdb's mi2 api is incomplete. Does anyone know of a more compatible api to gdb-mi2 commands, or if there are plans to improve lldb-mi's?
If you are familiar with node, it is similar to node_modules.
This is a pure Python implementation of the proposal laid out in PEP 582. The CPython implementation is available at https://github.com/kushaldas/cpython/tree/pypackages.