IRC channel 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 libR.so

<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: https://github.com/REditorSupport/vscode-R#features

<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: https://elephly.net/paste/1688733666.html

<rekado>ImportError: /gnu/store/qkvddl6cnfvqn1zx7grlgpk7s9aay8is-gcc-10.4.0-lib/lib/libstdc++.so.6: 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/libtorch_python.so)

<rekado>what’s up with that?

<PurpleSym>Is it a binary package?

<rekado>no

<rekado>CUDA is, obviously

<PurpleSym>libtorch_python.so 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.

IRC channel logs

2023-07-07.log