Re: How to *hide* a page from the website (and manuals)?
On 02/12/14 16:00, Urs Liska wrote: Am 02.12.2014 16:58, schrieb Paul Morris: Urs Liska wrote I just stumbled over http://lists.gnu.org/archive/html/lilypond-devel/2013-12/msg00187.html and http://lilypond.org/website/gsoc-2012.html I still think it would be best to convert it into a generic GSOC page and start the process of updating it for the next round which will arrive soon enough. Having a persistent page on the website about GSOC signals to any potential future GSOCoders that we're interested (not just for one year but every summer). Sound reasonable but is definitely more work than simply hiding or deleting it. We could ask the mentors listed on that page if they would still be interested in mentoring for 2015, and/or possibly remove their names and replace them with Mentor: to be determined. Just my $0.02 -Paul Added as: https://code.google.com/p/lilypond/issues/detail?id=4215 James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
Then an error didn't occur and correct test.pdf was generated.
https://github.com/trueroad/gub/tree/binutils-2.24
I may pull request if you request it.
Further, even if the runtime is mingw-w64,
bad_alloc occurred when optimization was turned on.
There is this at the end of skyline.cc:
// Should add during ver2.19 (to avoid an endless loop
// when merging identical skylines with a vertical segment)
// if (end = s2-front().end_) s2-pop_front();
Also, the mention of optimization reminds me of one of the horrors of
floating point types: a value in a register can quietly be changed when it is
written to memory. Take a look at some of the “myths” in section 1 of
https://hal.archives-ouvertes.fr/hal-00128124/en/ .
Do the skylines need to deal with the wide range of values that “double
allows? If not, replacing the Real class with a fixed-point math class would
make the code a lot less scaring.
I think that floating point can be used as long as it's used correct.
operator== shouldn't be used for comparison of floating point values.
operator!= shouldn't be used too.
operator and operator may be used.
It's better not to use operator= and operator=.
I tried the following patch.
But bad_alloc occurred.
Then, I think the floating point problem may be unrelated to this case.
```
--- a/lily/skyline.cc 2014-12-01 21:31:21.353083100 +0900
+++ b/lily/skyline.cc 2014-12-04 22:56:17.740379900 +0900
@@ -184,7 +184,7 @@
// conceals and intersection_x involve multiplication and
// division. Avoid that, if we can.
- if (c.y_intercept_ == -infinity_f)
+ if ((isinf(c.y_intercept_) signbit(c.y_intercept_)))
{
if (c.end_ b.end_)
return b.end_;
@@ -197,7 +197,7 @@
return start_x;
Real i = b.intersection_x (c);
- if (i start_x i = b.end_ i = c.end_)
+ if (i start_x (i - b.end_) DBL_EPSILON (i - c.end_)
DBL_EPSILON)
return i;
start_x = c.end_;
```
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
There is this at the end of skyline.cc: // Should add during ver2.19 (to avoid an endless loop // when merging identical skylines with a vertical segment) // if (end = s2-front().end_) s2-pop_front(); I meant at the end of internal_merge_skyline() in skyline.cc. (Fatigue strikes again.) make the code a lot less scaring. scary (derp) I tried the following patch, too. But bad_alloc occurred. ``` --- a/lily/skyline.cc 2014-12-01 21:31:21.353083100 +0900 +++ b/lily/skyline.cc 2014-12-04 23:46:29.488379900 +0900 @@ -329,7 +329,7 @@ s1-pop_front (); // Should add during ver2.19 (to avoid an endless loop // when merging identical skylines with a vertical segment) - // if (end = s2-front().end_) s2-pop_front(); + if (end = s2-front().end_) s2-pop_front(); x = end; } ``` ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: space-alist problem
What defines the distance between a time signature and the next note *with an accidental* (in addition to the TimeSignatures `extra-spacing-width')? I would expect that the `first-note' (or `next-note', if set) element of a TimeSignature's `space-alist' handles this case also, but this assumption is apparently wrong, as the example below shows... In case this is a bug, it would be a quite serious one... Entered as issue #4216. https://code.google.com/p/lilypond/issues/detail?id=4216 Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
On Dec 4, 2014, at 09:58 , Masamichi HOSODA truer...@sea.plala.or.jp wrote:
Also, the mention of optimization reminds me of one of the horrors of
floating point types: a value in a register can quietly be changed when it
is written to memory. Take a look at some of the “myths” in section 1 of
https://hal.archives-ouvertes.fr/hal-00128124/en/ .
[…]
I think that floating point can be used as long as it's used correct.
operator== shouldn't be used for comparison of floating point values.
operator!= shouldn't be used too.
operator and operator may be used.
The issue is more complex than that. Sit down and try this:
#include iostream
int main(void)
{
double a = 0;
double b = 0;
std::cin a;
std::cin b;
double x = a/b;
if (x a/b) {
std::cout x: x (a/b) std::endl;
}
volatile double y = x;
if (y a/b) {
std::cout y: y (a/b) std::endl;
}
return 0;
}
Results in LilyDev 3:
$ g++ fp.cc -o fp (echo 2 3 | ./fp)
x:0.67 0.67
y:0.67 0.67
$ g++ -O3 fp.cc -o fp (echo 2 3 | ./fp)
y:0.67 0.67
Add looping and you’ve got fatal issues. (And if you’re like me, steam will
erupt from your ears any second now...)
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
