Re: source file ... .scm newer than compiled ... .go file
Le 02/11/2022 à 12:02, Federico Bruni a écrit :
Il giorno mer 2 nov 2022 alle 00:12:07 +0100, Jean Abou Samra
ha scritto:
Your patch to Guile disables recompilation with a "return 1;"
at the end of the function but keeps the logic of the check and
the messages. Just additionally remove the code just above the line
it's touching, or add "return 1;" at the beginning of the function
rather than at the end.
I tried removing the whole function, but it's used later, as I got
this error:
https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/17
/usr/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
./.libs/libguile-2.2.so: undefined reference to `compiled_is_fresh'
$ git grep -n compiled_is_fresh
libguile/load.c:550:compiled_is_fresh (SCM full_filename, SCM
compiled_filename,
libguile/load.c:749: !compiled_is_fresh (source_file_name, found,
libguile/load.c:1221: && compiled_is_fresh (full_filename, fallback,
So I'd better use "return 1;" at the beginning of the function? Where
exactly? After the opening "{"?
Yes.
Re: source file ... .scm newer than compiled ... .go file
Il giorno mer 2 nov 2022 alle 00:12:07 +0100, Jean Abou Samra
ha scritto:
Your patch to Guile disables recompilation with a "return 1;"
at the end of the function but keeps the logic of the check and
the messages. Just additionally remove the code just above the line
it's touching, or add "return 1;" at the beginning of the function
rather than at the end.
I tried removing the whole function, but it's used later, as I got this
error:
https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/17
/usr/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
./.libs/libguile-2.2.so: undefined reference to `compiled_is_fresh'
$ git grep -n compiled_is_fresh
libguile/load.c:550:compiled_is_fresh (SCM full_filename, SCM
compiled_filename,
libguile/load.c:749: !compiled_is_fresh (source_file_name, found,
libguile/load.c:1221: && compiled_is_fresh (full_filename, fallback,
So I'd better use "return 1;" at the beginning of the function? Where
exactly? After the opening "{"?
Thanks
Federico
Re: source file ... .scm newer than compiled ... .go file
Le 01/11/2022 à 23:58, Federico Bruni a écrit : Today I noticed that the current Frescobaldi flatpak (LilyPond 2.23.80) doesn't hang, but it always prints a wall of annoying messages like: [...] I though that disabling Scheme recompilation would have also stopped this check. Here's the PR where I introduced the change: https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/14 How can I disable these messages? Your patch to Guile disables recompilation with a "return 1;" at the end of the function but keeps the logic of the check and the messages. Just additionally remove the code just above the line it's touching, or add "return 1;" at the beginning of the function rather than at the end.
Re: source file ... .scm newer than compiled ... .go file
Il giorno gio 13 ott 2022 alle 00:29:15 +0200, Federico Bruni ha scritto: Il giorno mer 12 ott 2022 alle 23:59:32 +0200, Federico Bruni ha scritto: I'll have to find a solution when building the flatpak. Waiting for minutes or hours while CPU hits 100% is not an option. For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Open issue which did not receive any feedback from flatpak developers: https://github.com/flatpak/flatpak/issues/3064 Today I noticed that the current Frescobaldi flatpak (LilyPond 2.23.80) doesn't hang, but it always prints a wall of annoying messages like: % lilypond 2.23.80 [Senza nome] in avvio... ;;; note: source file /app/share/guile/2.2/ice-9/psyntax-pp.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-1.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-1.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-9.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-9/gnu.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9/gnu.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-11.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-11.go ;;; note: source file /app/share/guile/2.2/rnrs/bytevectors.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/rnrs/bytevectors.go ;;; note: source file /app/share/guile/2.2/system/base/compile.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/system/base/compile.go ;;; note: source file /app/share/guile/2.2/system/vm/vm.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/system/vm/vm.go ;;; note: source file /app/share/guile/2.2/language/tree-il/optimize.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/tree-il/optimize.go ;;; note: source file /app/share/guile/2.2/language/tree-il/primitives.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/tree-il/primitives.go ;;; note: source file /app/share/guile/2.2/language/tree-il/peval.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/tree-il/peval.go ;;; note: source file /app/share/guile/2.2/language/tree-il/effects.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/tree-il/effects.go ;;; note: source file /app/share/guile/2.2/language/tree-il/fix-letrec.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/tree-il/fix-letrec.go ;;; note: source file /app/share/guile/2.2/language/cps/optimize.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/optimize.go ;;; note: source file /app/share/guile/2.2/language/cps/constructors.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/constructors.go ;;; note: source file /app/share/guile/2.2/language/cps.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps.go ;;; note: source file /app/share/guile/2.2/language/cps/intmap.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/intmap.go ;;; note: source file /app/share/guile/2.2/language/cps/with-cps.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/with-cps.go ;;; note: source file /app/share/guile/2.2/language/cps/contification.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/contification.go ;;; note: source file /app/share/guile/2.2/language/cps/renumber.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/renumber.go ;;; note: source file /app/share/guile/2.2/language/cps/cse.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/cse.go ;;; note: source file /app/share/guile/2.2/language/cps/effects-analysis.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/effects-analysis.go ;;; note: source file /app/share/guile/2.2/language/cps/dce.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/dce.go ;;; note: source file /app/share/guile/2.2/language/cps/types.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/types.go ;;; note: source file /app/share/guile/2.2/language/cps/licm.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/licm.go ;;; note: source file /app/share/guile/2.2/language/cps/peel-loops.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/peel-loops.go ;;; note: source file /app/share/guile/2.2/language/cps/simplify.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/language/cps/simplify.go ;;; note: source file
Re: source file ... .scm newer than compiled ... .go file
Le 19/10/2022 à 23:25, Carl Sorensen a écrit : Can't we add a batch file or shell script that contains the command (pointing to the lilypond binary) with the proper environment variable set, and point Frescobaldi to the batch file/shell script, rather than to the lilypond binary? We could even name it 'lilypond' if need be. That's the way I would handle it. Yes, exactly, you can do that. As I tried to say in my previous message, if you go for this approach, your shell script will be a wrapper around some LilyPond binary that you downloaded yourself, not the one from the Flatpak (not sure if you can even run that one from outside the Flatpak sandbox, but it's not meant to be). So the patched version of Guile in the Flatpak is not an issue. Thanks, Jean
Re: source file ... .scm newer than compiled ... .go file
On Wed, Oct 19, 2022 at 2:54 PM Federico Bruni wrote: > > > Il giorno mer 19 ott 2022 alle 18:06:16 +0200, Jean Abou Samra > ha scritto: > > Le 19/10/2022 à 17:25, Federico Bruni a écrit : > >> You have to manually add `/app/dev/bin/lilypond` in Frescobaldi. > >> (it's explained in the Github README) > >> It's a Frescobaldi limitation: it checks and adds only the first > >> lilypond executable in the PATH. > > > > > > OK, I may have invented a nonexistent problem after all. > > Does Frescobaldi have a way to run LilyPond with some > > environment variables set? If not, my point is moot. > > > > As far as I know, no, it's not possible to set up an environment > variable for LilyPond in Frescobaldi. > The best place to set it up would be "Custom engraving", but it > currently accepts only lilypond options and no environment variables. > If lilypond had an option to set up environment variables... > > Can't we add a batch file or shell script that contains the command (pointing to the lilypond binary) with the proper environment variable set, and point Frescobaldi to the batch file/shell script, rather than to the lilypond binary? We could even name it 'lilypond' if need be. That's the way I would handle it. Carl > >
Re: source file ... .scm newer than compiled ... .go file
Il giorno mer 19 ott 2022 alle 18:06:16 +0200, Jean Abou Samra ha scritto: Le 19/10/2022 à 17:25, Federico Bruni a écrit : You have to manually add `/app/dev/bin/lilypond` in Frescobaldi. (it's explained in the Github README) It's a Frescobaldi limitation: it checks and adds only the first lilypond executable in the PATH. OK, I may have invented a nonexistent problem after all. Does Frescobaldi have a way to run LilyPond with some environment variables set? If not, my point is moot. As far as I know, no, it's not possible to set up an environment variable for LilyPond in Frescobaldi. The best place to set it up would be "Custom engraving", but it currently accepts only lilypond options and no environment variables. If lilypond had an option to set up environment variables... I know how to run LilyPond with Guile auto-compilation: GUILE_AUTO_COMPILE=1 lilypond ... I also know how to do this from Frescobaldi, although I don't usually do this myself: set the lilypond executable in the preferences to a shell script that invokes LilyPond in an environment with GUILE_AUTO_COMPILE=1. AFAIU, the LilyPond executable from the Frescobaldi Flatpak isn't intended to be run from outside Frescobaldi. Even if I used the latter approach, I would use a lilypond executable downloaded myself, which would not have the issue with auto-compilation. If this is correct, sorry for the noise. Yes, I think you are correct. It's not worth testing your patch, until Frescobaldi allows setting the needed environment variable.
Re: source file ... .scm newer than compiled ... .go file
Le 19/10/2022 à 17:25, Federico Bruni a écrit : You have to manually add `/app/dev/bin/lilypond` in Frescobaldi. (it's explained in the Github README) It's a Frescobaldi limitation: it checks and adds only the first lilypond executable in the PATH. OK, I may have invented a nonexistent problem after all. Does Frescobaldi have a way to run LilyPond with some environment variables set? If not, my point is moot. I know how to run LilyPond with Guile auto-compilation: GUILE_AUTO_COMPILE=1 lilypond ... I also know how to do this from Frescobaldi, although I don't usually do this myself: set the lilypond executable in the preferences to a shell script that invokes LilyPond in an environment with GUILE_AUTO_COMPILE=1. AFAIU, the LilyPond executable from the Frescobaldi Flatpak isn't intended to be run from outside Frescobaldi. Even if I used the latter approach, I would use a lilypond executable downloaded myself, which would not have the issue with auto-compilation. If this is correct, sorry for the noise.
Re: source file ... .scm newer than compiled ... .go file
Il giorno mer 19 ott 2022 alle 17:12:31 +0200, Jean Abou Samra ha scritto: Basically it limits "never recompile" to files whose path starts with "/app/". I don't know Flatpak enough to be certain that /app/ is the right path to check, though. I think it's correct. I'll test and let you know. If I merge the flatpak PR tomorrow, can you test it with the edition engraver and report what happens? If you don't have time, no problem and we'll wait for users to report it. Sorry for asking dumb questions: how do I test it? When I install Frescobaldi from Flatpak, it only has LilyPond 2.22 preconfigured. Where should I find 2.23? You have to manually add `/app/dev/bin/lilypond` in Frescobaldi. (it's explained in the Github README) It's a Frescobaldi limitation: it checks and adds only the first lilypond executable in the PATH.
Re: source file ... .scm newer than compiled ... .go file
Le 17/10/2022 à 22:23, Federico Bruni a écrit :
If anybody can provide a patch which can disable automatic
recompilation internal to Guile and LilyPond only, I'd be happy to
apply it.
I'm not sure how to test this but I think it should work:
From fa8f848423d6a104aad0e8ba8fdf87feedd0c4a6 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra
Date: Wed, 19 Oct 2022 17:09:42 +0200
Subject: [PATCH] Never recompile files in /app/
---
libguile/load.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libguile/load.c b/libguile/load.c
index c209812dc..c0d7b5fd0 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -550,6 +550,11 @@ static int
compiled_is_fresh (SCM full_filename, SCM compiled_filename,
struct stat *stat_source, struct stat *stat_compiled)
{
+ if (scm_to_int (scm_string_length (full_filename)) >= 5
+ && scm_to_bool (scm_equal_p (scm_substring (full_filename,
scm_from_int (0), scm_from_int (5)),
+ scm_from_utf8_string ("/app/"
+ return 1;
+
int compiled_is_newer;
struct timespec source_mtime, compiled_mtime;
--
2.37.3
Basically it limits "never recompile" to files whose path starts
with "/app/".
I don't know Flatpak enough to be certain that /app/ is the right
path to check, though.
If I merge the flatpak PR tomorrow, can you test it with the edition
engraver and report what happens?
If you don't have time, no problem and we'll wait for users to report it.
Sorry for asking dumb questions: how do I test it?
When I install Frescobaldi from Flatpak, it only has LilyPond
2.22 preconfigured. Where should I find 2.23?
I don't have any spare time unfortunately and I can work on LilyPond
only for small chunks of time during night.
Re: source file ... .scm newer than compiled ... .go file
Il giorno dom 16 ott 2022 alle 21:35:39 +0200, Jean Abou Samra ha scritto: Le 16/10/2022 à 20:41, Federico Bruni a écrit : Il giorno dom 16 ott 2022 alle 12:18:25 +0200, Jean Abou Samra ha scritto: Le 14/10/2022 à 19:55, Jonas Hahnfeld via Discussions on LilyPond development a écrit : For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Not really great. On the other hand, you only need a very targeted installation and don't expect a fully functional Guile... Try really hard to avoid this. Some LilyPond libraries are written in .scm files, like a lot of the stuff in openLilyLib. It is important to use compilation (by running with GUILE_AUTO_COMPILE=1) in order to get helpful error messages when something goes wrong there. If this patch is used, as soon as one run with GUILE_AUTO_COMPILE=1 has been done, changes in the .scm files will have no effect, which is going to be very confusing for the user ... I'm afraid I have no alternative. The LilyPond 2.23.x version in flatpak doesn't currently work. I don't know when it started breaking, as I usually tested the stable only. I opened a PR which makes 2.23.x work again: https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/14 If all else fails, can you make it depend on the path so that files internal to Guile or LilyPond won't be recompiled but user files will? I don't have the knowledge to work around this issue. Currently I've patched Guile to disable automatic recompilation, so it won't work with any file, regardless of the path. If anybody can provide a patch which can disable automatic recompilation internal to Guile and LilyPond only, I'd be happy to apply it. If I merge the flatpak PR tomorrow, can you test it with the edition engraver and report what happens? If you don't have time, no problem and we'll wait for users to report it. I don't have any spare time unfortunately and I can work on LilyPond only for small chunks of time during night.
Re: source file ... .scm newer than compiled ... .go file
Le 16/10/2022 à 20:41, Federico Bruni a écrit : Il giorno dom 16 ott 2022 alle 12:18:25 +0200, Jean Abou Samra ha scritto: Le 14/10/2022 à 19:55, Jonas Hahnfeld via Discussions on LilyPond development a écrit : For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Not really great. On the other hand, you only need a very targeted installation and don't expect a fully functional Guile... Try really hard to avoid this. Some LilyPond libraries are written in .scm files, like a lot of the stuff in openLilyLib. It is important to use compilation (by running with GUILE_AUTO_COMPILE=1) in order to get helpful error messages when something goes wrong there. If this patch is used, as soon as one run with GUILE_AUTO_COMPILE=1 has been done, changes in the .scm files will have no effect, which is going to be very confusing for the user ... I'm afraid I have no alternative. The LilyPond 2.23.x version in flatpak doesn't currently work. I don't know when it started breaking, as I usually tested the stable only. I opened a PR which makes 2.23.x work again: https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/14 If all else fails, can you make it depend on the path so that files internal to Guile or LilyPond won't be recompiled but user files will? openLilyLib is used by a small number of users, I think, probably not even using flatpak. Most of it is indeed used by a handful of people, but the edition-engraver does have some traction and from time to time you see people asking about problems with it. And then there are the people who write Scheme extensions for themselves without telling anybody ... In case of problems they can still download and use the official LilyPond binaries. Sure, but debugging the problem is not going to be fun for them ... Open issue which did not receive any feedback from flatpak developers: https://github.com/flatpak/flatpak/issues/3064 Yes, this would need proper addressing for use cases such as Guile bytecode compilation. CPython has a system roughly similar to Guile's; how does packaging Python libraries work in Flatpak? I don't know. Do you know some Python libraries which may need a similar feature? OK, forget about this one sorry. I just checked and CPython doesn't rely on the timestamps provided by the filesystem, but embeds them in the .pyc bytecode file itself, which bypasses those redistribution problems.
Re: source file ... .scm newer than compiled ... .go file
Il giorno dom 16 ott 2022 alle 12:18:25 +0200, Jean Abou Samra ha scritto: Le 14/10/2022 à 19:55, Jonas Hahnfeld via Discussions on LilyPond development a écrit : For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Not really great. On the other hand, you only need a very targeted installation and don't expect a fully functional Guile... Try really hard to avoid this. Some LilyPond libraries are written in .scm files, like a lot of the stuff in openLilyLib. It is important to use compilation (by running with GUILE_AUTO_COMPILE=1) in order to get helpful error messages when something goes wrong there. If this patch is used, as soon as one run with GUILE_AUTO_COMPILE=1 has been done, changes in the .scm files will have no effect, which is going to be very confusing for the user ... I'm afraid I have no alternative. The LilyPond 2.23.x version in flatpak doesn't currently work. I don't know when it started breaking, as I usually tested the stable only. I opened a PR which makes 2.23.x work again: https://github.com/flathub/org.frescobaldi.Frescobaldi/pull/14 openLilyLib is used by a small number of users, I think, probably not even using flatpak. In case of problems they can still download and use the official LilyPond binaries. Open issue which did not receive any feedback from flatpak developers: https://github.com/flatpak/flatpak/issues/3064 Yes, this would need proper addressing for use cases such as Guile bytecode compilation. CPython has a system roughly similar to Guile's; how does packaging Python libraries work in Flatpak? I don't know. Do you know some Python libraries which may need a similar feature?
Re: source file ... .scm newer than compiled ... .go file
Le 14/10/2022 à 19:55, Jonas Hahnfeld via Discussions on LilyPond development a écrit : For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Not really great. On the other hand, you only need a very targeted installation and don't expect a fully functional Guile... Try really hard to avoid this. Some LilyPond libraries are written in .scm files, like a lot of the stuff in openLilyLib. It is important to use compilation (by running with GUILE_AUTO_COMPILE=1) in order to get helpful error messages when something goes wrong there. If this patch is used, as soon as one run with GUILE_AUTO_COMPILE=1 has been done, changes in the .scm files will have no effect, which is going to be very confusing for the user ... Open issue which did not receive any feedback from flatpak developers: https://github.com/flatpak/flatpak/issues/3064 Yes, this would need proper addressing for use cases such as Guile bytecode compilation. CPython has a system roughly similar to Guile's; how does packaging Python libraries work in Flatpak? Jean
Re: source file ... .scm newer than compiled ... .go file
> Touching the .go files is not allowed by flatpak.
> I tried this and got an error:
>
> find /app/lib/guile/2.2/ -name *.go -exec touch '{}' \;
> [...]
> touch: cannot touch '/app/lib/guile/2.2/ccache/web/uri.go': Permission
> denied
>
> I'll have to find a solution when building the flatpak.
Yes, the built flatpak is read-only.
> Waiting for minutes or hours while CPU hits 100% is not an option.
I think it's not even going to work, there are some fundamental files
that Guile cannot recompile on the fly...
On Thu, 2022-10-13 at 00:29 +0200, Federico Bruni wrote:
> Il giorno mer 12 ott 2022 alle 23:59:32 +0200, Federico Bruni
> ha scritto:
> > I'll have to find a solution when building the flatpak.
> > Waiting for minutes or hours while CPU hits 100% is not an option.
>
> For the records, another application using Guile (GNU Cash) had the
> same problem with flatpak three years ago.
> Their workaround was disabling recompilation. Bad idea or good idea?
> https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch
Not really great. On the other hand, you only need a very targeted
installation and don't expect a fully functional Guile...
> Open issue which did not receive any feedback from flatpak developers:
> https://github.com/flatpak/flatpak/issues/3064
Yes, this would need proper addressing for use cases such as Guile
bytecode compilation.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: source file ... .scm newer than compiled ... .go file
Il giorno mer 12 ott 2022 alle 23:59:32 +0200, Federico Bruni ha scritto: I'll have to find a solution when building the flatpak. Waiting for minutes or hours while CPU hits 100% is not an option. For the records, another application using Guile (GNU Cash) had the same problem with flatpak three years ago. Their workaround was disabling recompilation. Bad idea or good idea? https://github.com/flathub/org.gnucash.GnuCash/blob/master/patches/0001-Never-recompile.patch Open issue which did not receive any feedback from flatpak developers: https://github.com/flatpak/flatpak/issues/3064
Re: source file ... .scm newer than compiled ... .go file
Il giorno mer 12 ott 2022 alle 21:23:03 +0200, Jonas Hahnfeld
ha scritto:
On Wed, 2022-10-12 at 00:30 +0200, Federico Bruni wrote:
Hi all
I think I've already seen discussions about this.
Can you please remind how to work around this error?
Guile looks at file timestamps and the .go files must always be newer
than their .scm counterparts. Guile's build system should take care of
that during installation, but maybe flatpak copies around some files
afterwards? If you have the chance, either preserve the timestamps, or
copy the lib/ directory after share/. As a last resort, you may also
touch all .go files, but that's more of a hack...
Jonas
Yes, I think flatpak copies files somewhere else after the build and
probably timestamps change. Here's an example:
[ org.frescobaldi.Frescobaldi test]$ ls --full-time
/app/share/guile/2.2/ice-9/psyntax-pp.scm
-rw-r--r--. 2 nfsnobody nfsnobody 184880 2022-04-03 22:54:41.415067967
+0200 /app/share/guile/2.2/ice-9/psyntax-pp.scm
[ org.frescobaldi.Frescobaldi test]$ ls --full-time
/app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go
-rw-r--r--. 2 nfsnobody nfsnobody 506061 2022-04-03 22:54:41.012067973
+0200 /app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go
Touching the .go files is not allowed by flatpak.
I tried this and got an error:
find /app/lib/guile/2.2/ -name *.go -exec touch '{}' \;
[...]
touch: cannot touch '/app/lib/guile/2.2/ccache/web/uri.go': Permission
denied
I'll have to find a solution when building the flatpak.
Waiting for minutes or hours while CPU hits 100% is not an option.
Re: source file ... .scm newer than compiled ... .go file
On Wed, 2022-10-12 at 00:30 +0200, Federico Bruni wrote: > Hi all > > I think I've already seen discussions about this. > Can you please remind how to work around this error? Guile looks at file timestamps and the .go files must always be newer than their .scm counterparts. Guile's build system should take care of that during installation, but maybe flatpak copies around some files afterwards? If you have the chance, either preserve the timestamps, or copy the lib/ directory after share/. As a last resort, you may also touch all .go files, but that's more of a hack... Jonas signature.asc Description: This is a digitally signed message part
Re: source file ... .scm newer than compiled ... .go file
Federico Bruni writes: > Hi all > > I think I've already seen discussions about this. > Can you please remind how to work around this error? > > The 2.23.14 lilypond version built and bundled in Frescobaldi flatpak > hangs forever and cannot compile any simple file, probably because > it's checking this stuff. > > [ org.frescobaldi.Frescobaldi test]$ /app/dev/bin/lilypond test.ly > GNU LilyPond 2.23.14 (running Guile 2.2) > ;;; note: source file /app/share/guile/2.2/ice-9/psyntax-pp.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-1.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-1.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-9.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-9/gnu.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9/gnu.go > ;;; note: source file /app/share/guile/2.2/srfi/srfi-11.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-11.go > ;;; note: source file /app/share/guile/2.2/rnrs/bytevectors.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/rnrs/bytevectors.go > ;;; note: source file /app/share/guile/2.2/system/base/compile.scm > ;;; newer than compiled /app/lib/guile/2.2/ccache/system/base/compile.go > > [...] Just go to bed and hope that the file is through in the morning. Hopefully this is a one-time thing. -- David Kastrup
source file ... .scm newer than compiled ... .go file
Hi all I think I've already seen discussions about this. Can you please remind how to work around this error? The 2.23.14 lilypond version built and bundled in Frescobaldi flatpak hangs forever and cannot compile any simple file, probably because it's checking this stuff. [ org.frescobaldi.Frescobaldi test]$ /app/dev/bin/lilypond test.ly GNU LilyPond 2.23.14 (running Guile 2.2) ;;; note: source file /app/share/guile/2.2/ice-9/psyntax-pp.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/ice-9/psyntax-pp.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-1.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-1.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-9.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-9/gnu.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-9/gnu.go ;;; note: source file /app/share/guile/2.2/srfi/srfi-11.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/srfi/srfi-11.go ;;; note: source file /app/share/guile/2.2/rnrs/bytevectors.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/rnrs/bytevectors.go ;;; note: source file /app/share/guile/2.2/system/base/compile.scm ;;; newer than compiled /app/lib/guile/2.2/ccache/system/base/compile.go [...]
