Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 6:07 PM, John Doty wrote: > > Nobody else has really thought about the magnitude of the problem. I > challenge you to make a list. You are changing the subject, yet again. This is about you, John. > I encourage people to contribute to gedasymbols. Where is your contribution? Changing the subject, yet again. I have already acknowledged your contribution. I wouldn't in a million years expect you to acknowledge mine. >> Again, you're arguing against a position that nobody is arguing for. > > Not true. Really? Exactly *who* is arguing that we should have a built-in symbol for every possible use? It's clear enough that the only person arguing that is YOU, and you're only putting it out there to argue against it. Another classic straw man. > If the database behind the GUI tool is inadequate, the GUI gets in the way. > Users will have to get used to reaching around it anyway. That will drive > away everyone who thinks it should actually work, while the few remaining > will drop back to the workable flow, and the cute GUI feature will have only > driven people away. You're making assumptions upon assumptions so that you can insult the result as unworkable. Not helpful. Perhaps my memory is limited, but the only "workable flow" that I can recall you acknowledging is your own. Everything else that all of us do is just a "cute toy" to you-- we get it. (Some of us use those "cute toys" to make a living, you know.) Here's my opinion, which I don't require anyone to share: gEDA is fundamentally a graphics suite-- for creating graphical data like schematics and circuitry --and it's actually okay for a graphics suite to have a GUI. And I would definitely *encourage* our community to be able to discuss things like this, out in the open, without all the bashing. > This problem is already present in the component selection dialog in gschem. > A *true* advance in gEDA would be to have this lead the user directly into > the necessary customization, instead of promoting the illusion that this step > isn't necessary. Sounds like there's a hint of a possibly useful idea in there. Would you consider maybe someday contributing *constructively* to the dialog? How about making suggestions about ways to do that, or steering the conversation that way, rather than just shooting down everything that comes by, whether or not you agree with it? > Ah, but it does have to be perfect. Otherwise there will be lots of whining > about what a piece of crap gEDA is. People won't be able to find their > favorite component. People will design boards, fabricate them, and be shocked > when pin numbers turn out to be wrong. Nice red herring. Whether or not the symbols are *wrong* is totally irrelevant to the existence of a database. You know perfectly well that goofs in pin numbers could happen in an otherwise ideally perfect database or without one at all, even now at gedasymbols.org. (I've been bitten by such things in other EDA systems; I know the pain.) Besides, people already complain about what a piece of crap gEDA is-- in large part because it doesn't have ways for people to find their favorite component.So...if *that* is our biggest worry, we've got *nothing* to lose. > You have no comprehension of how far "every likely use" goes. gEDA isn't just > a toy for hobbyists. Do you really feel like you're making valid argument by insulting me? You don't know my background, nor what I comprehend. The only one referring to gEDA as a toy is you, and that's not helpful either. > Sure. Contribute your symbols to gedasymbols. I encourage this. But the > delusion that this can somehow lead to a situation where a user can just pick > a component from a menu without both careful checking and customization is > damaging. Thank you for calling me delusional. That really helps move things along, doesn't it. >> Your continued abusive behavior towards n00bz and veterans alike here is a >> damaging, dead end path that leads to loss for all of us. EDA is >> irrelevant to the problem. > > Huh? EDA is what gEDA does! The ONLY problem that I've been trying to address here in the last few messages is your unnecessary and abusive behavior towards individuals on this mailing list.It's got to stop. No, EDA really hasn't got a damn thing to do with it. > I would wish you could appreciate this, and adopt the Hippocratic principle: > first, do no harm. Again, you have no idea what I do and don't like about gEDA, nor on my stance on what features do and don't belong in a particular program. You're making some pretty wild (and wrong) assumptions there. What's obvious is this: you are doing a great deal of harm to the community with these abusive messages. Perhaps you should you yourself consider adopting the Hippocratic principle with respect to the gEDA community. _
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 9:28 PM, Jared Casper wrote: > Sorry, bored tonight and want to jump in... ;) > > On Thu, May 6, 2010 at 6:07 PM, John Doty wrote: >> I encourage people to contribute to gedasymbols. Where is your contribution? >> > > If gedasymbols is good, what's wrong with a tool to allow easier > access to a gedasymbols-like-but-more-organized database? Adding unnecessary layers to software makes it harder to use, not easier. It's already easy to pull things from gedasymbols. > >> Not true. If the database behind the GUI tool is inadequate, the GUI gets in >> the way. Users will have to get used to reaching around it anyway. That will >> drive away everyone who thinks it should actually work, while the few >> remaining will drop back to the workable flow, and the cute GUI feature will >> have only driven people away. >> > > Those that would be driven away by the fact that such a database isn't > complete and perfect will almost certainly be driven away by the > current situation. But if gEDA is perfect as is and no more features > should be added, why does it matter if people are driven away? An > open source project typically wants more users to have more > contributors, but if contributions are unnecessary (or contributions > are ignored, but that's another story) then it doesn't matter if > people are driven away. I have nothing against more users or more contributors. I have much against undisciplined development, particularly the notion that "features" have intrinsic value. I have much against unfactored monoliths. I have much against narrowly targeted solutions as opposed to flexible tools. > >> Ah, but it does have to be perfect. Otherwise there will be lots of whining >> about what a piece of crap gEDA is. People won't be able to find their >> favorite component. People will design boards, fabricate them, and be >> shocked when pin numbers turn out to be wrong. >> > > http://www.jwz.org/doc/worse-is-better.html > >> Sure. Contribute your symbols to gedasymbols. I encourage this. But the >> delusion that this can somehow lead to a situation where a user can just >> pick a component from a menu without both careful checking and customization >> is damaging. >> > > Just because it is hard and tedious to use use symbols/footprints from > gedasymbols But it isn't hard or tedious. > won't discourage people who would use them blindly from > doing so. Easier access to such a database would make it easier to > find existing symbols and pull them in for customization for those > that know how to use the tool set. Just because it may make it easier > for people to shoot themselves in the foot is no reason not to have > it. It's important for a tool to avoid providing an illusion of safety. 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: Database on symbols, footprints and other (was "Re: gattrib")
> If gedasymbols is good, what's wrong with a tool to allow easier > access to a gedasymbols-like-but-more-organized database? I've stated before, I have no problem with people figuring out ways to pull gedasymbols content into geda's tools over the web. IIRC there was one such implementation already. Also, I spec'd out a CSV format for gedasymbols so that people could start storing database-like info there as well as the symbols/footprints that go with it. I've also said before that "the database" should be some global composite database, including multiple sources including gedasymbols. gEDA is a community project, why shouldn't the database be too? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
Sorry, bored tonight and want to jump in... ;) On Thu, May 6, 2010 at 6:07 PM, John Doty wrote: > I encourage people to contribute to gedasymbols. Where is your contribution? > If gedasymbols is good, what's wrong with a tool to allow easier access to a gedasymbols-like-but-more-organized database? > Not true. If the database behind the GUI tool is inadequate, the GUI gets in > the way. Users will have to get used to reaching around it anyway. That will > drive away everyone who thinks it should actually work, while the few > remaining will drop back to the workable flow, and the cute GUI feature will > have only driven people away. > Those that would be driven away by the fact that such a database isn't complete and perfect will almost certainly be driven away by the current situation. But if gEDA is perfect as is and no more features should be added, why does it matter if people are driven away? An open source project typically wants more users to have more contributors, but if contributions are unnecessary (or contributions are ignored, but that's another story) then it doesn't matter if people are driven away. > Ah, but it does have to be perfect. Otherwise there will be lots of whining > about what a piece of crap gEDA is. People won't be able to find their > favorite component. People will design boards, fabricate them, and be shocked > when pin numbers turn out to be wrong. > http://www.jwz.org/doc/worse-is-better.html > Sure. Contribute your symbols to gedasymbols. I encourage this. But the > delusion that this can somehow lead to a situation where a user can just pick > a component from a menu without both careful checking and customization is > damaging. > Just because it is hard and tedious to use use symbols/footprints from gedasymbols won't discourage people who would use them blindly from doing so. Easier access to such a database would make it easier to find existing symbols and pull them in for customization for those that know how to use the tool set. Just because it may make it easier for people to shoot themselves in the foot is no reason not to have it. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 8:52 PM, DJ Delorie wrote: > > Doh! My fault for counting my working tree, not the official tree. > Pushing symbols out is on my to-do list. Sorry. I sympathize. Lots of Open-IP symbols to go, and then I should start sifting through board-level component symbols, decide what to publish. 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: Database on symbols, footprints and other (was "Re: gattrib")
Doh! My fault for counting my working tree, not the official tree. Pushing symbols out is on my to-do list. Sorry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 8:31 PM, DJ Delorie wrote: > >> Except that you're one of its more prolific contributors. Only >> Stefan and Kai-Martin have put in more symbols. > > Er, no? Ales's entry has 89 symbols, which (IIRC) were all the > symbols contributed to geda before gedasymbols.org happened, not > symbols Ales himself manages. Well, his name is on them. ;-) > I also have far more symbols than Ales, > Hmm. Where are they? [Hikyuu:gedasymbols/www/user] jpd% find dj_delorie/ -name '*.sym' -print | wc -l 81 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: Database on symbols, footprints and other (was "Re: gattrib")
> Except that you're one of its more prolific contributors. Only > Stefan and Kai-Martin have put in more symbols. Er, no? Ales's entry has 89 symbols, which (IIRC) were all the symbols contributed to geda before gedasymbols.org happened, not symbols Ales himself manages. I also have far more symbols than Ales, and Ales's files have remained untouched for over four years now. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
DJ Delorie wrote: > >> > Again I'd be happy to clean this page up a bit. >> >> Who is admin for this page? Ales? DJ? > > Me. I failed to read the fine print on the end of the page. ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 8:16 PM, Ales Hvezda wrote: > I have absolutely nothing to do with gedasymbols. Except that you're one of its more prolific contributors. Only Stefan and Kai-Martin have put in more symbols. 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: Database on symbols, footprints and other (was "Re: gattrib")
> > Again I'd be happy to clean this page up a bit. > > Who is admin for this page? Ales? DJ? Me. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
>> Again I'd be happy to clean this page up a bit. > > Who is admin for this page? Ales? DJ? I have absolutely nothing to do with gedasymbols. -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 7:07 PM, John Doty wrote: > gEDA isn't just a toy for hobbyists. I apologize if any hobbyist reading this is offended. I have great respect for hobbyists. But I have no respect for the position that toy tools are generally suitable for hobbyists, or that there's a small subset of available parts that will cover most hobbyist needs. Indeed, the hobbyist universe I perceive is broader than the one where I work (scientific instruments for spacecraft). Hobbyists have as much need for excellent tools as professionals. 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: Database on symbols, footprints and other (was "Re: gattrib")
Britton Kerin wrote: > * Or at least put the cvs checkout incantation somewhere on the page. Yes, this should definitely be somewhere on the main page. Currently, the anonymous CVS howto is linkesd to under the heading "Contributing". How about a section "Accessing"? > Again I'd be happy to clean this page up a bit. Who is admin for this page? Ales? DJ? ---<)kaimartin(>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Thursday 06 May 2010, Dave McGuire wrote: >On May 6, 2010, at 5:30 PM, Felipe De la Puente Christen wrote: >> Sometime ago I was thinking that gEDA-users as a comunity could >> request >> a part search API-like system to the distributors. For example,Digikey >> already has a fast-search bar for firefox, so they are not far from >> what >> I mean. But the useful way would be something like the GeoCode APIs >> available on the web. So the app can build a part search request >> from a >> set of string, and generate the url to get the answers. A solution >> like >> that would allow every EDA tool to implement multiple itneresting >> functions like purchase information from multiple distributors >> based on >> BOM info, and so on. >> >> I have the feeling that this could have good reception from companies >> like digikey, mouser, arrow... > > This would be wonderful, wonderful, WONDERFUL. > > It would ROCK. > > In case I'm being unclear, I think this is a great idea. > > And I like it. > >-Dave > What he said, +100. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: How many psychiatrists does it take to change a light bulb? A: Only one, but it takes a long time, and the light bulb has to really want to change. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 5:45 PM, Windell H. Oskay wrote: > >> A community database would need trillions of symbols when the combinatoric >> possibilities are considered. Now how big is the community that's >> contributing? There are 41 contributors to gedasymbols. They have >> contributed 1392 symbols. That's a measure of the capacity of this >> community. Now, I'm not disparaging that effort, and indeed I will >> continue to contribute to it and exploit it. How about you? But I have no >> illusions that this will solve the whining about symbols, even if we could >> enlist every EE in the entire world to contribute. > > Nobody but you is claiming that we need trillions of symbols nor all the > EEs in the world. Straw man much?) Nobody else has really thought about the magnitude of the problem. I challenge you to make a list. > > Instead, please consider: If it becomes easier to produce and use useful > symbols, the number of users and the number of people likely to contribute > useful symbols could grow very, very quickly. Telling people over and over > again that they're idiots for wanting something like that will does just > the opposite. It lead to a lower rate of symbol creation. I encourage people to contribute to gedasymbols. Where is your contribution? > > > >> And that's exactly what we have. But having a set of symbols for every >> likely use is impossible. Ditto for a "database" that represents their >> attributes (it's really the same thing, just packaged differently). > > Again, you're arguing against a position that nobody is arguing for. Not true. If the database behind the GUI tool is inadequate, the GUI gets in the way. Users will have to get used to reaching around it anyway. That will drive away everyone who thinks it should actually work, while the few remaining will drop back to the workable flow, and the cute GUI feature will have only driven people away. This problem is already present in the component selection dialog in gschem. A *true* advance in gEDA would be to have this lead the user directly into the necessary customization, instead of promoting the illusion that this step isn't necessary. > > Nobody needs to build a filled database from scratch, nor does the > database structure need to be perfect on the first version. Ah, but it does have to be perfect. Otherwise there will be lots of whining about what a piece of crap gEDA is. People won't be able to find their favorite component. People will design boards, fabricate them, and be shocked when pin numbers turn out to be wrong. > Having > *capacity* to introduce symbols and attributes for every likely use-- You have no comprehension of how far "every likely use" goes. gEDA isn't just a toy for hobbyists. > for 90% of people who are using gschem and/or PCB to build circuitry--is > quite likely. > > And, it will grow the community, which will lead to increased availability > of ready-made starter symbols. It will never be perfect or 100% > inclusive, but that's hardly a reason to give up. Sure. Contribute your symbols to gedasymbols. I encourage this. But the delusion that this can somehow lead to a situation where a user can just pick a component from a menu without both careful checking and customization is damaging. > For every corner case > (plumbing, thermal simulations, VLSI, and who knows what) there's still > scripting capacity. > > >>> Your insults don't change the fact that something that adds great value >>> to >>> 90% of users without removing functionality is a net gain. >> >> But something that leads them down a dead end path is a loss. > > Your continued abusive behavior towards n00bz and veterans alike here is a > damaging, dead end path that leads to loss for all of us. EDA is > irrelevant to the problem. Huh? EDA is what gEDA does! > > >> You misrepresent my position. > > In which way? You seemed to agree with the position that a blank canvas > is better than the Mona Lisa. Have you changed your mind? It depends on what you need. The Mona Lisa is a finished piece, not a tool at all. But a supply of blank canvas is part of a toolkit that can produce a variety of paintings. > > >> I've contributed several gnetlist back ends >> to the project. And there are a couple of useful scripts in my gedasymbols >> area. But these actually work, and solve the problems I intended to solve >> with them. > > I acknowledge and appreciate your role as contributor to the project. > I even saw that you were nice to someone on the list last week. (I was so > surprised that I saved the message for future reference.) However your > contributions do not compensate for nor justify your actions on this > list. > > Perhaps you should also consider acknowledging and appreciating that > people here discussing gEDA are also trying their best to contribute to > the project. To contribute you must first appreciate gEDA's strengths. Are you saying that every bad idea somebody has sh
gEDA-user: How do I mark the connection point on a pad?
I'm not sure I'm saying that right. What I've done is generate a set of pcb edge fingers using elongated pads, however when I run pcb, the ratsnest connects to the far end of the fingers, i. e. the part that goes into the socket. That gives me no end of grief trying to route the board. I've attempted to attach an image showing the problem. Thanks, Jim. <> ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 5:39 PM, Edward Hennessy wrote: > GParts reads the scheme configuration files using an embedded Guile > interpreter. In keeping with tradition, GParts configuration files are also > in scheme. OK. I suppose you've rewritten a few libgeda functions. That's cool. I guess a stripped-down version of flatten-gafrc would suffice to locate the configuration files for you. 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: Database on symbols, footprints and other (was "Re: gattrib")
> A community database would need trillions of symbols when the combinatoric > possibilities are considered. Now how big is the community that's > contributing? There are 41 contributors to gedasymbols. They have > contributed 1392 symbols. That's a measure of the capacity of this > community. Now, I'm not disparaging that effort, and indeed I will > continue to contribute to it and exploit it. How about you? But I have no > illusions that this will solve the whining about symbols, even if we could > enlist every EE in the entire world to contribute. Nobody but you is claiming that we need trillions of symbols nor all the EEs in the world. Straw man much?) Instead, please consider: If it becomes easier to produce and use useful symbols, the number of users and the number of people likely to contribute useful symbols could grow very, very quickly. Telling people over and over again that they're idiots for wanting something like that will does just the opposite. It lead to a lower rate of symbol creation. > And that's exactly what we have. But having a set of symbols for every > likely use is impossible. Ditto for a "database" that represents their > attributes (it's really the same thing, just packaged differently). Again, you're arguing against a position that nobody is arguing for. Nobody needs to build a filled database from scratch, nor does the database structure need to be perfect on the first version. Having *capacity* to introduce symbols and attributes for every likely use-- for 90% of people who are using gschem and/or PCB to build circuitry--is quite likely. And, it will grow the community, which will lead to increased availability of ready-made starter symbols. It will never be perfect or 100% inclusive, but that's hardly a reason to give up. For every corner case (plumbing, thermal simulations, VLSI, and who knows what) there's still scripting capacity. >> Your insults don't change the fact that something that adds great value >> to >> 90% of users without removing functionality is a net gain. > > But something that leads them down a dead end path is a loss. Your continued abusive behavior towards n00bz and veterans alike here is a damaging, dead end path that leads to loss for all of us. EDA is irrelevant to the problem. > You misrepresent my position. In which way? You seemed to agree with the position that a blank canvas is better than the Mona Lisa. Have you changed your mind? > I've contributed several gnetlist back ends > to the project. And there are a couple of useful scripts in my gedasymbols > area. But these actually work, and solve the problems I intended to solve > with them. I acknowledge and appreciate your role as contributor to the project. I even saw that you were nice to someone on the list last week. (I was so surprised that I saved the message for future reference.) However your contributions do not compensate for nor justify your actions on this list. Perhaps you should also consider acknowledging and appreciating that people here discussing gEDA are also trying their best to contribute to the project. > Cute features leading to dead ends (although unfortunately very > common in modern software) are not an advance. Deciding in advance that every possible feature is a "dead end" or is just "cute" isn't helpful. Shooting them down without discussion necessarily prevents advances. I think that it's a very accurate description of your position to say that you're opposed to advances in gEDA. Can you really argue against that conclusion? I for one-- and I am not alone --have grave reservations about discussing gEDA features on this list. It's bound to be a dead-end path so long as you keep this up. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 10:48 AM, John Doty wrote: > > On May 6, 2010, at 11:38 AM, John Doty wrote: > >> On May 6, 2010, at 11:26 AM, Edward Hennessy wrote: >> >>> I didn't know of another way to implement this function. GParts is looking >>> for where gEDA is installed in order to read gEDA's configuration files. I'm >>> not aware of another mechanism to locate where gEDA is installed. >>> Suggestions >>> are welcome. >> >> http://www.seul.org/pipermail/geda-user/2009-December/022135.html >> >> If you need more, ask. I think it's all accessible to Guile scripts. > > I would also note that you probably don't want to attempt to read the > configuration files directly, as they are actually Guile programs dependent > on definitions in libgeda. You'll need something like the flatten-gafrc > script in the message above to interpret the files and yield up the data you > want. GParts reads the scheme configuration files using an embedded Guile interpreter. In keeping with tradition, GParts configuration files are also in scheme. Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 3:42 PM, Windell H. Oskay wrote: >> Too large ever to assemble. > > Right. Your suggestion is that EVERY SINGLE PERSON should build a full > separate heavy symbol library for EVERY SINGLE PROJECT, Oh, I reuse symbols from project to project. Don't you? > and yet a single > community-built database is too large of a concept to even consider. A really big project needs 100 symbols. But the majority don't need to be constructed from scratch. It's not a big deal, at least for me. Takes a lot less time to make an IC symbol with DJ's web thing than it takes to figure out which IC best fulfills the requirements. And customizing an existing symbol is even quicker. But I measure trouble with a watch, while apparently others measure it in less objective ways. A community database would need trillions of symbols when the combinatoric possibilities are considered. Now how big is the community that's contributing? There are 41 contributors to gedasymbols. They have contributed 1392 symbols. That's a measure of the capacity of this community. Now, I'm not disparaging that effort, and indeed I will continue to contribute to it and exploit it. How about you? But I have no illusions that this will solve the whining about symbols, even if we could enlist every EE in the entire world to contribute. > Rght. > > >> That shows a complete misunderstanding of the nature of the problem. > >> But don't pollute the toolkit with functions that [...] > >> You don't understand that [...] > >> Perhaps to those of us with EDA experience [...] > > > To everyone else-- including those with EDA experince --having a set of > symbols to start with and customize is a known and effective solution. And that's exactly what we have. But having a set of symbols for every likely use is impossible. Ditto for a "database" that represents their attributes (it's really the same thing, just packaged differently). > > Your insults don't change the fact that something that adds great value to > 90% of users without removing functionality is a net gain. But something that leads them down a dead end path is a loss. > But we know > you're not interested in solutions. Obviously. Because nobody but you > understands the problems. We're all too stupid to understand and believe > in your one true completely-adaptable-to-everything workflow as the > solution to everything. > > You've made it perfectly clear time and again that you're opposed to new > features just on the basis that (to paraphrase), "features are bad." > Fine-- you're absolutely welcome to your opinion. Here's my opinion: you > should recompile your gEDA programs with all of code commented out. As > the limit of features goes to zero, you can finally have your perfect EDA > suite-- perfectly scriptable and 100% flexible. The perfect toolkit. You misrepresent my position. I've contributed several gnetlist back ends to the project. And there are a couple of useful scripts in my gedasymbols area. But these actually work, and solve the problems I intended to solve with them. Cute features leading to dead ends (although unfortunately very common in modern software) are not an advance. 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: Database on symbols, footprints and other (was "Re: gattrib")
You may also be able to get manufacturers to publish their part data in their own database repository. If the system is made general purpose, it could be adopted by other (commercial and open-source) packages. At that point there would be a lot of pressure for manufacturers to play along and do the work for us. I see it being a lot like the RPM package management system, where you can sign up to a lot of different information providers and search for the parts you need. __ From: Dave McGuire To: gEDA user mailing list Sent: Thu, May 6, 2010 2:34:31 PM Subject: Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib") On May 6, 2010, at 5:30 PM, Felipe De la Puente Christen wrote: > Sometime ago I was thinking that gEDA-users as a comunity could request > a part search API-like system to the distributors. For example,Digikey > already has a fast-search bar for firefox, so they are not far from what > I mean. But the useful way would be something like the GeoCode APIs > available on the web. So the app can build a part search request from a > set of string, and generate the url to get the answers. A solution like > that would allow every EDA tool to implement multiple itneresting > functions like purchase information from multiple distributors based on > BOM info, and so on. > > I have the feeling that this could have good reception from companies > like digikey, mouser, arrow... This would be wonderful, wonderful, WONDERFUL. It would ROCK. In case I'm being unclear, I think this is a great idea. And I like it. -Dave --Dave McGuire Port Charlotte, FL ___ geda-user mailing list [1]geda-u...@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
> Too large ever to assemble. Right. Your suggestion is that EVERY SINGLE PERSON should build a full separate heavy symbol library for EVERY SINGLE PROJECT, and yet a single community-built database is too large of a concept to even consider. Rght. > That shows a complete misunderstanding of the nature of the problem. > But don't pollute the toolkit with functions that [...] > You don't understand that [...] > Perhaps to those of us with EDA experience [...] To everyone else-- including those with EDA experince --having a set of symbols to start with and customize is a known and effective solution. Your insults don't change the fact that something that adds great value to 90% of users without removing functionality is a net gain. But we know you're not interested in solutions. Obviously. Because nobody but you understands the problems. We're all too stupid to understand and believe in your one true completely-adaptable-to-everything workflow as the solution to everything. You've made it perfectly clear time and again that you're opposed to new features just on the basis that (to paraphrase), "features are bad." Fine-- you're absolutely welcome to your opinion. Here's my opinion: you should recompile your gEDA programs with all of code commented out. As the limit of features goes to zero, you can finally have your perfect EDA suite-- perfectly scriptable and 100% flexible. The perfect toolkit. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 5:30 PM, Felipe De la Puente Christen wrote: Sometime ago I was thinking that gEDA-users as a comunity could request a part search API-like system to the distributors. For example,Digikey already has a fast-search bar for firefox, so they are not far from what I mean. But the useful way would be something like the GeoCode APIs available on the web. So the app can build a part search request from a set of string, and generate the url to get the answers. A solution like that would allow every EDA tool to implement multiple itneresting functions like purchase information from multiple distributors based on BOM info, and so on. I have the feeling that this could have good reception from companies like digikey, mouser, arrow... This would be wonderful, wonderful, WONDERFUL. It would ROCK. In case I'm being unclear, I think this is a great idea. And I like it. -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: Database on symbols, footprints and other (was "Re: gattrib")
Hi On Thu, 2010-05-06 at 15:11 -0600, John Doty wrote: > On May 6, 2010, at 2:18 PM, DJ Delorie wrote: > > > > >> That's what sinks all forms of general-purpose parts database, > >> including the ever popular proposed library of heavy symbols. > > > > If you're just going to just down everyone's attempt to solve this > > problem, please stop responding to it. We want to solve this problem, > > even if you don't, so stop being so negative and let us do it. > > You keep talking about software mechanisms to use a database that will never > exist. That shows a complete misunderstanding of the nature of the problem. > Please don't pollute the tools with unusable features. > May be its better to focus on a practical and intelligent way to fill the database first, and then go to the multiple utilities that can be developed and implemented around the database. Sometime ago I was thinking that gEDA-users as a comunity could request a part search API-like system to the distributors. For example,Digikey already has a fast-search bar for firefox, so they are not far from what I mean. But the useful way would be something like the GeoCode APIs available on the web. So the app can build a part search request from a set of string, and generate the url to get the answers. A solution like that would allow every EDA tool to implement multiple itneresting functions like purchase information from multiple distributors based on BOM info, and so on. I have the feeling that this could have good reception from companies like digikey, mouser, arrow... Onse you have the part's sources, you can focus on the procedures to build the database or the relational engine to do useful things with the data... > Again, it's like the SPICE model problem. We already have a software > solution: just attach model-name=whatever to the symbol. Easy ... not. > I think this part is a bit more complicated, but would be great if the same mechanism works on it. > 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 Best Regards, Felipe. -- Felipe De la Puente Christen Mobile Phone: +56 9 93199807 MSN/GTalk : fdelapue...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 2:18 PM, DJ Delorie wrote: > >> That's what sinks all forms of general-purpose parts database, >> including the ever popular proposed library of heavy symbols. > > If you're just going to just down everyone's attempt to solve this > problem, please stop responding to it. We want to solve this problem, > even if you don't, so stop being so negative and let us do it. You keep talking about software mechanisms to use a database that will never exist. That shows a complete misunderstanding of the nature of the problem. Please don't pollute the tools with unusable features. Again, it's like the SPICE model problem. We already have a software solution: just attach model-name=whatever to the symbol. Easy ... not. 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: Database on symbols, footprints and other (was "Re: gattrib")
Right, but for resistors for example, there are existing resistor symbols that will suffice for most people (once they've added their particular attributes). For ICs with uncommon pinouts, the symbol has to be created from scratch. If the database is the canonical source of part information to be fed into the design process, then the symbol should be generated from the info in the database. There shouldn't be anything controversial about pinout data -- it could easily be shared with others. The divergence in work flows starts in the conversion of pinout data to symbols; some people want hidden power pins, or parts split into several symbols, or different types of attributes, etc. This is where scripts can generate symbols to individual users' needs, or at least check that existing symbols match the known data for that part. Obviously every part has a huge number of parameters to totally specify it, and there may not be a lot of overlap between different users' part databases, but I think a database could be useful even for isolated users not sharing their data. If you do find someone else's part entry useful, you'll certainly have to add additional information to meet the requirements of your own process. Keeping the database concentrated on "just the facts" about the part should expand the usability to a very wide range of users (more than just gEDA users), which hopefully would improve the chances of finding existing entries that are useful. If we maintain a 1:1 correspondence of part number to actual physical part -- so there is only one type of package for each database entry for example -- and enter only the type of information that comes from spec sheets or suppliers (rather than, say, assigning a footprint or graphic symbol) then I think any given database entry should be generally usable for anyone interested in that part. For things like footprints or graphic symbols, those properties should be entered into the database only if they specify the tool that they're intended to work with, and if they allow for several different suggestions for that property. So for example you could have properties: gschem-suggested-symbol-1 gschem-suggested-symbol-2 pcb-suggested-footprint-1 gnucap-suggested-model-1 suggested-vendor-1 The task of actually selecting a footprint, symbol or model would be up to the individual later in their process; the suggestions would just be available to be queried if they're asked for. Also -- I think there would need to be some way of flagging errors or problems that you may find in other peoples' entries. To me, this is one big advantage of a database over files -- if someone finds an error, they could attach a note to that entry warning other potential users about the problem. *shrug* anyway, I'm not developing any of this, so these are just my thoughts on how it could work. :) mw. __ From: John Doty To: gEDA user mailing list Sent: Thu, May 6, 2010 12:49:19 PM Subject: Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib") On May 6, 2010, at 1:34 PM, Matthew Wilkins wrote: > For less-common parts, There are so many different parts on the market, and so many different kinds of applications, design flows, prejudices, etc. that *every* part is uncommon. That's what sinks all forms of general-purpose parts database, including the ever popular proposed library of heavy symbols. John Doty Noqsi Aerospace, Ltd. [1]http://www.noqsi.com/ [2]...@noqsi.com ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://www.noqsi.com/ 2. mailto:j...@noqsi.com 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 2:13 PM, DJ Delorie wrote: > >> Impractical in general. Just reproduces the heavy symbol problem >> behind yet another interface. The software is easy, assembling the >> data is impossible. > > No, it doesn't. It's a way to populate your project specific database > from a much larger field of parts, Too large ever to assemble. > or navigate through your project > specific database once it's created. It's a way to look at a large > data set and extract a smaller one from it. Show me that large data set. Concretely. Then worry about the (orders of magnitude smaller) job of using it constructively. But don't pollute the toolkit with functions that can never be practical, because the database to actually use them will never exist. Again, we already suffer from this problem. The symbol placement GUI implicitly assumes the library contains the heavy symbol you need, and guides newbies into a low productivity trap thereby. > It's a way to > synthetically create a heavy symbol database that's orders of > magnitude larger than what we'd be able to do with > one-symbol-per-partnumber heavy symbols like we (and you) use now. > > For example, look at any Digikey catalog (printed, not web). They > *don't* list all available part numbers, they provide > fill-in-the-blank part numbers for things like resistors and > capacitors. Wouldn't it be nice to have a plugin that could > synthesize all those part numbers on demand? So one resistor symbol > and a couple of rules gives you thousands of available heavy symbols, > with little overhead? There are already heavy symbol generators kicking around for this case. But consider that even with the occasional fill-in-the-blank form, the printed catalog is over 1000 pages of bifocal-challenging type. And Digikey only has a subset of what's out there. And what they have changes every day. > > Now, you can put the one symbol and the few rules in your project > specific database if you want, but I'd rather have one central > location for all my parts. However, my idea precludes neither way. > >> The package to use for a 4.7k 1/10W 5% resistor and a Digikey part # >> for it. > > That doesn't let me say "use any 4.7k resistor, and let someone else > figure out what part (or model) that is". It lets you defer that decision to as late as generally possible, just before design export to BOM and layout. > John, in your case, the > database *is* your project-specific database. YOU still have the > problem of creating those heavy symbols anyway, choosing among them, > and making design changes at varying steps along the flow. Why won't > you let us help you make your job easier? Because I don't find this credible. You don't understand that turning the code you want to write into a practical facility requires additional work beyond the code. This is a massive clerical problem, orders of magnitude larger than writing the code. > > Even if we all used your ideal workflow (which we don't), we still > want to easily solve problems like "I want an LED. What colors do I > have?" without having to go groping through a directory looking at > every possible LED we have and somehow remembering what color options > were available. > >> is practical. But that kind of mapping can already be done in gschem >> to the extent it makes sense. It's when you want to make wholesale >> decisions downstream that we have no mechanism. > > So... I try to add such a mechanism, and you tell me it's the wrong > thing to do? Of course. Because the mechanism will be trivial, but collecting the data to back it up is impossible. Consider the following recent thread: On Apr 24, 2010, at 7:46 PM, al davis wrote: > On Saturday 24 April 2010, kai-martin knaak wrote: >> There should not be a need to search for specific models for >> getting started with basic circuits in the first place. The >> models don't have to be exact. But they need to be available >> right away. >> > > Ah .. there's a good idea .. "don't have to be exact" .. they > never are Not detailed, but just good enough for a > beginner. .. Now we need a volunteer to do it. > > Have things like a generic parameterizable op-amp. .. with > parameters like gain, gbp, and so on. > > Can you make a list of the ones that should be included? The respondents all had wildly different ideas of what that implied, and even with just a handful of responses, it was clear that a very large effort would be needed. I actually contributed three simple opamp models, and the next question was "how about an OP07?" There's no satisfying the users here. This is a huge problem, and the one you want to solve is much larger. 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: Database on symbols, footprints and other (was "Re: gattrib")
> That's what sinks all forms of general-purpose parts database, > including the ever popular proposed library of heavy symbols. If you're just going to just down everyone's attempt to solve this problem, please stop responding to it. We want to solve this problem, even if you don't, so stop being so negative and let us do it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
> Impractical in general. Just reproduces the heavy symbol problem > behind yet another interface. The software is easy, assembling the > data is impossible. No, it doesn't. It's a way to populate your project specific database from a much larger field of parts, or navigate through your project specific database once it's created. It's a way to look at a large data set and extract a smaller one from it. It's a way to synthetically create a heavy symbol database that's orders of magnitude larger than what we'd be able to do with one-symbol-per-partnumber heavy symbols like we (and you) use now. For example, look at any Digikey catalog (printed, not web). They *don't* list all available part numbers, they provide fill-in-the-blank part numbers for things like resistors and capacitors. Wouldn't it be nice to have a plugin that could synthesize all those part numbers on demand? So one resistor symbol and a couple of rules gives you thousands of available heavy symbols, with little overhead? Now, you can put the one symbol and the few rules in your project specific database if you want, but I'd rather have one central location for all my parts. However, my idea precludes neither way. > The package to use for a 4.7k 1/10W 5% resistor and a Digikey part # > for it. That doesn't let me say "use any 4.7k resistor, and let someone else figure out what part (or model) that is". John, in your case, the database *is* your project-specific database. YOU still have the problem of creating those heavy symbols anyway, choosing among them, and making design changes at varying steps along the flow. Why won't you let us help you make your job easier? Even if we all used your ideal workflow (which we don't), we still want to easily solve problems like "I want an LED. What colors do I have?" without having to go groping through a directory looking at every possible LED we have and somehow remembering what color options were available. > is practical. But that kind of mapping can already be done in gschem > to the extent it makes sense. It's when you want to make wholesale > decisions downstream that we have no mechanism. So... I try to add such a mechanism, and you tell me it's the wrong thing to do? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 1:34 PM, Matthew Wilkins wrote: > For less-common parts, There are so many different parts on the market, and so many different kinds of applications, design flows, prejudices, etc. that *every* part is uncommon. That's what sinks all forms of general-purpose parts database, including the ever popular proposed library of heavy symbols. 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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 1:02 PM, DJ Delorie wrote: > Thus, gschem could query the database for available LED colors, Impractical in general. Just reproduces the heavy symbol problem behind yet another interface. The software is easy, assembling the data is impossible. But a *project specific* database that specifies things like: The package to use for a 4.7k 1/10W 5% resistor and a Digikey part # for it. Use LT1078S8 for low_power_opamp. is practical. But that kind of mapping can already be done in gschem to the extent it makes sense. It's when you want to make wholesale decisions downstream that we have no mechanism. 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: Database on symbols, footprints and other (was "Re: gattrib")
For less-common parts, I would think the schematic symbols would be generated _from_ data in the parts database. Let's say you're interested in using a particular 80-pin IC with a pinout that doesn't resemble any other part that is in the database or the symbol library. Here's an example of a possible work flow... not everyone will want something this complicated, but various people will various parts of this flow: -enter all known data about the part into the database (pinout, package options, full part number, operating temperature range, possible suppliers and supplier part numbers, etc.) -generate a .sym file from the database to match the part's pinout -- could be done automatically with options to cover different work flows and user preferences. * make a schematic * select generic parts from the database by spec and attach them to the symbols - Generate a BOM. query database for purchasing info. - Run checks. query the database for more info about parts in BOM. Do they all meet operating temperature requirement? * run the conversion to netlists, proto-board, model (* run model and re-select parts, re-run conversion) * layout the board The point is, I think the parts database will be accessed at several points in the process, not just post-gschem and pre-layout/simulation/BOM generation. Also, there's no reason for a parts database to be tied to gEDA specifically (as it would be if it was integrated in gschem); it is a very generic function and could be useful to all EDA users. Note that in this flow, the schematic symbols stay fairly 'light' but additional info is available from the database for tasks that otherwise would require 'heavy' symbols. __ From: Armin Faltl To: gEDA user mailing list Sent: Thu, May 6, 2010 11:41:18 AM Subject: Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib") >> I think even a lot of the database stuff is possible in Guile. I've used a Guile interface layer to MySQL and PostgreSQL, it works very well. It's called Guile-DBI: >> >> [1]http://home.gna.org/guile-dbi/ >> > > Hmm. Could a parts database utility be constructed to be logically inserted ahead of the gnetlist back end (using -l or -m options)? Plug-in... > Understandig the details of slots etc. or not, this is the way I want to work: * make a schematic * select parts by spec and attach them to the symbols * run the conversion to netlists, proto-board, model (* run model and re-select parts, re-run conversion) * layout the board Is this what you mean with "ahead of the gnetlist back end" ? ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://home.gna.org/guile-dbi/ 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 12:41 PM, Armin Faltl wrote: > >>> I think even a lot of the database stuff is possible in Guile. I've used a >>> Guile interface layer to MySQL and PostgreSQL, it works very well. It's >>> called Guile-DBI: >>> >>> http://home.gna.org/guile-dbi/ >>> >> >> Hmm. Could a parts database utility be constructed to be logically inserted >> ahead of the gnetlist back end (using -l or -m options)? Plug-in... >> > Understandig the details of slots etc. or not, this is the way I want to work: Missing steps: Forget how you want to work. Focus on what you want to accomplish. Understand what the toolkit can do for you. Choose a path to your goal that utilizes the toolkit's strengths. > > * make a schematic > * select parts by spec and attach them to the symbols > * run the conversion to netlists, proto-board, model > (* run model and re-select parts, re-run conversion) Right now, it is difficult to make schematics that both support simulation and are suitable for board layout. I have some ideas for fixing this, but it won't happen soon. > * layout the board > > Is this what you mean with "ahead of the gnetlist back end" ? Right now, one easy way is to create a separate project symbol file for each spec as you draw. Then edit those files to add detail (footprints, etc.). An alternative would be to have a way to add/modify such attributes between drawing and netlisting, either by "annotating" schematics (for small projects, gattrib works), or by some preprocessing of the internal data structures in gnetlist, ahead of netlist and BOM export (we have no such thing). For some things, e.g. putting in vendor part numbers, I have a flow where I postprocess the BOM. There are lots of paths here, and "one size does *not* fit all". 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: Database on symbols, footprints and other (was "Re: gattrib")
> Hmm. Could a parts database utility be constructed to be logically > inserted ahead of the gnetlist back end (using -l or -m options)? My thoughts are that such information needs to be available at schematic capture, netlisting, *and* layout. I choose parts at all levels... > Plug-in... Hence http://www.delorie.com/pcb/component-dbs.html "How is the database stored? I'm not going to specify that - it's irrelevent. What's important is how the app interacts w ith the database. My idea is that there's a well-documented ABI for a plug-in that provides the data. That way, the user can provide whatever back-end they prefer - perl script, CSV files, SQL database, web query - whatever. Even an aggregator that merges multiple plug-ins into a single one. The ABI works something like this: * The app sends the plugin the list of attributes for which it already has values, along with those values. Some of these attributes may be project-global. * The app sends a list of attributes for which it wants a list of possible values (an empty list implies all available attributes). * The plugin sends the app a list of those attributes, each with a list of possible values for those attributes." Thus, gschem could query the database for available LED colors, gnetlist could provide default 0603 packages for most resistors, and PCB could swap out a TSSOP for a VSSOP if space required it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
I think even a lot of the database stuff is possible in Guile. I've used a Guile interface layer to MySQL and PostgreSQL, it works very well. It's called Guile-DBI: http://home.gna.org/guile-dbi/ Hmm. Could a parts database utility be constructed to be logically inserted ahead of the gnetlist back end (using -l or -m options)? Plug-in... Understandig the details of slots etc. or not, this is the way I want to work: * make a schematic * select parts by spec and attach them to the symbols * run the conversion to netlists, proto-board, model (* run model and re-select parts, re-run conversion) * layout the board Is this what you mean with "ahead of the gnetlist back end" ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 12:23 PM, Dave McGuire wrote: > I was thinking about writing a parts database interface in Guile directly in > gschem I see that as the wrong place, at least from a schematic reuse perspective. To me, package selection, part# (manufacturer and distributor), even occasionally part value selection should happen when the BOM is exported. Now what this means depends on the flow: some netlist formats don't just represent topology but include BOM info (especially footprint). And anyway, we also make the tabular BOM with gnetlist in the usual flow. So gnetlist is one good place to merge your database info into the flow. Another is some post-gschem schematic "annotation" tool. 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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 2:18 PM, John Doty wrote:
I didn't know of another way to implement this function. GParts
is looking
for where gEDA is installed in order to read gEDA's
configuration files. I'm
not aware of another mechanism to locate where gEDA is
installed. Suggestions
are welcome.
http://www.seul.org/pipermail/geda-user/2009-December/022135.html
If you need more, ask. I think it's all accessible to Guile scripts.
I think even a lot of the database stuff is possible in Guile.
I've used a Guile interface layer to MySQL and PostgreSQL, it
works very well. It's called Guile-DBI:
http://home.gna.org/guile-dbi/
Hmm. Could a parts database utility be constructed to be logically
inserted ahead of the gnetlist back end (using -l or -m options)?
Plug-in...
Hmmm...sounds possible.
I was thinking about writing a parts database interface in Guile
directly in gschem awhile back, but never found the time to make it
happen. We've talked about it at great length here. I can see
having public read-only databases that we can share ("yes I have that
part, attach to my geda database at mysql://foo.bar.com/parts-is-
parts") along with some (free) parts database hosting for those of us
here who don't have or don't want to install a database server. I
have a big (dozens of GB) production database server here that I
could carve out space on for that.
-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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 12:10 PM, Dave McGuire wrote: > On May 6, 2010, at 1:38 PM, John Doty wrote: >>> I didn't know of another way to implement this function. GParts is looking >>> for where gEDA is installed in order to read gEDA's configuration files. I'm >>> not aware of another mechanism to locate where gEDA is installed. >>> Suggestions >>> are welcome. >> >> http://www.seul.org/pipermail/geda-user/2009-December/022135.html >> >> If you need more, ask. I think it's all accessible to Guile scripts. > > I think even a lot of the database stuff is possible in Guile. I've used a > Guile interface layer to MySQL and PostgreSQL, it works very well. It's > called Guile-DBI: > > http://home.gna.org/guile-dbi/ Hmm. Could a parts database utility be constructed to be logically inserted ahead of the gnetlist back end (using -l or -m options)? Plug-in... 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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 1:38 PM, John Doty wrote: I didn't know of another way to implement this function. GParts is looking for where gEDA is installed in order to read gEDA's configuration files. I'm not aware of another mechanism to locate where gEDA is installed. Suggestions are welcome. http://www.seul.org/pipermail/geda-user/2009-December/022135.html If you need more, ask. I think it's all accessible to Guile scripts. I think even a lot of the database stuff is possible in Guile. I've used a Guile interface layer to MySQL and PostgreSQL, it works very well. It's called Guile-DBI: http://home.gna.org/guile-dbi/ -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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 11:38 AM, John Doty wrote: > On May 6, 2010, at 11:26 AM, Edward Hennessy wrote: > >> I didn't know of another way to implement this function. GParts is looking >> for where gEDA is installed in order to read gEDA's configuration files. I'm >> not aware of another mechanism to locate where gEDA is installed. Suggestions >> are welcome. > > http://www.seul.org/pipermail/geda-user/2009-December/022135.html > > If you need more, ask. I think it's all accessible to Guile scripts. I would also note that you probably don't want to attempt to read the configuration files directly, as they are actually Guile programs dependent on definitions in libgeda. You'll need something like the flatten-gafrc script in the message above to interpret the files and yield up the data you want. 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: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 6:17 AM, Armin Faltl wrote:
> Thanks for all the hints on working with the current tools.
>
> Still my current concern is how I get gparts working with PostgreSQL and I
> found
> these BUGS:
> *) configure doesn't react in a sensible way to a missing MySQL installation.
> It records "no" version and then make happily tries to compile the
> mysql-backend.
>
> *) If more than one backend is supported, the system must decide somewhere,
> which database to use. Therefore I had a look into gparts-database.h and line
> 34 is
>
> typedef struct _GPartsDatabase GPartsDatabase;
>
> but there is no "struct _GPartsDatabase" in the entire source code. - does
> this compile?
> I think at least when the compiler tries to resolve a function call
> containing "GPartsDatabase"
> the bomb should blow up.
>
> Is there a special support for databases in glib/GDK/GTK?
> If not, why (the fucking bloody hell) is 'database' (declared in
> gparts-login-ctrl.c#416)
> initialized with g_object_new() - remember, it's a pointer to a structure,
> that's type is not defined?
So polite.
>
> Tbh, the code is difficult to comprehend for me, since it's "ravioli code"
> and/or "objectfuscated C"
> and has near 0 comments and no paper describing the overall internal design.
>
>
> Some comments on the why DB at all follow:
>
>> But you don't have to struggle so much if your project symbols are
>> organized. The mistake to avoid is using the library symbols directly.
>>
> If it's a mistake to use it, the problem is with the library...
It's not a mistake to use it, it's a mistake to use it in an inefficient way
("directly" by reference to the symbols, although unfortunately that's how the
GUI encourages you to work).
>
* Unless there are excellent import/export functions, a data base is an
additional obstacle to collaboration. These functions need to be written
and maintained-
>>> Inventing yet another cryptic file spec to describe the relations is even
>>> more obstructive.
>>>
>>
>> By this reasoning, gparts should work with the project symbol files. We are
>> already using this file spec, and it has already proven its value,
>> comprehensibility, and flexibility over and over.
>>
>> The problem here is that few seem to recognize that it is perfectly sensible
>> to see a .sym file as a container for a relation.
>>
> John, while I value you knowledge, rest assured, I understand the attributes
> to describe a relation.
> .sym files as of now (and hopefully never) don't have the relations I want
What you want seems to have little to do with what gEDA can give you. You seem
to be focused on some private notion of how you want to travel. Give up that
notion, learn to use the toolkit instead of fighting it, and you'll find it can
get you to useful destinations quickly and efficiently.
> (because the symbol
> is the wrong place to store this).
Depends on the information and the flow. For one of my projects I do some
trivial postprocessing of the BOM with an AWK script to get part numbers from
specs using a simple TSV "database". But the complexities of a general-purpose
DBMS need not be imported into the relatively simple problems we have.
>
>> Except that we already have much more than you recognize.
>>
> C let you shoot in your knee - with C++ you can even reuse the bullet. In a
> way your
> sacred files have the same property - a database has mechanism, that prevent
> at least inconsitencies - do you recognize this?
Note that what's "inconsistent" depends on the objective. DJ, for example,
likes to use the slotting mechanism as a general-purpose pin number remapping
mechanism. But to some it's "inconsistent" to have slot=6 on a 4 slot part.
Part of the power of gEDA is that it *doesn't* enforce such things on the user.
>
>> Why not express that mapping as a set of .sym files?
>>
> Because enumeration of the values of one attribute with otherwise redundant
> structures
> is exactly what I want to avoid. There is nothing that tells the engine that
> symbol
> foo-hu.sym is in any way related to foo-ha.sym - they by chance have some
> common
> properties. This is not a relation.
No, but it does relate the graphics to the attributes. And since the attribute
mechanism has no limits, it can express such higher level relations.
>
>>> Independent of this post of Kai-Martin I've thought about how to express
>>> the relations
>>> in the files we have now. Heavy symbols are restrictive and don't really do
>>> the trick.
>>> E.g. just now, I'm in the situation to work from a breed board towards a
>>> series-board
>>> and in this process may replace throughhole resistors with SMD.
>>>
>>
>> I will guess you let the defaults in gEDA take you down the usual
>> low-productivity path:
>>
>> 1. You used a library resistor symbol by reference rather than making a
>> project copy.
>>
>> 2. Then, of necessity, you attached footprint= att
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 11:26 AM, Edward Hennessy wrote: > I didn't know of another way to implement this function. GParts is looking > for where gEDA is installed in order to read gEDA's configuration files. I'm > not aware of another mechanism to locate where gEDA is installed. Suggestions > are welcome. http://www.seul.org/pipermail/geda-user/2009-December/022135.html If you need more, ask. I think it's all accessible to Guile scripts. 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: Database on symbols, footprints and other (was "Re: gattrib")
On Apr 29, 2010, at 12:28 PM, Armin Faltl wrote:
> Hi,
>
> I read some of the SQL files yesterday and just started an attempt to build
> gparts.
> The INSTAL file list requirements for building with MySQL and PostgreSQL.
> The later are present on my machine and I'm used to that DB.
>
> Then it's stated, that PostgreSQL is not supported yet. What is missing?
The database abstraction layer module (written in C) is not implemented.
Also, this program is under development. It currently does not have the
minimum functionality to be useful.
> I have no trouble fixing the master sql-script to use the PostgreSQL
> syntax
> > \i foo.sql
> instead of MySQL's
> > source foo.sql
> More trouble seems to be the use of
> > CALL AddPart('blah', 'blie', 'blu');
> that looks like a stored procedure to me. Tbh, I never used stored procedures
> so far.
> Is this portable? and if not, what is the advantage to
> > INSERT INTO part (he, hi, ho) VALUES ('blah', 'blie', 'blu');
> which is portable?
>
> What has to be done, to convice the C code to use PostgreSQL instead of MySQL?
> (I know from Perl, that it is a nobrainer, to switch between PostgreSQL and
> Oracle
> as long as one doesn't use non-standard constructs)
>
> And what does one need to do with the autoconf/automake combo, so the compiler
> will see something like "-DUSED_DB=PostgreSQL" (didn't use that either)?
The program is currently hardcoded to dynamically load a module for MySQL
support. Eventually, the configuration file gparts-systemrc will allow the
user to dynamically load support for other databases.
> Btw., the INSTALL misses instructions on how to run these and the typical
> ./configure; make; make check; make install; thing.
> As I don't know how to create it, I can't run configure --help...
Cheers,
Ed
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Apr 29, 2010, at 1:01 PM, Armin Faltl wrote: > Another strange thing with gparts: > > in 'sql/mysql/create-basic.sql' one finds: > cut > ... > CREATE TABLE Symbol ( > > SymbolIDINTEGER UNSIGNED NOT NULL AUTO_INCREMENT, > SymbolPath VARCHAR(500) NOT NULL, > DeviceIDINTEGER UNSIGNED NOT NULL, > > PRIMARY KEY ( SymbolID ), > FOREIGN KEY ( DeviceID ) REFERENCES Device, > UNIQUE ( SymbolPath ) > ); > > > -- Create a table for symbol details (comments). > -- > -- Each symbol may have many comments. > -- > CREATE TABLE SymbolDetail ( > > SymbolID INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, > DetailVARCHAR(500) NOT NULL, > > FOREIGN KEY ( SymbolID ) REFERENCES Symbol, > UNIQUE ( SymbolID, Detail ) > ); > ... > cut - > > what is the purpose of auto-increment on a foreign key? > Auto-increment would probably be the default behavior, but as it > will break the foreign key constraint this, same as not assigning > anything will prevent creation of that row. Actually it is worse > (at least with PostgreSQL): the autoincrement counter falls > behind, if the default behavior is not used. > It can be assumed, that the SymbolID's from "Symbol" will form a gapless > sequence. > If for some reason, the SymbolID gets missed during creation of a > SymbolDetail, the AUTO_INCREMENT will produce an integer > that is probably low, because this is a bug. And this will happily > attach the detail to a random symbol, instead of raising an exception. > > Wrong? > > Armin The AUTO_INCREMENT should not be there, but no problem occurs because of it. I'll remove it in a subsequent patch. Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 1, 2010, at 3:12 PM, Felipe De la Puente Christen wrote: > Hi, > Just to let you (Developers of gparts) know that I have compiled the > git version of gparts, and when I run the program it segfaults searching > for parts data. Thanks for the report. > > fel...@monster:/usr/local/src/gEDA/gparts$ gparts --help > ** (gparts:10512): DEBUG: Checking path /etc/xdg/xdg-gnome/gEDA > ** (gparts:10512): DEBUG: Checking path /etc/xdg/gEDA > ** (gparts:10512): DEBUG: Checking path /usr/share/gnome/gEDA > ** (gparts:10512): DEBUG: Checking path /usr/local/share/gEDA > ** (gparts:10512): DEBUG: Checking path /usr/share/gEDA > ** (gparts:10512): DEBUG: gEDA configdir found (null) > ** (gparts:10512): DEBUG: Checking path /usr/share/gnome/gEDA > ** (gparts:10512): DEBUG: Checking path /usr/local/share/gEDA > ** (gparts:10512): DEBUG: Checking path /usr/share/gEDA > ** (gparts:10512): DEBUG: gEDA datadir found (null) > Segmentation fault > > > Seems to me that the program doesn't use the config.h header or > whatever method to realize the real PREFIX under it's already > installed(or if installed at all). Since my prefix is definitely > different than /usr/ or /usr/local. May be a NULL check is appropriate > as a workaround. I didn't know of another way to implement this function. GParts is looking for where gEDA is installed in order to read gEDA's configuration files. I'm not aware of another mechanism to locate where gEDA is installed. Suggestions are welcome. I'll fix the segfault. Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On May 6, 2010, at 5:17 AM, Armin Faltl wrote: > Thanks for all the hints on working with the current tools. > > Still my current concern is how I get gparts working with PostgreSQL and I > found > these BUGS: > *) configure doesn't react in a sensible way to a missing MySQL installation. > It records "no" version and then make happily tries to compile the > mysql-backend. Currently, MySQL is the only supported database. The makefiles do not support conditional compilation of backends yet. > *) If more than one backend is supported, the system must decide somewhere, > which database to use. Therefore I had a look into gparts-database.h and line > 34 is It is in gparts-login-ctrl.c on line 425. Currently, database support modules are loaded in gparts-login-ctrl.c in the function gparts_login_ctrl_instance_init(). > typedef struct _GPartsDatabase GPartsDatabase; > > but there is no "struct _GPartsDatabase" in the entire source code. - does > this compile? > I think at least when the compiler tries to resolve a function call > containing "GPartsDatabase" > the bomb should blow up. GPartsDatabase is an interface in the GObject framework, so it is never instantiated. Both GPartsMySQLDatabase and GPartsPostgreSQLDatabase implement the interface. However, PostgreSQL support has not been implemented. These classes and interface make up the database abstraction layer. Other implementations could be created later, like SQLite, which has been requested. > Is there a special support for databases in glib/GDK/GTK? > If not, why (the fucking bloody hell) is 'database' (declared in > gparts-login-ctrl.c#416) > initialized with g_object_new() - remember, it's a pointer to a structure, > that's type is not defined? The call to g_object_new() would create GPartsMySQLDatabase (or GPartsPostgreSQLDatabase, but it is not implemented yet.) Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
Thanks for all the hints on working with the current tools. Still my current concern is how I get gparts working with PostgreSQL and I found these BUGS: *) configure doesn't react in a sensible way to a missing MySQL installation. It records "no" version and then make happily tries to compile the mysql-backend. *) If more than one backend is supported, the system must decide somewhere, which database to use. Therefore I had a look into gparts-database.h and line 34 is typedef struct _GPartsDatabase GPartsDatabase; but there is no "struct _GPartsDatabase" in the entire source code. - does this compile? I think at least when the compiler tries to resolve a function call containing "GPartsDatabase" the bomb should blow up. Is there a special support for databases in glib/GDK/GTK? If not, why (the fucking bloody hell) is 'database' (declared in gparts-login-ctrl.c#416) initialized with g_object_new() - remember, it's a pointer to a structure, that's type is not defined? Tbh, the code is difficult to comprehend for me, since it's "ravioli code" and/or "objectfuscated C" and has near 0 comments and no paper describing the overall internal design. Some comments on the why DB at all follow: But you don't have to struggle so much if your project symbols are organized. The mistake to avoid is using the library symbols directly. If it's a mistake to use it, the problem is with the library... * Unless there are excellent import/export functions, a data base is an additional obstacle to collaboration. These functions need to be written and maintained- Inventing yet another cryptic file spec to describe the relations is even more obstructive. By this reasoning, gparts should work with the project symbol files. We are already using this file spec, and it has already proven its value, comprehensibility, and flexibility over and over. The problem here is that few seem to recognize that it is perfectly sensible to see a .sym file as a container for a relation. John, while I value you knowledge, rest assured, I understand the attributes to describe a relation. .sym files as of now (and hopefully never) don't have the relations I want (because the symbol is the wrong place to store this). Except that we already have much more than you recognize. C let you shoot in your knee - with C++ you can even reuse the bullet. In a way your sacred files have the same property - a database has mechanism, that prevent at least inconsitencies - do you recognize this? Why not express that mapping as a set of .sym files? Because enumeration of the values of one attribute with otherwise redundant structures is exactly what I want to avoid. There is nothing that tells the engine that symbol foo-hu.sym is in any way related to foo-ha.sym - they by chance have some common properties. This is not a relation. Independent of this post of Kai-Martin I've thought about how to express the relations in the files we have now. Heavy symbols are restrictive and don't really do the trick. E.g. just now, I'm in the situation to work from a breed board towards a series-board and in this process may replace throughhole resistors with SMD. I will guess you let the defaults in gEDA take you down the usual low-productivity path: 1. You used a library resistor symbol by reference rather than making a project copy. 2. Then, of necessity, you attached footprint= attributes to each instance instead of your resistor symbol instead of placing a footprint= symbol in your project symbol. Your situation is very familiar to me, and is precisely why I use the project symbol collection approach for any large gEDA project. Think this is the 1st time I see explicitly stated, that an attribute in the schematic can override the value in the symbol. Thanks (docu-writes start bashing me as well now or fix this ;-) It's clearly undesirable to replace the symbols in my schematic. Likewise it's very tedious to replace footprint attributes in the symbols and error prone as of now. And then I may not want to replace all the through-hole parts because I like the via-functionaltiy of their legs or because I can put more traces beneath one. Use attached attributes at the schematic level to override your project symbol's attributes. Or make another symbol, substitute. This is another thing that's easy, but clumsy with the existing GUI. What one needs is an abstract description of the pinout of a component. This pinout can be embodied in several packages. This I think, is what the device attribute is really for. This won't catch all cases, therefore a direct connection from symbol to part should be possible. Reading the article on transistors (http://www.geda.seul.org/wiki/geda:transistor_guide) the example of "the same transistor" being available as TO and SOT package, the concept of freezing package pins to symbol connections breaks down completely. - I never und
