Re: Scoping of Guile modules
Am Samstag, dem 06.02.2021 um 22:27 +0100 schrieb Jonas Hahnfeld: > Am Samstag, dem 06.02.2021 um 21:01 +0100 schrieb Han-Wen Nienhuys: > > On Sat, Feb 6, 2021 at 7:21 PM Jonas Hahnfeld > > wrote: > > > While trying to understand the current situation of LilyPond and its > > > Guile modules, I noticed that there is a certain split: > > > * lily.scm and all files pulled in by ly:load are referenced relative > > > to scm/, ie just the file name (without the extension after my changes > > > at https://gitlab.com/lilypond/lilypond/-/merge_requests/635 ). > > > * On the other hand, proper modules are prefixed with (scm), for > > > example (scm framework-ps) and (scm output-ps). > > > > > > This works right now, but requires that main_with_guile prepends both > > > the determined datadir and datadir + "/scm" to the %load-path. Similar > > > treatment would be necessary for %load-compiled-path for the compiled > > > bytecode. That's a bit ugly because it requires an scm/ directory to > > > hold the compiled .go files... > > > > > > I experimented with this locally and it seems possible to remove the > > > (scm) scope and reference all modules relative to scm/, ie have modules > > > (framework-ps), (output-ps) and so on. My question would be: Is there a > > > good reason *not* to do this? > > > As far as I could find out, this split goes back to the very first > > > module added in commit > > > https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b > > > from 2001. I'm adding Han-Wen and Jan, do you happen to remember if > > > that was an explicit choice or "just worked"? > > > > I think this is a setup that stuck to the wall when we threw it, so > > there is no urgent reason to keep the naming precisely like this. > > However, other Scheme modules are grouped (eg, "(srfi srfi-1)" or > > "(ice-9 optargs)"). I think it would be good to follow this style and > > have a lilypond-specific prefix. Maybe "(lily framework-ps)" ? > > Yes, that would have been my next question: We can either go with a > flat layout like (framework-ps) or introduce our own scope that we use > consistently, like (lily framework-ps). Upon installation that would > require a subdirectory to both scm/ and the directory holding the > compiled bytecode, certainly doable I would say. What I'm not sure > about is lily.scm that is loaded into a module (lily) created by > lily/guile-init.cc. Should this become (lily lily), which looks odd, or > can this stay (lily) and still have submodules? Note that keeping this > at (lily) might be slightly awkward because it means that lily.scm must > not be installed in scm/lily/ like all other files, but only scm/ This is now https://gitlab.com/lilypond/lilypond/-/merge_requests/710 (at least for the sources, nothing related to bytecode yet). signature.asc Description: This is a digitally signed message part
Re: Scoping of Guile modules
On Feb 6, 2021, at 16:27, Jonas Hahnfeld wrote: > > lily/guile-init.cc. Should this become (lily lily), which looks odd, or or (lily core) or (lily main) but (srfi srfi-1) looks odd too and I haven't heard anyone complain. — Dan
Re: Scoping of Guile modules
Am Samstag, dem 06.02.2021 um 21:01 +0100 schrieb Han-Wen Nienhuys: > On Sat, Feb 6, 2021 at 7:21 PM Jonas Hahnfeld > wrote: > > While trying to understand the current situation of LilyPond and its > > Guile modules, I noticed that there is a certain split: > > * lily.scm and all files pulled in by ly:load are referenced relative > > to scm/, ie just the file name (without the extension after my changes > > at https://gitlab.com/lilypond/lilypond/-/merge_requests/635 ). > > * On the other hand, proper modules are prefixed with (scm), for > > example (scm framework-ps) and (scm output-ps). > > > > This works right now, but requires that main_with_guile prepends both > > the determined datadir and datadir + "/scm" to the %load-path. Similar > > treatment would be necessary for %load-compiled-path for the compiled > > bytecode. That's a bit ugly because it requires an scm/ directory to > > hold the compiled .go files... > > > > I experimented with this locally and it seems possible to remove the > > (scm) scope and reference all modules relative to scm/, ie have modules > > (framework-ps), (output-ps) and so on. My question would be: Is there a > > good reason *not* to do this? > > As far as I could find out, this split goes back to the very first > > module added in commit > > https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b > > from 2001. I'm adding Han-Wen and Jan, do you happen to remember if > > that was an explicit choice or "just worked"? > > I think this is a setup that stuck to the wall when we threw it, so > there is no urgent reason to keep the naming precisely like this. > However, other Scheme modules are grouped (eg, "(srfi srfi-1)" or > "(ice-9 optargs)"). I think it would be good to follow this style and > have a lilypond-specific prefix. Maybe "(lily framework-ps)" ? Yes, that would have been my next question: We can either go with a flat layout like (framework-ps) or introduce our own scope that we use consistently, like (lily framework-ps). Upon installation that would require a subdirectory to both scm/ and the directory holding the compiled bytecode, certainly doable I would say. What I'm not sure about is lily.scm that is loaded into a module (lily) created by lily/guile-init.cc. Should this become (lily lily), which looks odd, or can this stay (lily) and still have submodules? Note that keeping this at (lily) might be slightly awkward because it means that lily.scm must not be installed in scm/lily/ like all other files, but only scm/ > Are you trying to create a setup where the byte-compiled files are > preinstalled? I'm not sure what you mean by "pre"installed. But yes, from what I can see we will need to get compiled bytecode to reach startup times and overall performance comparable to Guile 1.8. I intend to post exact numbers once I have a complete setup, but it looks like having all .scm files compiled into .go files (currently via GUILE_AUTO_COMPILE) gets most metrics on par with Guile 1.8... signature.asc Description: This is a digitally signed message part
Re: Scoping of Guile modules
On Sat, Feb 6, 2021 at 7:21 PM Jonas Hahnfeld wrote: > While trying to understand the current situation of LilyPond and its > Guile modules, I noticed that there is a certain split: > * lily.scm and all files pulled in by ly:load are referenced relative > to scm/, ie just the file name (without the extension after my changes > at https://gitlab.com/lilypond/lilypond/-/merge_requests/635 ). > * On the other hand, proper modules are prefixed with (scm), for > example (scm framework-ps) and (scm output-ps). > > This works right now, but requires that main_with_guile prepends both > the determined datadir and datadir + "/scm" to the %load-path. Similar > treatment would be necessary for %load-compiled-path for the compiled > bytecode. That's a bit ugly because it requires an scm/ directory to > hold the compiled .go files... > > I experimented with this locally and it seems possible to remove the > (scm) scope and reference all modules relative to scm/, ie have modules > (framework-ps), (output-ps) and so on. My question would be: Is there a > good reason *not* to do this? > As far as I could find out, this split goes back to the very first > module added in commit > > https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b > from 2001. I'm adding Han-Wen and Jan, do you happen to remember if > that was an explicit choice or "just worked"? > I think this is a setup that stuck to the wall when we threw it, so there is no urgent reason to keep the naming precisely like this. However, other Scheme modules are grouped (eg, "(srfi srfi-1)" or "(ice-9 optargs)"). I think it would be good to follow this style and have a lilypond-specific prefix. Maybe "(lily framework-ps)" ? Are you trying to create a setup where the byte-compiled files are preinstalled? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Scoping of Guile modules
While trying to understand the current situation of LilyPond and its Guile modules, I noticed that there is a certain split: * lily.scm and all files pulled in by ly:load are referenced relative to scm/, ie just the file name (without the extension after my changes at https://gitlab.com/lilypond/lilypond/-/merge_requests/635 ). * On the other hand, proper modules are prefixed with (scm), for example (scm framework-ps) and (scm output-ps). This works right now, but requires that main_with_guile prepends both the determined datadir and datadir + "/scm" to the %load-path. Similar treatment would be necessary for %load-compiled-path for the compiled bytecode. That's a bit ugly because it requires an scm/ directory to hold the compiled .go files... I experimented with this locally and it seems possible to remove the (scm) scope and reference all modules relative to scm/, ie have modules (framework-ps), (output-ps) and so on. My question would be: Is there a good reason *not* to do this? As far as I could find out, this split goes back to the very first module added in commit https://gitlab.com/lilypond/lilypond/-/commit/e11dc9a89c31b64615bcdcb8b536621ded30176b from 2001. I'm adding Han-Wen and Jan, do you happen to remember if that was an explicit choice or "just worked"? Jonas signature.asc Description: This is a digitally signed message part
