Re: Curiosity: Microkernel implemented in Guile ?

[Jean Abou Samra <jean@abou-samra.fr>]

Hi,

Le 26/06/2022 à 08:22, Dr. Arne Babenhauserheide a écrit :
> Jean Abou Samra <jean@abou-samra.fr> writes:
>> (Also replying to Nala.) On the one hand, you have Guile without
>> compiled
>> bytecode, which is slow to run, and more importantly painful to use
>> because there are no error locations and often no function names in
>> error messages. On the other hand, Guile with bytecode takes compilation
>> time, which is an impediment in applications where it is merely being
>> used as a language that is practical to use for small extensions to an
>> existing program, without a need for optimized code. It forces you to
>> recompile even if you just touched one file, since otherwise it emits
>> ;;; messages about outdated .go files that create noise and/or affect
>> correctness. The compilation is impractical to set up when interfacing
>> with C if your main function is on the C side since compiling is started
>> from the Scheme side. There is no dependency tracking, so you need to
>> recompile everything whenever you change one file, which does not
>> encourage
>> quick experiments. Bytecode is fussy to integrate in installers: when
>> the user
>> unpacks an archive, you need to ensure that the .go files are unpacked
>> after the .scm files, otherwise Guile will consider them outdated. I
>> could list more …
> Please do! I’ve been trying to get a concrete list for issues hurting
> Lilypond for a long time.
>
> To summarize what I understood so far (with notes):
>
> - The compilation-messages (I hate them; these also hurt when writing
>    interactive utilities for the command-line, and I have too many
>    half-working fixes in script files to still be comfortable; I think I
>    once had a fix in configuration, but I lost it again — or maybe I had
>    just hacked Guile)
>
> - No dependency tracking for the explicit compilation, so changes to
>    Guile-code used elsewhere require an expensive re-compilation step,
>    even though compile-times are just what you want to avoid with a
>    scripting language ⇒ auto-compilation should just work and be
>    *silent*. Could this be fixed with a tool that recovers those
>    dependencies from Scheme-files? Something like
>    ./list-dependent-files.scm --start foo.scm bar.scm baz.scm moo.scm goo.scm
>    ⇒ bar.scm
>      baz.scm


Add:

- There is no simple way to byte-compile when the main
   function is in C(++). See the thread
https://lists.gnu.org/archive/html/guile-user/2022-02/msg00129.html
   about this one.

- A smarter strategy than looking at modification dates should
   be found for deciding when a bytecode file is outdated, for
   example storing a hash of the source file in the bytecode.
   This should avoid the problems with extracting and installing.

- Unless compilation is made really fast and can be used on-the-fly
   for large code chunks, interpreted code should be able to give
   meaningful error locations and backtraces.



>> Sorry for not exactly bringing enthusiasm to this otherwise interesting
>> thread.
> Don’t worry. I asked, and I’m glad you answered. There might be things
> that cannot be fixed, but I have not yet seen one here.



Sure, everything can be fixed with enough time and motivation.
We're in the free software world after all, and I have no
problem with tinkering with Guile myself to fix issues that
affect me. The problem, though, is getting the patches in Guile
after they have been produced. For example, exactly three months
ago I posted a patch fixing docstrings in curried definitions
<https://lists.gnu.org/archive/html/guile-devel/2022-03/msg00024.html>
which would fix a problem that prevents functions defined using
curried define from being listed in LilyPond's autogenerated
documentation. So far the patch has not received a reply. The
same holds for most patches being posted. This is the single one
thing that saddens me most about Guile, before all the technical
issues. Quite frankly, Guile is on the right path to abandonware.
I've said this before and I hoped the discussion
<https://lists.gnu.org/archive/html/guile-devel/2021-12/msg00012.html>
would lead to some change, but it didn't seem to happen.


> Though I don’t want to give false hope: I am not a core developer, so I
> cannot promise fast fixes. I can only promise that I will help pushing
> Guile more into the direction that Lilypond needs.


In my view, the most significant direction that LilyPond
needs is a situation where maintenance fixes can make it
to the main branch.


Thanks,
Jean