X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com From: geda AT psjt DOT org (Stephan =?utf-8?Q?B=C3=B6ttcher?=) To: Roland Lutz Cc: geda-user AT delorie DOT com Subject: Re: [geda-user] Parameter substitution References: <98D1C4E4-581D-4A03-94E4-E0330960EADF AT wellesley DOT edu> Date: Sun, 24 Jul 2016 00:45:22 +0200 In-Reply-To: (Roland Lutz's message of "Sat, 23 Jul 2016 23:33:38 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u6NMjrFZ003099 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 writes: > On Sat, 23 Jul 2016, Stephan Böttcher wrote: >> Roland Lutz writes: >>> I had a quick glance at the patch, and it seems what you have been >>> doing is roughly equivalent to the parameter substitution patch I >>> submitted a while ago in the experimental netlister feature branch[3]. >> >> This is your xorn netlister, right? > > It's gnetlist, with lots of refactoring. I probably shouldn't have > used a different name in the first place so people don't get the wrong > idea… > >> Those alternatives/branches do not align with my needs. > > The refactored netlister does (except for some small, well-documented > differences) exactly the same thing as the old one. How can that not > align with your needs, if gnetlist does? Why would I need the same thing twice? >> I see these just divide the resources of geda for things I do not >> care about. > > I've looked through your previous mails on this list, and I think > there are several things in the refactored netlister which you might > care about: > > - The individual components which make up a package can be inspected > by the backend, as well as the individual net parts and segments which > make up a net. In fact, *all* information which is available to the > netlister is available to the backend, too. That is John, who likes that :-) Ok, I usually agree with John. > - Processing steps are cleanly separated in individual modules. > There's currently no mechanism in place to do that, but it wouldn't be > a problem to skip, e.g., the slotting mechanism in the netlisting > process. What I'd like is a generalisation of slotting. For example Move the slotdefs into the pins. Allow all attribute values to be replaced selected by keys, including lower level (pin) attributes. pin attributes: pinnumber=1 pinnumber[SLOT1]=1 pinnumber[SLOT2]=4 pinnumber[SLOT3]=13 pinnumber[SLOT4]=10 component attributes footprint=MSOP14 footprint[MSOP]=MSOP14 footprint[SO]=SO14 footprint[DIL]=DIL14 instance attributes select=SLOT1,SO maybe even pinnumber[DIL,SLOT1]=2 (all keys must be present) Select the match with most keys. Warn if multiple selections (same number of keys) match. Imagine one transistor symbol for all permutations of pin numbers, associated to package selects. I have not used real slotting much. I have abused it sometimes, so selct between package options. > - Pins for subschematic symbols don't require a pinnumber= attribute, > and non-slotted pins don't require a pinseq= attribute. Have they ever required those? > - Named nets, subschematic pins, and port symbols can be connected > (though some of these are IIRC set to produce a netlister error). ? > - There are a lot of useful warning and error messages for cases in > which the old netlister silently produced erroneous output (e.g., > identical or missing port symbols in a subschematic or slotting > errors). So, yes, maybe in a future project, I may look into that. I am still using gsch2pcb. Can xorn be plugged into that? >> I understood that the semantics shall be discussed, before a patch >> like this could be considered. No such discussion evolved. In 2012 >> there was nobody available to discuss. The only response was: put >> it into the launchpad buftracker. It was sitting there ever since. > > Unfortunately, that's how things are usually going with gEDA. > >> Now, how about true hierarchical PCB layout? > > I've been thinking about that much, but haven't yet come up with a > really convincing idea on how that should work. Do you have any > suggestions? Just like for chip layout. Or inkscape groups. -- Stephan