On Sat, Aug 14, 2010 at 5:23 PM, Patrick McCarty pnor...@gmail.com wrote:
On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels t.dani...@treda.co.uk wrote:
The mingw binary of 2.13.30 gives the following error
under Vista on my system:
Running lilypond-book
Traceback (most recent call last):
carl.d.soren...@gmail.com writes:
On 2010/08/14 19:47:59, Neil Puttock wrote:
Since these are bound with defaults above, you don't need to use
chain-assoc-get
(radius size)
Done. I forgot about how nifty the new interface is that David made
possible.
Actually, the niftiness is due to
Patrick McCarty wrote Sunday, August 15, 2010 7:27 AM
On Sat, Aug 14, 2010 at 5:23 PM, Patrick McCarty
pnor...@gmail.com wrote:
On Sat, Aug 14, 2010 at 4:10 PM, Trevor Daniels
t.dani...@treda.co.uk wrote:
The mingw binary of 2.13.30 gives the following error
under Vista on my system:
Running
On 8/15/10 2:39 AM, David Kastrup d...@gnu.org wrote:
carl.d.soren...@gmail.com writes:
On 2010/08/14 19:47:59, Neil Puttock wrote:
Since these are bound with defaults above, you don't need to use
chain-assoc-get
(radius size)
Done. I forgot about how nifty the new interface is that
Trevor Daniels wrote:
The mingw binary of 2.13.30 gives the following error
under Vista on my system:
Running lilypond-book
Traceback (most recent call last):
File c:/program files/lilypond/usr/bin/lilypond-book.py, line
86, in ?
import book_base as BookBase
File
On 14 August 2010 10:35, Phil Holmes m...@philholmes.net wrote:
I've not been able to access the LSR since Friday. Is it down?
It seems, indeed.
And according to downforeveryoneorjustme.com it is down for everyone.
http://downforeveryoneorjustme.com/http://lsr.dsi.unimi.it/
Cheers,
Xavier
Hi, I'm just trying to improve the documentation of
define-markup-command and define-markup-command-list. Those commands
have some functionality for defining aliases to existing commands. For
one thing, I have my doubts that this works properly, for another, it
complicates implementation and
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
Hi, I'm just trying to improve the documentation of
define-markup-command and define-markup-command-list. Those commands
have some functionality for defining aliases to existing commands. For
one thing, I have my doubts that this
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
Hi, I'm just trying to improve the documentation of
define-markup-command and define-markup-command-list. Those commands
have some functionality for defining aliases to existing commands. For
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
IMO, getting rid of bit-rotted code is always a good idea.
Should it
be wrapped in a full review process?
I think so. The full
On Sun, Aug 15, 2010 at 2:39 PM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
What is the general stance towards cleanup (of unused dormant stuff
never documented for general use) like that as long as it is contained
in separate commits and not intermingled with
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
IMO, getting rid of bit-rotted code is always a good idea.
Should it
be wrapped in a full
On 8/15/10 8:06 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
IMO, getting rid of bit-rotted code is
Graham Percival gra...@percival-music.ca writes:
david
we don't *have* a full review process in any meaningful sense of the
term. Especially not for cleaning up things.
As evidence, consider:
http://codereview.appspot.com/1724041/show
- big initial patch
- lots of comments about
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 8:06 AM, David Kastrup d...@gnu.org wrote:
Whatever. I'll jump through the hoops for now. I am not confident
that I will consider doing cleanup worth the trouble in future. If
you have to invest those resources, it distracts from what
On 8/15/10 8:15 AM, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
david
we don't *have* a full review process in any meaningful sense of the
term. Especially not for cleaning up things.
As evidence, consider:
On Sun, Aug 15, 2010 at 3:15 PM, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
That's a huge black mark against our development process.
Not the process per se, but try doing this on Rietveld. Those are lots
of changes in small files. For every single
On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
Well, FWIW, Graham agrees with you and not with me, so you could
follow Graham's advice instead of mine.
There is sufficient disagreement that I consider it useful to get a more
Graham Percival gra...@percival-music.ca writes:
On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
Well, FWIW, Graham agrees with you and not with me, so you could
follow Graham's advice instead of mine.
There is sufficient
On Sun, Aug 15, 2010 at 3:47 PM, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
On Sun, Aug 15, 2010 at 3:18 PM, David Kastrup d...@gnu.org wrote:
There is sufficient disagreement that I consider it useful to get a
more qualified point of view.
That would
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
IMO, getting rid of bit-rotted code is always a good idea.
Should it
be wrapped in a full
2010/8/13 Graham Percival gra...@percival-music.ca:
Translators: at the moment, I'm cautiously predicting that 2.14.0 will
be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice
before 2.14.0 -- each release candidate is such a warning. Francisco,
you're in charge of sending
David Kastrup d...@gnu.org writes:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 6:48 AM, David Kastrup d...@gnu.org wrote:
IMO, getting rid of bit-rotted code is always a good idea.
On 8/15/10 9:14 AM, David Kastrup d...@gnu.org wrote:
The development work should go up to Rietveld, the cleanup should go up
to Rietveld. git-cl can associate only one review per branch. So I
need to fork out the cleanup from the middle of the branch. Possibly by
rebasing it to the tip
The aliasing functionality is unused in the current source code, not
documented at user level, and not sure to be fully working (there are no
regtests to check). Documenting it complicates the documentation
without an immediately visible user benefit.
The patch likely does not apply to a
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
I think so. The full review process for removing old stuff is
generally very short and sweet (post the patch, somebody important
says OK), so I don't
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 9:14 AM, David Kastrup d...@gnu.org wrote:
The development work should go up to Rietveld, the cleanup should go up
to Rietveld. git-cl can associate only one review per branch. So I
need to fork out the cleanup from the middle of the
URL:http://codereview.appspot.com/1991043
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Le 15/08/2010 17:20, Francisco Vila disait :
2010/8/13 Graham Percivalgra...@percival-music.ca:
Translators: at the moment, I'm cautiously predicting that 2.14.0 will
be 4 to 8 weeks away. You will have at least 2 weeks (14 days) notice
before 2.14.0 -- each release candidate is such a
Should it be wrapped in a full review process?
I think so. The full review process for removing old stuff is
generally very short and sweet (post the patch, somebody important
says OK), so I don't think it hurts a bit to do it.
Well, IMHO, for trivial things: Just do it!
Werner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Has anyone noticed this problem on the second and following pages of PDF
output, I've reproduced this with 2.13.17 and with 2.13.29. I'd like
to know if anyone else has noticed this.
The shortInstrumentNames you should see are:
Picc 1
Picc
On 8/15/10 9:40 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
I think so. The full review process for removing old stuff is
generally very short and sweet
LGTM.
Further info: This code has been in the file since
114c05e7b0e992de7dbdd0958d23eb8d2ab1eaae
(the file name at that time was scm/new-markup.scm).
I think that the alternate syntax has never been used in the main source
tree;
it could have been used (but it's doubtful) in an individual
LGTM.
Thanks
http://codereview.appspot.com/1991043/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 9:40 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/15/10 7:39 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
I think so. The full review process for removing old
In the patch
Author: Graham Percival gra...@percival-music.ca 2010-08-15 19:14:33
Committer: Graham Percival gra...@percival-music.ca 2010-08-15 19:14:33
Parent: cfe29e5a0720f8e5ca7e220c77e9cf8ab2d08306 (Doc: CG: add warning about
test-output-distance.)
Branches: master, remotes/origin/master
On Mon, Aug 16, 2010 at 05:00:37AM +0200, David Kastrup wrote:
In the patch
Doc: CG: begin cleaning up Releases chapter.
I read a number of changes like
+...@item
* write preface section for manual.
Yes.
It would seem to me that adding the @item lines should be accompanied by
37 matches
Mail list logo
