X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: karl AT aspodata DOT se To: geda-user AT delorie DOT com Subject: Re: [geda-user] XML file format (what could be expected) In-reply-to: References: <20151220120219 DOT c4644eef1a65b0eb2fb60d76 AT gmail DOT com> <20151220122659 DOT 378AF809D791 AT turkos DOT aspodata DOT se> <20151220120219 DOT c4644eef1a65b0eb2fb60d76 AT gmail DOT com> <20151220125839 DOT 10228 DOT qmail AT stuge DOT se> <20151220133436 DOT 0B120809D791 AT turkos DOT aspodata DOT se> <0BA0A334-56C7-47B7-959F-C0131BED822C AT noqsi DOT com> <20151220173341 DOT fb4442a7816009e9f4e943b6 AT gmail DOT com> <20151230180007 DOT B4391809D79B AT turkos DOT aspodata DOT se> <20151230194212 DOT 312d35a02f7f667b8b1f92af AT gmail DOT com> Comments: In-reply-to John Doty message dated "Wed, 30 Dec 2015 12:01:24 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <20151230213354.277D0809D79C@turkos.aspodata.se> Date: Wed, 30 Dec 2015 22:33:54 +0100 (CET) X-Virus-Scanned: ClamAV using ClamSMTP 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 John Doty: > On Dec 30, 2015, at 11:42 AM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > >>>> Neither gschem nor the schematic file format need any > >>>> modification to do this. It works nicely with SPICE. It’s a > >>>> downstream issue. > >> > >> Ok, that is one way to do it. I meant more that I wanted gschem to > >> be able to show alt. the formula or the result, i.e. with the > >> parameter/formula applied. > > > > An annotation mechanism may be a solution if could be made > > without adding confusion. I don't know what "annotation" means. > It’s tricky when you consider exporting hierarchical netlists > rather that flattening. The netlisters have to understand either: > > 1. Substitution of the parameters in a flat netlist. > > Or > > 2. Translation of the parameter syntax to that used downstream > in a hierarchical netlist. Wouldn't it suffice for the time being to simply generate a flat netlist. How many downstreams would understand a hierarchical netlist ? Yes, it wwould be nice, but if there is no support for any hierarchical things in downstream, there is no point at implementing it in netlist. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57