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: <0cc19ac4-217d-0897-52db-8b6fdcbbd975 AT epilitimus DOT com> From: "Glenn (glimrick AT epilitimus DOT com) [via 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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