Le mercredi 25 novembre 2009 à 10:48 +0100, David Kastrup a écrit :
> Sounds like a dependency impacting developers rather severely.
Are you joking? Is requiring an officially released version and not
supporting a version from CVS excessive? We have no control on
Texi2HTML development, and in pa
Le mercredi 25 novembre 2009 à 11:41 +0100, David Kastrup a écrit :
> When the code requires meddling with the internals of Texi2HTML, like I
> understood Reinhold, it is in some parts linked to the particular
> version. In this case it makes sense to distribute the required version
> alongside si
Le mercredi 25 novembre 2009 à 22:07 +, Graham Percival a écrit :
> On Tue, Nov 24, 2009 at 09:33:50PM +0100, John Mandereau wrote:
> > Jan already translate a few sentences in several nodes in French and
> > Dutch, and while splitted HTML translated docs used t
Le jeudi 26 novembre 2009 à 23:40 +, Graham Percival a écrit :
> Make sure that the texi2html is being called with the right
> arguments. I think the relevant command is in make/doc-i8n-*.
Sure, but after my hacking texi2html currently dies at manuals in
English. I'm about to remove the code
Le vendredi 27 novembre 2009 à 00:20 +, Graham Percival a écrit :
> If you're talking about line 370 and onwards in
> web-texi2html.init, then they're already "removed" -- see the
> if (0 and ...)
> line?
They should not be removed, because proper working of translations use
functionnality
Le lundi 09 novembre 2009 à 20:08 +, Graham Percival a écrit :
> And we could try looking into why we get the duplicate
> anchors which confuse opera)
If Opera is case-sensitive for anchors, it looks like I accidentally
solved this issue: this isn't a consequence of a deliberate design but
of
Le vendredi 27 novembre 2009 à 14:38 +, Graham Percival a écrit :
> I have no index_xy.html files where _xy is a number.
I have no longer such files generated in my build tree with current
master, I hope it's still the same for you.
> I have
> index_abt, index_toc (which we don't want/need
Hi guys,
Please always check that Lily and docs compile (make all && make doc)
before pushing, or push to a branch different from master.
/home/lilydev/git/lily/master/Documentation/out//essay/engraving.texi:950: Prev
reference to nonexistent node `Notation benchmarking' (perhaps incorrect
sect
Le samedi 05 décembre 2009 à 11:32 +0100, Francisco Vila a écrit :
> WARNING: Node 'Index de LilyPond' was NOT found in the map
> File name: index-de-lilypond.html
There is a lot of debug prints from the init file, a lot of them are
commented out; I'll remove most of them when the init file will b
Le samedi 05 décembre 2009 à 11:18 +, Graham Percival a écrit :
> I've seen similar messages when attempting to build it on GUB,
> although they specify /contributor/ instead. I haven't seen them
> when building it natively, though. I'll try building the online
> target and see if that dies.
Hi guys,
Dénes made a bunch of suggestions to avoid repetitions in docs, which
would require a fair amount of maintenance work. I'm replying on the
lists for the record and possibly for discussion, but I'm too budy to
tackle these suggestions before next year; I propose to register these
suggesti
Le mercredi 09 décembre 2009 à 05:03 +, Graham Percival a écrit :
> Could translations of texi2html stuff be done in a separate file? I'm
> sure that perl has some way of reading a {} data type from a file.
Texi2HTML implements (or is going to implement very soon) Gettext, so
I'm for dealing
Le mercredi 09 décembre 2009 à 01:19 +, Graham Percival a écrit :
> Only if you accept responsibility for making it work in makeinfo,
> texi2pdf, and texi2html. This duplicates 10 or 20 commands in
> macros.itexi. That's one file. When you change a manual name,
> you need to update 4 lines o
Le dimanche 06 décembre 2009 à 19:37 +0100, Francisco Vila a écrit :
> I have rm-rf'ed completely out* and Documentation/, then reset them
> hard, and still
>
>*** Can't open ./out-www/learning/ for writing: Is a directory,
>
> after 41 min of compilation.
To investigate this, I need the Git
Le samedi 05 décembre 2009 à 11:18 +, Graham Percival a écrit :
> I've seen similar messages when attempting to build it on GUB,
> although they specify /contributor/ instead.
Please send me the same info I asked in my reply to Francisco, otherwise
there is little chance I see why extract-texi
Le mercredi 09 décembre 2009 à 22:59 +, Trevor Daniels a écrit :
> /home/trevor/lilypond-git/scripts/build/out/www_post LilyPond
> 2.13.9 ./out-www "offline"
> Mirroring...
> Traceback (most recent call last):
> File "/home/trevor/lilypond-git/scripts/build/out/www_post", line 67,
> in
>
Le mercredi 09 décembre 2009 à 20:19 +0100, Francisco Vila a écrit :
> Thank you, now I have upgraded texi2html to v1.82 and have been able
> to complete the process.
Ah, if you used a version older than 1.82, it probably doesn't normalize
the node names the same way.
> I uncompressed it from
Le jeudi 10 décembre 2009 à 03:44 +, Graham Percival a écrit :
> On Wed, Dec 09, 2009 at 11:11:20AM +0100, John Mandereau wrote:
> > 4 lines of Texinfo multiplied by the number of languages, which
> > completely changes the deal.
>
> It's still only a few minutes
Le vendredi 11 décembre 2009 à 09:10 +, Graham Percival a écrit :
> Doing an out-of-tree build:
> mkdir ../lily-out
> make distclean
> cd ../lily-out
> ../lilypond/configure
> make
> make doc
>
> produces a 0-byte contributor.xref-map
I guess the problem might come from the lack o
Le vendredi 11 décembre 2009 à 08:39 +, Trevor Daniels a écrit :
> John, many thanks for your reply, but thankfully the problem
> appears to have gone away.
>
> I modified www_post.py as you suggested, and then made a
> clean start by running ./autogen.sh, make doc-clean and then
> make doc in
Le vendredi 11 décembre 2009 à 14:24 +, Graham Percival a écrit :
> Quick poll: I promised to announce 2.13.9 on the info list (after
> waiting 12-24 hours for tests to avoid any huge embarassment), but
> it seems that the website still only displays 2.13.7. Who thinks
> I should announce 2.13
Le vendredi 11 décembre 2009 à 13:35 -0800, Patrick McCarty a écrit :
> Do we know what's wrong with the website? Is this something I can help fix?
No, as my previous reply probably shows, only somebody with a login on
lilypond.org (and possibly privileges to update the makefiles and
scripts in t
Hi Mark,
I'm pleased to see you back on the lists :-)
Le samedi 12 décembre 2009 à 13:23 -0800, Mark Polesky a écrit :
> Hey everyone,
>
> Pardon my confusion; I've been doing a lot of stuff here and
> I've not yet figured out what causes what. Among the many
> things I've done recently is this
other messages than there are
issues with build attempts on Fedora, so I'd rather keep that
conservative setup at the moment and help with issues on the side of
the target, and Python seems to be first on the list.
Greetings
--
John Mandereau
_
n I reach this stage I'll issue a patch or a
Git branch.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat 2019-01-19 00:01 +0100, John Mandereau wrote:
> I merged GUB PRs 53 and 54 (with respective revisions c410c4b and
> d1c9a24, which are older than current ones)
I didn't realize Github lists commits of a pull request in
chronological order, the opposite of "git log",
can be done by distinct people, so my little available time can
be spent on upgrading Python in GUB, which is now for me a challenge as
great as hacking the build system a decade ago.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypo
FWIW I had success on Ubuntu 14.04 with GUB master branch merged with
PRs #53, #54, #55, #56 and LilyPond revision 17c0c744 from master
branch. What are the commonly agreed criteria for merging GUB pull
requests? FTR I have write access on gperciva/gub, but
lilypond-book call, and linux-(arch)::gs needs a different
directory in LD_LIBRARY_PATH, namely target/linux-64/root/usr/lib.
I haven't investigated when and why such a wrapper would be necessary,
but if it is, it might be saner to define
LD_LIBRARY_PATH=%(system_prefix)s/lib${LD_LIBRARY_PATH:+
esting binaries, "localdoc", and examining regresssion tests
comparison, with several branches (master and stable/2.20) have
certainly a higher priority.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
-doc".
I'll do other builds from scratch, testing newer pull requests on top
of #53-60, and will also make an attempt on Fedora 29 plus local
install of GCC 7 (with GCC 8 shipped with this distro, tools:guile GUB
build fails, and it seems
eted
nearly 3/4 of the migration of a big patch for cross-building Python
2.7; lots of tests of Python scripts in binaries may be necessary when
this is ready to be built.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
te.
> Right now, lilypond's behaviour is quite
> erratic and has some bugs...
You allude to many issues we had with GUB builds, don't you?
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
r for potential users who are not
comfortable with handling complex software dependencies.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
code. With this in mind, the last
revised algorithm you sent looks good to me.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
were
interpreted in Latin-1.
FWIW I used as a test input
https://www.mutopiaproject.org/cgibin/piece-info.cgi?id=2240
with application of convert-ly.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
with Ccache), I get the same error as with
system's GCC (8.2.1), error you've already reported.
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Werner LEMBERG wrote:
> Yes, I think we should prevent that, if possible – they are indeed of
> no practical use.
It's certainly possible, it must boil down to filtering out web from
TEXI_FILES or TEXINFO_MANUALS, and give this to PDF_FILES definition in
the makefiles. I'm testing a patch for this
Hi folks,
As suggested by Werner on February 8th in "Please test GUB" thread, we
should update tex/texinfo.tex in our sources from Texinfo git repo. Is
there any objection to applying this change on both staging and
stable/2.20 branches without the usual review process?
I also have another reque
Werner LEMBERG wrote:
> Obviously, I don't have objections :-)
OK, upon guidelines recalled by David, I did this only for staging
branch for now, after a succesful clean make, 'make doc' and glances at
the Essay and Notation manual in PDF.
Best,
John
_
Le mer. 20 févr. 2019 à 00:26, John Mandereau a
écrit :
> It's certainly possible, it must boil down to filtering out web from
> TEXI_FILES or TEXINFO_MANUALS, and give this to PDF_FILES definition in
> the makefiles. I'm testing a patch for this.
>
Could somebody ple
v.villen...@gmail.com wrote:
> page-turn-page-breaking.cc: In instantiation of 'bool is_break(T*)
> [with
> T = Grob]':
> page-turn-page-breaking.cc:50:54: required from here
> page-turn-page-breaking.cc:38:3: warning: operation on '*0' may be
> undefined [-Wsequence-point]
> if (turnable
>
On February 21 2019 18:07 +, Trevor wrote:
> Added with Developer privileges. Welcome!
Thanks Trevor; at the end of the issue creation, an auto-generated
email bounced with
"""
Your mail to 'Testlilyissues-auto' with the subject
[testlilyissues:issues] #5482 Do not build PDFs from the web
David Kastrup wrote:
> Huh. Maybe the Ubuntu compilation of gcc/g++ disabled some warnings?
>
> g++ --verbose
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-l
Werner LEMBERG wrote:
> we had some good progress with GUB. However, in the last few weeks
> the development stalled, which is not good. I thus propose the
> following.
>
> * The pull requests as described in
>
> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg0022
> 1.html
>
Werner LEMBERG wrote:
> https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmake
> file#newcode54
> Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB
> = $(filter-out
> web,$(TEXINFO_MANUALS))
> LGTM except this variable name. Could you invent a different one?
What about "TEXINFO
Le dimanche 24 février 2019 à 21:04 +0100, John Mandereau a écrit :
> Werner LEMBERG wrote:
> > https://codereview.appspot.com/363930043/diff/1/Documentation/GNUma
> > ke
> > file#newcode54
> > Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB
> > = $(fil
Werner LEMBERG wrote:
> Yes, I could try to generate the packages and upload them to a given
> place. However, I've never done a lilypond release before, so any
> guidance would be helpful.
I hope the guidance from our Contributors' Guide is as good for this as
it has been for me to get back to L
Le dim. 24 févr. 2019 à 23:09, John Mandereau a
écrit :
> > What about "TEXINFO_MANUALS_WITHOUT_WEB"?
>
> To make the contest a little bit more interesting, what about the
> following ones?
>
> NON_WEBSITE_TEXINFO_MANUALS
> TEXINFO_MANUALS_WITHOUT_WEBSITE
Hi folks,
On Sun, 2019-03-03 at 16:01 +, James Lowe wrote:
>
> Push:
>
> 5477 Broken links in website pages - john-mandereau
> https://sourceforge.net/p/testlilyissues/issues/5477
> http://codereview.appspot.com/361790043
Sorry for the delay, I pushed it a couple of
This looks good to me, except a phrasing nitpick.
https://codereview.appspot.com/566540043/diff/566530044/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
https://codereview.appspot.com/566540043/diff/566530044/Documentation/contributor/sourc
Hi folks,
I already asked almost one month ago if we could we cherry-pick the
following commits from master:
88633ac Issue 5469/2: Add `TEX` environemnt variable for texi2pdf
e757c64 Issue 5469/1: Tweak wrapped lines
002382c Issue 5463: Fix dblatex uses xetex backend
Without them, GUB build on s
On Tue, 2019-03-19 at 00:00 +0100, David Kastrup wrote:
> The currently rather long persisting release-less state is quite a
> nuisance and I have problems understanding what stopped our releases
> from working when they did work previously and I am not aware of
> things particularly breaking this
On Tue, 2019-03-19 at 11:20 +, Phil Holmes wrote:
> Please let me/the list know if you're successful. It would also help
> me immensely if you could post a set of instructions (like the ones
> for development builds in the CG at
> http://lilypond.org/doc/v2.19/Documentation/contributor/minor-
On Tue, 2019-03-19 at 11:20 +, Phil Holmes wrote:
> John,
>
> Please let me/the list know if you're successful.
I completed a non-clean GUB build with stable/2.20 branch, in 1h07min,
done after a successful GUB build of master branch (4h05min, on a
laptop with Intel Core i7-7500U and Debian t
On Wed, 2019-03-20 at 12:53 +, Phil Holmes wrote:
> I understand this would be possible if someone puched a change to
> release/unstable without it going through staging/master. However,
> in the
> life of LilyPond I don't think it has ever happened. so may not be
> worth
> being too concer
On Fri, 2019-03-22 at 13:41 +, Phil Holmes wrote:
> The website is now also updated - I had previously forgotten that I
> would
> need to update news and VERSION etc. in staging and master. This has
> to be
> done because the website is built from master automatically.
Great!
I'm a bit puz
end, testing
them on PureOS (a Debian 10 Buster derivative).
Best
--
John Mandereau
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
C++ in LLVM since one
year ago, LilyPond depends on GCC or equivalent, see the thread
starting at
https://lists.gnu.org/archive/html/lilypond-devel/2018-11/msg00019.html
Best
--
John Mandereau
his patch for building GUB on PureOS
(Debian 10 derivative), for both master and stable/2.20, the former
built from scratch and the latter after having moved uploads directory
and "rm -rf target/*/*/*lilypond*".
Best
--
John Mandereau
enough to effectively accept GUB pull
requests; I'd have added nothing more than a remark that lilypond-
ancient was a GUB setup for building ancient LilyPond versions on
recent systems; given the amount on work to build current versions, I
can understand it's been removed.
Best
--
John Mandereau
On Mon, 2019-11-18 at 19:29 +0100, Jonas Hahnfeld wrote:
> Sure, but does it fix an issue that makes it "critical" enough to add
> the new relocation code fairly late in the process?
For the discussion that motivated these changes, see
https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg0
On Mon, 2019-11-04 at 10:38 +0100, Jonas Hahnfeld wrote:
> To be honest I don't know because the binaries don't even start to
> execute due to not having the correct libc. So what's the expected
> procedure here? There is no libc in the installation tarball, is there
> some documentation on what's
Le dimanche 13 décembre 2009 à 16:48 +0100, David Kastrup a écrit :
> So if the hashed filenames pass through make (no idea if they do)
They don't, they pass between lilypond-book and lilypond.
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
___
Hi Han-Wen,
Le dimanche 13 décembre 2009 à 13:55 -0200, Han-Wen Nienhuys a écrit :
> Oh wait - there is one thing I did not think about: snippets may be
> shared by different documents, so if you use make -jX it is
> conceivable that make invokes two separate lilypond processes that
> have non-empt
Le dimanche 13 décembre 2009 à 16:13 -0200, Han-Wen Nienhuys a écrit :
> The lock could just be per file, using file system locks (which are
> simple to use and efficient). Probably ly:parse-file should just lock
> and unlock the file while processing it.
This may be the best solution if we fail
Le lundi 14 décembre 2009 à 14:08 +0100, David Kastrup a écrit :
> Maybe lilypond-book could create its temporary files in a local
> directory with a unique name (involving host and process id, for
> example). It sounds like this could do the trick for parallel
> lilypond-book runs.
No. We share
Le lundi 14 décembre 2009 à 16:05 +, Graham Percival a écrit :
> That could be what's happening... not necessarily parallel
> lilypond-book runs in the same directory, but building the english
> docs + translations at the same time with lilypond-book in
> parallel?
AFAIK and have experienced,
Le mardi 15 décembre 2009 à 15:11 +0100, Mats Bengtsson a écrit :
> On the other hand, Mark's question is highly relevant. Why not use the
> starting note of the voice? I, myself, have mistyped the octave for the
> C at several times and would probably have done it correctly more times
> if I ha
built
only in HTML format, like the existing Japanese translation.
Best,
John Mandereau
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Le jeudi 17 décembre 2009 à 01:11 +, Graham Percival a écrit :
> The new website is lacking the search box. The init file
> contains:
>
> if ($sergsmoeivjriohuemf) {
> ...
> my $name = "search-box.html"
>
> which looks quite interesting. Is this a holdover from the
> Hun
Le jeudi 17 décembre 2009 à 15:31 +0100, Werner LEMBERG a écrit :
> Yeah. I can imagine that autogen.sh script handles this – for regular
> tarballs this isn't necessary.
>
> John?
Sorry, but I'd rather concentrate on other things than the old build
system (which include autogen and configure),
Hi Mark,
Le dimanche 20 décembre 2009 à 22:06 -0800, Mark Polesky a écrit :
> $ mkdir lilypond; cd lilypond
> $ git init
> $ mkdir lilypond-translation; cd lilypond-translation
> $ git init
Although I already read this section in the CG, I missed this detail
you're pointing out. If you're still
Le dimanche 20 décembre 2009 à 13:58 -0800, Mark Polesky a écrit :
> If a less verbose build output if desired, the variable
> QUIET_BUILD may be set to 1 on make command line, or in
> ‘local.make’ at top of the build tree.
>
> How do I make this work? Neither of these work for me:
>
> QUIET_BUI
Le dimanche 13 décembre 2009 à 15:55 +, Graham Percival a écrit :
> diff --git a/scripts/lilypond-book.py b/scripts/lilypond-book.py
> index 392ddd0..b9731f1 100644
> --- a/scripts/lilypond-book.py
> +++ b/scripts/lilypond-book.py
> @@ -1273,7 +1273,11 @@ left-margin-default right-margin-defaul
Le vendredi 18 décembre 2009 à 00:38 -0200, Han-Wen Nienhuys a écrit :
> We already have a plausible explanation, and a fairly simple solution:
> use flock() in ly:parse-file on the .ly file.
I think it's better to sanitize lilypond-book behaviour instead, namely
fixing relevant_contents and make
Le mercredi 23 décembre 2009 à 08:41 +0100, Marc Hohl a écrit :
> Carl Sorensen schrieb:
> > Looks good to me. I'd also like to see half-way between this attempt and
> > the first attempt, not because I think this is wrong, but because I tend to
> > find optimum settings by finding "not enough" an
Le mercredi 23 décembre 2009 à 12:58 -0200, Haake care of both things
later.
> My take is that independent lp-book runs (by make -jX) share ly file
> snippets.
I've never seen any proof of this situation. I tried to make sure make
doesn't call simultaneous lilypond-book instances, and AFAIK it ha
Le lundi 21 décembre 2009 à 22:28 +0100, Translation Project Robot a
écrit :
> A new POT file for textual domain 'lilypond' has been made available
> to the language teams for translation. It is archived as:
>
> http://translationproject.org/POT-files/lilypond-2.13.7.pot
What is this? The P
Le mercredi 23 décembre 2009 à 19:51 +0100, Jan Nieuwenhuizen a écrit :
> Also, it seems that the nl.po has not been updated with the latest
> 2.13.9 strings; so you might run into problems getting this accepted
> until that is fixed, along with the newly introduced strings.
I'm waiting a reply fr
Le mercredi 23 décembre 2009 à 18:49 +, Graham Percival a écrit :
> file from VC not distributed: lilypond-2.13.10/Documentation/es/web.texi
> file from VC not distributed:
> lilypond-2.13.10/Documentation/es/web/GNUmakefile
> file from VC not distributed:
> lilypond-2.13.10/Documentation/es/w
Hi guys,
In my way of fixing lilypond-book hashing, I'm afraid I'll have to
revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
md5 hashing strategy", because ignoring fragment options for the hash
which have an impact on music typesetting is wrong. I'll not simply
revert that
Le lundi 21 décembre 2009 à 21:44 -0800, Mark Polesky a écrit :
> Except that once I designate a remote branch `origin', I
> need to name the other branch something else? My
> understanding is hazy, but from the build directory of my
> `master' repo, adding the lilypond/translation branch as in
>
Le lundi 21 décembre 2009 à 21:44 -0800, Mark Polesky a écrit :
> Except that once I designate a remote branch `origin', I
> need to name the other branch something else?
If you do "git branch -a", you may discover that the remote branch is
actually origin/BRANCH_NAME, origin is just a "remote" (w
Le mercredi 23 décembre 2009 à 09:41 -0700, Carl Sorensen a écrit :
> Having reviewed all four of the clefs, I think I like 3 the best, but I have
> a hard time deciding between 3 and 4. Either of them seems fine to me.
Looking at two-by-two comparisons of cropped graphics sent on the list,
I agr
Le mercredi 23 décembre 2009 à 22:45 +, Graham Percival a écrit :
> Remember why we did this: the regtest filenames weren't matching
> up between versions because the [options] changed.
Sorry for having been idle at that time, but regtest comparison
shouldn't prevent us from changing lilypond-
Le mercredi 23 décembre 2009 à 23:17 +, Graham Percival a écrit :
> Yes; that's why we changed the hash calculation from self.ly() to
> self.full_ly()
You meant the opposite.
> -- produced lily-abcd1234 filename would not
> depend on the fragment options,
This is wrong. lilypond-book rel
Le jeudi 24 décembre 2009 à 01:37 +0100, Francisco Vila a écrit :
> - The Spanish description has accented characters, I'd like them to
> appear properly listed like others do.
>
> (btw I don't understand the reasons given for the latter not being
> satisfied; if the host can not do it, how can
Hi folks,
Please review
http://codereview.appspot.com/183048
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypon
Le jeudi 24 décembre 2009 à 03:28 +0100, Francisco Vila a écrit :
> Now I understand why I had to touch the music itself to make snippets
> regenerated on a set of exercises.
I hope my patch on Rietveld will completely fix this:
- all fragment options are taken into account in the hash, so a chang
Le jeudi 24 décembre 2009 à 20:52 +, Graham Percival a écrit :
> I can now confirm that the regtest comparison is done on the files in
> input/regression/out-test/ , which are created via "make test".
More precisely, the comparison is done between
input/regression/out-test/ and input/regressio
Le jeudi 24 décembre 2009 à 19:30 +, Graham Percival a écrit :
> Ah, we're talking about two different kinds of hashes. One hash
> decides if the snippet should be (re)processed -- I don't care
> about that one. Do whatever seems sensible for that.
>
> The other kind of hashing produces the
near to the
Release Candidate state.
Best regards and merry Christmas,
John Mandereau
signature.asc
Description: Ceci est une partie de message numériquement signée
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Le jeudi 24 décembre 2009 à 10:18 -0800, Patrick McCarty a écrit :
> Thank you for noticing this, John. I'll admit I did not think through
> the issue carefully enough when I made that commit.
>
> I'm not qualified to comment on your patch to fix the issue, but I
> trust your judgment here.
OK,
Le jeudi 24 décembre 2009 à 22:21 +0100, Reinhold Kainhofer a écrit :
> I would definitely like that option. Every now and then, when working with
> lilypond-book based projects, I also need to send e.g. an image per mail or
> insert an image into some word-processing app. In these cases, such an
Le jeudi 24 décembre 2009 à 21:17 +, Graham Percival a écrit :
> commit 6c1cdaa331972442a8fd62d98da5adebfaa9a17b
>
> I thought that texinfo macros were supposed to have a {} after them --
> I mean, it's not /required/ for arguments without any macros, but...?
..but see Texi2HTML warnings if "
Le jeudi 10 décembre 2009 à 15:50 +, Graham Percival a écrit :
> Ok. Let's just agree to disagree: you think it's important, but I
> don't think it's important. If somebody (be it you or Denes)
> writes a patch, I'm willing to test it on GUB.
I just tried factorizing French macro definitions
Le vendredi 25 décembre 2009 à 14:29 +, Graham Percival a écrit :
> > ..but see Texi2HTML warnings if "@insertcopying{}" is used.
>
> I know about those warnings.
Then, why the mao do you waste our time with this thread? :-)
> I guess that in this case, it doesn't really matter.
Indeed, th
Le vendredi 25 décembre 2009 à 14:57 +, Graham Percival a écrit :
> I was wondering if I was wrong about texinfo. It's been known to
> happen.
Texinfo is not a well-defined language, it's defined only by what the
formatters support and to some extent by Texinfo manual, so it's
practically imp
Le vendredi 25 décembre 2009 à 22:17 +, Graham Percival a écrit :
> The regtests are not used in the docs. Period.
>
> It's possible that a new feature might a file in
> Documentation/snippets/new/ which is an exact copy of a new
> regtest (actually, I've encouraged this), but we don't have m
401 - 500 of 1573 matches
Mail list logo
