Re: Broken commit IDs in French translation

[Jean-Charles Malahieude]

Le 05/11/2022 à 18:39, Jean Abou Samra a écrit :



Le 05/11/2022 à 17:26, Jean-Charles Malahieude a écrit :

Le 03/11/2022 à 21:31, Jean Abou Samra a écrit :

Hi Jean-Charles,

What is your procedure for filling in commit IDs in translated
files? It looks like a number of them don't exist in the repository.




I either copy what is returned by "git rev-parse HEAD" or then content 
of the "Id SHA1" field  in gitk.


I don't know whats is going wrong.




Does it happen that you insert the ID of a commit that is in your branch 
but not in master yet?




Because of what you say below, it happens to have been a /bad/ habit…

Our workflow is based on rebasing one's branch just before merging, and 
rebasing changes commit IDs (more precisely, because Git commits are 
immutable, it creates new commits with different IDs).




In the old times the Translation branch was merged without rebasing.
I would then adapt CG-5.9.3 to state that the ID to pick *must be* the 
latest on master, before any update and commit.


Cheers,
--
Jean-Charles

Re: Broken commit IDs in French translation

[Jean-Charles Malahieude]

Le 03/11/2022 à 21:31, Jean Abou Samra a écrit :

Hi Jean-Charles,

What is your procedure for filling in commit IDs in translated
files? It looks like a number of them don't exist in the repository.




I either copy what is returned by "git rev-parse HEAD" or then content 
of the "Id SHA1" field  in gitk.


I don't know whats is going wrong.

Re: Backslashes in @warning

[Jean-Charles Malahieude]

Le 19/10/2022 à 17:38, Werner LEMBERG a écrit :

The page

https://lilypond.org/doc/v2.23/Documentation/notation/writing-text.html#text-marks

is missing some backslashes in the box [...]

I don't immediately see what this discrepancy could be caused by,
apart from a bug or limitation of texi2html 1.82.

Can this be worked around somehow?


I can confirm this problem with a local build; it seems indeed to be a
bug in the old texi2html version, which swallows backslashes in
`@warning{...@code{...}...}`.  Alas, I don't know how to fix it.




You just have to "escape" it, like in texidocs:

@code{\\textMark} et @code{\\textEndMark}


I'll prepare a MR later today for text.itely.

Cheers,
--
Jean-Charles

Re: RFC: disconnect from the Translation Project

[Jean-Charles Malahieude]

Le 06/07/2022 à 20:51, Jonas Hahnfeld a écrit :


... which, as far as I understand, is processed by some form of a bot,
right? At least that one message was taken care of *very* quickly...



I have to confess that _I am_ the bot… until the mail announcing new 
releases are directly sent to the FTP as well.


Cheers,
--
Jean-Charles

Re: RFC: disconnect from the Translation Project

[Jean-Charles Malahieude]

Le 06/07/2022 à 13:31, Jean Abou Samra a écrit :

On 7/6/22 11:15, Werner LEMBERG wrote:

The PO template that is the basis for PO files needs to be updated
at every release by notifying the coordinator of the release.
That's a maintenance cost.  Right now, we're not paying it, and the
result is that the PO template any translators would base their work
on is from LilyPond 2.21.7, a year and a half ago.

Hmm.  Jonas regularly updates LilyPond's `.pot` and `.po` files.
Maybe sending them to that robot can be integrated into the release
scripts?



They're not sent to a robot but to a human.



It's a mail addressed to the coordinator of the FTP, see
https://lists.gnu.org/archive/html/lilypond-devel/2020-10/msg00056.html


Have a look at commit 6d84a36fd1dde3fe2035ff17a78672c72f3ab0fc from 10 
years ago.


I acknowledge the FTP once we branch out and prepare a stable release. 
Why not add the FTP-Coordinator to the mails announcing each release, 
and fetch all the updated po in a run with


rsync –Lrtvz translationproject.org:: tp/latest/lilypond/ po

and commit them before making any release? Note that the lilypond.pot 
will always be one step beyond the language files.


Many software acknowledge the FTP only when making a stable RC and not 
at every development release.


Cheers,
--
Jean-Charles

Re: Thinking about the next stable release

[Jean-Charles Malahieude]

Le 26/05/2022 à 18:12, Jean Abou Samra a écrit :



Le 22/05/2022 à 14:39, Jonas Hahnfeld via Discussions on LilyPond 
development a écrit :

Hi all,

with the unstable releases switched over to Guile 2.2, I think it might
be a good idea to think about the next stable release. The last time,
for 2.22.0 in early 2021, we kind of coincidentally aligned with the
Debian freeze timeline for Bullseye. For the next release, Debian 12
"Bookworm", the preliminary freeze plan can be found here:
https://lists.debian.org/debian-devel-announce/2022/03/msg6.html

[...]


I think there's reasonable agreement that this is a
good plan (at least, no objections have been raised).
Now, how do we organize for that? Do you (speaking to
everyone) think we should do some sort of feature freeze
some time before branching, for example? (I have no specific
opinions on those things.)



If you'd prefer to have the documentation duly translated, it is 
preferable to let some time for the job to be accomplished.


Cheers,
--
Jean-Charles

Re: Stepping down from Patch Meister role

[Jean-Charles Malahieude]

Le 08/01/2022 à 12:15, Jonas Hahnfeld via Discussions on LilyPond 
development a écrit :

Am Samstag, dem 08.01.2022 um 10:06 + schrieb James:

Hello,

I am going to stop doing the Patch countdown at the end of this month.

I'll continue for the next few weeks, but my last countdown will be
whatever the last date in January ends up being.

Thanks for your understanding.




Hi James,

Thanks a lot for all you did for helping Lily's development.
Enjoy your new life!

Cheers,
--
Jean-Charles

[Doc] Organizing changes.tely

[Jean-Charles Malahieude]

Hello all,

In the last days of 2017, just before 2.20 was born, James arranged 
changes.tely such that items don't get just stacked one over the other 
but sort of reflect the organizing of the Notation Reference. I found it 
very wise and useful for the reader, and kept that during the 
development of 2.21.


I took care of moving things around with the branching of stable/2.22 
for the English version and the other translators did their duty…

And I've kept it in French for the moment.

What do you think about having a policy about it, since most of the 
change's entries go with an update to other manuals?



Cheers,
--
Jean-Charles

Re: Broken make info dependencies

[Jean-Charles Malahieude]

Le 01/10/2021 à 02:48, David Kastrup a écrit :


And having to build the HTML documentation of all languages when the
Info files only need the images from the English version is not
exactly rewarding either.



When I want to check my work in French, I first run

make doc LANGS='en fr'

in order to limit the build to only the English and French versions.

--
Jean-Charles

Re: [translations] Re: Working repo

[Jean-Charles Malahieude]

Le 05/03/2021 à 15:25, Jonas Hahnfeld a écrit :

Am Donnerstag, dem 04.03.2021 um 19:34 +0100 schrieb Jean-Charles

Even if outside the countdown process, these MR should IMHO still be
reviewed or specifically "tagged" and maybe translators prefix their own
branch with Doc-LL when pending for a while (it took me more than a week
for polishing !671). The CG will have to be adapted.


Sure, we'll need proper procedures. For example, we could have a label
Patch::translation to keep these MRs out of the countdown. However, I'm
not sure how much "review" is appropriate since the translator is
usually the one who can judge best (especially if already part of the
team = push access). Regarding branch names, are there multiple
translators working on the same language? How do they synchronize at
the moment?



Good point! IIRC and except for the "French team" (John, Gauvain, me and 
later Valentin) patches used to be centralized by the "main" translator, 
be it Francisco for Spanish or Federico for Italian before landing on 
the repository, and newcomers were "mentored" by one of us like i did 
with Walter for Catalan -- mainly checking the log-files for bad 
cross-references and giving advises or tips.





The more immediate problem right now is that Savannah is ahead of
GitLab, so once somebody pushes to GitLab the synchronization will fail
because branches cannot be force-pushed to Savannah. Given the issue
with overlong lines, maybe it's best to reset Savannah's translation
branch to the commit on GitLab? I can do this manually if nobody
disagrees.



Please go ahead.


Done, translation on Savannah now equals the branch on GitLab. I have a
copy of the Hungarian translation locally, should that be needed.



Benkő Pál is actually reviewing MR675

Re: [translations] Re: Working repo

[Jean-Charles Malahieude]

Le 04/03/2021 à 18:55, Jonas Hahnfeld a écrit :

[...]

MRs to the translation branch won't work because there are no CI
pipelines defined, but I've configured GitLab to require that prior to
merging. So far, we've mostly continued with the practice that
translators have access to the repository and just push the translation
branch.
Now that we have the MR system fleshed out and sufficiently fast
runners, I think it might be time to retire the translation branch:
Translators would open regular MRs that are merged to master, but
outside of the countdown process. That would also allow "outside"
contributors to work on the translation more easily (cf. !668).



Even if outside the countdown process, these MR should IMHO still be 
reviewed or specifically "tagged" and maybe translators prefix their own 
branch with Doc-LL when pending for a while (it took me more than a week 
for polishing !671). The CG will have to be adapted.




The more immediate problem right now is that Savannah is ahead of
GitLab, so once somebody pushes to GitLab the synchronization will fail
because branches cannot be force-pushed to Savannah. Given the issue
with overlong lines, maybe it's best to reset Savannah's translation
branch to the commit on GitLab? I can do this manually if nobody
disagrees.



Please go ahead.

Cheers,
--
Jean-Charles

Re: Releasing 2.22.0

[Jean-Charles Malahieude]

Le 03/01/2021 à 12:05, Jonas Hahnfeld a écrit :

Hi all and happy new year 2021 to everyone!



A happier new year to everyone !



As there was no real announcement for 2.20.0, I'd rather follow the
release of 2.18.0 including a post to info-lilypond. Here's a first
draft:



OK with me for this new year's gift.

Cheers,
--
Jean-Charles

Re: Welcome to Travis CI!

[Jean-Charles Malahieude]

Le 19/12/2020 à 09:58, Han-Wen Nienhuys a écrit :

Am Donnerstag, dem 17.12.2020 um 11:26 + schrieb Travis CI:

    =  Welcome to Travis CI, GNU
LilyPond (unofficial)!  =


"GNU LilyPond (unofficial)" is the name of the Github organization for
LilyPond, which has only 5 members.

I don't know how this happened. Logging in requires giving Travis an absurd
number of permissions. Let's just ignore it?

On Fri, Dec 18, 2020 at 7:41 PM Jonas Hahnfeld via Discussions on LilyPond
development  wrote:


Hm, so I do use Travis at work, but I hope I didn't click anywhere I
shouldn't and this wasn't me. Does anybody have plans to use Travis?






This might as well be just spam from them since they've changed their 
business model.



Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 26/10/2020 à 19:30, Jonas Hahnfeld a écrit :


Yes, that !347 is quoted in commit d75b86de13 which introduced the
above commit hash. As you were running translation-status in commit
a2f89036bc, I suspected a rebase issue which would have kept the old
commit hash for some time in your local repository.

Of course, all of that doesn't matter after updating the commit hashes
to some value that allows translation-status to succeed ;-)




Juts for the record, with everything updated and pushed to Translation:

===
-*- mode: compilation; default-directory: "~/GIT/Traduc/Documentation/" -*-
Compilation started at Tue Oct 27 16:57:17

