What's the status of the new scheme on TeXmacs? Also, what is the status of the new release?

Submitted the issue!

1 Like

Fair enough! My understanding is the browser runs some of the code in interpreted mode and some compiled. I was thinking the same thing for TeXmacs, but as you say, that is not necessary.

Is running TeXmacs in webassembly something people are working on?

@yufens is working on the webassembly port of Mogan based on @mgubi 's work.

You can try online via https://mogan.app

To clarify, Mogan is a community driven project. It is not for profit. As a result, the wasm version of Mogan will never require a login.

I’m exploring the design space in Vau (https://github.com/mgubi/vau) which at the moment is going to be a web viewer for TeXmacs files, but which is also a test to see how to “grow” a web application which uses the core of TeXmacs typesetter. In my opinion the full TeXmacs app is not a useful web app. Desktop =/ web and a web app has other requirements and therefore needs another interface, maybe simpler and single window, with less toolbars and relying on HTML+CSS for UI. But I do think that is strategically important that we deliver some functionalities via the browsers, in an app which can be run without installation and possibly which make easy to collaborate.

Found a guile3 cygwin package, I don’t have a working Windows though.

1 Like

I don’t know much about what the different build options are for Windows. I’ve seen people mention Cygwin, MinGW, MSYS2 and MXE, but I’m not completely sure what they all do.

I see there’s also a Guile 3 packages for MSYS2:

Yet, there’s also this issue

Then there’s this discussion on MinGW on the Guile mailing list:
and this work in progress git branch:

I don’t know how all of this ties together and what would be needed for TeXmacs on Windows. Perhaps someone with more Windows expertise can chime in?

Both GNU Guile or Chez Scheme are too big for GNU TeXmacs.

We only need a very small subset of the Scheme language. And we do not need most of the standard library shipped by Chez Scheme and GNU Guile.

1 Like

I’m not suggesting anybody do this, but was it ever considered to write your own scheme interpreter for TeXmacs?

Again, using emacs-lisp as an inspiration.

@pikachuhy (who is a compiler engineer) was playing on it, see https://github.com/PikachuHy/PicoScheme

For now, I think S7 Scheme is the best solution. And I hope I can spare some time to participate in the development of S7 Scheme.

I insist that S7 is a good tradeoff for the moment :slight_smile: but I was also looking to femtolisp (https://github.com/JeffBezanson/femtolisp) which is currently used in production to run the parsing stage of the Julia language. It seems quite small and fast, but I’m not sure it is fast enough for TeXmacs.

I agree, S7 seems good enough. My initial objection was because I thought it was a dead project. Since that’s not the case, there’s no reason to look elsewhere (except for maybe that weird bug everyone seems to mention).

Some people thought GNU TeXmacs was a dead project.

It’s a reasonable assumption to make when a software is not updated for a while or if the website doesn’t work (which was the case for S7). At least TeXmacs has a relatively up to date github; hopefully there’s a new binary release soon too.

I write a new toy scheme, https://github.com/PikachuHy/pscm

One of its goals is to build a windows native texmacs, which means we can build texmacs with MSVC.

I don’t know how long it will take.

The first step, I think, is to build Vau (https://github.com/mgubi/vau) with my pscm.

Currently, the wasm version is available: https://pscm.dev/demo.html

Nice project! Please be aware that it is a nontrivial task. I’ve tried to embed other schemes and they are too slow to be usable. For example Chibi. For TeXmacs it is critical to have a fast parser and interpreter and also symbol lookup (because the sources define tons of symbols which have to be resolved during calls). I fear that a naive implementation would be not viable. S7 has a lot of optimisations and even Guile 2 interpreter (written in Scheme and compiled) is too slow for running TeXmacs. One had to wait for the Guile 3 interpreter to match the speed of Guile 1.8.

I looked at femtolisp which is quite fast (even in the benchmarks). If however you insist in want to develop you own scheme then I would like to suggest you try to allow it to work with TeXmacs’ strings so that we do not have to convert them back and forth. Joris was also of the opinion that we need our own interpreter.

I looked at femtolisp which is quite fast (even in the benchmarks).

where is the benchmarks code?

try to allow it to work with TeXmacs’ strings so that we do not have to convert them back and forth.

good idea

we can do more TeXmacs-specific optimization.

Here: https://ecraven.github.io/r7rs-benchmarks/

If I’m not mistaken, S7 was specifically written to work well with another software. So going that way for TeXmacs is not a bad idea.

I’m not sure what you mean. S7 has no specific problem to be embedded in TeXmacs. I do not know if it has been “designed” to work with another software. I do not see any specific design decision which make it bad for TeXmacs. If we can have a performant interpreter which uses TeXmacs internal data-structures that would remove a lot of overhead between C++ and Scheme, but write a good interpreter does not seems an easy task (otherwise there will be more fast interpreters around…). Anyway, kudos to @pikachuhy for initiating the project. Let me know if you need help with Vau integration. (btw: Vau does not currently use a lot of Scheme since all the UI part has been disabled, so it is not a good test for a new interpreter). Porting TeXmacs to a new scheme is very easy on the C++ side, it would take some more work to have all the Scheme primitives which are needed to run our Scheme code.

According to their website, S7 was designed as an extension language to their sound editor software.

I’m not saying S7 is unsuitable for other tasks. Just saying that they wrote it to use in their software because no other scheme suited their purposes.