I barely feel qualified to review this, but it looks fine to me. I
could not think of any better way to do it than your ugly hack.
LGTM.
Carl
http://codereview.appspot.com/2065041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM.
The else clause is one space too far to the right,
I couldn't do sn inline comment because the side-by-side diff is
missing.
Carl
http://codereview.appspot.com/2020041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Thanks Carl,
I am reticent to go any farther with this patch after Joe's email
concerning what pure print functions actually need to do. There is no way
to verify that these added functions behave correctly, which means that we
put the user in a position where they'll see no warning or error
Reviewers: ,
Message:
I have another tiny clarity rewrite for code.
Description:
Clarify infinity_f preprocessor definition.
The old code confuses various style programs, including our own
fixcc.py (it produces un-compilable code!). In particular:
-
const Real infinity_f
= #ifdef
-
LGTM.
Anything we can do rationally to get automatic style fixers to work on
our code should be done, IMO.
Thanks, Graham!
http://codereview.appspot.com/2099043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 2010/09/06 14:23:36, Carl wrote:
LGTM.
Thanks, pushed.
Anything we can do rationally to get automatic style fixers to work on
our code
should be done, IMO.
About 2.5 hours of work so far; not bad. I think I'm about halfway.
Cheers,
- Graham
http://codereview.appspot.com/2099043/
On 9/6/10 6:53 AM, Mike Solomon mike...@ufl.edu wrote:
Thanks Carl,
I am reticent to go any farther with this patch after Joe's email
concerning what pure print functions actually need to do. There is no way
to verify that these added functions behave correctly, which means that we
put
I see a really weird C++ construct in this (short) file:
lily/freetype-error.cc
const struct Freetype_error_message
{
FT_Error err_code;
const char* err_msg;
} ft_errors[] =
#include freetype/fterrors.h
;
The #include and the ; appear to be part of the const struct
On 9/6/10 11:44 AM, Graham Percival gra...@percival-music.ca wrote:
I see a really weird C++ construct in this (short) file:
lily/freetype-error.cc
const struct Freetype_error_message
{
FT_Error err_code;
const char* err_msg;
} ft_errors[] =
#include
[Wearing the FreeType maintainer hat]
I see a really weird C++ construct in this (short) file:
What's the problem?
lily/freetype-error.cc
const struct Freetype_error_message
{
FT_Error err_code;
const char* err_msg;
} ft_errors[] =
#include freetype/fterrors.h
Am Montag, 30. August 2010, 01:48:46 schrieb Reinhold Kainhofer:
Am Montag, 30. August 2010, um 00:25:47 schrieben Sie:
I don't really see any other way to turn the input path to an
absolute path
than calling os.path.abspath, in particular, since the input path
can already
be an
'sHi everybody,
I'm getting cyclic dependency problems with laissez vibrer ties
attached to cross-staff notes which seems harmless in a minimal
snippet, but more serious in a real music example. It appears to have
been introduced following the fix for issue #881, which made the
LaissezVibrerTie
On 9/6/10 3:01 PM, Neil Puttock n.putt...@gmail.com wrote:
I wondered whether this is the right approach; perhaps we should
rethink the fix for issue #881 instead.
Perhaps we should rethink the 881 fix, since it was always a bit mysterious
why it worked. But I don't have any better ideas
On Mon, Sep 6, 2010 at 8:08 PM, Werner LEMBERG w...@gnu.org wrote:
[Wearing the FreeType maintainer hat]
:)
I see a really weird C++ construct in this (short) file:
What's the problem?
The problem -- and I readily admit that this isn't a problem with
freetype -- is that if we run our
On 06/09/10 22:19, Graham Percival wrote:
On Mon, Sep 6, 2010 at 8:08 PM, Werner LEMBERG w...@gnu.org wrote:
[Wearing the FreeType maintainer hat]
:)
I see a really weird C++ construct in this (short) file:
What's the problem?
The problem -- and I readily admit that this isn't a problem
On Mon, Sep 6, 2010 at 10:30 PM, Wols Lists antli...@youngman.org.uk wrote:
On 06/09/10 22:19, Graham Percival wrote:
inside a function)... but since I didn't recognize the C++ construct,
I thought it was worth asking.
As a C programmer, it took me about 30 seconds (or less) to twig what it
As a C programmer, it took me about 30 seconds (or less) to twig what it
was doing.
Could you take 120 seconds or so to explain what it's doing? I'm
supposed to be teaching first-year C programming, and I haven't run
across this before.
Here is the documentation from fterrors.h:
On 06/09/10 22:30, Wols Lists wrote:
As a C programmer, it took me about 30 seconds (or less) to twig what it
was doing.
I mean, why _do_ we have a hanging = sign? I could understand if it
was any of these:
} ft_errors = 0;
} ft_errors = NULL;
} ft_errors;
(with the #include
Reinhold Kainhofer wrote Monday, September 06, 2010 8:29 PM
Am Montag, 30. August 2010, 01:48:46 schrieb Reinhold Kainhofer:
Am Montag, 30. August 2010, um 00:25:47 schrieben Sie:
I don't really see any other way to turn the input path to an
absolute path
than calling os.path.abspath, in
On 2010-09-07 01:28, Alexander Kobel wrote:
[...] Here's my shot to explain it: [...]
Hm, when I just tried to look up a bit of the syntax, I stumbled across
this:
http://en.wikipedia.org/wiki/C_preprocessor#X-Macros
That's basically it.
Cheers,
Alexander
On 06/09/10 22:30, Wols Lists wrote:
Because C doesn't give a monkeys about white space, but the
pre-processor does. The #include has to be the first thing on the line
otherwise the pre-processor will screw up, but once the pre-processor
has done its job, the compiler will happily ignore
Thanks, applied.
http://codereview.appspot.com/2083043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
22 matches
Mail list logo
