lldb-mi
venom
lldb-mi | venom | |
---|---|---|
11 | 6 | |
150 | 976 | |
1.3% | 1.6% | |
4.6 | 7.3 | |
2 months ago | 7 days ago | |
C++ | Go | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lldb-mi
-
My Personal Serverless Rust Developer Experience. It’s Better Than You Think
I'm on the record of loving the VSCode experience with Rust. And I do think that it's amazing that a "non-IDE" can feel so much like an IDE. However, I've recently pivoted off of that stance. I know it's still in EAP, but Rust Rover gives me all of the things that I get from VSCode plus an easier integration with LLDB.
-
Taming the dragon: using llnode to debug your Node.js application
Fortunately, we can use this same technique with our Node.js applications! This is possible through llnode: a LLDB plugin which enables us to inspect Node.js core dumps. With llnode, we can inspect objects in the memory and look at the complete backtrace of the program, including native (C++) frames and JavaScript frames. It can be used on a running Node.js application or through a core dump.
-
How to debug programs in console? (C program for example)
An alternative to gdb is lldb. But I like gdb.
-
How to Debug WASI Pipelines with ITK-Wasm
The CMake-based, itk-wasm build system tooling enables the same C++ build system configuration and code to be reused when building a native system binary or a WebAssembly binary. As a result, native binary debugging tools, such as GDB, LLDB, or the Visual Studio debugger can be utilized.
-
What is the debug drawer?
The debugger component of the LLVM project. It’s what you’re typing into when you type po someExpression. https://lldb.llvm.org/ Web searches could help explain a lot of this for you 😊
-
Best debugger for windows? GDB is not stable and can't seem to find an alternative.
If you really don't want to touch Visual Studio/MSVC then you can try to compile with clang and use lldb: https://lldb.llvm.org/
-
dap: configuration to automatically launch codelldb server
LLDB - https://lldb.llvm.org/ - Debugger from the LLVM project
-
Debugging with GDB
Well, there's LLDB (https://lldb.llvm.org/) - I've heard it's got some nifty architectural features (e.g. having access to the Clang framework for handling C/C++ expressions).
I've done some minimal poking about in the code; I found its object-orientation a bit hard to grok (just for me personally) but it seemed to be quite uniformly applied so it might well be easier to work with.
-
Write your GDB scripts in Haskell
The article does mention lldb as a future target.
-
Kdevelop: Debug, "Could not run 'lldb-mi'
check if lldb-mi comes with lldb in your package manager. if not build it form here: https://github.com/lldb-tools/lldb-mi.
venom
-
Ask HN: What's your favorite software testing framework and why?
You can also load fixtures in database directly, work with Kafka queues both as a producer (e.g. write an event to a Kafka queue, wait a few seconds and see that it was consumed by the service you test, and that some side effects can be observed) or as a consumer (e.g. make sure after an HTTP call, an event was correctly pushed to a queue), or even read a mailbox in IMAP to check that your service correctly send an email.
It's a bit rough on the edges sometimes, but I'd never go back on writing integration tests directly in my programming language. Declarative is the way to go.
[1]: https://github.com/ovh/venom
-
Easy Integration Testing with Venom!
To write and run our integration tests, we'll use Venom. Venom is a tool created and made open-source by OVHcloud: https://github.com/ovh/venom
- Venom: Manage and run your integration tests with efficiency
-
Show HN: Step CI – API Testing and Monitoring Made Simple
From my experience, generated tests are worthless for anything more serious than smoke tests. I prefer working with no tests than automated tests, I feel they give you a false sense of confidence.
The Step CI engine itself looks good though. It looks like a cleaner, but less powerful version of a tool (open source, build in-house) we used when I worked at OVHcloud, Venom: https://github.com/ovh/venom
Here's an example test file for the HTTP executor of Venom: https://github.com/ovh/venom/blob/master/tests/http.yml it's very close to Step CI format.
I'd still use Venom because it's way more powerful (you have DB executors for example, so after executing a POST request you can actually check in DB that you have what you expect) and I prefer focusing on actually writing integration tests instead of generating them.
Maybe this post sounds harsh (I feel it as I write it because I have strong feelings against test generation) but I think your approach is a good one for actually writing automated tests. Testing APIs declaratively like this has a great benefit: your tests work on an interface. You can migrate your API to a whole new stack and your tests remain the same. I did it multiple time at OVHcloud: one time migrating a huge API from a Go router to another (Gin->Echo), and another time migrating public APIs from a legacy, in-house Perl engine to a Go server.
-
Debugging with GDB
I still struggle with GDB but my excuse is that I seldom use it.
When I was studying reverse engineering though, I came across a really cool kit (which I've yet to find an alternative for lldb, which would be nice given: rust)
I'd recommend checking it out, if for no other reason than it makes a lot of things really obvious (like watching what value lives in which register).
https://github.com/hugsy/gef
LLDB's closest alternative to this is called Venom, but it's not the same at all. https://github.com/ovh/venom
-
Do you write integration tests in go?
We incorporated [Venom](https://github.com/ovh/venom) into our workflow. It's great for initiating and managing a suite of yaml based tests. It didn't work out of the box for us due to the heavily asynchronous nature of our system, but after a few additions, it has helped my team greatly. We were often afraid to make large changes to critical pieces of the system since a full regression test could take a week or so to check everything. Now it takes an hour.
What are some alternatives?
gef - GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
godog - Cucumber for golang
gdb-dashboard - Modular visual interface for GDB in Python
dockertest - Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal work.
vscode-lldb - A native debugger extension for VSCode based on LLDB [Moved to: https://github.com/vadimcn/codelldb]
testcontainers-go - Testcontainers for Go is a Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers that should be run as part of a test and clean up those resources when the test is done.
CodeLLDB - A native debugger extension for VSCode based on LLDB
stepci - Automated API Testing and Quality Assurance
rr - Record and Replay Framework
gotestfmt - go test output for humans
voltron - A hacky debugger UI for hackers
gotestfmt - go test output for humans