X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 8 Jul 2015 05:58:32 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] gEDA/gschem still alive?
In-Reply-To: <CAOP4iL3_CPL-3KWfXUSxcM+ZQ=_TtJwRCYwN8ZBa7Js-c=33vw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1507080529500.6924@igor2priv>
References: <1435510363 DOT 682 DOT 26 DOT camel AT ssalewski DOT de> <20150703030409 DOT 32398 DOT qmail AT stuge DOT se> <CAFC5WMoa2-z6bNca_bQN+jmMR260UBmoJQybUzH=L2TrBpzNNA AT mail DOT gmail DOT com> <1436006726 DOT 677 DOT 13 DOT camel AT ssalewski DOT de> <20150706200609 DOT GD24178 AT localhost DOT localdomain>
 <CAC4O8c9f0pLsLu_dyuO5ggh7RmHY1vAA=UUhk9AE0JYZb4mhBQ AT mail DOT gmail DOT com> <CAM2RGhQfPO31-1Uyc3kC7w286r0VD7c41UZEZcyYquzknCxbsQ AT mail DOT gmail DOT com> <20150707060409 DOT GB14357 AT localhost DOT localdomain> <CAOP4iL2C_LU=RQy5FWYF-7RrHW6tqhqqyFJGjkwLQ2AD7FiYJA AT mail DOT gmail DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1507071749560 DOT 6924 AT igor2priv> <CAM2RGhRA9Qt_PNUNzvaZ7OjjKDvrWobCJ2CptFYhBojtbxXXCA AT mail DOT gmail DOT com> <CAOP4iL3_CPL-3KWfXUSxcM+ZQ=_TtJwRCYwN8ZBa7Js-c=33vw AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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



On Tue, 7 Jul 2015, Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

>
>
>On Tue, Jul 7, 2015 at 9:05 AM, Evan Foss (evanfoss AT gmail DOT com) [via
>geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>
>      The Unix mentality these are all independent tools that we
>      choose to
>      combined this way. Most people have avoided binding them via a
>      database because they want to keep things separate.
>
>
>Works great as long as the data in the pipes only flows in one direction.
>What do you do when you need to backannotate from one tool to another?

It's not because pipes have to be unidirectional. It's because the actual 
toolchain lacks the backannotation path. That path can be implemented in a 
path-independent way. This does not depend on having separate tools at 
all; actually back annotation is a great example to demonstrate this, so 
let's take a closer look.

There are multiple ways doing forward annotation; what I do is I run make 
to get new stuff from gschem to pcb. PCB GUI is perpared for 
loading a new netlist or new components and the glue can prepare data in a 
way pcb is happy with. An important aspect is that PCB defines 
"completeness" (rat lines) so after receiving the new info, it can 
clearly show the user what needs to be done so that the PCB macthes the 
_current state of the design_.

But what's the current state of the design? Because we have forward 
annotation-only, currently anything the schematics say, and anyone else 
has to follow the changes on the schematics.

Technically the very same thing could work in the other direction as well: 
I make my modifications in PCB and use external glue to get them back to 
gschem. Then the current design is a bit more distributed and depends on 
where the user made their last modifications. What's needed for this and 
we don't have {what keeps me back from coding it myself}:

1. solve the lack of gschem's idea of "completeness"; sort of rat lines - 
so when I swap connector or GPIO pins on the PCB, gschem would know the 
connections on the schematics are incorrect, would indicate so and the 
user could update the schematics to match the design {scheme}

2. A way gschem could load such information from an external source (e.g. 
files, like PCB does with the netlist) {scheme}.

3. PCB features so that the user can tell PCB that a specific a 
difference/deviation/change in a netlist/footprint/whatever is intended 
and should be back annotated {that point 1. and 2. wouldn't be done}.

4. A glue script in PCB -> gschem direction; it'd probably read the PCB 
file that'd have changes of point 3 marked and would generate the file 
required by point 2 {that point 1. and 2. wouldn't be done}.

Back to your original statement on UNIX mentality: imagine we had an 
integrated tool. It would include gschem and PCB and gnetlist, as one 
monolithic GUI, maybe even written in the same language, but each with 
its current design. It would be something equivalent with the current 
code base, feature-wise. Alternatively imagine you can easily combine 
them into such a monolith with a magic wand.

In either case, exactly which points we wouldn't need to solve of the 
above 4? The only diff I can think of is point 4., which we would still 
need to solve, of course, just it wouldn't be an external script but some 
internal code. Thus I don't see how tighter integration would save any 
work on back annotations.

Regards,

Igor2