On 10/08/12 15:06, Reinhold Kainhofer wrote:
I haven't looked at the code, but I don't see a reason why it wouldn't
be possible to extend that to non-power-of-2 denominators.
Great! :-)
What's odd is that it already works for some cases, but not others -- examples
attached to the bug report h
On 01/08/2012 00:29, Joseph Rushton Wakeling wrote:
> You get a similar error with the following:
>
> \compoundMeter #'((4 2/3 4))
>
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
> c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
>
> That is,
>
> Parsing...ERROR: In procedure ly:make-moment:
> ERROR: Wrong type
On 30/07/12 17:52, Graham Percival wrote:
In general, yes. But some aspects of our syntax haven't been
around for a long time -- footnotes, woodwind fingering, compound
meters, etc. Do we have the best syntax for those? I mean,
maybe David can figure out a way to allow us to write
\compound
Graham Percival writes:
> In general, yes. But some aspects of our syntax haven't been
> around for a long time -- footnotes, woodwind fingering, compound
> meters, etc. Do we have the best syntax for those? I mean,
> maybe David can figure out a way to allow us to write
> \compoundMeter (3+
On Fri, Jul 27, 2012 at 12:56:12PM -0300, Han-Wen Nienhuys wrote:
> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> wrote:
> > Let’s decide whether to try to stabilize the syntax or not. What
> > type of project do we want LilyPond to be? What kinds of
> > guarantees (or at least firm intention
Han-Wen Nienhuys writes:
> On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
> wrote:
>> This summer hasn't been going as I'd hoped -- heh, who am I
>> kidding, this whole year hasn't been going as I'd hoped. Anyway,
>> we seem to have radically different concepts of what "input
>> stabilization
>> Yes: cis, ces, fisis, feses, etc.
>
> And asas.
Yes, I think so.
> Or aeses? Or was that ases?
Never heard.
> bes or heses?
Rather the latter.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/lis
Werner LEMBERG writes:
>>> At least for German, the current syntax is the only good one IMHO,
>>> both for accidentals (for the twelve tones of an octave
>>
>> You mean the 35 tones. After all, we are talking printed output and
>> not Midi.
>
> Yes: cis, ces, fisis, feses, etc.
And asas. Or a
>> At least for German, the current syntax is the only good one IMHO,
>> both for accidentals (for the twelve tones of an octave
>
> You mean the 35 tones. After all, we are talking printed output and
> not Midi.
Yes: cis, ces, fisis, feses, etc.
Werner
__
Werner LEMBERG writes:
>> This is kind of the nub of the issue. I agree that the notation for
>> staff pitches (and octaves) is going to remain stable -- but I'm
>> _not_ convinced that you can guarantee stability for accidentals or
>> durations.
>
> At least for German, the current syntax is th
> This is kind of the nub of the issue. I agree that the notation for
> staff pitches (and octaves) is going to remain stable -- but I'm
> _not_ convinced that you can guarantee stability for accidentals or
> durations.
At least for German, the current syntax is the only good one IMHO,
both for
On Tue, Jul 24, 2012 at 6:09 AM, Graham Percival
wrote:
> This summer hasn't been going as I'd hoped -- heh, who am I
> kidding, this whole year hasn't been going as I'd hoped. Anyway,
> we seem to have radically different concepts of what "input
> stabilization" might mean, or even if it's a goo
On 27/07/12 11:11, Graham Percival wrote:
Think of the stable notation as a subset, not the complete set.
Yes, fair enough -- it's very likely changes can be done additively and if not
for the traditional syntax to be maintained as syntactic sugar.
Hmm. I'll have to think about this more.
On Fri, Jul 27, 2012 at 08:54:47AM +0100, Joseph Rushton Wakeling wrote:
> On 26/07/12 19:19, Graham Percival wrote:
> >I should add some more context. I've just remembered that we have
> >a tutorial (don't ask me how I forgot), and that covers pretty
> >much what I was thinking about "really simp
Just realized I sent my original reply straight to Graham and not to the list --
sorry for the double email :-(
On 26/07/12 19:19, Graham Percival wrote:
I should add some more context. I've just remembered that we have
a tutorial (don't ask me how I forgot), and that covers pretty
much what I
On Thu, Jul 26, 2012 at 06:31:50PM +0100, Joseph Rushton Wakeling wrote:
> >Sounds to me like that was what Graham proposed in the first place.
>
> No, Graham proposed freezing a subset of _Lilypond syntax_. I'm
> proposing that before doing any such thing it's important to look at
> Lilypond's m
On 26/07/12 16:50, David Kastrup wrote:
Joseph Rushton Wakeling writes:
How feasible is it for LilyPond to support a deprecation mechanism for
syntax?
At some time, it will be removed or the warning is pointless. So this
will not address the topic of bitrot for large mostly dormant bodies of
Joseph Rushton Wakeling writes:
> On 24/07/12 10:09, Graham Percival wrote:
>> Let’s decide whether to try to stabilize the syntax or not. What
>> type of project do we want LilyPond to be? What kinds of
>> guarantees (or at least firm intentions) do we want to give to
>> users with respect to li
On 24/07/12 10:09, Graham Percival wrote:
Let’s decide whether to try to stabilize the syntax or not. What
type of project do we want LilyPond to be? What kinds of
guarantees (or at least firm intentions) do we want to give to
users with respect to lilypond 2 or 5 years from now being able to
rea
"Trevor Daniels" writes:
> Graham Percival wrote Tuesday, July 24, 2012 10:09 AM
>
>> ** Summary
>>
>> Let’s decide whether to try to stabilize the syntax or not.
>
> We /should/ try to stabilize the syntax, but trying to do this
> at exactly the time when David is straightening out the
> parser
On Thu, Jul 26, 2012 at 09:02:38AM +0100, Trevor Daniels wrote:
> Graham Percival wrote Tuesday, July 24, 2012 10:09 AM
>
> > Let’s decide whether to try to stabilize the syntax or not.
>
> We /should/ try to stabilize the syntax, but trying to do this
> at exactly the time when David is straight
Graham Percival wrote Tuesday, July 24, 2012 10:09 AM
> ** Summary
>
> Let’s decide whether to try to stabilize the syntax or not.
We /should/ try to stabilize the syntax, but trying to do this
at exactly the time when David is straightening out the
parser seems a bad idea. As yet we do not kno
On Wed, Jul 25, 2012 at 04:58:57AM +, Keith OHara wrote:
> Graham Percival percival-music.ca> writes:
>
> > 2. Define a subset of input as being stable for the 3.x branch.
> > We add regression tests for that subset of notation and
> > forbid running convert-ly on those files.
>
>
Francisco Vila writes:
> 2012/7/24 David Kastrup :
>> convert-ly can't work reliably since it does not understand the
>> structure of LilyPond files.
> (...)
>> Reliable conversions need to understand structure. You can do them on
>> XML. LilyPond is too complex.
> (...)
>
> Right, so a "perfec
On Wed, Jul 25, 2012 at 12:33:30PM +0200, Francisco Vila wrote:
> Speaking of, another stupid idea I once had, was to establish big
> "ranges of music Lily can do", for example "All J.S.Bach" and try to
> find counter-examples that break this set. If we find them, _that_
> would be a good source of
2012/7/24 David Kastrup :
> convert-ly can't work reliably since it does not understand the
> structure of LilyPond files.
(...)
> Reliable conversions need to understand structure. You can do them on
> XML. LilyPond is too complex.
(...)
Right, so a "perfect" convert-ly would solve all problems
Graham Percival percival-music.ca> writes:
> This is a
> problem for projects such as mutopia – a large fraction of their
> .ly files don’t compile with current lilypond. That means that
> they can’t benefit from recent bugfixes; users wanting the sheet
> music in a different size (say, printing
On Tue, Jul 24, 2012 at 3:09 AM, Graham Percival
wrote:
> Some “computer languages” are fairly stable. A TeX or C++ program
> written 10 years ago will probably still compile with no
> modifications (notwithstanding the g++ 4.3 header and namespace
> changes). The same is not true of LilyPond; eve
Nicolas Sceaux writes:
> As a maintainer of 100+ Mbytes of LilyPond files, I'm very interested
> in this topic.
>
> IMHO, we should aim at stabilizing what is currently hardcoded in the
> lexer and parser (notes, file structure...). Nowadays, only David
> works in this area, he has the best expe
Le 24 juil. 2012 à 11:09, Graham Percival a écrit :
> ** Stability or not?
>
> Stabilizing a language is a tricky process. If you do it too
> early, then you’re stuck with whatever mistakes or poor design
> decisions. If you do it too late, then there’s a large body of
> documents in the pre-stab
Francisco Vila writes:
> Take this as the result of a quick reading of the summary. My comment
> as a non-expert is that probably a good, reliably working convert-ly
> is a substitute for syntax stability, because it is precisely what
> will make your documents compile on the long term.
convert-
Hi Graham,
On 24/07/12 10:09, Graham Percival wrote:
>
> Hopefully we can settle those questions now.
> http://lilypond.org/~graham/gop/gop_4.html
>
>
> ** Summary
>
> Let’s decide whether to try to stabilize the syntax or not. What
> type of project do we want LilyPond to be? What kinds of
On Tue, Jul 24, 2012 at 11:00:30AM +0100, Phil Holmes wrote:
> Surely an alternative is to have an archive of stable version
> installations?
We have that already:
http://lilypond.org/old-downloads.html
> We could advise users who require that their work
> will compile into the future to ensure i
On Tue, Jul 24, 2012 at 11:48:13AM +0200, Francisco Vila wrote:
> Take this as the result of a quick reading of the summary. My comment
> as a non-expert is that probably a good, reliably working convert-ly
> is a substitute for syntax stability,
I disagree. For one thing it is often very difficul
- Original Message -
From: "Francisco Vila"
To: "Graham Percival"
Cc:
Sent: Tuesday, July 24, 2012 10:48 AM
Subject: Re: GOP2-3 - GLISS or not
Take this as the result of a quick reading of the summary. My comment
as a non-expert is that probably a good, reliabl
Take this as the result of a quick reading of the summary. My comment
as a non-expert is that probably a good, reliably working convert-ly
is a substitute for syntax stability, because it is precisely what
will make your documents compile on the long term. Your personal,
misfortunate case would not
36 matches
Mail list logo
