X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=BFdwcfFUuwxNb/YMldv6T2df974U5JYamdhlckZfu/k=;
	b=kGED8JrZ3w7vBdJUx7yZEdv7cewg5CHjboXrqudhcfcOp48HOdE7hrL9p/xgAHZL/W
	vBLXK4P+ETd+XgFBrHrr/J3obKYkXG+AZhvF2nBjQ69+mfgjfpWg9A1oqFRaYCorAF94
	asNuIqpqQZd9tQs+hGQc8K7lniNFBejZn/AfebYFgJRzON/dggP2OIYkowSgPglAKC8J
	ch7gX8rXrO6BNhqH3cVSrK5Dx6uVWTtccTsIAE5kCnTOU8t+SpNCwYoE6pYBN6X3iHuU
	y/h9ALcp6/JL4vZJhc8gfSpakHcS1aP+TnohPx5CM3DhR3oCqonUoMyIWedS4/H7CaHF
	C4tQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=BFdwcfFUuwxNb/YMldv6T2df974U5JYamdhlckZfu/k=;
	b=F8BhDwP1qc4gILy2wE8KbkCOyb/LFObA+c8UOBT635Unm3NiJ8x0yyJcztU/zSedWD
	oo+NZqzf5Lm19SZBoqgbr+sQxO2fKw8QEPasKhj0kzSCWukspoojrXsi14QfckNIdxox
	/trQRhDtBw365RJsRmcDw5pDZtgEHKNuz7dJU2NIsltWq2tPXUgdOa4A25ypBRXfgk/E
	ABOdlFpvvE9PV8OMIZb0Rp+QTWyTjykGvvBR0aF+2OkjSUQ0Z4ehl227gbAUQqM41qVW
	ivaYdzeeZKCPfcUqdxetT/XKMBz+lSgkxDFJeE5wvpiiJs5hYFGYLZMkb1CFvRKupuiv
	vfaQ==
X-Gm-Message-State:	AG10YOTUti2cIMjkt9rWeioglkJgb3B1R3qUpKUG31amDrKLsKyTS0uxrCQoNcL5lUI1lHgujziC8Q+waBuHIw==
MIME-Version:	1.0
X-Received:	by 10.28.1.23 with SMTP id 23mr4543237wmb.37.1454006940975; Thu,
	28 Jan 2016 10:49:00 -0800 (PST)
In-Reply-To:	<56AA5948.4090109@ecosensory.com>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
	<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
	<20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com>
	<s6n1t93h4ub DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com>
	<s6npowne74w DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com>
	<s6n37tjt1tv DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
	<56A8F74B DOT 8080304 AT ecosensory DOT com>
	<CAC4O8c9UKLsh5FAAwUMEtHThKH-w3gUmCU2i9dRW9igkyRt-TQ AT mail DOT gmail DOT com>
	<CAJZxidDmjMtd_fKvR5qZVRa+hwDUbvfaz79oZjkBgDuE1m8RBg AT mail DOT gmail DOT com>
	<56A961BC DOT 3040405 AT ecosensory DOT com>
	<CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q AT mail DOT gmail DOT com>
	<s6nbn863xlu DOT fsf AT blaulicht DOT dmz DOT brux>
	<56A9E416 DOT 8080500 AT ecosensory DOT com>
	<20160128124020 DOT 8f2f33210481f637a696f5d0 AT gmail DOT com>
	<CAJZxidD7=NE+Q3FGOU+ER3Xh7TRskEPRTKa=yrwUm51_VaYw0A AT mail DOT gmail DOT com>
	<56AA3753 DOT 6020109 AT ecosensory DOT com>
	<20160128165227 DOT 9c633097c1c9bee6d05423f6 AT gmail DOT com>
	<56AA5948 DOT 4090109 AT ecosensory DOT com>
Date:	Thu, 28 Jan 2016 09:49:00 -0900
Message-ID:	<CAC4O8c8P-Q4pyFqdVVjocRPTCVzRN_EXgB_3yMqy6a2vvkMytw@mail.gmail.com>
Subject:	Re: [geda-user] The nature of gEDA layers (Atomic id)
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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

On Thu, Jan 28, 2016 at 9:09 AM, John Griessen <john AT ecosensory DOT com> wrote:
> On 01/28/2016 09:52 AM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>>>
>>> One thing needed in core data structures is room for and a mechanism for
>>> a unique ID for each atomic board element such as
>>> >trace, pad, polygon, text...
>>
>> Can you explain why?
>
>
> If you had that you could build up physical connectivity DRC check results
> that are accurate is the main reason.
> Then it can be part of attributes used in extracted netlists to compare with
> schematic netlist for simulations.
> It could be used by routers - define a list of elements that act as a
> boundary for this and that.

I believe this already exists, its the ID field of ANYOBJECTFIELDS
defined in global.h.  Each object gets an ID at creation in create.c.
They aren't serialized however, so you presumably get a different ID
each time.  I've never had the urge to use it for anything but it does
get used:

$ cd ../src && grep -e '(->|\.)ID' * | grep -v create.c | grep -v
cscope.out | wc -l
71

- Raw text -