kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

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/kicad-developers@xxxxxxxxxxxxxxxxxxx/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/kicad-developers@xxxxxxxxxxxxxxxxxxx/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