On iq.org he lists j u l i e n @ post.harvard.edu as one of his email addresses but people from Harvard, if Quora answers are to be believed, cannot confirm he ever was at Harvard in any capacity. Maybe a joke or smoke and mirrors?
The problem seems to be post-commit code review or something like that. I don't know if they did, but I hope they used git-notes which has been in git core for a while now.
If this has been using core git's notes[1] feature, then there's nothing to export from the site. But as export is mentioned in the announcement, it seems unlikely.
If you're using Emacs and org-mode, look into org-babel which supports R among many other inline languages (C, Haskell, sh, SQL, ....) you can use as if you were in iPython.
> Our operating system detects even the tiniest corruption to files and will automatically restore them from our service. The system is completely self-healing.
There's a JIT branch in the official upstream emacs repository. Just checkout nick.lloyd-bytecode-jit after cloning emacs from git and run `./configure --with-jit` once you have libjit (originally a part of GNU dotNET) to give it a try. libjit doesn't install a .pc file so you'll have to explicitly set the LIBJIT lib and C ./configure flags if you install libjit from source.
I feel like we're talking past each other :). Building rustup with and for musl isn't the problem. Needing glibc for the binaries downloaded by rustup is. So this is more about toolchain and target binaries for linux being libc-agnostic which is easiest to achieve by musl-static-linking them which requires upstream support. As a first step a second set of musl-dynlink, parallel to glibc-dynlink, binaries would suffice.
Speaking of Debian, one has to be careful in how stuff is built for the result to run on Debian, Fedora, Arch, Suse, which is another reason to simplify things with musl since it already bundles third party C code anyway. So far rustup doesn't suffer from that, but if it ever were to dynlink ncurses or another core Linux lib, it would have the same issue as GHC's bindists. It doesn't and that's great!
For bootstrapping it in and for a distro that's the right thing, but if we want to have access to the rustup toolchains and targets, then those require musl-hosting support upstream in order for rustup binaries to be made available which, like on Windows or FreeBSD, are downloaded and used by rustup.
Building rust right now takes enough time that it's hard to recommend a hypothetical from-source mode for rustup that works similar to OCaml's `opam switch compiler-vsn`. If building rustc becomes similarly fast, this can be a good alternative. And in that case having a rustc version in the distro is very useful, as long as it's not older than two releases.
> Well, hosted is trickier due to compiler plugins, but yes.
This has been discussed multiple times in tickets and it's pending. Hopefully soon :).
> please submit bugs upstream or comment on any open issues
Of course but there's nothing I can add to already existing and open issues that hasn't already been discussed. There's a need for rustc dev focus on this just like msvc support in the past.
> Once you get rustc, rustup should be fine.
What do you mean? Being able to build rustup doesn't give you access to rustup toolchains/targets that run on Alpine, if that's what you mean. Or?
Sadly it's outdated, only a single version, and missing all the other important rustup features. Ultimately rustup's Linux binaries would benefit from either optionally or exclusively being available in a version that's linked dynamically - or more practically - statically against musl. These would work in default docker images, Ubuntu, Red Hat, Alpine, Void Linux, anywhere that has Linux 2.6 ABI. Stack has started doing this for their GHC builds. Of course, a prerequisite is upstream support for hosting rust in a musl (no glibc) environment. Since Rust has a musl target for static compilation, it's natural to be hosted as well.
Alpine Linux is great and I wish they would do more to upstream their build fixes so that stuff works out of the box with musl. I also wish Rust and then rustup will work out of the box on Alpine soon, as this will make it very easy to use generally and in docker images for ci specifically. No complaints, just a small wish list for a distro that's already very useful. Huge thanks to all alpine devs!
> As an aside I always kind of wondered why all browsers started including developer tools by default as they are not of use to 99.9% of users.
I wish this wasn't the case, but I use built-in devtools inspector to work around bad websites that impose invisible ad overlays which are somehow not caught by the combo of uMatrix+uBlockOrigin. I have to use the Inspector to select and delete the overlay so that I can use such sites. Thus DevTools serve a purpose to non-development browser sessions.