Re: gEDA-user: symbol databases, was Re: Wish list, sort of
Mike Crowe wrote: I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. The function of schematic viewed with latest data can be had with a files-as-database system too, just by using a different project definition file, or ini files, however you call it. Could database driven apps get their data from gschem running this way? That might have to be done with another full project dir, but that can be had easily with a git branch. The work flow I am imagining is: Werner's files-as-database system used to create a version, git create a branch later for analyzing new parts used, update project file to use newest libraries, connect database apps to that project dir somehow, (probably with Peter Brett's libgeda database-connector. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
Hi John, On Dienstag, 6. Januar 2009, John Doty wrote: On Jan 6, 2009, at 1:36 PM, Kai-Martin Knaak wrote: Yes! If you keep your project's symbols together in a project symbol directory, this is very easy. Each symbol file encodes a relation, including graphics, and is conveniently editable in gschem. The files are also easy to process with classic text tools. That's your database. I've added a per project symbol library to the todo list of gEDA 1.8: http://geda.seul.org/wiki/geda:todos#stable1 But there seems to be a mental block here. We keep trying to make the library symbols more usable, and don't get that that's a road a billion files long. The library symbols are templates only: a facility to automatically copy a selected symbol to the project symbol directory is needed. Not sure. I prefer having complete symbols for all larger parts and only symbol templates for small parts (resistors, ...). But no matter how the data source (symbol library) provides the symbols I think It would be good to have a local storage for every project (or schematic). Do that, and the user is defended from library changes, This would also help to maintain the symbol library, as you don't have to take care of every user of the library. If there's a bad symbol in the library you can change or delete it. Regards Werner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Wednesday 07 January 2009 18:44:04 Werner Hoch wrote: Hi John, On Dienstag, 6. Januar 2009, John Doty wrote: On Jan 6, 2009, at 1:36 PM, Kai-Martin Knaak wrote: Yes! If you keep your project's symbols together in a project symbol directory, this is very easy. Each symbol file encodes a relation, including graphics, and is conveniently editable in gschem. The files are also easy to process with classic text tools. That's your database. I've added a per project symbol library to the todo list of gEDA 1.8: http://geda.seul.org/wiki/geda:todos#stable1 I can probably put together a Guile script which will implement this, using the current framework. Peter -- Peter Brett Electronic Systems Engineer Integral Informatics Ltd signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Dienstag, 30. Dezember 2008, Peter TB Brett wrote: On Wednesday 07 January 2009 18:44:04 Werner Hoch wrote: I've added a per project symbol library to the todo list of gEDA 1.8: http://geda.seul.org/wiki/geda:todos#stable1 I can probably put together a Guile script which will implement this, using the current framework. That would be cool. But we should carefully think about everything that has to do with this topic. * library reload (update the schematic with parts from the global lib) * symbol name collisions * checksums for the local symbols? * ... Regards Werner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 5, 2009, at 5:32 PM, Mike Crowe wrote: I don't know if putting gschem netlist data or the graphics data into a database helps with much, as relationalism there doesn't seem to be of much benefit. Relationalism may not be of much benefit, but easy, centralized, network-based management of that data certainly is. I regularly edit schematics from 3-4 different computers, and I currently use rsync to keep my symbols up-to-date across them. I'd much rather use a central network-based repository. Since I already have a large database server here that manages everything from internal web content to email aliases, I'd like to just stick it in there. I'd love to be able to give gschem a list of sorta-URLs, each looking something like this: mysql://mysqlserver.neurotica.com/dbname/tablename ...and have the symbols stored there automagically added to the list of available symbols. Anyone with a database server (I suspect I'm not the only one here) could have local repositories, someone could even run a large central one for all of us (I'd volunteer to do that), etc etc. That's something I could probably whip up in a few hours, except for the configuration side of it. (I've not looked at that part of gschem) The same sort of functionality would be very useful for footprints in PCB. What I'm envisioning is simply something that would augment the getting it all from /usr/local/geda/share/gEDA/sym/... setup. Which, of course, works extremely well, but a centralizable mechanism would be really nice. This is, of course, something that could also be easily accomplished using NFS outside of gschem, or HTTP, even XML-RPC...or pretty much any other protocol. But database servers, MySQL servers in particular, are pretty ubiquitous, and the API is easy. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Tue, 2009-01-06 at 07:26 -0500, Dave McGuire wrote: On Jan 5, 2009, at 5:32 PM, Mike Crowe wrote: I don't know if putting gschem netlist data or the graphics data into a database helps with much, as relationalism there doesn't seem to be of much benefit. Relationalism may not be of much benefit, but easy, centralized, network-based management of that data certainly is. I regularly edit schematics from 3-4 different computers, and I currently use rsync to keep my symbols up-to-date across them. I'd much rather use a central network-based repository. I've thought about this, too, and my current solution which I'm quite happy with is to use the 'git' distributed revision control system. My tree of library parts is one repo, each design I work on is a repo, and I have a central server I 'git push' updates to that as a result could be thought of as my master copy. Tagging the parts database at the same time I tag a design database to indicate a particular release / version is handy, too, because it simplifies the process of getting back to a known state if I ever need to later. I can even envision potential use of branching to try out part tweaks before making a long term commitment to the change, but I haven't actually needed that yet. Bdale ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Tue, 06 Jan 2009 07:26:08 -0500, Dave McGuire wrote: But database servers, MySQL servers in particular, are pretty ubiquitous, and the API is easy. No doubt, a data base can be fine and powerful. However, many tasks have to be implemented by the application. From the top of my head: searching, editing, versioning, back-up, character encoding, permissions, import/export, updates, ... Failure to do these tasks properly would cripple the user experience. A directory based approach can refer the user to the general tools of the OS. No need to spend valuable developer resources on this kind of infrastructure. ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 1:36 PM, Kai-Martin Knaak wrote: No doubt, a data base can be fine and powerful. However, many tasks have to be implemented by the application. From the top of my head: searching, editing, versioning, back-up, character encoding, permissions, import/export, updates, ... Failure to do these tasks properly would cripple the user experience. A directory based approach can refer the user to the general tools of the OS. No need to spend valuable developer resources on this kind of infrastructure. Yes! If you keep your project's symbols together in a project symbol directory, this is very easy. Each symbol file encodes a relation, including graphics, and is conveniently editable in gschem. The files are also easy to process with classic text tools. That's your database. But there seems to be a mental block here. We keep trying to make the library symbols more usable, and don't get that that's a road a billion files long. The library symbols are templates only: a facility to automatically copy a selected symbol to the project symbol directory is needed. Do that, and the user is defended from library changes, Hs works right (you can edit the symbol), and you can minimize promotion of attributes (most belong in the database, not the schematic) and editing of promoted attributes (just change the symbol, not every instance). Better leverage. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 3:36 PM, Kai-Martin Knaak wrote: But database servers, MySQL servers in particular, are pretty ubiquitous, and the API is easy. No doubt, a data base can be fine and powerful. However, many tasks have to be implemented by the application. From the top of my head: searching, editing, versioning, back-up, character encoding, permissions, import/export, updates, ... Failure to do these tasks properly would cripple the user experience. A directory based approach can refer the user to the general tools of the OS. No need to spend valuable developer resources on this kind of infrastructure. Eh. My opinion differs. :) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Tue, 2009-01-06 at 20:36 +, Kai-Martin Knaak wrote: On Tue, 06 Jan 2009 07:26:08 -0500, Dave McGuire wrote: But database servers, MySQL servers in particular, are pretty ubiquitous, and the API is easy. No doubt, a data base can be fine and powerful. However, many tasks have to be implemented by the application. From the top of my head: searching, editing, versioning, back-up, character encoding, permissions, import/export, updates, ... Failure to do these tasks properly would cripple the user experience. A directory based approach can refer the user to the general tools of the OS. No need to spend valuable developer resources on this kind of infrastructure. I agree that adding a database adds end user complexity that should probably be avoided. I also agree that there are limited developer resources available, but a new optional interface, largely worked on by new developers would address these concerns. I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. Our company uses an internal part number. In the parts database, there is: an inventory table providing part number - location, quantity keying bill of material table providing build number - part number keying component table providing part number keying - general attribute information vendor table providing vendor - part nubmer keying. From these tables we generate Build shortages Bills of materials Purchase requests At this point, I use gschem to create a crappy bill of material which I import into the database. The schematic becomes depricated over time because the attribute info in it does not update as the database is updated. My personal desire is to allow some way of maintaining the attributes through the database, while leaving the graphics and netlist alone as after a board is designed those aspects become pretty much static. If I can do this with gschem then the schematic remains a viable tool. By the way, I also use external version control to maintain schematics (subversion). Works well. They way the development environment is shaking out it appears that adding the back-end tools to do these things is pretty straight forward. (Thanks for the links Werner) ---(kaimartin)--- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 2:55 PM, Mike Crowe wrote: I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. That's part of what using a project symbol directory, instead of library symbol instances, achieves. The only difference between this and some other kind of database is the form of the capsule around the information. A symbol file is a perfectly reasonable capsule. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 6:26 PM, John Doty wrote: I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. That's part of what using a project symbol directory, instead of library symbol instances, achieves. The only difference between this and some other kind of database is the form of the capsule around the information. A symbol file is a perfectly reasonable capsule. Well, and network availability. (assuming no NFS) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 4:59 PM, Dave McGuire wrote: On Jan 6, 2009, at 6:26 PM, John Doty wrote: I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. That's part of what using a project symbol directory, instead of library symbol instances, achieves. The only difference between this and some other kind of database is the form of the capsule around the information. A symbol file is a perfectly reasonable capsule. Well, and network availability. (assuming no NFS) I'm not clear on what your point is. In my flows, the source files from which the entire design can be regenerated go into CVS. Releases are tagged just as in a software flow, so I can readily look up the history of the versions that made it to hardware. And generally it is a software flow, too, since software is often part of the project. If the network isn't available, I can't access the archive, but I can still access whatever the current design on my laptop is, which is generally good enough except at the time of a release. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 5:26 PM, Dave McGuire wrote: On Jan 6, 2009, at 7:22 PM, John Doty wrote: I have used some of the comercial schematic packages that allow integration of attribute information into a database. It provides significant improvements for tasks such as; generating purchasing requests, inventory management, and bill of materials management, and component obsolescence. When viewing the attributes on the schematic, one is looking at the latest component information. That's part of what using a project symbol directory, instead of library symbol instances, achieves. The only difference between this and some other kind of database is the form of the capsule around the information. A symbol file is a perfectly reasonable capsule. Well, and network availability. (assuming no NFS) I'm not clear on what your point is. In my flows, the source files from which the entire design can be regenerated go into CVS. Releases are tagged just as in a software flow, so I can readily look up the history of the versions that made it to hardware. And generally it is a software flow, too, since software is often part of the project. If the network isn't available, I can't access the archive, but I can still access whatever the current design on my laptop is, which is generally good enough except at the time of a release. A perfectly good approach, of course. I'm in a situation, though, in which the network is *never* unavailable, for other reasons, and I am a big fan of centralized storage and decentralized processing. That is the standpoint from which I speak. I'm still not clear what you're asserting here. The project symbol directory approach works fine in a centralized storage and decentralized processing environment. Been there, done that, with Viewlogic instead of gEDA, but the issues are the same. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 9:39 PM, John Doty wrote: I'm not clear on what your point is. In my flows, the source files from which the entire design can be regenerated go into CVS. Releases are tagged just as in a software flow, so I can readily look up the history of the versions that made it to hardware. And generally it is a software flow, too, since software is often part of the project. If the network isn't available, I can't access the archive, but I can still access whatever the current design on my laptop is, which is generally good enough except at the time of a release. A perfectly good approach, of course. I'm in a situation, though, in which the network is *never* unavailable, for other reasons, and I am a big fan of centralized storage and decentralized processing. That is the standpoint from which I speak. I'm still not clear what you're asserting here. The project symbol directory approach works fine in a centralized storage and decentralized processing environment. Been there, done that, with Viewlogic instead of gEDA, but the issues are the same. Centralized on the *network*, not on a single system. I edit schematics on many different systems, depending on where I'm working. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 7:55 PM, Dave McGuire wrote: On Jan 6, 2009, at 9:39 PM, John Doty wrote: I'm not clear on what your point is. In my flows, the source files from which the entire design can be regenerated go into CVS. Releases are tagged just as in a software flow, so I can readily look up the history of the versions that made it to hardware. And generally it is a software flow, too, since software is often part of the project. If the network isn't available, I can't access the archive, but I can still access whatever the current design on my laptop is, which is generally good enough except at the time of a release. A perfectly good approach, of course. I'm in a situation, though, in which the network is *never* unavailable, for other reasons, and I am a big fan of centralized storage and decentralized processing. That is the standpoint from which I speak. I'm still not clear what you're asserting here. The project symbol directory approach works fine in a centralized storage and decentralized processing environment. Been there, done that, with Viewlogic instead of gEDA, but the issues are the same. Centralized on the *network*, not on a single system. I edit schematics on many different systems, depending on where I'm working. Yes, I understand that. At the MIT Center for Space Research we had hundreds of systems networked via NFS, and that's where I used this approach with Viewlogic. It doesn't matter whether you centralize with CVS or Subversion, centralize with NFS, decentralize with git, or just develop on a single machine. The project symbol directory approach works well in *all* of these cases. So I still don't understand what you are attempting to assert. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: symbol databases, was Re: Wish list, sort of
On Jan 6, 2009, at 10:33 PM, John Doty wrote: A perfectly good approach, of course. I'm in a situation, though, in which the network is *never* unavailable, for other reasons, and I am a big fan of centralized storage and decentralized processing. That is the standpoint from which I speak. I'm still not clear what you're asserting here. The project symbol directory approach works fine in a centralized storage and decentralized processing environment. Been there, done that, with Viewlogic instead of gEDA, but the issues are the same. Centralized on the *network*, not on a single system. I edit schematics on many different systems, depending on where I'm working. Yes, I understand that. At the MIT Center for Space Research we had hundreds of systems networked via NFS, and that's where I used this approach with Viewlogic. It doesn't matter whether you centralize with CVS or Subversion, centralize with NFS, decentralize with git, or just develop on a single machine. The project symbol directory approach works well in *all* of these cases. So I still don't understand what you are attempting to assert. I'm attempting to assert that, if it were present, I'd happily use the ability to specify a list of network locations, URL-style, from which to pull symbol libraries in real-time in the symbol selection dialog. That is all. Your opinion on the usefulness or wisdom of this may vary. :-) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
