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:17:45 +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: <E5C6D693-D7F1-41B0-934F-CBAFD710D67E@noqsi.com>
Message-ID: <alpine.DEB.2.00.1512300804420.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>
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, 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!

>
>>
>> Look at how these changes happen (in pcb or anywher else). There's a model of the world in the tool; the user performs some actions; the tool converts these actions into changes in the model.
>>
>> What I realized was this: instead of applying the changes to the model and then trying to regain the same changes by diffing two models, it's more efficient to just save the diff. Not because pcb, not because the netlist forma,t not because flow-specific things. Only because the actual user input _is_ a change, and this way I can avoid converting it forth-and-back.
>
> But you can?t do this for, say, geda-gaf->Osmond PCB without helper scripts.

We are talking about the other direction, Osmond PCB -> geda-gaf.

For geda->something, we need scripts (gnetlist and sometimes even other 
things on top of that, like gsch2pcb).

I don't see why we wouldn't accept that a something->geda path wouldn't 
require scripts.

Independently of this, my actual pcb->geda path happens not to require 
extra scripts, because:

- the format is designed so that it is easy to handle and use by gschem

- I found it more useful to implement native support in pcb - this way the 
UI can distinguish between forward and backward annotation

This does not mean any other tool needs to have native support.

> Not that this is hard, and in this case I?ve actually written much of 
> what is needed already.

I don't see the connection with the format. If interfacing between osmond 
and geda is hard, I expect it to be hard in both directions.

>>
>> I don't see any real advantage of not saving the diff but generating the changed model and then regenerating the diff later.
>
> There is no advantage, except that most downstream tools can?t save the diff and are not open source.

So let them save whatever they can and add a script to convert.

The patch format is what actually is needed in gschem, if gschem is to 
show the deviations. The question is whether we pass in the info in this 
format, so gschem doesn't need to try to calculate diffs, or we pass in a 
full model.

Since the format is also close to the actual user input, I believe it 
would be common that open source flows would implement saving the patch 
instead of trying to generate a full model.

So this seems to be the easier way for both geda and the other tool.

If there are some tools where it is impossible to save direcly in this 
format, let the extra scripts go into this problem, instead of 
complicating the flow for the rest.


> So, we need a more general mechanism, much of which would be useful in 
> other ways anyway

Not really. The problem is that Osmond does not save anything directly 
usable by geda. Is osmond open source? If so, you have the chance to 
change it. If not, you need a script anyway. This all does not depend on 
the actual format geda uses - it depends on Osmond.

>>
>>> Some more general approach is needed. Common, canonical forms of netlist and BOM could drive patch file generation, and they could be useful for other things (as others have noted).
>>
>> Since you failed to prove that:
>>
>> - my approach was not generic
>>
>> - yours is more generic
>>
>> - and more generic is really needed
>>
>> your conclusion is wrong.
>
> I don?t understand this. Our approaches are not in conflict.

> But yours won?t work with anything but your pcb variant since other 
> downstream tools can?t directly make your patch file.

False. It's a generic format. There's no requirement on the downstream 
tool to directly emit the patch file.

It's like if you said any flow is invalid that depends on gnetlist and 
can't directly import an sch file.


> All I?m suggesting is that the problem of accommodating other downstream 
> flows could use a common tool to generate your patch file via common 
> canonical formats.

I am for it: if there are common formats downstream tools like to emit, it 
should be easy to write scripts that convert these into patches with 
or without using the original netlist.

However, we shouldn't enforce this on flows where it's not necessary: we 
should allow tools to emit native if they can and want to.

Thus, I don't think the format is not generic enough.