texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] TeXmacs with S7 Scheme


From: Massimiliano Gubinelli
Subject: Re: [Texmacs-dev] TeXmacs with S7 Scheme
Date: Wed, 30 Dec 2020 10:38:08 +0100

Dear Giovanni,

> On 30. Dec 2020, at 01:35, Giovanni Piredda <pireddag@posteo.de> wrote:
> 
> 
> Am 30.12.2020 um 00:58 schrieb Massimiliano Gubinelli:
>> Dear all,
>>  I've spent the last few days in integrating S7 Scheme
>> 
>> https://ccrma.stanford.edu/software/snd/snd/s7.html
>> 
>> with TeXmacs to replace Guile. S7 is a very small scheme interpreter and I 
>> wanted to see how difficult was to port TeXmacs to it and whether 
>> performance is acceptable. The good thing is that porting is not very 
>> difficult and now that I understand the process better, I think will be also 
>> possible to port TeXmacs to other scheme interpreters if needed. 
>> Unfortunately performance seems to be worser than Guile 1.8 so at the moment 
>> does not seems a viable option.
> 
> I have a suspicion here---that having many different possible implementations 
> of Scheme may be dangerous: packages written for one implementation may not 
> work with another one, and this might hinder the development of 
> user-contributed packages, and I think user contributions would help the 
> development and diffusion of TeXmacs.
> 
> But perhaps it is sufficient that there is one "official" TeXmacs version 
> (with Guile :-) ) and then the presence of alternatives would not hinder 
> developments on the official version.
> 


>> I'm also maintaining a port to Guile 2/3 which seems to work fine.
>> 
> I am eagerly waiting for it to become the main TeXmacs version.
> 
> 

I'm not doing this for the sake of having various implementations. From the 
point of view of the user there is not much difference. However there are some 
issues inherent with the use of Guile which I was considering and trying to 
find alternatives for.

The current situation is the following:

1) Guile 1.8 is not supported in major Linux distributions. This makes more 
difficult than it should be for us to keep up to date packages. 

2) Guile 2 is supported in all the major linux distributions, however I'm not 
sure what happens on Windows. Moreover the performance of Guile 2 for our 
use-case seems not great, i.e. not better than Guile 1.8. Lilipond, a program 
which uses Guile much as we do, seems to be still on Guile 1.8 for this reason. 
I've checked how they do to support Windows and they cross-compile from a Linux 
machine. 

3) Guile 3 is not yet in all the major Linux distributions, as far as I 
understand. 

4) As far as I see Guile developers do not care too much about Windows. It is 
usually not easy to compile Guile on Windows and currently Guile 3 seems not 
supported there, also I do not know what will happen to the passage to the ARM 
architecture on Mac (Guile3 has a machine code compiler so it depends on the 
underlying architecture).

5) Guile 3 is faster than Guile 2 and interpreted code run as far as Guile 1.8 
(but to faster). However Guile 2/3 can also compile code to a bytecode 
interpreter and Guile 3 has a JIT compiler which produce machine code, so we 
could hope that it make TeXmacs faster and that we can write more parts in 
scheme instead of C++.

From my point of view is unclear what is the best decision for the long term 
future of TeXmacs. Currently I see two reliable alternatives:

1) We stick to Guile 1.8. We can just integrate it in our codebase (as we do 
with PDFWriter) and strip away all the parts we do not need, so that it is 
easier to maintain and compile in Windows and packageable in Linux. 

2) Follow Guile developers into Guile 3+ and maintain compatibility with Guile 
1.8 as a fallback. On Linux we link against Guile 2/3 and on the other 
platforms we use the best alternative we have.

Best
Max



> _______________________________________________
> Texmacs-dev mailing list
> Texmacs-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/texmacs-dev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]