make ISOLANG=fr NO_COLOR=1 check-translation > ../../chktrans
warning: fr/search-box.ihtml: 128 fatal: path 
'Documentation/en/search-box.ihtml' does not exist in 'HEAD'


Compilation finished at Tue Oct 27 16:57:20
===

and an empty file for chktrans.
I don't really care about the English search-box that lives one step 
above unlike the translated ones.


So, for now, the only thing that misses is a run of translation-status 
just before releasing.


Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 21/10/2020 à 20:12, Jonas Hahnfeld a écrit :

Am Mittwoch, den 21.10.2020, 20:01 +0200 schrieb Jean-Charles
Malahieude:

since I'm trying to understand why
snippets get translated in 2.21.7 on lilypond.org but not on my box
(I've updated about 250 fr/texidocs and wanted to check how they appear)
and check-translation gives me some strange messages like

warning: fr/essay/engraving.itely: 128 fatal: path
'Documentation/user/engraving.itely' does not exist in
'e9e5be535bfffbd50f33dfce3a8ee47b39e42bb5'

despite the fact I'm sure I was up to date with
d75b86de1363084c28cebde4eea5fe56a657975a on 2020/09/12.


I get the same and see that commit hash in some French manuals, but the
canonical repo doesn't contain it. Maybe it was rebased to another
hash?



Found it: MR344 end MR347 touched both the original and translated 
versions. I suspect this has deeply disturbed (or upset) 
check-translation; I don't remember having seen such thing after 
update-snippets.py or update-with-convert-ly.sh were run.


Cheers,
Jean-Charles

Re: ready for 2.21.80?

[Jean-Charles Malahieude]

Le 26/10/2020 à 12:06, Jonas Hahnfeld a écrit :

[…]
Changing directory before invoking lilypond-book might solve this
problem and help against similar issues in the future:
https://gitlab.com/lilypond/lilypond/-/merge_requests/479

This looks good in preliminary testing, both with separate build tree
and for in-tree compilation. To be sure, I'm currently doing a full
build with GUB. In the mean time, I'll investigate if it would be
feasible to revert !347 without too many conflicts...



Applying MR 479 onto the translation branch work fine: snippets in NR 
are again translated, and snippets.html as well when building in-tree.


Thanks,
--
Jean-Charles

Re: ready for 2.21.80?

[Jean-Charles Malahieude]

Le 25/10/2020 à 19:13, Jonas Hahnfeld a écrit :


I can try to help if I understand the problem in detail. As you mention
the NR, you're probably referring to the Selected Snippets / Morceaux
choisis? The first example would be:
http://lilypond.org/doc/v2.21/Documentation/notation/writing-pitches.fr.html#accidentals
Are you saying that you're seeing the English text instead?



Exactly. And it's the same everywhere. I can't check snippets.html since 
its revival came just this Summer (but it was in French except for the 
menu).



As a translator, you're probably building in-tree without a separate
build directory? I'll test that kind of setup in a second, maybe
there's a problem with that.



I don't remember the reason, but translators were very "annoyed" with 
out-of-tree building.


Thank you for any idea you might dig out!

Re: ready for 2.21.80?

[Jean-Charles Malahieude]

Le 25/10/2020 à 14:42, Jonas Hahnfeld a écrit :

As the title says. We still need to merge the PO translations (see
https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick
them to stable/2.22. If you speak one of the concerned languages that
I've been hijacking the translation for (ca, eo, es, it, nl, sv),
please consider giving it a short look. I'll also merge the translation
branch to stable/2.22 before asking Phil for a release.



Before releasing, it seems like my computer is reluctant to let me read 
the translated texidocs in the NR and I'd like to know why. I don't 
manage to diagnose when this change appeared (docs for 2.21.7 are OK on 
lilypond.org).


Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 24/10/2020 à 17:51, Jonas Hahnfeld a écrit :


I just pushed a reordered version of the English changes.tely to
stable/2.22, compiled HTML version attached.



LGTM.

BTW, your remark about skylines, the changes' entries come from 
different issues dealt by Torsten:


commit 72e9c4c6c313a15f934b58e00cceabc71503b06d
issue #5319: Make skylines reflect grob rotation

commit df0ca89d232ca1811605c0a5acc753b6783d8293
issue 5307: Skyline Refinements (Rounded Boxes and Rotated Ellipses)

The sentence introduced when resolving #5307 might, IMO, go with the 
longer example from #5319.


Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 21/10/2020 à 17:35, Jonas Hahnfeld a écrit :

Hi,

sorry, I forgot to reply here...

Am Samstag, den 17.10.2020, 10:15 +0200 schrieb Jean-Charles
Malahieude:
[...]

>

I'll appreciate anybody first checking I've not not affected a wrong
category.


Some things I noticed after looking at
https://lilypond.org/doc/v2.21/Documentation/changes/index.fr.html:
  - I'd put a few items into a section "Input file improvements":
* "All input languages (\language statement) can be entered using
their proper UTF-8 spelling"
* "The \partcombine command [...] are now written with a capital C"
* Change of relative-include
* Unicode filenames on Windows
  - "Fret-diagrams may now be printed left-handed" probably belongs to
"Unfretted and fretted string instrument improvements"?

A few more general thoughts:
  - There are two entries about skylines taking rotation into account?
  - Some SVG changes were already part of 2.20 (output-classic-
framework, -dclip-systems, -dcrop).

I think we need an English version that we can all take a look at and
iterate on (I live in France since a few weeks, but I certainly don't
know all the French terms for music notation!). Would you be able to
come up with an initial proposal based on your work on the French
version and the above items?



Sure, but not before Saturday night, since I'm trying to understand why 
snippets get translated in 2.21.7 on lilypond.org but not on my box 
(I've updated about 250 fr/texidocs and wanted to check how they appear) 
and check-translation gives me some strange messages like


warning: fr/essay/engraving.itely: 128 fatal: path 
'Documentation/user/engraving.itely' does not exist in 
'e9e5be535bfffbd50f33dfce3a8ee47b39e42bb5'


despite the fact I'm sure I was up to date with 
d75b86de1363084c28cebde4eea5fe56a657975a on 2020/09/12.


Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 16/10/2020 à 20:21, Jonas Hahnfeld a écrit :

Am Freitag, den 16.10.2020, 20:01 +0200 schrieb Jean-Charles
Malahieude:


I should have finished and sent fr.po to the FTP over the week-end.
I'll group the fetching once a week in a MR to master.


I wonder if the translated po files should go via master or directly to
stable/2.22: lilypond.pot will be updated with the next unstable
releases (should that be necessary). But I don't mind either way,
shouldn't pose big problems...



I think po files tagged 2.21.7 should go in both 2.22 and master at the 
same time and, if later amended because of changes in lilypond.pot, 
cherry-picked into master.




I've tried to keep this grouping for the French version, hoping to have
correctly qualified the entries…


Your chance to group the English version the same and make it "correct"
by definition :-D



I'll appreciate anybody first checking I've not not affected a wrong 
category.


Cheers,
--
Jean-Charles

Re: stable/2.22 has branched; master is 2.23.0

[Jean-Charles Malahieude]

Le 16/10/2020 à 19:41, Jonas Hahnfeld a écrit :

Hi all,

I created stable/2.22 as discussed and the situation is as follows:
* b7c2bc5feb (origin/master) Reset Changes document for next cycle
* 7f0bb931c3 Bump VERSION to 2.23.0 for next cycle
| * 8a58e932f8 (origin/stable/2.22) ci: Build branch on push
| * b63a51f52f (origin/translation) Bump VERSION to 2.21.80 for release 
candidates
|/
*   b5de5719b7 Merge branch 'translation' into master

So master is 2.23.0 and usual development can resume, with the pleading
to avoid disruptive changes that make picking harder than necessary.
Fixes should also go to master and I'll pick them to the branch. If you
really need to do that, please use 'git cherry-pick -x' to record the
original hash.



Thanks, Jonas!

I should have finished and sent fr.po to the FTP over the week-end.
I'll group the fetching once a week in a MR to master.


translation builds on stable/2.22 and must only be merged there.
Attempting a merge into master should give conflicts in VERSION, but
please don't try at home ;-)

In the past releases, the Changes document was grouped into subheadings
instead of a list. If anyone volunteers this time, please speak up.



I've tried to keep this grouping for the French version, hoping to have 
correctly qualified the entries…


Cheers,
--
Jean-Charles

lilypond-2.21.7

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://lilypond.org/download/source/v2.21/lilypond-2.21.7.tar.gz


Cheers,
--
Jean-Charles Malahieude

Re: internationalized snippets

[Jean-Charles Malahieude]

Le 13/09/2020 à 12:30, Han-Wen Nienhuys a écrit :

Jean (or should I say Jean Abou?) found the following gem:

  
https://github.com/lilypond/lilypond/blob/a2f89036bc6ed0147385ef04d1201cad3ad10fa7/python/book_snippets.py#L368

I think the problem was introduced in

   
https://gitlab.com/lilypond/lilypond/-/commit/d4a36739fbf2b85e3a6c85fdf76b482b8c07b656

from May 2010.  This means that the support for internationalized
snippets through gettext on variables and comments hasn't worked in
over 10 years (and nobody noticed?). To me this seems like a strong
signal that we should get rid of this feature.

thoughts?



I think most translators noticed this when it appeared, but without 
anybody tackling it. And it used to work fine and was valuable for 
non-native English speaker.


The advantages were:

– variables and comments appeared translated, eventually combined to the 
title (doctitleLL) and explanation (texidocLL). I consider it 
unfortunate when explanations are given through comments within the code.


– lesser use of @KEEPLY before @lilypond – CG 5.9.2 states:
"Please keep verbatim copies of music snippets (in @lilypond blocs). 
However, some music snippets containing text that shows in the rendered 
music, and sometimes translating this text really helps the user to 
understand the documentation; in this case, and only in this case, you 
may as an exception translate text in the music snippet, and then you 
must add a line immediately before the @lilypond block, starting with


@c KEEP LY

Otherwise the music snippet would be reset to the same content as the 
English version at next make snippet-update run."

Re: Side effects of MR 84 with scripts

[Jean-Charles Malahieude]

Le 09/08/2020 à 13:12, Han-Wen Nienhuys a écrit :

On Sun, Aug 9, 2020 at 12:44 PM Han-Wen Nienhuys  wrote:


make translation-status

translations-status.py
Reading documents...
Generating status pages...
translations-status.py:717: warning: using markup = TexiMarkup (): ugly
HTML
  output, questionable PDF and info output.
  Consider using HTML-only markup = HTMLMarkup ()
Traceback (most recent call last):
File
"/home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py",
line 817, in 
  open(os.path.join(l, 'en/translations.itexi'),
'w').write(lang_status_page)
FileNotFoundError: [Errno 2] No such file or directory:
'ca/en/translations.itexi'
make: *** [GNUmakefile:483: translation-status] Error 1




thanks; there was a straightforward problem that I have a fix for, but now
I get

  Traceback (most recent call last):
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 782, in 
 master_docs = [MasterTelyDocument(os.path.normpath(filename))
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 782, in 
 master_docs = [MasterTelyDocument(os.path.normpath(filename))
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 669, in __init__
 [(lang, self.translated_factory(os.path.join(lang, self.filename),
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 669, in 
 [(lang, self.translated_factory(os.path.join(lang, self.filename),
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 682, in translated_factory
 return TranslatedTelyDocument(filename, self, parent)
   File "/home/hanwen/vc/lilypond/scripts/auxiliar/translations-status.py",
line 419, in __init__
 self.translation = translation[self.language]
TypeError: 'set' object is not subscriptable


which was apparently caused by

14f96a55304d4133a02e5669a56d371a79ac62b8 is the first bad commit
commit 14f96a55304d4133a02e5669a56d371a79ac62b8
Author: Jean Abou Samra 
Date:   Sun Jul 12 17:38:42 2020 +0200

 Python cleanup (V): Clean up langdefs.py

Sorry that I haven't participated enough with it.





no worries, the documentation build is too complicated for its own good. I
wouldn't blame anyone who wants to stay away from it.



Not being a developer often doesn't help much…


MR321 is OK for me.
Thanks for having resolved the problem.

Cheers,
--
Jean-Charles

Side effects of MR 84 with scripts

[Jean-Charles Malahieude]

Hi all,

I wanted to tackle updating the French version of the NR, but

cd Documentation
make ISOLANG=fr NO_COLOR=1 check-translation > ../../chktrans

reveals that all files have been deleted. Sure! they have moved into a 
dedicated directory.



And running translation status  gives

-*- mode: compilation; default-directory: "~/GIT/Traduc/Documentation/" -*-
Compilation started at Sun Aug  9 12:16:10

make translation-status
translations-status.py
Reading documents...
Generating status pages...
translations-status.py:717: warning: using markup = TexiMarkup (): ugly HTML
output, questionable PDF and info output.
Consider using HTML-only markup = HTMLMarkup ()
Traceback (most recent call last):
  File 
"/home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py", 
line 817, in 
open(os.path.join(l, 'en/translations.itexi'), 
'w').write(lang_status_page)
FileNotFoundError: [Errno 2] No such file or directory: 
'ca/en/translations.itexi'

make: *** [GNUmakefile:483: translation-status] Error 1


Sorry that I haven't participated enough with it.

Cheers,
--
Jean-Charles

Re: Access request to push to translation

[Jean-Charles Malahieude]

Le 21/06/2020 à 13:53, Jonas Hahnfeld a écrit :

Am Sonntag, den 21.06.2020, 13:20 +0200 schrieb Han-Wen Nienhuys:

BTW, regarding translations:

I notice that translation work gets merged as

"commit cb1b3c1fb0c1d9dc1fb6fdadb0907c07b8a692e5
Merge: 22eca98efe b47e5def69
Author: Jean-Charles Malahieude 
Date:   Sat Jun 20 17:44:05 2020 +0200

 Merge branch 'master' into translation"


could we flip the merge order? The history view in gitk now makes it
look as if 'translation' is the main development branch, while
'master' gets merged in from the side.


+1, that's also what CG will recommend once the updated version is
online. (I did it wrong myself when doing the first merge, and figured
out later that the other order makes more sense.)



For the record, here is how I've proceeded, since one can't directly 
push "master":


0- pull "translation" and "master", and checkout "translation"
1- merge "master" into translation, with git-gui
2- download sv.po from the FTP
3- just to be sure, run
   ./autogen.sh && make -j5 && make -j5 doc
4- pull again "master" and merge it into "translation"
5- push "translation"
6- log in at Gitlab
7- open a MR form "translation" into "master"

I think we, translators, need precise, concise and useful directives on 
how to proceed if the way we've followed since LilyPond uses git must 
evolute and that might read:


0- pull "master"
1- create and checkout "translation-LL"
2- elaborate the dishes (one commit per manual, at least)
3- push "translation-LL"
4- log in at Gitlab
5- open a MR from "translation-LL" into "mater"
6- delete "translation-LL"

Please let me know, I'm beginning to get lost.

Cheers,
--
Jean-Charles

convert-ly doesn't find lilylib

[Jean-Charles Malahieude]

Hi,

with master as of 15de2c8874262c2c0a9f2cc3beee5070c766dde4


$ cat buggy.ly
\version "2.18.2"
c1

$ ~/GIT/Mentor/out/bin/convert-ly -e TEST.ly
Traceback (most recent call last):
  File "/home/jcharles/GIT/Mentor/out/bin/convert-ly", line 65, in 
import lilylib as ly
ModuleNotFoundError: No module named 'lilylib'
$

Cheers,
--
Jean-Charles

Re: migrating to GitLab

[Jean-Charles Malahieude]

Le 10/05/2020 à 10:50, Jonas Hahnfeld a écrit :

Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:

On May 9, 2020, at 15:13, David Kastrup  wrote:

Carl Sorensen  writes:

->CS At any rate, I think that we should have appropriate CG
instructions at the time we make the switch.  They don't have to be
perfect (the CG has a much lower editing bar than the NR), but they
need to be in place, IMO.


It's sort of a hen and egg problem: if we want to have all that before,
it increases the workload for those preparing the migration and they
have to guess.

I totally agree that the CG should reflect the new workflows.  But at
the time we do the switch, those new workflows are still in flux.


I understand Carl's perspective, but I'm on the side of jumping in.  I don't 
expect that we'll be inundated with newbie contributors between now and the 
time we figure out what to put in the CG.

Maybe we could put in a minimal note referring to the project on GitLab and 
explaining that a more thorough CG revision is pending.


Sure, I can prepare such update. But as written roughly the same time
yesterday, we need to release 2.21.2 in order for that to be uploaded.

In any case it's not clear to me whether I should prepare for the
migration today or not. This would be less frustrating if other high-
volume developers (including but not limited to David, Han-Wen, Werner)
commented on the plan...



It's fine with me. The only thing I'll have to know is how I should 
adapt my ./git/remotes file to ping the right repo


** traduc **
URL: ssh://my_u...@git.savannah.gnu.org/srv/git/lilypond.git/
Push: translation:refs/heads/translation
Pull: translation:refs/remotes/origin/translation
** EOF **

and have "$ git pull traduc" work as usual since 2009.

Cheers,
--
Jean-Charles

Re: migrating to GitLab

[Jean-Charles Malahieude]

Le 08/05/2020 à 08:57, Jonas Hahnfeld a écrit :

I haven't heard further objections which, for me, means we are going
with GitLab. If you don't agree, now's your final time to speak up.
Otherwise I would like to tackle the migration rather soon to take
advantage of the new opportunities :-)

This leads me to some final considerations:
[...]

3) The idea is to have the "main" repository at GitLab, next to the
issues and merge requests. This leads to the question what to do with
Savannah because git is distributed anyway. I first thought about only
pushing "important" branches and tags to GitLab (master, stable/*,
release/*). Switching platforms would actually be one of the few
opportunities to do so - in particular tags are hard to get rid of.
However most of us are probably going to reuse their local repository,
just updating the URL. While GitLab has options to prevent pushing
certain refs, that's probably not a great idea. So I guess I'll just
push an identical copy to GitLab unless somebody has a better proposal.



Please don't forget the translation branch. BTW, will the merry-go-round 
(master->translation->staging) have to be played the same way?


Cheers,
--
Jean-Charles

Re: Annoying 'langdefs.py' warning

[Jean-Charles Malahieude]

Le 26/04/2020 à 09:46, Jonas Hahnfeld a écrit :

Am Samstag, den 25.04.2020, 21:53 +0200 schrieb Francisco Vila:

El 24/4/20 a las 17:18, Jonas Hahnfeld escribió:

However I'm pretty sure that many translations in the latter are dead:
As far as I understand we don't translate the docs by putting the
strings in Documentation/po, but rather by copying the files and
translating them below Documentation/lang.


Documentation/po/'lang'.po used to work as a way to get comments in
verbatim code translated. In a certain point of time it stopped working.
This is what I'd like to see improved.


My patch leaves all the infrastructure and existing translations in
place if somebody (not me) wants to make this work again. However
please keep in mind that translating snippets will render 'make doc'
even slower because it has to compile them for every language instead
of once.



Thanks for letting the infra in place.

If you read AU 3.3, you'll see:
"If you would like to translate comments and variable names in verbatim 
output but not in the sources, you may set the environment variable 
LYDOC_LOCALEDIR to a directory path; the directory should contain a tree 
of ‘.mo’ message catalogs with lilypond-doc as a domain."


So to say, the snippet is not generated multiple times. Only the 
verbatim part gets rendered in the language specified in the header of 
the .*texi/.*tely file. And it worked smoothly until some day during the 
year 2010 (I've got an OK 2.13.1 tarball of the docs dated 2009/05/01, a 
KO 2.13.45 from 2011/01/03 and the 2.12.3 (2010/01/13) on the download 
site is OK).




Still, translations for the
footer in HTML pages appear to be used (like "Other languages:" and
"About automatic language selection"). Whoever is interested in
improving this situation is more than welcome!


Any improvements here should not prevent anyone of seeing every page in
all other languages if he wants to, I think.


Agreed, that should stay the way it is. Actually I wanted to express
that just deleting the files would break existing functionality that is
actually useful to have.



What makes me wonder is that "texidoc" end "doctitle" are honored as 
opposed to the "gettextification" (even when forcing a full path for 
LYDOC_LOCALEDIR in my .bashrc end commenting out the line in 
make/lilypond-vars.make). It might be a side effect from Reinhold's 
patches from June 2010 that makes LYDOC_LOCALEDIR not honored.


I'll try to build a test case tomorrow.

Cheers,
--
Jean-Charles

lilypond-2.21.1

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://lilypond.org/download/source/v2.21/lilypond-2.21.1.tar.gz


Cheers,
--
Jean-Charles Malahieude

Re: Annoying 'langdefs.py' warning

[Jean-Charles Malahieude]

Le 19/04/2020 à 16:17, Valentin Villenave a écrit :

On 4/16/20, Werner LEMBERG  wrote:

Building lilypond you get a bunch of harmless but annoying
   langdefs.py: warning: lilypond-doc gettext domain not found.
and
   .../podir-targets.make:14: warning: ignoring old recipe for target
'po-update'
messages.  Is there a way to suppress them?


Hi Werner,
I’ve been annoyed by these for quite some time as well. Is it worth
opening a tracker page?



I've tried to understand how it comes, but with no success.
I think John had a good reason for it back in 2008 when creating the 
infrastructure for translated web and docs.


Cheers,
--
Jean-Charles

Failing build

[Jean-Charles Malahieude]

Hi,

Wishing to merge back translation into master, I first want to have 
everything fine but, with HEAD at


2f4b432c66 framework-svg.scm: Fix 'style' tag

and nothing wrong with autogen, I get

make VERBOSE=1
# Making out/VERSION
mkdir -p ./out
echo 2.21.1 > out/VERSION
# Making out/share/lilypond/current/lilypond-force
cd /home/jcharles/GIT/Devel/out && rm -rf bin lib share
mkdir -p ./out/bin
mkdir -p ./out/share/lilypond/current
mkdir -p ./out/lib/lilypond/current
mkdir -p ./out/share/lilypond/current/elisp
mkdir -p ./out/share/lilypond/current/fonts
mkdir -p ./out/share/lilypond/current/fonts/otf
mkdir -p ./out/share/lilypond/current/fonts/svg
mkdir -p ./out/share/lilypond/current/fonts/enc
mkdir -p ./out/share/lilypond/current/tex
cd ./out/bin && \
ln -sf ../../lily/out/lilypond . && \
	for i in abc2ly convert-ly etf2ly lilymidi lilypond-book 
lilypond-invoke-editor midi2ly musicxml2ly; \

do ln -sf ../../scripts/out/$i . ; done
cd ./out/lib/lilypond/current && \
ln -s ../../../../python/out python
cd ./out/share/lilypond/current && \
ln -s /home/jcharles/GIT/Devel/ly ly && \
ln -s ../../../../mf mf && \
ln -s /home/jcharles/GIT/Devel/ps && \
ln -s ../../../../python/out python && \
ln -s /home/jcharles/GIT/Devel/scm && \
ln -s /home/jcharles/GIT/Devel/scripts scripts
cd ./out/share/lilypond/current/tex && \
ln -s /home/jcharles/GIT/Devel/tex source && \
ln -s ../../../../../tex/out tex-out && \
true
cd ./out/share/lilypond/current/fonts && \
ln -s /home/jcharles/GIT/Devel/mf source && \
true
cd ./out/share/lilypond/current/elisp && \
ln -sf ../../../../../elisp/out/lilypond-words.el . && \
ln -s /home/jcharles/GIT/Devel/elisp/*.el .
true
touch ./out/share/lilypond/current/lilypond-force
make -C python
make[1]: Entering directory '/home/jcharles/GIT/Devel/python'
# Making python/out/rational.pyc.dummy (py compile)
# Do not use buildscript-dir, this has not been traversed yet.
cd ./out && /usr/bin/python -tt 
/home/jcharles/GIT/Devel/scripts/build/compile.py rational.py

Traceback (most recent call last):
  File "/home/jcharles/GIT/Devel/scripts/build/compile.py", line 17, in 


py_compile.compile (src, cfile=cfile, doraise=True)
  File "/usr/lib64/python3.7/py_compile.py", line 141, in compile
source_bytes = loader.get_data(file)
  File "", line 916, in get_data
FileNotFoundError: [Errno 2] No such file or directory: 'rational.py'
make[1]: *** [GNUmakefile:14: out/rational.pyc.dummy] Error 1
make[1]: Leaving directory '/home/jcharles/GIT/Devel/python'
make: *** [GNUmakefile:198: build-scripts] Error 2

Re: OT: maillist changes width, messes lines

[Jean-Charles Malahieude]

Le 30/03/2020 à 17:31, Francisco Vila a écrit :
At some point in the email path from sender to recipients, our list 
incorrectly word wraps some long lines. See attachment. It's in the 
actual email code, too.


I was pretty much ignoring it until I couldn't help reading

   "Anything and rather sake uses from"

which clearly tends to distort the message.


It happens mostly when it comes from Rietveld. What I do in such case is 
opening the discussion directly on codereview.appspot.


Cheers,
--
Jean-Charles

Re: [translations] Anything missing for 2.21.0?

[Jean-Charles Malahieude]

Le 29/03/2020 à 18:59, David Kastrup a écrit :

Jean-Charles Malahieude  writes:


But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr,
it, ja, nl, sv) which are in advance on stable/2.20. As I work on
local clones (one per branch), I can copy them and push onto staging
(they come from different commits and with some overwrites) if you
mind.


I'd be happy for you to do this since I don't have an idea how
stable/devel play out with regard to the po files.



Done as f4ee267ae276d02779dac178b825b55cd67510b6 on staging.

Pizza just out of the oven, have to go for it.

Cheers,
--
Jean-Charles

Re: [translations] Anything missing for 2.21.0?

[Jean-Charles Malahieude]

Le 29/03/2020 à 17:54, David Kastrup a écrit :


[Repeat message since I got the address of translations wrong]

I see that translation-status is in master.  The web site is still
getting fixed (including MacOSX download links), so we'd probably better
wait with the big announcements until that is there.

But roll the release?  It's just the first unstable in a series anyway.

Anybody can think of a holdup?




If you mean issue 5867, I'd consider it's not worth having another 
Mary-go-round (master->translation->staging->master) just for this; 
let's adapt translation at the next round.


But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr, 
it, ja, nl, sv) which are in advance on stable/2.20. As I work on local 
clones (one per branch), I can copy them and push onto staging (they 
come from different commits and with some overwrites) if you mind.


Cheers,
--
Jean-Charles

Re: 2.21.0 and announcements

[Jean-Charles Malahieude]

Le 26/03/2020 à 18:38, David Kastrup a écrit :

Jean-Charles Malahieude  writes:


Would you mind letting me run translation-status and merge updated
docs from Franscisco and myself into staging?


I would not mind at all.  In fact, I'd have planned to do so myself, but
certainly would be glad for you to do it.



Done and pushed.

Please don't forget to cherry-pick from stable/2.20 the updated po files 
before the release process, otherwise the work will get lost (ca, da, 
de, eo, es, fr, it, ja, nl, sv).


Cheers,
--
Jean-Charles

Re: 2.21.0 and announcements

[Jean-Charles Malahieude]

Le 26/03/2020 à 17:11, David Kastrup a écrit :


Because once the big announcements are made, we want people to actually
be able to work with what they find on the web page.

We can release 2.21.0 prior to that, of course, since the web page
updates are (I think) independent from releases.



Would you mind letting me run translation-status and merge updated docs 
from Franscisco and myself into staging?


Cheers,
--
Jean-Charles

AU-1.2 Relocation

[Jean-Charles Malahieude]

Hi Werner,

On my way to updating the French documentation, I read in running.itely 
(1st item of  Relocation algorithm)


"Compute the directory where the currently executed
@command{lilypond} binary is located.  Let's call this
@code{bindir}.  Set (internal) environment variable
@code{INSTALLER_PREFIX} to @file{@var{bindir}/..} (i.e., the
parent directory of @code{bindir})."

I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up in 
the genealogy).


Would you mind confirming my assumption?
If "../bindir" is the right spelling, I'll change it on Translation's 
branch and it will be merged into staging afterwards.


Cheers,
--
Jean-Charles

Re: make builds everything

[Jean-Charles Malahieude]

Le 21/03/2020 à 18:11, Malte Meyn a écrit :

Hi list,

first of all, I’d like thank those who made the make output less 
verbose, this makes errors much easier to find. 


It is, unfortunately, sometimes too little verbose: say I've omitted a 
closing brace in a texinfo @-command. The only thing I get is


[…]
Making Documentation/fr/out-www/translation-lily-images (hard links)

Please check the logfile

  /home/jcharles/GIT/Traduc/Documentation/fr/notation.texi2pdf.log

for errors

make[3]: *** 
[/home/jcharles/GIT/Traduc/stepmake/stepmake/texinfo-rules.make:85: 
out-www/notation.pdf] Error 1

make[3]: *** Deleting file 'out-www/notation.pdf'
make[2]: *** 
[/home/jcharles/GIT/Traduc/stepmake/stepmake/generic-targets.make:167: 
WWW-1] Error 2
make[1]: *** 
[/home/jcharles/GIT/Traduc/stepmake/stepmake/generic-targets.make:167: 
WWW-1] Error 2
make: *** 
[/home/jcharles/GIT/Traduc/stepmake/stepmake/generic-targets.make:185: 
doc-stage-1] Error 2


Compilation exited abnormally with code 2 at Mon Mar 23 14:40:40
[end of terminal output]

and at the bottom of notation.texi2pdf.log

[919][920][921][922]
4893652 bytes written
/usr/bin/texi2dvi: 
/home/jcharles/GIT/Traduc/scripts/build/out/xetex-with-options exited 
with bad status, quitting.


As I've updated some files, I would have preferred the old way
instead of, like with .ly files, trying to obtain a MWE !

How would it be possible to access the Nirvana, or to reinstate some 
verbosity in this case, with:


[484][485][486]
2455109 bytes written

/home/jcharles/GIT/Stable/Documentation/fr/out-www/notation/world.texi:53: 
Emer

gency stop.

   @par
l.53


Cheers,
--
Jean-Charles

Re: Upgrading to current makeinfo

[Jean-Charles Malahieude]

Le 14/03/2020 à 21:34, Torsten Hämmerle a écrit :

Apart from the fact that it's super-inelegant, you can use raw code within
your @ifhtml branch to get a real superscript even in HTML, as in:


… and fastidious in matter of typing,and don't forget to add a space 
before the next word:


@ifnothtml
256@sup{e}, 512@sup{e} et 1024@sup{e}
@end ifnothtml
@ifhtml
@html
256e, 512e et 1024e
@end html
@end ifhtml
 de soupir,


Thanks for the tip!
--
Jean-Charles

Re: Upgrading to current makeinfo

[Jean-Charles Malahieude]

Le 31/08/2019 à 21:11, Werner LEMBERG a écrit :


To have both `!' and `\!' (and similar `\foo' command and `foo'
property entries) in the index of the info and PDF version of the NR
it is necessary to tag corresponding entries with `@sortas'
directives[*]

   https://sourceforge.net/p/testlilyissues/issues/5551/
   https://sourceforge.net/p/testlilyissues/issues/5552/

`@sortas' was introduced in texinfo 6.1 (released in 2016); I would
thus like to upgrade the minimum version of texinfo to version 6.1
accordingly.  Note that we already use version 6.1 in gub.

Objections?


 Werner


[*] Currently, HTML output is handled by an ancient version of
 `texi2html' that doesn't understand `@sortas' at all; I'm going to
 add a dummy macro replacement to fix that.  As a consequence, the
 index of the HTML output will stay inferior to both the info and
 PDF versions until we upgrade to a recent version of `texi2any'.
 Unfortunately, this is quite a difficult task...



Furthermore, texi2html doesn't honor French typographic rules regarding 
ordinals: you can't use @sup{letter} like 1^er for 1st and I have to type


@ifnothtml
256@sup{e}, 512@sup{e} et 1024@sup{e}
@end ifnothtml
@ifhtml
256e, 512e et 1024e
@end ifhtml


Cheers,
--
Jean-Charles

PO: reverse from stable to master

[Jean-Charles Malahieude]

Hi David,

Would you mind cherry-picking the updated translation of po-files from 
stable/2.20 into master, in order for us not to redo what is up-to-date?


It concerns

98c40be14709b8ca367f7940cd6d2f760f86a275
PO: fetch French and Italian from FTP

940cfe021fed3c981464c9d4bb6f0f1fbdd4ebe6
PO: fetch Japanese from FTP

69260c169c7071bb83eca78b54ef509ea78d059a
PO: fetch Spanish and Dutch from FTP

and
5628d2d678d929202d6051e6821880331251ab6d
PO: fetch German from FTP


I'll acknowledge the FTP when 2.21 wil be backed out.


Cheers,
--
Jean-Charles

Re: translations-status.py crashes

[Jean-Charles Malahieude]

Le 10/03/2020 à 14:50, Jonas Hahnfeld a écrit :

The fix for this problem is here:
https://sourceforge.net/p/testlilyissues/issues/5839/


Now in staging.
Also many thanks to James for providing immediate feedback that I
didn't break anything unintentionally - much appreciated!



Thanks a lot. Now master has been merged into translation, the 
"translation status" pages are up to date, and translation has been 
merged into staging.


Time for us translators to show "translated" and "up to date" almost 
everywhere.


Cheers,
--
Jean-Charles

translations-status.py crashes

[Jean-Charles Malahieude]

Hi,

Another problem with switching to Python 3:

cd Documentation && make translation status

crashes on branch translation (after merging master into it); it works 
well as expected on transaltion-staging (still on Python 2).


the message is

-*- mode: compilation; default-directory: "~/GIT/Traduc/Documentation/" -*-
Compilation started at Mon Mar  9 20:09:53

make translation-status
translations-status.py
Traceback (most recent call last):
  File 
"/home/jcharles/GIT/Traduc/scripts/auxiliar/translations-status.py", 
line 109, in 

appendix_number_trans = string.maketrans ('@ABCDEFGHIJKLMNOPQRSTUVWXY',
AttributeError: module 'string' has no attribute 'maketrans'
make: *** [GNUmakefile:400: translation-status] Error 1

Compilation exited abnormally with code 2 at Mon Mar  9 20:09:54


Cheers,
--
Jean-Charles

Re: Doc: organize changes.tely

[Jean-Charles Malahieude]

Le 09/03/2020 à 19:09, David Kastrup a écrit :

Francisco Vila  writes:


El 9/3/20 a las 11:58, David Kastrup escribió:

I think I was told to run the update script and forgot.  I am not sure
where to run it now in order to get the results somewhere.


do

   make translation-status

from Documentation/ .

Then commit changes to

   contributor/doc-translation-list.itexi
   translations.itexi
   LL/translations.itexi for each LL language


Which branch do I run make translation-status in?  Which branch do I
commit the results to?



Do it on translation-staging and cherry-pick on stable/2.20, I'll take 
care of translation and master.


Cheers,
--
Jean-Charles

Re: [translations] Changes section in stable

[Jean-Charles Malahieude]

Le 09/03/2020 à 18:21, Francisco Vila a écrit :

Anyway. I expected wrongly to see translated es/changes showing
online, but this will only happpen when the second stable minor
version occurrs. Right?



Wrong! translation has to be merged into master and then the website 
regenerated.


And I'm about to first merge master into translation (you'll have one 
more item in changes.tely BTW).


Cheers
--
Jean-Charles

Re: check_translation crashes

[Jean-Charles Malahieude]

Le 08/03/2020 à 18:33, Jonas Hahnfeld a écrit :

Am Sonntag, den 08.03.2020, 18:29 +0100 schrieb Jean-Charles
Malahieude:

It might be useful in other places as well, I don't know.


What do you mean? I hope I got most other scripts covered. Please let
me know if I missed other as well.



It's just that I now see some python files with a line "# -*- coding: 
utf-8 -*-" and some other without. But I don't know the implications.


Cheers,
--
Jean-Charles

Re: Doc: organize changes.tely

[Jean-Charles Malahieude]

Le 08/03/2020 à 18:34, pkx1...@posteo.net a écrit :
The sectioning was done based on (sort of) how the NR is organized and I 
thought it would be more useful for users to search for something based 
on its type of enhancement/change than just in the order the changes 
were added.




And it was a smart idea and a real enhancement IMO, even if no @node nor 
menu in html.


Cheers,
--
Jean-Charles

Re: check_translation crashes

[Jean-Charles Malahieude]

Le 08/03/2020 à 18:16, Jonas Hahnfeld a écrit :

Am Samstag, den 07.03.2020, 11:27 +0100 schrieb Jean-Charles
Malahieude:

Hi all,

As I'm done with the French translations for 2.20, I'd like to now take
care of 2.21 but… my workflow is now broken and I'm not able to diagnose
what's wrong. The only change in the body of check_translation.py since
2009 has been introduced with issue 5646. A "python --version" gives 3.7.6.


Yes, that's fallout from the switch to Python 3  please apply the one
-liner from https://sourceforge.net/p/testlilyissues/issues/5838/. If
that also works on your system, I'll likely super-fast-track this.



YES! works like a charm! 187 Ko like the one Franciso sent me privately 
yesterday night.


It might be useful in other places as well, I don't know.

Thanks,
--
Jean-Charles

Doc: organize changes.tely

[Jean-Charles Malahieude]

Hi all,

Purging the French version of changes.tely, came to my mind it might be 
wise to avoid moving around and re-organize items like James did in late 
2017 when preparing for a new major release (and translators afterwards) 
and have it structured on the fly. This was the first time for those 
News to be categorized, but I think it's worth it. For the record, here 
is James "sectioning":


*New for musical notation
 -Displaying pitch improvements
 -Rhythm improvements
 -Expressive mark improvements
 -Repeat notation improvements
 -Staff notation improvements
 -Editorial annotation improvements
 -Text formatting improvements
*New for specialist notation
 -Vocal music improvements
 -Unfretted and fretted string instrument improvements
 -Chord notation improvements
*New for input and output
 -Input structure improvements
 -Titles and header improvements
 -Input file improvements
 -Output improvements
 -MIDI improvements
 -Extracting music improvements
*New for spacing issues
 -Page breaking improvements
 -Vertical and Horizontal spacing improvements
*New for changing defaults
*New for Internal interfaces and functions

Cheers,
--
Jean-Charles

check_translation crashes

[Jean-Charles Malahieude]

Hi all,

As I'm done with the French translations for 2.20, I'd like to now take 
care of 2.21 but… my workflow is now broken and I'm not able to diagnose 
what's wrong. The only change in the body of check_translation.py since 
2009 has been introduced with issue 5646. A "python --version" gives 3.7.6.


Here is the output on the transalation-staging branch (reflecting 
stable/2.20):


-*- mode: compilation; default-directory: 
"~/GIT/Doc-Stable/Documentation/" -*-

Compilation started at Sat Mar  7 10:48:28

make ISOLANG=fr NO_COLOR=1 check-translation > ../../chktrans
langdefs.py: warning: lilypond-doc gettext domain not found.

Compilation finished at Sat Mar  7 10:48:30


And on translation (reflecting master):

-*- mode: compilation; default-directory: "~/GIT/Traduc/Documentation" -*-
Compilation started at Sat Mar  7 10:14:19

make ISOLANG=fr NO_COLOR=1 check-translation > ../../chktrans
Traceback (most recent call last):
  File 
"/home/jcharles/GIT/Traduc/scripts/auxiliar/check_translation.py", line 
168, in 

main ()
  File 
"/home/jcharles/GIT/Traduc/scripts/auxiliar/check_translation.py", line 
165, in main

do_file (i, list(langdefs.LANGDICT.keys ()))
  File 
"/home/jcharles/GIT/Traduc/scripts/auxiliar/check_translation.py", line 
96, in do_file

sys.stdout.write (diff_string)
TypeError: write() argument must be str, not bytes
make: *** [GNUmakefile:393: check-translation] Error 1

Compilation exited abnormally with code 2 at Sat Mar  7 10:14:19

Any help in resolving this will be really mostly appreciated.

Cheers,
--
Jean-Charles

Re: Getting download sizes right: proof of concept

[Jean-Charles Malahieude]

Le 26/02/2020 à 02:18, David Kastrup a écrit :



Anybody want to see what it takes to get this across the finishing line?



Just a nitpick: the sizes are in Documentation/web/manuals.itexi.
I'll have a look this afternoon.

Cheers,
--
Jean-Charles

Re: testing out Docker CI scripts?

[Jean-Charles Malahieude]

Le 23/02/2020 à 16:38, David Kastrup a écrit :

Why wouldn't either of you be using the CPU_COUNT= ... environment
variable for letting lilypond-book run parallel jobs of lilypond ?



I forgot to mention that I've a
Traduc (translation)]$ cat local.make
CPU_COUNT = 4

Re: testing out Docker CI scripts?

[Jean-Charles Malahieude]

Le 23/02/2020 à 15:56, Han-Wen Nienhuys a écrit :

On Sun, Feb 23, 2020 at 11:44 AM Han-Wen Nienhuys  wrote:

and initially it is working as expected (4 cpus.)

11:12:40 3.23  Making Documentation/out-www/music-glossary.pdf < texi
11:12:41 3.30  Making Documentation/out-www/notation.pdf < texi
11:12:47 3.43  Making Documentation/out-www/snippets.pdf < texi

but later in the process, I get

11:17:54 2.07  Making Documentation/de/out-www/notation.pdf < texi
..
11:18:46 1.85  Making Documentation/es/out-www/notation.texi < tely
11:19:25 2.51  Making Documentation/es/out-www/learning.texi < tely

ie. the build process for other languages is leaving ~2 CPUs idle, for
about 15 minutes. This means it should be doable to shave off 7.5
minutes off the make doc build.


I should have taken more detailed notes on the first runtime.

I tried some more work with parallelization, which yields an overall
runtime of 36m, which shows that I haven't been able to disprove
David. It's a ~5 min improvement. Probably we should look more deeply
into making lp-book not be exclusive.

15:17:11 2.73  Making Documentation/de/out-www/learning.pdf < texi
15:17:17 2.91  Making Documentation/de/out-www/notation.pdf < texi
..
15:18:13 2.26  Making Documentation/es/out-www/learning.texi < tely
15:18:14 2.26  Making Documentation/es/out-www/notation.texi < tely

real 36m12.256s
user 79m24.432s
sys 10m36.464s

For posterity, during the lp-book processing for doc/web, lilypond is
busy at about 40%. The rest presumably goes to ghostscript and image
scaling.

Compared to just the regtests, that is 2.5x more files and 2.5x more
expensive processing = 6x more expensive overall. Since the regtest
completes in about 3 minutes, the equivalent for "make doc" would be
18 mins. So we still are missing a factor two. It looks like the poor
parallelism of the build process can explain that remaining factor.




FWIW, on my Fedora31 box, Intel® Core™ i5-4440 CPU @ 3.10GHz with 8 Gigx 
of RAM, on the translation branch as of 
5149cf967a8b9f5c01696a3bd994c5ca6f2fa473 (Fix some dead links in German 
documentation):


-*- mode: compilation; default-directory: "~/GIT/Traduc/" -*-
Compilation started at Sun Feb 23 12:14:23

./autogen.sh && make -j5 && make -j5 doc
[…]
make[1]: Leaving directory '/home/jcharles/GIT/Traduc'

Compilation finished at Sun Feb 23 12:46:46

Re: [translations] 2.20 and 2.21 release plans

[Jean-Charles Malahieude]

Le 17/02/2020 à 13:25, David Kastrup a écrit :


Ok, I think 2.20 is basically done and we should push it out by the end
of this week.  This leaves a few days for the translation team to catch
up with the current state.

In particular HINT HINT HINT it gives the opportunity to native speakers
of languages not as meticulously maintained as the currently most active
translations to at least tackle the Changes document and maybe check a
few other points of the web presence.  This is more addressed to people
reading this announcement on the lilypond-devel list than to lurkers on
the translations list, though of course the latter would be equally
welcome.



I've planned to merge translation into stable on Thursday night, with 
the French part fully updated (lots of work with Werner's indexing).


Cheers,
--
Jean-Charles

Re: lilypond.org now serving HTTPS

[Jean-Charles Malahieude]

Le 13/02/2020 à 15:10, Han-Wen Nienhuys a écrit :

FYI, lilypond.org is now serving on HTTPS

See here https://codereview.appspot.com/559470043/ for background.



This should be applied on stable/2.20 as well.

Cheers,
--
Jean-Charles

Re: lilypond-2.19.84

[Jean-Charles Malahieude]

Le 06/02/2020 à 20:10, Benkő Pál a écrit :

the News section at lilypond.org dates 2.19.84 to 2019.  can I (or
anyone else) push a fix to staging?



I would prefer Phil or David to take care of this silly calendar not 
wanting to go ahead…


Cheers,
--
Jean-Charles

Re: Documentation suggestions.

[Jean-Charles Malahieude]

Le 05/02/2020 à 23:30, Michael Käppler a écrit :

Dear Peter,
it would be nice if you could register yourself at Rietveld. If you
already have a Google account it should be
straightforward, I think.
Please see the updated issue at:
https://codereview.appspot.com/579280043/



You don't need a Google account. Just give a valid email address.

Re: [translations] Remaining sprint for the release of version 2.20

[Jean-Charles Malahieude]

Le 06/02/2020 à 00:44, David Kastrup a écrit :


Whatever else may be on the plate, the immediate problem to be put
behind us right now is the release of 2.20.  I put specifically the
translation team and Werner into Cc.  The translation team should check
what changes of the recent release of 2.19.84 they still need to get
track of.



I've merged stable/2.20 into translation on Sunday for those (including 
myself) who want to be synchronized with the English version.  I plan to 
be done for the French part on Saturday (2 remaining work-weeks before 
one for vacations).



Werner basically is the person most affected by changes I have not yet
cherry-picked because of problems, changes that likely would be a good
idea to have in 2.20.

Those are his extensive indexing review, and reworks of several
examples.  The indexing review is hard to apply to the by now
significantly from master diverged stable/2.20, and with the reworks of
the examples I am not sure whether they need to be accompanied by
changes to the lilypond-extra archive.  At some point of time, there has
been such a requirement; I was not sure whether it persisted.  If I am
assured that this is either not an issue, or that lilypond-extra will
get the necessary treatment until we can release 2.20 (hopefully in a
week or so), I can do the required cherry-picking myself.



I don't remember either if lilypond-extra is to be touched.

As a matter of fact and re-thinking about it, those rewordings  and 
indexing, as long as they only concerned "old" material that was already 
on the stable/2.20 branch, should have been done directly on its 
material (they would be back-ported to master with a merge) like we 
acted for translations even if new.



So let's make sure we get our last ducks in a row for closing that
long-awaited chapter.



I just acknowledged the Free Translation Project that a new release is 
out. It might take a few days before importing the results.


Cheers,
--
Jean-Charles

lilypond-2.19.84

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://lilypond.org/download/source/v2.19/lilypond-2.19.84.tar.gz


Cheers,
--
Jean-Charles Malahieude

Re: stable/2.20 branch does not complete "make doc"

[Jean-Charles Malahieude]

Le 30/01/2020 à 19:46, David Kastrup a écrit :

Oops.

dak@lola:/usr/local/tmp/lilypond$ git checkout origin
error: The following untracked working tree files would be overwritten by 
checkout:
Documentation/snippets/non-traditional.snippet-list
Please move or remove them before you switch branches.
Aborting

That sounds suspicious.  Probably created by a makelsr call of mine but
did not make it into version control.  I'll check what is up with that:
it may be that this is what caused the problem.



Strange!
I've a "non-traditional-key-signatures.ly" but not your snippet-list

Re: Build problem with fonts

[Jean-Charles Malahieude]

Le 08/12/2019 à 18:12, Werner LEMBERG a écrit :


Please try again with

   strace -ff -o ~/mf2pt1.strace mf2pt1 feta11.mf

so that we can see the strace messages from `t1asm` also.  Note that
you will get at least two files called `mf2pt1.strace.X`, where
`X` is a process ID.



Four log-files were created, and the 3 resulting font-files as well.

feta11.pfb seems to be truncated, last lines being just

"
dup 142 /scripts.caesura.straight put
dup 1
"

And the console, as usual, finally spits

"Invoking "t1asm feta11.pt1 feta11.pfb"...
mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find 
another way to convert feta11.pt1 to feta11.pfb"


I enclose the generated files in mf/ if it helps.

Thanks,

ps. The dinner is smoothly cooking, just waiting for Madame to come home 
after concert.

--
Jean-Charles


mf2pt1.strace-ff.tar.xz
Description: application/xz


feta11.tar.xz
Description: application/xz

Re: Build problem with fonts

[Jean-Charles Malahieude]

Le 08/12/2019 à 17:10, Werner LEMBERG a écrit :


Strange indeed.  Can you temporarily replace `mf2pt1` with a script
that calls `strace`?  Something like

   strace mf2pt1 ... &> ~/mf2pt1.strace.log

You could then investigate in more detail which files `mf2pt1` tries
to open and/or execute.



[jcharles@pc1 mf]$ strace mf2pt1 feta11.mf &> ~/mf2pt1.strace

generates the .pfb .pt1 and .tfm

And I don't see anything special in the log (enclosed), at first glance 
since I'm not really able to interpret it.


Have to leave for now, and come back tomorrow.

TIA,
--
Jean-Charles


mf2pt1.strace.tar.xz
Description: application/xz

Re: Build problem with fonts

[Jean-Charles Malahieude]

Le 08/12/2019 à 16:51, Werner LEMBERG a écrit :


Can you execute t1asm?

   t1asm --help



It works either in $HOME or in my compiling folders.


Is it in your path that you use for compiling lilypond?



which t1asm
/usr/bin/t1asm

so I don't see any reason why, just at once, it failed at running… after 
a good sleeping night!


--
Jean-Charles

Build problem with fonts

[Jean-Charles Malahieude]

Hi all,

For about two weeks now, I'm unable to build and then merge translation 
with stable, even after a fresh clone. I cannot believe it has something 
to do with an upgrade from Fedora 30 to 31.


Tail of the log :
--8<--
cd ./out && /usr/bin/fontforge -script emmentaler-11.genpe
Copyright (c) 2000-2019. See AUTHORS for Contributors.
 License GPLv3+: GNU GPL version 3 or later 

 with many parts BSD . Please read 
LICENSE.

 Version: 20190801
 Based on sources from 00:00 UTC 15-Aug-2019-ML-D.
Cannot open /home/jcharles/GIT/Stable/mf/out/feta11.pfb
The requested file, feta11.pfb, does not exist
MergeFonts: Can't find font: feta11.pfb
Called from...
 emmentaler-11.genpe: line 17
make[1]: *** [GNUmakefile:138: out/emmentaler-11.otf] Error 1
make[1]: Leaving directory '/home/jcharles/GIT/Stable/mf'
make: *** 
[/home/jcharles/GIT/Stable/stepmake/stepmake/generic-targets.make:6: 
all] Error 2


Compilation exited abnormally with code 2 at Sun Dec  8 15:46:09
-->8--

I notice, upwards in the log, that

Invoking "t1asm feta11.pt1 feta11.pfb"...
mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find 
another way to convert feta11.pt1 to feta11.pfb



despite I've t1utils-1.41-1.fc31.x86_64 installed.

Some hints?

Cheers,
--
Jean-Charles

Re: build problem

[Jean-Charles Malahieude]

Le 26/07/2019 à 09:44, Federico Bruni a écrit :
Jean-Charles, version 1.0.3 is now available in Fedora 30 repositories. 
And version 1.1.0 is in rawhide.




As I've cloned the repository and built it without any problem, 
everything is fine.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: build problem

[Jean-Charles Malahieude]

Le 30/06/2019 à 11:10, Knut Petersen a écrit :

Build it yourself. Building and installing extractpdfmark is  an easy
an fast task.
Cloning the repository, building, testing and installing of 
extractpdfmark takes less than 20 seconds here:




This, as intended, works like a charm, but I was expecting an rpm to do 
its job (and notice nothing wrong when creating them).


Cheers,
--
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: build problem

[Jean-Charles Malahieude]

Le 30/06/2019 à 02:51, Masamichi Hosoda a écrit :

In Fedora 30, I suggest to use extractpdfmark from package,
rather than self-built extractpdfmark.
https://apps.fedoraproject.org/packages/extractpdfmark

If I understand correctly,
Fedora 30 has popler-0.73.0 package that has libpoppler.so.84.
https://koji.fedoraproject.org/koji/rpminfo?rpmID=17656985
Fedora 29 has popler-0.67.0 package that has libpoppler.so.78.
https://koji.fedoraproject.org/koji/rpminfo?rpmID=17657086

Did you build extractpdfmark on Fedora 29?
If so, it depends on libpoppler.so.78.
However, Fedora 30 does not have libpoppler.so.78.



My first attempts were using the official Fedora package (as I do since 
one is available), version 1.0.2. Facing this library problem, I've 
built a package for 1.0.3 and then 1.1.0 which both bump the wall.


Unfortunately, I don't remember if my last merge was just before 
upgrading to Fedora 30 or not. And Federico, who runs a Fedora 30 as 
well if I'm not mistaken, pushed on Translation mid-June…



Cheers,
--
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

build problem

[Jean-Charles Malahieude]

Hello,

Since I can't get a successful doc-build on my Fedora 30 box, I'm unable 
to check doc-changes and merge translation into stable.


It's the same with extractpdfmark 1.0.2 1.0.3 and 1.1.0

log spits:

extractpdfmark -o ./out-www/collated-files.pdfmark 
./out-www/collated-files.tmp.pdf
extractpdfmark: error while loading shared libraries: libpoppler.so.78: 
cannot open shared object file: No such file or directory


And I won't try to package poppler-0.78. There are too many dependencies 
for me (Fedora is stuck to 0.73).


Cheers,
--
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Google Season of Docs

[Jean-Charles Malahieude]

Le 05/04/2019 à 20:46, Werner LEMBERG a écrit :


Would this be of interest for LilyPond?



This might help us going forward and profit from the evolution of 
texinfo, as well as recover the use of lilypond-doc.po that vanished 
with GDP.


Cheers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Release plan

[Jean-Charles Malahieude]

In order to make available the various updates to translations of our 
documentation (thanks to Federico, Francisco, Walter and Tomohiro 
Tatejima)  would it be possible to release a 2.19.82?


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

core dump

[Jean-Charles Malahieude]

Hi all,

Trying to compile one of Nicolas Sceaux' score, I get a core dump.

Strange thing is the message, depending on the binary:

with the downloaded and installed 2.19.80, it says

lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/lily/script-interface.cc:48: 
static Stencil Script_interface::get_stencil(Grob*, Direction): 
Assertion `false' failed.


but, with a self compiled version (Stable/20.20 as of 2018/02/03 commit 
"Doc: run translation-status") it says without any location reference


lilypond: script-interface.cc:48: static Stencil 
Script_interface::get_stencil(Grob*, Direction): Assertion `false' failed.



In both cases, the command resulting from the Makefile is

lilypond --loglevel=DEBUG -ddelete-intermediate-files 
-dno-protected-scheme-parsing -o out/IndesGalantes1735-dessus 
-dpart=dessus  Rameau/Opera/IndesGalantes1735/part.ly


In both cases, the backtrace (except for the location of the executable) is

{   "signal": 6
,   "executable": "/home/jcharles/lilypond/usr/bin/lilypond"
,   "stacktrace":
  [ {   "crash_thread": true
,   "frames":
  [ {   "address": 139797459277419
,   "build_id": "3113881229974f02113945e92c1a4d4f146e061c"
,   "build_id_offset": 226923
,   "function_name": "raise"
,   "file_name": "/lib64/libc.so.6"
}
  , {   "address": 139797459284865
,   "build_id": "3113881229974f02113945e92c1a4d4f146e061c"
,   "build_id_offset": 234369
,   "function_name": "abort"
,   "file_name": "/lib64/libc.so.6"
}
  , {   "address": 139797459245306
,   "build_id": "3113881229974f02113945e92c1a4d4f146e061c"
,   "build_id_offset": 194810
,   "function_name": "__assert_fail_base"
,   "file_name": "/lib64/libc.so.6"
}
  , {   "address": 139797459245426
,   "build_id": "3113881229974f02113945e92c1a4d4f146e061c"
,   "build_id_offset": 194930
,   "file_name": "/lib64/libc.so.6"
}
  , {   "address": 6807769
,   "build_id_offset": 2613465
,   "file_name": "/home/jcharles/lilypond/usr/bin/lilypond"
}
  , {   "address": 139797493296192
,   "build_id_offset": 3120192
,   "file_name": 
"/home/jcharles/lilypond/usr/lib/libguile.so.17.3.1"

} ]
} ]
}


Full log and what says ABRT are available.

What can I do further?
--
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypond-2.19.80

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.80.tar.gz


Cheers,
Jean-Charles Malahieude

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Changes.tely

[Jean-Charles Malahieude]

Hi James,

I didn't review your patch, but Documentation/changes-splittexi.log contains

WARNING: Unable to find node 'Isolated durations in music now stand for 
unpitched notes' in book notation.


Seems to be a wrong command in changes.tely -- lines 335

@noindent
with multiple exceptions separated by bar checks.  Note that writing the
exception pattern without pitches is convenient but not mandatory (also
see the previous documented rhythm improvement --
@ruser{Isolated durations in music now stand for unpitched notes}.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: make test fails → texi2html (?) error

[Jean-Charles Malahieude]

Le 06/10/2017 à 16:27, Malte Meyn a écrit :

Hi list,

I tried to compile the regression tests (make test) but this failed with 
the following message in input/regression/collated-files.texilog.log:


Undefined subroutine ::get_index called at 
/home/malte/lilypond/Documentation/lilypond-texi2html.init line 2408.


What’s this? I found the same message in the list archive 
(https://lists.gnu.org/archive/html/lilypond-devel/2015-03/msg00084.html) but 
I couldn’t find any other hints what to do now. If that helps, my 
texi2html version is 5.0.




You've to downgrade texi2html to version 1.82.
I've tried to upgrade several times, but there are too many things I 
don't understand in our texi2html.init to have it successfully work.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Absence

[Jean-Charles Malahieude]

Hi all,

Sorry not to be active for the past two weeks, but a family "disaster" 
will keep me away from any activity for this week as well.


I'll let David, Federico or Francisco do the merging between stable/2.20 
and translation until Monday 9th.


I might just be able to read some mails on my father's old windows computer.

Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: translation branch and stable/2.20 branch

[Jean-Charles Malahieude]

Le 08/08/2017 à 16:48, Masamichi Hosoda a écrit :

2.19.65 has been released,
it seems that it does not contain some recent translations.

[...]

Which branch should the translators translate?
e.g. translate the English document in the master branch,
commit to the translation branch, etc.



Sorry for the delay, but holidays keeps me pretty much off-line.

According to the thread "Any objections to branching off a stable branch 
for 2.20?" and especially 
http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00090.html 
translating only apply to the translation branch.


New material, improvements and amendments will be cherry-picked from 
master into stable/2.20. I'll let David K. list which commits are to be 
part of it.


Cheers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Any objections to branching off a stable branch for 2.20?

[Jean-Charles Malahieude]

Le 19/07/2017 à 14:48, David Kastrup a écrit :

Federico Bruni writes:


Il giorno lun 17 lug 2017 alle 19:14, David Kastrup ha scritto:


Other things up for cherry-picking are documentation changes and
their translations. Since translations usually are done in "bulk",
it would make sense to only translate stuff in the stable 2.20
branch in the interregnum: that way the translation branch can be
merged (rather than individual parts cherry-picked) into the stable
branch until the stable branch gets released.


So when you create the stable/2.20 branch, Jean-Charles or Paco will
merge that branch (instead of master) into the translation branch; and
translators will keep working on the translation branch as usual.

Is it correct?


Yes, I think this is what should make sense.  I'll do so today.



I've included Walter's patch into translation and now stable/2.20 and 
translation are similar.


So, until next 2.21 is out, the translators' Mary-go-round is just 
between the stable/2.20 and translation branch.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: help with bash script to translate @ref{} items in translated manuals

[Jean-Charles Malahieude]

Le 21/04/2017 à 17:59, Federico Bruni a écrit :



Il giorno ven 21 apr 2017 alle 15:54, k...@aspodata.se ha scritto:

You already have such an replacement file in Documentation/po/it.po:

$ fgrep -C2 'Different editions from one source' Documentation/po/it.po
#. @node in Documentation/notation/input.itely
#. @subsection in Documentation/notation/input.itely
msgid "Different editions from one source"
msgstr ""

Maybe that could be put to use.



The translation stuff is quite a mess.
IIRC those po files are used only to translate a few strings of the 
website, but most of the strings are useless.

In fact they are empty and nobody complains about it :)



It has been broken during the GDP process.
I've a tarball of the 2.12.3 docs (January 2010) and we even had 
variables' name and comments translated in the @lilypond thanks to those 
po files.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [LilyIssues-auto] [testlilyissues:issues] #4966 the font name is Emmentaler, while Feta and Parmesan are two subsets of glyphs

[Jean-Charles Malahieude]

Le 12/03/2017 à 11:37, Federico Bruni a écrit :



Il giorno dom 12 mar 2017 alle 11:10, Jean-Charles Malahieude

No, the two typos are still there...




Sorry, take a look at commit
1e5c6b0f54079eb3285dcc4c7e53f17d8bb03933
Doc: typos and spurious seealso

Seems like documentation in not rebuilt when merging staging into master.

Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [LilyIssues-auto] [testlilyissues:issues] #4966 the font name is Emmentaler, while Feta and Parmesan are two subsets of glyphs

[Jean-Charles Malahieude]

Le 12/03/2017 à 10:50, David Kastrup a écrit :

Auto mailings of changes to Lily Issues

writes:


James, I think that you can mark this issue as fixed and I'll create a
new issue for the fourth item in the above list.

I have only two comments about your patch (sorry for being late):

1. There's a typo in Documentation/notation/notation-appendices.itely:


used for clasical notation and @qq{Parmesan}, sed for Ancient


sed -> used


What about clasical -> classical ?



I've dealt with those ones yesterday, see commit 
afbf2adcf51b409d7825daa71f6869f7dbf0385a and a link from

scm/define-markup-commands.scm

I think that, when renaming a node, should be run from the root directory a

git grep 'OLD_NODE_NAME'

in order to avoid this nasty warning in the doc-building-logs:
WARNING: Unable to find node 'OLD_NODE_NAME' in book BOOK.

Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypond-2.19.54

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.54.tar.gz


Cheers,
Jean-Charles Malahieude





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New LilyPond website

[Jean-Charles Malahieude]

Le 03/12/2016 à 22:28, Graham Percival a écrit :

On Fri, Dec 02, 2016 at 07:50:50PM +0100, Jean-Charles Malahieude wrote:

I've already given it a try, but get stopped by some errors I don't know how
to resolve (I've no knowledge about perl). Three patches are available for
anybody willing to help me… I can compile the English version, except that I
don't get the TOC sidebar.


Hmm, sounds like there's some duplicated effort there.  In July
2015, we created:
https://github.com/gperciva/lilypond-texinfo
to try to update lilypond-texi2html-init.



Which has not moved since August 23 (2015)!
I just give it a try as texinfo evoluates. Just refer to issue 1000.

Cheers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New LilyPond website

[Jean-Charles Malahieude]

Le 02/12/2016 à 02:10, Paul a écrit :

Hi Carl,

On 12/01/2016 12:44 PM, Carl Sorensen wrote:

One thing that is note mentioned in your quote is that texinfo separates
semantics from appearance.  It is this precise separation that allows one
to make big but consistent changes in the appearance of the website with
changes in the CSS.  I'm a firm believer in the principle of separating
semantics from presentation (and we do that with LilyPond, by the way,
which is one of its strengths IMO).


I totally agree about the value of separating semantics and appearance.
Using texinfo does enforce that in a strict way, although well-written
HTML also follows this principle.  HTML for content and CSS for style.
(E.g. one could just write directly the HTML that is generated from
texinfo.)  Maybe I'm missing something or maybe the strict enforcement
is the point?  At any rate, my intention is not to engage in argument or
advocate for anything.



I remember the "traffic" I had to do when the site was in full HTML 
(back in 2005) and we began with John Mandereau t translate it. 
Fortunately, I found a macro to use with emacs that "un-htmlized' for 
the time I typed the French text and "re-htmlized" before pushing any 
patch. It' hard to read at first sight:


Ces plaques taient encres et les reliefs 
crs par les poinons et

les dcoupes retenaient l'encre.




Upgrading to the latest version of texi2any[0] and/or using Haunt would
help, but those are non-trivial endeavors.  The current setup certainly
introduces friction for website work, especially for those who are used
to working directly with HTML.

I believe that we want to avoid working directly with HTML because of its
mixture of semantics and presentation.


I just wish that working with texinfo (for the website) was more
intuitive for contributors who know HTML but not texinfo.  For example,
an HTML element with an id and also a number of classes, all used for
styling it with CSS.  I don't know if you can generate that HTML element
(with both id and classes) from texinfo with our current setup.  If so I
haven't figured it out yet.  Maybe upgrading to the latest texi2any
would help.  Maybe someday I'll have the time to work on it.



I've already given it a try, but get stopped by some errors I don't know 
how to resolve (I've no knowledge about perl). Three patches are 
available for anybody willing to help me… I can compile the English 
version, except that I don't get the TOC sidebar.


Once lilypond-texi2html-init amended, I cannot deal with

Useless use of hash element in void context
Texi2HTML::Config::generate_ly_toc_entries() called too early to check 
prototype

Prototype mismatch: sub main::normalise_node: none vs ($)
Use of uninitialized value $Texi2HTML::Config::SPLIT in string eq

and tons of warnings, one for each @ref{} encountered, like

out-www/changes.texi:1174: warning: @vindex should only appear at the 
beginning of a line (possibly involving @rlearning)


comming from the rMANUAL macro definition.

What I do is:
1- uninstall texi2html.1.82

2- create a symlink
  cd ~/bin
  ln -s /usr/bin/texi2any texi2html

In a final stage, occurrences of texi2html might be replaced by texi2any.

3- try building the docs in my local branch dev/texi2any
  make doc LANGS=''

no way until now to build the translations!


4- erase my symlink and reinstall texi2html for usual work on 
translation branch.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Stepping down and moving on

[Jean-Charles Malahieude]

Le 09/11/2016 à 18:09, David Kastrup a écrit :


Hi folks and team,

while I haven't really occupied an official function in LilyPond
development, it's hard to deny that I have effectively functioned as
acting chief architect and vetter (with a rather mottled performance).

I have accepted a full-time development (and team management) position
with another company.  Due to their project and team expansion plans,
I will be starting already in December.



First of all, many thanks for all you did in and for LilyPond.
And I wish you all the best in you new position.

Mach's gut!
--
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patchy email

[Jean-Charles Malahieude]

Le 28/09/2016 à 13:23, James a écrit :


Now if only Jean-Charles, Graham et al, could script checking reg
test diffs and finding obscure make errors in all the .log files we
generate ;)



I'm not good at all with scripting, but could try to track down the 
logs. What would you like me to do in this area ?


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Mail to tranlati...@lilynet.net failing

[Jean-Charles Malahieude]

Le 27/08/2016 à 10:05, Walter Garcia-Fontes a écrit :

Mail to lilynet.net is failing with the following error:

Delivery to the following recipient failed permanently:

 translati...@lilynet.net

Technical details of permanent failure:
DNS Error: 21251920 DNS type 'mx' lookup of lilynet.net responded with code 
NXDOMAIN
Domain name not found: lilynet.net

In any case, my message said that I've prepared a new set of Catalan
translations:

http://puna.upf.edu/catalan_august_26_2016.zip


Back from vacation, I applied your patches on my local copy, but there 
are so many errors…

Please keep in mind that, notwithstanding the spelling,

1- what is in the @menu MUST be equal to what comes after @node:

  @menu
  *hotdog::  For snacking
  @end menu

  @node hotdog
  @section Bred and sausage and mustard

2- what is in @ref{…} MUST be equal to what comes after @node:

  …foo @ref{hotdog}
or
 …foo @rXXnamed{hotdog, Hotdogs}

Another help  is to check the MANUAL.log file: except for those 
cross-references dealing with manuals that are not translated (mainly 
snippets and internals), you should not get any line like


WARNING: Unable to find node 'Escriptura de les notes' in book notation.

I had first to amend ca/notation/rhythms.itely (see 
ca-notation-rhythms-TODO) before being able to fully build the docs.


What I usually do is
 - translate or upgrade
 - check the docs fully build
 - check the log-files for potential bad cross-references
 - make doc-clean
 - make doc
and then only commit.


Cheers,
Jean-Charles
WARNING: Unable to find node 'Escriptura de les notes' in book notation.
WARNING: Unable to find node 'Lligadures d'unió' in book notation.
WARNING: Unable to find node 'Lligadures d'expressió' in book notation.
WARNING: Unable to find node 'Lligadures de fraseig' in book notation.
WARNING: Unable to find node 'Matisos dinàmics' in book notation.
WARNING: Unable to find node 'Explicació dels contextos' in book notation.
WARNING: Unable to find node 'LilyPond Scheme-Syntax' in book extending.
WARNING: Unable to find node 'L'ordre tweak' in book notation.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Costum tablatures' in book notation.
WARNING: Unable to find node 'Costum tablatures' in book notation.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Clau' in book internals.
WARNING: Unable to find node 'Altures y armadures' in book learning.
WARNING: Unable to find node 'Altures i armadures' in book learning.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Tessitura' in book internals.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'slurs' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Groupig staves' in book notation.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Duracions' in book snippets.
WARNING: Unable to find node 'Altures' in book snippets.
@@ 

Re: State of staging branch?

[Jean-Charles Malahieude]

Le 08/05/2016 à 16:30, David Kastrup a écrit :

"Phil Holmes"  writes:


Compile was fine and staging pushed to master.  I guess James's patchy
machine is having connectivity problems or similar.


Ok...  Just for interest: your system is 64bit?  Mine is 32bit and still
at it.  I think James' is 64bit.



I got no problem yesterday in compiling staging (64bit) before pushing 
my merge.


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: hyphen syntax

[Jean-Charles Malahieude]

Le 14/02/2016 20:41, Dan Eble a écrit :

Are there technical limitations that require typing a double hyphen
to hyphenate lyrics?  Why not just one?



Technically, I don't know. But, in terms of coherence, I would leave it 
as it is:


one hyphen is treated as one syllable, just like one underscore "skips" 
one (group of) note, and I will type my first-name Jean- Char -- les or 
"Jean -" Char -- les since it's a composed word,


one double-hypen (which may output several dashes depending of the 
length of a melisma) separates syllables of a same word, like a 
double-underscore draws a line indicating the last syllable has to last 
over serveral notes.



Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Musicians prefer LilyPond scores, study finds

[Jean-Charles Malahieude]

Le 17/12/2015 17:53, Francisco Vila a écrit :

Hello,

I just gained my PhD. My humble thesis tells the design and results of
an experiment with a number of musicians, comparing lilypond scores
with the originals which those scores were copied from.



Congratulations!


Now I will try to translate again. Of course my long absence makes me
unworthy of the translator meister position, but it has been a good
personal cause.



Glad to see you back in the pond…

Cheers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: I seem to have broken staging

[Jean-Charles Malahieude]

Le 17/11/2015 22:37, David Kastrup a écrit :

Thomas Morley  writes:


Hm, before I pushed this, I had gotten a merge conflict while rebasing.
Was in "/Documentation/notation/fretted-strings.itely", iirc.
Resolved it manually.

Though, I didn't even touch the french or any other
fretted-strings.itely-file and didn't notice it before pushing.

Did I something wrong?
If so, what can I do to avoid this mess?


In this particular case, do a "git grep" for the stuff to be backed out
again, like '(determine-frets #' or similar.

Since the change was in the translations, not even reverting the
original commit would have restored the stuff to working state.  It was
sort of unlucky that the Patchy testing occured while the translations
were not yet merged back into master.



Sorry, I've just merge master into translation a couple of days after 
7f1b4934f96cfea964986c29d4048e6e794b9611, translated it in French. 
Everything built fine, so I merged into staging, which later merged into 
master…


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypon.org down

[Jean-Charles Malahieude]

LP.org is down here in France since yesterday afternoon. Are we the only 
one?


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypon.org down

[Jean-Charles Malahieude]

Le 31/10/2015 14:03, bobr...@centrum.is a écrit :

According to:

http://www.downforeveryoneorjustme.com/lilypond.org

It's down.

-David


From: "Jean-Charles Malahieude"


LP.org is down here in France since yesterday afternoon. Are we the only
one?



But download.linuxaudio.org/lilypond/binaries/ is still available…

Chhers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond.org - file storage

[Jean-Charles Malahieude]

Le 30/08/2015 17:45, Graham Percival a écrit :

On Sun, Aug 30, 2015 at 01:15:48PM +0100, Phil Holmes wrote:

We also have source files back to 0.0 and 1.0.  I assume we could
never recreate these from Git, but are we ever going to need to?  It
certainly seems pointless keeping lots of source tarballs, given
that all the more recent history is in Git.


I think it would be nice to keep the ancient history around; software
archeology research sometimes look at open-source projects.  That said,
they don't necessarily need to be on that particular web server.
Something like Amazon Glacier could work well for that, or maybe google
drive... there are other storage platforms available.
(and no, I'm not in a position to offer to take care of this)

I fully support deleting all test-output for non-current development
versions.  (though again, in an ideal world they would be stored on some
other server or service)



BTW, is there any difference between download/source and download/sources ?

Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypond-2.19.26

[Jean-Charles Malahieude]

Hi,

Please find a new tarball for LilyPond at

http://download.linuxaudio.org/lilypond/source/v2.19/lilypond-2.19.26.tar.gz


Cheers,
Jean-Charles Malahieude





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Remove old News entry from home page

[Jean-Charles Malahieude]

Le 19/07/2015 08:25, Federico Bruni a écrit :

[…]




 2. We still depend on texi2html and the help request by
 Jean-Charles, who tried moving to texi2any, not surprisingly was
 ignored:

http://lists.gnu.org/archive/html/lilypond-devel/2015-05/msg00032.html


[Werner]
The `non surprisingly' is polemic.  As you certainly know, if noone
answers on the mailing list, the request is not ignored, but nobody
has time or knowledge to help – I really would love to help, but I
also don't have time currently.  Just imagine that all developers
write I'm-so-sorry-e-mails for every request...


I didn't mean to be polemic, I just wanted to highlight strongly that
AFAICS we do not have active maintainers of the current tools. The first
point I wrote above, which you think is irrelevant to the discussion, is
relevant.

texi2html is deprecated since 2011. It's still present in most
distributions but I guess that it won't be there forever. For example,
in Debian:
https://wiki.debian.org/Texi2htmlTransition
https://lists.debian.org/debian-devel/2013/05/msg01516.html

There will be a pressing need to move to texi2any quite soon, otherwise
LilyPond may be removed from the distro repository.



I'll rise it again, since texinfo-6.0 has been released and I upgraded 
my Fedora (21, don't want 22 for now…), once the Translation branch will 
 have been updated in French.
I've an (over)full-time job, and try to keep the French part of docs up 
to date as well as try to help, but days last only 24 hours and I've no 
skill in programming (just trying to understand but often reach my 
limits) and don't want to break anything!


Cheers,
Jean-Charles

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue 1557: Migration from texi2html to texi2any

[Jean-Charles Malahieude]

Le 02/05/2015 20:18, Jean-Charles Malahieude a écrit :



What I've tried so far is:

4- replace any occurrence of @documentlanguage utf-8 by
@documentlanguage UTF-8 and add it where needed


Oops! should have read before sending:

4- @documentencoding UTF-8



Could anybody help?



Cheers,
Jean-Charles


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

issue 1557: Migration from texi2html to texi2any

[Jean-Charles Malahieude]

Hi all!

Texinfo evolves, and so does texi2any.

What I've tried so far is:
1- build and install a new 5.9.90 texinfo
2- uninstall texi2html
3- ln -s /usr/bin/texi2any ~/ME/bin/texi2html
4- replace any occurrence of @documentlanguage utf-8 by 
@documentlanguage UTF-8 and add it where needed


I've adapted lilypond-texi2html.init according Please check the logfile 
suffix-tely.texilog.log for errors (lines 1090, 1609, 1612 and 1613) 
but get stuck with the rest of it.


Could anybody help?

Cheers,
Jean-Charles
Option i is ambiguous (ifdocbook, ifhtml, ifinfo, ifplaintext, iftex, ifxml, info, init-file, internal-links)
Option i is ambiguous (ifdocbook, ifhtml, ifinfo, ifplaintext, iftex, ifxml, info, init-file, internal-links)
Option i is ambiguous (ifdocbook, ifhtml, ifinfo, ifplaintext, iftex, ifxml, info, init-file, internal-links)
Scalar value @hrefsplit[$#hrefsplit] better written as $hrefsplit[$#hrefsplit] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1090.
Scalar value @hrefsplit[$#hrefsplit] better written as $hrefsplit[$#hrefsplit] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1090.
Scalar value @hrefsplit[$i] better written as $hrefsplit[$i] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1609.
Scalar value @split[0] better written as $split[0] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1612.
Scalar value @split[1] better written as $split[1] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1612.
Scalar value @hrefsplit[$i] better written as $hrefsplit[$i] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1613.
Scalar value @split[0] better written as $split[0] at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1613.
Useless use of hash element in void context at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1680.
Texi2HTML::Config::generate_ly_toc_entries() called too early to check prototype at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1687.
Prototype mismatch: sub main::normalise_node: none vs ($) at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 81.
Use of uninitialized value $Texi2HTML::Config::SPLIT in string eq at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1009.
Use of uninitialized value $Texi2HTML::Config::SPLIT in string eq at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 1009.
Use of uninitialized value $Texi2HTML::Config::SPLIT in string eq at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 2322.
Use of uninitialized value $Texi2HTML::Config::SPLIT in string eq at /home/jcharles/GIT/new-texinfo/Documentation/lilypond-texi2html.init line 2322.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel