X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Fri, 14 Dec 2012 11:36:59 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Find rat lines
In-Reply-To: <C0A29256-3D74-4C3F-B2A0-150F85C85047@noqsi.com>
Message-ID: <alpine.DEB.2.00.1212141116350.26605@igor2priv>
References: <20121204183305 DOT 6b04c0dc AT jive DOT levalinux DOT org> <20121208112649 DOT 388a9d22 AT jive DOT levalinux DOT org> <1355011808 DOT 19390 DOT 8 DOT camel AT localhost> <alpine DOT DEB DOT 2 DOT 00 DOT 1212090407031 DOT 26605 AT igor2priv> <1355188647 DOT 12937 DOT 14 DOT camel AT localhost> <A7B4EDBD-3704-4837-9350-A16559C60A2A AT noqsi DOT com>
 <1355442697 DOT 2993 DOT 14 DOT camel AT localhost> <008677C3-7BA0-4B7D-B8E7-D0A5B2CCC573 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1212140350530 DOT 26605 AT igor2priv> <898C7D41-7B55-4D61-9CC6-7ABB560C144E AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1212140458230 DOT 26605 AT igor2priv> <5189151C-7C93-4AD6-A154-185C8F7AC203 AT noqsi DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1212140537520 DOT 26605 AT igor2priv> <6E00459F-C749-4DE5-B182-44A8623E70E8 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1212141012260 DOT 26605 AT igor2priv> <C0A29256-3D74-4C3F-B2A0-150F85C85047 AT noqsi DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



On Fri, 14 Dec 2012, John Doty wrote:

>
> On Dec 14, 2012, at 2:15 AM, gedau AT igor2 DOT repo DOT hu wrote:
>
>> How do you _exactly_ define/calculate network affiliation? That was the original problem for the non-history case, so don't just assume it is solved, solve it.
>
> How about having the user affirmatively declare it before drawing? Touch a known object, or select from list, or type netname (could implement all of these). Prominently display the netname under construction in status somewhere.

Finally, after so many emails, an idea... Let the user tag each object 
manually.

This would be a valid solution, but I don't see the benefits. First of 
all, it would be very expensive (a single line in gschem often translates 
to dozens of objects in PCB). At the end, it could help the user by 
remembering user intentions. Unfortunately this leaves many of the 
problematic quesitons unanswered. Corner cases:

1. The user loads a new netlist - copper areas totally valid for 
connectivty are highlighted as shorts

2. Assume 3 networks, A, B and C; A and B has a long parallel pair of 
traces and connects exactly the pins they should (no short); the copper of 
C also connects what it should, but it crosses the long parallel lines of 
A and B. What should be highlighted and how did the software decide to 
get that result? More importantly, how would it be more useful than what
other proposes would highlight?

3. Two networks, A and B, parallel for a long time, then crossover, and 
parallel again. Same questions as for 2.

4. How do you handle untagged objects?



By the way this method is already possible on single sided boards using 
layers - each net can have its own layer. Most probably because of the 
extra effort involved I can't recall seeing anyone doing this, except for 
some of the most important/crowded nets (GND, VCC).

>
>> Just highlighting everything what is in short is possible with the old behaviour: press F over a shorted net. This is exactly what we want to refine, as it is not helpful on complex boards.
>
> But of course that doesn't work because there are no primitive objects with known net affinites, so F can't identify the specific points where the problem is. And part of that problem (and to me, a source of great confusion) is a lack of primitive objects in the first place.

Nope. You didn't understand what I said: highlighting too much (everything 
that participates in the short), is not helpful, this is my main 
statement. If you can put your hatred away for a moment, you will see this 
is a theoretical statement, and does not do anything with the actual 
software. It applies to your dream-pcb as well.

The second statement was that this theoretical solution, while does not 
help, is possible to generate with the current software.

So you either attack the theoretical statement, but then you can't legally 
mix in your anti-PCB propaganda, or you attack the second, but that means 
you blame the design of the software _because_ it works.


Regards,

Tibor