Re: unsafe caching of .fmt files
Hi Han-Wen - neither fmt generation nor any other runtime generation has ever been parallel-safe. Even if I added locking to mktexfmt (I guess you are making use of the dynamic fmt creation), something I am not at all anxious to do, the failed simultaneous runs that would result doesn't sound like a good outcome for you. Instead, I think you need to generate the formats you need before starting the parallelism, either with multiple mktexfmt foo.fmt calls or fmtutil-user (or fmtutil-sys, but if you want ~/.texlive2019 to be used instead of /usr/local/texlive/... or whatever, that sounds like fmtutil-user), depending on your needs. Indeed, in this situation, I also suggest that you explicitly disable any mktex* creation. MKTEXFMT=0; export MKTEXFMT; MKTEXTFM=0; export MKTEXTFM; MKTEXMF=0; export MKTEXMF; MKTEXPK=0; export MKTEXPK Alternative: you could set TEXMFVAR or TEXMFSYSVAR to a per-process directory. But then every TeX run will need to create its own .fmt, which sounds like an awful waste of time. --best, karl.
Re: @documentencoding utf-8?
chance for @documentencoding utf-8 to be implemented in texinfo soonish? Not by me. Sorry. Patches would be more than welcome, of course. (Doing the fonts in TeX is an especially large piece of the problem, although even having support in makeinfo alone would be terrific. I don't think it will be easy.) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: install-info problems
install-info: menu item `mup2ly' already exists, for file `lilypond/lilypond'
The patch below will fix the problem for mup2ly and the other lilypond
entries, hopefully.
However, the problem still exists for
* Glossary: (lilypond/music-glossary). Glossary of music terms.
This is because install-info is not prepared to handle dir entries for
info files other than the one being processed (given on the cmd line).
I think install-info should simply read the dir entries out of the info
file, and not care what the name of the file is, but that will mean a
complete rewrite, and I really don't want to right now.
So, can I ask you to put the @direntry for Glossary in music-glossary.texi
instead of lilypond.texi? At least, I'm guessing that's the scenario.
Thanks,
karl
*** install-info.c.~1.3.~ Thu Mar 18 14:15:38 2004
--- install-info.c Fri Mar 26 16:14:37 2004
***
*** 315,323
static int
menu_item_equal (const char *item, char term_char, const char *name)
{
unsigned name_len = strlen (name);
/* First, ITEM must actually match NAME (usually it won't). */
! int ret = strncasecmp (item, name, name_len) == 0;
if (ret)
{
/* Then, `foobar' doesn't match `foo', so be sure we've got all of
--- 315,342
static int
menu_item_equal (const char *item, char term_char, const char *name)
{
+ const char *item_basename = item;
unsigned name_len = strlen (name);
+
+ /* We must compare the basename in ITEM, since we are passed the
+ basename of the original info file. Otherwise, a new entry like
+ lilypond/lilypond won't match lilypond.
+
+ Actually, it seems to me that we should really compare the whole
+ name, and not just the basename. Couldn't there be dir1/foo.info
+ and dir2/foo.info? Also, it seems like we should be using the
+ filename from the new dir entries, not the filename on the command
+ line. Not worrying about those things right now, though. --karl,
+ 26mar04. */
+ while (*item_basename !IS_SLASH (*item_basename))
+ item_basename++;
+ if (! *item_basename)
+ item_basename = item; /* no /, use original */
+ else
+ item_basename++; /* have /, move past it */
+
/* First, ITEM must actually match NAME (usually it won't). */
! int ret = strncasecmp (item_basename, name, name_len) == 0;
if (ret)
{
/* Then, `foobar' doesn't match `foo', so be sure we've got all of
***
*** 335,342
{
char *suffix = suffixes[i];
unsigned suffix_len = strlen (suffix);
! ret = strncasecmp (item + name_len, suffix, suffix_len) == 0
! item[name_len + suffix_len] == term_char;
}
}
--- 354,361
{
char *suffix = suffixes[i];
unsigned suffix_len = strlen (suffix);
! ret = strncasecmp (item_basename + name_len, suffix, suffix_len) == 0
! item_basename[name_len + suffix_len] == term_char;
}
}
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: info problems
Node: Staff notation0x7f182205 Hmm. I don't see any change for this in the ChangeLog, but when I run the current cvs makeinfo -o foo.info lilypond.nexi, I get Node: Staff notation0x7f81023 and that is indeed where the Staff notation node starts. The (wrong) .info files in the archive you sent me report themselves as being made by makeinfo 4.6 ... I'm about to make another pretest, so please try that. Thanks, k ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: install-info problems
install-info: menu item `mup2ly' already exists, for file `lilypond/lilypond' Well, the error message is misleading (I'll look into that), but install-info sorts entries within sections. I think that's why nothing is happening? k P.S. Thanks for reporting the offset bug. I'm going to be gone for a couple days, but I'll work on it when I get back later this week, if Alper doesn't get to it first. (Alper, I'll send you the input files in case ...) ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: info problems
Yes that's maybe the best option, I'll do that. It's just that we list all program names at top level, and `lilypond' is the name of a program too... Right. So, the rule in my mind is not all programs, it's all programs that are not also manual names :). As you probably know, this very topic (in a different guise) is being discussed on emacs-devel right now ... ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: bad html formatting
@quotation @example foo @end example @end quotation Why is @example inside @quotation in the first place? (Although I don't think this causes the problem, it seems wrong, like a kludge to get examples indented maybe?) What's the reason for the `br'? It seems that @example and the like always insert brpre (line 503 of insertion.c). I don't know why, seems like just pre would be better. I'll see if I can dig up a reason for the br, if not, I'll try getting rid of it. Thanks, k ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
