Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> We'll have to be careful to make this transparent to the user. Yes, this is the tricky part. I suspect we'd need "standard names" for various fields, for example the search fields Digikey uses, and figure out some backend rules for how various database chunks are merged, etc. But from the user's point of view, it should be no more complex than our current chooser, perhaps. Or right-click -> attributes -> some sort of dynamic menu. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
DJ Delorie wrote: > >> I will put together such a combined symbol and footprint lib >> in my section of gedasymbols. May take about a week or so. > > Excellent! Thanks! After I skipped through what needs to be done, I have to admit that it will take a bit longer. > Hmmm... I don't think "easy" precludes "setting up directories". I > meant, the *internal* structure of the library should be such that the > user can unpack the tree, point to it, and go. For symbols this means a flat tree with no subdirectories at all. I'd say, the search routine of the add symbol dialog really should be enhanced recursively descend to directories. > Yes. However, I don't want us to have a zillion footprints that are > all the same shape, just because each packet has its own copy, either. This is why footprints symbols and essentially any other objects can be embedded in the packet, or referenced. It is up to the designer of the packet library to decide what is the mos useful. > However, if a packet has a *custom* footprint, that's OK. That's what I meant :-) > Your packet idea could be implemented as a subdirectory (contains all > the symbols, footprints, models, relations, etc for a single category > of component), So an object "embedded" in the packet would just be a file in the subdir. I like this. It turns embedding into a reference to the local directory. At the heart of the packet would be a file that gives all the relations and defaults. > My component DB goes one step further - the tool offers the > information it has, and the database passes back *all* the packets > that match, by way of specifying, for each empty attribute, which > values are compatible with the existing ones. Eventually you filter > it down to one option, and you get that component. How would you communicate the rules you taught the database to colleagues? Say, there is a brand new series of FPGAs you'd like to share. > So if you start with "resistor", for example, the next step might be > to pick a value, or a footprint, or a tolerance... but you have to be > able to pick from many packets across many libraries. We'll have to be careful to make this transparent to the user. Else there would be a feeling of inconsistency -- The system seems to erratically choose from different libs. I already found the m4/newlib ambiguity no fun at all. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On 05/28/2011 10:01 AM, Dave McGuire wrote: This is my opinion, speaking as a professional developer of both hardware and software: Scheme was a good choice for gEDA, and it should be left alone. The chosen implementation of Scheme, guile, may not be the best tool for the job right now, but the language is. Me too. How about Tiny scheme? What's the status of that? Who started with it and what did they find? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
Mike Bushroe wrote:
(snip)
> but could the 'packet' of data also have choices for alternate naming
> in the schematic of pins with multiple uses?
Is this supposed to configure individual pins? Or is it more like whole
ranges of pins used either as analog input or as digital output? I
think, we need both :-)
For individual pins I propose an extension of the pin attribute concept.
Add a comma separated list of alternatives in an attribute like this:
pinlabels=foo,bar,baz
The gschem GUI would present a drop-down list of these alternatives in
the attribute editor. It is a way to give a choice of default values for
the pinlabel attribute rather than just one as we do now. This technique
may be applied to every attribute. It does not affect the notion of packets
at all.
For whole ranges of pins the packet may contain alternate sub-symbols.
These sub-symbols shall bear a unique label. The scope of uniqueness
of the labels is just the current packet. So it is easy to meet.
These labels are used by a be a set of rules that tell the system which
sub symbols are alternates, which sub symbols are required (e.g. power)
and which are optional. The rules are be attributed individually with
a policy flag to tell the system how to treat violations ("enforce",
"warn", "ignore", ...). The default of the policy flag is set at design
time of the packet. It can be overridden by the user per instance of the
packet in the schematic.
> You would also have to allow
> for the fact that the DIP part is often limited to 40 pins, but the TQFP has
> 44 pins, and when they have one the BGA is 49.
This is the pin mapping theme again. The packet may, no, should contain
a scheme to map symbol pins to footprint pads.
---<)kaiamrtin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> but could the 'packet' of data also have choices for alternate > naming in the schematic of pins with multiple uses? Perhaps that kind of choice could be part of the symbol itself, not part of the component data? It would have to be independent of the symbolic name we use in the packet, but perhaps a pinlabel like "P45/TXD4/IRQ7" could offer you the chance to only show the P45 part, or only the IRQ7 part, in the symbol? What I've done in the past is just make different symbols that correspond to parts of the chip being used according to certain perhipherals; like a symbol for the ethernet portion of an RX chip, or the power/programming module of an R8C. But that's not an elegant solution. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
DJ, while reading your comments about gschem and pcb requesting ALL the 'packets' that match the partial information in order to fill in gaps reminds me of another minor problem I have with the occasional work _I_ do. I usually start with an Atmel microcontroller and add on parts and wires from there. I can see the packet starting with "ATMega64" that would select a microcontroller with given memory size, but with several different package styles, and thus footprints, and different clock speeds and thus spice models. But another problem rather specific to microcontrollers, whether they by PIC, Atmel, Parallax, etc is that most pins have multiple uses, and that is hard to squeeze into the symbol without needing a E size drawing for the schematic. I Know John Doty will roll over in his eventual grave over this, but could the 'packet' of data also have choices for alternate naming in the schematic of pins with multiple uses? You would also have to allow for the fact that the DIP part is often limited to 40 pins, but the TQFP has 44 pins, and when they have one the BGA is 49. Since one of the hardest parts for me of the gschem, gshcm2pcb, pcb tool chain is finding the right footprints for device, switch, connector, I am glad that a heavy library approach is being tried. I think if this works it will further open up the schematic to pcb tool chain for newcomers. Mike -- Burn the Land, Boil the Sea, You can't take the SKY from me! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On 05/26/2011 07:40 PM, John Doty wrote: If the consensus is that gnetlist is the place to perform the transformations we're discussing, then we're in Scheme territory, I think. I can't see abandoning guile/scheme. I've even written scripts in Cadence skill language, which is pretty much LISP. I just need to find some way to pare down the magnitude of the task so I could do some little slices of it and go back to work for a week and a half, then do another slice...and repeat... Otherwise I am learning python for web site programming with the Django framework and like that better than C code for the TinyOS framework that I've done. I look at my old PERL scripts and it's like a language I never knew... PERL familiarity seems to evaporate completely from my head every six months. John -- Ecosensory ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> I will put together such a combined symbol and footprint lib > in my section of gedasymbols. May take about a week or so. Excellent! Thanks! > This implies changes to the way gschem, gnetlist and PCB search for > libs. Currently, the only way to replace the default library is to > actually replace them at their original path (with root permission). Hmmm... I don't think "easy" precludes "setting up directories". I meant, the *internal* structure of the library should be such that the user can unpack the tree, point to it, and go. > > gschem and pcb both need to be better at referencing multiple > > libraries of arbitrary depth. This includes a better way to manage > > the libraries (gui, config, query rules), enable/disable them, and > > browse them. This information should be sharable between tools, > > specifically, at least, between gschem, gnetlist, and pcb. > > yes, please! Well, as you test your library, document what problems you encounter and think about what we'll need to do to Make It Right. (then do it, of course ;) > If we were to introduce the notion of packets, it would change the way > to look at the data. Without them, we'd have a symbol lib, a footprint > lib, a bunch of other data and a web of relations in the database. Packets > are a way to represent the relations in an intuitive way. They partition > the web of relations into, well, handy packets. > In addition to the footprint lib and the symbol lib there would be a > packet lib. Yes. However, I don't want us to have a zillion footprints that are all the same shape, just because each packet has its own copy, either. That's just wasteful. However, if a packet has a *custom* footprint, that's OK. I'm thinking, the directory structure (or effective tree structure) of the database should be such that gschem, pcb, and other tools can at least share a top-level node and the categories, but only see files relevent to their needs. Then we can have subdirectories for, say, Maxim (custom symbols and packet, but no footprints since they're all standard). Or subdirectories for Hirose connectors (no symbols since they're all standard, but custom packets and footprints), etc. Plus a section (or sections) for "standard symbols and footprints" Your packet idea could be implemented as a subdirectory (contains all the symbols, footprints, models, relations, etc for a single category of component), or your packet could be a row in a table in such a directory (i.e. the "1.2k Rohm 0603" row in the Rohm resistors library), or it could be the whole table if it uses all standard symbols/footprints (Rohm resistors would, for example, but Maxim wouldn't). Or it could be something else of course ;-) > Packets would change the way gschem, gnetlist or PCB access > objects. Rather than query directly for footprints, symbols or meta > data, they would ask the data base to pass the packet. Then they > would evaluate the contents of the packet to suggest footprints, > simulation models, or alternative symbols. My component DB goes one step further - the tool offers the information it has, and the database passes back *all* the packets that match, by way of specifying, for each empty attribute, which values are compatible with the existing ones. Eventually you filter it down to one option, and you get that component. So if you start with "resistor", for example, the next step might be to pick a value, or a footprint, or a tolerance... but you have to be able to pick from many packets across many libraries. > > Gschem and pcb need a way to swap variants on symbols and footprints, > > for example, switching between resistor-1 and resistor-2, or RESC1608N > > and RESC1608M. This depends on the metadata being available (above). > > Did I mention, that packets provide a means for this kind of task? Yup. We're past the "should we do it" phase and into the "how should we do it" phase. > > Send a reply letting us know what you're working on, > > I'll try to come up with a data format for a packet. Excellent! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
DJ Delorie wrote: > We need to create a few small heavy symbol libraries. These are the > self-contained "starter" libraries we talked about. I will put together such a combined symbol and footprint lib in my section of gedasymbols. May take about a week or so. > These libraries should be packaged such that it's easy for > the user to replace the standard library with them, and immediately be > productive. This implies changes to the way gschem, gnetlist and PCB search for libs. Currently, the only way to replace the default library is to actually replace them at their original path (with root permission). > gschem and pcb both need to be better at referencing multiple > libraries of arbitrary depth. This includes a better way to manage > the libraries (gui, config, query rules), enable/disable them, and > browse them. This information should be sharable between tools, > specifically, at least, between gschem, gnetlist, and pcb. yes, please! > While I do not wish to start a discussion about what kind of data > should go in our "metadata", we need tools to work with it. I think > that breaks down to the following: > > * On the database end, design an API or two with which we talk to the > data servers. Implement a few servers to see how it works. I've > started some ideas at http://www.delorie.com/pcb/component-dbs.html > at the "How is the database stored?" text. > > * In gschem and pcb, we need a way to query the data servers in the > attribute editors, in order to suggest attributes. > > * In gschem and pcb, be able to choose symbols/footprints based on > metadata queries - use the metadata as a filter for the library > dialog. > > * gnetlist needs the most work. It needs to be able to read a set of > rules, query the database, and fill in additional attributes based > on the rules. This need not be more than just "fill in the blanks" > for now. If we were to introduce the notion of packets, it would change the way to look at the data. Without them, we'd have a symbol lib, a footprint lib, a bunch of other data and a web of relations in the database. Packets are a way to represent the relations in an intuitive way. They partition the web of relations into, well, handy packets. In addition to the footprint lib and the symbol lib there would be a packet lib. Packets would change the way gschem, gnetlist or PCB access objects. Rather than query directly for footprints, symbols or meta data, they would ask the data base to pass the packet. Then they would evaluate the contents of the packet to suggest footprints, simulation models, or alternative symbols. > Gschem and pcb need a way to swap variants on symbols and footprints, > for example, switching between resistor-1 and resistor-2, or RESC1608N > and RESC1608M. This depends on the metadata being available (above). Did I mention, that packets provide a means for this kind of task? > Modify gschem's symbol chooser to allow filtering based on attributes > within the symbol, not just the symbol name. The symbol chooser would morph into a packet chooser. This should be able to do filtering based on the contents of the packets. > Send a reply letting us know what you're working on, I'll try to come up with a data format for a packet. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
DJ Delorie wrote: >> Scala anyone? > > I think the rule for choosing a language, other than "readily > available on mac, linux, and windows" is that you can go to pretty > much any bookstore and buy an "XYZ for Dummies" for it. I'd be fine with any language that is imperative by nature. By contrast, I'd only touch code based on lambda calculus if I have to. Yes, I already had my share of it. And I didn't like it. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
Another plus for Python. Such a nice language to code in IMHO. On 26 May 2011 21:22, Geoff Swan <[1]shinobi.j...@gmail.com> wrote: +1 python :) On Fri, May 27, 2011 at 4:52 AM, Andrew Poelstra <[1][2]as...@sfu.ca> wrote: On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > Opportunity to pick a more modern language, too. Something more > os-agnostic, we've had issues with scheme on Windows before. > > I'm a Perl fan myself. > Although Perl is probably better for string-handling, I think Python would be a better choice. It "feels" a lot more like a Lisp and quite a bit more well-known these days. It is also platform-agnostic, handles errors more cleanly, and is usually easier to read. Having said that, I have only a passing knowledge of both Perl and Python. -- Andrew Poelstra Email: asp11 at [2][3]sfu.ca OR apoelstra at [3][4]wpsoftware.net Web: [4][5]http://www.wpsoftware.net/andrew/ ___ geda-user mailing list [5][6]geda-user@moria.seul.org [6][7]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:[8]as...@sfu.ca 2. [9]http://sfu.ca/ 3. [10]http://wpsoftware.net/ 4. [11]http://www.wpsoftware.net/andrew/ 5. mailto:[12]geda-user@moria.seul.org 6. [13]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [14]geda-user@moria.seul.org [15]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:shinobi.j...@gmail.com 2. mailto:as...@sfu.ca 3. http://sfu.ca/ 4. http://wpsoftware.net/ 5. http://www.wpsoftware.net/andrew/ 6. mailto:geda-user@moria.seul.org 7. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 8. mailto:as...@sfu.ca 9. http://sfu.ca/ 10. http://wpsoftware.net/ 11. http://www.wpsoftware.net/andrew/ 12. mailto:geda-user@moria.seul.org 13. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 14. mailto:geda-user@moria.seul.org 15. 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: Task list for: Solving the light/heavy symbol problem
On May 26, 2011, at 11:56 PM, DJ Delorie wrote: >> >> Awhile back, Peter B. told me he was close to reimplementing >> gnetlist completely in Scheme. That might be a sensible place to >> start. > > Opportunity to pick a more modern language, too. Something more > os-agnostic, we've had issues with scheme on Windows before. One problem is that the gnetlist back-ends are a *tremendous* resource, and they're written in Scheme. From my perspective, losing those would cripple gEDA. If the consensus is that gnetlist is the place to perform the transformations we're discussing, then we're in Scheme territory, I think. The other option I see is to be more ambitious and add another tool. Rather than transform attributes in gnetlist, we could do it in a schematics-to-schematics tool, then feed the transformed schematics to gnetlist. With a new tool, we're not restricted to any particular language. This would also solve the next problem we'll encounter: once they can transform attributes and connections, users will want annotated schematics reflecting those transformations. At the risk of repeating myself, there's a prototype for this at https://github.com/xcthulhu/lambda-geda, in production use for producing flattened schematics for documentation of a hierarchical design. It implements the flow: (schematics)->[parser]->(s-expressions)->[transformation script]->(s-expressions)->[writer]->(schematics) However, it's written in Haskell. While that is certainly a "more modern language" than Scheme, I fear that if I were to advocate it to this group somebody would arrange a meeting for me with the Yakuza in a dark Tokyo alley ;-) > I'm a Perl fan myself. (shudder) 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: Task list for: Solving the light/heavy symbol problem
> -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Mark Rages > Sent: Thursday, May 26, 2011 4:24 PM > To: gEDA user mailing list > Subject: Re: gEDA-user: Task list for: Solving the > light/heavy symbol problem > > +1 python. If only it were as easy as voting... Not quite, but it certainly helps if a lot of people like it. That makes it a lot more likely that more people will be able to jump and contribute quickly, without having to learn a new language. D ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> +1 python. If only it were as easy as voting... One vote per patch :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On Thu, 2011-05-26 at 16:45 -0400, DJ Delorie wrote: > Scala anyone? I think the rule for choosing a language, other than "readily available on mac, linux, and windows" is that you can go to pretty much any bookstore and buy an "XYZ for Dummies" for it. May be Ruby? (There's a "Ruby on Rails for Dummies" at least...) After some advertising here on the list I decided to learn some Ruby and looks like powerful+fun+natural language all in one. Otherwise I like the idea of Python. I currently use it for footprint generation API inspired on Darrel Harmon's footgen.py. Best Regards, Felipe. -- Felipe De la Puente Christen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
Friends - On Thu, May 26, 2011 at 01:41:08PM -0700, Jared Casper wrote: > On Thu, May 26, 2011 at 11:52 AM, Andrew Poelstra wrote: > > On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > >> I'm a Perl fan myself. > > I think Python would be a better choice. > Scala anyone? It's probably a long shot, but I would give my vote for any language backed up by an independent standards committee. The standards document is a contract between the language implementor and the coding in that language. It takes a big step away from the "it works for me" mind-set and towards a long-term supportable investment in reliable code. Scheme fits: IEEE 1178-1990, reaffirmed in 2008. Not that I'm any fan of IEEE's copyright behavior. ECMAScript? - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
+1 python. If only it were as easy as voting... On Thu, May 26, 2011 at 3:22 PM, Geoff Swan wrote: > +1 python :) > > On Fri, May 27, 2011 at 4:52 AM, Andrew Poelstra <[1]as...@sfu.ca> > wrote: > > On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > > > Opportunity to pick a more modern language, too. Something more > > os-agnostic, we've had issues with scheme on Windows before. > > > > I'm a Perl fan myself. > > > > Although Perl is probably better for string-handling, I think > Python would be a better choice. It "feels" a lot more like a > Lisp and quite a bit more well-known these days. > It is also platform-agnostic, handles errors more cleanly, > and is usually easier to read. > Having said that, I have only a passing knowledge of both Perl > and Python. > -- > Andrew Poelstra > Email: asp11 at [2]sfu.ca OR apoelstra at [3]wpsoftware.net > Web: [4]http://www.wpsoftware.net/andrew/ > > ___ > geda-user mailing list > [5]geda-user@moria.seul.org > [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > References > > 1. mailto:as...@sfu.ca > 2. http://sfu.ca/ > 3. http://wpsoftware.net/ > 4. http://www.wpsoftware.net/andrew/ > 5. mailto:geda-user@moria.seul.org > 6. 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 > > -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
If you give a 1,000,000 monkeys 1,000,000 typewriters, and give them 1,000,000 years to write stuff, one monkey will eventual write a Java program. The others just produce Perl scripts. I find perl unreadable. Python, Lua, Java, Ruby, ... I like all those types of languages. Isn't there an open source package that supports a bunch of automation with your favorite language (including Guile which would maintain a bunch of backward compatibility)? The main reason I don't like Guile is I find it hard to read and awkward to write in. My vision is not the best and I really get messed up on the parenthesis. Oliver __ From: Colin D Bennett To: geda-user@moria.seul.org Sent: Thu, May 26, 2011 1:18:44 PM Subject: Re: gEDA-user: Task list for: Solving the light/heavy symbol problem On Thu, 26 May 2011 11:52:04 -0700 Andrew Poelstra <[1]as...@sfu.ca> wrote: > On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > > > Opportunity to pick a more modern language, too. Something more > > os-agnostic, we've had issues with scheme on Windows before. > > > > I'm a Perl fan myself. > > > > Although Perl is probably better for string-handling, I think > Python would be a better choice. It "feels" a lot more like a > Lisp and quite a bit more well-known these days. > > It is also platform-agnostic, handles errors more cleanly, > and is usually easier to read. +1 Python -32767 Perl I have written a lot of Perl code over the past 15 years, and still use it for quick one-liner text processing tasks, but even as a novice Python user I must say that my Python code is vastly more maintainable than Perl code. I have found that it always pays off to write clean and readable Python code rather than taking what seems at first to be the easy way and throwing some Perl together. Sure, you *can* write maintainable Perl code, but it takes tremendous effort because there are so many quick shortcuts that tempt the author or Perl code, and there are a million different ways to write the same code -- not necessarily good for maintainability. A project like gEDA would have to have some really tight style guidelines to get consistent and readable Perl code... Regards, Colin ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:as...@sfu.ca 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: Task list for: Solving the light/heavy symbol problem
On 26 May 2011 19:52, Andrew Poelstra wrote: > > Although Perl is probably better for string-handling, I think > Python would be a better choice. It "feels" a lot more like a > Lisp and quite a bit more well-known these days. > +1 for Python from me, even though until very recently I was a Tcl bigot. As an example, it's been at the heart of Blender since the 2.5 rewrite and it works very well indeed. It can be used to write in a functional (to a certain extent) style as well as imperative and object-oriented styles, and the string handling in the standard library is very decent. If there's a prototype/proof-of-principle that needs to be written in Python, I'd be happy to contribute. If it's to be done in Perl, I'm washing my hair that month ;) Cheers Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> Scala anyone? I think the rule for choosing a language, other than "readily available on mac, linux, and windows" is that you can go to pretty much any bookstore and buy an "XYZ for Dummies" for it. And no, we won't use Javascript :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On Thu, May 26, 2011 at 11:52 AM, Andrew Poelstra wrote: > On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: >> >> Opportunity to pick a more modern language, too. Something more >> os-agnostic, we've had issues with scheme on Windows before. >> >> I'm a Perl fan myself. >> > > Although Perl is probably better for string-handling, I think > Python would be a better choice. It "feels" a lot more like a > Lisp and quite a bit more well-known these days. > > It is also platform-agnostic, handles errors more cleanly, > and is usually easier to read. > Scala anyone? It's both functional and procedural, platform agnostic, and is all the rage in some academic circles. ;) http://www.scala-lang.org/ Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On Thu, 26 May 2011 11:52:04 -0700 Andrew Poelstra wrote: > On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > > > Opportunity to pick a more modern language, too. Something more > > os-agnostic, we've had issues with scheme on Windows before. > > > > I'm a Perl fan myself. > > > > Although Perl is probably better for string-handling, I think > Python would be a better choice. It "feels" a lot more like a > Lisp and quite a bit more well-known these days. > > It is also platform-agnostic, handles errors more cleanly, > and is usually easier to read. +1 Python -32767 Perl I have written a lot of Perl code over the past 15 years, and still use it for quick one-liner text processing tasks, but even as a novice Python user I must say that my Python code is vastly more maintainable than Perl code. I have found that it always pays off to write clean and readable Python code rather than taking what seems at first to be the easy way and throwing some Perl together. Sure, you *can* write maintainable Perl code, but it takes tremendous effort because there are so many quick shortcuts that tempt the author or Perl code, and there are a million different ways to write the same code -- not necessarily good for maintainability. A project like gEDA would have to have some really tight style guidelines to get consistent and readable Perl code... Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
+1 python :) On Fri, May 27, 2011 at 4:52 AM, Andrew Poelstra <[1]as...@sfu.ca> wrote: On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > Opportunity to pick a more modern language, too. Something more > os-agnostic, we've had issues with scheme on Windows before. > > I'm a Perl fan myself. > Although Perl is probably better for string-handling, I think Python would be a better choice. It "feels" a lot more like a Lisp and quite a bit more well-known these days. It is also platform-agnostic, handles errors more cleanly, and is usually easier to read. Having said that, I have only a passing knowledge of both Perl and Python. -- Andrew Poelstra Email: asp11 at [2]sfu.ca OR apoelstra at [3]wpsoftware.net Web: [4]http://www.wpsoftware.net/andrew/ ___ geda-user mailing list [5]geda-user@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:as...@sfu.ca 2. http://sfu.ca/ 3. http://wpsoftware.net/ 4. http://www.wpsoftware.net/andrew/ 5. mailto:geda-user@moria.seul.org 6. 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: Task list for: Solving the light/heavy symbol problem
On Thu, May 26, 2011 at 10:56:40AM -0400, DJ Delorie wrote: > > Opportunity to pick a more modern language, too. Something more > os-agnostic, we've had issues with scheme on Windows before. > > I'm a Perl fan myself. > Although Perl is probably better for string-handling, I think Python would be a better choice. It "feels" a lot more like a Lisp and quite a bit more well-known these days. It is also platform-agnostic, handles errors more cleanly, and is usually easier to read. Having said that, I have only a passing knowledge of both Perl and Python. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
2011/5/26 DJ Delorie : >> Maybe we should aim at core gnetlist API being available in libgeda? >> Or in libgnetlist? > > What would this API provide? Would PCB need/want to use it? > I haven't had time to follow all the discussions lately; however, I've long thought that gnetlist should be a very basic API/data structure and a collection of plugins that provide actions that operate on that basic data structure. Something like a basic hierarchy of objects that each have a name and a collection of key/value pairs where values can be other objects. Then a gschem plugin that provides a "LoadGschem(file, [file...])", a database plugin that provides something like "MapPackages(metadata_file)", a guile plugin that provides a "GuileExport(backend)", pcb plugin that provides "CreatePCB()" and "UpdatePCB()", gnucap plugin provides "SaveVerilog()", some XML fan provides "SaveXML()", etc. Then legacy gnetlist behavior becomes a tcl (?) script "LoadGschem(files); Preprocess(<-c argument>); GuileExport(backend);" etc. Just wish I had time to flesh it out (obviously there's a lot of devil in the details) and code up a prototype/proposal to see if it makes sense. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> What is the intended workflow gschem -> PCB in future? gschem \ partdb >-> gnetlist -> action script -> pcb oldpcb / > Currently we have gsch2pcb (gnetlist) and I read that recent PCB can > read gschem schematics direct -- I have no idea how PCB does this, is PCB calls gnetlist. Gnetlist generates an action script which describes the "should be", and PCB updates the layout to match it. > The reason why I am asking: I would like to transfer extended > information from schematics to initial PCB layout, The importer (gnet-pcbfwd.scm) copies any attributes from the schematic to the PCB element already. PCB has some logic for placing new elements, but I don't recall if it does the placement before or after it imports the attributes. It's all in src/action.c (the Import() action). > My intention was to define something like an extended netlist format, > which may contain footprint names and there position and nets with > attributes (width, impedance, length, ...) PCB's netlist already supports a "style" parameter, but nobody uses it at this time. The file format for storing the netlist is similarly limited. However, the new importer doesn't use the old netlist file any more. It's all done with PCB actions - gnetlist builds a script, pcb runs it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On Thu, 2011-05-26 at 11:52 -0400, DJ Delorie wrote: > > Maybe we should aim at core gnetlist API being available in libgeda? > > Or in libgnetlist? > > What would this API provide? Would PCB need/want to use it? > > Unfortunately I was not able to follow all the discussions on this list, so maybe my question is already answered somewhere: What is the intended workflow gschem -> PCB in future? Currently we have gsch2pcb (gnetlist) and I read that recent PCB can read gschem schematics direct -- I have no idea how PCB does this, is PCB using gnetlist, or only parsing the schematics files? (So gnetlist will become obsolete for gschem -> PCB workflow?) The reason why I am asking: I would like to transfer extended information from schematics to initial PCB layout, i.e. position of elements (initial position of footprints should be similar to symbol position in schematics) and optional attributes for each net segment. My intention was to define something like an extended netlist format, which may contain footprint names and there position and nets with attributes (width, impedance, length, ...) Maybe all that is obsolete already -- sometimes development speed is so fast that I can not really follow... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
W dniu 26 maja 2011 17:52 użytkownik DJ Delorie napisał: >> Maybe we should aim at core gnetlist API being available in libgeda? >> Or in libgnetlist? > > What would this API provide? Would PCB need/want to use it? I'm not sure yet - just were trying to think how to provide an option to use multiple scripting languages. Currently backend methods are discovered & loaded by the gnetlist core. That is only possible if scripting language is embedded into executable. If gnetlist became a library, common low-level code & the driving part would be kept there. Backends would then be standalone executables/scripts that would load gnetlist library, register callbacks and kick gnetlist core to start processing. Another way is to provide primitive operations for querying schematics and other data sources and implement whole netlister flow in the backend - depends on the level of freedom/burden we want to have in the scripting layer. -- Krzysztof Kościuszkiewicz "Simplicity is the ultimate sophistication" -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> Maybe we should aim at core gnetlist API being available in libgeda? > Or in libgnetlist? What would this API provide? Would PCB need/want to use it? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
Maybe we should aim at core gnetlist API being available in libgeda? Or in libgnetlist? Then SWIG [1] could be used to provide bindings to multiple scripting languages with relatively low effort. Of course if we want to embed a scripting language (as we currently do) then we need to stick to one choice :) [1] http://www.swig.org/ -- Krzysztof Kościuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: k...@jabster.pl "Simplicity is the ultimate sophistication" -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
DJ Delorie wrote: > I'm a Perl fan myself. +1 (Although I am noob in that language.) ---<)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: Task list for: Solving the light/heavy symbol problem
> Hmm, you make up a long and daunting list which is still missing the > biggest job, bigger than all of the others put together, and then > when I point this out you assign it to me. Thanks a lot ;-) I'm Evil that way :-) Realistically, it's an *excuse* to replace it. Whether you do or not is of course up to you. Replacing it chunk-wise would be just as good. Break it down into sub-tasks and get others to help, like I did. It just seemed that you had the most to say about the gnetlist issues, and the most experience with it, so it makes sense that you should address them. Plus, if you don't do it, who will? > Awhile back, Peter B. told me he was close to reimplementing > gnetlist completely in Scheme. That might be a sensible place to > start. Opportunity to pick a more modern language, too. Something more os-agnostic, we've had issues with scheme on Windows before. I'm a Perl fan myself. > The refactored code is present in 1.7.0. So I think I can continue > to prototype in Scheme. Ah, good point brought up - don't worry about backwards compatibility. We're moving forward here, not fixing bugs, and if users have to bear a little pain to upgrade, it'll be worth it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On May 26, 2011, at 2:05 AM, DJ Delorie wrote: > >> The fundamental problem here is that gnetlist is designed to deliver > > John, I think this is your exuse to rewrite it from scratch "the right > way". As they say, "show us your power". Hmm, you make up a long and daunting list which is still missing the biggest job, bigger than all of the others put together, and then when I point this out you assign it to me. Thanks a lot ;-) Awhile back, Peter B. told me he was close to reimplementing gnetlist completely in Scheme. That might be a sensible place to start. Otherwise, I think I'll look at what I can do with Scheme and the existing front end. I realized last night that the refactoring that failed to fix the argument censorship bug can nevertheless allow a Scheme procedure to gather enough information to figure out the details of the slot assignments (because it can now see all of the slotdef attributes, not just the first one). The refactored code is present in 1.7.0. So I think I can continue to prototype in Scheme. 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: Task list for: Solving the light/heavy symbol problem
> http://www.xilinx.com/support/documentation/user_guides/ug385.pdf Ok, I'll put you down for that one. (in case you hadn't noticed, the rule today is "if you suggest it, you get to do it" ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On Wed, May 25, 2011 at 5:25 PM, Tom Pope wrote: > Just dwelling on the 'what' phase a little more, can we start a few > pages on the wiki for people to list: > > a) all the workflows people would like supported (maybe break it down > into newby GUI workflows, 'power user' GUI workflows and scripted > flows. > b) new features wishlist > c) jobs that need doing (and who's doing them) > > If someone can spell out what's desired I'm happy to help out making > symbol and footprint libraries. One of the things I'd like to see is > to a library containing all(most) of the land patterns for some of the > popular chip vendors eg maxim- > http://www.maxim-ic.com/design/packaging/index.mvp?a=2&f= ,TI > -http://focus.ti.com/lit/an/sbfa015a/sbfa015a.pdf , Atmel etc. http://www.xilinx.com/support/documentation/user_guides/ug385.pdf ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> The fundamental problem here is that gnetlist is designed to deliver John, I think this is your exuse to rewrite it from scratch "the right way". As they say, "show us your power". ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> can we start a few pages on the wiki for people to list: Go for it. > If someone can spell out what's desired I'm happy to help out making > symbol and footprint libraries. At this point, I think "If you want to do it" is the criteria for the heavy libraries. Don't worry about what people want, just do what *you* want. Once we get some experience and critical mass, they'll let us know what they want. > One of the things I'd like to see is to a library containing > all(most) of the land patterns for some of the popular chip vendors > eg maxim- Go for it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
> I don't claim to have any great level of experience in writing APIs > at all - but I have already started some parts db stuff I would like > to continue - put me down against some parts db work. Done! :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
On May 25, 2011, at 3:38 PM, DJ Delorie wrote: > * gnetlist needs the most work. It needs to be able to read a set of > rules, query the database, and fill in additional attributes based > on the rules. This need not be more than just "fill in the blanks" > for now. The fundamental problem here is that gnetlist is designed to deliver certain digests of the design data to the back end. Most of this behavior is "hard-wired" in the gnetlist front end. The little prototype plug-in I posted for mapping package attributes works by intercepting the delivery of the digested data, but that's not a reasonable option for other attributes. So, a prerequisite here is refactoring to remove much of the hard-wired behavior from the gnetlist front end. We need to allow plug-ins to reasonably access all of the data from the schematics, not just the digests (although of course we should keep the digests, too: they're very useful). Once we have that, reading rules is pretty easy: I have already prototyped one representation. But if you start from the top-down, demanding that gnetlist support database access as a built-in "feature", it will be a very big job indeed. I don't think it can ever be done in a satisfactory way from that direction. Refactoring could also enable plug-ins to implement some other things I believe you'd like, such as electrically significant busses. 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: Task list for: Solving the light/heavy symbol problem
Just dwelling on the 'what' phase a little more, can we start a few pages on the wiki for people to list: a) all the workflows people would like supported (maybe break it down into newby GUI workflows, 'power user' GUI workflows and scripted flows. b) new features wishlist c) jobs that need doing (and who's doing them) If someone can spell out what's desired I'm happy to help out making symbol and footprint libraries. One of the things I'd like to see is to a library containing all(most) of the land patterns for some of the popular chip vendors eg maxim- http://www.maxim-ic.com/design/packaging/index.mvp?a=2&f= ,TI -http://focus.ti.com/lit/an/sbfa015a/sbfa015a.pdf , Atmel etc. -Tom Pope ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Task list for: Solving the light/heavy symbol problem
I don't claim to have any great level of experience in writing APIs at all - but I have already started some parts db stuff I would like to continue - put me down against some parts db work. cheers, Geoff On Wed, May 25, 2011 at 4:38 PM, DJ Delorie <[1]d...@delorie.com> wrote: The "what" phase seems to have drawn to a close, so now it's time for the "how" phase. How do we do the things we want to do? What tasks will lead us to the features we want? Here, in no particular order, are the tasks I think we need to undertake to get started (others will come up as we progress). If you were one of the proponents of one of these ideas, it's up to you to make sure it happens. Don't worry about "pretty" - just put together something that shows off the concept, so we can see it in action and evaluate it. We need to create a few small heavy symbol libraries. These are the self-contained "starter" libraries we talked about. Since these do not require any software changes, we should start on these right away. The purpose of these will be to give new users an opportunity to learn the editing tools without having to simultaneously learn how to make a library. These libraries should be packaged such that it's easy for the user to replace the standard library with them, and immediately be productive. gschem and pcb both need to be better at referencing multiple libraries of arbitrary depth. This includes a better way to manage the libraries (gui, config, query rules), enable/disable them, and browse them. This information should be sharable between tools, specifically, at least, between gschem, gnetlist, and pcb. While I do not wish to start a discussion about what kind of data should go in our "metadata", we need tools to work with it. I think that breaks down to the following: * On the database end, design an API or two with which we talk to the data servers. Implement a few servers to see how it works. I've started some ideas at [2]http://www.delorie.com/pcb/component-dbs.html at the "How is the database stored?" text. * In gschem and pcb, we need a way to query the data servers in the attribute editors, in order to suggest attributes. * In gschem and pcb, be able to choose symbols/footprints based on metadata queries - use the metadata as a filter for the library dialog. * gnetlist needs the most work. It needs to be able to read a set of rules, query the database, and fill in additional attributes based on the rules. This need not be more than just "fill in the blanks" for now. gschem, pcb, and the sims need ways to query remote libraries. I suggest HTTP as the protocol, so we can use pretty much any web server out there. Gedasymbols is the obvious candidate, and I can work with whoever does this task to install any needed server-side logic. Someone needs to build a test library where the symbols have symbolic pin names, and the metadata maps those to physical pins in footprints. I suggest using the transistor problem as a basis for this library. Gnetlist will need to be modified to apply the mappings, although for this first step, there's no need to include pin or gate swapping information. Gschem and pcb need a way to swap variants on symbols and footprints, for example, switching between resistor-1 and resistor-2, or RESC1608N and RESC1608M. This depends on the metadata being available (above). Modify gschem's symbol chooser to allow filtering based on attributes within the symbol, not just the symbol name. I think it would be better if, at this point, people choose tasks and develop a quick prototype to (1) see if it works, (2) provide a basis for comparison against other potential solutions. Less talkie, more typie! ;-) Send a reply letting us know what you're working on, to make sure nothing gets left out. It's OK (in fact desirable) to have multiple people working on different solutions to the same tasks, so don't worry if someone else took your favorite. ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. http://www.delorie.com/pcb/component-dbs.html 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
gEDA-user: Task list for: Solving the light/heavy symbol problem
The "what" phase seems to have drawn to a close, so now it's time for the "how" phase. How do we do the things we want to do? What tasks will lead us to the features we want? Here, in no particular order, are the tasks I think we need to undertake to get started (others will come up as we progress). If you were one of the proponents of one of these ideas, it's up to you to make sure it happens. Don't worry about "pretty" - just put together something that shows off the concept, so we can see it in action and evaluate it. We need to create a few small heavy symbol libraries. These are the self-contained "starter" libraries we talked about. Since these do not require any software changes, we should start on these right away. The purpose of these will be to give new users an opportunity to learn the editing tools without having to simultaneously learn how to make a library. These libraries should be packaged such that it's easy for the user to replace the standard library with them, and immediately be productive. gschem and pcb both need to be better at referencing multiple libraries of arbitrary depth. This includes a better way to manage the libraries (gui, config, query rules), enable/disable them, and browse them. This information should be sharable between tools, specifically, at least, between gschem, gnetlist, and pcb. While I do not wish to start a discussion about what kind of data should go in our "metadata", we need tools to work with it. I think that breaks down to the following: * On the database end, design an API or two with which we talk to the data servers. Implement a few servers to see how it works. I've started some ideas at http://www.delorie.com/pcb/component-dbs.html at the "How is the database stored?" text. * In gschem and pcb, we need a way to query the data servers in the attribute editors, in order to suggest attributes. * In gschem and pcb, be able to choose symbols/footprints based on metadata queries - use the metadata as a filter for the library dialog. * gnetlist needs the most work. It needs to be able to read a set of rules, query the database, and fill in additional attributes based on the rules. This need not be more than just "fill in the blanks" for now. gschem, pcb, and the sims need ways to query remote libraries. I suggest HTTP as the protocol, so we can use pretty much any web server out there. Gedasymbols is the obvious candidate, and I can work with whoever does this task to install any needed server-side logic. Someone needs to build a test library where the symbols have symbolic pin names, and the metadata maps those to physical pins in footprints. I suggest using the transistor problem as a basis for this library. Gnetlist will need to be modified to apply the mappings, although for this first step, there's no need to include pin or gate swapping information. Gschem and pcb need a way to swap variants on symbols and footprints, for example, switching between resistor-1 and resistor-2, or RESC1608N and RESC1608M. This depends on the metadata being available (above). Modify gschem's symbol chooser to allow filtering based on attributes within the symbol, not just the symbol name. I think it would be better if, at this point, people choose tasks and develop a quick prototype to (1) see if it works, (2) provide a basis for comparison against other potential solutions. Less talkie, more typie! ;-) Send a reply letting us know what you're working on, to make sure nothing gets left out. It's OK (in fact desirable) to have multiple people working on different solutions to the same tasks, so don't worry if someone else took your favorite. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
