Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
41–50 of 59 posts
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#42I love it, I always wished for something like that. Will try to later test with python. Wish there was also for JS/TS. As for rr debugger did it got by now any support for MacOS or Windows or Android? I'm also wondering how heavy are those recording for typical apps. This would be also great for LLM to give some context via MCP server or even let LLM pick what variables history wanna see instead of giving full record…
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#43If you are using Clojure or ClojureScript check out FlowStorm: https://www.flow-storm.org/
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#44The Noir support makes sense given its use in ZK proofs where execution tracing is particularly valuable, but I'm really looking forward to the Python and Ruby implementations. Those languages' dynamic nature makes bugs particularly elusive sometimes. Has anyone here tried using this with Noir yet? I'm curious about the performance overhead of the tracing mechanism, especially for longer-running programs. Also wonder…
The planned RR recordings integration is what I'm most excited about though. Having this capability for systems languages like Rust and C++ would be transformative for complex debugging scenarios where you're often forced to restart debugging sessions from scratch after stepping past a crucial point.
It's not ready yet, and it might be proprietary: it would be great if we can open source it, if we find a sustainable business model for that
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#45Just out of curiosity, why did you use two languages to write CodeTracer and not just one of them?
Nim and some Python are used for our closed source rr backend currently, and the frontend is written in Nim (compiling to JavaScript).
The backend for blockchain and scripting language which is open sourced, is newer and we used Rust there for several reasons. One of them is related to the fact that many blockchain languages are implemented in Rust and this makes it easier to interoperate/contribute. There are other aspects as well: both languages have pros and cons.
Some pros of Nim are e.g. it's metaprogramming support; the ability to share easily code/types between backend and frontend(it's an alternative to both e.g. C++/Go and TypeScript for us).
We're thankful to both language communities!
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#46Windows support? What languages? How does it work? I don’t like that the headline is “designed to support multiple languages” but it only actually supports an obscure language I’ve never heard of. Feels like a bait and switch.
I am sorry if the headline felt misleading or the current support disappointing: we do have experimental Ruby support, that you can try right now if you record a `.rb` program.
We do design the frontend, trace format/lib and backends to support multiple languages. Ruby is already having experimental support, and we try to keep various other languages/usecases in mind. We hope to find a model that lets us work more on supporting many more scripting languages. We'd also love contributors/the community adding support for languages or codetracer itself!
We also do have a closed source backend based on RR[1] that has partial C/Rust/Nim support, but it is not yet ready. It might be released as a proprietary solution. (However if we find an alternative sustainable business model, it would be great to be able to open source it.)
The scripting/blockchain languages backend is more db-like: it collects a trace by hooking in tracing API-s or instrumenting/patching vm-s (the trace is later postprocessed before replay).
The system languages backend is based on RR[1] recordings currently.
We'd be happy to discuss more usecases or languages!
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#47Years and years ago I had the opportunity to give Intel processor designers (the time of the 386!) requests for features.
I requested a system tick timer for stamping logs (they did that), bus mask and value registers that triggered a debug interrupt on a match (they did that).
And a jump source history. Maybe 10 jumps back. So on a breakpoint you could figure out how you got there. A time travelling debug feature.
At this point Intel sold an expensive debug probe for recording the bus, you plugged this insane cable into the processor socket and it actually executed in their external hardware, recording every instruction.
My jmp history would have replaced much of that, obviating it's need for the vast majority of users.
Ah well, it didn't happen. So now we all rebuild code 'debug' so we can add tracing and tracking, disrupting the execution path, changing timing and code size and on and on.
I always regretted not getting that.
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#48Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#49Neat! Years and years ago I had the opportunity to give Intel processor designers (the time of the 386!) requests for features. I requested a system tick timer for stamping logs (they did that), bus mask and value registers that triggered a debug interrupt on a match (they did that). And a jump source history. Maybe 10 jumps back. So on a breakpoint you could figure out how you got there. A time travelling debug feat…
[1] https://stackoverflow.com/questions/14670586/what-is-the-ove...
[2] The MSRs for LBRs (MSR_LASTBRANCH_*_{TO,FROM}_IP) and BTS (IA32_DS_AREA) are described in Volume 4, Section 2.2 of the SDM: "MSRS IN THE INTEL® CORE™ 2 PROCESSOR FAMILY". Core 2 was launched in 2006.
Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust
#50Because in an HN title, the language a tool is written in or the kind of music the author listens to matters more than what the tool actually does.