X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Message-ID: <1355450625.2993.18.camel@localhost>
Subject: Re: [geda-user] Find rat lines
From: Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To: geda-user AT delorie DOT com
Date: Fri, 14 Dec 2012 02:03:45 +0000
In-Reply-To: <201212140122.qBE1MoKM019255@envy.delorie.com>
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>
	 <201212140010 DOT qBE0ABjV023762 AT envy DOT delorie DOT com>
	 <172CCAAB-0423-43EF-8A04-5A9961F1D5B9 AT noqsi DOT com>
	 <201212140122 DOT qBE1MoKM019255 AT envy DOT delorie DOT com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.0-0ubuntu3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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 Thu, 2012-12-13 at 20:22 -0500, DJ Delorie wrote:
> > To expand on my confusion, I cannot understand how this could be
> > difficult
> 
> An example of the difficulty: the user selects a region of items on
> the pcb and moves them to the other side, or even just moves them
> elsewhere.  The simplistic "first touch" netlist ownership method
> fails miserably with those simple commands, because a huge number of
> connections change simultaneously.
> 
> Even something as simple as adding a single trace could "short"
> multiple existing subnets, and if some of those subnets have been
> assigned to nets but some subnets are as yet unassigned (because they
> have yet to connect to something known to be in the netlist), you get
> lots of arbitrary choices to be made about how everything needs to be
> resolved.

Yes,

It is really important that we can handle the "it's already shorted"
case with the algorithm.

This is important for the reasons DJ mentioned (e.g. bulk moves /
breakage), but ALSO, for netlist changes driven from the schematic.

Lets say I have all my ICs connected to a common power-rail, but later I
decide to split some sensitive analogue parts onto their own rail,
filtered with a pi-network or similar.

Bang.. all pre-assigned nets are wrong, and you get to keep the broken
pieces.

-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics