Re: Please test gub
>> @Werner: Didn't you write something about updating python in gub? Well, someone (I forgot his name) offered to work on updating python to the latest 2.7.x version, which should make it easier to eventually migrate to python 3.x... > I assume you're referring to the situation that (e.g.) 2.19.82's > musicxml2ly chokes with an error message regarding UTF-8 and > producing ly files containing garbage bytes in each literal string. > > On my system, your description matches: Current Master's musicxml2ly > python script runs fine using my local python2 (2.7.15rc1) but has > the error using 2.19.82's python2.4 (2.4.5). Given that nobody is really working on musicxml2ly, I strongly suggest that people start testing and using Jacques Menu's `xml2ly' program instead: https://github.com/grame-cncm/libmusicxml/tree/lilypond (i.e., the `lilypond' branch of the `libmusicxml' git repository). AFAIK, the results are far superior to the `musicxml2ly' script. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Le vendredi 08 février 2019 à 22:19 +0100, Werner LEMBERG a écrit : > > - addition of texinfo/txi-pt.tex from Texinfo sources, as > Portuguese > > translation has been added and I don't have Texinfo installed in > GUB > > host system; > > ??? What exactly needs Portuguese? Lilypond doesn't, AFAICS. In stable/2.20 here's a translation of the website in this language, and a PDF of the website is built and even shipped in the documentation tarball and the website, e.g. look at the end of the file list on http://lilypond.org/doc/v2.19/Documentation/ Is there some practical usage of web*.pdf documents, or shall we prevent their building? BTW I'm surprised to see that the doc compiled for offline usage is uploaded to lilypond.org instead of the doc to be served online with content negotiation; I must have missed something about this during my several years long LilyPond hibernation. > Yeah, it would be nice to know whether this is a Python issue that > can > be corrected by using a newer version, or whether a gub programming > error. I'm almost certain GUB Python code runs under Python installation of the OS, and Ubuntu 14.05 with available updates applied I used for GUB provides 2.7.6. I think it's a programming error, but I doubt this non- clean build issue has a higher priority than other items like Python update in GUB. BTW it was me the guy who proposed to work on this, and I've completed nearly 3/4 of the migration of a big patch for cross-building Python 2.7; lots of tests of Python scripts in binaries may be necessary when this is ready to be built. Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi, -- 5e44fec38f33997109bc85c099472b2736649fde is the first bad commit commit 5e44fec38f33997109bc85c099472b2736649fde Author: Frederic Gohier Date: Thu May 10 11:12:44 2018 +0100 Fix crash when using musicxml2ly Issue 5317 Crash when running musicxml2ly :04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 750f9ccdbec7fa68babf3f4414aecb70f57c812b M python -- So this might be the "currently unknown point in time"? ... I'm sorry, but this does not seem to be correct. It seems Frederic's commit fixed a crash that made the UTF-8 problem visible because one could not get to that point before. So it seems one has to apply Frederic's change to older revisions as well in order to be able to bisect the UTF-8 problem. Is this possible with git? Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools. At some currently unknown point in time musicxml2ly became incompatible to our python 2.4. The hidden usage of the system's python masked that incompatibility. With our python 2.4 musicxml2ly does not barf, it simply produces garbage that lateron causes lilypond to fail. The error was introduced when John Gourlay copied changes made by Philomelos into the LilyPond git tree in commits 2ab5d80245dcab194daea64ec83ded3ec8252e51 dc90b895668826a09e06ad1ef94e5e90569a870c da6591bef1cd9c684a9fb98f1563ea40c543ecdd in February 2016. Since these changes were copied as a bunch, one would probably have to delve into Philomelos's git tree or analyze the source directly. If you folks think it would be worth the effort, I could try to do this. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
On my system, your description matches: Current Master's musicxml2ly python script runs fine using my local python2 (2.7.15rc1) but has the error using 2.19.82's python2.4 (2.4.5). Given that nobody is really working on musicxml2ly, I strongly suggest that people start testing and using Jacques Menu's `xml2ly' program instead: https://github.com/grame-cncm/libmusicxml/tree/lilypond (i.e., the `lilypond' branch of the `libmusicxml' git repository). AFAIK, the results are far superior to the `musicxml2ly' script. Well, the situation is that (at least with currently shipped 2.19.82) there is a tool called musicxml2ly (which is also explicitly supported in Frescobaldi, so people might expect it to work) but which fails on execution. I'm not well acquainted with the situation for 2.20 (e.g. which Python version might be shipped with it), but it seems to me that to have a well-documented tool shipped with LilyPond might be a show-stopper for a stable release. I'm not sure I see the situation correctly, but the only ways forward I see would be to 1) make musicxml2ly work again (by changing the Python version used, or by fixing the problems with 2.4), or 2) remove musicxml2ly from the distribution bundle, possibly 2a) without replacement, 2b) replaced by xml2ly Even if 2b) is the most attractive route in the long term, as you suggest, it seems to me that only 2a) and maybe 1) can be expected to happen soon enough for a stable release of 2.20. And I'm not sure whether 2a) would be a good idea. I'm willing to try and help, but I'm not at all convinced that my very limited coding skills can be of much use here. Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Lukas-Fabian Moser writes: >>> For more than 10 years gub/specs/lilypond.py used >>> /usr/bin/python. That means that during lilypond-test the system's >>> python interpreter is used as the interpreter for the musicxml2ly >>> script, not our own python in target/tools. At some currently >>> unknown point in time musicxml2ly became incompatible to our python >>> 2.4. The hidden usage of the system's python masked that >>> incompatibility. >>> >>> With our python 2.4 musicxml2ly does not barf, it simply produces >>> garbage that lateron causes lilypond to fail. >>> > The error was introduced when John Gourlay copied changes made by > Philomelos into the LilyPond git tree in commits > > 2ab5d80245dcab194daea64ec83ded3ec8252e51 > dc90b895668826a09e06ad1ef94e5e90569a870c > da6591bef1cd9c684a9fb98f1563ea40c543ecdd > > in February 2016. Since these changes were copied as a bunch, one > would probably have to delve into Philomelos's git tree or analyze the > source directly. > > If you folks think it would be worth the effort, I could try to do this. I think it would make more sense updating Python to 2.7 in Gub. With a few people currently looking at Gub, does that seem feasible? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Relocation
Folks, attached are two images that show my planned documentation of lilypond's binary relocation. What I'm interested in are comments to the relocation algorithm. If we can find an agreement, I'm going to fix lilypond to follow it.[*] Right now, lilypond's behaviour is quite erratic and has some bugs... Werner [*] Note that the planned environment variable LILYPOND_RELOCDIR doesn't exist yet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Relocation
>> I'd rather do this in the opposite order and put #4 and #5 (as "Use >> VAR_FOODIR as LilyPond FOO directory) just after #1, and execute #2 >> only if LILYPOND_DATADIR environment variable is unset. > > Good idea, thanks. Here's an updated version of the algorithm, which is now pretty simple and thus probably better :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Relocation
>> What I'm interested in are comments to the relocation algorithm. >> If we can find an agreement, I'm going to fix lilypond to follow >> it.[*] > > Is there a good reason for looking for $INSTALLER_PREFIX > subdirectories (#2) before examining whether LILYPOND_DATADIR and > LILYPOND_LOCALEDIR are already set in the environment (#4 and #5)? It has been implemented like this by Hanwen and Jan. > I'd rather do this in the opposite order and put #4 and #5 (as "Use > VAR_FOODIR as LilyPond FOO directory) just after #1, and execute #2 > only if LILYPOND_DATADIR environment variable is unset. Good idea, thanks. > I'm not sure of the semantics of #3: does "relocation is disabled, > and a compile-time value for data directory is used" imply exiting > after this, skipping all the other items? Yes, this is my plan. > I'd rather put #3 after #6, with condition "if LilyPond's data > directory is still not set", so that possible overrides defined in > #6 can be applied. Overrides in #6 don't affect lilypond's data directory. > Maybe I didn't get that you might have designed #6 not for > relocation of LilyPond itself, but for its dependencies (GS, > Fontconfig, Guile...). Exactly. > I also have a minor concern with $INSTALLER_PREFIX/etc/relocate: > could we use a less generic path to avoid any clash with other > packages in $INSTALLER_PREFIX? Again, this is code from Hanwen and Jan, but it should be easy to change that. However, ... > Something like $INSTALLER_PREFIX/etc/lilypond-relocate or > $INSTALLER_PREFIX/etc/lilypond/relocate. ... I think this is not necessary. I'm not aware of any other program that uses a similar mechanism with a `relocate' directory to set environment variables needed internally. >> Right now, lilypond's behaviour is quite erratic and has some >> bugs... > > You allude to many issues we had with GUB builds, don't you? Actually no. It's rather that the current code doesn't cover all cases. For example, if you call lilypond as `./lilypond' (i.e., you are in the binary's directory), you get a wrong relocation path for the datadir. On the other hand, if relocation fails, there is no compile-time datadir defined at all... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Relocation
Le samedi 09 février 2019 à 20:56 +0100, Werner LEMBERG a écrit : > attached are two images that show my planned documentation of > lilypond's binary relocation. What I'm interested in are comments to > the relocation algorithm. If we can find an agreement, I'm going to > fix lilypond to follow it.[*] Is there a good reason for looking for $INSTALLER_PREFIX subdirectories (#2) before examining whether LILYPOND_DATADIR and LILYPOND_LOCALEDIR are already set in the environment (#4 and #5)? I'd rather do this in the opposite order and put #4 and #5 (as "Use VAR_FOODIR as LilyPond FOO directory) just after #1, and execute #2 only if LILYPOND_DATADIR environment variable is unset. I'm not sure of the semantics of #3: does "relocation is disabled, and a compile-time value for data directory is used" imply exiting after this, skipping all the other items? I'd rather put #3 after #6, with condition "if LilyPond's data directory is still not set", so that possible overrides defined in #6 can be applied. Maybe I didn't get that you might have designed #6 not for relocation of LilyPond itself, but for its dependencies (GS, Fontconfig, Guile...). I also have a minor concern with $INSTALLER_PREFIX/etc/relocate: could we use a less generic path to avoid any clash with other packages in $INSTALLER_PREFIX? Something like $INSTALLER_PREFIX/etc/lilypond- relocate or $INSTALLER_PREFIX/etc/lilypond/relocate. > Right now, lilypond's behaviour is quite > erratic and has some bugs... You allude to many issues we had with GUB builds, don't you? Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please test gub
Hi everybody, For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools. At some currently unknown point in time musicxml2ly became incompatible to our python 2.4. The hidden usage of the system's python masked that incompatibility. With our python 2.4 musicxml2ly does not barf, it simply produces garbage that lateron causes lilypond to fail. @Werner: Didn't you write something about updating python in gub? I assume you're referring to the situation that (e.g.) 2.19.82's musicxml2ly chokes with an error message regarding UTF-8 and producing ly files containing garbage bytes in each literal string. On my system, your description matches: Current Master's musicxml2ly python script runs fine using my local python2 (2.7.15rc1) but has the error using 2.19.82's python2.4 (2.4.5). -- 5e44fec38f33997109bc85c099472b2736649fde is the first bad commit commit 5e44fec38f33997109bc85c099472b2736649fde Author: Frederic Gohier Date: Thu May 10 11:12:44 2018 +0100 Fix crash when using musicxml2ly Issue 5317 Crash when running musicxml2ly :04 04 32b11d27366ff7d629f2b6ca4d250a08293d6ece 750f9ccdbec7fa68babf3f4414aecb70f57c812b M python -- So this might be the "currently unknown point in time"? Best Lukas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
