X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sat, 23 Jul 2016 23:33:38 +0200 (CEST) From: Roland Lutz To: geda-user AT delorie DOT com Subject: Re: [geda-user] Parameter substitution In-Reply-To: Message-ID: References: <98D1C4E4-581D-4A03-94E4-E0330960EADF AT wellesley DOT edu> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2027178216-1469309469=:1800" Content-ID: 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-2027178216-1469309469=:1800 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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? > 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. - 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. - Pins for subschematic symbols don't require a pinnumber= attribute, and non-slotted pins don't require a pinseq= attribute. - 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). > 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? --8323329-2027178216-1469309469=:1800--