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 --]
next prev parent 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).