I have some experience with Ubuntu, not enough with Debian. In Ubuntu, I tried installing the package from https://www.texmacs.org/tmweb/download/linux-packages.en.html#ubuntu and the package manager told me that it wanted to uninstall guile-2.2 (I forgot the details).
I found on StackExchange this answer that to me looks believable: https://superuser.com/a/877729
TeXmacs on Debian 11 (Bullseye)
This experience seems outdated. I downloaded the latest deb file and found no dependency about guile. I think that Guile is embedded in the current TeXmacs packages, cf. https://github.com/texmacs/texmacs/commit/eee5a00c65dcf870f0ca65082333f41f7a4ec470
How about try this branch:
Guile 3 Integration for GNU TeXmacs 2.1 by darcy-shen · Pull Request #54 · texmacs/texmacs (github.com)
I’m using GNU TeXmacs (built with Guile 3) on Debian sid. It works fine.
You are right, and thanks for letting me know. I installed TeXmacs 2.1 on Xubuntu 20.10 using the package and it worked.
I realized that I do not recall whether I used the package or the Ubuntu repository ( http://www.texmacs.org/tmweb/download/linux-repos.en.html#ubuntu ). Perhaps it was the repository, but I am not going to test it now.
Please give me some time, I will let you know.
It is the same for the repo (in fact, since I myself use the repo, and after looking at the result of apt-cache depends texmacs, I find that guile-1.8 or something similar is no longer there).
Unfortunately, it seems that this has not been resolved yet.
This seems to be solved in the repo: https://ftp.texmacs.org/TeXmacs/tmftp/repos/apt/pool/universe/t/texmacs/
but the webpage is not updated:
https://texmacs.org/tmweb/download/linux-packages.en.html#debian
Could any maintainer of the website intervene? @jeroen @mgubi @darcy
1 Like
I don’t think any of us have access to the main website (at least I don’t). It would be helpful if you could raise this on the users mailing list.
Yes, the main website is maintained directly by Joris. It is better to write (even a short message) on the mailing list (texmacs-dev or texmacs-users) to make him aware of this. Thanks!
I don’t have quantitative measurements, but it seems to me that this AppImage version runs slower than the native version in Debian Buster (although it seems faster than generic Linux builds).
Curious. Is it known that AppImages have performance problem? (maybe the linking process at startup is different?). It would be nice to have some benchmark for TeXmacs so that we could also evaluate regressions during development.
Seemingly this is not only about AppImages, but the builds from https://download.opensuse.org/repositories/home:/slowphil:/texmacs-devel/
Official builds do not seem to suffer from the same issue. Mogan neither: Beamer is very laggy
It’s not widely known that the official TeXmacs packages for Linux distros are built at OpenSuze Open Build Service just like mine, using the same build scripts 
.
Regarding AppImages, I already commented elsewhere on this forum that they are just standard builds (i.e. using dynamically linked libraries, some of them from the system and some bundled in the AppImage). After a one-off decompression step at startup, AppImages perform exactly as any other TeXmacs build for Linux, and my experience using them confirms that.
The bottom line is that I’d be extremely surprised if anyone would come up with actual measurements showing that, for a given version, my builds are slower than official ones.
The main differences of my builds are:
- They presently incorporate all what has been committed to the trunk since v. 2.1.2 was released (providing new features, bug fixes but also possible regressions, if any)
- I add a patch that brings new features, but the areas it touches cannot change performance of the core TeXmacs (anyone can check the patch content).
- OBS provides repos for one’s favorite distro which enable automatically installing guile 1.8 (not conflicting with more recent guile version) as a dependency when installing TeXmacs. Updates are proposed whenever I make a new build.
- I provide AppImages that allow running TeXmacs on all Linux distros without installing anything on the system (hence including when the user has no admin rights), and not worrying about guile either.
A tiny point: AppImage decompress root path of TeXmacs into /tmp, which is in-memory tmpfs on my machine (ArchLinux with linux 6.2.2.arch1-1).
It may differ between different distros though. From my limited experience, AppImage version doesn’t show significantly sluggish compared to natively built version (I built the lastest trunk from aur/texmacs-svn). Actually AppImage starts faster.
I am aware that the official build is out of OBS. I remember that I saw the official OBS, but I do not have it at hand.
One difference that I remember is that, the official OBS build does not produce correct debug symbols (the dbgsym files are essentially empty).
Do you have a build for 2.1.1? The official build does not have 2.1.2 for Debian Bullseye. I also wonder how to benchmark, say, for typing the math symbols. My memory is that, the sluggish happens during the math typing.
It seems to me that I was mistaken somewhere. Now I cleared cache (although I have a vague memory of starting with a fresh .TeXmacs), and it seems that the sluggish is not perceived anymore (it is not shown in std-bench either), both for Debian build in this repo, and for AppImage. I have to test more.
@sharkc, Indeed, if the AppImage gets decompressed to ram, it should perform great. In any case, using an AppImage should never be a drag unless if, opposite to you, one would have the bad idea to setup their /tmp on a slow device such as an USB flash drive or a 40-year-old floppy disk!
the sluggish is not perceived anymore
Ah, glad you could clear that problem. The bug tracker documents some circumstances under which TeXmacs becomes unbearably sluggish, but not specifically for math typing. If the slow math input comes back, please try to figure what actions trigger it (so that developers can reproduce it for debugging) and report it there.
@pjoyez Now Debian 12 is released and it is no longer “Debian Testing”. It seems also better to always use the versioning number instead of “Testing” so that there is no need to change the name any longer?
1 Like