IRC channel logs


back to list of logs

<PurpleSym>Hm, that means vite must be injecting Panmirror differently that I am doing with esbuild.
<rekado>I’ve got 2023.06.0 Build 421 on one of our servers
<rekado>I see different variables in the top namespace
<rekado>there is no Panmirror in the top namespace, for example
<rekado>maybe this will change after loading an rmd file
<rekado>(it installs a bunch of dependencies first)
<rekado>for years I’ve had the strong urge to write RStupido, a simple alternative to RStudio, built around reproducible sessions
<rekado>talk to R like ESS does, not via
<rekado>the urge intensifies whenever I debug RStudio things…
<rekado>in our RStudio we have a whole lot of Panmirror* variables in the iframe’s namespace.
<rekado>e.g. Panmirror$lambda$0$Type
<rekado>we don’t have that in the official RStudio docker thing.
<rekado>(all that is after opening the editor, switching to rmarkdown mode, and then enabling Visual mode)
<rekado>the Panmirror object itself looks virtually the same (modulo naming differences due to minification)
<rekado>it doesn’t look like it’s a problem with the injection to me
<rekado>but it’s quite odd that we’ve got this weird spillage of variables in our version.
<PurpleSym>And VSCode – I hear it’s quite good – doesn’t have good R support?
<PurpleSym>This looks pretty comprehensive:
<rekado>oh, I forgot about vscode…
<rekado>yes, it’s pretty good
<PurpleSym>We’d just have to package it…
<rekado>RStudio Server still has value, though, because of its server mode
<rekado>hosting R and exposing the IDE through a web browser
<PurpleSym>I heard VSCode can do the same and attach to a compute session on a remote server.
<rekado>yes, like ESS. But can you just visit a URL and have an RSession? Or do you need to have a local copy of VSCode?
<PurpleSym>It also fully runs in the browser.
<rekado>oh, I see.
<rekado>guix-science-nonfree’s python-pytorch-with-cuda11 fails its sanity check phase
<rekado>here’s the output:
<rekado>ImportError: /gnu/store/qkvddl6cnfvqn1zx7grlgpk7s9aay8is-gcc-10.4.0-lib/lib/ version `GLIBCXX_3.4.29' not found (required by /gnu/store/nbdldccc1zy7k881z1c60hjpsnmkqzah-python-pytorch-with-cuda11-1.13.1/lib/python3.10/site-packages/torch/lib/
<rekado>what’s up with that?
<PurpleSym>Is it a binary package?
<rekado>CUDA is, obviously
<PurpleSym> links against it and CUDA expects a different gcc/glibc version?
<rekado>oh, did we switch to gcc 11…? We’re using 10 for cuda 11.7
<PurpleSym>A while ago, I think.
<SomeoneUTC3[m]><rekado> "oh, did we switch to gcc 11..." <- We've been suffering from the same issue in nixpkgs btw. What we do now is we use an nvcc-compatible gcc (e.g. gcc11), but we always link the latest libstdc++ (e.g. from gcc12) regardless, just so it works with other nixpkgs shared libraries.