2013/7/14 Frédéric Bron :
> I also read the proposed ideas in "notes about solution.txt" but I
> admit that it is difficult to understand for a novice to the lilypond
> C++ code. However, thanks for having written all this, I am sure it
> will become clearer later.
Since i've been thinking about t
> Could you take a look at readme.txt in Dropbox folder and confirm that
> it explains the
> issue?
Yes, I started from there.
I also read the proposed ideas in "notes about solution.txt" but I
admit that it is difficult to understand for a novice to the lilypond
C++ code. However, thanks for hav
2013/7/14 Frédéric Bron :
>> Of course not! This is just a simulation of a wider spacing.
>> Is this clearer now?
>
> That's fine now. Thanks,
> Frédéric
Could you take a look at readme.txt in Dropbox folder and confirm that
it explains the
issue? Other people might have similar questions.
than
Frédéric Bron writes:
[...]
>> We have very few high-quality developers with significant resources
>> for working on LilyPond, and minimal peer review. As a result, any
>> particularly complex task is very likely to be implemented in a quite
>> suboptimal and underdocumented manner and with cod
> Of course not! This is just a simulation of a wider spacing.
> Is this clearer now?
That's fine now. Thanks,
Frédéric
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
>> I see that boost is not used. Is it deliberate? These are c++03
>> libraries and most of them have been the source of the new standard.
>
> "source of standard" means that they are liable to change particularly
> in the course of becoming part of a standard.
I use boost every day for my profess
immanuel litzroth writes:
> On Sun, Jul 14, 2013 at 9:58 PM, David Kastrup wrote:
>
>> immanuel litzroth writes:
>>
>> > On Sun, Jul 14, 2013 at 9:20 PM, David Kastrup wrote:
>> >
>> >> They are also humongous, which means a quite larger amount of work
>> >> for GUB.
>> >>
>> > What do you mea
On Sun, Jul 14, 2013 at 9:58 PM, David Kastrup wrote:
> immanuel litzroth writes:
>
> > On Sun, Jul 14, 2013 at 9:20 PM, David Kastrup wrote:
> >
> >> They are also humongous, which means a quite larger amount of work
> >> for GUB.
> >>
> > What do you mean with humongous? Boost is large becaus
immanuel litzroth writes:
> On Sun, Jul 14, 2013 at 9:20 PM, David Kastrup wrote:
>
>> They are also humongous, which means a quite larger amount of work
>> for GUB.
>>
> What do you mean with humongous? Boost is large because it has a lot
> of stuff.
What's your point? "has a lot of stuff" is
On Sun, Jul 14, 2013 at 9:20 PM, David Kastrup wrote:
> Frédéric Bron writes:
>
> >> Change them so that they will fail using anything but C++11? That
> >> sounds like it would not buy us anything but trouble at the current
> >> point of time.
> >
> > OK, I forget that.
> > I see that boost is
Frédéric Bron writes:
>> Change them so that they will fail using anything but C++11? That
>> sounds like it would not buy us anything but trouble at the current
>> point of time.
>
> OK, I forget that.
> I see that boost is not used. Is it deliberate? These are c++03
> libraries and most of the
2013/7/14 Frédéric Bron :
>>> I see this in your "bad" examples of ties:
>>> d'4~ s4 d' s2 e'4~ s4 e' s
>>>
>>> How do you justify that this should work with non logical spacers included?
>>
>> What do you mean by "non logical spacers"? I don't quite understand
>> this question.
>
> I mean why wou
>> I see this in your "bad" examples of ties:
>> d'4~ s4 d' s2 e'4~ s4 e' s
>>
>> How do you justify that this should work with non logical spacers included?
>
> What do you mean by "non logical spacers"? I don't quite understand
> this question.
I mean why would you write d'4~ s4 d' in real life
Hi Frederic,
2013/7/14 Frédéric Bron :
> Hi Janek,
>
> I see this in your "bad" examples of ties:
> d'4~ s4 d' s2 e'4~ s4 e' s
>
> How do you justify that this should work with non logical spacers included?
What do you mean by "non logical spacers"? I don't quite understand
this question.
> I t
> Change them so that they will fail using anything but C++11? That
> sounds like it would not buy us anything but trouble at the current
> point of time.
OK, I forget that.
I see that boost is not used. Is it deliberate? These are c++03
libraries and most of them have been the source of the new
Hi Janek,
I see this in your "bad" examples of ties:
d'4~ s4 d' s2 e'4~ s4 e' s
How do you justify that this should work with non logical spacers included?
I tried to replace this with logical spacers and do not get any issue:
<< {
> \repeat unfold 8 { d''8[ d''] }
} \\ {
d'4~ d' e'4~
Frédéric Bron writes:
> Hi,
>
> g++ defaults to the C++ standard of 2003. 2 years ago a new standard
> has been published with a log of improvements.
> Today the g++ commands in the build process of lilypond do not specify
> any standard so that it defaults to c++03.
> Could we switch to c++11?
- Original Message -
From: "David Kastrup"
To:
Sent: Sunday, July 14, 2013 5:45 PM
Subject: Re: Backtrace from LilyPond crashing while running make doc
"Phil Holmes" writes:
As I've said earlier, I consistently get a crash trying to make doc,
and the crash continues to occur whils
"Phil Holmes" writes:
> As I've said earlier, I consistently get a crash trying to make doc,
> and the crash continues to occur whilst making the preview of
> orchestra.ly. I've followed David's instructions and created the
> attached backtrace. This was created using ../configure
> --disable-o
>
> g++ defaults to the C++ standard of 2003. 2 years ago a new standard
> has been published with a log of improvements.
>
We've been using selected features from C++11 for a while now, and we are
very happy with the improvements. Features like strongly typed enums
are worth the switch alone.
To
As I've said earlier, I consistently get a crash trying to make doc, and the
crash continues to occur whilst making the preview of orchestra.ly. I've
followed David's instructions and created the attached backtrace. This was
created using ../configure --disable-optimising (the same happens wit
Hi,
g++ defaults to the C++ standard of 2003. 2 years ago a new standard
has been published with a log of improvements.
Today the g++ commands in the build process of lilypond do not specify
any standard so that it defaults to c++03.
Could we switch to c++11?
I suspect that a test would be require
I've built the release and copied the Windows installer to my windows box,
and confirmed that this does not crash with the Issue 3432 test case.
I'll be uploading the build later this afternoon, when I don't need my
internet bandwidth.
--
Phil Holmes
___
23 matches
Mail list logo
