Re: [Kicad-developers] Was: page selection dialog, everybody please comment

2013-04-19 Thread Lorenzo Marcantonio 
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::vector::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

Re: [Kicad-developers] Was: page selection dialog, everybody please comment

2013-04-19 Thread Lorenzo Marcantonio 
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

Re: [Kicad-developers] Was: page selection dialog, everybody please comment

2013-04-19 Thread Dick Hollenbeck 

> 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

2013-04-19 Thread Karl Schmidt 

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

[Kicad-developers] XSL Script to generate BOM for Digi-Key ordering system

2013-04-19 Thread Stefan Helmert 
Hello,

I have done an xsl file, which is generating a csv file from the BOM xml file 
to order the parts directly from Digi-Key by uploading the csv.

I hope it will be helpful

Best regards

Stefan Helmert


bom2digikey.xsl
Description: application/xslt
___
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

2013-04-19 Thread Lorenzo Marcantonio 
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

2013-04-19 Thread jp charras 

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

2013-04-19 Thread Wayne Stambaugh 

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

2013-04-19 Thread Lorenzo Marcantonio 
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

2013-04-19 Thread jp charras 

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

2013-04-19 Thread jp charras 

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.

--
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

2013-04-19 Thread Lorenzo Marcantonio 
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

2013-04-19 Thread Lorenzo Marcantonio 
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

2013-04-19 Thread jp charras 

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

2013-04-19 Thread Dick Hollenbeck 
On Apr 19, 2013 6:12 AM, "Lorenzo Marcantonio" 
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

2013-04-19 Thread Lorenzo Marcantonio 
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

2013-04-19 Thread Dick Hollenbeck 
On Apr 18, 2013 2:34 PM, "Lorenzo Marcantonio" 
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")
>

Re: [Kicad-developers] Was: page selection dialog, everybody please comment

2013-04-19 Thread Sergey A. Borshch 


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] Patch to fix pcbnew example scripts and SWIG interface

2013-04-19 Thread Miguel Angel Ajo 
Pushed now in 4105 If I'm not wrong :-)

Miguel Angel Ajo
http://www.nbee.es (http://www.nbee.es/)
+34911407752
skype: ajoajoajo


On Wednesday, 17 de April de 2013 at 23:25, Miguel Angel Ajo wrote:

> Ehh, it seems that I did not push to main repository the previous patches, I 
> will check  
> what happened tomorrow morning, sorry about this…
>  
>  
> Miguel Angel Ajo
> http://www.nbee.es (http://www.nbee.es/)
> +34911407752
> skype: ajoajoajo
>  
>  
> On Monday, 15 de April de 2013 at 23:13, Miguel Angel Ajo wrote:
>  
> > Thanks a lot Wayne,
> >  
> >Don't worry at all, the refactoring needed to be done, and it's high 
> > priority,
> > you're making our lives easier in the future, some pain now it's ok.
> >  
> > If you had simple to run tests in the scripting you'd have detected it 
> > very
> > easily, but we didn't provide this. And, at the moment I write this, the
> > methods were not available yet, only the m_xx , but I wasn't still confident
> > to start touching code that wasn't mine (even asking), I wrote my own
> > python wrappers from GetXX to m_XX, which didn't necessarily need to  
> > match what it was finally done, because I did it and told nobody :)
> >  
> >   Keep the good refactoring work, it's good for all :)
> >  
> >  
> > Miguel Angel Ajo
> > http://www.nbee.es (http://www.nbee.es/)
> > +34911407752
> > skype: ajoajoajo
> >  
> >  
> > On Monday, 15 de April de 2013 at 16:47, Wayne Stambaugh wrote:
> >  
> > > On 4/15/2013 5:35 AM, Miguel Angel Ajo wrote:
> > > > Hi Matthew, sorry for my slow response,but finally I could check and
> > > > commit your patch, thanks for the 2nd version too. It's in release 4100
> > > >  
> > > > I found the GetText/TextPosition missing in TEXTE_PCB too, I think we
> > > > should ask Wayne Stambaugh,
> > > >  
> > > > Wayne, What should we use one to get a TEXTE_PCB position?
> > >  
> > > GetTextPosition(). The TEXTE_PCB object does not have a GetPosition()
> > > function. I apologize for breaking the Python scripting support. In
> > > the future I will try to be more aware of the impact of my changes to
> > > the Python scripting. To help mitigate the problem int the future,
> > > please avoid directly accessing public member variables and use the
> > > access functions whenever they are available. I knew encapsulating
> > > EDA_TEXT was going to cause problems but it's been on my personal to do
> > > list for a long long time. I just couldn't stand it any more so I broke
> > > down an fixed it. Thank you for your patience and your help.
> > >  
> > > Best Regards,
> > >  
> > > Wayne
> > >  
> > > >  
> > > > Miguel Angel Ajo
> > > > http://www.nbee.es 
> > > > +34911407752
> > > > skype: ajoajoajo
> > > >  
> > > > On Wednesday, 10 de April de 2013 at 22:21, Matthew Beckler wrote:
> > > >  
> > > > > Thanks for the feedback, I have prepared a new patch that removes the
> > > > > simple pass-through python-only accessor methods as discussed. I
> > > > > applied the changes to the scripting example files, and tested the
> > > > > createPcb.py and listPcbLibrary.py. There was a problem with the
> > > > > listPcb.py script, in trying to call GetText() and GetPosition() on a
> > > > > TEXTE_PCB object. I am not sure how to fix that one immediately
> > > > > offhand, but I will look into it more in the next days.
> > > > >  
> > > > > Thanks,
> > > > > Matthew Beckler
> > > > > Wayne and Layne, LLC
> > > > >  
> > > > >  
> > > > > On Mon, Apr 8, 2013 at 7:22 PM, Cirilo Bernardo
> > > > > mailto:cirilo_berna...@yahoo.com) 
> > > > > > wrote:
> > > > > > Using 'XXX()' instead of 'GetXXX()' makes more sense if you're
> > > > > > replacing a pair of Get/Set routines, but this is really only a
> > > > > > consistency issue with Python.
> > > > > >  
> > > > > > - Cirilo
> > > > > >  
> > > > > > PS. Sorry for the top post; goddamned Yahoo doesn't allow a user to
> > > > > > create messages in a sensible fashion anymore. Stinking google's
> > > > > > screwing things up too. Is there anyone out there who still gives
> > > > > > you good old plain text and quoting/indentation?
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > > 
> > > > > > > From: Miguel Angel Ajo  > > > > > > (mailto:miguelan...@nbee.es) >
> > > > > > > To: Matthew Beckler  > > > > > > (mailto:matthew.beck...@gmail.com) 
> > > > > > > >
> > > > > > > Cc: KiCad Developers  > > > > > > (mailto:kicad-developers@lists.launchpad.net)
> > > > > > >  
> > > > > >  
> > > > > > >
> > > > > > > Sent: Tuesday, April 9, 2013 6:27 AM
> > > > > > > Subject: Re: [Kicad-developers] Patch to fix pcbnew example 
> > > > > > > scripts and SWIG interface
> > > > > > >  
> > > > > > >  
> > > > > > > Hey, thanks a lot Matthew,  
> > > > > > >  
> > > > > > >  
> > > > > > > This happened because of the on