We use RR a lot with Julia. It only gives you a GDB view of the system, but it can work with any interpreted or compiled language.
Things that don't work are drivers that update mapped addresses directly. An example of this is CUDA in order to replay one would need to model the driver interactions (and that's even before you get to UVM)
Another great thing is that RR records the process tree and so you can easily look at different processes spawned by your executable.
Shameless plug: https://undo.io does everything rr can but can also work with drivers that update the process memory (or unrecorded processes or even hardware). If you need that kind of advanced usage, check it out.
(Unlike rr it's not open source though - sorry! We have lots of programmes working on it full time and they insist on getting paid every month :)
Changing the `function foo()` in the "Usage: descend" section to `function madness()` sounds like a pretty good/funny idea.
@descend madness()
would be a pretty good reference to the original text!
Positive: it would also let people know at a glance that things like `rand() > 0.5 ? Int64 : Float64` are indeed madness.
Potential negative: some people may not consider it super DEI-friendly? As a neurodivergent person, I'd just find it to be just a lovely reference though.
> And dealing with bugs in LLVM is basically a no-go, I've seen this happen in the Julia ecosystem as well.
As one of the folks dealing with LLVM bugs in the Julia ecosystem.
Yes it requires a distinct skillet different from working on the higher-level Julia compiler and yes it can sometimes take ages to merge bugfixes upstream, but we actually have a rather good and productive relationship with upstream and the project would get a lot less done if we decided to get rid of LLVM.
In particular GPU support and HPC support (hello PPC) depends on it.
But this is also why we maintain the stance that people need to build Julia against our patchset/fork and will not invest time in bugs filled against Julia builds that didn't use those patches. This happens in particular with distro builds.
Yeah I often describe Julia as a Lisp in sheep's clothing.
Or as the m-Lisp promised to us :)
I chuckled when I read:
> The way that common Lisp systems produce executable binaries to be used as application deliverables is by literally dumping the contents of memory into a file with a little header to start things back up again.
Which is pretty much of Julia's sys-/pkgimages work. Pkgimages are an incremental variation on this idea.
One of the novelties in Julia is the world-age system and the limits on dynamisim it introduces on eval.
Yes that is precisely what was fixed, essentially the thread local storage that Julia was expecting were not setup and thus calling the runtime from a foreign thread would cause a crash.
This now enables to dynamically add and remove threads.
How closely tied is this to Python?
The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.
For this project, Python is a hard requirement, though it's possible the approach may be applied (after significant effort -- Python took me ~3 years and counting) to other languages / runtimes as well.
How closely tied is this to Python?
The need for reactivity is what drove the development for Pluto.jl, but it would be nice to have something like this for IJulia.jl as well.
Due to some wonderful C++ features the dynamic linker is forced to unify symbols across shared libraries, even if those symbols have different versions.
This utterly breaks loading multiple libLLVM's except if you build the copy you care about with -no-gnu-unique (or whatever the flag was called)
I have seen wonderful things like the initializers of an already loaded libLLVM being rerun when a new one is loaded.
