Re: [Kicad-developers] Was: page selection dialog, everybody please comment
As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Thank you for that offer. Since you were aware of my concern about LAYER_NUM ahead of your commit, and the fact that I do not view that enum as helpful, I will accept your offer, but only if I can convert you to my point of view. : : So, no, I'm still convinced that not calling a LAYER_NUM an int is a good idea, even if it's only to look for every place where a layer number is used...I have done that *a lot*. OK then, I am making the consultative decision to allow this to stand then. Lorenso, you were the only person consulted on this one. Some amount of work was expended by you. The consultative decision process is described here: http://www.zingtrain.com/articles/decisions-part-i-choosing-a-decision-style/ While you are in this reference, see what Peter Drucker said: “A decision is a judgment. It is a choice between alternatives. It is rarely a choice between right and wrong. It is at best a choice between ‘almost right’ and ‘probably wrong’ — but much more often a choice between two courses of action, neither of which is provably more nearly right than the other.” We should be prepared to have disagreement on other topics, and in such cases those decisions may either be consultative decisions (possibly with disagreeable results to you), or even in rare cases: command decisions. But I think on this one we both made good efforts to reach a common point of view. The effort is probably a good practice, even though it seems painful at times. The democratic decision making process is never used in this project, even though it may feel like it is or has been to observers, non-participants. The reason observers can be fooled about this, is that the team is comprised of very respectful individuals, quality individuals, who go out of their way to consult with others even though they may not actually need to do so on a purely technical basis. I am very proud to have helped assemble such a quality team. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Mon, Apr 22, 2013 at 08:01:15AM -0500, Dick Hollenbeck wrote: Lorenso, you were the only person consulted on this one. Some amount of work was expended by you. The consultative decision process is described here: http://www.zingtrain.com/articles/decisions-part-i-choosing-a-decision-style/ Uhm interesting stuff. I'll read that. While you are in this reference, see what Peter Drucker said: “A decision is a judgment. It is a choice between alternatives. It is rarely a choice between right and wrong. It is at best a choice between ‘almost right’ and ‘probably wrong’ — but much more often a choice between two courses of action, neither of which is provably more nearly right than the other.” Perfectly agree on that. Also here in Italy we just had political elections... no goverment *yet* for something like a month :D I added the 'everybody please comment' to have feedback. I have exposed my point and I think I have nothing else to say on the topic (other than personal preferences). If the core developers or most other people at the end think that an int would be better then, as I said, I'll even backpatch the LAYER_NUM to int. No problem with that. The work wouldn't be had done in vain anyway since I discovered the many points of layer usage and that would be useful later (version control is useful for that too). Is that democratic enough for you? :D -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 9:17 PM, jp charras jp.char...@wanadoo.fr wrote: Another think... what does the ki in kicad stand for??? No special meaning. after a small brain storming, a friend of mine suggest me kicad. Now all I need to know is how to say it! KeeCad or KeyeCad? Mitch. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Mon, Apr 22, 2013 at 09:27:39PM +0800, Mitch Davis wrote: Now all I need to know is how to say it! KeeCad or KeyeCad? In Italy it's kee-kad :D -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 07:11:48PM -0500, Dick Hollenbeck wrote:
LAYER_NUM is mostly used as an iterator in our code, used to walk through for
loops.
Also as a parameter for indexing into stuff and especially LAYER_MSK
stuff. The main 'practical' reason for its introduction was finding
*every* place where a layer number was used.
What an enum brings is range safety. Used alone, it would only bring about a
1 in 28
layer chance of providing the proper value. This is your type safety.
Type safety is
a comforting phrase, and even to the point of being misleading when used with
enums. With
enums it is essentially fools gold, because it simply brackets a range of
values.
Not only that. You *can't* do operations with enum without casting; in
fact the new enum classes in C++11 almost removes the automatic int
promotion. So the type safety here is: you can't pass another int as
a LAYER_NUM and you can't (theorically, but current C++ doesn't enforce
it) us a LAYER_NUM as an int. Pascal got them better, I agree (you had
the enumerate them with prev and succ)
The 'real' C++ solution would have been a class (something like an
iterator), but probably that would have been overweight.
What would be real gold is value accuracy. Value accuracy cannot be
achieved by enums
alone. Value accuracy comes from testing, unit tests, code maturity,
asserts, proper
limits on for loops, and other techniques. In our case code maturity and for
loop limits
play a key role.
Let me check if I got the concept: value accuracy == the value is what
I wanted to represent and not something else unrelated. Example: it's
copper and not some other thing?
So for a 1 in 28 chance guarantee, then why is it to be weighed so heavily as
to promoted
as a solution to anything? It is *not* a solution to value accuracy. If
you like fools
gold, and it makes you feel good, there may be some merit for it.
First of all it avoids about 2^32-28 invalid values:D also without it
some things like the encoding in vias or a layer mask passed as a layer
number couldn't be caught by the compiler. *That* is type safety for me
(in statically typed languages like C++);
In the same way I claim as fool's gold trivial member accessors (if you
have Get and Set on a member, then it's the same as making it public,
it's easy to see)
The downside, or the cost, of using LAYER_NUM is that it becomes the center
of attention
of every for() loop. It makes the for() loop look non-standard, and makes
opaque an
iterator that really is nothing other than an index most of the time. In
fact, nearly all
the time.
It seems to me that would be *exactly* what C++ standard practice is:
for (std::vectorSTUFF::iterator it = v.begin(); it != v.end(); ++it) {
// Do stuff with *it
}
versus
for(LAYER_NUM it = FIRST_LAYER; it LAST_LAYER; ++it) {
// Do stuff with xx[it]
}
As I said before LAYER_NUM would have been theorically something like an
iterator class, but even for me that would have been too much.
The upside is slim to none. The downside is only moderate.
OK, quiz: what does this function want?
void stuff(int aLayer);
A layer number, a layer mask or some index from a dialog list?
The designers of Java go so sick of Microsoft's obfuscation of integer types,
that they
basically made it impossible to typedef an int. Their thinking is to be
seen as
revolutionary, and simplifying. Look at Java code, go back to the 80's and
90's and look
at Microsoft Windows code examples. Java is simple and elegant by
comparison. That is
Uhm... I don't agree with that... I learnt Windows API on the Petzhold
and (other than their hungarian notation) I didn't find them
obfuscated... even opengl has GLdouble and GLfloat (for portability
reason, here).
And I also think that java designers should be hung because they got
wrong almost every language feature :D
because in part, int does not become the center of attention in every for
loop. The for
loop limits, as I have said, are far more important to giving you value
accuracy.
And int is more readable.
Not when you're trying to know what it's representing.
Another thing: your little man doing stuff on the stairs i.e. it has not
to be an int! I already knew that something 'strange' would be needed
for the new mask, but maybe it would be needed for the index too.
Let say (it's hypotetical, but could be a useful idea) that the new
layer design calls for non-enumerated layers; arguments for this were
already been given by Wayne for the paper size, for example. Also he
said we needed (possibly good) ideas, so I have a shot at it.
Brainstorming if you want.
Let say that we want the user to define whatever layers he want (one of
the CERN project, after all) and (for some reason, maybe for integration
for other files? I don't know) the layer identifier is not anymore an
int. For example, I find 'ugly' than on a two sided board I have to step
over 14 unused inner
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
I'd like to have feedback from everyone on these opinions. I fully agree with Lorenzo, I really need Top Assembly and Bot Assembly layers, as well as more user layers (and user grids too). But that's doesn't matter because all we could get as a result of discussion is a Dick's cry about money. -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Apr 18, 2013 2:34 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Thu, Apr 18, 2013 at 12:35:01PM -0500, Dick Hollenbeck wrote: Lorenzo, The page selection dialog was broken in rev 4081 by a change which collapsed was from USLedger to US Ledger. Sorry my fault. I *really* tought it was a typo. I'm really against exposing keyword/internal data to the user anyway. And not only for internationalization purposes. It's a rule of work (look around for surrogate keys) in database design for example to *never* expose primary keys or internal ids to the user because (s)he *will* want them to be changed. For example not even licence plate or chassis number are used as primary key in fact since they *actually change* in real life, too: last year here in Italy we changed every moped licence plate, for example... I don't agree to their use as 'fixed keyword' in the files, for a similar reason (the design of PAGE_INFO is discutible for other reasons, too). I am still worried about extra layers (I need them and I worked a lot for having them, too). If the user can't even rename ECO1 to something more useful (still she *can* rename Inner1 to something else, so there is already a symbol mapping in there!) I don't even want to think of the work needed to add support for another couple or two of layers. Since we're sexp based, just exploit one of the main feature of the sexp, the 'symbol': (layers (15 Component signal) (0 Copper signal) (16 B.Adhes user) (17 F.Adhes user) (18 B.Paste user) (19 F.Paste user) (20 B.SilkS user) (21 F.SilkS user) (22 B.Mask user) (23 F.Mask user) (24 Dwgs.User user) (25 Cmts.User user) (26 Eco1.User user) (27 Eco2.User user) (28 Edge.Cuts user)) Technically: layer is a symbol (the form car, in this case), 15 is a number (a fixnum, most probably), Component is a symbol, signal is a symbol. Guess what, in sexps there are no keywords (common lisp *has* a keyword concept but it's only tied to the package facility; keywords *are* symbol, they only begin with : to avoid namespace scoping). These sexp are not meant to be executed so no quoting, it's fine. To highlight we're talking about symbols I'll use |Component| (another common lisp syntax since by default symbols are not case sensitive, but that's not the issue, it's only to make clear I'm talking about a symbol). It seems obvious that kicad sexps are case sensitive (or at least case preserving). The second element is the layer name, a symbol too; the third is mostly (only?) for specctra but let's say it's the layer type. We have to decide if the layer primary key is the number or the symbol. Inside pcbnew in fact the number is the key (LAYER_NUM for now is an int); for convenience you (quite rightly) use decided to use the layer symbol for reference in the rest of the file: (segment (start 121.92 140.97) (end 119.38 143.51) (width 0.508) (layer Copper) (net 1) (status 800)) that's fine, referencing layer |Copper| it goes in layer 0. This is a single faced board so I have called them |Copper| and |Component| (or maybe it was the old default). Moving on: (gr_line (start 192.00114 71.99884) (end 117.2 71.99884) (angle 90) (layer Edge.Cuts)) please note |Edge.Cuts| is a symbol in the *same class* of |Copper|. Also an italian user has *no idea* of what |Edge.Cuts| means (just as he has no idea of what USLetter mean... it's called Lettera here, which is coincidental similar; google translator give the equivalent German as Briefbogen which is *quite* different...); a good name would be probably |Bordi|, for example (by the way it's easier for an italian to know french than english). So why not: (layers (15 Componenti signal) ;; OMISSIS (28 Bordi user)) and then (gr_line (start 192.00114 71.99884) (end 117.2 71.99884) (angle 90) (layer Bordi)) Here, pcbnew internally knows that layer 28 is the pcb border (if it wasn't so *why* put the layer number in the file?), associate the symbol |Bordi| to it and matching works fine. The same exact machinery in motion for saying |Copper| instead of |B.Cu|. This is the design if the primary key is the layer number, in the file. It's arbitrary, and it's more or less the way eagle handles layers (by number). Let's decide (as an alternative design) the layer name symbol it's the primary key for pcbnew: (layers (15 F.Cu signal) (0 B.Cu signal) ;; OMISSIS (28 Edge.Cuts user)) With this approach this won't work. If the symbol is the key what is the number for? Also you lose the capability to rename even copper layers (pcbnew doesn't known what |Component| is). We could for example do this: (layers (F.Cu signal Componenti) ;; OMISSIS (Edge.Cuts user Bordi)) here the layer name is directly a string
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 05:45:33AM -0500, Dick Hollenbeck wrote: We might do well as a team by slowing down and focusing on reliability and quality not features for awhile. Firstly, the bugs are damaging to the project. Using the user visible string as an index *is* a bad practice and a bug in the user view. Why not replacing it with a simpler enumeration? The whole one-class-for-paper format is also debatable when a simple array would suffice (like for the color table array). As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Then you're even free to use void* for every pointer in the project. Good luck then finding when a layer is used instead of a simple counter (or something which is not a layer is passed in, which actually occurred a few times in the past). Also have fun with the two layer numbers encoded in a single variable in the via class (obviously worth the 4 byte gain for each via). Other than that these are only design opinions (altough type safety is generally considered a good thing) and everybody can do whatever he want with his own code. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Apr 19, 2013 6:12 AM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Fri, Apr 19, 2013 at 05:45:33AM -0500, Dick Hollenbeck wrote: We might do well as a team by slowing down and focusing on reliability and quality not features for awhile. Firstly, the bugs are damaging to the project. Using the user visible string as an index *is* a bad practice and a bug in the user view. No, I am a user and do not hold that view. My dog is named jasper. He is not named 80 lb. brown labrador. Once people learn his name and see him, they call him jasper. That is exactly what I did when I first saw the eco1 layer. I learned its name and realized I could use it or not. Since I have two 80 lb. brown dogs, people can have a conversation about jasper only by using his name. Otherwise which one are they talking about? I have used 3 features of kicad this week and none of them worked. Two of them had been working when I committed them. Yes you can have your own branch and make your own changes. However it takes a team to keep from having hundreds of separately evolving branches and instead one cohesive common code base. Somehow that team needs to come to a more or less unified vision. That my friend is not a purely technical process. Being the smartest guy in the room may actually make you the least likable and hardest to work with. At least that is what I have heard. Why not replacing it with a simpler enumeration? The whole one-class-for-paper format is also debatable when a simple array would suffice (like for the color table array). As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Then you're even free to use void* for every pointer in the project. Good luck then finding when a layer is used instead of a simple counter (or something which is not a layer is passed in, which actually occurred a few times in the past). Also have fun with the two layer numbers encoded in a single variable in the via class (obviously worth the 4 byte gain for each via). Other than that these are only design opinions (altough type safety is generally considered a good thing) and everybody can do whatever he want with his own code. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
Le 19/04/2013 13:12, Lorenzo Marcantonio a écrit : On Fri, Apr 19, 2013 at 05:45:33AM -0500, Dick Hollenbeck wrote: We might do well as a team by slowing down and focusing on reliability and quality not features for awhile. Firstly, the bugs are damaging to the project. Using the user visible string as an index *is* a bad practice and a bug in the user view. Why not replacing it with a simpler enumeration? The whole one-class-for-paper format is also debatable when a simple array would suffice (like for the color table array). Good or bad practice mainly depend on your criteria: I know (and Dick knows) using an user visible string can create issues, but using an index is not better: when you insert a new item or change items order, indexes in existing files will be broken. I remember I already used indexes in config files (to identify the language to use in user interface) and have serious issues. Indexes are always an image of the internal code, and I can say using them is also a bad practice. However they are often used because this is an easy way to store info. Good or bad practice just depends only the most important issue you want to fix or avoid (like file readability), and the time you accept to spend to code some things. As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Then you're even free to use void* for every pointer in the project. Good luck then finding when a layer is used instead of a simple counter (or something which is not a layer is passed in, which actually occurred a few times in the past). Also have fun with the two layer numbers encoded in a single variable in the via class (obviously worth the 4 byte gain for each via). Other than that these are only design opinions (altough type safety is generally considered a good thing) and everybody can do whatever he want with his own code. Layers names, number of layers and other things related to layers (setup dialogs, DRC requirement...) are an other topic, and I can say a *very* complicated topic that cannot be fixed in one minute. This topic *needs* time and *very good* ideas. (And not just a remark like I want more layers, useless for developers) -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 02:11:08PM +0200, jp charras wrote: Good or bad practice mainly depend on your criteria: I know (and Dick knows) using an user visible string can create issues, but using an index is not better: when you insert a new item or change items order, indexes in existing files will be broken. Agreed. In fact I was advocating for indexes as the code level; the external representation is another thing. The same hold for layer numbers, they are mapped to name in the file which is good. Indexes are always an image of the internal code, and I can say using them is also a bad practice. However they are often used because this is an easy way to store info. A string as an index is useful *if* is constant. And shouldn't visible to the user (surrogate key theory docet). If the paper collection would be wildly variable and customizable I'd agree to index it by string. But the internal name or the user name? Using the user name for stuff bit me a lot on windows drivers :P In fact when enlarging the palette I used color names (the internal ones) for the config file; the dialog palette would then translate them. Good or bad practice just depends only the most important issue you want to fix or avoid (like file readability), and the time you accept to spend to code some things. Completely agree. Layers names, number of layers and other things related to layers (setup dialogs, DRC requirement...) are an other topic, and I can say a *very* complicated topic that cannot be fixed in one minute. This topic *needs* time and *very good* ideas. (And not just a remark like I want more layers, useless for developers) This is the reason for the previous (long) messages and for not committing other thing I've been trying for trying. I concur that the layer issue is not trivial but saying layer are called this way because I like it and it's so is a very bad argument for me. Especially when other people ask for change *and* some of these changes are already in the code. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 07:06:05AM -0500, Dick Hollenbeck wrote: My dog is named jasper. He is not named 80 lb. brown labrador. *YOU* named your dog. And since it has been given a *proper* name, why couldn't a layer be called 'ClearancesForAvoidingBigExplosions'. Otherwise you're self-contradicting, you should call your dog dog (not even brown dog, you didn't know the colour before the dog design :D) Once people learn his name and see him, they call him jasper. Sure, this is also the reason for which we have nicknames. That is exactly what I did when I first saw the eco1 layer. I learned its name and realized I could use it or not. To this day I still don't know what ECO stands for, in fact... Comment2 would have been more explicative. And *I* know english, at least a bit. Since I have two 80 lb. brown dogs, people can have a conversation about jasper only by using his name. Otherwise which one are they talking about? Exactly. The owner decided the name, not the big-dog-maker in the sky :D I have used 3 features of kicad this week and none of them worked. Two of them had been working when I committed them. Yes you can have your own branch and make your own changes. However it takes a team to keep from having hundreds of separately evolving branches and instead one cohesive common code base. Somehow that team needs to come to a more or less unified vision. I'm sorry for breaking things; in the past when I did make error I tried to fix them as soon as possible. Version control is also made for this. Otherwise people just wouldn't do *anything* and the translators would have still been complaining about composite strings. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
Le 19/04/2013 14:39, jp charras a écrit : Le 19/04/2013 14:28, Lorenzo Marcantonio a écrit : To this day I still don't know what ECO stands for, in fact... Comment2 would have been more explicative. And *I* know english, at least a bit. Some EDA tools use ECO layers for specific comments: ECO means Engineering Order Comments. Sorry: Engineering Comment Order -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 02:41:01PM +0200, jp charras wrote: Engineering Comment Order Maybe Engineering Change Order? some CAD use this term for forward/back annotation... Another think... what does the ki in kicad stand for??? Just curious:P -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On 4/19/2013 8:11 AM, jp charras wrote: Le 19/04/2013 13:12, Lorenzo Marcantonio a écrit : On Fri, Apr 19, 2013 at 05:45:33AM -0500, Dick Hollenbeck wrote: We might do well as a team by slowing down and focusing on reliability and quality not features for awhile. Firstly, the bugs are damaging to the project. Using the user visible string as an index *is* a bad practice and a bug in the user view. Why not replacing it with a simpler enumeration? The whole one-class-for-paper format is also debatable when a simple array would suffice (like for the color table array). Good or bad practice mainly depend on your criteria: I know (and Dick knows) using an user visible string can create issues, but using an index is not better: when you insert a new item or change items order, indexes in existing files will be broken. I remember I already used indexes in config files (to identify the language to use in user interface) and have serious issues. Indexes are always an image of the internal code, and I can say using them is also a bad practice. However they are often used because this is an easy way to store info. Good or bad practice just depends only the most important issue you want to fix or avoid (like file readability), and the time you accept to spend to code some things. As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Then you're even free to use void* for every pointer in the project. Good luck then finding when a layer is used instead of a simple counter (or something which is not a layer is passed in, which actually occurred a few times in the past). Also have fun with the two layer numbers encoded in a single variable in the via class (obviously worth the 4 byte gain for each via). Other than that these are only design opinions (altough type safety is generally considered a good thing) and everybody can do whatever he want with his own code. Layers names, number of layers and other things related to layers (setup dialogs, DRC requirement...) are an other topic, and I can say a *very* complicated topic that cannot be fixed in one minute. This topic *needs* time and *very good* ideas. (And not just a remark like I want more layers, useless for developers) Maybe some historical perspective will help. When I designed the new file format, there was a long discussion between Dick, JP, and myself about the layer definitions with an eye on the future expansion of the number of layers. The original intent was to use the layer names alone without the ordinal (index) numbers and this was how the first commit of the new format behaved. This failed due to translated layer names and the decision to put the ordinal numbers back in was made. The new file format was disabled until was fairly stable so most users would not have noticed these problems. Later, Dick suggested that the layer names be simplified so that through hole modules layers could be defined as *.Cu (all copper layers) rather than have every copper layer name in the module layer definition along with some other simplifications. This significantly cleaned up the file format for the better. JP's comments about indices is correct. Using an ordinal number does not guarantee layer compatibility when we finally get around to adding more layers. They are also not readable. What is a layer 0, 1, 2, 3...N? You would always have to refer back to the layer table to know which layer the ordinal number is mapped to if they were used define layers in the rest of the file. The only good thing about ordinal numbers in this case is they cannot be translated. That being said, I do believe that providing users a way to define their own layer names that can be translated is a good thing. It's just that they cannot be used in the file layer definitions or any of the layer manipulation code. They can only be mapped to the standard layer names and only be used for UI purposes. I'm guessing that adding a 4th entry to the layer definition in the file would do the trick. However, I am in agreement with Dick that we should get the footprint library table implemented so that both the board and footprint file formats are stable then consider how we want to add user defined layer names. I working on it as fast as I can given my time constraints. Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
Le 19/04/2013 14:48, Lorenzo Marcantonio a écrit : On Fri, Apr 19, 2013 at 02:41:01PM +0200, jp charras wrote: Engineering Comment Order Maybe Engineering Change Order? some CAD use this term for forward/back annotation... Yes, or perhaps Engineering Command Order. ECO was used in my previous EDA tool, but this was 15 years ago, so I do nor remember exactly ... I used it in Kicad as comment layers. Another think... what does the ki in kicad stand for??? Just curious:P No special meaning. When I was searching for a name, I was searching a name with Cad (Computer Aided Design) inside. But most of names like Ecad, eecad, freecad ... were already in use, and after a small brain storming, a friend of mine suggest me kicad. The word was also something like an English word, and French guys are strange guys: they like English words for names (and in the same time, complain there are too many English words in use in French...) I was pleased with this and used it. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 09:06:39AM -0400, Wayne Stambaugh wrote: comments about indices is correct. Using an ordinal number does not guarantee layer compatibility when we finally get around to adding more layers. They are also not readable. What is a layer 0, 1, 2, 3...N? You would always have to refer back to the layer table to know which layer the ordinal number is mapped to if they were used define layers in the rest of the file. The only good thing about ordinal numbers in this case is they cannot be translated. OK, I got it. It's a 'transitional phase', and the layer number are more or less scheduled to disappear (or be deprecated), at least from the external files. I am not too happy with numbered layer but they could do *inside* of pcbnew. In the file format I agree they are only a nuisance. That being said, I do believe that providing users a way to define their own layer names that can be translated is a good thing. It's just that they cannot be used in the file layer definitions or any of the layer manipulation code. They can only be mapped to the standard layer names and only be used for UI purposes. I'm guessing that adding a 4th entry to the layer definition in the file would do the trick. However, I am in agreement with Dick that we should get the footprint library table implemented so that both the board and footprint file formats are stable then consider how we want to add user defined layer names. I working on it as fast as I can given my time constraints. So it would be like my second scenario. Perfectly fine with that, I have no hurry. Internal names are the layer key and user names are for user convenience, everybody wins. In the end LAYER_NUM could be even be some kind of interned string... The thing I was worried about was the complete inflexibility of Dick about layer naming. If it meant the 'internal and file format ones' I agree with him. In this case I think that keeping the internal names even for the copper layers (in the file) would be the better thing to do (since there is anyway a 'user name' field available) Thanks for the explanation (and a little bit of roadmap). -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On 04/19/2013 08:17 AM, jp charras wrote: Le 19/04/2013 14:48, Lorenzo Marcantonio a écrit : On Fri, Apr 19, 2013 at 02:41:01PM +0200, jp charras wrote: Engineering Comment Order Maybe Engineering Change Order? some CAD use this term for forward/back annotation... It is ECO Engineering Change order - and there is possible confusion thus my comment: PADS used the term to mean a sort of diff file (xxx.eco) of the schematic that got sent to the PCB and the opposite. ( A real bad idea to use reverse ECOs BTW .. but they had the feature) In real life ECO means something a bit different -- they are documents that help stop things like purchasing substituting parts with lower voltages.. I would write and sign an ECO for any part change - sometime purchasing would not be able to get a particular part so before they could buy a substitute it would have to be approved by Engineering with a signed ECO. If there was a design flaw and a product needed changing - again there would be a ECO document. Making changes with out a paper trail can cost huge sums of money. I'm supposing that the ECO layers in kicad would be to put text strings describing the changes? I've always wondered what the original intent was? See : http://wiki.xtronics.com/index.php/EE_CAD_Terminology and this (which is really narrow and seems to not realize that ECOs are used in many engineering fields outside of electronics ) : http://en.wikipedia.org/wiki/Engineering_Change_Order Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Truth is mighty and will prevail. There is nothing wrong with this, except that it ain't so. --Mark Twain ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
As for the layer number issue, as I already said, you're free to search and replace it to int. I'll do it personally if you like it. Thank you for that offer. Since you were aware of my concern about LAYER_NUM ahead of your commit, and the fact that I do not view that enum as helpful, I will accept your offer, but only if I can convert you to my point of view. What is curious is that you never asked for why I hold my opinion. You simply sent me to a website, probably written by someone with a 1/3 of my C++ experience. I guess it is human nature, and we all do this as humans, to assume that if someone does not agree with us, that is their lack of information that is the cause. I am also guilty of this. But sometimes a question as simple as why to you hold that opinion? can yield very enlightening results. LAYER_NUM is mostly used as an iterator in our code, used to walk through for loops. What an enum brings is range safety. Used alone, it would only bring about a 1 in 28 layer chance of providing the proper value. This is your type safety. Type safety is a comforting phrase, and even to the point of being misleading when used with enums. With enums it is essentially fools gold, because it simply brackets a range of values. What would be real gold is value accuracy. Value accuracy cannot be achieved by enums alone. Value accuracy comes from testing, unit tests, code maturity, asserts, proper limits on for loops, and other techniques. In our case code maturity and for loop limits play a key role. So for a 1 in 28 chance guarantee, then why is it to be weighed so heavily as to promoted as a solution to anything? It is *not* a solution to value accuracy. If you like fools gold, and it makes you feel good, there may be some merit for it. For colors, the enum is not used quite as frequently as an iterator, so the downside is not as heavy. Then what is the downside you ask? The downside, or the cost, of using LAYER_NUM is that it becomes the center of attention of every for() loop. It makes the for() loop look non-standard, and makes opaque an iterator that really is nothing other than an index most of the time. In fact, nearly all the time. The upside is slim to none. The downside is only moderate. Hence my conclusion: not helpful, after weighing the pros and the cons. The designers of Java go so sick of Microsoft's obfuscation of integer types, that they basically made it impossible to typedef an int. Their thinking is to be seen as revolutionary, and simplifying. Look at Java code, go back to the 80's and 90's and look at Microsoft Windows code examples. Java is simple and elegant by comparison. That is because in part, int does not become the center of attention in every for loop. The for loop limits, as I have said, are far more important to giving you value accuracy. And int is more readable. Then you're even free to use void* for every pointer in the project. Good luck then finding when a layer is used instead of a simple counter (or something which is not a layer is passed in, which actually occurred a few times in the past). Also have fun with the two layer numbers encoded in a single variable in the via class (obviously worth the 4 byte gain for each via). Other than that these are only design opinions (altough type safety is generally considered a good thing) and everybody can do whatever he want with his own code. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Was: page selection dialog, everybody please comment
On Fri, Apr 19, 2013 at 07:11:41PM -0500, Karl Schmidt wrote: In real life ECO means something a bit different -- they are documents that help stop things like purchasing substituting parts with lower voltages.. I would write and sign an ECO for any part change - sometime purchasing would not be able to get a particular part so before they could buy a substitute it would have to be approved by Engineering with a signed ECO. Ah... *that's* an ECO:D I know it, even too well... and even higher voltages than specced give issues: fuses have different I²s and ceramic caps are strongly voltage dependent (in this case usually it's better:P) We simply say sign me for this component here:P I'm supposing that the ECO layers in kicad would be to put text strings describing the changes? I've always wondered what the original intent was? No idea, the manual just says these are for commente. and this (which is really narrow and seems to not realize that ECOs are used in many engineering fields outside of electronics ) : I suppose everything with a BOM or a manufacturing sequence needs something like that... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
