Re: gEDA-user: Design Flow Roadmap starting point
On Fri, 16 Mar 2007, John Griessen wrote: >John Griessen wrote: >> So, "What do you want? > Please add this to the list: [PCB] an interface for presenting dynamic dialog boxes for importers and wizards similar to the exporters. This would help some plugins to integrate better in the GUI. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> S2/S2/L1 S2/S2/C1 and S2/S2/U1 > > is the RenumberBlock funtion capable of this? It currently pulls the last string of digits (suffix) off for renumbering, but pulling the first string shouldn't be too hard. It doesn't give you automatic updating, though. If you edit the master block, you'd cut out the copies, and re-copy/renumber the master block to make new copies. We could script this if we had an action to select a region, but it would certainly be better if it "just knew" about such blocks. > Because when you use those virtual 01005 capcitors there isn't a lot > of room for a readable refdes as it is Too true. I didn't even bother with a silkscreen on the furnace board, and that's only 0603s. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
DJ Delorie wrote: >> From PCB, I would like to seperate the hierarchy from the rest of >> the refdes. I would like to be able to layout a hierarchical >> section. I would like to be able to save that section as a seperate >> collection. I would like to be able to paste a copy of that section >> into a larger pcb layout and only have to change the top of >> hierarchy string to correctly interact with the netlist. >> > > PCB doesn't care what the refdes is, a heirarchical one is just as > valid as a common one. I have a RenumberBlock() action that's > designed to make it easier to have repetetive blocks on a board, but I > think you want something more automatic, like the way element data is > grouped as an element. For example, have a block on the board that is > a modular entity. Normally, you can't do anything but move it around > as a whole. A special action "opens" this block (and hides everything > else) so you can edit it. When you're done, it's closed again - and > any copies of the block are automatically updated in place. > > The usual buffer to/from file mechanism should be sufficient > (gui-wise) for saving blocks as files. > > Have you tried using Xfig's group/ungroup/editgroup mechanism? > > > An example of what I was thinking is If I have the following hierarchical refdess S1/S2/L1 and S1/S2/C1 and S1/S2/U1 The hierarchy is S1/S2 the non hierarchy refdes are L1, C1 and U1 I would like to replicate this block and just have to edit once the hierarchy to S2/S2 giving the full hierarchy + refdes to be S2/S2/L1 S2/S2/C1 and S2/S2/U1 is the RenumberBlock funtion capable of this? Plus I would like to be able to say to that block Don't display the hierarchy in the silkscreen. Because when you use those virtual 01005 capcitors there isn't a lot of room for a readable refdes as it is ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> Yes fab shops can cnc the layers before gluing and pressing them > together. Drool. Yeah, you'd need the "layer types" patch to really manage that, as you'd be able to tag multiple pcb layers as "outline" layers and associate them with specific board layers or whatnot. You could do it now, except that they'd have all the pins' copper on them as well as the outline. The only thing you can't do already is tell pcb to put elements on inner layers. Of course, I'm curious *why* you need to recess parts... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
>> While I am at it. PCB should be able to do hidden vias, buried vias >> and micro vias... >> > > If we can get the "layer types" project done (this is listed as the > non-copper layers project in SoC), we'll be able to have a concept of > a "layer stack" (unless we just assume the physical stack matches the > GUI layer layout). > > The next project after that is what I call a "multi-pin", which is a > standard pin, but with a much more intense copper description, one for > each layer, with drill depth parameters et al. That would include > blind and buried vias. Microvias is just a drill size after that, > unless you need them called out in a different .cnc file > > No a micro via should be the same in the the cnc file. The PCB fab shop will deside how to drill the hole. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
DJ Delorie wrote: > > >> Did I mention the ability to cut out areas of >> layers such that I can resese components into lower layers? >> > > Assuming you know a fab that can mill layers before assembling > them... is that what you're talking about? That would mean having > elements and pads on layers other than the outer two, yes? > > Yes fab shops can cnc the layers before gluing and pressing them together. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
> From PCB, I would like to seperate the hierarchy from the rest of > the refdes. I would like to be able to layout a hierarchical > section. I would like to be able to save that section as a seperate > collection. I would like to be able to paste a copy of that section > into a larger pcb layout and only have to change the top of > hierarchy string to correctly interact with the netlist. PCB doesn't care what the refdes is, a heirarchical one is just as valid as a common one. I have a RenumberBlock() action that's designed to make it easier to have repetetive blocks on a board, but I think you want something more automatic, like the way element data is grouped as an element. For example, have a block on the board that is a modular entity. Normally, you can't do anything but move it around as a whole. A special action "opens" this block (and hides everything else) so you can edit it. When you're done, it's closed again - and any copies of the block are automatically updated in place. The usual buffer to/from file mechanism should be sufficient (gui-wise) for saving blocks as files. Have you tried using Xfig's group/ungroup/editgroup mechanism? > I would like to be able in the netlist to tell pcb which slots are > swapable, which i/o pins are swapable and which pin pairs can > function as differential pairs (these last two have to be able to be > limited to specific banks) such that pcb could correctly change the > net list itself. Then I would like PCB to be able to tell me what > pins and in what order the pins were swapped so that this could be > imported back into the original design. This is the usual back-annotation request, for starters. If we can propogate the slotting information to pcb, perhaps we can figure out a GUI to swap them. > While I am at it. PCB should be able to do hidden vias, buried vias > and micro vias... If we can get the "layer types" project done (this is listed as the non-copper layers project in SoC), we'll be able to have a concept of a "layer stack" (unless we just assume the physical stack matches the GUI layer layout). The next project after that is what I call a "multi-pin", which is a standard pin, but with a much more intense copper description, one for each layer, with drill depth parameters et al. That would include blind and buried vias. Microvias is just a drill size after that, unless you need them called out in a different .cnc file. > Did I mention the ability to cut out areas of > layers such that I can resese components into lower layers? Assuming you know a fab that can mill layers before assembling them... is that what you're talking about? That would mean having elements and pads on layers other than the outer two, yes? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
>From PCB, I would like to seperate the hierarchy from the rest of the refdes. I would like to be able to layout a hierarchical section. I would like to be able to save that section as a seperate collection. I would like to be able to paste a copy of that section into a larger pcb layout and only have to change the top of hierarchy string to correctly interact with the netlist. I would like to be able in the netlist to tell pcb which slots are swapable, which i/o pins are swapable and which pin pairs can function as differential pairs (these last two have to be able to be limited to specific banks) such that pcb could correctly change the net list itself. Then I would like PCB to be able to tell me what pins and in what order the pins were swapped so that this could be imported back into the original design. While I am at it. PCB should be able to do hidden vias, buried vias and micro vias... Did I mention the ability to cut out areas of layers such that I can resese components into lower layers? Finaly I could use all of these by, . say next Tuesday. "I'd gladly pay you Tuesday for a hamberger today" Thanks, Steve M. John Griessen wrote: > John Griessen wrote: >> So, "What do you want? > > The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned > recently and needing discussion are: > > Steve Meier: > 1) hierarchical data and file structures (xml or other) > 2) an integrated hierarchical netlister > 3) use of a better supported scripting language > 4) a method of dynamically partioning devices into meaningfull symbols > 5) a method of communicating between the schematic design and the layout > program on issues of slot swapping, i/o pin swapping, differential i/o > pin swapping, bank swapping > 6) strong drc > > > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > > the refdes and create a large box on the silkscreen which is labled S1. > > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > > inside ths S2 box an even smaller box labled S3. The device inside the > > S3 box will have a silk screened comment near it that states U3. > > Svenn Are Bjerkem wrote: (about geda installer)jg > For real day-to-day work the engineer should be > able to decide himself what tool he wants to use > it should be enough to > run a command to have it installed. > > On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about > multiple flows)jg > > I think designing the tool up front to explicitly deal with and support > > 2 different back end flows (layout and simulation in this case) is very > > important. Presumably that will be a good vehicle to making sure it > can > > extend to many back end flows. > > David Baird wrote: (about data tie ins to higher abstractions > than "just boards")jg > I've been thinking (maybe just dreaming?) about an extensible system > which > allows the representation of information which has not yet even been > envisioned, while also providing forwards and backwards compatibility > as new component representations are devised. For these reasons, OWL > struck me somewhat and now I am learning OWL and trying to see if I > can really make it do what I want. -- A simple example -- convey to a > PCB program that a set of nets are actually grouped > > together to form the address bus of a microprocessor system. > > Dan McMahill wrote: (about using gnetman work already done to get > hierarchy )jg > I guess what I'd hate to see is a lot of work put into improving > gnetlist (which needs improving) > only to find that the underlying database structure and methods for > accessing it still > aren't complete enough, fast enough, or scalable enough. > > Stuart Brorson wrote: > The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would they look? > Right now, the main data structure for a schematic is a linear linked > list of graphical objects (for each schematic page). Some list items > point to others (i.e. to support component attributes). How would that > change to support hierarchy? > > * ONce a datastructure is decided upon, then what does the file > format look like? Note that our current file format maps fairly > closely onto the internal data structures. Preserving this close > mapping is a desirable goal. Therefore, the data structures defining > hierarchy should more-or-less dictate what the file format should look > like. > > * How should gschem behave once hierarchy is architected in? Right > now you attach a source= attribute to a symbol. Then you do > "schematic down" on that symbol to dive into the sub-schematic. Is > that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a sub-schematic > which I instantiate four times, how should it be refdesed in the > netlist? If I dive into one of the four instantiations and edit it, > is it OK that the other three instantiations are also updated. >
Re: gEDA-user: Design Flow Roadmap starting point
John Griessen wrote: Dan McMahill wrote: (about using gnetman work already done to get hierarchy )jg I guess what I'd hate to see is a lot of work put into improving gnetlist (which needs improving) only to find that the underlying database structure and methods for accessing it still aren't complete enough, fast enough, or scalable enough. and just to clarify, this is a reason to use the gnetman database as opposed to one designed by one of us. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
John, Keep this up and we are not only going to think you are paying attention but that you are taking notes as well. Steve Meier John Griessen wrote: > John Griessen wrote: >> So, "What do you want? > > The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned > recently and needing discussion are: > > Steve Meier: > 1) hierarchical data and file structures (xml or other) > 2) an integrated hierarchical netlister > 3) use of a better supported scripting language > 4) a method of dynamically partioning devices into meaningfull symbols > 5) a method of communicating between the schematic design and the layout > program on issues of slot swapping, i/o pin swapping, differential i/o > pin swapping, bank swapping > 6) strong drc > > > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > > the refdes and create a large box on the silkscreen which is labled S1. > > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > > inside ths S2 box an even smaller box labled S3. The device inside the > > S3 box will have a silk screened comment near it that states U3. > > Svenn Are Bjerkem wrote: (about geda installer)jg > For real day-to-day work the engineer should be > able to decide himself what tool he wants to use > it should be enough to > run a command to have it installed. > > On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about > multiple flows)jg > > I think designing the tool up front to explicitly deal with and support > > 2 different back end flows (layout and simulation in this case) is very > > important. Presumably that will be a good vehicle to making sure it > can > > extend to many back end flows. > > David Baird wrote: (about data tie ins to higher abstractions > than "just boards")jg > I've been thinking (maybe just dreaming?) about an extensible system > which > allows the representation of information which has not yet even been > envisioned, while also providing forwards and backwards compatibility > as new component representations are devised. For these reasons, OWL > struck me somewhat and now I am learning OWL and trying to see if I > can really make it do what I want. -- A simple example -- convey to a > PCB program that a set of nets are actually grouped > > together to form the address bus of a microprocessor system. > > Dan McMahill wrote: (about using gnetman work already done to get > hierarchy )jg > I guess what I'd hate to see is a lot of work put into improving > gnetlist (which needs improving) > only to find that the underlying database structure and methods for > accessing it still > aren't complete enough, fast enough, or scalable enough. > > Stuart Brorson wrote: > The discussion about hierarchy should focus on the > following points: > > * What kind of data structures are desirable? How would they look? > Right now, the main data structure for a schematic is a linear linked > list of graphical objects (for each schematic page). Some list items > point to others (i.e. to support component attributes). How would that > change to support hierarchy? > > * ONce a datastructure is decided upon, then what does the file > format look like? Note that our current file format maps fairly > closely onto the internal data structures. Preserving this close > mapping is a desirable goal. Therefore, the data structures defining > hierarchy should more-or-less dictate what the file format should look > like. > > * How should gschem behave once hierarchy is architected in? Right > now you attach a source= attribute to a symbol. Then you do > "schematic down" on that symbol to dive into the sub-schematic. Is > that OK? Or what's a better scheme? > > And how to handle re-use blocks? That is, if I have a sub-schematic > which I instantiate four times, how should it be refdesed in the > netlist? If I dive into one of the four instantiations and edit it, > is it OK that the other three instantiations are also updated. > > A list of use-cases would be helpful here. > > * Similarly, how should gnetlist behave? A use-case list would be > useful. > > * Finally, how should PCB behave with a hierarchical schematic? > > > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Design Flow Roadmap starting point
John Griessen wrote: So, "What do you want? The gschem gnetlist PCB gsch2pcb gattrib gerbv wants mentioned recently and needing discussion are: Steve Meier: 1) hierarchical data and file structures (xml or other) 2) an integrated hierarchical netlister 3) use of a better supported scripting language 4) a method of dynamically partioning devices into meaningfull symbols 5) a method of communicating between the schematic design and the layout program on issues of slot swapping, i/o pin swapping, differential i/o pin swapping, bank swapping 6) strong drc > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide > the refdes and create a large box on the silkscreen which is labled S1. > Then inside the S1 Box, a smaller box on the silcrean labled S2 and > inside ths S2 box an even smaller box labled S3. The device inside the > S3 box will have a silk screened comment near it that states U3. Svenn Are Bjerkem wrote: (about geda installer)jg For real day-to-day work the engineer should be able to decide himself what tool he wants to use it should be enough to run a command to have it installed. On 3/4/07, Dan McMahill <[EMAIL PROTECTED]> wrote:(about multiple flows)jg > I think designing the tool up front to explicitly deal with and support > 2 different back end flows (layout and simulation in this case) is very > important. Presumably that will be a good vehicle to making sure it can > extend to many back end flows. David Baird wrote: (about data tie ins to higher abstractions than "just boards")jg I've been thinking (maybe just dreaming?) about an extensible system which allows the representation of information which has not yet even been envisioned, while also providing forwards and backwards compatibility as new component representations are devised. For these reasons, OWL struck me somewhat and now I am learning OWL and trying to see if I can really make it do what I want. -- A simple example -- convey to a PCB program that a set of nets are actually grouped > together to form the address bus of a microprocessor system. Dan McMahill wrote: (about using gnetman work already done to get hierarchy )jg I guess what I'd hate to see is a lot of work put into improving gnetlist (which needs improving) only to find that the underlying database structure and methods for accessing it still aren't complete enough, fast enough, or scalable enough. Stuart Brorson wrote: The discussion about hierarchy should focus on the following points: * What kind of data structures are desirable? How would they look? Right now, the main data structure for a schematic is a linear linked list of graphical objects (for each schematic page). Some list items point to others (i.e. to support component attributes). How would that change to support hierarchy? * ONce a datastructure is decided upon, then what does the file format look like? Note that our current file format maps fairly closely onto the internal data structures. Preserving this close mapping is a desirable goal. Therefore, the data structures defining hierarchy should more-or-less dictate what the file format should look like. * How should gschem behave once hierarchy is architected in? Right now you attach a source= attribute to a symbol. Then you do "schematic down" on that symbol to dive into the sub-schematic. Is that OK? Or what's a better scheme? And how to handle re-use blocks? That is, if I have a sub-schematic which I instantiate four times, how should it be refdesed in the netlist? If I dive into one of the four instantiations and edit it, is it OK that the other three instantiations are also updated. A list of use-cases would be helpful here. * Similarly, how should gnetlist behave? A use-case list would be useful. * Finally, how should PCB behave with a hierarchical schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: New section on geda wiki: Design Flow Roadmap
It's not got much yet, http://geda.seul.org/wiki/geda:design_flow_roadmap but I will add email excerpts as we discuss wants mentioned in the "Flame about XML" and "hierarchy issues and other rants" threads recently, but put in terms of how we do designs, not how we might implement it. In other words define "it" first. As DJ said, "What we need from you folks, the users, is a description of what functionality you need and why, so that we can find the best way to get there. Telling us "you need XML" doesn't help, we can write a converter to XML and "have XML" without solving your problem." So, "What do you want? John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: XML file formats .... was: Re: gEDA-user: Some footprints I tried to create
On Mar 15, 2007, at 8:32 AM, Evan Lavelle wrote: However, I ended up implementing a flat, lexer-only solution, which of course is possible only with reverse polish notation. So, if you need a *small*, truely extensible (trivial, even), and easy to write parser, that doesn't require even more complexities like bison/yacc (not all platforms have them), then you might want to consider the RPN option as well. A lexer just tokenises an input stream for you; it matches the input against a set of regular expressions that you specify, and lets you execute some code when it finds a match. You could, in principle, implement an RPN (postfix) calculator using something like lex, by just pushing matched tokens onto a stack and popping them off when you match an operator. IMHO, though, this would be pretty pointless. You might just as well match "a + b" or "+ a b" and make a note to carry out evaluation one or two tokens after the '+', instead of immediately. This then gives you an infix or a prefix calculator, rather than a postfix one. There's nothing special about the RPN case - it's just marginally easier to implement, at the expense of readability. In practice, it's trivial (and normal) to just pass the matched tokens to a parser such as yacc, which lets you check the structure of the input, recover from errors, distinguish unary from binary operators, evaluate complex expressions with precedence and associativity, and so on. It's very difficult to build any smarts into a lexer-based solution, but easy when you've got a parser on top. Where RPN is useful is where you have (very) simple stack-based hardware, hence the usage in calculators. Evan Using the standard Unix compiler development tools for a Forth is swatting fles with a cannon. John Doty Noqsi Aerospace, Ltd. [EMAIL PROTECTED] ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: XML file formats .... was: Re: gEDA-user: Some footprints I triedto create
On Mar 15, 2007, at 5:46 PM, Greg Cunningham wrote: On Thu, 2007-03-15 at 07:34 -0400, David Kerber wrote: Can you point me to a link on how this works? I use an RPN calculator, but never heard that term applied to data storage/configuration/ however you describe what you are doing here. Dave ... http://www.forth.org/faq/faq1.txt http://en.wikipedia.org/wiki/Charles_H._Moore http://www.amresearch.com/starting_forth/sf1/sf1.html Forth is one of the early(iest?) RPN TILs (Threaded Interpretive Languages). Attempting to master it absorbed a year or 2 of my youth. Despite my fascination for RPL languages & stack parsers, I have produced zilch with them... There's a GPL development system I wrote for a very simple Forth dialect (LSE64) at http://space.mit.edu/home/jpd/. I actually use it a lot in conjunction with gEDA. I test hardware with a Linux box full of DAQ cards using test programs in LSE64 (through drivers from comedi.org). Some of the things I design are microprogrammed: the microcode generation is in LSE64. I also use it for generating test vectors for circuit simulations. Some of my customers have been using it also, especially the DAQ and microcode generation stuff. The problem with using something like Forth for data file exchange is that it's dangerously powerful. Virus writers could have a lot of fun. Perhaps one could remove some features and add checks for illegal data access, but it would probably require some serious care. John Doty Noqsi Aerospace, Ltd. [EMAIL PROTECTED] ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GTK Layer controls
Stephen Williams wrote: I try to move one of the existing layers out of the group that it is in to a group of its own (I'm trying to create a ground plane) but it doesn't stick. [EMAIL PROTECTED] wrote: > The radio button selects the layer for new lines, polygons, text, > and thermals. [jg]And after setting the new layer, and selecting a set of lines, you can excute movetolayer by a bind key to change the layer of the whole group of objects. John G ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Re: Flame about XML
Svenn Are Bjerkem <[EMAIL PROTECTED]> wrote: > actually come from UK. (I recognize from the mail adress that Levente > may not be from the US). That is true. I'm from EU. :-) > I am a bit frustrated because everytime XML show up in topics, there > are some opinions and then there is nothing but hardware talk. > -- Levente http://web.interware.hu/lekovacs ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GTK Layer controls
Steve - On Fri, Mar 16, 2007 at 10:39:28AM -0700, Stephen Williams wrote: > Are the Layers controls dialog box buttons connected to anything? > I try to move one of the existing layers out of the group that it > is in to a group of its own (I'm trying to create a ground plane) > but it doesn't stick. It's as if the radio button of the group > select are not connected to anything. The radio button selects the layer for new lines, polygons, text, and thermals. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB GTK Layer controls
Are the Layers controls dialog box buttons connected to anything? I try to move one of the existing layers out of the group that it is in to a group of its own (I'm trying to create a ground plane) but it doesn't stick. It's as if the radio button of the group select are not connected to anything. -- Steve Williams"The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where are the bugs databases?
> I suggest a page just for links to the bugs databases that includes > a 1 line description of what parts of geda goes for each. pcb's bugs, feature requests, etc; go to pcb's sourceforge tracker: http://sourceforge.net/tracker/?group_id=73743 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hi.... first post
Great. How do I ask Ales for a login? Got it. ahvezda at geda.seul.org. Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where are the bugs databases?
Hi Steve, On 3/16/07, Stephen Williams <[EMAIL PROTECTED]> wrote: I'm fiddling with gschem/gattrib/gsch2pcb/pcb and find that I may want to report bugs. What I need now, though, is a place front and center that has links to the various bug reporting databases. I know that there are a few on sourceforge, but there is nothing written (other then mailing list lore) saying where they are and what their boundaries are. The bug trackers on sourceforge are the ones to use. To summarize: All bugs for anything in gEDA/gaf http://sourceforge.net/tracker/?group_id=161080&atid=818426 All feature requests for gEDA/gaf: http://sourceforge.net/tracker/?atid=818429&group_id=161080&func=browse All patches for gEDA/gaf: http://sourceforge.net/tracker/?atid=818428&group_id=161080&func=browse I suggest a page just for links to the bugs databases that includes a 1 line description of what parts of geda goes for each. There is also: http://geda.seul.org/developer.html which lists the bug databases as well as: http://geda.sourceforge.net/ But these don't spell things out that explicitly. I'll add some text. And on that note, where do I report bugs in gsch2pcb? Yeah, please file into the bug, feature, or patch tracker listed above. Thanks, -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hi.... first post
I just asked Ales for a http://geda.seul.org/wiki login. It's for the gEDA suite Great. How do I ask Ales for a login? Tarun ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where are the bugs databases?
Stephen Williams wrote: I suggest a page just for links to the bugs databases that includes a 1 line description of what parts of geda goes for each. How about on the geda wiki? I'll write it up after I get my login there. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Where are the bugs databases?
I'm fiddling with gschem/gattrib/gsch2pcb/pcb and find that I may want to report bugs. What I need now, though, is a place front and center that has links to the various bug reporting databases. I know that there are a few on sourceforge, but there is nothing written (other then mailing list lore) saying where they are and what their boundaries are. I suggest a page just for links to the bugs databases that includes a 1 line description of what parts of geda goes for each. And on that note, where do I report bugs in gsch2pcb? -- Steve Williams"The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hi.... first post
C P Tarun wrote: I have read perhaps 100 A4-sized pages of text on gschem and pcb and the connection between the two, by going through the info pages for PCB and online tutorials and FAQs. And I remember feeling very uneasy about the names-versus-numbers issue. But I do not remember reading any good explanation. Your text above should not be allowed to be lost. If there is something I could do, please tell me. I just asked Ales for a http://geda.seul.org/wiki login. It's for the gEDA suite including PCB, so if you get one too, you can put write ups into the FAQs there and make them better directly. John G PS The heading for a geda want list I am thinking of now is Design Flow Roadmap. sound good for assembling half-baked, codeless ideas as in, "What we need from you folks, the users, is a description of what functionality you need and why, so that we can find the best way to get there. "(DJ Delorie) John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where to place pcb footprints?
If you mean where pcb finds footprints, displayed in its "library" window, then you can set this in ~/.pcb/preferences. I have a line: "library-newlib = ./footprints:/home/des0prb/pcb/geda/footprints" in there. Personally I don't ever use the pcb library window though, because I always do pcbs from schematics. Here what matters is where gsch2pcb looks for its footprints. I put this in a project file in the working directory for the design, using a line like "elements-dir /home/des0prb/pcb/geda/footprints" I believe you can also specify this on the command line to gsch2pcb, but I find the project file approach more convenient. Make is an alternative of course. Hope this helps. If others have better ways of doing this, I'd be glad to hear them. On Fri, 2007-03-16 at 00:02 +0100, Philipp Klaus Krause wrote: > Where is a good place to store pcb footprints? For previous projects I > just copied them to the global footprint directories, but I suppose > that's not really the right place. The pcb documentation tells me to > place project-specific footprints in pkg/newlib. I'd prefer some place > under my home directory for footprints used by multiple projects, but > how do I tell pcb and gsch2pcb to look there? Is there some > configuration file for this? The pcb documentation mentions nothing > about configuration files. Maybe pcb doesn't have one? Is the command > line option to gsch2pcb the only way to tell it where to look for > footprints? -- Peter Baxendale <[EMAIL PROTECTED]> ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
