vchuravy

Arrested is not the same as convicted. I lived in Japan for a few years, and I have heard of similar situations to what the article describes.

In Japan you can be arrested while an investigation is in process, only afterwards you will be indicted. Additionally, Japan does not permit defendants to post bail prior to an indictment.

Yes Japan has a really high conviction rate, but that is because they indict only cases were a conviction is likely.

Arrests don't need to lead to the person being indicted.

My point is if you set JULIA_CPU_TARGET during the docker build process, you will get relocatable binaries that are multi-versioned and will work on other micro-architecture? It's not just for PackageCompiler, but also for Julia's native code cache.

Very cool. Does the dynamic instrumentation handle JIT emitted code?

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.

Ah but what defines madness? For me it's innocuous functions that have surprising/wild behavior due to type inference disagreeing with me.

Most of the time I am the one wrong.

One of the authors here, happy to answer questions.

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

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.