I ask that you submit the changes in a separated way: it's easier to
review, and if it does break something, it's easier to identify and
revert the incriminating commit.
- Okay, I will resubmit some non-controversial parts of it in the near
future.
but just removing the check is not the right solution
- I know this can happen in theory, but I was referring to the actual
implementation. I will leave the warning here.
I am more familiar with vimdoze and SVN, than linux and git, so thanks
for clarifying.
Did you run the regression test?
- I just did (make check?), it fails (I guess, I'm not sure what to
look for).
If we are doing a fixup of this, we should try to do all files at the
same time, or at least a section of files.
- I will gladly do that, even if it takes a lot of time, but we should
clarify a few things first, as my developing RSI doesn't permit me to do
things that will simply be rejected (I do have some time now, however).
Should I write a basic coding guideline, based on the source code (and
the provided links), that you guys can modify so that everything
important is clarified (eg. spreadsheets.google.com)? A huge poll could
follow it, with the alternatives that were presented there.
If we decide on a line length limit (I am fine with 100 or 80. We have
80 at google, and I find it on the short side), we should document that
and then fix all instances of it in a structured way.
- okay, then I guess I shouldn't post that patch yet, until it's
decided.
I doubt you can measure a speed difference between double and float.
- I'm not certain here, but more floats can fit in the cache and if the
compiler does some vectorization or other SSE optimization, then twice
as many floats can be calculated in the same time. Might gain speed if
memory bandwidth is the problem, but as far as I have read, it's rarely
a bottleneck (you still have to cast it, if you use both).
Just wrote a simple test case, the result were 3.21s for float and 3.79s
for double (15% diff, not much in this case).
What is 'too many' ? Which macros could we do without?
- I meant inline functions are many times preferable instead of
preprocessor macros.
I agree with this in some cases but not in all, which is also why I
want to see more targeted commits, so we discuss specific cases.
- Would it be possible, to discuss it first? I don't like to work in
vain.
It would be really nice to standardize on things, but it's a
non-trivial task.
- As a new member I find it hard to read a code that has the
personality of all its commiters, standardizing would really help, in
case you want others to join (otherwise it's okay, if you consider it to
be).
Thanks,
Lőrinc
http://codereview.appspot.com/1724041/show
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
