Live data from Hacker News

Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

github.com

41–50 of 59 posts

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#42
post #7

I 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…

I just released a JS/TS/Python time travel debugger that overlays variable values on top of vscode. It's just a npm or pip install and VsCode extension so it might be easier to use for you: https://github.com/dedale-dev/ariana I'm also planning to add MCP integration today actually!

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#44
post #19
post #17

The 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.

the support for system languages (the rr integration "backend") is currently closed source.

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

#45

Just out of curiosity, why did you use two languages to write CodeTracer and not just one of them?

Nim is the original language we use. Zahary is a prolific contributor to Nim, and we have a good relationship with the Nim community, they've helped a lot!

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

#46

Windows 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.

We're working on Windows support for the scripting and blockchain languages.

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!

1: https://rr-project.org/

Re: Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

#47
Neat!

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 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

#49

Neat! 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…

Intel x86 cores have had Last Branch Records (LBRs) and Branch Trace Store (BTS) since at least Merom in 2006 [1][2]. Nowadays, there's Processor Trace (PT) or Precise Event-Based Sampling (PEBS) which can provide even more information. PT in particular is almost purpose-built to enable this kind of trace reconstruction.

[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

#50

Because 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.

You can appreciate it for building up good, under-supported languages like nim, zig, and D.
Post reply on HN