Mail Archives: geda-user/2015/12/30/02:15:45
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.
- Raw text -