gEDA-user: Python: Task list ...
Hmm, Python seems popular, but my Python capability is limited to: 1. Import a few things 2. Invoke a few things 3. Declare the job finished A bit like: http://xkcd.com/353/ ;-) On May 27, 2011, at 6:33 AM, DJ Delorie wrote: > One vote per patch :-) It seems to me that the first step to switching languages here is for somebody to: 1. Define a mapping of the .sch/.sym file format into a data structure. 2. Implement a parser that reads a file into such a structure. I don't think this is a job for a committee. One we have this, though, we can all start playing. Any volunteers to do this in Python? 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: Fixing the attribute censorship bug
Based on feedback from Kai-Martin, here's an improved version: censor-fix.scm Description: Binary data On May 26, 2011, at 4:58 PM, John Doty wrote: > Folks, > > The "attribute censorship bug" is what I call the problem that given a refdes > that corresponds to multiple symbol instances, gnetlist only looks for > attributes from the first instance it finds, ignoring the rest. One common > place this causes trouble is in footprints for slotted components: if the > footprints on the different slots don't agree, or if the footprint is missing > from the first instance, the result may not be what the user intended. > > The latest development release (1.7.0) has the capability to detect this > problem, and it works in the case of an attribute that is consistent, but > perhaps not present on all instances. In the case of conflicting attributes > all it does is issue a warning, and otherwise repeats the old behavior. I > don't think this constitutes a complete fix: the wrong attribute may still > show up in the output. > > The attached script not only emits a message, but substitutes > "attribute_conflict" for the attribute in question. Since that's not normally > a legitimate value, it should help the user to detect the problem. > > Usage: > > gnetlist -m censor_fix.scm (other gnetlist args) > > I haven't tested it much, so please report any problems. And, of course, > you're welcome to change its behavior to suit your flow. It requires at least > version 1.7.0. > > > > 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 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
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: File format change needed for metric conversion
Andrew Poelstra wrote in geda.devel: > But what is our plan for allowing backward compatibility? > It isn't really difficult to output in the old format (just > giving a different spec to pcb_printf) so we should give > the user an option to do this. Since mortal users like me are not allowed to post to geda devel, I'll throw in my 2 eurocent here in geda.user: Please try to make format bumps so, that it is still possible to share geda/pcb documents in a heterogeneous environment. That is, in an environment where some of the users go with bleeding edge versions from git, while others go with the package their distro provides. This may be achieved with an option to save in old format. Or there may be an external conversion script to turn the new file format into the old format. If this means that some features of the new PCB version won't survive the conversion, then issue a warning and convert anyway. The user of bleeding edge PCB may avoid these features if compatibility with older versions is needed. An example for such a feature is the holes in polygons recently added to PCB format. Backward incompatibility hit me unsuspecting a few months ago, when I tested the improved grid patch. A quick test with a dummy project looked promising. So I started using it for real world projects. It was a royal pain to get the modified layouts back into old style format. If the bleeding edge version of PCB produces files my colleagues can't open, then I can't use it for day to day work. My testing will be casual at best. ---<)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: file format documentation formatting in the wiki
Ethan Swint wrote: > $0.02 request/opinion from me: a keyword, rather than a number, so that > arguments can be optional and more-human readable? > Well, the current file format of gschem relies entirely on positional parameters. I was just dealing with the documentation. The positional parameters is a design decision that comes with pros and cons. There have been suggestions to get rid of positional parameters and implement a new format that is more like named attributes in symbols. Some ideas have been tossed, but nothing definitive has grown from this. ---<)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: Two things ... or actually, three
> I'd really like to contribute something back -- but as I'm not really a > proficient coder Contributions come in other forms, Certainly, library work and documentation are sorely in need of contributors and even owners. If you read the light/heavy thread, you'll see I just put out a call for folks to put together sample self-contained heavy libraries, those can be as small as one component (although something big enough to be a 'starter library' would be better). As a new user with experience (huh?) documentation might be a good place to contribute too, pick a chunk of one of the manuals and replace it with something modern, for example. Or find an old tutorial and update it to match the current tools. In any event, don't feel that you have to be a code guru to help out, and don't wait for an invitation - pick something you can do and do it. > - Zero length lines in PCB: I found that when drawing lines in PCB, I think you're tripping over the metric-rouding bug, where what you're seeing is lines that are 0.01 mil long. We're working on that with the metrification of PCB. > Now I was used to the work flow of gschem -> [update pcb in] xgsch2pcb > -> PCB, but this appears to have changed. It's still available, there are now alternate ways that are more integrated, that's all. > I wondered if someone could explain this in a few words. gsch2pcb, xgsch2pcb, and pcb's File->Import all do the same thing - they run gnetlist. In all three cases, *someone* needs to know which schematics are read, and which layout is updated. The File->Import case is different in that the list of schematics you need, is stored in the layout that needs them, and PCB is running the process so it knows that it also needs to read the new info and update the board. Look at the documentation for the Import() action in the PCB reference, it tells you what needs to be added to the layout to store this information. There are menu options for editing "layout attributes", which is where they go. > Do I also need a newer gschem version? No. The gnetlist backend is part of pcb, just make sure it gets installed with the other netlisters. > And has anything changed with regard to custom created symbols and > footprints (as in: how do I make the new gschem and PCB versions > aware of their existence?). You need to make *PCB* aware of your footprint paths. Use the Preferences dialog to set these paths, and check them with the Library window (if they show up in the Library window, the import will work) > Anyway, thanks once again, and please tell me if e.g. footprints or > symbols I created are welcome (and where I can send these). Email me privately and I'll set you up with a gedasymbols.org account. ___ 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: Two things ... or actually, three
> Then two more usage questions:
> - Zero length lines in PCB: I found that when drawing lines in PCB,
> sometimes dots (zero length lines) get created inadvertently on corners
> and bends. This isn't much of a problem, until I start dragging lines
> and end points in rubber band mode: those dots then get stretched into
> undesired line segments which I sometimes don't notice until I get DRC
> errors and warnings about short circuits.
> Do I recall correctly that someone created a script to filter out those
> zero-length lines? I can't find anything in the mailing list archives,
> and it turns out that a regex recognizing Line[X Y X Y ... ] doesn't
> seem all that trivial to construct.
These *may* be fixed up by "Connects -> Optimize routed tracks ->
simple optimization". Use this feature with care - it usually removes
zero length lines but occasionally it also erases needed trace
segments by mistake. I recommend saving first and performing DRC
check and net connectivity check ("o" key) both before and after,
checking for any changes - there /should/ be none.
The trace optimizer only touches autorouted tracks by default - if you
want it to work on manually routed traces you need to clear the
"Connects -> Optimize routed tracks -> [/] Only autorouted nets"
checkbox.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Two things ... or actually, three
Hello all, First of all, I would like to express a huge "thank you" to all the people who built and contributed to gEDA. I recently finished a largish project with hundreds of devices and thousands of nets, and I got the work done without a hitch. I find that gschem, PCB and other gEDA building blocks are amazingly powerful tools. I'd really like to contribute something back -- but as I'm not really a proficient coder (otherwise I wouldn't be asking the question below), simple things like symbols and footprints is all I can think of. And oh, I can do translations. Suggestions are welcome, although I probably won't get round to spending much time on anything until this summer. Then two more usage questions: - Zero length lines in PCB: I found that when drawing lines in PCB, sometimes dots (zero length lines) get created inadvertently on corners and bends. This isn't much of a problem, until I start dragging lines and end points in rubber band mode: those dots then get stretched into undesired line segments which I sometimes don't notice until I get DRC errors and warnings about short circuits. Do I recall correctly that someone created a script to filter out those zero-length lines? I can't find anything in the mailing list archives, and it turns out that a regex recognizing Line[X Y X Y ... ] doesn't seem all that trivial to construct. - Work flow of newer gschem/PCB version: until recently, I worked with an older PCB version (20080202), but I finally got round to compiling and installing the latest version -- and it's quite an improvement (no more disappearing crosshairs, outlines and other GUI imperfections). Now I was used to the work flow of gschem -> [update pcb in] xgsch2pcb -> PCB, but this appears to have changed. Now I think I can find out by myself, but being a lazy person, I wondered if someone could explain this in a few words. Do I also need a newer gschem version? And has anything changed with regard to custom created symbols and footprints (as in: how do I make the new gschem and PCB versions aware of their existence?). Anyway, thanks once again, and please tell me if e.g. footprints or symbols I created are welcome (and where I can send these). I could also put them online on my own server, although I'd first like to add descriptions and (pointers to) manufacturers' datasheets, so that it's clear what part a particular symbol or footprint actually refers to. Best regards, Richard Rasker ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Fixing the attribute censorship bug
Folks, The "attribute censorship bug" is what I call the problem that given a refdes that corresponds to multiple symbol instances, gnetlist only looks for attributes from the first instance it finds, ignoring the rest. One common place this causes trouble is in footprints for slotted components: if the footprints on the different slots don't agree, or if the footprint is missing from the first instance, the result may not be what the user intended. The latest development release (1.7.0) has the capability to detect this problem, and it works in the case of an attribute that is consistent, but perhaps not present on all instances. In the case of conflicting attributes all it does is issue a warning, and otherwise repeats the old behavior. I don't think this constitutes a complete fix: the wrong attribute may still show up in the output. The attached script not only emits a message, but substitutes "attribute_conflict" for the attribute in question. Since that's not normally a legitimate value, it should help the user to detect the problem. Usage: gnetlist -m censor_fix.scm (other gnetlist args) I haven't tested it much, so please report any problems. And, of course, you're welcome to change its behavior to suit your flow. It requires at least version 1.7.0. censor-fix.scm Description: Binary data 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
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: Solving the light/heavy symbol problem
This post kind of blew out a bit - TLDR version - I have a database idea that may be helpful in the pin swapping under discussion. The database would provide a device representation that captures *everything*. The database would help inform the pin swapping decision process rather than provide any gEDA plugin automation. It would be a standalone tool (at this stage). long version... I have some thoughts on this - as my original reason for starting a database for managing symbols and components was trying to come up with some sane method of capturing all possible configurations of an ARM chip while only displaying those that are currently in use in the schematic. I am not convinced that the schematic is the correct place to capture the full detail of all possible functional variations of a symbol, otherwise the component symbol becomes bloated or split into many many subcomponents either of which is likely to be unreadable or obfuscated. I want a schematic that describes succinctly what the design is intended to do. I *do* however need to have some representation somewhere that captures what a device is capable of so that I can implement the design as easily as possible - the idea is to not have to manually create a new component symbol by hand for each design variation. Pin/function swapping to enable better routing I think *has* to be a fairly user involved process - although I suppose in theory it may be somewhat possible to tie into an autorouter of some description... - but would it be possible to have a second class of rats nest that is one link per function? - ie 1 point to point line to indicate a data bus path etc - or just colored rats-nest where common function nets are color coded I think DJs description of pin swapping makes sense - it seems like a more complete version of slotting. In the design I have been working on recently, I used a slotted resistor package. The process for changing which device was used was actually very easy with the 'import schematic option'. I had the schematic and layout open side by side - hover the mouse over the footprint to determine the net - then swap the slot in the schematic and hit import schematic - then 'O' in PCB to refresh the rats nest. This was quite pleased at the efficiency, and pushing the design flow from schematic to layout makes sense to me. I could be handy to be able to pull some schematic information from the PCB, however how you indicate the change to the net from pcb is beyond me. (I don't think laying copper would be correct - what if you had an accidental short somewhere?) More on the capturing of functional component information - my current plan is to create an entirely self sufficient database of component information. This would redefine the concept of a device to encompass all possible variations of the device. (noting that not all of them are required for a device description to be useful) Eg, * A logical device is made up of a number of logical pins (one pin may exist across a number of device packages/footprints) * A logical pin can be tied to a number of functions (eg UART-TX, SPI-MOSI) * A function can be grouped in a functional class (eg UART) * A physical-device is defined by joining a device, footprint and pinout * The pinout mapping allows a logical pin to be defined once and remapped across multiple packages - ie DIP, SOIC, QFN * Functional class awareness allows a package with multiples of the same function to be swapped with a degree of automation, including grouping pins that together form a functional group (ie a data or address bus, a serial port etc) * Pins and functions are somewhat separated - so it's easy to handle the situation where UART1_TX can be on pin 15, or pin 47. * This allows for the possibility of remapping a generic UART function between UART_1 and UART_2, along with the option of configuring UART_1 to use pins 15 and 16, or pins 47 and 48. This concept does not in any way replace DJs description of pin swapping - this is more about the capture of information than the mechanics of an implementation at this stage. I think I have the bulk of the database schema worked out, with a few minor details about some of the linkages to finalize - the harder part is providing a workable interface to the information. Particularly an efficient way to capture and describe the information in the first place, and then methods of manipulation and output. My initial thoughts are to have some of the information captured from a spreadsheet - this is most likely the easiest way to enter the data that is read from a datasheet - this can then be pulled into the database (similar to tragesym I suppose). The next issue is then view and manipulating the data - again my first pass would be to
