guile-user
[Top][All Lists]
Advanced

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

Re: Curiosity: Microkernel implemented in Guile ?


From: Dr. Arne Babenhauserheide
Subject: Re: Curiosity: Microkernel implemented in Guile ?
Date: Sun, 26 Jun 2022 08:22:08 +0200
User-agent: mu4e 1.6.11; emacs 28.1

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

> 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.

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.

Because for me, Lilypond is one of the most important tools that use
Guile. I use several Guile-using tools nowadays, but the only one I
could really not do without is Lilypond.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

Attachment: signature.asc
Description: PGP signature


reply via email to

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