Implements DOM-id property for grobs. (issue 5504106)

[pnorcks]

LGTM


https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm
File scm/output-ps.scm (right):

https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm#newcode258
scm/output-ps.scm:258: (define (open-node n) n)
I don't see this procedure used anywhere...

https://codereview.appspot.com/5504106/diff/1/scm/output-ps.scm#newcode261
scm/output-ps.scm:261: (define (close-node n) n)
.. or this one.

https://codereview.appspot.com/5504106/

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

PATCH: Countdown to 20120108

[Colin Campbell]

For Sunday January 8th

Issue 2170 : 
Patch: Updates makelsr to point to lilypond exe - R5489134 



Some syntax comments from Graham, but they shouldn't hold up the countdown.

Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )

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

Re: "include" music-function

[David Kastrup]

Jan-Peter Voigt  writes:

> #(define-public includeLocal (define-music-function (parser location
> file)(string?)
> (let ((outname (format "~A.ly" (ly:parser-output-name parser)))
>   (locname (car (ly:input-file-line-char-column location
>  (if (or (string=? outname locname)(string-suffix? outname
> locname))
>  (let ((content (ly:gulp-file file)))
>   (ly:parser-include-string parser content)))
>  (make-music 'SequentialMusic 'void #t
>
> \includeLocal "test.ly"
> --snip--
> This function first compares the outname with the location name and
> only includes the file if they match. (This should not work, if you
> have set some output-suffix!)
>
> This is a usable solution to me. But I would like to have the correct
> location info available, while parsing the included file.
> Is it possible to create an arbitrary "include"-music-function? This
> would make it possible, to (for example) include all files in a
> directory or matching a specific pattern.

You can start your string with \sourcefilename and \sourcefileline.
ly:parser-parse-expression has optional arguments for that purpose.  If
you would consider this helpful, I might try fudging this into
parser-include-string as well.

I have not followed the reasons why we would not have
parser-include-file.

-- 
David Kastrup


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

Re: "include" music-function

[David Kastrup]

Jan-Peter Voigt  writes:

> This does not work ... the var "music" is not known in the file
> included with ly:parse-file.
> There has been a function ly:parser-parse-file in 2.12 - and if my
> memory doesn't trick me, there has been discussion on devel why and
> how to remove it.
> This might or might not have been useful in this context.

Maybe.  At that time, I was not acquainted with the code.

> So a question remains: How could I carry defined variables between
> inside-outside ly:parse-file ?

With the current tools, I don't have much of an idea.

-- 
David Kastrup


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

Re: "include" music-function

[Jan-Peter Voigt]

Hello David,

Am 05.01.2012 13:50, schrieb David Kastrup:


Ah yes.  ly:parse-file does not help either?


yes it does, thanks ... but ...

--snip--
#(define-public includeLoc (define-music-function (parser location 
file)(string?)

(let ((outname (format "~A.ly" (ly:parser-output-name parser)))
  (locname (car (ly:input-file-line-char-column location
 (if (or (string=? outname locname)(string-suffix? outname 
locname))

 (ly:parse-file file))
 (make-music 'SequentialMusic 'void #t
--snip--

I nowadays store the music in a scheme structure saved as a singleton in 
a self-made module. If the included file refers to this singleton, the 
music will appear ... great!


Before this, I created variables
--snip--
music = \relative c' { c4 e g c }
\includeLocal "test-music.ly"
--snip--
and used a file
--snip-- (test-music.ly)
{ \music }
--snip--

This does not work ... the var "music" is not known in the file included 
with ly:parse-file.
There has been a function ly:parser-parse-file in 2.12 - and if my 
memory doesn't trick me, there has been discussion on devel why and how 
to remove it.

This might or might not have been useful in this context.
So a question remains: How could I carry defined variables between 
inside-outside ly:parse-file ?


Cheers,
Jan-Peter


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

Re: "include" music-function

[David Kastrup]

Jan-Peter Voigt  writes:

> Hello David,
>> Any reason you don't just do #{ \include #file #} here?
>>
> yes there is:
> --snip--
> \version "2.15.21"
>
> #(define-public includeLocal (define-music-function (parser location
> file)(string?)
> (let ((outname (format "~A.ly" (ly:parser-output-name parser)))
>   (locname (car (ly:input-file-line-char-column location
>  (if (or (string=? outname locname)(string-suffix? outname
> locname))
>  #{ \include $file #}
>  (make-music 'SequentialMusic 'void #t)
>
> \includeLocal "test.ily"
> --snip--
> this places the include in some context, generated by #{ #}.

Ah yes.  ly:parse-file does not help either?

-- 
David Kastrup


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

Re: "include" music-function

[Jan-Peter Voigt]

Hello David,

Any reason you don't just do #{ \include #file #} here?


yes there is:
--snip--
\version "2.15.21"

#(define-public includeLocal (define-music-function (parser location 
file)(string?)

(let ((outname (format "~A.ly" (ly:parser-output-name parser)))
  (locname (car (ly:input-file-line-char-column location
 (if (or (string=? outname locname)(string-suffix? outname 
locname))

 #{ \include $file #}
 (make-music 'SequentialMusic 'void #t)

\includeLocal "test.ily"
--snip--
this places the include in some context, generated by #{ #}.
So if I have:
--snip-- ("test.ily")
\version "2.15.21"

mus = \relative c' {
  c4 e g c
}

{ \mus }
--snip--
it will fail, because I try to assign "mus" here in a contained context.

Cheers,
Jan-Peter


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

@rlsrnamed{Name,Translation} translates also the name in the URI

[Federico Bruni]

Issue 1721 reported that @rlsr{Name} keeps the text in english but 
translates the link in the translated manuals (no idea where the 
translation comes from).

So it recommends to use @rlsrnamed{Name,Translation} instead.

But it looks like @rlsrnamed is affected by the same bug.

Looking through the log file of make doc I've found a lot of errors like 
this:


WARNING: Unable to find node 'Hauteurs' in book snippets.

(look at NR 1.1, you'll find a lot of these broken links)

In general, go to the french NR and search for "Morceaux choisis :": 
you'll see that most of the links are broken.


There are some exceptions, for example this works:
http://lilypond.org/doc/v2.15/Documentation/notation/piano.fr.html

(Claviers link down on the page)

The syntax used is the same: @rlsrnamed{Name,Translation}.
Putting a space after the comma makes any difference.

I can't understand the reason of this weird behaviour.
Can you please explain what's happening?

Thanks,
Federico

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

Re: "include" music-function

[David Kastrup]

Jan-Peter Voigt  writes:

> I am compiling this file directly:
> --snip--
> #(define-public includeLocal (define-music-function (parser location
> file)(string?)
> (let ((outname (format "~A.ly" (ly:parser-output-name parser)))
>   (locname (car (ly:input-file-line-char-column location
>  (if (or (string=? outname locname)(string-suffix? outname
> locname))
>  (let ((content (ly:gulp-file file)))
>   (ly:parser-include-string parser content)))
>  (make-music 'SequentialMusic 'void #t
>
> \includeLocal "test.ly"
> --snip--
> This function first compares the outname with the location name and
> only includes the file if they match. (This should not work, if you
> have set some output-suffix!)
>
> This is a usable solution to me. But I would like to have the correct
> location info available, while parsing the included file.
> Is it possible to create an arbitrary "include"-music-function? This
> would make it possible, to (for example) include all files in a
> directory or matching a specific pattern.

Any reason you don't just do #{ \include #file #} here?

-- 
David Kastrup


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

"include" music-function

[Jan-Peter Voigt]

Dear lily-list-members,

first of all: A happy new year!

In my projects I often combine several files, each containing one piece, 
to a book.
In fact, I store the music in a scheme-based structure to instantiate it 
later.
The included files shall intentionally not create a PDF, so that 
instantiation can be organized in bookparts as needed.
But when I work on a specific piece I want to debug it without compiling 
the whole book.
One solution would be to use frescobaldi and a comment %%master: 
../.ly at the end of the file. But then I have to create a 
master-file for each part.
So I created a music-function to include a testfile wich contains 
instructions to instantiate the music stored in my structures only if I 
am compiling this file directly:

--snip--
#(define-public includeLocal (define-music-function (parser location 
file)(string?)

(let ((outname (format "~A.ly" (ly:parser-output-name parser)))
  (locname (car (ly:input-file-line-char-column location
 (if (or (string=? outname locname)(string-suffix? outname 
locname))

 (let ((content (ly:gulp-file file)))
  (ly:parser-include-string parser content)))
 (make-music 'SequentialMusic 'void #t

\includeLocal "test.ly"
--snip--
This function first compares the outname with the location name and only 
includes the file if they match. (This should not work, if you have set 
some output-suffix!)


This is a usable solution to me. But I would like to have the correct 
location info available, while parsing the included file.
Is it possible to create an arbitrary "include"-music-function? This 
would make it possible, to (for example) include all files in a 
directory or matching a specific pattern.


Cheers,
Jan-Peter


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

Re: (was) Some drum notation questions - (now) problem with noteheads in doc?

[Marc Hohl]

Am 04.01.2012 19:59, schrieb James:

On 4 January 2012 18:55, James  wrote:

Hello,

On 4 January 2012 18:32, Vaylor Trucks  wrote:

I have been using lilypond for years for my own projects and have recently
introduced it to a friend of mine.  He is a drum instructor and has been reading
drum notation for many years.  He's pointed out some things that are
non-standard about the way lilypond handles some drum notation tasks.  Most of
these I have been able to correct using a #(define block.  There are, however,
some things I have not yet been able to crack.

First, for hi-hat, the notation for open and closed are correct, but for the
half-open he would like to appear exactly like the open hi-hat notation, except
the "o" above the stem of the note needs to have a single slash through it.

Also, the note head for a China cymbal he notes by having a standard cross note
head, but with a box around it.

Can anyone point me in the right direction for making these changes?

I have no experience of doing this but you might want to start here

http://lilypond.org/doc/v2.14/Documentation/notation/modifying-stencils

The percussion notes are all here:

http://lilypond.org/doc/v2.14/Documentation/notation/percussion-notes

I've just noticed that most of the note heads on

http://lilypond.org/doc/v2.14/Documentation/notation/percussion-notes

here are semibreves insetad of I assume lots of crosses and circles etc.

The PDF from 2.15.22 also show this.

Can someone verify this?


In the documentation, namely

Documentation/included/percussion-chart.ly

the notes are defined as whole notes:

\drummode {
   \cadenzaOn

   bda1^\markup { \center-align "acousticbassdrum: bda" }

As whole notes make not much sense in percussion parts IMHO,
a change to
  bda4^\

should Do The Right Thing (tm).

Marc




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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Jan 5, 2012, at 11:24 AM, David Kastrup wrote:
>
>> m...@apollinemike.com writes:
>> 
>>> On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
>>> 
 Grob::get_vertical_axis_group is not protected against the case where g
 has an axis group interface but no Y_AXIs parent.
>>> 
>>> I thought it was.  If g has no Y_AXIS parent, then when
>>> get_vertical_axis_group (g->get_parent (Y_AXIS)); is called, the first
>>> test if (!g) will return 0, no?
>> 
>> Grob::get_vertical_axis_group (Grob *g)
>> {
>> if (!g)
>>   return 0;
>> if (Axis_group_interface::has_interface (g)
>> && Align_interface::has_interface (g->get_parent (Y_AXIS)))
>>   return g;
>> return get_vertical_axis_group (g->get_parent (Y_AXIS));
>> 
>> }
>> 
>> You call Align_interface::has_interface (g->get_parent (Y_AXIS)) here
>> before you call get_vertical_axis_group.
>> 
>
> Fixed.

Note: I have no clue about what the code does.  This was just one thing
that did not earn extra credit in the "obviously not wrong" category
with me.  I don't have more to go by at the moment.  And it is scary to
me if that may, at times, be enough.

-- 
David Kastrup


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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[m...@apollinemike.com]

On Jan 5, 2012, at 11:24 AM, David Kastrup wrote:

> m...@apollinemike.com writes:
> 
>> On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
>> 
>>> Grob::get_vertical_axis_group is not protected against the case where g
>>> has an axis group interface but no Y_AXIs parent.
>> 
>> I thought it was.  If g has no Y_AXIS parent, then when
>> get_vertical_axis_group (g->get_parent (Y_AXIS)); is called, the first
>> test if (!g) will return 0, no?
> 
> Grob::get_vertical_axis_group (Grob *g)
> {
> if (!g)
>   return 0;
> if (Axis_group_interface::has_interface (g)
> && Align_interface::has_interface (g->get_parent (Y_AXIS)))
>   return g;
> return get_vertical_axis_group (g->get_parent (Y_AXIS));
> 
> }
> 
> You call Align_interface::has_interface (g->get_parent (Y_AXIS)) here
> before you call get_vertical_axis_group.
> 

Fixed.

Cheers,
MS

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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[David Kastrup]

m...@apollinemike.com writes:

> On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:
>
>> Grob::get_vertical_axis_group is not protected against the case where g
>> has an axis group interface but no Y_AXIs parent.
>
> I thought it was.  If g has no Y_AXIS parent, then when
> get_vertical_axis_group (g->get_parent (Y_AXIS)); is called, the first
> test if (!g) will return 0, no?

Grob::get_vertical_axis_group (Grob *g)
{
  if (!g)
return 0;
  if (Axis_group_interface::has_interface (g)
  && Align_interface::has_interface (g->get_parent (Y_AXIS)))
return g;
  return get_vertical_axis_group (g->get_parent (Y_AXIS));

}

You call Align_interface::has_interface (g->get_parent (Y_AXIS)) here
before you call get_vertical_axis_group.


-- 
David Kastrup


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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[mike]

On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:

> Grob::get_vertical_axis_group is not protected against the case where g
> has an axis group interface but no Y_AXIs parent.

I thought it was.  If g has no Y_AXIS parent, then when get_vertical_axis_group 
(g->get_parent (Y_AXIS)); is called, the first test if (!g) will return 0, no?

> 
> The second if in Grob::vertical_less has a test that can obviously not
> be true.
> 

This is true - fix pushed to staging.

Cheers,
MS




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

Re: critical issues

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Jan 5, 2012, at 9:14 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com"  writes:
>> 
>>> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>>> 
 Correct me if i'm wrong, but my impression is that
 there is no particular direction in which we are going.
>>> 
>>> I'm sure that other people have their pet projects as well.  The
>>> ensemble of these projects is the "direction" of LilyPond, and I don't
>>> see why it would need more of a direction that that.
>> 
>> Because
>> a) LilyPond becomes unmaintainable if everybody implementing his own pet
>> project implements his own pet infrastructure and pet APIs for it.
>> b) LilyPond becomes unusable if everybody implementing his own pet
>> project does not bother paving the path for slightly similar pet
>> projects.
>
> I agree with this - I should have added that those who are
> contributing to LilyPond should do so in a way that favors
> extensibility.

If everybody does it in his own local way, it is more a distraction than
anything else.  "How does one do x in LilyPond?" "Depends on whether you
are talking about functionality written by Mike, David, Han-Wen, Jan,
Graham, Carl or Werner".  That's not what a user wants to hear.

> I agree with the "something like" part of your statement.

If I have something like a fire-breathing dragon with a hunger for human
flesh in my backyard, that is scary enough as a starting point for me.
Even if I got the details wrong.

>> As opposed to an artwork, _any_ corner of LilyPond, no matter how
>> small, can _ruin_ the rest.  You tend to think of bugs and bad code
>> of blemishes at most, when they are actually more like fungi that
>> will eat through the whole canvas and cause it to fall apart.
>
> This is not how I think of bugs.  If I thought of bugs like this, I
> wouldn't have taken the time to squash so many bugs in LilyPond over
> the past several months.

Well, "bug" was probably the wrong word to use here.  A bug is an
isolated phenomenon.  Squashing bugs is fine in itself, but if you find
yourself excelling at it, at one point of time you should probably
rather think about how to better lock your alimentaries away.

>> And if the LilyPond code does not make great strides in the direction
>> of becoming boring by doing everything the same way, projects like
>> "use linear programming" will be dead in the water since you can't
>> streamline a garbage heap of disparate code into doing linear
>> programming if you can't even make it do the same things in the same
>> way everywhere before changing that way to a linear programming one.
>
> I agree.  For example:
>
> The new StemTremolo code does less internal moving of the stencil and
> farms this out to callbacks.
> The new Stem code is decoupled from the Flag code and now behaves
> (along with the flag) more like other grobs.
> The Beam scoring code now looks more like the Stem and Tie scoring
> code on the inside.
>
> I did not work on these projects expressly in order to make LilyPond
> more uniform, but in working on them, I tried to move LilyPond to a
> state where its code was uniform.

Well, uniform code is nice, modular code is better.  You don't need to
worry about uniformity if everything actually calls the same code.  And
if you need to change how it works, being able to do it in one place is
much less likely to cause problems.  Of course, that needs to touch
foreign code in a lot of places instead of just leading by example.  And
that's where actual leadership is helpful since it can _make_ people
change their _own_ code, and they usually are much better qualified to
see problems in connection with those changes than a self-appointed
global janitor can hope to be.

> I think a good policy is that, when working on that which one wants to
> work on, one should always strive to do it in a way that leads to
> better maintainability and extensibility.

If those efforts are not coordinated, there is no end user benefit.
He'll still have to learn the individual ways of every part of LilyPond
he is going to work with.  And if the individual ways are all different
but still over-generalized, this becomes more of a distraction than a
benefit.  Generalization is not useful as an example or a proposal in
some corner of the code.  It makes only sense if it is pervasive.  And
if it is left to the individual's discretion, it can only become
pervasive when the individual is working _everywhere_.  LilyPond has
grown beyond the scope of a single-person project, however.

> 
> There are again two methods of removing the causes of faction: the
> one, by destroying the liberty which is essential to its existence;
> the other, by giving to every citizen the same opinions, the same
> passions, and the same interests.

[...]

Diversity is nice in a community.  It isn't in a program.  And it isn't
all too much in a single entity like a person, either.  There is not
much you can sensibly talk about with a fanatic conservative liberal

Re: critical issues

[m...@apollinemike.com]

On Jan 5, 2012, at 9:14 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>> 
>>> Correct me if i'm wrong, but my impression is that
>>> there is no particular direction in which we are going.
>> 
>> I'm sure that other people have their pet projects as well.  The
>> ensemble of these projects is the "direction" of LilyPond, and I don't
>> see why it would need more of a direction that that.
> 
> Because
> a) LilyPond becomes unmaintainable if everybody implementing his own pet
> project implements his own pet infrastructure and pet APIs for it.
> b) LilyPond becomes unusable if everybody implementing his own pet
> project does not bother paving the path for slightly similar pet
> projects.

I agree with this - I should have added that those who are contributing to 
LilyPond should do so in a way that favors extensibility.

> c) Implementors are scarcer than users.
> 
>> In fact, I think that it is because of some sorta unified direction
>> that for-profit programs can often miss out on adding experimental or
>> innovative features.
> 
> Mike, just recently you said something like you had implemented
> something along the line of spanbars, did not actually understand what
> you were doing, it could not actually do the work you intended it to do,
> but you thought there was nothing wrong with leaving it in until
> somebody hit bugs caused by this code.

I agree with the "something like" part of your statement.

> As opposed to an artwork, _any_ corner of LilyPond, no matter how small,
> can _ruin_ the rest.  You tend to think of bugs and bad code of
> blemishes at most, when they are actually more like fungi that will eat
> through the whole canvas and cause it to fall apart.

This is not how I think of bugs.  If I thought of bugs like this, I wouldn't 
have taken the time to squash so many bugs in LilyPond over the past several 
months.

> And if the LilyPond code does not make great strides in the direction of
> becoming boring by doing everything the same way, projects like "use
> linear programming" will be dead in the water since you can't streamline
> a garbage heap of disparate code into doing linear programming if you
> can't even make it do the same things in the same way everywhere before
> changing that way to a linear programming one.
> 

I agree.  For example:

The new StemTremolo code does less internal moving of the stencil and farms 
this out to callbacks.
The new Stem code is decoupled from the Flag code and now behaves (along with 
the flag) more like other grobs.
The Beam scoring code now looks more like the Stem and Tie scoring code on the 
inside.

I did not work on these projects expressly in order to make LilyPond more 
uniform, but in working on them, I tried to move LilyPond to a state where its 
code was uniform.  I think a good policy is that, when working on that which 
one wants to work on, one should always strive to do it in a way that leads to 
better maintainability and extensibility.  Perhaps this is my American bias, 
but I strongly believe that the value of LilyPond is in the innovativeness of 
those who care enough about it to work on it.  LilyPond's becoming more 
maintainable and extensible is a result of the good coding practices of these 
people.  However, I do not think that a grand unified vision of where LilyPond 
should go (short of several guidelines on style and common practice (many of 
which are already in the CG)) is necessary or desirable.


There are again two methods of removing the causes of faction: the one, by 
destroying the liberty which is essential to its existence; the other, by 
giving to every citizen the same opinions, the same passions, and the same 
interests.

It could never be more truly said than of the first remedy, that it was worse 
than the disease. Liberty is to faction what air is to fire, an aliment without 
which it instantly expires. But it could not be less folly to abolish liberty, 
which is essential to political life, because it nourishes faction, than it 
would be to wish the annihilation of air, which is essential to animal life, 
because it imparts to fire its destructive agency.

The second expedient is as impracticable as the first would be unwise. As long 
as the reason of man continues fallible, and he is at liberty to exercise it, 
different opinions will be formed. As long as the connection subsists between 
his reason and his self-love, his opinions and his passions will have a 
reciprocal influence on each other; and the former will be objects to which the 
latter will attach themselves. The diversity in the faculties of men, from 
which the rights of property originate, is not less an insuperable obstacle to 
a uniformity of interests. The protection of these faculties is the first 
object of government. From the protection of different and unequal faculties of 
acquiring property, the possession of different degrees and kinds of property 
immediatel

Re: critical issues

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>
>> Correct me if i'm wrong, but my impression is that
>> there is no particular direction in which we are going.
>
> I'm sure that other people have their pet projects as well.  The
> ensemble of these projects is the "direction" of LilyPond, and I don't
> see why it would need more of a direction that that.

Because
a) LilyPond becomes unmaintainable if everybody implementing his own pet
project implements his own pet infrastructure and pet APIs for it.
b) LilyPond becomes unusable if everybody implementing his own pet
project does not bother paving the path for slightly similar pet
projects.
c) Implementors are scarcer than users.

> In fact, I think that it is because of some sorta unified direction
> that for-profit programs can often miss out on adding experimental or
> innovative features.

Mike, just recently you said something like you had implemented
something along the line of spanbars, did not actually understand what
you were doing, it could not actually do the work you intended it to do,
but you thought there was nothing wrong with leaving it in until
somebody hit bugs caused by this code.  You can't debug or understand
this sort of experimental and innovative code, and if you can't
yourself, how can you expect anybody else to do?  This sort of bit rot
which nobody know how to either fix or remove(!) is _lethal_ to a
project.  A few dozen things like that, and nobody can make the product
stable again with reasonable amounts of efforts.  Instead you get
symptom-fixing, taking _huge_ amounts of resources in order to let code
nobody understand not hit fatal situations.  And the code not actually
doing anything useful or reliable is causing man-months of maintenance
work.

As opposed to an artwork, _any_ corner of LilyPond, no matter how small,
can _ruin_ the rest.  You tend to think of bugs and bad code of
blemishes at most, when they are actually more like fungi that will eat
through the whole canvas and cause it to fall apart.

Features and innovations come at a cost.  With good modularization and
infrastructure, their cost and benefits are mostly separable from
others: don't use them, and you don't get troubled by them.

LilyPond is not modular enough for that, and it does not have the
infrastructure.  Those don't fall from the sky, and if they are to fit
their purpose, they will require very little experimentation or
innovation but will be perfectly boring.

And if the LilyPond code does not make great strides in the direction of
becoming boring by doing everything the same way, projects like "use
linear programming" will be dead in the water since you can't streamline
a garbage heap of disparate code into doing linear programming if you
can't even make it do the same things in the same way everywhere before
changing that way to a linear programming one.

-- 
David Kastrup

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