At least we all have to be clear in what we say. It seems I understood incorrectly what should I do, and what shouldn't.
В сообщении от Пятница 18 ноября 2011 21:23:21 вы написали: > > 1) Regarding the use of "class wrappers for integers", you never completed > the argument to a point of having built a consensus. Both Jean-Pierre, > Lorenzo, and myself expressed disagreement towards this plan in the > following thread: I do not realize what sort of argument you're want from me. Is it known method for you to encourage the compiler to catch possible bugs? > http://www.mail-archive.com/[email protected]/msg01879. > html > > Independent of how good or bad the idea is or was, we now have a political > problem, and that is that we currently think you have some "team player" > issues to improve on. Perhaps an apology and a continuation of the > original conversation is needed. Seemingly I'm bad 'team player'. I apologize. > 2) Your code is not conforming to the coding standards, even after being > requested in private email by Wayne this week to improve on this. As of > today we can look at the function UnitDescription() in file > common/common.cpp and notice several violations in just a few lines of > code: > > a) Star * to be after LENGTH_UNIT_DESC not before UnitDescription() > b) { bracket to be on its own line after first line of function. > c) switch() needs whitespace around the aUnit on both ends. > d) { brack to be on its own line in switch. > e) switch indenting of cases is wrong, cases to be at same level as > switch() f) single line comments are to be C++ not C style.. bcde) was my fault, I still did not spent 15 s to reformat 5 lines of code, but... It seems my eyes cheat me, but I still do not see the *rules* for a) and f). > > This you committed in rev 3222, and is an example of what we are saying. > > 3) Even if you had won the argument in the email thread back on June 23rd, > (which you still must do before potentially wasting > your time on this (3) ), you are not going about the conversion in a way > which we would expect: > > a) Your plan is not documented for all to understand. I thought I wrote enough above to express my concepts. If it still did not understood, I apologize again. > Your new macros and > functions in common.h are all largely undocumented. Did you mean 'largely uncommented' under 'largely undocumented'? I hought the purpose and meaning would be clear after looking on their name and source code (especially if there are just a few lines of it). > One would expect to see function comments on functions like > LengthFromTextCtrl() and all the new transition macros. > > b) The effects of KICAD_NANOMETRE on file formats have not been documented. I can express the effect in one sentence "Length-dimensioned data is stored with integer and fractional parts separated by 'full stop' (.) character rather than just integer". Would it be enough for documentation? > c) The anticipated effects of *not* defining KICAD_NANOMETRE in a build, > have not been documented. Even if this is not defined in a build, I see > saved board files now have floating point dimensions in them which have > trailing zeros. (Suggest %.6g instead of %f to printf() style functions.) What are your arguments? My ones are: For "%f", atoi() still able to decode it, just dropping fractional part, and the absoulte precision of "%f" is constant. > We normally don't want to inject unnecessary changes in a board file > unless someone pulls the trigger, by defining the pivot #define, which we > guess to be KICAD_NANOMETRE. It shall not effect on *saving* untill KICAD_NANOMETRE is triggered. If it was, it is a bug. But I still can not reproduce it in current revision. On loading it should accept old and new files. --- that's the comment where it is documented --- // there would be some period while program gain ability to // load float data but not acually save it (rev3241:lengthpcb.h:93-94) > > d) The blueprint could also be used to describe what you are up to. > > > In summary, we recognize that it is cumbersome for you to enter into a long > debate when you are > not working in your native language, and the ideas and expressions do not > flow as easily. We recognize that. You however, need to recognize that > the lead developers do not have time to express disagreement more than > once. A disagreement is a state of circumstance and current understanding > of pros and cons. It is not necessarily a permanent situation. Pros can > be sold through persuasion, and their weight's can be enhanced. Cons can > also be. Disagreements can be permanent or temporary, but it is important > to recognize which state you are in currently. Moving forward against the > wishes of a lead developers in a state of disagreement, without having > built a consensus, is not politically wise, and is specifically > disrespectful. You could explain you wishes in order they're fullfilled. I still dislike any politic games. > > The advantage you have now is that you can use your code as an example to > argue why we should accept your design. Your original argument (see link > below) was weak no doubt in part due to the fact that English is not your > native language. Try to take some member with length dimension, e. g. TEXTE_MODULE::m_Pos0 amd try to mak them hold value in nanometers. Count how much time you spent debugging it. Then compare with my results. That's my argument. LENGTH and LIMITED_INT are just a debug helpers, and can be turned to just ints in release or if they're unnecessary to debug. > http://www.mail-archive.com/[email protected]/msg01879. > html > > > Perhaps you can point to your current commits via an email, and explain > what you think the benefits are to all the complexity, slower compile > times, and reduced human readability. What you're mean under 'complexity'? Did you compare compile time? If you bother on it you still may compile it with KICAD_NANOMETRE turned off. What you're mean under 'human'? I do not see an impact to readability. > There is still a possibility that we revert (remove) your changes, but > equally likely, with some > political effort on your part, that we can be persuaded that your changes > and contributions are the correct way to go. And of course you understand > that no one objects to the idea of higher resolution on the internal > units, just the implementation details are on the table. It seem to me the best way for me is to fork/branch (at leash until I have good working concept), 'cause it's too much for me to do work twice writing the same in two languages (English and C++ I meant). > > We thank you in advance for your conscientious understanding of our > concerns, and for your interest in KiCad. > > Dick p. s. Do you want to know my (and russian KiCAD developers I met today) point of view on KiCad sources? Do you find easy to read well formatted spaghetti like code?.. -- --- KeyFP: DC07 D4C3 BB33 E596 CF5E CEF9 D4E3 B618 65BA 2B61 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
