Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Oct 9, 2010, at 3:25 AM, Armin Faltl wrote: > > > Edward Hennessy wrote: >> On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote: >> >>> To express the many-to-many relation between parts and symbols it uses >>> a table called "device". This is fed by the infamous device attribute >>> in the symbol libraries. There's nothing wrong in the theory of DB-design >>> with it, but the indiscriminate use of this attribute in the symbol-libs >>> waters the use of this design down to uselessness. >>> >> >> I'm investigating another mechanism to create a part 'class' with some >> existing data in the part library. Using the device attribute for this >> causes problems. I am pondering the first portion of the symbol filename. >> So, 'resistor-1.sym' is part of the 'resistor' class. Any other >> suggestions? >> > Thank you for still working on this hard topic at all. > > Do I understand you correct: you want to limit the range of symbols, that are > possible > to connect to a given part, based on a part classification? Correct. Parts and symbols have a many-to-many relationship. I'd like to have a human intelligible name assigned to the relationship. This name will be used as a key. I know this value will be a string, but where does it come from? > I don't recall all the details of the DB layout, but i fear, the only > solution is to manually > enter meaningful device values in the symbol libraries. This way would require modification of the symbol library, which I was hoping to avoid by using the first part of the filename. However, symbols need to be modified anyway, to insert macros. For example, a resistor would need to have the attribute: VALUE=$(Resistance). The part manager will substitute the $(Resistance) with the field from the database. > I'm not aware, that the device attribute is used for anything in the current > workflow, > thus the quality of the entries. It looks like it has meaning for simulation: http://www.brorson.com/gEDA/SPICE/x115.html Currently, if the part manager needs to populate this attribute, then it needs to be changed to: DEVICE=$(DeviceName), and can no longer contain a key. > If one sets out to map devices to a part classification, I'd suggest > ':'-notation like > "diode:schottky" or "transistor:power:igbt". Therefore it is questionable, to > completely preset this value in the symbol library at all - maybe just the > 1st element. > This would require a strict rule: something that does not have the same symbol > mustn't have the same top category: MOSFET != transistor or the top categories > would need to be 'transistor:mosfet' and 'transistor:bipolar' - I'm getting > confused... For transistors, an important part of the key is the polarity. The symbols for an NPN and PNP are different. Extending the convention a bit: transistor:bipolar:npn Transistors present another problem: pin configuration. Transistors may require an additional convention, like listing the pin functions in order. For example an NXP PDTC114EE would use: transistor:bipolar:npn:bec So, the base is on pin 1, the emitter is on pin 2, and the collector is on pin 3. Internally, the part manager treats this data as a string and does not interpret the data. So, changing the convention does not change the object code. However, data files would need to follow the same convention to be imported into the same part library. 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")
Edward Hennessy wrote: On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote: To express the many-to-many relation between parts and symbols it uses a table called "device". This is fed by the infamous device attribute in the symbol libraries. There's nothing wrong in the theory of DB-design with it, but the indiscriminate use of this attribute in the symbol-libs waters the use of this design down to uselessness. I'm investigating another mechanism to create a part 'class' with some existing data in the part library. Using the device attribute for this causes problems. I am pondering the first portion of the symbol filename. So, 'resistor-1.sym' is part of the 'resistor' class. Any other suggestions? Thank you for still working on this hard topic at all. Do I understand you correct: you want to limit the range of symbols, that are possible to connect to a given part, based on a part classification? I don't recall all the details of the DB layout, but i fear, the only solution is to manually enter meaningful device values in the symbol libraries. I'm not aware, that the device attribute is used for anything in the current workflow, thus the quality of the entries. If one sets out to map devices to a part classification, I'd suggest ':'-notation like "diode:schottky" or "transistor:power:igbt". Therefore it is questionable, to completely preset this value in the symbol library at all - maybe just the 1st element. This would require a strict rule: something that does not have the same symbol mustn't have the same top category: MOSFET != transistor or the top categories would need to be 'transistor:mosfet' and 'transistor:bipolar' - I'm getting confused... ___ 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")
Yikes folks, sorry for brining this old thread back to life, somehow it got pulled to the top of my gmail in a thread and i starded re reading it. and commenting.. Sorry for bringing it all back 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")
OMG! what is the core temperature of earth?? did it drop a few degrees? :-) On Tue, May 4, 2010 at 9:26 PM, Kai-Martin Knaak wrote: > On Mon, 03 May 2010 08:45:29 -0600, John Doty wrote: > >> Yep. And then if you do that, and update regularly, trivial search >> commands like: >> >> locate .sym | grep -i max921 > > Hey-ho! Finally a topic I totally agree with John D.! ;-) > > ---<)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+kmk&op=get > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > 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 Mon, May 3, 2010 at 1:41 PM, Britton Kerin wrote: > What about SQLite? I've *glanced* at its home page a couple times in > the past (really no more than that), > and in really less than 10 minute just now I was able to download it, > build it, create a database in a file, > query it, and dump its generative code (probably a good format for > grep-happy people like you :). > What I've been thinking of lately is a sort of heavy symbol wiki that > people could add to as they create their > own project parts like you do. You could build parts in chroots with a > few things (Pcb_9.pm tragesym etc.) available. I'm not sure how useful > a DB would be in an application like this but I wouldn't rule it out > just based > on bad experiences with servers databases. > Britton SQLite for the win, it is easy, simple and relitivly fast. built into Python. built into Mac OSX When needed you can switch your database code over to a heaver database. ___ 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 2:14 AM, Armin Faltl wrote: > To express the many-to-many relation between parts and symbols it uses > a table called "device". This is fed by the infamous device attribute > in the symbol libraries. There's nothing wrong in the theory of DB-design > with it, but the indiscriminate use of this attribute in the symbol-libs > waters the use of this design down to uselessness. I'm investigating another mechanism to create a part 'class' with some existing data in the part library. Using the device attribute for this causes problems. I am pondering the first portion of the symbol filename. So, 'resistor-1.sym' is part of the 'resistor' class. Any other suggestions? 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")
Part of the gedasymbols philosophy is that everything is owned by someone. The two choices are to keep Ales' name on it, or delete it. I don't want to have unowned stuff out there. ___ 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 Fri, 07 May 2010 06:35:29 -0400, Ales Hvezda wrote: > I should remove those symbols since they are completely unmaintained and > I do not want them associated with me. IMHO, they should stay available on gedasymbols. How about a virtual user Anon N. Nymous? His page may clearly state, that this is a repository of completely unmaintained, orphaned symbols? ---<)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+kmk&op=get ___ 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: 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. A very good approach IMO. The SQL "COPY" command, at least with PostgreSQL, can use CSV files as input and output. A drawback of the COPY command (not CSV) is, that constraints are turned off to speed the processing. It is however easy, to circumvent this problem: * copy into an empty database * run queries, that test the constraints * if all is ok, copy into the live system * if there is trouble, the database (test query) will tell you, where the problem in the CSV file is, at least indirectly 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? Sure. One thing I want to consider here is, that too high a complexity in the design of the database may prevent the average user from fixing input errors like injecting wrong pin-mappings. How to go about this must be well documented and relatively easy. Armin ___ 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")
John, I said a number of nice things about you and asked that you stop being mean to people. That's hardly abominable. If you'd like to keep the discussion to EDA, that pleases me greatly. -Windell ___ 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")
Windell, Your repeated personal attacks do not belong in an engineering discussion. Plainly, you are unwilling to rationally discuss EDA issues. Blaming your abominable behavior on me is ridiculous: you are responsible for your own behavior. When you are ready to join a real discussion, I will be a willing participant, but until then I will simply ignore 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")
> No, it is about polluting good engineering with sloppiness. Aye. To wit: You've been polluting what could otherwise be a good forum for engineering discussion with seriously sloppy social engineering. > As a non-contributer, you ask for changes whose consequences you do not > understand. I have not asked for ANY changes except in your behavior. Do you *really* think that there would be dire consequences for gEDA if you were to argue the exact same things except *politely*? (And, thank you for labeling me a "non-contributer" -- I'll be sure and keep my place rather than contributing. Helpful indeed.) > It's a *consequence* of your position. If you travel the road to Hell, > you'll wind up in Hell, even if you're not arguing that Hell is where you > want to go. My contention that it's reasonable *to discuss* databases necessarily leads to Hell? Wow-- your church is much more strict than mine. >> Perhaps my memory is limited, but the only "workable flow" that I can >> recall you acknowledging is your own. > > Which flow? I have a different one for each project. Again, good > engineering allows the ends to dictate the means. The genius of gEDA is > that its flexibility supports this. "Your own," i.e., whichever one you're working on. I never even implied that you had a single inflexible flow-- I said quite the opposite, in fact. > I'm sorry your thin skin has forced you to bash me. This is about EDA, not > about personality. I have a thick skin. That's why I stepped into the conversation in the first place: to call you out when you almost sequentially posted four uncalled for, almost bullying messages to other members of the list. I've done so before, and if you can't keep it civil, I *will* call you out on it again-- whether or not I agree with you about the EDA portion of the discussion. You personally directed the discussion from one about engineering to one about personality when you switched from criticizing ideas to insulting the people who made them. This conversation is the natural consequence. > Of course. Didn't I just yesterday praise Edward's work, and offer a > solution to one of his problems? Didn't I suggest plug-ins to gnetlist as > a another possible approach? But my notion of a "database" is different > from yours (and actually achievable): a project-specific mapping of > schematic symbols to physical components. You have been helpful at times; I went out of my way to acknowledge that already. But that doesn't give you license to bully people the rest of the time. (Actually, you can be mean to people all you like; you'll just get into another one of these very unproductive conversations as a consequence.) Besides gEDA, I also use a commercial (, not $) EDA system with a database where many standard parts can be pulled "off the shelf" as it were, with symbol and footprint. Yeah, I still spend a lot of time drawing and modifying footprints and so forth, but the database does save me a huge amount of time. Approaches like this are neither foolproof nor un-achievable. > No it is not. Engineering is about *consequences*. You really think that insulting community members without provocation has no consequences? That's sloppy engineering. > Engineering is about consequences. A consequence of your plan is that gEDA > becomes more toy-like, regardless of how you wish to describe it. No. My plan is that we can have civil conversations about the future of gEDA on this mailing list, regardless of how you wish to describe it. How you get from that to "toy-like" is beyond me. > Delusions are common in engineering, even for perfectly sane engineers. If > you can't have bad ideas, you won't have good ones either. That's why > designs need review. It's also why you shouldn't be so emotionally > invested in your ideas that you're personally insulted by criticism of > them. I haven't been insulted at all by your engineering arguments, nor by your criticism of any proposals about gEDA. I'm really not sure what orifice you're pulling all this out of. (You keep making strange assumptions about my position. As I've said before, I mostly agree with you on matters of engineering.) However, I *am* invested in gEDA and the health of the community, which is why I stepped into this in the first place. If you feel a need to insult someone, you can continue to do so to me rather than to the rest of the community. > That's life for a scientist. You need a thick skin. I am a scientist and I have a thick skin. Maybe you should pay attention. > No, you're selling an approach that will damage the toolkit. I ain't > buying. I guess to a salesman, that counts as an insult. I'm sorry you're > so invested in your ideas that you consider criticism of them a personal > insult. If you're going to have ideas, you'd better get used to criticism > of them. My assertion that you should stop behaving like a jerk => Damage will occur to the toolkit? Really? Come off of it already
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Fri, May 7, 2010 at 2:45 PM, Dave McGuire wrote: > On May 7, 2010, at 12:49 PM, Windell H. Oskay wrote: >>> >> I wonder how third-part component search services (like findchips.com and >> octopart) presently search the distributors. Does anyone know? There must >> be some sort of API that the distributors are providing them, at least >> privately. > > Not necessarily; they could just be "screen-scraping", parsing the returned > HTML. It can be a bitch to do, but it's pretty common. I thought it might be screen-scraping since the displayed format looks similar to the format on the distributor's site. (* jcl *) ___ 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 7, 2010, at 12:49 PM, Windell H. Oskay wrote: I think there's not much to do to implement the service. In fact the service is already there, what's lacking is a proper interface to let 3rd party software get the search results without accesing the website through a browser. It could even be there already in the case of digikey, but I'm not that familiar with these search-bar plugins, and haven't had the time to check the code(?) for info to implement the searches. Interesting. I wonder how third-part component search services (like findchips.com and octopart) presently search the distributors. Does anyone know? There must be some sort of API that the distributors are providing them, at least privately. Not necessarily; they could just be "screen-scraping", parsing the returned HTML. It can be a bitch to do, but it's pretty common. -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 9:56 PM, Windell H. Oskay wrote: > > 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. No, it is about polluting good engineering with sloppiness. > > >> I encourage people to contribute to gedasymbols. Where is your contribution? > > Changing the subject, yet again. As a non-contributer, you ask for changes whose consequences you do not understand. > > I have already acknowledged your contribution. I wouldn't in a million > years expect you to acknowledge mine. Why not? I acknowledge others' contributions. > > > > >>> 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 a *consequence* of your position. If you travel the road to Hell, you'll wind up in Hell, even if you're not arguing that Hell is where you want to go. > 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. No it is not. A basic principle of software engineering is that when you hide imperfection behind an interface, you amplify the effect of that imperfection. > > >> 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. I'm sorry that you find pointing out the chasm between your intensions and the likely consequences of them unhelpful. > > Perhaps my memory is limited, but the only "workable flow" that I can recall > you acknowledging is your own. Which flow? I have a different one for each project. Again, good engineering allows the ends to dictate the means. The genius of gEDA is that its flexibility supports this. > 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-- Graphics is the easy part of the job. The fun part. The clerical stuff is the part everybody wishes would go away (it won't). But the clerical part is also more friendly to automation *if* we can keep it in the text world where computers (especially with Unix-derived utilities) are more capable. > for creating graphical data like schematics and circuitry --and it's actually > okay for a graphics suite to have a GUI. For graphical tasks, it's essential. But the design mistake is to use cute graphics for essentially textual tasks. EDA involves both kinds of tasks, so a good toolkit will have both kinds of tools. Unfortunately, too many users have become conditioned to integrated graphical tools, where use of GUI for clerical tasks numbs the mind (because GUI *is* fun) to the time wasted. The most extreme examples of this I've seen are apparently intelligent programmers who spend huge amounts of time hunting for bugs by single-stepping through code in fancy GUI IDE's, when a few asserts and printfs would quickly isolate the problem. Another problem is that GUI *sells*, so for commercial software it has driven out textual interfaces even in the cases where they are better. Integration also sells, and tightens the grip of the producer on the consumer, so toolkits are out of fashion. Fortunately, in free software, we can resist these pressures. We should. > And I would definitely *encourage* our community to be able to discuss > things like this, out in the open, without all the bashing. I'm sorry your thin skin has forced you to bash me. This is about EDA, not about personality. > > > >> 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? Of course. Didn't I just yesterday praise Edward's work, and offer a solution to one of his problems? Didn't I suggest plug-ins to gnetlist as a another possible approach? But my notion of a "database" is different from yours (and actually achievable): a project-specific mapping of schematic symbols to physical components. > How about making suggestions about ways to do that, or steering the >
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Fri, 2010-05-07 at 09:49 -0700, Windell H. Oskay wrote: > On May 7, 2010, at 9:40 AM, Felipe De la Puente Christen wrote: > > > I think there's not much to do to implement the service. In fact the > > service is already there, what's lacking is a proper interface to let > > 3rd party software get the search results without accesing the website > > through a browser. It could even be there already in the case of > > digikey, but I'm not that familiar with these search-bar plugins, and > > haven't had the time to check the code(?) for info to implement the > > searches. > > Interesting. > > I wonder how third-part component search services (like findchips.com and > octopart) presently search the distributors. Does anyone know? There must > be some sort of API that the distributors are providing them, at least > privately. Well, now that I see the url generated by the Digikey toolbar there's not much to request so far. This is a request for keyword=AT91SAM9G45 (leadfree, rohs and instock activated) http://search.digikey.com/scripts/dksearch/dksus.dll?Keywords=at91sam9g45&site=us&lang=en&stock=1&pbfree=1&rohs=1&WT.mc_id=tbr_srch&WT.mc_ev=click It's pretty clear. Of course this is just an initial approach, and is far from a standard search pattern for every supplier, but may be would be useful to get the data parsing results from this king of searches. By the way, here's the Geolocation API I mentioned before. Of course the results are much simpler in this case since the answer is always the same. http://ipinfodb.com/ip_location_api.php 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 7, 2010, at 9:40 AM, Felipe De la Puente Christen wrote: > I think there's not much to do to implement the service. In fact the > service is already there, what's lacking is a proper interface to let > 3rd party software get the search results without accesing the website > through a browser. It could even be there already in the case of > digikey, but I'm not that familiar with these search-bar plugins, and > haven't had the time to check the code(?) for info to implement the > searches. Interesting. I wonder how third-part component search services (like findchips.com and octopart) presently search the distributors. Does anyone know? There must be some sort of API that the distributors are providing them, at least privately. Windell H. Oskay ___ 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 Fri, 2010-05-07 at 14:45 +, Kai-Martin Knaak wrote: > On Thu, 06 May 2010 17:30:01 -0400, Felipe De la Puente Christen wrote: > > > I have the feeling that this could have good reception from companies > > like digikey, mouser, arrow... > > I have a feeling, that they won't bother. They may not see a reason to > provide a special service. I think there's not much to do to implement the service. In fact the service is already there, what's lacking is a proper interface to let 3rd party software get the search results without accesing the website through a browser. It could even be there already in the case of digikey, but I'm not that familiar with these search-bar plugins, and haven't had the time to check the code(?) for info to implement the searches. > We don't represent a relevant volume of sales. It isn't about us, it is about the EDA-users community. Independently of being gEDA-users the ones requesting the thing, the benefit is for the whole EDA-users, since all other EDA developers can implement features based on the new source of information. That said, I have my doubts about the nature of the database needed(in general terms). The device/manufacturer/distributor/package/price/whatever info is already on the supplier's databases, and it's changing continuously. So for me, the "gEDA" database should try to have the minimum hard-saved data as possible, and take advantage of the info provided(which is already maintained by 3rd parties). 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")
>> I have the feeling that this could have good reception from companies >> like digikey, mouser, arrow... > > I have a feeling, that they won't bother. They may not see a reason to > provide a special service. We don't represent a relevant volume of sales. Not sure of that. We buy tens to hundreds of thousands of dollars worth of parts from DigiKey and Mouser per year. Mostly because the Big Names like Arrow, Future, Nu Horizons, et.al. won't carry stock [More to this than that simple statement but don't feel like going into the detail here.] You are correct that it should not be a special service from each, it should be standard service from all... ___ 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 Thu, 06 May 2010 17:30:01 -0400, Felipe De la Puente Christen wrote: > I have the feeling that this could have good reception from companies > like digikey, mouser, arrow... I have a feeling, that they won't bother. They may not see a reason to provide a special service. We don't represent a relevant volume of sales. ---<)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+kmk&op=get ___ 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")
[snip] >symbols Ales himself manages. I also have far more symbols than Ales, >and Ales's files have remained untouched for over four years now. > As I said, I have absolutely nothing to do with gedasymbols. I should remove those symbols since they are completely unmaintained and I do not want them associated with me. -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 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
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
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
On Mon, 03 May 2010 08:45:29 -0600, John Doty wrote: > Yep. And then if you do that, and update regularly, trivial search > commands like: > > locate .sym | grep -i max921 Hey-ho! Finally a topic I totally agree with John D.! ;-) ---<)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+kmk&op=get ___ 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")
Perhaps that's where the pain is, but customizing symbols takes little time, so endure the brief pain and get on with it. You can't avoid it. Even if you have a heavy symbol from somebody else's library, you have to check it carefully, and that's almost as much work as customizing. My heavy symbols won't fit your needs, and vice-versa. This problem exists even in the big $$ commercial EDA tools. Symbol libraries simply don't work the way you wish they would. Too many possibilities... One company I worked for had a separate symbol for every single part. It was a 1-1 between schematic symbol and physical device. This meant that you could have multiple 10k resistors, even multiple 10k 0.1W 0805 resistors if the part was sourced from a few different manufacturers and ended up recorded as such in our CML. The actual process of creating such parts was not too arduous as it was usually a case of copy a similar part and change the necessary attributes. This was using Altium as the end to end EDA. It is interesting to note that despite an expensive, highly integrated schematic capture, parts library and pcb layout software that the same issues of component/symbol replication and redundancy exist. Although despite the proliferation of symbols in this case it did actually work ok. There isn't a magic bullet that will fix these issues. By having as much as possible light symbols that are easily modified, a public repository of customised heavier symbols this provides people with options. Perhaps in the hobby market having a set of predifined heavy symbols would be attractive however this really only suits those people who for whatever reason are not inclined to thoroughly check the symbol against their component and intended application. In these cases an 0805 resistor has no variants. This however is not the case for a design that goes through many iterations or has a particularly stringent set of design rules. Symbols need to be customised. Often on a project by project basis. All that can be done is to make this process easier where possible. regards, Geoff ___ 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 3, 2010, at 4:07 PM, Britton Kerin wrote: >> If you have a reference design that you're trying to modify or > extend >> getting a working set of symbols takes most >> of the time. And reference designs are the open source way. > > You can distribute symbol files with a reference design. No problem. > Still, I'd expect to have to tweak them. > Indeed, design reuse is a strength of the project symbol approach. > Change packages, even parts selection (have symbols fast_npn.sym, > etc, choose part to fit requirements later) by changing project > symbols. Leave the schematics alone. Like changing include files in > software. > > I was thinking more of the situation where you have a published circuit > and want to capture it and build it on > a board. In this case you're probably not starting with gEDA stuff, > and the pain of building the thing on a board > is mostly the (effectively heavy) symbol creation. Perhaps that's where the pain is, but customizing symbols takes little time, so endure the brief pain and get on with it. You can't avoid it. Even if you have a heavy symbol from somebody else's library, you have to check it carefully, and that's almost as much work as customizing. My heavy symbols won't fit your needs, and vice-versa. This problem exists even in the big $$ commercial EDA tools. Symbol libraries simply don't work the way you wish they would. Too many possibilities... 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 you have a reference design that you're trying to modify or extend > getting a working set of symbols takes most > of the time. And reference designs are the open source way. You can distribute symbol files with a reference design. No problem. Still, I'd expect to have to tweak them. Indeed, design reuse is a strength of the project symbol approach. Change packages, even parts selection (have symbols fast_npn.sym, etc, choose part to fit requirements later) by changing project symbols. Leave the schematics alone. Like changing include files in software. I was thinking more of the situation where you have a published circuit and want to capture it and build it on a board. In this case you're probably not starting with gEDA stuff, and the pain of building the thing on a board is mostly the (effectively heavy) symbol creation. Britton ___ 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 3, 2010, at 10:16 AM, Britton Kerin wrote: > On Mon, May 3, 2010 at 7:04 AM, John Doty <[1]...@noqsi.com> wrote: > > On May 2, 2010, at 11:41 PM, Britton Kerin wrote: >> I use a probably almost identical project symbol approach. If this > is >> high-productivity way I'd hate to see the alternative. > Essentially, >> everybody gets to continually reinvent the same heavy symbols. Its > got >> to be possible to do better than this. > > Reinvent the same symbols? Nah. There are trillions of possibilities > for heavy symbols. It's unlikely two independently developed > projects would have much in common here. Even my own projects tend > not to have much overlap: different customers, different > requirements, even different project phases. > > How much really changes for a chip resistor or SOIC uc? In one recent project, we started out thinking we'd use 0402 resistors to save space. Found we had more space than expected, so changed to 0603. Also, package changes are common between prototype and production. > These things > should take ZERO effort to get something pretty in gschem that will > work with pcb. Maybe you use pcb, but I don't (although there's this new project where it might fit). There are lots of ways to use gEDA. > If people care about the exact mask settings and such > they can tweak. Tweaking is much more common than you think. > > I don't know about you, but customizing pre-existing symbols takes > me very little time compared to the rest of the design process. > Creating new ones from scratch takes more time, but between the gEDA > library and [2]gedasymbols.org, there's often a starting point for > anything truly common. > > If you have a reference design that you're trying to modify or extend > getting a working set of symbols takes most > of the time. And reference designs are the open source way. You can distribute symbol files with a reference design. No problem. Still, I'd expect to have to tweak them. Indeed, design reuse is a strength of the project symbol approach. Change packages, even parts selection (have symbols fast_npn.sym, etc, choose part to fit requirements later) by changing project symbols. Leave the schematics alone. Like changing include files in software. > > If people were reinventing the same heavy symbols, there'd be a high > probability of finding a suitable heavy symbol on > [3]gedasymbols.org. In practice, I find those symbols almost always > need customization. But of course this shouldn't be surprising. > > Interestingly, I've looked at [4]gedasymbols.org briefly before and > failed to find most of its content, since its hiding > under the names of the contributors and in the search field. I > concluded it had ended up as a footprint library. Footprints for pcb are apparently more of a problem than symbols for gschem, so they've tended to take over. > I'd suggest the following (heck I'll do it if someone wants to give me > access): > * Put the whole ball of symbols tarball under a Download section. > * Or at least put the cvs checkout incantation somewhere on the > page. I'm assuming you can check it all out > without an account? Oh in fact poking around more I find this > information under "ask for a CVS account" link. Yes, and as far as I'm concerned that's the easy way to use it. New files show up frequently. 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 Mon, May 3, 2010 at 7:04 AM, John Doty <[1]...@noqsi.com> wrote: On May 2, 2010, at 11:41 PM, Britton Kerin wrote: > I use a probably almost identical project symbol approach. If this is > high-productivity way I'd hate to see the alternative. Essentially, > everybody gets to continually reinvent the same heavy symbols. Its got > to be possible to do better than this. Reinvent the same symbols? Nah. There are trillions of possibilities for heavy symbols. It's unlikely two independently developed projects would have much in common here. Even my own projects tend not to have much overlap: different customers, different requirements, even different project phases. How much really changes for a chip resistor or SOIC uc? These things should take ZERO effort to get something pretty in gschem that will work with pcb. If people care about the exact mask settings and such they can tweak. I don't know about you, but customizing pre-existing symbols takes me very little time compared to the rest of the design process. Creating new ones from scratch takes more time, but between the gEDA library and [2]gedasymbols.org, there's often a starting point for anything truly common. If you have a reference design that you're trying to modify or extend getting a working set of symbols takes most of the time. And reference designs are the open source way. If people were reinventing the same heavy symbols, there'd be a high probability of finding a suitable heavy symbol on [3]gedasymbols.org. In practice, I find those symbols almost always need customization. But of course this shouldn't be surprising. Interestingly, I've looked at [4]gedasymbols.org briefly before and failed to find most of its content, since its hiding under the names of the contributors and in the search field. I concluded it had ended up as a footprint library. I'd suggest the following (heck I'll do it if someone wants to give me access): * Put the whole ball of symbols tarball under a Download section. * Or at least put the cvs checkout incantation somewhere on the page. I'm assuming you can check it all out without an account? Oh in fact poking around more I find this information under "ask for a CVS account" link. Again I'd be happy to clean this page up a bit. Britton References 1. mailto:j...@noqsi.com 2. http://gedasymbols.org/ 3. http://gedasymbols.org/ 4. http://gedasymbols.org/ ___ 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 3, 2010, at 8:28 AM, Kai-Martin Knaak wrote: > On Sun, 02 May 2010 22:41:21 -0700, Britton Kerin wrote: > >> What I've been thinking of lately is a sort of heavy symbol wiki that >> people could add to as they create their own project parts like you do. > > you mean, like http://www.gedasymbols.org ? > Technically, it is not a wiki but a CVS repository. Still, it is meant to > serve almost exactly the purpose you propose. Due to its repository > nature, it can easily be mirrored on the local hard disk. Yep. And then if you do that, and update regularly, trivial search commands like: locate .sym | grep -i max921 will turn up useful symbols wherever they are: the common library, gedasymbols, your old projects... 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 Sun, 02 May 2010 22:41:21 -0700, Britton Kerin wrote: > What I've been thinking of lately is a sort of heavy symbol wiki that > people could add to as they create their own project parts like you do. you mean, like http://www.gedasymbols.org ? Technically, it is not a wiki but a CVS repository. Still, it is meant to serve almost exactly the purpose you propose. Due to its repository nature, it can easily be mirrored on the local hard disk. ---<)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+kmk&op=get ___ 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 2, 2010, at 11:41 PM, Britton Kerin wrote: > I use a probably almost identical project symbol approach. If this is > high-productivity way I'd hate to see the alternative. Essentially, > everybody gets to continually reinvent the same heavy symbols. Its got > to be possible to do better than this. Reinvent the same symbols? Nah. There are trillions of possibilities for heavy symbols. It's unlikely two independently developed projects would have much in common here. Even my own projects tend not to have much overlap: different customers, different requirements, even different project phases. I don't know about you, but customizing pre-existing symbols takes me very little time compared to the rest of the design process. Creating new ones from scratch takes more time, but between the gEDA library and gedasymbols.org, there's often a starting point for anything truly common. If people were reinventing the same heavy symbols, there'd be a high probability of finding a suitable heavy symbol on gedasymbols.org. In practice, I find those symbols almost always need customization. But of course this shouldn't be surprising. 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 Sun, May 2, 2010 at 8:29 AM, John Doty <[1]...@noqsi.com> wrote: >> * 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. Databases may be evil, but you have to admit this diagram: [2]http://www.geda.seul.org/wiki/geda:gparts_dd#part_database is a much more coherent start to understand the situation that gEDA is trying to model than all the footprint/device fun. From a new user's perspective. [snip] > 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. I use a probably almost identical project symbol approach. If this is high-productivity way I'd hate to see the alternative. Essentially, everybody gets to continually reinvent the same heavy symbols. Its got to be possible to do better than this. > Therefore, the whole business may be moved into a device-entity, that maps > the electrical connections of a part (that are represented in a symbol) to > the physical pins of its package. (I know this has been described before) Except that can already be described by the symbol file, so why have a redundant way to do this? I'm not sure what the correct approach is here. These days, too many users seem to want separate, labelled things like "databases", rather than seeing all the isomorphisms that make life in the technical world simpler, better connected, and easier to comprehend. Well, all the parts vendors keep things in databases. I agree that the server databases manage to be such a pain in the ass to install and administer that they usually are not worthwhile (including in this case). I *like* the files way as well, don't think I'm just a db junkie :) But really this is the sort of thing DBs are really good for. What about SQLite? I've *glanced* at its home page a couple times in the past (really no more than that), and in really less than 10 minute just now I was able to download it, build it, create a database in a file, query it, and dump its generative code (probably a good format for grep-happy people like you :). What I've been thinking of lately is a sort of heavy symbol wiki that people could add to as they create their own project parts like you do. You could build parts in chroots with a few things (Pcb_9.pm tragesym etc.) available. I'm not sure how useful a DB would be in an application like this but I wouldn't rule it out just based on bad experiences with servers databases. Britton References 1. mailto:j...@noqsi.com 2. http://www.geda.seul.org/wiki/geda:gparts_dd#part_database ___ 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 2, 2010, at 3:11 PM, kai-martin knaak wrote: I got hurt more than once and pretty badly by data base corruption while working with protel. Loss of several weeks worth layout/schematic design made me very reluctant when it comes to data bases. FYI, speaking as someone who works with large, complex databases every day, this is not the norm in the database world. Database corruption is about as common as filesystem corruption in the real database world. The fact that Protel has problems doesn't describe how the rest of the world works...it just says "don't use Protel". -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")
Armin Faltl wrote: > It's an independent tool like gattrib and you are free not to use it. That's why I said "_I_'d avoid data base solutions (...)". Of course you can add to the list of geda applications whatever you like. Just don't expect everybody to cheerfully join in. > The idea of the tool is, to describe the relations between the entities > you mention. However, relations in the EDA world are not that complex. Each component relates to just a few footprints, not thousands. The same is true for the relation between real components and symbols. > You are also free to do searches among the thousands of little packets > some of them with wrong lables as of now by hand. The quality of symbols, footprints and models won't magically improve when stored in a database. >> * 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. The only way to share an entity stored in a data base is a proper pair of input and export functions. This means, data bases and import/export functions on both sides of the transfer must be synchronized or at least be compatible. The effort to make sure this is the case is not trivial. Ask the maintainer of any accounting software for what it takes to upgrade the system. Compare import/export of complex objects with the act of giving away a set of files. I got hurt more than once and pretty badly by data base corruption while working with protel. Loss of several weeks worth layout/schematic design made me very reluctant when it comes to data bases. >> * Only a very small subset of the operations available on file systems is >> present by default in data bases. Just to get the same level of user >> power as with files, a major effort of data base scripting is needed. >> > ??? Think grep, find, ed, awk, perl, mv, cp, merge, diff, mkdir, ... >> * A data base can easily be corrupted on update of the data base driver. >> > A file backend driver on changes of the file format can mess up as well, These drivers act on one file at a time. So they are less likely to leave the whole lib unusable. > esp. if one tries > to reuse some parts of the parser. So can format converters of any kind. A decent converter does not even Attempt to write to the original files. > As the name "gparts" suggests, the databases main objective is not to > map symbols to footprints but to map vendor-parts to geda-aggregats. This is indeed a missing ingredient in the geda soup. I just doubt, that a data base is the best way to store the relation. > 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. 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. (snip) > Therefore, the whole business may be moved into a device-entity, that maps > the electrical connections of a part (that are represented in a symbol) to > the physical pins of its package. (I know this has been described before) Other EDA applications like eagle, orcad and protel successfully tackle this set of problems with the notion of "packages". The package knows about the symbols, footprints and models an actual component may be comprised of. ---<)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 2, 2010, at 5:21 AM, Armin Faltl wrote: > >> I'd avoid data base solutions for footprints, symbols, simulation models and >> the like. > Appart from my attempt to come up with my own table layout, I try now to get > gparts working. > It's an independent tool like gattrib and you are free not to use it. > The idea of the tool is, to describe the relations between the entities you > mention. > You are also free to do searches among the thousands of little packets some > of them > with wrong lables as of now by hand. 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. > >> * 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. >> * Only a very small subset of the operations available on file systems is >> present by default in data bases. Just to get the same level of user power >> as with files, a major effort of data base scripting is needed. >> > ??? >> * A data base can easily be corrupted on update of the data base driver. >> > A file backend driver on changes of the file format can mess up as well, esp. > if one tries > to reuse some parts of the parser. So can format converters of any kind. >> * Open source data base drivers like postgres or mysql may be quite mature. >> Compared to the stability of the unix file utils they still look shaky. And >> fast moving. >> > The implementations are evolving. The good thing is, there is an > ANSI/ISO-standard called SQL99 > and that is stable and more than sufficient to describe what we need. >> * A data base would add a major dependency to the already significant set. >> > True. For me still a lighter burden, than to implement the functionality of a > database engine. Except that we already have much more than you recognize. >> * The number of all objects in the library is fairly moderate. All symbols >> and footprints from the distribution plus all of gedasymbols are currently >> about 4300. This can easily be handled by a file system. >> > Even the millions of parts with their several packages each could be handled > by a proper > directory tree. It's the connections that are the problem and a database > expresses them > implicitly. (there is no such thing as a "symbolic half-link" that connects > to everything > that happens to have "the other half" ;-) > > As the name "gparts" suggests, the databases main objective is not to map > symbols to > footprints but to map vendor-parts to geda-aggregats. Why not express that mapping as a set of .sym files? > > 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. > 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 sym
Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
I'd avoid data base solutions for footprints, symbols, simulation models and the like. Appart from my attempt to come up with my own table layout, I try now to get gparts working. It's an independent tool like gattrib and you are free not to use it. The idea of the tool is, to describe the relations between the entities you mention. You are also free to do searches among the thousands of little packets some of them with wrong lables as of now by hand. * 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. * Only a very small subset of the operations available on file systems is present by default in data bases. Just to get the same level of user power as with files, a major effort of data base scripting is needed. ??? * A data base can easily be corrupted on update of the data base driver. A file backend driver on changes of the file format can mess up as well, esp. if one tries to reuse some parts of the parser. So can format converters of any kind. * Open source data base drivers like postgres or mysql may be quite mature. Compared to the stability of the unix file utils they still look shaky. And fast moving. The implementations are evolving. The good thing is, there is an ANSI/ISO-standard called SQL99 and that is stable and more than sufficient to describe what we need. * A data base would add a major dependency to the already significant set. True. For me still a lighter burden, than to implement the functionality of a database engine. * The number of all objects in the library is fairly moderate. All symbols and footprints from the distribution plus all of gedasymbols are currently about 4300. This can easily be handled by a file system. Even the millions of parts with their several packages each could be handled by a proper directory tree. It's the connections that are the problem and a database expresses them implicitly. (there is no such thing as a "symbolic half-link" that connects to everything that happens to have "the other half" ;-) As the name "gparts" suggests, the databases main objective is not to map symbols to footprints but to map vendor-parts to geda-aggregats. 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. 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. 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 understood the difference of pinnumber- and pinseq attributes in a symbol. As far as I can tell, the number is redundant to the seq and used for nothing. It would be intelligable, if the number were used for the netlist and using the same number for different seq's means, the physical pins denoted by seq are electrically connected. This of course doesn't go well with the rendering of symbols as of now. Therefore, the whole business may be moved into a device-entity, that maps the electrical connections of a part (that are represented in a symbol) to the physical pins of its package. (I know this has been described before) This mail is not complete, as I have to leave now. Regards, Armin ___ 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 7:37 PM, Armin Faltl wrote: Looks ok: [ a...@ajf8 /usr/tmp/gparts] > autoreconf -vi Someone else pointed out the autogen.sh script, which I assumed you had checked for already. It contains a similar command line. ___ 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")
Armin Faltl wrote: > since the stuff I managed to layout with your help is soldered now and > shining brightly, > I got some time, to have a look at my attempt to a database. So I have > to take levels > of abstraction and their naming serious. I'd avoid data base solutions for footprints, symbols, simulation models and the like. * Unless there are excellent import/export functions, a data base is an additional obstacle to collaboration. These functions need to be written and maintained- * Only a very small subset of the operations available on file systems is present by default in data bases. Just to get the same level of user power as with files, a major effort of data base scripting is needed. * A data base can easily be corrupted on update of the data base driver. * Open source data base drivers like postgres or mysql may be quite mature. Compared to the stability of the unix file utils they still look shaky. And fast moving. * A data base would add a major dependency to the already significant set. * The number of all objects in the library is fairly moderate. All symbols and footprints from the distribution plus all of gedasymbols are currently about 4300. This can easily be handled by a file system. Just my two euro cents. ---<)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")
Looks ok: [ a...@ajf8 /usr/tmp/gparts] > autoreconf -vi autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force configure.ac: installing `./install-sh' configure.ac: installing `./missing' src/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' [ a...@ajf8 /usr/tmp/gparts] > echo $? 0 Charles Lepple wrote: On Sat, May 1, 2010 at 6:33 AM, Armin Faltl wrote: Hi all, esp. authors of gpart, an attempt to run autoconf in gparts gives me: autoconf configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:9: error: possibly undefined macro: AM_PROG_LIBTOOL What happens if you run 'autoreconf -vi'? ___ 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, 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. 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. On Sat, 2010-05-01 at 17:55 -0400, Charles Lepple wrote: > On Sat, May 1, 2010 at 6:33 AM, Armin Faltl wrote: > > Hi all, esp. authors of gpart, > > > > an attempt to run autoconf in gparts gives me: > >> autoconf > > configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE > > If this token and others are legitimate, please use m4_pattern_allow. > > See the Autoconf documentation. > > configure.ac:9: error: possibly undefined macro: AM_PROG_LIBTOOL > > What happens if you run 'autoreconf -vi'? > In my system the autogen.sh/configure/make/make install process ran without any issues.(ubuntu 10.04 amd64) 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 Sat, May 1, 2010 at 6:33 AM, Armin Faltl wrote: > Hi all, esp. authors of gpart, > > an attempt to run autoconf in gparts gives me: >> autoconf > configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.ac:9: error: possibly undefined macro: AM_PROG_LIBTOOL What happens if you run 'autoreconf -vi'? -- - Charles Lepple ___ 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 to say: I had libtool installed - it's version 1.5.26 this is a Debian lenny system btw. Jim wrote: You have to install libtool. Search for libtool via your distro yum or apt-cache for RPM or DEB distros. I have no idea how to do it for Windows. Jim. ___ geda-user mailing list geda-user@moria.seul.org 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")
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 It's not impossible that mysql would quietly ignore an autoincrement attribute for a foreign key. I agree it looks wrong. 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")
Armin Faltl wrote: Hi all, esp. authors of gpart, an attempt to run autoconf in gparts gives me: > autoconf configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:9: error: possibly undefined macro: AM_PROG_LIBTOOL The documentation of autoconf is incredibly long - I found m4_pattern_allow() but still don't know what to do. Trying to run automake gives errors as well. If you could tell me the correct setup for autoconf/automake or provide a working configure I'll have a next try. Regards, Armin You have to install libtool. Search for libtool via your distro yum or apt-cache for RPM or DEB distros. I have no idea how to do it for Windows. 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")
Hi all, esp. authors of gpart, an attempt to run autoconf in gparts gives me: > autoconf configure.ac:2: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:9: error: possibly undefined macro: AM_PROG_LIBTOOL The documentation of autoconf is incredibly long - I found m4_pattern_allow() but still don't know what to do. Trying to run automake gives errors as well. If you could tell me the correct setup for autoconf/automake or provide a working configure I'll have a next try. Regards, Armin ___ 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")
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 ___ 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,
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?
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)?
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...
Greetings, Armin
I won't try to compile it now, but the table diagram looks promissing.
Regards, Armin
___
geda-user mailing list
geda-user@moria.seul.org
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")
A bit more reading and thinking reveals a problem with current gpart: To express the many-to-many relation between parts and symbols it uses a table called "device". This is fed by the infamous device attribute in the symbol libraries. There's nothing wrong in the theory of DB-design with it, but the indiscriminate use of this attribute in the symbol-libs waters the use of this design down to uselessness. While sacrificing the ability to attach more than one symbol to a part by directly referencing the symbol in the part, my schema avoids this problem. To use it, one has to bypass the device thing and enter a correct relation. This would have meant no drawback for me, since I rarely see a need to use more than one symbol per part personally. And others will see this different. The flexible way to fix this, is to go the way of gpart and use the device table correctly by either not feeding from the current symbol libraries of fixing the device attribute there. Example that bit me on 1st chance: there is a US and EUR variant of the resistor-varible-?.sym so both will have zealots in favour. Both use a random pinout and don't show, which pin is which in the schematic. Both say device=RESISTOR_VARIABLE and here is the problem: of course the tap on my physical potentiometer is at pin 2 and so it is in my selfmade footprint, while in the symbols the tap is of course at pin 3. To get this right in the database one has to use something like device=POTENTIOMETER_T2 to show where the tap is in the symbol, so it is impossible, to connect a device=POTENTIOMETER_T3 with my footprint. Of course it was easy to fix this with a scalpel, verowire and a soldering iron ;-) And later on with a selfmade symbol that is more elegant than the others anyway... Regards, Armin Armin Faltl wrote: Thanks for the hint. I installed git on my machine to get this Then I searched for references on the web, since the README is a oneliner stating it's own existence. After having found this http://www.geda.seul.org/wiki/geda:gparts_dd I see now, that I reinvented the wheel with small differences. No mention of gparts can be found in the master documentation of geda http://geda.seul.org/wiki/geda:documentation I won't try to compile it now, but the table diagram looks promissing. Regards, Armin ___ 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 the hint. I installed git on my machine to get this Then I searched for references on the web, since the README is a oneliner stating it's own existence. After having found this http://www.geda.seul.org/wiki/geda:gparts_dd I see now, that I reinvented the wheel with small differences. No mention of gparts can be found in the master documentation of geda http://geda.seul.org/wiki/geda:documentation I won't try to compile it now, but the table diagram looks promissing. Regards, Armin Bert Timmerman wrote: Hi Armin, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Armin Faltl Sent: Wednesday, April 28, 2010 5:27 PM To: gEDA user mailing list Subject: Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib") Hi, attached is a 1st version of the table definitions. The file should be self-documenting. Armin Did you have a stab at: git clone git://git.gpleda.org/gparts.git Just my EUR 0.02 Kind regards, Bert Timmerman ___ geda-user mailing list geda-user@moria.seul.org 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")
Hi Armin, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Armin Faltl > Sent: Wednesday, April 28, 2010 5:27 PM > To: gEDA user mailing list > Subject: Re: gEDA-user: Database on symbols, footprints and > other (was "Re: gattrib") > > Hi, > > attached is a 1st version of the table definitions. The file > should be self-documenting. > > Armin > Did you have a stab at: git clone git://git.gpleda.org/gparts.git Just my EUR 0.02 Kind regards, Bert Timmerman ___ 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,
attached is a 1st version of the table definitions. The file should be
self-documenting.
Armin
-- author: Armin Faltl
-- date : 2010-04-28
-- description:
-- This collection of tables shall describe the connectivity between
-- schematic symbols, parts, packages of electronic parts and
-- copper footprints.
-- It shall take into account the influenc of different production
-- processes on the possible copper patterns.
-- Additionally other relations like part to simulator-model
-- shall be supported.
--
-- Database Design Considerations:
-- Since the pinout of symbols is mapped to footprints via parts and
-- packages, a many-to-many relation of symbols to parts would need
-- some sort of pinout-descriptor or wisely restricting the assigned
-- symbols to a part. This would introduce a further pitfall, so as
-- of now, the table definitions allow only one symbol per part.
-- Not including symbols at all would lose the ability to relate
-- symbol-pins to footprint pins of course.
-- choosing footprints for symbols of parts is a total mess atm!
-- there has to be some hierarchy and order
create table category (
ctg_idx serial primary key, -- just to show you, I know other types than "varchar"
ctg_name varchar unique
);
insert into category (ctg_name) values ('resistor');
insert into category (ctg_name) values ('capacitor');
insert into category (ctg_name) values ('inductor');
insert into category (ctg_name) values ('diode');
insert into category (ctg_name) values ('transistor');
-- and so on
-- enumeration of symbols
-- - or more, including a path to the symbol file,
-- general description etc.?
create table symbol (
sym_name varchar primary key,
categ integer references category,
descr varchar -- a short description of what the symbol represents
);
-- "part" is what sometimes is stated in the "device" in gschem, but it should
-- be more specific than "RESISTOR" - or not?
-- Beware! certain "devices" have different pinout, depending on the package.
-- Because the symbol is not in the primary key, this has to be handled in the
-- part_name. The unique ID provided by ordering information should do.
create table part (
part_name varchar primary key, -- this is either a vendor part name/number
-- or a generic pseudo-part denoting an
-- anonymous class of parts providing the function
-- it is questionable to state a symbol here, since it restricts
-- a many-to-many relation to a one-to-many
symbol varchar references symbol, -- thou shall not assign a MOSFET part to
-- a resistor symbol
categ integer references category, -- if this doesn't match the symbols category
-- you might expect trouble
part_spec varchar,-- URI/path to specification
alias varchar references part -- this is an alias to a canonical part for the
-- purpose of grouping specialized vendor stuff
-- to a coarser view
-- stock integer -- inhouse stock of this part
);
-- layout relevant tables --
-- "package" is a table describing the physical package attributes
create table package (
pkg_name varchar, -- canonical name as of a standard or manufacturer
pgk_spec varchar -- URI to a specification of the package
-- 3d_model varchar -- for rendering ala kicad or mechanical cad
);
-- "part_pkg", this is a many-to-many relation, requiring a correlation table
--
-- Beware! certain parts have different pinout, depending on the package.
-- In that case there is a connection between the symbol and the package,
-- that is not expressed explicitly here.
create table part_pkg (
part varchar references part,
pkg varchar references package
);
-- "footprint", the actual copper pattern
create table footprint (
fp_name varchar primary key,
lib_name varchar, -- name/path of the library, containing the footprint
);
-- enumeration of processes, to avoid "inventions"
create table process (
proc_name varchar primary key
};
insert into process (proc_name) values ('hand');
insert into process (proc_name) values ('wave');
insert into process (proc_name) values ('reflow');
-- and so on
-- "pkg_fp" expresses the relation between package, footprint and process
create table pkg_fp (
package varchar references package,
process varchar references process,
footprint varchar references footprint
);
-- simulation relevant tables --
--
-- the simulation stuff is not very well thought out
--
create table simulator (
sim_name varchar primary key
-- add stuff to describe the simulator here...
);
create table model (
model_file varchar primary key,
simulator varchar references simulator,
model_part varchar references part,
param varchar -- list of parameters to feed into the model for
-- that particular part
);
-- create table model_part (
-- model varchar primary key,
-- part varchar references part,
-- param varchar -- lis
gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")
Hi, since the stuff I managed to layout with your help is soldered now and shining brightly, I got some time, to have a look at my attempt to a database. So I have to take levels of abstraction and their naming serious. John Doty wrote: On Apr 27, 2010, at 12:26 PM, Mike Bushroe wrote: Not because of the bugs I ran into but since choosing a footprint is a difficult process in it self I was longing for a footprint browser. My personal view is that schematics should use the conventions in the gEDA documentation: http://geda.seul.org/wiki/geda:pcb_footprint_naming_conventions Agree with adhering to the convention, don't agree with the convention. The simple reason for my critics on the convention is case-use: studies in the aera of teletyping have shown, that lower case is faster to read than uppercase. That and the limit on bandwidth is why teletypes used all lowercase letters. Then computers appeared on the sceen and some sales-managers found, that upper case letters "look more professional" than lowercase letters. That and the limit on bandwidth is, why the 1st computer terminals used all uppercase ;-) Now compare the following: PART 1: AXHN868X888 PART 2: AXBN868X888 PART 3: AXHN8688X88 vs. part 1: axhn868x888 part 2: axbn868x888 part 3: axhn8688x88 I don't want to suggest to deviate from well known acronyms like DIN, but why must we use an uppercase X for separation of dimensions and the like? (And what are "Basic SMT semiconductors"? surface mounted tevices ?) Some of the convention-based names seem to contain spaces. From what I read, the trailing non-space groups are actually macro parameters for the m4-processor. This should be dealt with somehow I think, since it clashes with easy file treatment and newlib is the way to go, isn't it? These refer to the device, not the pattern of copper on the board. The pattern of copper corresponding to a given device footprint should be chosen in the layout process, because it depends (like other layout parameters) on the manufacturing processes. For me a device is a MAX232 or HCTL-2016, both sitting in a DIL-16 package (among other possibilties). So actually the convention above would describe canonical names for packages. So far in all datasheets I read, the copper pattern if at all is specified with dimensions and no mention is made of any manufacturing process (or I just ignored it, knowing my hand-soldering capabilities being far from um-precision). Still I want the database to provide for such detail and distinguish between "package" and "footprint". A database-driven tool that maps device footprints into layout footprints would be useful. We could have databases for various requirement sets here. One thing that comes to mind with integrating simulator-models in the database is, that the package for a given device influences parameters like parasitic capacitance of pins. The more so does the copper pattern of the pads including layers below the actual pad. - would we want to address this in a database? Where does it end? (if this sounds weird, go to www.analog.com, search for "rarely asked questions" and then find RAQ_capacitycectomy.pfd - it's fun to read IMO) Keeping the responsibility for this out of gschem avoids unnecessary complication and facilitates design reuse: the schematic should be as free as possible from dependencies on the layout and manufacturing processes. Agree. Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
