X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 30 Dec 2015 08:58:12 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: 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] Project leadership (design error in the core of
 gschem)
In-Reply-To: <6645DDA7-7371-4E11-8B8D-82279DCC7C41@noqsi.com>
Message-ID: <alpine.DEB.2.00.1512300849200.9035@igor2priv>
References: <CAJXU7q_3XwthnN_8mp7B+-ShHeK+=7J=54ZavKBUG3S3bSKp2A AT mail DOT gmail DOT com> <CANEvwqiM7CKG+WpDRpG4L=HsmSEZ32=CBDyUhuk3ks-SNedL2Q AT mail DOT gmail DOT com> <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512290406210 DOT 9035 AT igor2priv>
 <20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com> <CAM2RGhQ363RydhBJKMnNX5sLOkD1K4qVwb-PPwov3MT3D6MfdQ AT mail DOT gmail DOT com> <449C2A4A-814E-4858-ACB3-82807A80BE8A AT noqsi DOT com> <CAM2RGhQD1b0NKLWNYyB-m1whgYJZeEH9syzSs4OZt+22D5hooA AT mail DOT gmail DOT com>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1512300441390 DOT 9035 AT igor2priv> <E8E70657-A89A-4F51-B779-C24E029ABECA AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300611420 DOT 9035 AT igor2priv> <C3D7084C-1A24-4266-806D-C337CFA17322 AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300716090 DOT 9035 AT igor2priv>
 <E5C6D693-D7F1-41B0-934F-CBAFD710D67E AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1512300804420 DOT 9035 AT igor2priv> <6645DDA7-7371-4E11-8B8D-82279DCC7C41 AT noqsi 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 Wed, 30 Dec 2015, John Doty wrote:

>
> On Dec 30, 2015, at 12:17 AM, gedau AT igor2 DOT repo DOT hu wrote:
>
>>
>>
>> On Tue, 29 Dec 2015, John Doty wrote:
>>
>>>
>>> On Dec 29, 2015, at 11:22 PM, gedau AT igor2 DOT repo DOT hu wrote:
>>>
>>>>
>>>>
>>>> On Tue, 29 Dec 2015, John Doty wrote:
>>>>
>>>>>
>>>>> On Dec 29, 2015, at 10:29 PM, gedau AT igor2 DOT repo DOT hu wrote:
>>>>>
>>>>>>>
>>>>>>> A common netlist/bom format with a canonical form (so equivalent netlists would be identical) would be a useful intermediate.
>>>>>>
>>>>>> Could work. To me, the current patch format is much cleaner. I already have fully working code both in pcb-rnd and gschem. If you implement an alternative solution that is at least as capable, let me know.
>>>>>
>>>>> I?m not saying get rid of your patch format. But you took a shortcut generally not available by having pcb make the patch directly.
>>>>
>>>> False. I did make a shortcut, but on a totally different level of abstraction.
>>>
>>> Only available to the geda-gaf->pcb flow.
>>
>> Nope, it's available in the pcb->geda-gaf flow. Not due to the format, not due to the shortcut. Only because I did't implement it for anything else.
>>
>> Please provide your reasoning why anything else couldn't emit a similar format!
>
> Not directly from a tool whose code you can?t modify. Indirectly through through additional scripts, of course, which is my proposal.


That is not a property of the format we choose. That's a property of the 
program. If we go that way, the only acceptable format would be 
one of the formats osmond can already directly export.


>
> How would you implement this for Osmond PCB?

I'll always show both directions.

[gschem] --sch--> [gnetlist] --whateverformat1--> [osmond]
[osmond] --whateverformat2--> [script] --patch--> [gschem]

Depending on the "whateverformat2", the script may need access to the 
original netlist (form the gschem->osmond path). Also depending on the 
format the script may have major functionality overlap with gnetlist. If 
that's the case, it may be reasonable to implement the script within 
gnetlist.

This is one possible flow. There are other possible flows with other 
tools. The one currently implemnted is:

[gschem] --sch--> [gsch2pcb] --multiplefiles--> [pcb]
[pcb] --patch--> [gschem]

My point was that the fact osmond can't directly emit the patch format 
doesn't invalidate other flows where it is possible. It also doesn't tell 
anything about the format itself - it only tells anything about osmond. It 
also doesn't seem to be more complicated than the other direction 
(actually looks exactly the same in complexity).

Thus I can't agree with saying that either the flow or the format is not 
generic enough because you need the same extra step in osmond->gschem 
direction that you need in gschem->osmond direction.