[geda-user] SchemeIt

[Joshua Lansford]

Hey Guys,
Just saw Scheme-It by DigiKey anounced a couple weeks back. I know there
has already been discussions on how trusting online tools is bad. I
thought I would post this as simply a reference to other "stuff" which is
out there for inspiration. Scheme-It does seem to have nice net stretching
and multi-page support which gschem might like someday.
http://www.digikey.com/en/resources/scheme-it
~Joshua

[Ouabache Designworks]

On Tue, Oct 14, 2014 at 5:52 AM, Joshua Lansford <

Post by Joshua Lansford
Hey Guys,
Just saw Scheme-It by DigiKey anounced a couple weeks back. I know there
has already been discussions on how trusting online tools is bad. I
thought I would post this as simply a reference to other "stuff" which is
out there for inspiration. Scheme-It does seem to have nice net stretching
and multi-page support which gschem might like someday.
http://www.digikey.com/en/resources/scheme-it
~Joshua

How do you get a netlist out of it?

John Eaton

[Joshua Lansford]

Post by Ouabache Designworks
How do you get a netlist out of it?
John Eaton

Doesn't look like it is possible.
http://electronicdesign.com/products/still-drawing-circuits-napkin-try-scheme-it-instead

I suppose it must be some sort of lock-in strategy.
~Joshua

[Roger Williams]

Scheme-it isn't intended to be an EDA front-end. It's just a drawing tool.

