alehander42
Joined 11 years ago
Karma
580
Submissions
190
Member since
Jun 5
I like language development.
Some of my stuff: https://github.com/alehander92
View on Hacker NewsRecent submissions
Comment · 1 year ago
you're right: in the RR case: currently this is not merged yet, but a RR contributor works on persistent checkpoints; they can act as snapshots
Comment · 1 year ago
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 `<somepath>.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!
Comment · 1 year ago
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!
Comment · 1 year ago
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
Comment · 1 year ago
Very impressive! Lisp people are always good at tooling.
Comment · 1 year ago
True!
The next major version of the format should use a more optimized format, as mentioned.
However, some of the important optimizations, that we're preparing are not related so much to the format, but to record more specific things and reconstruct more in the postprocessing.
Comment · 1 year ago
We'd love additional contributors! We also have some more detailed plans for such an extension. If you're interested in chatting about it, you can join our discord[1] (or we can expand here/in a github issue as well)
Comment · 1 year ago
We are currently working on two "backends" where recording works in different ways.
For the scripting languages and smart contract/ZK languages, we instrument the interpreters using high level hooking API-s or direct patches, and we produce a trace.
For system languages, we directly build on top of RR[1] recordings for now: RR can record multiple processes, and it works in userland. IIRC it doesn't support modifications of shared memory outside of the recording. It's very well documented in their paper: Engineering Record And Replay For Deployability: Extended Technical Report[2].
Comment · 1 year ago
A contributor to the D language helped us for many aspects of the project. He would really like to see D support haha!
Comment · 1 year ago
We are building our future support for the system languages for now directly on top of RR recordings: credit to Robert(roca) and Kyle and all other contributors for RR and Pernosco, they're amazing technologies.
We've researched possible alternative approaches/tools as well, especially keeping in mind Windows/Mac support.
The traces for Noir and the scripting languages work in a completely different way, capturing all the relevant data which is later indexed into a db-like structure. With some future optimizations this can be very useful for various shorter programs in scripting languages, and generally for blockchain languages(as the running time there is usually low) and we hope that eventually with flexible record filtering it can be practical even for capturing important segments/aspects of long-running real world projects.
Comment · 1 year ago
We are also planning to develop a distributed tracing platform, similar to Jaeger and OpenTelemetry, that continuously records the execution of many distributed processes (e.g. micro-services).
Unlike the existing platforms, which capture only message flows and require you to make educated guesses when some anomaly is observed, our system will let you accurately replay the processing code for each message to quickly identify the root cause for the anomaly.
This would rely on our ability to jump to the specific moment in time when a certain incoming message starts being processed. This moment can be identified either by a log line with a specific format or by a call to some special tracking function (e.g. track_incoming_message(request_id)).
For the system languages, the RR[1] recordings try to be practical by capturing only the non-deterministic events in the program execution. You can pair this with a ring buffer that discards the data after a certain retention period.
For the scripting languages(or any implementation using the db-like traces) we might add some advanced record filtering options.
(But maybe we are misunderstanding the question?)
Comment · 1 year ago
Thank you!
The Python initial prototype is not yet finished. It's easy to play with, so anyone interested can actually work on it! Currently, in the experimental tracers, Ruby is usable for smaller programs, so one can try Ruby immediately.
I do plan on improving some of the prototypes, and on adding additional ones: for Lua, but JavaScript: e.g. v8 is also a good target. Scripting language users that find it useful, are welcome to discuss/chat with us, or even directly contribute or propose support for new languages.
A form of record filtering is planned indeed.
We have experimented with automatic chart visualizations of some things, we've planned custom visual representation as well, great to see interest in those
Comment · 3 years ago
Most Bulgarians are actually proud of their country, often sharing that the Cyrillic originated there, and focusing proudly on the old history and all kinds of inventors/achievements, even on stuff like the uniqueness of our yoghurt: so I have the opposite impression, as a Bulgarian
Comment · 4 years ago
Well, we can't and we shouldn't find agreement if our base beliefs are different. I only also disagree with any vitriol against the professor.
I have my doubts: even the comment you were critiquing, it seems to me that you read it with bad faith, assuming ill intentions which leads me unconvinced that you could argue objectively from the Biblical viewpoint in other cases.
I had my share of non-christian worldview for many years, so there is sadly not much surprising about your arguments except for the stubbornness in applying interpretations on Scripture that no normal christian through the ages or even scholar probably held.
I know we all go through different periods in our lifes, so I hope you find Christ again. He loves all of His lost sheep. See you.