Sorry if my question is a bit vague. I know there are quite a few people here running SC on Arch Linux (or Manjaro). So, rather than expecting a clear answer to my question I’d like to know if someone has made the same or similar experience as me.
I’ve installed SC 3.13 via pacman on a ThinkPad T470s with 24GB of memory with the latest Arch version, using a Plasma 5.27.6 desktop (Wayland) and 6.1.38.12.realtime1-2-rt-lts kernel. Starting up SC works just fine and sound is also playing as expected.
However, I’m using some GUI classes, that usually allow me to load and save setups from and to Archive files which doesn’t cause any troubles as long as I do it from code. Only when I try to save from GUI by clicking some buttons that call the same code that I can execute from the IDE without problems sclang easily freezes. I.e. it doesn’t always happen but pretty often, too often to be acceptable.
I’ve used the same classes for years on UbuntuStudio and Debian but I’ve never experienced these problems under these distributions.
I’ve already built SC myself as a debug build and attached a GDB debugger, respectively let strace examine the sclang output when clicking the buttons in my GUI but no luck so far. I can’t make head nor tail of the debug output. All I can say is that clicking buttons in my GUIs often crash sclang but not always. I’ve tried to write a simple reproducer but so far I haven’t been able to reproduce the behaviour.
Has anyone made the same or similar experiences in SC on Arch?
Although I’m making GUIs from time to time I haven’t seen any hangups, except when opening the FileDialog in kde (logged in FileDialog hangup in KDE · Issue #3807 · supercollider/supercollider · GitHub but to my frustration it eventually was closed without any (accepted) solution). So I had no choice but to stop using FileDialog - maybe in the meantime the problem no longer happens, but I couldn’t tell.
Yes! I’ve seen exactly the same when I did my debug build (and, frankly, I returned back to the pacman installation because of that). Let me guess - you set up Arch with separate root and home partitions, did you? As far as I could see that’s where the error comes from. The OS then does not allow to e.g. copy files from /home/your_user/.local/share/SuperCollider/Help/ to /usr/share/SuperCollider/HelpSource/ which leads to incompletely rendered helpfiles. How did you fix this in your build?
Right! I’m not using FileDialog but Dialog and it almost every time happens when trying to open the dialog by clicking a dedicated button in my GUI. I’ve tried to write a reproducer but that almost always works:
a = {20.0.rand}!100000
a.size
l = Library();
l.put(\a, ())
l[\a].put(\arr, a)
f = { |f| l.writeTextArchive(f) }
// open dialog directly
Dialog.savePanel(f, "~".standardizePath)
// open dialog by clicking a button
b = Button(bounds: 100@40).states_([["SAVE"]]).action_({ |b| Dialog.savePanel(f, "~/Desktop".standardizePath) }).front
… so, even if it doesn’t help much it’s good to have my observations confirmed (somehow).
Btw.: defering the call to Dialog.savePanel, respectively Dialog.openPanel (which is how I’m using Dialog) as you mentioned in your bug report seems to solve my problem with using Dialog - thanks for that hint!
The problem is not related to the OS, but caused by a bug in the boost filesystem version currently used in supercollider. It’s fixed by building with a newer boost version. Supercollider as distributed by arch (pacman) is already built with a later boost version by default, so it doesn’t have the problem.
Towards the end of the bug report thread on github at least there’s a manual workaround for the problem which should get you a working help system even with the old boost version. Three steps are needed:
//1. start scide -> get the error
//2. in bash:
# delete the faulty folder just created by scide
rm -rf ~/.local/share/SuperCollider/Help
# manually recreate
cp -rL /usr/share/SuperCollider/HelpSource ~/.local/share/SuperCollider/Help
// 3. in scide
reboot the interpreter
(OOPS, I had totally forgotten about finding a workaround for the FileDialog… glad it works for you too!)