Han-Wen Nienhuys <hanw...@gmail.com> writes: > I apologise - I opened the page again, and expected it to always show > the latest patch set, which it didn't obviously. That, coupled with a > lengthy explanation of about using state machines made assume > erroneously that you did not change the .ll code
The explanation was not "lengthy", and you obviously did not bother reading my reply through. Neither did you bother reading the comments that you asked for. > The lexer code looks OK now - you could remove the markup_p variables; > ly_module_constant() memoizes the lookup, so the second lookup will > basically be a noop. There are two different lookups in alteration, and I can't find the definition of ly_lily_module_constant. > As for the scheme code, it would be nice if the validity check were > moved in a separate pure function, so the setter does > > (define (set-signature cmd sig) > (if (valid-sig? sig) (set-property .. .) > (ly:error (_ "invalid signature for command))) I'll think about it. > For one reason or another, whenever I review code from you it degrades > into a fight. I am not quite sure why this always happens. Because you don't bother taking the contributions of other people seriously. You don't read the code comments, even after you asked for them. You apply utterly different standards to the code which is everywhere else and written by you and "trusted" people. You reject code that obviously took hours to write and comment by an experienced programmer without even investing the time needed to read the comments. If you think that the code has to be trivial enough to be understood by you in 5 minutes (or instantly), why do you think it took years for someone to actually write it? > Could we mutually assume that when the other party makes comments or > writes improvements, that all of this happens in good faith, so if > something seems wrong, we assume the other party made an innocent > mistake? Could we also assume that the other party's intelligence is not so much below our own that something must be wrong if we need to more than superficially glance at his code? I've actually thrown out all of the C code checking for the validity of the signature since your original comments made abundantly clear that there was no way that I could write straightforward C code checking for a valid sequence of argument types that you would ever accept. Because the _problem_ was at a level for which you were not going to accept code from me. And even though the part you complained about was contained in about 10 lines of code, you did not even bother checking the comments carefully about what it was supposed to do. And proposed substituting it with about 4 lines of trivial code without bothering to entertain the thought that the original code was not looking more complex thatn that because it solved a problem more complex than that? Even discounting that your last batch of comments was for an old version (again, what kind of moron do you think you are dealing with when you can't discern a single change after his explanation that he'll rip everything out and do it differently?), could you at least bother checking what problem some code is trying to solve (it states so in the comments) before rejecting it because it is not more trivial than the problem it solves? That is the main problem I have with you "making comments" and "writing improvements": you don't take the other side serious enough to entertain the thought that he might be doing something for a good reason instead of plain stupidity. You don't bother to actually read through explanations in code comments, or in Rietveld comments. Not carefully enough to understand what they are talking about. And I find this kind of condescension decidedly unrewarding. If you want to be taken seriously, you should extend the same courtesy to others. It very much kills motivation to participate with Lilypond if you don't. And it also does not help that you apply double standards with regard to code you are willing to let into Lilypond, since a new contributor can't take the existing code as a guideline for how to write things in an acceptable way. Try investing at least one minute of thought for every hour of thought that a contribution required. How do you expect _not_ to miss the point when you don't? Not every problem has a trivial solution. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
