unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
To: Jean Abou Samra <jean@abou-samra.fr>
Cc: Nala Ginrut <nalaginrut@gmail.com>,
	Matias Jose Seco Baccanelli <matias_jose_seco@autoproduzioni.net>,
	Guile User <guile-user@gnu.org>
Subject: Re: Curiosity: Microkernel implemented in Guile ?
Date: Sun, 26 Jun 2022 08:22:08 +0200	[thread overview]
Message-ID: <87fsjrap6t.fsf@web.de> (raw)
In-Reply-To: <U7F1ER.6TNNMZBOUMZQ2@abou-samra.fr>

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]


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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

  reply	other threads:[~2022-06-26  6:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23  6:11 Curiosity: Microkernel implemented in Guile ? Matias Jose Seco Baccanelli
2022-06-23  6:57 ` Mikael Djurfeldt
2022-06-23  9:01   ` Ricardo G. Herdt
2022-06-24  5:40     ` Dr. Arne Babenhauserheide
2022-06-23  7:02 ` Dr. Arne Babenhauserheide
2022-06-23  7:32 ` zimoun
2022-06-23  7:34 ` Maxime Devos
2022-07-02  9:47   ` Matias Jose Seco Baccanelli
2022-07-04  2:49     ` Blake Shaw
2022-06-23  9:13 ` pukkamustard
2022-06-23 10:09 ` Nala Ginrut
2022-06-23 11:22   ` Maxime Devos
2022-06-23 15:38   ` Nala Ginrut
2022-06-23 22:03     ` Dr. Arne Babenhauserheide
2022-06-24  1:12       ` Nala Ginrut
2022-06-24  5:45         ` Dr. Arne Babenhauserheide
2022-06-24  7:01         ` Jean Abou Samra
2022-06-24  7:41           ` Dr. Arne Babenhauserheide
2022-06-25 14:35             ` Jean Abou Samra
2022-06-26  6:22               ` Dr. Arne Babenhauserheide [this message]
2022-06-26  7:55                 ` Ricardo Wurmus
2022-06-26  8:32                   ` Dr. Arne Babenhauserheide
2022-06-28 22:23                 ` Jean Abou Samra
2022-06-26 10:37               ` Nala Ginrut
2022-06-28 22:30                 ` Jean Abou Samra
2022-06-24 12:42           ` Nala Ginrut
2022-06-24  3:27       ` Ognen Duzlevski
2022-06-24 21:24         ` Dr. Arne Babenhauserheide
2022-06-23 12:13 ` Ognen Duzlevski
2022-06-23 13:30   ` Dr. Arne Babenhauserheide
2022-06-23 17:47     ` Paul Emsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsjrap6t.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=guile-user@gnu.org \
    --cc=jean@abou-samra.fr \
    --cc=matias_jose_seco@autoproduzioni.net \
    --cc=nalaginrut@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).