On 02/07/2014 02:45 AM, Maciej Sumiński wrote:
> On 02/06/2014 11:48 PM, Dick Hollenbeck wrote:
>> On 02/06/2014 04:26 PM, Maciej Sumiński wrote:
>>
>>> It is not my intention to increase the number of bits in m_VisibleElements - I prefer
>>> to leave it as it is now, particularly that it is saved as a 32-bit number in
>>> .kicad_pcb files and I would like to preserve compatibility (so if older versions
>>> expect 32-bit number there
>>
>> Note, that if we were always bound to allow older versions of KiCad to load newer files,
>> then it would be impossible to add new features which needed saving on disk.
>>
>> I value new features far more.  We can all stop writing code and wasting time on a mailing
>> list if we are not to write features requiring file format changes.  It would essentially
>> mean that we could only make improvements which do not require change.
>>
>> The pay is too low already.  If you can find a way to make improvements without also
>> making changes, then I am in the wrong universe.
> 
> Sure, I am aware that to improve you need to change, but not always the 
> file format. In this case, one cannot even benefit from saving the 
> visibility settings for netname layers, as they are turned on/off 
> together with copper layers. To take advantage of that, we need to add 
> some checkboxes first.
> We could put in a document all the changes that we want to introduce to 
> the file format and then change it every e.g. 6 months according to the 
> paper. In this way, users will not be bothered by so frequent file 
> format changes. Especially that the majority seems to be using the 
> stable version, so they would not be able to open files done with the 
> newest product (and getting the freshest product is still beyond 
> capabilities of many users).


Orson,

I am very impressed with your skill set, and I think that your time on the project is
extremely valuable to its future longevity.  You have my profound respect and hopes for
the future.  You are one of the bright spots in the project moving forward.

Your employer is paying for your time.  I am paying for my time.

Therefore, my time is more important than anything, and I am insanely intolerant of it
being wasted or disrespected. But it also gives you a view of the lens from which I see
things.

You think our users are the most important thing.  I think our developers are the most
important thing.

Note that I run a company.  In that world, the users are the most important thing.

Here, in open source, you've got squat without developers.


>>
>> The lesson here is that "long" is
>>
>> a) not necessarily longer than int, and
>>
>> b) not known until you pick a machine and a compiler.  So you don't get 64 bitness if
>> thats what you need.
> 
> But it is not what I needed - as I said, it was only to assure 32 bits 
> size. 


int is 32  bits (at least)  or the whole wx graphics realm would not work, nor would you
be able to support our internal units of nanometers.  You are new to the project, but
anyone with 3 years here would know we needed 32 bit ints for wxInt to work for us.
wxPoint, etc.  We did all the math, looked at every one of the 4 billion possibilities, etc.


Us old guys hate visual noise, especially noise that is simply and alias for, "how wide is
this datatype?"


Got that? We HATE it.  We also hate everything Microsoft introduced in the 80's regarding
hungarian notation.  int is beautiful.  Normally it means "I don't care how wide the type
is, its probably big enough."

But on KiCad, int is at least 32 bits or you should return your computer for a full refund.

long is useless, I suggest you never write another line of code which uses it.  It means
the same thing as int, except now you have to think twice about it.  You still don't know.
 Worse yet, you have to listen to someone telling you "I really hope this type is big
enough".  Well if you are hoping, then you are a dope.

We use int when we are not hoping.  But remember on KiCad int is 32 bit minimum, that's
been established since 1995.  Windows 95.

So that makes using int32_t nonsensical on our desktops.


I have changed this to long, as long is guaranteed in the standard
> to have 32 bits. I admit that on some platforms I could waste 4 bytes of 
> RAM. But if int does the job on the supported platforms then why not 
> leave it as it is (or change it to int32_t)?


int is at least 32 bits for us.  For KiCad.  That's a fact jack.  File it in your head.

Old guys don't want to look at "long", period.  "int" is lean and simple.  We stray only
when we have a specific need for a specific bit width, then comes in stdint.h, or unsigned.

Old guys know stuff, lots of stuff that smart young guys can learn from.  Having older
mentors is a key to having a successful career  (along with continuous study).

I wish I could have been yours.  I like you.


Dick


> 
> Sincerely, my main concern is to fix the bug. I have already learned a 
> lesson and reverted the commit that you have found improper. Is there 
> anything else that I could do to have the branch merged?
> 
> Regards,
> Orson
>