kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/27/2013 12:56 AM, Lorenzo Marcantonio wrote:
> On Fri, Apr 26, 2013 at 08:48:52PM -0500, Dick Hollenbeck wrote:
>> It will definitely be a bottleneck.  Maybe we should measure how bad soon, otherwise this
>> is a suggestion which serves as a roadblock to progress, and the roadblock itself it not
>> currently a solution.
> 
> I don't trust much python speed... however some heavy caching could
> help, if needed. OTOH if you have ever seen the speed of the CAM350
> 'streams' checker:P I have to admit it's designed to be a pre-production
> final check but 40 minutes for a small 4 layers board (about 500 nets)
> are a little too much
> 
>> The idea is innovative, and if it is not like watching snails race, it may have some merit.
> 
> I fear that could be unapproachable for the 'common' user. 


100% agreed.


But how important is that really?  Will it result in a reduction in pay?

The "common" user has been a hobbyist, and is becoming a corporate employee as the
software gets better.

So while I agree, I think the importance of this concern is minimal.  Actually zero.
If we like it, that should be good enough.  We are corporate employees, and are paying to
make this software useable for our needs.  You said yourself the same thing.


> What about
> surveying what other cads are using and pick the more useful/less
> esoteric ones? 

Great idea, do it.  It seems we are all still open to the best ideas.

> For example, different clearances on different parts of
> the board would a) need some kind of partitioning tool and b) only of
> really specialistic use (AFAIK only for multideposition or hybrid
> boards...)
> 
> Instead of booleans we could use some kind of truth table to check the
> needed conditions (like for syslog-ng filtering or apache httpd ACLs),
> that would be a lot more usable. Some thinking about use cases is needed
> here. The result is actually equivalent to a sum-of-product normal form,
> so I think we would not lose flexibility.
> 
> Also this kind of 'programmable' clearance (be it done in python or in
> tabular form) would implement interclass clearance.
> 
> Before of this I think that some better way to assign netclasses is
> needed (preferably from eeschema, thru the netlist, maybe). Having to
> crosscheck between pcbnew and labels on eeschema is way too error prone.


Tom's idea is still on the table AFAIAC.    Some benchmarking of this concept should not
be that hard.  We have instrumentation/timing code for that now.

Tom, let's talk about this class called "both".  Can it be written in C/C++?

(Its results are dynamic, so I don't see where all this stuff can be pre-evaluated.)

Is there a way we can provide a python expression, but do most of the work in C++?, by
implementing the functions being called in C++ behind the expression, by following the
python C API.

This is a slight variation on the original idea, which can be a way to turbo charge it,
maybe to cut out a few lookups at runtime.

Obviously the python expressions can all be "pre-compiled", but I don't think they can be
"pre-evalutated" when "both" is in play, since that is a dynamic match maker.


Dick