From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Massimiliano Gubinelli Newsgroups: gmane.lisp.guile.user Subject: Re: rfc: next guile 1.8.x release Date: Sun, 31 Jan 2021 18:35:58 +0100 Message-ID: References: <87ft38jw4h.fsf@gnuvola.org> <874kizh1er.fsf@gnu.org> <878s8b71d6.fsf@web.de> <871re2ip29.fsf@elephly.net> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2611"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user@gnu.org, =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Ricardo Wurmus Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Jan 31 18:36:22 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l6Ge3-0000QT-Po for guile-user@m.gmane-mx.org; Sun, 31 Jan 2021 18:36:19 +0100 Original-Received: from localhost ([::1]:40054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6Ge2-0008ET-Kc for guile-user@m.gmane-mx.org; Sun, 31 Jan 2021 12:36:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6Gdp-0008CC-Nb for guile-user@gnu.org; Sun, 31 Jan 2021 12:36:05 -0500 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:37386) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l6Gdn-0003Dw-3F; Sun, 31 Jan 2021 12:36:05 -0500 Original-Received: by mail-wr1-x430.google.com with SMTP id v15so14147518wrx.4; Sun, 31 Jan 2021 09:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+qe6i6C3cJ3iqcjwMYph3Fw/oNJABJxD8XDYjZ/Q5rU=; b=CpbckRQrm8SShz5ZY3NGxmXenCQd/hXzNvNdP/aCDO4oVyT5JJMPQkKyFDUOjMCFQ2 RFUma5KQfdaOaBaX+eX+SHGrhMUKoIK7mxy5n+jcy6YL8Pqk18UaEUv9C3wCUiS3EBMP t0OM4RNdefOZ98rxOOm0F1Lf+8UqgcT2YGNrYwSKuRtOvPhOi1Wl6TvPKJJMMQvI10ZF YUusFT1ylqEFbj9Ey3hjrNlt+ANH9XUXx+72n/F6RoIwosoZ7cCNtKeOwqovN1hZ6gcB gVljwnMnWbAFLyemSV3LY+Z0oFw58tzzas6Z5wbAffxWGBDaBlhgYOkfMo62hQ+VzwDI xVng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+qe6i6C3cJ3iqcjwMYph3Fw/oNJABJxD8XDYjZ/Q5rU=; b=CSuShUpj2p95+wM/ZsyqvQEQlmPe69XQySTa9n4muvwbnATyNTTytZs6rgtLU6AFXP cgCCMbuc29YQD21hsWfXnNY/WLCac6uWu5VDQ8ECozgpid6GOqtGKGMAHKguVxquftZq B2Ij8eAdRhD2/vELxDsiI2gk4yWdfB3CYhtv7gqso93NafSbFivZkoegZlspexXJdcDd J8sVUmObdpvSko2CFA20kd+VK2JjlAcaXJv34gVF/fKmPQXNoHbnkUcLiBJdR6EKsTAG kab5zIFZ3TB8MiyskqCkwco312uAgZDa/OMpocDQTa4x02v03Sd1KpovaoQnPY09XnPw 4Z8Q== X-Gm-Message-State: AOAM533ntPZWK2TgXjw2Ep9LbDwlfR4WMy34f+Yt7fhPp4b+mGacW/+X TgK1FEF/b70UqqPot0Y/kmc= X-Google-Smtp-Source: ABdhPJzotmCdek1zjdjRa9SQMKkonyt+rv72VYSK39eWpPwWtae/VlgzgmvZ7m0xK/vkYcf0v2/5KQ== X-Received: by 2002:adf:cf04:: with SMTP id o4mr14363154wrj.412.1612114560505; Sun, 31 Jan 2021 09:36:00 -0800 (PST) Original-Received: from [192.168.0.10] ([78.192.22.137]) by smtp.gmail.com with ESMTPSA id b18sm23457164wrm.57.2021.01.31.09.35.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2021 09:35:59 -0800 (PST) In-Reply-To: <871re2ip29.fsf@elephly.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=m.gubinelli@gmail.com; helo=mail-wr1-x430.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17220 Archived-At: > On 30. Jan 2021, at 13:31, Ricardo Wurmus wrote: >=20 >=20 > Dr. Arne Babenhauserheide > = writes: >=20 >> Ludovic Court=C3=A8s writes: >>=20 >>> Thien-Thi Nguyen skribis: >>>> I would like to work (on the weekends, so as not to intefere w/ >>>> ) on preparation and release of Guile 1.8.9, targeted >>>> for the ides of April (more or less). >>>>=20 >>>> Guile 1.8.x users: What changes do you want to see in 1.8.9? >>=20 >> I am not a Guile 1.8.x user, but changes I would like to see is = anything >> that could ease incremental porting to Guile 3.x. If there=E2=80=99s = a way to >> backport incompatible interfaces from 3.x so people can replace the >> 1.8.x-specific interfaces one by one, that could make it more viable = to >> move upwards. >=20 > Guile 2 was already very different from 1.8. >=20 >>>> Guile maintainers: Any tips (process, content, interop, etc) >>>> most welcome! >>>=20 >>> Guile 1.8 has been unmaintained for years and I wonder about the = message >>> we=E2=80=99d be sending by publishing a bug-fix release 11 years and = 3 major >>> versions later. >>=20 >> The message we=E2=80=99re sending is that we don=E2=80=99t leave = anyone out in the cold >> who committed to using Guile. >=20 > The mailing lists are evidence enough that users of Guile 1.8 can get > help in migrating to version 2+. >=20 > But suggesting that Guile 1.8 is still maintained when it emphatically > is not =E2=80=94 that is a step too far, in my opinion. >=20 I spent the last few months of my allowed "hacking time" in trying to = understand the situation and the possible strategies TeXmacs has wrt. = extension language. Since the beginning TeXmacs used Guile (I think it = was the natural choice for a GNU project). In TeXmacs Guile is an = "extension language" and this means various things. 1) most of the codebase is in C++ and depends on other large libraries = like Qt for cross-platform compatibility and defines its own interface = to the OS 2) internally we do not use Unicode for strings 3) our code is written for a fast interpreted and dynamical scheme (like = Guile 1.8) all these three features point to weakness of various possible solutions 1) we do not need a Scheme with a lot of OS interfaces, this duplicate = functionalities in QT and in our own code. For example all the OS = interaction is dealt with internal functions (also because TeXmacs has = its own virtual filesystem). We do not need threads, GMP, etc... all = these additional parts add bloat without providing real useful = functionalities. 2) it is better for us to have a Scheme which is not picky wrt. = encodings.=20 3) compiled schemes or schemes without first-class modules are more = difficult to adapt to our own flavour of scheme coding. Currently I'm trying three different routes: - embed S7 (which is fast, dynamic and minimal and works everywhere) - go for Guile 3 (I've still problems with phasing of macro expansion = and bootstrap of our codebase. Will it work on Windows? Do we really = need to carry on all the code we do not use?) - go for Chez Scheme (like for Guile 3 problems with compilation phases = and bootstrap of our codebase. I'm more confident it will work on = Windows and on new architecture, it is more compact than Guile, = essentially only the compiler, I've still problems with the garbage = collector at the level of C++ interface). My feeling is that Scheme developers are focused on compiled static = programs and not so much on providing a reliable extension language for = other programs. Ideally I would agree with the idea of writing = everything in a fast scheme, but reality is different: cross-platform = GUI are written in C++, TeXmacs' typesetting code is in C++: nobody has = the time to rewrite everything. What Scheme provide to TeXmacs (and I = think to a project like Lilypond, which however I do not know well) is a = way to create our own extension language where to specify custom = behaviour: we have macros to describe the GUI, the keybindings, the = conversion algorithms, etc... all this is a quite large codebase which = does not fit very much in the "statically compiled module" idea. Still = it is a very complex layer (TeXmacs has 100.000 lines of Scheme code). Guile 1.8 works very well for us, that is the irony... We like it a lot, = it is fast (and we need fast because interpreted code is called at every = keypress....) It is so good that it is not easy to find a replacement: = Chibi is too slow, S7 is very good but I needed to patch it otherwise it = had some problem and was much slower than Guile 1.8.=20 So Guile 1.8 today remains a very good piece of software, that is the = reason we keep it. Maybe Lilypond has similar reasons. Our problems come = from the fact that major Linux distributions do not package it anymore, = so packaging TeXmacs has become a pain. We are even thinking to just = include the code in our codebase... or even include Guile 1.6 which is = also good enough for us and does not force us to link GMP. In my mind Guile 1.8 is a very different language than Guile 2/3 and I = do not see reason to make difficult for people to install them in = parallel as it is possible for Guile 2 and Guile 3. Guile 2 cannot = replace Guile 1.8, in this respect S7 is a better replacement, actively = maintained.=20 What would be ideal for large programs like ours is to have an extension = language with the following characteristics: 1) it exposes as little surface as possible to the OS (so that it is = easily portable and adaptable), 2) allow to use other string representations, so that one can just use = the strings which come with the application without marshalling them = thru the FFI, 3) is fast enough even with interpreted code so that interactive = applications can rely on it. 4) it has some consideration of interactive applications where the = separations of code in libraries is not very appropriate: one cannot ask = the user to import 10-20 modules before being able to write some code. = In TeXmacs we have a system where every module create procedures in a = global environment. This is easy to do with Guile first-class modules = but it is quite difficult to do in other schemes which are more picky = about symbol lookup.=20 I would be interested in hearing from other "large" adopters of Guile = about their experience on the topics I mentioned above.=20 Also I would be interested in pointers into current uses of Guile in = other large programs so that I can learn patterns/techniques which maybe = I've missed (how to structure the codebase, how to do cross-platform = development, interaction with the OS, etc...) Let me just finish by saying that at the moment we do not have clear = plans on the future of Guile in TeXmacs, and it is probable that we will = stick with Guile 1.8 for a while longer, so if there are patch around = (e.g. to compile in Windows, etc...) it would be very useful to have a = way to centralize them, and maybe to have Guile 1.8 parallel installable = with Guile 2/3.=20 Best, Massimiliano ps: some time ago I noted down some remarks about the problem of which = Scheme to use in TeXmacs here : = https://texmacs.github.io/notes/docs/scheming.html = comments are welcome. > --=20 > Ricardo