Aspen Labs, the company that developed the technology, described Scheme-it as a sort of "Visio for electronics".
--
Roger Williams <roger-Ug/***@public.gmane.org>
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Ouabache Designworks
How do you get a netlist out of it?
John Eaton
Doesn't look like it is possible.
http://electronicdesign.com/products/still-drawing-circuits-napkin-try-scheme-it-instead
I suppose it must be some sort of lock-in strategy.
~Joshua

[Enoch]

Post by Roger Williams
Scheme-it isn't intended to be an EDA front-end. It's just a drawing tool.
Aspen Labs, the company that developed the technology, described Scheme-it as a sort of "Visio for electronics".

Hi,

How do people here feel about collaboration tools such as:
https://upverter.com/

It is being promoted even by the Open Hardware "BeagleBone Black"
project: http://beagleboard.org/black (see "Fork me on Upverter").

It seems to me that geda needs to adapt to this new trend,
somehow... that is, develop "git" like capabilities at the abstraction
level of the shcematics (not at the primitive sch source lines level).

Adapt or Die :-)

Thanks, Enoch.

[Ouabache Designworks]

Post by Enoch
Hi,
https://upverter.com/
It is being promoted even by the Open Hardware "BeagleBone Black"
project: http://beagleboard.org/black (see "Fork me on Upverter").
It seems to me that geda needs to adapt to this new trend,
somehow... that is, develop "git" like capabilities at the abstraction
level of the shcematics (not at the primitive sch source lines level).
Adapt or Die :-)
Thanks, Enoch.

1) It costs $$$$$

2) You don`t buy it , you rent it. If the company fails then the tool stops
working.

3) You can import from several formats but no mention of export. Welcome to
the Hotel California.

4) If that company dies then they take all of your current and past work
with them.

Its all about the data. You must never lose access to any past design work
that you have done


John Eaton

[Roger Williams]

Very true! But that doesn't address Enoch's main proposal, which is that "geda needs to adapt to this new trend" [collaborative schematic capture and PCB layout] by developing [SCM] capabilities at the schematic abstraction level, not the text string level.

Indeed, if the desired model is really multiple designers simultaneously editing the same schematic page, some clever rethinking about SCM is needed. But I don't believe that anyone really wants to work that way, and I'm sceptical about upverter's ability to cleanly support it. In my experience, collaborative design always means different designers working on different parts of the design. And SCM tools like git and svn do a good job of supporting that working model.

Now, what upverter does offer is a very large component library and handy graphical tools to simplify footprint and symbol creation, and tight integration between the schematic capture and PCB layout tools.
--
Roger Williams <roger-Ug/***@public.gmane.org>
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Enoch
Hi,
https://upverter.com/
It is being promoted even by the Open Hardware "BeagleBone Black"
project: http://beagleboard.org/black (see "Fork me on Upverter").
It seems to me that geda needs to adapt to this new trend,
somehow... that is, develop "git" like capabilities at the abstraction
level of the shcematics (not at the primitive sch source lines level).
Adapt or Die :-)
Thanks, Enoch.
1) It costs $$$$$
2) You don`t buy it , you rent it. If the company fails then the tool stops working.
3) You can import from several formats but no mention of export. Welcome to the Hotel California.
4) If that company dies then they take all of your current and past work with them.
Its all about the data. You must never lose access to any past design work that you have done
John Eaton

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

Post by Roger Williams
Now, what upverter does offer is a very large component library and handy
graphical tools to simplify footprint and symbol creation, and tight
integration between the schematic capture and PCB layout tools.

Not having libraries that really work and that cover the components we're
using, is a much bigger impediment to collaborative design than not having
application-specific source control integration.

[Britton Kerin]

Post by mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/

Post by Roger Williams
Now, what upverter does offer is a very large component library and handy
graphical tools to simplify footprint and symbol creation, and tight
integration between the schematic capture and PCB layout tools.

Not having libraries that really work and that cover the components we're
using, is a much bigger impediment to collaborative design than not having
application-specific source control integration.

Agreed. The huge weakness gEDA has is the total lack of any agreed upon
way of reusing component descriptions and subcircuits. Everyone has their
own private way of doing it.

A short while ago someone came up with IIRC a way to roll component libraries
into sch files. This is a step in the right direction. Has anyone gotten
around to trying this?

I meant to try it but haven't done so, and as usual I'm not sure where the
code for it ended up.

Britton

[Enoch]

Post by Enoch
Hi,
https://upverter.com/
It is being promoted even by the Open Hardware "BeagleBone Black"
project: http://beagleboard.org/black (see "Fork me on Upverter").
It seems to me that geda needs to adapt to this new trend,
somehow... that is, develop "git" like capabilities at the abstraction
level of the shcematics (not at the primitive sch source lines level).
Adapt or Die :-)
Thanks, Enoch.
1) It costs $$$$$
2) You don`t buy it , you rent it. If the company fails then the tool stops working.
3) You can import from several formats but no mention of export. Welcome to the Hotel California.
4) If that company dies then they take all of your current and past work with them.
Its all about the data. You must never lose access to any past design work that you have done
John Eaton

Though Open Hardware projects they charge nothing I agree with you
completely.

What I am more interested in drawing the attention to is their
presumably easy collaboration at schmeatics ("data") level. Geda does an
impressive colaboration at tools, git and friends make it easy for
us. Generations of talented programmers keep this project alive for
years... but what about collaborative creation of data, the next
BeagleBone like design?

Suppose you and I work on a common design project, you move resistors
around, you change values, ... how am I supposed to see your changes, by
doing a diff on the sch or pcb ASCII files... I believe that Geda should start
adding tags to the sch and pcb which are related to version control.

In short, add revision control support within gschem, within pcb, etc.

Is this a pipe dream?

Thanks, Enoch.

[Ivan Stankovic]

Post by Enoch
What I am more interested in drawing the attention to is their
presumably easy collaboration at schmeatics ("data") level. Geda does an
impressive colaboration at tools, git and friends make it easy for
us. Generations of talented programmers keep this project alive for
years... but what about collaborative creation of data, the next
BeagleBone like design?

I'm afraid more and more designs of such complexity will probably not be
made by using gEDA, except maybe for few people that have their own
private forks, scripts and basically very special workflows that,
really, should not have been necessary.

Although I do not want to beat a dead horse (again), I have to say that
gEDA simply does not address the issues of modern complex designs.
Complex designs require much better integration and more functionality
than is currently provided by gEDA.

Now, I'm sure there are some who will jump in and say that every design
that can be done using other EDA tools can also be done using gEDA. And
while I may agree for the most part, I have to ask, at what cost?
Sure, you could conceivably build a house with only a hammer and a
shovel, but would you really want to?

Post by Enoch
Suppose you and I work on a common design project, you move resistors
around, you change values, ... how am I supposed to see your changes, by
doing a diff on the sch or pcb ASCII files... I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.
Is this a pipe dream?

I'd say it is.

[Britton Kerin]

Post by Ivan Stankovic

Post by Enoch
What I am more interested in drawing the attention to is their
presumably easy collaboration at schmeatics ("data") level. Geda does an
impressive colaboration at tools, git and friends make it easy for
us. Generations of talented programmers keep this project alive for
years... but what about collaborative creation of data, the next
BeagleBone like design?

I'm afraid more and more designs of such complexity will probably not be
made by using gEDA, except maybe for few people that have their own
private forks, scripts and basically very special workflows that,
really, should not have been necessary.
Although I do not want to beat a dead horse (again), I have to say that
gEDA simply does not address the issues of modern complex designs.
Complex designs require much better integration and more functionality
than is currently provided by gEDA.

Exactly what are you thinking of, besides the ability to *encapsulate*
what you have done, and *share* it?

Post by Ivan Stankovic
Now, I'm sure there are some who will jump in and say that every design
that can be done using other EDA tools can also be done using gEDA. And
while I may agree for the most part, I have to ask, at what cost?
Sure, you could conceivably build a house with only a hammer and a
shovel, but would you really want to?

Post by Enoch
Suppose you and I work on a common design project, you move resistors
around, you change values, ... how am I supposed to see your changes, by
doing a diff on the sch or pcb ASCII files... I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.
Is this a pipe dream?

I'd say it is.

So how many crazy people really do hardware design this way? If you're working
on the same subsystem as me, and you come in and make changes like the above
without talking to me, I'm gonna be pissed. scm is a terrible substitute
for communication even for software and doubly so for hardware, where the
coupling of all the pieces of a subsystem is usually pretty tight. Forget
about collaboration tools designed to compensate for designer deficiencies
and worry about more fundamental capabilities, like sharable modules.

Britton

[Evan Foss]

At work we have a gforge setup that uses git. Now we coordinate who
does what so the following has never been done but if we both edit a
page.

1. You check the comments
2. Check the actual schematic page(s).
3. There is code out there for doing visual diff of them. (i would
love a git web plugin for this and preview)
4. You talk to the other user.

When you have multiple users working on the same project people
generally have to break off parts of the design. It is the only way to
coordinate anything. So the issue you are imagining is very rare for
schematics. PCB layout can get more hairy.

Post by Britton Kerin

Post by Ivan Stankovic

Post by Enoch
What I am more interested in drawing the attention to is their
presumably easy collaboration at schmeatics ("data") level. Geda does an
impressive colaboration at tools, git and friends make it easy for
us. Generations of talented programmers keep this project alive for
years... but what about collaborative creation of data, the next
BeagleBone like design?

I'm afraid more and more designs of such complexity will probably not be
made by using gEDA, except maybe for few people that have their own
private forks, scripts and basically very special workflows that,
really, should not have been necessary.
Although I do not want to beat a dead horse (again), I have to say that
gEDA simply does not address the issues of modern complex designs.
Complex designs require much better integration and more functionality
than is currently provided by gEDA.

Exactly what are you thinking of, besides the ability to *encapsulate*
what you have done, and *share* it?

Post by Ivan Stankovic
Now, I'm sure there are some who will jump in and say that every design
that can be done using other EDA tools can also be done using gEDA. And
while I may agree for the most part, I have to ask, at what cost?
Sure, you could conceivably build a house with only a hammer and a
shovel, but would you really want to?

Post by Enoch
Suppose you and I work on a common design project, you move resistors
around, you change values, ... how am I supposed to see your changes, by
doing a diff on the sch or pcb ASCII files... I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.
Is this a pipe dream?

I'd say it is.

So how many crazy people really do hardware design this way? If you're working
on the same subsystem as me, and you come in and make changes like the above
without talking to me, I'm gonna be pissed. scm is a terrible substitute
for communication even for software and doubly so for hardware, where the
coupling of all the pieces of a subsystem is usually pretty tight. Forget
about collaboration tools designed to compensate for designer deficiencies
and worry about more fundamental capabilities, like sharable modules.
Britton

[John Griessen]

Post by Enoch
I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.

We have attributes. All that is needed for a VCS merge to work easily is
same handling of white space in file structure no matter how or in what order
a drawing is created. Possibly another external tool could alphabetize
the lines in a .sch or .pcb file so each collaborator would have
merges go in the same spot in the files... or possibly that "alphabetic
sorting" of lines of a .sch or .pcb file could be done internally.

I don't see any need or anyone with time to spend on reinventing a VCS within
PCB or gschem, just use one externally on the data.

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

Post by John Griessen
I don't see any need or anyone with time to spend on reinventing a VCS within
PCB or gschem, just use one externally on the data.

That's great as long as the files remain text files. I hope they will.

[gedau-1XeMD6fE9sqV9CSZFf/]

Post by John Griessen

Post by Enoch
I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.

We have attributes. All that is needed for a VCS merge to work easily is
same handling of white space in file structure no matter how or in what order
a drawing is created. Possibly another external tool could alphabetize
the lines in a .sch or .pcb file so each collaborator would have
merges go in the same spot in the files... or possibly that "alphabetic
sorting" of lines of a .sch or .pcb file could be done internally.
I don't see any need or anyone with time to spend on reinventing a VCS within
PCB or gschem, just use one externally on the data.

In general I agree: reinventing VCS in each tool is a bad thing.

In some details I do not agree, and probably all these stem from
the same source: meaningless diffs. IIRC there have been some efforts to
make the tools keep some order (of objects, attributes, etc) on
save/edit/load cycles, which reduced the amount of diffs by reducing the
noise.

However, looking at a diff on two sch files or two pcb files won't really
show the user what's changed except for a few very trivial cases:
- when a specific existing numeric/text data field has changes (e.g.
drill size in pcb, attribute data in sch)
- when a few existing elements are deleted and nothing else changed
- when a few new elements are added and nothing else changed

Where it certainly won't help:
- object coord changes, things getting moved around in pcb
- logical connections change in sch
- pcb element or sch symbol gets replaced
- sch element gets embedded or unembedded

In my practice after the initial few commits the latter group makes up
majority of the changes. In my experience the PCB file format is more
friendly to diffing (in the sense that reading the diff on a terminal may
yield useful result) while the sch format is nearly unusable this way.
Please note that I do know the formats a bit, I often write scripts
processing/editing both pcb and sch files - still, I find the sch format
generally hard to manually handle both in original form and in diff form.

Some of the above issues could be solved by changing the file format,
especially on sch where coordinates of things shouldn't matter much; for
example a format that would:
- store symbols+attributes blocks separately from coordinates
- would be restructured and indented for easier manual read (my daily
PITA is figuring which attribute blocks are corresponding to which
component and which attribute survives of the multiple blocks of an
embedded sym)
- a new structure should actively help diff to show useful context; if
there are like 10 attributes of a symbol and the value of the last one
changes, in the diff the attribute value change is visible, but usually
not enough context to identify which component's attribute has changed;
increasing the number of context lines doesn't help since this would
increase the nosie too
- separate coordinate info and pin connection info on nets; e.g. instead
of a list of coordinates, a net would be a list of connection between
named component/pins and where needed (automatically named) non-component
hub points

Diff on such a format would reveal how the connections have changed (among
with a set of random-looking coord changes at the bottom which the user
then could simply ignore).

However, I can't imagine anything similar for PCB - PCB is all about the
geometry of the layout, so all about coords and I don't think any textual
diff would be fully readable on these. This means meaningful diffs in PCB
world would mean a GUI diff tool unfortunately. I know about a
graphical PCB diff tool, but that operates with diffing rendered PNGs
(IIRC); that's not really comparable to diff(1).

Once one accepts the above for PCB, it's a valid question whether the same
should be done to gschem instead of changing the file format to be more
diff(1) friendly.



However, once the diff problem is solved, with file format change, with
external tools or with new features within the tools, I wouldn't go any
further in VCS integration, especially wouldn't try to integrate with a
specific VCS system (or a group of specific VCS systems). As a UNIX user
I believe a VCS should be used as a VCS and an (pcb, schematics, etc.)
editor should be used as an editor. So far I prefer gschem and pcb over
more integrated suites exactly for this sort of decoupling.

Regards,

Tibor

[Evan Foss]

I agree that we want to use external version control. Besides people
will want to use the one they are most friendly with. Forcing everyone
into one integrated into the tool will start a "My VCS is better than
yours" fight that I want no part of.

When I said visual diff I meant taking the schematics exported as PDF
and a diff on those images not a diff on the text. There is code for
this.

Post by gedau-1XeMD6fE9sqV9CSZFf/

Post by John Griessen

Post by Enoch
I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.

We have attributes. All that is needed for a VCS merge to work easily is
same handling of white space in file structure no matter how or in what order
a drawing is created. Possibly another external tool could alphabetize
the lines in a .sch or .pcb file so each collaborator would have
merges go in the same spot in the files... or possibly that "alphabetic
sorting" of lines of a .sch or .pcb file could be done internally.
I don't see any need or anyone with time to spend on reinventing a VCS within
PCB or gschem, just use one externally on the data.

In general I agree: reinventing VCS in each tool is a bad thing.
In some details I do not agree, and probably all these stem from the same
source: meaningless diffs. IIRC there have been some efforts to make the
tools keep some order (of objects, attributes, etc) on save/edit/load
cycles, which reduced the amount of diffs by reducing the noise.
However, looking at a diff on two sch files or two pcb files won't really
- when a specific existing numeric/text data field has changes (e.g. drill
size in pcb, attribute data in sch)
- when a few existing elements are deleted and nothing else changed
- when a few new elements are added and nothing else changed
- object coord changes, things getting moved around in pcb
- logical connections change in sch
- pcb element or sch symbol gets replaced
- sch element gets embedded or unembedded
In my practice after the initial few commits the latter group makes up
majority of the changes. In my experience the PCB file format is more
friendly to diffing (in the sense that reading the diff on a terminal may
yield useful result) while the sch format is nearly unusable this way.
Please note that I do know the formats a bit, I often write scripts
processing/editing both pcb and sch files - still, I find the sch format
generally hard to manually handle both in original form and in diff form.
Some of the above issues could be solved by changing the file format,
especially on sch where coordinates of things shouldn't matter much; for
- store symbols+attributes blocks separately from coordinates
- would be restructured and indented for easier manual read (my daily PITA
is figuring which attribute blocks are corresponding to which component and
which attribute survives of the multiple blocks of an embedded sym)
- a new structure should actively help diff to show useful context; if
there are like 10 attributes of a symbol and the value of the last one
changes, in the diff the attribute value change is visible, but usually not
enough context to identify which component's attribute has changed;
increasing the number of context lines doesn't help since this would
increase the nosie too
- separate coordinate info and pin connection info on nets; e.g. instead of
a list of coordinates, a net would be a list of connection between named
component/pins and where needed (automatically named) non-component hub
points
Diff on such a format would reveal how the connections have changed (among
with a set of random-looking coord changes at the bottom which the user then
could simply ignore).
However, I can't imagine anything similar for PCB - PCB is all about the
geometry of the layout, so all about coords and I don't think any textual
diff would be fully readable on these. This means meaningful diffs in PCB
world would mean a GUI diff tool unfortunately. I know about a graphical PCB
diff tool, but that operates with diffing rendered PNGs (IIRC); that's not
really comparable to diff(1).
Once one accepts the above for PCB, it's a valid question whether the same
should be done to gschem instead of changing the file format to be more
diff(1) friendly.
However, once the diff problem is solved, with file format change, with
external tools or with new features within the tools, I wouldn't go any
further in VCS integration, especially wouldn't try to integrate with a
specific VCS system (or a group of specific VCS systems). As a UNIX user I
believe a VCS should be used as a VCS and an (pcb, schematics, etc.) editor
should be used as an editor. So far I prefer gschem and pcb over more
integrated suites exactly for this sort of decoupling.
Regards,
Tibor

[Enoch]

Post by gedau-1XeMD6fE9sqV9CSZFf/

Post by John Griessen

Post by Enoch
I believe that Geda should start
adding tags to the sch and pcb which are related to version control.
In short, add revision control support within gschem, within pcb, etc.

We have attributes. All that is needed for a VCS merge to work easily is
same handling of white space in file structure no matter how or in what order
a drawing is created. Possibly another external tool could alphabetize
the lines in a .sch or .pcb file so each collaborator would have
merges go in the same spot in the files... or possibly that "alphabetic
sorting" of lines of a .sch or .pcb file could be done internally.
I don't see any need or anyone with time to spend on reinventing a VCS within
PCB or gschem, just use one externally on the data.

In general I agree: reinventing VCS in each tool is a bad thing.
In some details I do not agree, and probably all these stem from the same source: meaningless diffs. IIRC there have been some efforts to make the tools keep some order (of objects, attributes, etc)
on save/edit/load cycles, which reduced the amount of diffs by reducing the noise.
- when a specific existing numeric/text data field has changes (e.g. drill size in pcb, attribute data in sch)
- when a few existing elements are deleted and nothing else changed
- when a few new elements are added and nothing else changed
- object coord changes, things getting moved around in pcb
- logical connections change in sch
- pcb element or sch symbol gets replaced
- sch element gets embedded or unembedded
In my practice after the initial few commits the latter group makes up majority of the changes. In my experience the PCB file format is more friendly to diffing (in the sense that reading the diff on
a terminal may yield useful result) while the sch format is nearly unusable this way. Please note that I do know the formats a bit, I often write scripts processing/editing both pcb and sch files -
still, I find the sch format generally hard to manually handle both in original form and in diff form.
- store symbols+attributes blocks separately from coordinates
- would be restructured and indented for easier manual read (my daily PITA is figuring which attribute blocks are corresponding to which component and which attribute survives of the multiple blocks
of an embedded sym)
- a new structure should actively help diff to show useful context; if there are like 10 attributes of a symbol and the value of the last one changes, in the diff the attribute value change is
visible, but usually not enough context to identify which component's attribute has changed; increasing the number of context lines doesn't help since this would increase the nosie too
- separate coordinate info and pin connection info on nets; e.g. instead of a list of coordinates, a net would be a list of connection between named component/pins and where needed (automatically
named) non-component hub points
Diff on such a format would reveal how the connections have changed (among with a set of random-looking coord changes at the bottom which the user then could simply ignore).
However, I can't imagine anything similar for PCB - PCB is all about the geometry of the layout, so all about coords and I don't think any textual diff would be fully readable on these. This means
meaningful diffs in PCB world would mean a GUI diff tool unfortunately. I know about a graphical PCB diff tool, but that operates with diffing rendered PNGs (IIRC); that's not really comparable to
diff(1).
Once one accepts the above for PCB, it's a valid question whether the same should be done to gschem instead of changing the file format to be more diff(1) friendly.
However, once the diff problem is solved, with file format change, with external tools or with new features within the tools, I wouldn't go any further in VCS integration, especially wouldn't try to
integrate with a specific VCS system (or a group of specific VCS systems). As a UNIX user I believe a VCS should be used as a VCS and an (pcb, schematics, etc.) editor should be used as an editor. So
far I prefer gschem and pcb over more integrated suites exactly for this sort of decoupling.
Regards,
Tibor

I have a dream that one day we shall all have a git-blame like gschem
display mode, I have a dream :-)

Thanks, Enoch.

[John Griessen]

Where it certainly won't help: - object coord changes, things getting moved around in pcb - logical connections change in sch -
pcb element or sch symbol gets replaced - sch element gets embedded or unembedded
In my practice after the initial few commits the latter group makes up majority of the changes.

Yes, that does stop an external VCS from helping merges. It's a harder problem than my first glance idea.

a format that would: - store symbols+attributes blocks separately from coordinates - would be restructured and indented for
easier manual read (my daily PITA is figuring which attribute blocks are corresponding to which component and which attribute
survives of the multiple blocks of an embedded sym) - a new structure should actively help diff to show useful context; if
there are like 10 attributes of a symbol and the value of the last one changes, in the diff the attribute value change is
visible, but usually not enough context to identify which component's attribute has changed; increasing the number of context
lines doesn't help since this would increase the nosie too - separate coordinate info and pin connection info on nets; e.g.
instead of a list of coordinates, a net would be a list of connection between named component/pins and where needed
(automatically named) non-component hub points
Diff on such a format would reveal how the connections have changed (among with a set of random-looking coord changes at the
bottom which the user then could simply ignore).

What if that format was created by an external lint program instead of being part of every design file?

meaningful diffs in PCB world would mean a GUI diff tool

Yes, sounds right. And also it would be great to have a fuzzy visual diff that showed some circuitry
shoved a little to the side still matching. Highlighting of who the owner of the discrepancy is based on
a previous and a 2nd previous drawing might be helpful to keep collaborators from
accidentally changing something. In PCB a visual diff could be used just to enforce working in separate corners
of a drawing for easy merging. Suppose visual diffs were done every 3 minutes and a zone in between called
a no-person's-land was checked for changes and alarmed if any stepping on occurs.

John

[Evan Foss]

I think we want the diff functions internal to the geda and friends
and the version control external.

For those who have not seen the visual diff I am talking about.
http://www.evilmadscientist.com/2011/improving-open-source-hardware-visual-diffs/
It would be nice to do this stuff internally. That is with out going
through external tools and doing the pdf export. That way we could
more eligantly merge features between versions.

Post by John Griessen

Where it certainly won't help: - object coord changes, things getting
moved around in pcb - logical connections change in sch -
pcb element or sch symbol gets replaced - sch element gets embedded or unembedded
In my practice after the initial few commits the latter group makes up
majority of the changes.

Yes, that does stop an external VCS from helping merges. It's a harder
problem than my first glance idea.

a format that would: - store symbols+attributes blocks separately from
coordinates - would be restructured and indented for
easier manual read (my daily PITA is figuring which attribute blocks are
corresponding to which component and which attribute
survives of the multiple blocks of an embedded sym) - a new structure
should actively help diff to show useful context; if
there are like 10 attributes of a symbol and the value of the last one
changes, in the diff the attribute value change is
visible, but usually not enough context to identify which component's
attribute has changed; increasing the number of context
lines doesn't help since this would increase the nosie too - separate
coordinate info and pin connection info on nets; e.g.
instead of a list of coordinates, a net would be a list of connection
between named component/pins and where needed
(automatically named) non-component hub points
Diff on such a format would reveal how the connections have changed (among
with a set of random-looking coord changes at the
bottom which the user then could simply ignore).

What if that format was created by an external lint program instead of being
part of every design file?

meaningful diffs in PCB world would mean a GUI diff tool

Yes, sounds right. And also it would be great to have a fuzzy visual diff
that showed some circuitry
shoved a little to the side still matching. Highlighting of who the owner
of the discrepancy is based on
a previous and a 2nd previous drawing might be helpful to keep collaborators from
accidentally changing something. In PCB a visual diff could be used just to
enforce working in separate corners
of a drawing for easy merging. Suppose visual diffs were done every 3
minutes and a zone in between called
a no-person's-land was checked for changes and alarmed if any stepping on occurs.
John

[John Griessen]

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.

The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.

That's FOSS-volunteer-feasible.

[Evan Foss]

Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.

Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

[Evan Foss]

I believe is that visual diff is coming to a lot of other document
types and the people who make the web interfaces for a lot of version
control systems will end up adding plugins to call functions like what
I just suggested.

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

[Roger Williams]

Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.

I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Roger Williams <roger-Ug/***@public.gmane.org>
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

[Evan Foss]

Thanks Roger.

I am curious though. Would it not make more sense to use the command
line version of diffpdf? Personally I prefer to draft in GUI but do
all the other stuff from makefiles and things. I don't mean to talk
you out of contributing.

Has anyone looked for schdiff(1) in
http://wiki.geda-project.org/geda:gaf
I never noticed it was there.

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

[Roger Williams]

Sorry, I wasn't clear.

I was referring to the feasibility of creating a "gschdiff" utility that renders a visual diff of two raw schematic files using the libgeda libraries.
--
Roger Williams <roger-Ug/***@public.gmane.org>
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Thanks Roger.
I am curious though. Would it not make more sense to use the command
line version of diffpdf? Personally I prefer to draft in GUI but do
all the other stuff from makefiles and things. I don't mean to talk
you out of contributing.
Has anyone looked for schdiff(1) in
http://wiki.geda-project.org/geda:gaf
I never noticed it was there.

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

[Evan Foss]

Using libgeda for gschdiff is more like what I was imagining.

All this talk about version control and diff is making me wonder.
Visual diff is sweet and all but I feel like we are missing something
work flow wise.

Post by Roger Williams
Sorry, I wasn't clear.
I was referring to the feasibility of creating a "gschdiff" utility that renders a visual diff of two raw schematic files using the libgeda libraries.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Thanks Roger.
I am curious though. Would it not make more sense to use the command
line version of diffpdf? Personally I prefer to draft in GUI but do
all the other stuff from makefiles and things. I don't mean to talk
you out of contributing.
Has anyone looked for schdiff(1) in
http://wiki.geda-project.org/geda:gaf
I never noticed it was there.

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

Post by Roger Williams
Hmm, I tend to agree with Evan. The strength of FOSS tools (and UNIX utilities in general) have always been their ability to be used as parts of a flexible toolbox that can be combined as needed. This is even true of large EDA tools, so long as they rely on text files as their medium.
I've built, examined, and built the diffPDF code under Linux and OSX, and I think that it is certainly feasible for a single volunteer to develop a visual "gschdiff" utility. Probably the largest workload would be adapting the Qt code to Gtk.
--
Chief Technical Officer, Qux Corporation
245 Russell Street, Hadley, MA 01035, USA
Tel [phone] * Fax [phone]

Post by Evan Foss
Why can't we have a gschdiff command that generates colorized or
shaded (for the color blind) schematic files where the file A is one
shade and file B is the other.
Why is that FOSS-volunteer-infeasible?

Post by John Griessen

Post by Evan Foss
I think we want the diff functions internal to the geda and friends
and the version control external.

I don't see that as easy in the context of volunteer developers.
The internal part could be limited to defining the no-person's-land
zone, and exporting the data in that zone, without netlist,
for use by an external diff program and the results tracked by
an external VCS.
That's FOSS-volunteer-feasible.

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

[Svenn Are Bjerkem]

Post by Evan Foss
Using libgeda for gschdiff is more like what I was imagining.
All this talk about version control and diff is making me wonder.
Visual diff is sweet and all but I feel like we are missing something
work flow wise.

What do you have in mind on work flow? make does a good job gluing the
command line tools together in my work flows.

[Evan Foss]

Well I think Roger and I are on the same page about diff. I like make
it does the job well. Sorry workflow was the wrong word. I was just
wondering if like diff there was something obvious missing in the
toolchain.

The for software we have diff, patch and etc. I am just wondering what
other tools we could create parity for and how that might work.

PS: Is anyone else going to the MIT Amateur Radio Flee tomorrow?




On Sat, Oct 18, 2014 at 4:50 PM, Svenn Are Bjerkem

Post by Svenn Are Bjerkem

Post by Evan Foss
Using libgeda for gschdiff is more like what I was imagining.
All this talk about version control and diff is making me wonder.
Visual diff is sweet and all but I feel like we are missing something
work flow wise.

What do you have in mind on work flow? make does a good job gluing the
command line tools together in my work flows.
--
Svenn

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

Post by Evan Foss
it does the job well. Sorry workflow was the wrong word. I was just
wondering if like diff there was something obvious missing in the
toolchain.

I think the obvious thing missing is integration between schematic capture
and PCB layout, and both with the desktop environment. I've already
griped here on the list about diodes getting reversed, and I won't
belabour that beyond saying that it's a dealbreaker. But we also have
different hotkeys for the two GUIs; hotkeys in both that conflict, both in
specific details and in general approach, with the conventions of desktop
environments (e.g. using sequences of unshifted alphabet letters where
everything else on my desktop would use Ctrl or Alt; *not* accepting the
Delete key for "delete", deleting something near the mouse cursor (chosen
at random if there is more than one such thing!) instead of the thing that
is selected, etc.); the need to run a separate converter program and then
load three separate files manually, in the right order, one of them by
typing a scripting language command into a command line, just to get one
schematic into pcb; and so on. Attempting to use gschem or pcb doesn't
just have a learning curve. It requires actively unlearning the rules
that other GUI programs follow. And attempting to use either of them
after using the other requires unlearning the many points on which they
conflict.

If you want yet another separate un-integrated program to add to the
system, something to improve back-annotation from pcb to gschem seems like
an obvious gap in the current system.

Integration doesn't have to mean everything must be done by a single huge
GUI program. We can have lots of separate single-task utilities - and we
should, the success of Unix demonstrates why. But they should all be able
to really work together without requiring the user to manually compensate
for the conflicts between the different pieces of software.

The gEDA FAQ contains a fair bit of text attempting to justify why a lack
of integration is really better. With respect, it is wrong. The fact of
poor integration is easily understandable from the history of the system,
and it may not be easy or possible to solve it given volunteer resource
limitations, but it is a CATASTROPHIC PROBLEM, not a positive selling
point. And the fact that this is a frequently-asked question suggests a
significant number of users are looking for integration and being turned
away because gEDA doesn't have it.

[DJ Delorie]

the need to run a separate converter program and then load three
separate files manually, in the right order, one of them by typing a
scripting language command into a command line, just to get one
schematic into pcb;

PCB has a File->Import that does all this in one step.

[gedau-1XeMD6fE9sqV9CSZFf/]

Post by mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/
is selected, etc.); the need to run a separate converter program and then
load three separate files manually, in the right order, one of them by
typing a scripting language command into a command line, just to get one
schematic into pcb; and so on. Attempting to use gschem or pcb doesn't

This has been addressed (and I dare to say solved) already, multiple
ways:

- there is a program xgsch2pcb that provides a gui for "automating" this;
this software acts as a suite manager to coordinate editing the same
design in gschem and pcb without doing any of the things you listed above

- "recent" versions of pcb support direct import of schematics from the
menu - single click, fully integrated into the GUI, no need to do any of
the manual steps. I used quote around recent because this feature has been
around for years.

HTH,

Tibor

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

That's great. I wish it were mentioned in documents like this one:
http://wiki.geda-project.org/geda:gsch2pcb_tutorial

That is the second thing (after the "you shouldn't really want
integration" FAQ) recommended for new users to read on the
geda-project.org home page.

Is there also an easy undocumented way to make the GUIs follow standard
user interface conventions?

[DJ Delorie]

Are you volunteering to make the changes? If so, I can give you
access to those documents.

[mskala-iYp5QZLjffFsCj9YYT8S7fd9D2ou9A/]

Post by DJ Delorie
Are you volunteering to make the changes? If so, I can give you
access to those documents.

No.

[Abhijit Kshirsagar]

In my lab we're using git to track schematics, netlists and PCBs.
So far things are going well, although there are only 2-3
collaborators at most per project.
+1 for external VCS.
Diffs of gschem sch files are not very easy to read, but if (as John
Griessen suggests) the schematic is sorted it would be better.
Same for netlists.
However, IMO if the commits are well commented the diffs are easy
enough to understand. For schematics, schdiff is good* 99% of the
time. The only place it fails is a messy merge or rebase.
Abhijit

(* I did a little patching to improve schdiff - its on an older thread
on geda-user)