X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-CMAE-Analysis:	v=2.4 cv=ev4acqlX c=1 sm=1 tr=0 ts=6019f0a6
	a=+cj0cO56Fp8x7EdhTra87A==:117 a=qlNXr4QCEXuv9mAflUni8w==:17
	a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19
	a=IkcTkHD0fZMA:10 a=qa6Q16uM49sA:10 a=M8viIMcIzhwtZsI3BzoA:9 a=QEXdDO2ut3YA:10
X-SECURESERVER-ACCT:	glimrick AT epilitimus DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=epilitimus.com; s=default; h=Content-Transfer-Encoding:Content-Type:
	In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:
	Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
	List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=YY/hl1igcQH4uHyQW23BVNGLVh+oO0GeirKqb11zAI8=; b=IVX2VRyMlTdoyxTy+f2MUNn+fo
	uEULpV77wlaFq6+DFXNVeyiayDnOsKG0Q78Fo2iVXW0BcGl5vPEjrZzQpVjnL1NTce/CGjcLBMQQ+
	e8mVIggxDPphN3d/baMkhbeH9s+/6vvScfFv35zExQquBTrNwCgRD7Rjjg1gOdSf6B0mTYg4qhkuu
	BZupPmarz2ih5D25b+tTeKD7gf7bXOfjxcd4LNapTBn4qg2lSOzTx+tNnXQaDIA5TrpA4H0tMWFjW
	KWNxiXC9XMCWAd2h8QaeY6zM7/XlrSuTS/RJ6zfSLC+lZ1htiR6WxnBDMlvd/HtCxw2iGWWYkz5ej
	TajZVnVQ==;
Subject:	Re: [geda-user] recursive subsheet issue
To:	geda-user AT delorie DOT com
References:	<d3f9a609-d761-8646-8f4f-0f3fb3fa6b33 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2102021301260 DOT 1295 AT nimbus>
	<0cc19ac4-217d-0897-52db-8b6fdcbbd975 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 21 DOT 2102022220190 DOT 4264 AT nimbus>
From:	"Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<2fbaecf3-90bb-7282-84f7-8be9adb2bc21@epilitimus.com>
Date:	Tue, 2 Feb 2021 16:39:03 -0800
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Firefox/60.0 SeaMonkey/2.53.3
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.21.2102022220190.4264@nimbus>
X-AntiAbuse:	This header was added to track abuse, please include it with any abuse report
X-AntiAbuse:	Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net
X-AntiAbuse:	Original Domain - delorie.com
X-AntiAbuse:	Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse:	Sender Address Domain - epilitimus.com
X-Get-Message-Sender-Via:	a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender:	a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com
X-Source:
X-Source-Args:
X-Source-Dir:
X-CMAE-Envelope:	MS4xfCkVRWhMs5T82Ewy4i/WCXxMZCNJnhvahUgxFa0AwOpsPpnK+N1sWjmWtZR4gj7Ww+AbkbXJoxBl3CfvvhcHJoWgN+svr5bPz+DnV0+tPmpxm+ruk8xj
	lz68yDejQETUSG90ZBzmRganW9ULUDoI2LPk8RNZvBw+NYNobAaI5PjLYwxMc9RTNgxxL9vMmJO01VcxmtfhIGqceugI8G7nD970cT1dLBPi0YvYlZLSePIj
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

Roland Lutz wrote:
>
> I try to keep using exceptions at a minimum.  In particular, an input
> error should not terminate netlist generation just like a compiler
> error doesn't terminate compilation.
>
> Instead, the error should be reported by calling the "error" method on
> the offending pin, component, or schematic, or, if none of these
> apply, on the netlist object.  This prints the error message along
> with the filename and object coordinates and sets the "failed" flag so
> no netlist is emitted.
>
> For warnings, there is a similar "warn" function which doesn't set the
> failure flag.  The convention is that everything which may result in
> an invalid netlist should be an error, and everything that indicates
> that the resulting netlist will most probably not be what the user
> intended should be a warning.
>
> After reporting the error, netlist generation continues.  Instead of
> the invalid input, the next-valid thing should be assumed; in this
> case, this would probably mean ignoring the offending instantiation. 
> While there may be follow-up errors, seeing the next errors in advance
> may spare the user some unnecessary round-trips.
>
I would say recursive subsheets are pretty well fatal. So call error,
don't process the recursed sheet, continue processing...sounds doable.
>> For the xspice backend, which I have finally started to get back to, I
>> decided it would be nice in the header of the output to provide a
>> listing of the hierarchy from which the netlist was generated in case
>> you don't get the output you are expecting re: refdes etc.
>
> Sounds useful.  If I recall correctly, this information is contained
> in the netlist object which is passed to the backend.
Not directly as far as I can tell. The top level sheets are listed in
the toplevel_sheets member but below that it has to be recreated from
gaf.netlist.Sheet.instantiating_component. At least that is the way I
read the code so far. So take a sheet, walk back up the hierarchy, graft
the path to a tree at the lowest possible point. Alternative is a
downward traveling recursion but then I may as well hack
gaf.netlist.netlist to store the tree as it does exactly that during
netlist generation. So then the question becomes is it useful enough to
make available to all backends via the netlist, or keep it local to the
backend and don't clutter up the netlist structure? I had actually
considered writing a backend that just outputs the hierarchy...still
thinking about it. It would also be useful I think to be able to output
the path to the recursed sheet in the error message for the above, kind
of like a stack trace only for subsheets. hmmm....

Glenn

- Raw text -