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
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
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
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
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
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
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:
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,
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:
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
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
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
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
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
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
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
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
17 matches
Mail list logo
