Re: gEDA-user: help with pcb dsn plugin
On Sun, Sep 18, 2011 at 1:00 AM, Bert Timmerman bert.timmer...@xs4all.nl wrote: PCB mostly has a consistent style, and we won't apply patches which don't follow that. This is the next patch on my todo list. Is the above the exact syntax ? No worries, I changed the style in the first place (when a good chunk of it was already in the standard style), I'll change it all to the standard when I put in some of the bug fixes I'm finding right now... Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: help with pcb dsn plugin
On Sun, Sep 18, 2011 at 4:18 AM, Peter Clifton pc...@cam.ac.uk wrote: Just for the record, I don't like PCB's code formatting style myself either ;) I assume there are PCB devs that prefer the gnu style? Or is it only enforced to be consistent with all the legacy code? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: help with pcb dsn plugin
On Sun, Sep 18, 2011 at 11:46 AM, DJ Delorie d...@delorie.com wrote: I assume there are PCB devs that prefer the gnu style? 1. I prefer GNU style. Emacs automatically does this style when coding, too. Good enough. Note that Emacs automatically does whatever style you tell it to, including the linux kernel style. The default is just gnu, because, well, it's a gnu program. A quick ctrl-c . and you are writing in a different style. 2. GNU style seems to be popular elsewhere too, which reduces the learning curve for many new developers I'm sure you've seen a lot more code than I have, but from my own experience it's only projects with a code base 10 something years old or more that use it. Most newer code I've seen, especially in academia, use something more like the linux kernel style. Maybe it's just the circles I code in. I'm personally not a fan of the gnu style, but don't go as far as Linus to think that people should print it out and burn it. :) I just don't think it looks aesthetically pleasing and find it difficult to read, but probably just because I'm used to the other style. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: help with pcb dsn plugin
I just posted this to the related bug tracker, but thought some people that would be interested wouldn't be following that, so reposting here: I wanted try out this freerouting.net thing so went ahead and updated this patch to work with the latest git head and nanometer awesomeness. Here's what I did: -- extensive style changes for my own sanity. There was inconsistent style throughout (like all of pcb's code), so I chose the one I personally like best (linux kernel style with indent of 4 instead of 8). :) -- Brought all the handling of coordinates up to date with the new Coord type and nm precision. There were a few places where dimensions were being rounded to the nearest mil, etc. which would've been bad for metric based boards. This has all been taken care of and appears to be working in some simple tests. DSN files are now in mm units with nm precision. -- Removed the somewhat dubious code for finding the rotation of the part copied over from bom.c. We don't have the original footprint anyway, so the rotation was not being used. The code is still there in bom.c if it is needed in the future. -- Fixed some minor issues like a small memory leak, etc. -- Fixed issues registering the action and updated config values to use Coord. -- New line from the session file weren't clearing polygons. -- Possibly some other stuff, I forget, I just went through the whole thing top to bottom and fixed anything I saw weird. Some things still not quite handled: -- Existing polygons on the pcb don't make it into the dsn. -- Parts rotated at non-orthogonal angles probably won't work since rectangular pads won't be rotated correctly. -- As noted in the bug report, there is no copyright/license notice from the original authors. Maybe some legal issues with the Specctra file format as well (I doubt it though, the text-based file format would be trivial to reverse-engineer even without the spec). -- Probably some other stuff. It appears to be working with some early tests, and freerouting.net is pretty awesome. Jared On Sun, Jun 12, 2011 at 12:45 PM, Josh Jordan outerspacema...@yahoo.com wrote: I was able to fix the action problem and create a single patch, if anyone is interested in using freerouting.net. Turn on only the layers you want routed on before exporting. -Josh Jordan --- On Sun, 6/12/11, Josh Jordan outerspacema...@yahoo.com wrote: From: Josh Jordan outerspacema...@yahoo.com Subject: gEDA-user: help with pcb dsn plugin To: geda-user@moria.seul.org Date: Sunday, June 12, 2011, 12:14 PM I made a dsn export/import plugin a few years back that I am trying to merge into latest git pcb version. It works to export and the dsn can be routed with freerouting.net, and the import function appears in the menu, but the import action does not work. The function name is ActionLoadDsnFrom() but somehow during compilation it lists a LoaddsnFrom in the list of actions. It says Unknown Action when I try to use LoaddsnFrom or ActionLoadDsnFrom, or LoadDsnFrom. Is there a way to list what actions exist in pcb? I had to make 2 patches, the first one with git diff it only shows files that were changed. The second patch is from git add -i /src/hid/dsn, git commit and git format-patch -1 and it will only show files that were added. If anyone knows how to make the patch with 1 command that would also help. Thanks, Josh Jordan -Inline Attachment Follows- ___ geda-user mailing list [1]geda-user@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. file://localhost/mc/compose?to=geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user From a0bb98376c96e91876bebdcc6d958c8a9f07d6e4 Mon Sep 17 00:00:00 2001 From: Jared Casper jaredcas...@gmail.com Date: Thu, 15 Sep 2011 17:12:52 -0700 Subject: [PATCH] Add SPECCTRA dsn export and session file (.ses) import. Original patch by Josh Jordan and Dan McMahill. --- configure.ac |2 +- src/Makefile.am | 18 ++- src/gpcb-menu.res.in |1 + src/hid/dsn/dsn.c| 609 ++ src/hid/dsn/dsn.h|3 + src/hid/dsn/hid.conf |1 + src/pcb-menu.res.in |1 + 7 files changed, 633 insertions(+), 2 deletions(-) create mode 100644 src/hid/dsn/dsn.c create mode 100644 src/hid/dsn/dsn.h create mode 100644 src/hid/dsn/hid.conf diff --git a/configure.ac b/configure.ac index a802790..197e325 100644 --- a/configure.ac +++ b/configure.ac @@ -436,7 +436,7 @@ esac AC_MSG_CHECKING([for which exporters to use
Re: gEDA-user: How to disable specific hooks?
On Tue, Sep 13, 2011 at 1:30 PM, Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Some hooks of gschem are hooked in by default in system-gschemrc. Most of these are fine. But some don't mix well with my style of schematics (e.g. autoplace-object-attributes) Is there a way to unhook these short of editing system-gschemrc? I thought about overloading with some kind of NOP script in my personal gschemrc. But being a noob with guile I just don't know where to start. Any hints? http://www.gnu.org/software/guile/manual/html_node/Hook-Reference.html Looks like there is a remove-hook! function, or just reset-hook! and start over with what you want. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why some skip KiCAD and gEDA
On Sat, Sep 10, 2011 at 4:35 AM, Stefan Salewski m...@ssalewski.de wrote: Consider the toys from the big company with the damaged fruit: A reason for the success of the toys is that documentations seems to be not needed. I agree with the idea, but the thing is, the Apple software that doesn't need documentation doesn't do a whole lot. I don't know of any sufficiently powerful tool, especially CAD, that doesn't require some time learning how to use the thing. Try to sit down in front of SolidWorks and pump out a widget without first reading some documentation; build a 3d animation in 3d Studio or Maia; pump out a board in Orcad. Sufficiently powerful tools need learning. People build careers out of being very good at using just one of these tools. A lot of documentation can make people think that it is very complicated. IMHO, it _IS_ very complicated (relatively), and necessarily so. There are a lot of options that need considered, a lot of details to get right, a lot of workflows to support, etc.. But complicated doesn't have to mean hard to use and not intuitive. For gEDA/PCB we have collected a lot of documentation over the years -- some is obsolete/outdated/redundant now or covers details, which most people are not interested in -- at least not when starting with gEDA/PCB. For me, there is no such thing as too much documentation. The problem is when there is too much obsolete and just plain wrong documentation and not enough of the right kind of documentation. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why some skip KiCAD and gEDA
On Sat, Sep 10, 2011 at 4:12 PM, Markus Hitter m...@jump-ing.de wrote: Using a keyboard to do anything but writing text is a thing of the past, to start with. I couldn't disagree more. I only want to use the mouse for things that absolutely require a mouse (drawing things mostly). If I have to use the mouse to click buttons or menus, etc. I consider that a complete failure. To get an idea of a fairly intuitive tool, have a look at Fritzing. gEDA is as far away from Fritzing as Word is from NotePad. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why some skip KiCAD and gEDA
On Sat, Sep 10, 2011 at 6:09 PM, John Griessen j...@ecosensory.com wrote: But they both have many of the same low level primitive commands and actions. I think you could base two apps on the same code and many of the users would never know, since some are so little into craft and so into speed, they would never read about the crafty details. True. IMHO though, for an app like Fritzing doesn't seem to be the core to be the hard part, the GUI is. For an app like gEDA both the core and GUI are hard. JG PS Fritzing is not all bad... I think it aims to be the arduino-compatible development tool for hardware. Absolutely, never said it was bad. :) From what I've seen, Fritzing is a great app for what it aims to be. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Sun, Sep 4, 2011 at 6:21 PM, Kai-Martin Knaak k...@familieknaak.de wrote: back to git-head from gpleda.org . Fall back to the last relased version of PCB would have been not so nice, because of the long release cycle. On Sun, Sep 4, 2011 at 7:14 PM, DJ Delorie d...@delorie.com wrote: use a released version, or stick with one checked-out version you know works, or maintain your own bugfix branch. Git head is where development happens, and when we're bringing in big changes, stuff breaks. Maybe give a non-dev volunteer permission to make official development snapshots, similar to how Icarus Verilog has done in the past. Those who want tested stability use the official release that is packaged by distros, those who want more bleeding edge but want to have had someone at least do a quick check that there aren't major board-breaking bugs can use the development snapshot, and those who want to tinker use git head. The difference between the snapshot and an official release is the time spent testing for bugs, dealing with which features to hold off the release for, etc. Even if a snapshot ends up with a major bug, if they happen often enough you won't loose a lot of features by going back a snapshot or two like you would going back to the last release. Just a thought. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Sun, Sep 4, 2011 at 9:52 PM, DJ Delorie d...@delorie.com wrote: Maybe give a non-dev volunteer permission to make official development snapshots, similar to how Icarus Verilog has done in the past. Go for it, I say. It's Free Software, they don't need permission, they just need dedication. If they offer something useful, people will use it. They don't need permission to make a snapshot, but they need permission to make official snapshots that are linked to and downloadable from the web page, acknowledged by the devs, etc. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New layer selector to play with (git preview)
On Wed, Aug 24, 2011 at 3:21 AM, Andrew Poelstra as...@sfu.ca wrote: Hey all, The new gtk layer selector is finished for most uses now. If you want to play with it before it's ready to be published (which is a few days away still), you can get it here: Looks great! Just played around with it for a second and noticed a bug though, when you delete or otherwise change the layers in the PCB Preferences dialog (i.e. delete or move the currently selected layer, or add a new one) the layers are changed, but the widget isn't updated, even after the dialog is closed, leading to all kinds of confusion. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Foss-pcb Proposed plan from CERN
On Tue, Aug 23, 2011 at 2:29 PM, Kai-Martin Knaak k...@familieknaak.de wrote: Indeed. The posts to the list that I woke up to this morning took a frighteningly KiCad-centric turn. Well, this is, because apparently one of the kicad developers showed up. Is any of the geda devs going to join the OHR mailinglist? The guy from cern seemed equally leaning towards kicad and a kicad-like toolset. Especially with comments like I bet KiCad will gain more developers quite soon. Depending on how influential he is, the battle may be over before it even begins. I chuckled at what this community would think of the comment, in response to There are users who prefer separate dedicated applications to an integrated design environment., BTW. How many of these users have ever designed a PCB with more than 4 layers and, say, 300 components? From my own experience, above the certain level of PCB complexity the intuitiveness and efficiency of the GUI become a paramount. As someone who only does relatively simple boards, I wasn't in a position to respond. Maybe some of our power users could step in? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Layer button backgrounds
On Thu, Aug 18, 2011 at 3:56 PM, Andrew Poelstra [1]as...@sfu.ca wrote: 2. Whenever you hide a layer, the selector would jump to the previously-selected layer. I haven't tried it yet, but I think that from a user's perspective that would make the visibility buttons seem independent of list selection. This would work for hiding layers, but not making them visible. If layer X is active and layer Y is invisible, how do I make layer Y visible without making it the active layer? I like KMK's click/double-click idea if possible. In practice I avoid moving the mouse all the way over to the layer selection while doing a layout anyway, instead using my free hand on the number keys to select the active layer. Jared References 1. mailto:as...@sfu.ca ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem gnetlist problem
On Wed, Jul 13, 2011 at 4:06 PM, Kai-Martin Knaak k...@familieknaak.de wrote: Peter Brett wrote: Yes, both are pretty straightforward to add (I think), but I don't have time right now. File feature requests? :-) done: https://bugs.launchpad.net/geda/+bug/810202 Needed a break from verilog so wrote up a quick implementation and attached it to the bug report. Scheme can be fun! ;) From what I can tell it is the first use of the fancy backend-getopt module Peter added back in January. 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
2011/5/26 DJ Delorie d...@delorie.com: 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
On Thu, May 26, 2011 at 11:52 AM, Andrew Poelstra 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. 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: Reinventing the wheel
On Thu, May 19, 2011 at 6:45 AM, Stephan Boettcher boettc...@physik.uni-kiel.de wrote: I still do not know where the pcb users manual is to be found. I found PCB home page (pcb.gpleda.org) top level link in navigation box on the left: Manual. Choose your version. One could argue about how good or complete it is, but certainly not that it can't easily be found. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec martin.ku...@kupson.cz wrote: If layers types would be defined by attributes, someone would be able to declare one layer both as conductive and as silk for example. That could cause me a nighmares. That is why I insist on 'typed' layers, not 'tagged' layer. That example is probably silly, but someone would probably come up with something more realistic, but still giving me nightmares. But what if I want a silk layer to just be a copy of a copper layer? That may be just as silly, but I'm sure someone could come up with a use for it. Why would such a layer cause nightmares? When the code is worried about connectivity etc., it sees this layer is tagged as conductive and includes it in whatever its doing, ignoring the fact that it is also silk. When the code is putting out the silkscreen, it notices this layer is tagged as silk and puts it out, ignoring that it is also a conductive layer. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:32 PM, DJ Delorie d...@delorie.com wrote: The core includes the autorouters, optimizers, DRC, exporters, reports, and even simple editing - we have a hide vias button. How does that work if you no longer have vias as an inherent type? You go through and hide all the composites marked as a via. For pcb to deal with vias differently doesn't mean that vias needs to be something fundamentally different than a footprint. On Fri, Mar 18, 2011 at 1:38 PM, DJ Delorie d...@delorie.com wrote: The HID is the wrong place to be assigning *meaning* to the data. That is still in the core. The fact that some composites are vias is something intrinsic to the pcb design, independent of what color you make it on the screen, and independend of how vias are implemented at the lowest internal levels. From my reading of this conversation there is a disconnect between what people are talking about w.r.t. words like the core. Some are talking about the lowest internal levels where a via can just be another composite object. Some are talking about everything in pcb besides the gui, where do you need to distinguish a via from a footprint. While others seem to be using gui as everything but the lowest internal levels Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie d...@delorie.com wrote: But what if I want a silk layer to just be a copy of a copper layer? This is a different category of problem - the CAM job. Typically, you'd have a file that describes how to map design layers to output layers. In that file, you'd say this copper layer should be output as a silk layer also. Such a file could also say copper objects with the also-paste attribute should be drawn on the paste layer etc. Okay, but you are just moving the layer/object tags out to a separate file and process, the layers are still tagged so some extent somewhere. But I get your point. At the design/edit level, that layer is a copper layer. Note to John: And DRC freaks out because it has two separate incompatible sets of rules to apply to it. But if I am doing that (just to extend this silly example too far), I would want the DRC checker to ensure that it obeys both the rules for copper _and_ for silk. If those are incompatible sets then I have to deal with the failed DRC for one of them because I am asking the tool to do something that doesn't agree with with the DRC rules I have asked it to check, but I would still like to know that is what I'm doing. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Thu, Feb 24, 2011 at 7:39 PM, Kai-Martin Knaak k...@lilalaser.de wrote: I agree that color does not belong in the layout file. I may keep changing my preferences on my pcb color theme, but I don't want to update all my layout files to take advantage of an updated color theme -- UI preferences like color theme should definitely not be included in the .pcb layout file itself. I partly disagree. Some information on color should be in the layout. Real world use cases: ... The layout may not contain the whole explicit color information. Just a name of a color scheme may be enough. If no matching color scheme can be found in $HOME/.pcb/.color, or in the project dir, some default scheme would be used. That way you can have both. Central color config files and layout chosen color schemes. As a bonus, my color blind colleague can keep a palette adjusted to his needs and we can still both work with the same layout files. I would vote for color schemes to map colors to layer types/properties and no color info in the layout file, as opposed to color schemes with color-layer number mapping and some color info in the file. So instead of the color scheme saying blue for layer 0, red for layer 1, etc. It would say blue for the primary layer, red for the secondary layer, green for layers with the ground plane attribute (or whatever), etc. This way a color scheme works for any board that I load. I think this would cover all of your use cases, wouldn't it? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open Collector Error Checking
2011/2/14 DJ Delorie d...@delorie.com: A separate git repo would make it harder for me to review patches. I'm much more interested in the history and discussion of the patch, than in the actual patch itself, and if there's anything wrong with the patch, LP/SF is a better way to manage those issues than git. github's pull request/code review system works pretty well for discussing a patch (https://github.com/features/projects/codereview). I also like the way Google Project hosting does code reviews, especially the voting system. I'm not sure if github has something similar. Thought I'd throw that out there, even though we should probably just stick to LP for everything since we just moved over to it. (Although I'm still unclear how to differentiate bugs and patches in the LP tracker) I think maybe what Karl was getting at was a group of Junior devs that commit to a repo to indicate they have looked at and agree with the patch. The senior dev, if he trusts the junior dev's judgement, issues a few git commands and the patch is in. Perhaps now that we are on LP, the ideas in this thread are more realizable: http://www.seul.org/pipermail/geda-user/2010-March/045968.html Maybe make an official LP tag of vetted or something that junior developers can add to a patch, allowing a senior dev to concentrate on those first, not spending on time on patches that need work. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB-Patches] Action-documentation
On Sat, Nov 13, 2010 at 6:35 PM, kai-martin knaak k...@familieknaak.de wrote: PS: (*) Would a general switch of element to footprint receive a warm welcome by the developers? This would provide more consistency between geda and pcb wording. I've always thought of the footprint as the definition and the element as the instantiation of the footprint. I think it would be confusing to call the pcb element a footprint. Would I say there are twenty 0603 footprints on a board? No, there is just one 0603 footprint in use, and it is used 20 times to make 20 elements. Just a different perspective from a user, but I could be out in left field. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: icarus, fork, and recursive tasks
On Sat, Nov 6, 2010 at 4:37 PM, DJ Delorie d...@delorie.com wrote: Not to usefully, they all shared the one task (or variable), and thus all exited at exactly the same time. How do I do a local instantiation of a task? From IEEE 1364-2005: All variables of a static task shall be static in that there shall be a single variable corresponding to each declared local variable in a module instance, regardless of the number of concurrent activations of the task. However, static tasks in different instances of a module shall have separate storage from each other. If a task isn't automatic (which is what you really want), it is static. So it seems to me the only way to do what you want to do is figure out a way to partition things so each twait task is part of a separate module instantiation. I haven't confirmed this with Icarus though. I've gotten around issues like this before with the ugly hack of just copy/pasting the task for each caller... twait_cson, twait_wron, twait_wdon, twait_cswwait, etc... Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb still unable to run actions with print HID
On Sat, Jun 12, 2010 at 5:32 PM, kai-martin knaak k...@familieknaak.de wrote: I understand, that you are weary to remove the CRASH statement when not 100% sure what it's purpose in this particular case is. But is this a valid reason to withhold a working patch and keep printing from the command line in a crippled state? I made it pretty clear, that I am interested in getting While you know I'm all for community contributed patches getting in, I disagree that this should be applied as is without understanding what is going on. imho, bandaids covering up bugs should be avoided at all cost, especially if you don't even know if it is a bandaid or not. A bug left in the code (especially one with a work-around) is better than one covered with a bandaid. If you want to help fix the bug, figure out why invalidate_lr is being called without a gui and make an argument as to why that is okay, or make it so it doesn't happen. Seems like the purpose of those CRASH statements are to let the hid developer know that a hid function is being called that he hasn't explicitly implemented. That seems like a worthwhile thing to have and not just ditch because you don't understand why that function is being called. If there is a legitimate reason why it is okay for that function to be called when using the printing hid, maybe the better solution is to point to a blank function in the print hid's structure instead of leaving it null to default to hidnogui's function? This would explicitly document that this is going to be called for this gui and its okay, rather then taking out the general mechanism to know when something is called that you didn't anticipate. (although maybe that isn't the best solution, haven't thought it through fully...) command line printing fixed. Why didn't I get a note that only half the patch was applied? Yes, I can fix it on my local copy. But this does not help with colleagues and students who I teach using geda. I do agree whoever applied it should've let you know that part of it wasn't going in, if that is the case. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Patches: Use c99 bool instead of manual typedef.
On Sat, Jun 5, 2010 at 11:38 AM, DJ Delorie d...@delorie.com wrote: I really want to encourage people to work on the code and become contributors, and telling them their hard work is for naught because someone somewhere might have an uncommitted patch that might be affected, is not acceptable to me. IMHO the biggest thing that can be done on this front is to organize a way to contribute. I'm guessing I would have done at least 2 - 3 times as much work on PCB in the past year or two if it didn't take an average of three to four MONTHS of nagging to get work I have done even looked at, let alone committed. And it isn't just me. You say you want people to become contributers, but then don't have the organization and/or man power to accept contributions. Either one of the devs needs to step up and take charge of handling contributions, or the devs need to extend their trust to someone willing to do it. Sorry, couldn't let a statement like that pass... Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Patches: Use c99 bool instead of manual typedef.
On Sat, Jun 5, 2010 at 12:35 PM, Peter TB Brett pe...@peter-b.co.uk wrote: I have commit access to the PCB repo, and I'd be willing to take this on, except for the two issues that a) I'm not as familiar with the PCB codebase as many of the other developers, and b) I often disagree with DJ about what the Right Thing is. I guess that's why the success many open source projects relies on someone with the authority and willingness to make the final decisions (which takes a lot of their time on the project I would imagine, or in some cases most of it). There doesn't seem to be one lead developer or benevolent dictator of PCB as far I can tell. Maybe elect one? :) However, I think a majority of contributions wouldn't or shouldn't cause enough controversy or disagreement that the person willing to do the work of verifying the patch can't just make the decisions. You just need someone familiar enough the code to know without too much digging that a particular patch isn't going to affect/break something the contributor wasn't aware of. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB patches (was: [PATCH 1/7] PCB localization)
On Thu, May 27, 2010 at 12:50 AM, Jared Casper jaredcas...@gmail.com wrote: On Wed, May 26, 2010 at 11:49 PM, Ineiev ine...@gmail.com wrote: On 5/26/10, Jared Casper jaredcas...@gmail.com wrote: So since the only way to contribute to PCB seems to be to continually spam the list with patches, here's three patches to fix bugs in the bug tracker. Comments welcome. Here are two more patches dealing with issues similar to 0001-Fix-pr2976245-refdes-labels-in-new-layout-can-t-be-m.patch If it makes it any easier. All five of these patches can be pulled from: git://github.com/jaredcasper/pcb.git I just rebased the bug fixes in this repository against the current git head (including the bool changes). Any chance a dev could take a look and comment on or push these? I've included a couple more trivial bug fixes from the sourceforge tracker and one of my own. (Sorry for the rebase if anybody happened to pull from this repo earlier, wanted to make things as easy as possible to get these patches in) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Patches: Use c99 bool instead of manual typedef.
On Thu, May 27, 2010 at 10:57 PM, Ineiev ine...@gmail.com wrote: Robert Spanton rspan...@zepler.net wrote: The key word being if. If and when the issue arises, then we fix it. In other words, you are willing to break it and won't fix. It's not exactly one way or the other, but I believe this falls more under the You Aren't Gonna Need It category than the breaking it category. Robert has already pointed out that PCB currently won't build without a C99 compiler (because of the c++ style comments, and I'd be willing to bet a few other things). Why add complexity to the code for unneeded and half-way features (the feature here being non-c99 compatibility). If you need the feature, you can add it when you need it. I'll grant that replacing Boolean with bool takes it further away from being non-c99 compatible, which could be seen as breaking it further if non-c99 compatibility is what you want. However, it has plenty of advantages, that he has pointed out, that IMHO out weigh that negative. In addition, if one were to aim for non-c99 compatibility, the AC_HDR_STDBOOL way is arguably the right way to do it, so this patch takes the code part of the way there anyway. Why not apply it to your local branch instead of PCB master? Because it's annoying to maintain a local patch set, and one of the great things about open-source software is the community contributing back and making the code/program better. Robert provided the script and the git filter-branch tip to make it easier for those with local change-sets to avoid the conflicts if this were committed to the main repo by removing all the conflicts in one easy step. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB patches (was: [PATCH 1/7] PCB localization)
On Wed, May 26, 2010 at 11:49 PM, Ineiev ine...@gmail.com wrote: On 5/26/10, Jared Casper jaredcas...@gmail.com wrote: So since the only way to contribute to PCB seems to be to continually spam the list with patches, here's three patches to fix bugs in the bug tracker. Comments welcome. Here are two more patches dealing with issues similar to 0001-Fix-pr2976245-refdes-labels-in-new-layout-can-t-be-m.patch If it makes it any easier. All five of these patches can be pulled from: git://github.com/jaredcasper/pcb.git Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB patches (was: [PATCH 1/7] PCB localization)
On Tue, May 25, 2010 at 1:58 PM, Bert Timmerman
bert.timmer...@xs4all.nl wrote:
By email also has its advantages:
1. Email means the patches get seen and reviewed 2. Git sends
the email for you - so no extra work for the sender 3. I can
save the patches without having to poke sourceforge 4. I can
save the patches without having to poke sourceforge
5. *all* the impatient geda-users can apply the patches to their local
repository themselves, and have a test drive, without having to poke
sourceforge.
6. *all* impatient geda-devs can apply the patches to their local repository
themselves, and have a test drive, without having to poke sourceforge ;-)
Last time this was brought up there was a big discussion about how
pretty much everyone is not happy with the sourceforge trackers. A
few of us asked to be allowed to help out to get a new tracker up and
going so the devs didn't have to spend their time worrying about, but
I got a definite impression any work on that front would also not be
used by the developers (that blaming it on sourceforge was just a
euphemism for we don't have enough time to deal with contributions,
which is unfortunate but understandable.)
So being stuck with sourceforge I thought maybe I could help out and
make it a little nicer, got my sourceforge account access to the PCB
trackers, cleaned up a few bugs, and tackled a few that I felt like I
could handle. Put the patches in the patch tracker, commented on the
bug that a patch was available, etc. The result? One of four patches
applied; better than nothing I guess.
There was a suggestion that a group of non-devs go through and filter
bugs and patches and suggest patches for the devs to review. Until
there is evidence that there is a process or method of handling
patches within the devs themselves, it seems such a team wouldn't be
of much use.
So since the only way to contribute to PCB seems to be to continually
spam the list with patches, here's three patches to fix bugs in the
bug tracker. Comments welcome. If any of the devs have any
suggestions for how I can better contribute to PCB, I'd be glad to
hear it. I don't want to sound like I'm continually complaining, I
just want to know how to help out.
Jared
From 2344dab7f2544e33a7374d763a24db7e6a42cb86 Mon Sep 17 00:00:00 2001
From: Jared Casper jaredcas...@gmail.com
Date: Fri, 9 Apr 2010 15:32:34 -0700
Subject: [PATCH] Fix pr2717258, Lock mode with F12.
Binds F12 to lock mode in the default gcpb-menu.res and pcb-menu.res
files, bringing them inline with existing documentation.
---
src/gpcb-menu.res |2 +-
src/pcb-menu.res |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gpcb-menu.res b/src/gpcb-menu.res
index 1511e09..29e575f 100644
--- a/src/gpcb-menu.res
+++ b/src/gpcb-menu.res
@@ -518,7 +518,7 @@ PopupMenus =
{Insert Point checked=insertpointmode,1 Mode(InsertPoint) a={Insert KeyInsert}}
{Move checked=movemode,1 Mode(Move)}
{Copy checked=copymode,1 Mode(Copy)}
- {Lock checked=lockmode,1 Mode(Lock)}
+ {Lock checked=lockmode,1 Mode(Lock) a={F12 KeyF12}}
{Cancel Mode(Escape) a={Esc KeyEscape}}
}
}
diff --git a/src/pcb-menu.res b/src/pcb-menu.res
index c18eb86..69ed6f5 100644
--- a/src/pcb-menu.res
+++ b/src/pcb-menu.res
@@ -182,7 +182,7 @@ MainMenu =
{Insert Point checked=insertpointmode,1 Mode(InsertPoint) a={Insert KeyInsert}}
{Move checked=movemode,1 Mode(Move)}
{Copy checked=copymode,1 Mode(Copy)}
- {Lock checked=lockmode,1 Mode(Lock)}
+ {Lock checked=lockmode,1 Mode(Lock) a={F12 KeyF12}}
{Cancel Mode(Cancel) a={Esc KeyEscape}}
-
{Command Command() a={: Key:}}
--
1.7.1
From f4deaa4efc523c89ff12dc8aa17288e3d10db1ef Mon Sep 17 00:00:00 2001
From: Jared Casper jaredcas...@gmail.com
Date: Fri, 16 Apr 2010 21:30:14 -0700
Subject: [PATCH] Fix pr2924962 and other issues with layer selection in the gtk hid.
In general there was a lack of consistency in the behavior when
changing the visibility of layers using the buttons and menu. This
fixes both the hang in the bug report, and many other small issues.
The code attempted to make it so that the active layer was always
visible, but failed in a few places, such as when the silk or rats
layers were activated while hidden or hidden while active, or when the
last layer group was active and hidden, it remained active. There was
also issues when the active layer was hidden using the menus. This
patch fixes all of that.
This patch allows the active layer to become the silk or rats layer if
no copper layer is visible.
It was necessary to add an additional flag to ChangeGroupVisibility()
to indicate if the hid should be notified via the LayersChanged
action. This was causing problem when the menu was used to hide the
active layer, an extra LayersChanged call was scheduling a
ghid_menu_cb which reverted the change to the layer visibility. In
generally this was causing also just causing a lot of extra
Re: gEDA-user: OT: Bike Alarms (was: Re: Copper-free area in footprint)
On Thu, May 13, 2010 at 8:25 AM, kai-martin knaak k...@familieknaak.de wrote: Getting a GPS location when at an unknown position consumes a fair amount of computational power (to find the satellites). So this is a modified proposal for less energy consumption: Just check for an incoming SMS once a day. Only if the owner considers the bike as stolen, GPS may spring into action. How cheap a service contract can you get for the sim card? Unless you can get a per-SMS plan or something, after a year or two you may be approaching a non-trivial percentage of the cost of replacement. While the tech solution is definitely cooler, covering the bike under a renter's or home owner's insurance policy may be cheaper and easier. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How do I mark the connection point on a pad?
On Sat, May 8, 2010 at 9:19 AM, kai-martin knaak k...@familieknaak.de wrote: They do not in GTK-HID, which is, what the file gpcb-menu.res refers to. I tried with pcb 20091103 as packaged by debian/squeeze, pcb-head from git and with the GL-enabled version from the before_pours branch of Peter C. In none of these versions a via inserted with the via tool responds to any of the v-accels. Since via sizes can be incremented with the s-key and its various modifiers, such a binding would be redundant, anyway. They change the size of new vias (i.e. what will be created when you place a via), not existing vias. Look at the status line along the bottom at the via= as you hit the *-v combos. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Database on symbols, footprints and other (was Re: gattrib)
Sorry, bored tonight and want to jump in... ;) On Thu, May 6, 2010 at 6:07 PM, John Doty j...@noqsi.com wrote: I encourage people to contribute to gedasymbols. Where is your contribution? If gedasymbols is good, what's wrong with a tool to allow easier access to a gedasymbols-like-but-more-organized database? Not true. If the database behind the GUI tool is inadequate, the GUI gets in the way. Users will have to get used to reaching around it anyway. That will drive away everyone who thinks it should actually work, while the few remaining will drop back to the workable flow, and the cute GUI feature will have only driven people away. Those that would be driven away by the fact that such a database isn't complete and perfect will almost certainly be driven away by the current situation. But if gEDA is perfect as is and no more features should be added, why does it matter if people are driven away? An open source project typically wants more users to have more contributors, but if contributions are unnecessary (or contributions are ignored, but that's another story) then it doesn't matter if people are driven away. Ah, but it does have to be perfect. Otherwise there will be lots of whining about what a piece of crap gEDA is. People won't be able to find their favorite component. People will design boards, fabricate them, and be shocked when pin numbers turn out to be wrong. http://www.jwz.org/doc/worse-is-better.html Sure. Contribute your symbols to gedasymbols. I encourage this. But the delusion that this can somehow lead to a situation where a user can just pick a component from a menu without both careful checking and customization is damaging. Just because it is hard and tedious to use use symbols/footprints from gedasymbols won't discourage people who would use them blindly from doing so. Easier access to such a database would make it easier to find existing symbols and pull them in for customization for those that know how to use the tool set. Just because it may make it easier for people to shoot themselves in the foot is no reason not to have it. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using git to track work on schematics done using gschem
On Wed, May 5, 2010 at 9:39 AM, Kurt Jensen k...@zoompig.com wrote: However, # is the comment character for a .gitignore file. I tried to escape the # character like: \#* but that does not seem to work either. Does anyone have a suggestion on how to do this? \#* works for me with git 1.7.1. Are the files already part of the repository? If so .gitignore won't ignore them until you git rm them. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB configuration skin
On Mon, Apr 26, 2010 at 10:43 AM, Bert Timmerman bert.timmer...@xs4all.nl wrote: FWIW, I have a very dim vieuw about this issue and would be very surprised if even a very very big protest would help (very very big as in more than 20,000 protests). For anyone interested (as I was), here is a (the?) discussion about this (which Google didn't immediately turn up): https://bugzilla.gnome.org/show_bug.cgi?id=602882 Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Patch to PCB build system needs testing/feedback
On Mon, Apr 19, 2010 at 7:57 AM, John Griessen j...@ecosensory.com wrote: Anything to help understandability of compile output is good by me. Your change probably won't decrease error output, just the ones that go smoothly are shortened, right? The errors/warnings themselves aren't shortened, it just shortens the command line used to compile. As an example this is the output of the build with this patch applied, versus without. (sorry for the spam of compile output, but since people without automake 1.11 won't be able to see the change, I think this will help demonstrate what this patch would do. In fact the mere fact I feel like I need to apologize for pasting compile output could be part of the argument :) With patch (warnings obvious) CC action.o CC autoplace.o CC autoroute.o ../../../pcb/pcb/src/autoroute.c:3431: warning: ‘add_clearance’ defined but not used CC buffer.o CC change.o ../../../pcb/pcb/src/change.c: In function ‘ChangeElementName’: ../../../pcb/pcb/src/change.c:1016: warning: unused variable ‘old’ CC clip.o CC command.o Without patch (very difficult to quickly see what exactly is going on, let alone catch the warnings): gcc -std=gnu99 -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I. -I../../../pcb/pcb/src -I.. -I../../../pcb/pcb -I../../../pcb/pcb/src/icons -I../../../pcb/pcb/src/gts -I/usr/include -I/usr/include -I/usr/include -DPREFIXDIR=\/usr/local\ -DBINDIR=\/usr/local/bin\ -DHOST=\x86_64-unknown-linux-gnu\ -DPCBLIBDIR=\/usr/local/share/pcb\ -DPCBTREEDIR=\/usr/local/share/pcb/newlib\ -DPCBTREEPATH=\/usr/local/share/pcb/newlib:/usr/local/share/pcb/pcblib-newlib\ -DNDEBUG -g -O2 -I/usr/include -I/usr/include -I/usr/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14-Wall -Wdeclaration-after-statement -MT action.o -MD -MP -MF $depbase.Tpo -c -o action.o ../../../pcb/pcb/src/action.c \ mv -f $depbase.Tpo $depbase.Po depbase=`echo autoplace.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ gcc -std=gnu99 -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I. -I../../../pcb/pcb/src -I.. -I../../../pcb/pcb -I../../../pcb/pcb/src/icons -I../../../pcb/pcb/src/gts -I/usr/include -I/usr/include -I/usr/include -DPREFIXDIR=\/usr/local\ -DBINDIR=\/usr/local/bin\ -DHOST=\x86_64-unknown-linux-gnu\ -DPCBLIBDIR=\/usr/local/share/pcb\ -DPCBTREEDIR=\/usr/local/share/pcb/newlib\ -DPCBTREEPATH=\/usr/local/share/pcb/newlib:/usr/local/share/pcb/pcblib-newlib\ -DNDEBUG -g -O2 -I/usr/include -I/usr/include -I/usr/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14-Wall -Wdeclaration-after-statement -MT autoplace.o -MD -MP -MF $depbase.Tpo -c -o autoplace.o ../../../pcb/pcb/src/autoplace.c \ mv -f $depbase.Tpo $depbase.Po depbase=`echo autoroute.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ gcc -std=gnu99 -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I. -I../../../pcb/pcb/src -I.. -I../../../pcb/pcb -I../../../pcb/pcb/src/icons -I../../../pcb/pcb/src/gts -I/usr/include -I/usr/include -I/usr/include -DPREFIXDIR=\/usr/local\ -DBINDIR=\/usr/local/bin\ -DHOST=\x86_64-unknown-linux-gnu\ -DPCBLIBDIR=\/usr/local/share/pcb\ -DPCBTREEDIR=\/usr/local/share/pcb/newlib\ -DPCBTREEPATH=\/usr/local/share/pcb/newlib:/usr/local/share/pcb/pcblib-newlib\ -DNDEBUG -g -O2 -I/usr/include -I/usr/include -I/usr/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14-Wall -Wdeclaration-after-statement -MT autoroute.o -MD -MP -MF $depbase.Tpo -c -o autoroute.o ../../../pcb/pcb/src/autoroute.c \ mv -f $depbase.Tpo $depbase.Po ../../../pcb/pcb/src/autoroute.c:3431: warning: ‘add_clearance’ defined but not used depbase=`echo buffer.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ gcc -std=gnu99 -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_CONFIG_H -I. -I../../../pcb/pcb/src -I.. -I../../../pcb/pcb -I../../../pcb/pcb/src/icons -I../../../pcb/pcb/src/gts -I/usr/include -I/usr/include -I/usr/include -DPREFIXDIR=\/usr/local\ -DBINDIR=\/usr/local/bin\ -DHOST=\x86_64-unknown-linux-gnu\ -DPCBLIBDIR=\/usr/local/share/pcb\ -DPCBTREEDIR=\/usr/local/share/pcb/newlib\ -DPCBTREEPATH=\/usr/local/share/pcb/newlib:/usr/local/share/pcb/pcblib-newlib\ -DNDEBUG -g -O2
Re: gEDA-user: Patch to PCB build system needs testing/feedback
On Mon, Apr 19, 2010 at 2:03 AM, Ineiev ine...@gmail.com wrote: On 4/18/10, Jared Casper jaredcas...@gmail.com wrote: I think it makes the build much cleaner and readable overall and, more importantly, makes the errors and warnings much easier to see. Actually, I don't think so; the build itself does not change, the readability arguably decreases (I'll need an extra step to switch on the full mode). I'm curious why you feel readability decreases? I still see what file is being compiled and the full output the errors. The only information I loose and need to switch on full mode for is the full compiler flags used in the compile, most of which probably aren't directly related to compiling this particular file and in my experience are very rarely needed to understand a compiler error or warning. Readability is increased because the warnings are not lost in the lines and lines of command line output (see my last reply) It works for me with autoconf-2.63, automake-1.10.2; that is, nothing changes. Thanks for testing, that is indeed what was expected. Some of patches from my collection will need to be rebased manually, but I have no other objections. I'm sure they will get in before this (if it does), in which case I'll rebase this stuff, no problem. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Patch to PCB build system needs testing/feedback
Hi all, I just discovered that the latest automake (1.11) has a nifty feature to create silent build rules to produce a Linux kernel style build that just displays CC file.c etc. instead of the whole command line (must have missed the memo last year). The attached patch enables this mode in PCB and edits most of the custom build rules to use the new silent type of output. Right now it turns silent build on by default. The old style can be obtained using make V=1 or with the --disable-silent-rules configure option. To make it not on by default, remove the [yes] in the call to AM_SILENT_RULES in configure.ac. I think it makes the build much cleaner and readable overall and, more importantly, makes the errors and warnings much easier to see. I decided to send it here instead of the patch tracker for two reasons: 1) Feedback to see if people like this style of build output. 2) Testing. I don't have a box that has autoconf 2.60 and automake 1.11 (I either have servers that have been up for ever and still on autoconf 2.60 or desktops that are very up to date and have automake = 1.11.) I'd be surprised if it broke things with automake 1.11, but that needs testing. Also, I don't have a Windows box or a box with a non-GNU tool chain to test it out on. So if any body with these environments can test this out for me I'd appreciate it. Thanks! Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Patch to PCB build system needs testing/feedback
This time with the patch. On Sun, Apr 18, 2010 at 4:05 PM, Jared Casper jaredcas...@gmail.com wrote: Hi all, I just discovered that the latest automake (1.11) has a nifty feature to create silent build rules to produce a Linux kernel style build that just displays CC file.c etc. instead of the whole command line (must have missed the memo last year). The attached patch enables this mode in PCB and edits most of the custom build rules to use the new silent type of output. Right now it turns silent build on by default. The old style can be obtained using make V=1 or with the --disable-silent-rules configure option. To make it not on by default, remove the [yes] in the call to AM_SILENT_RULES in configure.ac. I think it makes the build much cleaner and readable overall and, more importantly, makes the errors and warnings much easier to see. I decided to send it here instead of the patch tracker for two reasons: 1) Feedback to see if people like this style of build output. 2) Testing. I don't have a box that has autoconf 2.60 and automake 1.11 (I either have servers that have been up for ever and still on autoconf 2.60 or desktops that are very up to date and have automake = 1.11.) I'd be surprised if it broke things with automake 1.11, but that needs testing. Also, I don't have a Windows box or a box with a non-GNU tool chain to test it out on. So if any body with these environments can test this out for me I'd appreciate it. Thanks! Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 0001-Enable-linux-kernel-style-silent-build-if-available.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Patch to PCB build system needs testing/feedback
On Sun, Apr 18, 2010 at 8:38 PM, Larry Doolittle ldool...@recycle.lbl.gov wrote: I don't mind the short form, until I run into trouble. Then I want a documented way to turn it off, so I can see what make is actually trying to do. The explicit command lines are wonderful sources of cutting-and-pasting experiments on the command line. Absolutely. Like I said it is pretty easy to turn off. Using make V=1 instead of just make will display all the full command lines for a single run of make. ./configure'ing with --disable-silent-rules will turn off the silent builds completely and show all command lines in the build tree. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: A modest proposal regarding newlib footprints
On Sun, Mar 14, 2010 at 7:53 PM, kai-martin knaak k...@familieknaak.de wrote: I read the devel list via gmane (gmane.comp.cad.geda.devel) Gmane is a service that transfers mailinglists to usenet-protocol and back. Since usenet readers are optimized for threaded discussions with many participants, they are convenient for mailing lists. See http://gmane.org for details. On linux I'd recommend knode as a reader. But thunderbird or any other email client that can deal with the NNTP protocol might be just fine, too. Thanks everyone for the suggestions, gmane works great! Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mon, Mar 15, 2010 at 12:44 PM, John Griessen j...@ecosensory.com wrote: Al Davis has been asking for a translator that is external so progress can be made soon and not have to rewrite gschem. What is the plugin status of gschem? Is it anything like pcb's plugin writing? Here's what Al has been asking for in outline form: http://www.geda.seul.org/wiki/glue-projects Here's a more detailed description of Al's proposed translator: http://www.geda.seul.org/wiki/geda:format_translation Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: A modest proposal regarding newlib footprints
On Sun, Mar 14, 2010 at 5:54 AM, Kai-Martin Knaak k...@familieknaak.de wrote: Why is this discussion in geda.devel, where ordinary users can't write and hardly read? Is there any way to allow read-only subscriptions to geda-dev for those of us interested to read what is going on in a more convenient way than the archive? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Tue, Mar 9, 2010 at 5:06 PM, Dan McMahill d...@mcmahill.net wrote: Here's an example of a place where extra help wouldn't have needed any knowledge of internals. Over the years there have been various bug reports about some of the footprints that ship with pcb. For each of those, the process becomes Since footprint bugs take so long, maybe some triage is necessary. I think it make sense for you developers to make a footprint category, plop all of these in there and concentrate on pruning the list of bugs that require a developer to handle. (I agree with the idea that has been posted here before that a symbol/footprint/model/etc. library for gEDA should be a separate project altogether) I think it would help to organize the bugs in there. Currently there are 140 open bugs, most without a category, no groups used, and all priority 5. I can imagine for a developer it just looks like a mountain of sludge that would take a lunch break just to start on something. The tracker would probably be more useful and thus used more if it were more manageable. Well defined categories, groups and priorities would go a long way. Given access I'll try to make some time start trudging through and cleaning the trackers up, but can't do much myself as is. Another example is when a new HID is added. Almost no existing code is touched. However, it needs to be built. Code needs to be checked for formatting (run through indent(3)), compiler warnings checked, basic Does PCB and/or gEDA have a coding style preference, let alone one documented somewhere? author didn't provide that, etc. I spent probably 2 hours today (my entire lunch and a chunk of my evening) on a single patch submission to get it to where I didn't feel bad about it. At this rate, it would take me a month of And now PCB has a gcode exporter. Sweet! :) full time work to get through the bug and patch database I went ahead and did it on this one, but in general, it would have been useful to have extra hands to do some of these checks and to help out the author (whose work I really appreciate, this email is not meant to complain since he put in a lot of work already). ... so for the patches that you can't put so much time into, just a comment to say what needs to be done before it gets applied would go a long way. The submitter has most likely spent enough time on the patch that they probably won't mind spending another hour or two doing the necessary grunt work to get it included in the main repository. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni alberto.macci...@gmail.com wrote: the code on the mailing list, but it took me several months to discover the submit patch procedure. What procedure did you find? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Bugmail
On Mon, Mar 8, 2010 at 2:09 PM, Peter Clifton pc...@cam.ac.uk wrote: Or - in my ideal word, can we just dump the crappy sourceforge bug trackers and switch to Launchpad??? (Pretty please). What are the chances of installing something like flyspray, bugzilla, or even redmine or trac, on gpleda.org? Would that be substantially better than SF or Launchpad? (I don't have a lot of experience with them, but the projects I've seen that do host their own issue tracker it sure works/looks better) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Bugmail
On Wed, Mar 10, 2010 at 10:43 AM, Kai-Martin Knaak k...@familieknaak.de wrote: On Wed, 10 Mar 2010 18:12:20 +, Peter TB Brett wrote: It's been discussed before. http://archives.seul.org/geda/dev/Oct-2008/msg00139.html Oh yeah, I remember reading that now, thanks. :) But revisiting the topic once every year or so doesn't seem too bad, what was true then may not still be true. Before I read the whole thread: What was the upshot of this discussion? I think it boils down to this one from Ales: http://archives.seul.org/geda/dev/Oct-2008/msg00147.html There needs to be a very good reason to go through the hassle of hosting it on gpleda.org. Multiple gEDA projects willing to consolidate to one system on gpleda.org seemed like it would do it, but tough to put together. Time for maintenance, compute resources, and single-point of failure were an issue. Maybe it makes sense to have another machine and person run tracker.gpleda.org? Moving to some other hosting site like Google code or something was deemed acceptable, but there wasn't one that was clearly so much better than sourceforge that it would be worth it. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni alberto.macci...@gmail.com wrote: This: http://sourceforge.net/tracker/?group_id=73743atid=538813 which is also linked from: http://www.gpleda.org/developer.html Ah yes... unfortunately, at present, Sourceforge is where patches go to die*. I've had more success getting patches applied by emailing them to this list then posting them there, even though that is the preferred method according to the website. Hopefully that'll change and eventually a standard, actually used, procedure for community contributions will arise out of all of this (be it sourceforge or not). Jared *http://archives.seul.org/geda/user/Oct-2009/msg00258.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Wed, Mar 10, 2010 at 12:52 PM, Peter TB Brett pe...@peter-b.co.uk wrote: We (Peter C I) try quite hard to keep on top of patches to gschem/libgeda etc., y'know. Putting them in the tracker makes things a lot easier for us, and I really encourage you to keep doing that. Sorry, didn't mean to diminish your efforts, I appreciate it. As shown by the g-code patch, it does work on occasion. Just pointing out that as is putting a patch on sourceforge is no guarantee it will be seen. (the ... go to die quote was quoting Peter C). Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 9:48 AM, DJ Delorie d...@delorie.com wrote: Yes, I feel ignored by the developers. No, I am not happy about it. I agree. Those mean developers! Why can't they spend more time on PCB and less time with their families and jobs? They should be ashamed of themselves, not giving free software priority over things like food and shelter. He said nothing about developers spending too little time on the project, I think everyone understands about real life and appreciates the time put into the project. He said he was being ignored, which is an orthogonal issue. Clearly time has been spent by the developers working on PCB since Kai-Martin has submitted those patches, so it's a matter of prioritizing the time spent on the project, not prioritizing things in your own life. I believe part of the priviledge of having commit access to the public repository involves the responsibility to spend some of the small amount of time you have for the project going through and applying or denying and commenting on community contributions instead of just working on your own pet sub-project. I can't complain too loudly since all of my patches have eventually made it in, but it still irks me that this happens and I've seen a lot of good functionality and quality patches ignored. As an example Stephen and the other devs working on Icarus Verilog are fantastic about this and may provide a good example of how this could be done. Of course that may just be that Steve is able and willing to put in the extra time as the benevolent dictator of the project. One thing that I believe they do that could apply here (I could be wrong and maybe they will correct me) is while Steve is spending time working on a big re-work or feature, Cary forgoes the fun part of working on new features and does the grunt work of fixing bugs and going through community contributions and stuff. Then it will be Cary's turn next to work on something fun while Steve does some grunt work. However Steve manages to make it work, it certainly makes me want to spend more time working on Icarus every time I put a patch in, whereas I'm often hesistant to work on PCB, wondering if it will be ignored or not. Just some thoughts... carry on. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
On Mon, Mar 8, 2010 at 12:10 PM, DJ Delorie d...@delorie.com wrote: So what can we do? How can we get people with *less* experience more involved in solving this problem? That opens up the labor pool so to speak, letting the main developers work on the hard problems. How about this idea: I like the ideas, but am not sure if there will be enough support to staff two new groups with those not already developers.It seems like step #1a would be to clean up the SF repository of patches and bugs. Given access to change things on SF I'd be willing to start trudging through and cleaning it up if there was enough reason to believe that it would eventually be used. I would also be wiling to host a git repo to apply and test patches to for eventual inclusion in the public repo, again with the assurance that eventually it would get pulled in. However, alone I'm not sure if I'd make progress fast enough to keep up. Another problem is I unfortunately don't have much time for PCB development lately (as it isn't part of my day job), so don't actually use the software very much, so am probably not the best tester of new patches. (but I want to help because when I do get around to doing a PCB here and there, I like to have nice open source tools to do it with :) It'd be nice to get people to volunteer for this group who use PCB on a regular basis and would actual non-trivially test patches before they were recommended for the main line. The benefit I see of being in this group is the ability to get your own patches in front of the line. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
Since I'm in the mood to share my opinions today... :) On Mon, Mar 8, 2010 at 1:30 PM, Peter Clifton pc...@cam.ac.uk wrote: It might seem unfair that we're (or I am) trying to third party contributions to a higher standard than some of PCB's existing legacy code, but assuming it doesn't completely stifle contribution, encouraging high standard commits should aid PCB's long term quality. I think holding new additions, either from third parties or the devs, to a higher standard than existing code is a good thing. On the other hand, I am reluctant to bash down people's patch contributions with continual bombardment to polish them endlessly. Falling back to the I'm busy stance is lots less confrontational than me batting the patch back to you and demanding revisions before I apply it. Perhaps we should just apply the patch as is, and catch any bugs (if) they appear. I don't want to discourage future contributions. I think your email is a great response to KMK and loads better than ignoring it, saying I'm busy, or even applying it without being happy with it. I don't think it is inappropriate for devs to require contributors to follow guidelines and a certain standard (to a certain extent). It would be nice if we could agree on a standard format and process, which I guess is part of DJ's plan. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Bugmail
On Mon, Mar 8, 2010 at 2:09 PM, Peter Clifton pc...@cam.ac.uk wrote: Or - in my ideal word, can we just dump the crappy sourceforge bug trackers and switch to Launchpad??? (Pretty please). I'd like to add my vote for anything but sourceforge to track bugs and patches. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: I am such a troll for posting to slashdot
On Sat, Feb 27, 2010 at 12:31 AM, timecop time...@gmail.com wrote: standard parts library. And if you're making footprints and symbols, text files generated by scripts are FAR superior to any GUI. I'd never get 100-1000 pins right if I had to use a GUI. lol, every altium user disagrees. if you ever seen their IPC pattern / component wizard, you wouldn't be saying this. Would this be even (legally) possible for an open source app given the licensing of the IPC standards? (I have no idea what the license restrictions are, just asking) I've seen some gui-oriented pattern wizards for PCB floating around, but always preferred the script method myself so haven't tried them. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Message and Library windows
On Wed, Feb 24, 2010 at 12:15 PM, Frank Bergmann frank.g...@frajasalo.de wrote: On Tue, 23 Feb 2010 22:32:20 -0800, Jared Casper wrote: The functionality I saw someplace (was it in your repo?) to attach/embed the log window to the main window will help out with this problem as well I think. Maybe it was in this thread: http://thread.gmane.org/gmane.comp.cad.geda.user/27394 You find the patch(es) in the sf tracker: http://sourceforge.net/tracker/?func=detailaid=2779826group_id=73743atid=538813 Yup, that's what I was thinking of. I think it'd be cool to see this or something like it worked into the mainline. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: little slivers from pours
On Sun, Jan 10, 2010 at 6:04 PM, Ben Jackson b...@ben.com wrote: On Sat, Jan 09, 2010 at 05:41:05PM -0800, Ben Jackson wrote: I meant automatic solutions which would enforce the normal DRC rules on the slivers, eliminating any smaller than the minimum trace width. (replying to myself) Actually, I think I just figured out how to fix it AND do it live. I'll look into it. If I don't post back to the list in a few days someone pester me. ;-) Did you ever get time figure this out? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Message and Library windows
On Tue, Feb 23, 2010 at 3:53 PM, Peter Clifton pc...@cam.ac.uk wrote: I can't help but feel that some log messages are important enough to bother the user about - and others are not.. we'll have to see what people actually using it think, I'm not doing any PCB design work at the moment myself. Maybe add a Warn function along side Message (or something along those lines), and add a flag to HID.log that says whether or not to bring the log window to the foreground? Or go all out and add an enum for severity. It'd be easy to add the plumbing, the hard part would be to go through and decide what Message()s should be Warn()s, etc. I'm sure different severities could be displayed differently in the log quite easily as well... The functionality I saw someplace (was it in your repo?) to attach/embed the log window to the main window will help out with this problem as well I think. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB plugin for contoured traces?
On Sat, Feb 20, 2010 at 10:33 PM, Mark Rages markra...@gmail.com wrote: I had a quick question. I know there are several sparsely-documented plugins for PCB but I am trying to locate the one that makes the traces on the board look like they were laid out by hand the old-fashioned way with tape, resulting in curving, contoured traces instead of the standard auto-routed straight X/Y traces generated by default. As I recall you would route your board and then run this plugin as the final step since editing it afterwards was virtually impossible. Am I thinking of a different pcb layout program or does this plugin exist somewhere? http://www.delorie.com/pcb/puller/ You can also play with the GlobalPuller action. (type :GlobalPuller(), after you've saved your work!) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Changing key bindings in PCB
On Sat, Feb 20, 2010 at 8:49 PM, Larry Battraw lbatt...@gmail.com wrote: that's not documented somewhere? I tried editing the ~/.pcb-menu.res as well with no changes either. Not sure about the dynamic editing of shortcuts, but for the GTK hid you'll want to edit ~/.pcb/gpcb-menu.res (I believe, not at my computer right now...). Or put a gpcb-menu.res in your project directory. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Fri, Feb 12, 2010 at 8:22 AM, Peter Clifton pc...@cam.ac.uk wrote:
DJ; Or, you could get PCB to pass the search path to gnetlist. I think
that can be done using a gafrc file in the temp directory, with
(scheme-directory ${SCMDIR})
This could of course clash with an gafrc required by the project in the
first place, so is probably a bad idea.
I've hacked in to gnetlist a command line option to add directories to
the search path for a backend, enabling me to use a backend that is
not in the system path and not play with my normal .gafrc (I used -L
to mimic compilers searching for a library). Seems like that could've
come in handy here (although wouldn't help the bootstrapping problem
faced now). I could clean up the patch and send it in if the devs
think this is a good idea.
Jared
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Latex
On Sat, Feb 6, 2010 at 11:10 AM, gene glick carzr...@optonline.net wrote: Anyway, time to fire up the Chevelle SS396, pop the clutch, burn some rubber, and haul butt up the learning curve :) There are numerous guides and references around the internet as I'm sure you'll find, but http://en.wikibooks.org/wiki/LaTeX is one of the best references IMHO. I've been using latex for years now and still find new tricks in there on occasion. Not sure how it is as a beginners guide though, as it wasn't around when I was starting. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some questions about pcb
On Tue, Nov 24, 2009 at 12:30 AM, Kai-Martin Knaak k...@familieknaak.de wrote: Well, check the command line options given in the pcb manual -- Hardly any in the list is still valid with current pcb. That part comes from doc/pcb.texi, which is much less likely to get updated than the comments in parse_y.y, which is where the file format stuff comes from. I'm only saying the file format stuff should be valid (i.e. you are safe to use it); I'm not saying anything about the rest of the manual. :) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some questions about pcb
On Mon, Nov 23, 2009 at 2:32 PM, Kai-Martin Knaak k...@familieknaak.de wrote: By the way, is there a more comprehensive documentation of the pcb format available? http://pcb.gpleda.org/pcb-cvs/pcb.html#File-Formats ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some questions about pcb
On Mon, Nov 23, 2009 at 10:23 PM, Kai-Martin Knaak k...@familieknaak.de wrote: On Mon, 23 Nov 2009 19:33:45 -0800, Jared Casper wrote: http://pcb.gpleda.org/pcb-cvs/pcb.html#File-Formats Is this specification up to date? I am curious, because the command line options described in this document are mostly obsolete. It's possible that there are features (i.e. flags or something) implemented that aren't in that spec, but I would be pretty surprised if a file conforming to that spec didn't work. You can make the doc from the source in the repository, and it extracts the file format info directly from comments in the parser file (parse_y.y). So I would imagine it'd be pretty up to date, unless somebody changed the parser file without updating the comments. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: unpromoted visible attributes
On Sat, Oct 24, 2009 at 8:22 AM, Peter Clifton pc...@cam.ac.uk wrote: Unless there is anyone available to work on implementing it, the point is moot anyway! While that is true, if those with enough experience and clout in the project were to spend the time to agree on a plan, or a direction at least, then people like me could possibly put in the legwork to start making it happen. I'm not saying I'd have the time, but it's possible I will early next year, but I think a lot of us agree that this one of the bigger things that if fixed could really enhance the tool (along with things like the universal translator I've seen talked about a lot). As it is looking through the history, there's a lot of chatter about this, but no real agreement on what should be done, so if I were to have the time to do it, I'd have no idea where to go with it. :) Although I guess I may be underestimating what you mean by implementing it. With this kind of thing, the design will probably (at least should) take as much or more time than the actual coding, which means there probably needs to be a higher-up available to put in the time to design, or help design, it (which may be what you meant). Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: unpromoted visible attributes
Hi all, I'm working on a patch to libgeda and got in a little over my head so wanted to get some help/feedback... I wanted to make it possible to not promote visible attributes, as previously, all visible attributes were automatically promoted. This was annoying if say, I wanted the part number or description for some symbol to be visible on the schematic, but remain unpromoted as part of the project-global symbol so I could tweak it in one place if things changed. So I went ahead and added a promote-visible flag parallel to the promote-invisible flag, then in o_complex_is_eligible_attribute(), if promote-visible is false and the attribute isn't in always-promote-attributes, then don't promote it, even if it is visible. The problem is when a schematic file was being loaded, and a complex object read in, only attributes that were promotable, as defined by o_complex_is_eligible_attribute(), were marked invisible or deleted since there would be a schematic-level attribute coming up for it. This meant that an attribute that was promoted manually, but not identified as promotable, would end up with two copies, the copy from the complex because it wasn't promotable and the copy from the schematic that was added when it was promoted. This wasn't visible when all visible attributes were promotable, but now that a visible attribute could be unpromotable this would cause two visible copies of the manually promoted attribute to appear, clearly wrong. The fix was to check for attributes that were actually promoted, instead of those that were just promotable, and hide/remove those. Of course this can't happen until the attached attributes are read in, not at the point the complex is loaded. So I changed o_complex_remove_promotable_attribs() to o_complex_remove_promoted_attribs() (and changed the functionality to match the changed name), and called it in a_basic.c:o_read_buffer() after the attached attributes were read in instead of o_complex.c:o_complex_read(). Another hiccup was when a complex is copied. Previously, o_complex_remove_promotable_attribs() was called on the newly copied complex, which didn't make much sense to me since the source complex would already have them hidden or removed. The problem is (I think this was a problem before?) if the complex is copied, but the attached attributes aren't, then the copy will be missing (or have invisible) attributes that the user would probably expect to be there. This seems like a minor issue though. In any case, I removed the o_complex_remove_promotable_attribs() call from o_complex_copy(). So this all seems right and okay to me, but I'm not super familiar with the code, so if anyone has any feedback I would appreciate it. What side affects might this have that I haven't checked for? Can I assume that if an attribute attached to complex has the same name as one inside the complex, that it is a promoted version of that attribute and the internal one should be hidden or removed? I'll attach a copy of the patch that seems to be working for me. Thanks, Jared From 186ebda9e61afde11700fbfcb772e2d26c2b66e8 Mon Sep 17 00:00:00 2001 From: Jared Casper jaredcas...@gmail.com Date: Wed, 21 Oct 2009 22:41:23 -0700 Subject: [PATCH] Add promote-visible flag to libgeda. Previously, there was no way to only promote only some visible attributes when a component is instantiated, because if attribute promotion was on at all, all visible attributes would be promoted. With the promote-visible flag set to true, the old behavior exists. With it set to false, it is possible to completely specify exactly what attributes are promoted using always-promote-attributes (minus symversion). The caused a problem when a schematic file was being loaded, and a complex object read in, the attributes that were promotable were marked invisible or deleted since there would be a schematic-level attribute coming up for it. This meant that an attribute that was promoted manually, but not identified as promotable by o_complex_is_eligible_attribute(), would end up with two copies, the copy from the complex because it wasn't promotable and the copy from the schematic that was added when it was promoted. This wasn't visible when all visible attributes were promotable, but now that a visible attribute could be unpromotable this would cause two visible copies of the manually promoted attribute to appear, clearly wrong. The fix was to check for attributes that were actually promoted, instead of those that were just promotable, and hide/remove those. Of course this can't happen until the attached attributes are read in, not at the point the complex is loaded. So I changed o_complex_remove_promotable_attribs() to o_complex_remove_promoted_attribs() (and changed the functionality to match the changed name), and called it in a_basic.c:o_read_buffer() after the attached attributes were read in instead of o_complex.c:o_complex_read(). --- libgeda/include/i_vars_priv.h|1 + libgeda/include
Re: gEDA-user: unpromoted visible attributes
On Fri, Oct 23, 2009 at 4:33 PM, Peter Clifton pc...@cam.ac.uk wrote: This is a really nasty and troublesome issue, and there are lots of subtleties which can catch you out - such as embedded complex objects. I figured as much... :) Thank you for your detailed reply. There isn't an easy solution I can see, since it is impossible to define whether the in-symbol version of an attribute still matters to the back-ends. This wouldn't be so hard to define if we hate name=value where name is unique, but we already have cases where we support multiple name=something_1 and name=something_2 cases. When you have attributes with this name inside _and_ outside the symbol - which are wanted? Both? Does having one outside the symbol kill off or hide one or more _inside_, or does it add to the list? I guess I was thinking I could avoid this complexity by just dealing with whether or not an attribute was visible or not, not who masked what. But I guess since if keep_invisible=FALSE we are dealing with more than visibility... and one could imagine a case where multiple attributes with the same name should be visible.. I'm not sure I welcome any more complexity in this area.. it is already very difficult to ensure code changes relating to attribute promotion are sound - and adding more options makes it harder. I do see why you want it though, but I'm not sure your way helps. I'm of the mind that we should (in an ideal world) _remove_ all automatic attribute promotion (perhaps excepting the special case of symversion), and define some new rules as to how an aggregate list of attributes is constructed from a symbol, and attributes inside the schematic. I buy that, and would agree that automatic promotion is not the right thing to be doing (as evidenced by my trying to be able to prevent automatic promotion of every attribute except those that I explicitely name :) It's a tricky balance, as I would think you'd get the most flexibility by not having much, if any, logic about attributes in libgeda at all. All it does is keep a lit of text objects that are attached to an object and let the user of the library decide what to do with that list. However, that just moves the complexity to the user of the library. Gschem could know that an attached refdes should be displayed instead of the symbol version, but what about some attribute it doesn't know about? This might allow us to identify and hide attributes in the symbol which have been masked by attached (promoted if you will) attributes. We might be able to extend some syntax for explicitly back annotating the visibility of an attribute we no longer wish to see on the page. Yet another option - add some new file-format syntax for a special text ... Maybe a flag in the text object inside a symbol that indicates if an attached text object should override it or not? There are quite a few options here, but none seem to be perfect :) Are you sure? I think that was deleted in this commit: o_complex_copy() definitely still calls o_complex_remove_promotable_attribs. Not sure why though. I'm not in favour of any long term solutions which continue to keep a different in-memory representation of a symbol as it loads from disk - that includes not removing / hiding attributes ;) if libgeda doesn't touch what is defined in the .sym file, then gschem is going to need to gain some smarts. Every symbol has a visible text object like refdes=R?, and gschem will have to learn not to show this if there is an attached refdes (just as one example). Sorry to be both negative, and rather speculative in my reply. This is a complex area (no pun intended), and there are no obvious easy answers. No worries, after hacking for an hour I realized I was in over my head and that an hour or two wasn't going to cut it. And while I had a solution that was working, I was skeptical. :) BTW.. if you're looking at gEDA attributes, take a look at some of the code I've got queued up for some time in the 1.7.x development cycle relating to event based attribute processing: I'll take a look if I get a chance. Best wishes, Peter C. Thanks again for your quick and detailed reply, Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Information on PCB
On Tue, Oct 20, 2009 at 11:01 PM, Bert Timmerman bert.timmer...@xs4all.nl wrote: What remains to be done is to update and apply patch [1733991] in the SF tracker with the Doxygen configuration files. The patch is from 2007-09-09 and is having some bit rot, it needs to be updated since the pcb tree moved from CVS to git. ... on this note, I for one would be more willing/excited to contribute more to PCB if the developers were more responsive to patches. The SF tracker is full of open patches, some of which are discussed, but most of which sit there with no reply at all from the developers. I've also seen a few patches sent to this list (mine included, but others as well) go completely ignored. I realize this all takes precious time away from development, but IMHO, spending 15 minutes to look at a patch that someone has spent a good amount of time putting together (almost certainly way more time than it takes to review/apply it) is generally better spent than 15 minutes on the source code, whether or not the patch ends up getting accepted. It is hard to justify spending time working on a project when there's a decent chance that your work will be ignored. Just my two cents, /rant Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Information on PCB
On Wed, Oct 21, 2009 at 8:04 AM, Ineiev ine...@gmail.com wrote: OTOH my experience with PCB suggests that your work is not ignored if it is not ignored by yourself, and if even you don't need it then it is probably OK that it is ignored by other people. Sure, but it takes at least a bit more effort to make a patch ready to submit to the project (make the code more general purpose as opposed to a quick hack, clean up the code, test with other hid's/workflows, write out a good commit log, wait for sourceforge's slow pages, etc.) And I think if developers discourage their users from doing this (by visibly ignoring patches from others) they are missing out on a vast resource that is a huge part of open source software. Also, if I see a problem with the program, I'm definitely more motivated to fix it if I feel like I could fix it for everyone that uses the program, not just me. If I know it's just going to be for me, there's a good chance I'll just learn to work around it and move on, and that kind of attitude in the users isn't going to help in making the program better. Kind regards and BTW thanks for your patchs, You're welcome. :) And btw, I felt a little weird making this point as most of the few patches I have sent in have been applied, so I can't really complain much. However, I figured I would offer the suggestion because I still feel reluctant to spend much time on more because of all the others that weren't applied (or explicitely rejected) because I feel like it's a bit of a crap shoot, and if I feel that way, I'm sure I'm not the only one. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Information on PCB
On Wed, Oct 21, 2009 at 12:09 PM, Peter Clifton pc...@cam.ac.uk wrote: Sourceforge is where patches go to die.. unfortunate, but true. I'm not sure I even get mails about PCB's trackers. (I know I do for the gEDA ones though). That is unfortunate, looks like there are some helpful patches in there... Best to nag the people who might actually apply the patch (on list, or directly by private email - if on-list doesn't work ;)). Dan, DJ, Ben Jackson, myself Maybe a sentence on pcb.gpleda.org, on the Reporting Bugs page, that mentions it is better to email this list with patches then to post to Sourceforge is in order? Right now it says that SF is the place for bugs (which it may still be?) but one would assume that means it is also the place for patches (which it appears it isn't). I'm stuck in QA hell with the PCB+GL stuff at the moment ;) I definitely appreciate that effort, I haven't looked back after using your branch for the first time for my (limited amount of) PCB design. On Wed, Oct 21, 2009 at 12:35 PM, Peter Clifton pc...@cam.ac.uk wrote: Oh.. and for what its worth.. it is hard enough understanding, checking and reviewing _my own_ patches.. let along someone else's! The more complex / messy the code the patch deals with (and lets face it, PCB has a lot of messy and / or complicated code), the harder it is to be sure that a given patch is right. I can understand that, but remember you're GL patches are in a completely different ball park than most user-produced patches. :) I would expect a complex/messy change from a user to be fairly difficult to get into the mainline, but small bug fixes and tweaks that only touch a handful of lines shouldn't be too much trouble. Thanks again for all your work... I've had a good time learning how to make PCBs in this last year, which I definitely would not have done without free software to do it. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB PATCH] Bug fix - gtk hid layer buttons getting confused
Hi all, I figured four months was long enough to wait for a resend of this patch so it's not lost in the archives. Jared On Fri, Jun 12, 2009 at 11:15 PM, Jared Casper jaredcas...@gmail.com wrote: I tracked down and fixed a bug that has been annoying me in the gtk hid where the silk and rats layer buttons get out of sync when you revert the board (in sourceforge as bug #1988951). Patch attached. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 0001-Fix-a-bug-in-gtk-hid-which-caused-layer-buttons-to-g.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnucap development snapshot 2009-08-13
On Fri, Aug 14, 2009 at 2:27 PM, al davisad...@freeelectron.net wrote: There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-08-13.tar.gz Hi Al, The attached patch is still needed to compile with gcc 4.4. Jared On Fri, Jun 12, 2009 at 2:13 PM, Jared Casperjaredcas...@gmail.com wrote: On Thu, Jun 11, 2009 at 3:26 PM, al davisad...@freeelectron.net wrote: There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-06-11.tar.gz Nice job Al, gcc 4.4 changed the const-ness of some c library functions in the c++ headers [1], including strchr, so the attached patch is needed to compile with gcc 4.4. Jared [1] http://gcc.gnu.org/gcc-4.4/porting_to.html (see Strict null-terminated sequence utilities) gcc4.4.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: soldermask over vias and stuck footprints
On Tue, Aug 11, 2009 at 5:44 AM, Jasong...@lakedaemon.net wrote: have to. Especially since every time I delete a trace, I can't seem to create a new trace in it's place. pcb won't let me terminate it in the same place the old trace terminated. Yup, I'm missing something, again. And for future reference, you probably just need to re-optimize the rats nest. The rat line went away when the original trace completed the net, so when you delete the trace you need to re-generate that rat line (which will be done automatically with 'o'), otherwise pcb thinks the new trace is shorting nets because there isn't a rat line connecting the two. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: syntax error after gsch2pcb
On Mon, Jul 13, 2009 at 1:38 PM, Christianchristianlu...@gmx.de wrote: What is running wrong? I did not change the *.pcb file manually, so either there is a problem in/with pcb or gsch2pcb, right? Can you tell me, what I can do, to get it working? It could be one of your footprints is a .pcb file instead of a footprint file. Did you make any of your own footprints? If so check out one of the guides (see http://www.geda.seul.org/wiki/geda:pcb_tips#how_do_i_draw_a_new_footprint) to make sure you did it right. In particular, you can't just draw the footprint in pcb and chose file | save. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Parenthesis and commas in pcb action arguments
On Fri, Jun 19, 2009 at 8:57 PM, DJ Deloried...@delorie.com wrote: I pushed this one. It turns out we had a similar patch in the patch tracker, but I thought this one was better. The other one, however, had a nifty feature - if the string had multiple actions, it would run all of them. It would be nice if we could have that feature with this patch, since the function name *is* hid_parse_action*S* ;-) Thanks. Unless I'm missing something, hid_parse_actions() would already (and still) runs multiple actions if they are there, seperated by spaces. It could be more robust (currently if you put Action1(); Action2(); it'll fail, cause it isn't expecting the ';'s) but it should work if you use Action1() Action2(). In fact if I remember right, the mouse resource patch I put in earlier relies on that. Also, looks like a change uncommenting the fprintf(stderr, invoke: `%s'\n, rstr); line got added to the patch before commit. Other action-related thoughts... snip I think if we did that, the lesstif hid could be changed to just call the common routine and remove a lot of replicated code. I'll take a look at this when I get a chance, since I was just looking at that code. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnucap development snapshot 2009-06-11
On Thu, Jun 11, 2009 at 3:26 PM, al davisad...@freeelectron.net wrote: There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-06-11.tar.gz Nice job Al, gcc 4.4 changed the const-ness of some c library functions in the c++ headers [1], including strchr, so the attached patch is needed to compile with gcc 4.4. Jared [1] http://gcc.gnu.org/gcc-4.4/porting_to.html (see Strict null-terminated sequence utilities) gcc4.4.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Parenthesis and commas in pcb action arguments
On Thu, Jun 11, 2009 at 3:37 PM, DJ Deloried...@delorie.com wrote: I think 2 3 would be good ideas even if we fixed gsch2pcb. Two patches attached. First is for the pcb repo and adds quoting and escaping to the action argument parsing in pcb. I made the quoting rules similar to those for bash (single quotes give literal string, double quotes give literal string but allow escapes). Second is for the gaf repo and changes the pcbpins gnetlist backend to quote strings with a comma or close parenthesis in them. I didn't just quote all string so that for people without the functionality in pcb, non-problematic strings won't be affected, and problematic strings will just be a little weirder. Comments are welcome. Jared 0001-Allow-quoted-strings-and-escaped-characters-in-actio.patch Description: Binary data 0001-Quote-pins-names-if-they-contain-comma-or-close-pare.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB PATCH] Teaching GTK hid to use mouse resources
On Sun, Jun 7, 2009 at 11:05 AM, DJ Deloried...@delorie.com wrote: Also - could you add support for the scroll wheel to gpcb-menu.res et al? patch attached. Jared 0001-Adding-ability-to-customize-mouse-scroll-action-in-G.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem's new pretty menus
On Mon, Jun 8, 2009 at 3:25 PM, DJ Deloried...@delorie.com wrote: It was this bit from Jared, probably... D'oh! You're right, my bad. Still new to the source and learning all the interactions, but should've tested exporting, duh.. I'll fix this ASAP (busy at work now, but hopefully in a few hours). Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB patches
2009/6/7 DJ Delorie d...@delorie.com: Patch 0001: Doesn't build; lesstif has errors: hid/lesstif/main.c: In function ‘lesstif_mod1_is_pressed’: hid/lesstif/main.c:3335: error: ‘alt_pressed’ undeclared (first use in this function) hid/lesstif/main.c:3335: error: (Each undeclared identifier is reported only once hid/lesstif/main.c:3335: error: for each function it appears in.) My mouse patch removed alt_pressed as it removed the only use of it (at the time). Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB PATCH] Teaching GTK hid to use mouse resources
Thanks Ineiev and Steven for looking at it, attached is a modified patch to address your comments, with replies inlined below. Additional comments are of course always welcome On Mon, Jun 1, 2009 at 11:20 PM, Ineiev ine...@gmail.com wrote: Nice work. I tried it a little and found only one small shortcoming: when ctrl-rightclicked, PCB switches to panning (the board moves with the cursor); when right-clicked (without ctrl) again, it exits panning. I think you'll be able to fix this easily. Good catch, it was just a bug in the default gpcb-menu.res, there was no ctrl-right click resource defined so it would start a pan, but there was a ctrl-right release defined, so it do that instead of un-pan. I just made it do the ctrl-right click action (change the cross hairs) on the down click, not sure why it was on the release before. On Tue, Jun 2, 2009 at 3:16 PM, Steven Michalske smichal...@gmail.com wrote: need to look at gtk code for mod1, and OSX. see patch 1 from http://archives.seul.org/geda/user/May-2009/msg00457.html option (alt) returns 113, not GDK_MOD1_MASK Might want to define a list of modifier masks, and allow for translation in the HIDs You have it now no translation needed, except that under GTK and OSX, the option(alt) key needs translation. I think fixes for the OSX stuff is an orthogonal patch, but I made the modifier code in the mouse handling stuff more general. hid_resource.h #define's M_Shift, M_Ctrl, and M_Mod(n), which the gui hid's use to set the masks passed to the mouse stuff. So the hid's can use any number of modifier keys up to the number of bits in a uint minus three. I left M_Alt as an alias for M_Mod(1) and M_Multi as an alias for M_Mod(2) from the lesstif hid. I was using (less general) #define's before, but wasn't explicit in their use in the gtk hid, I made it more explicit in gtk/gui.h. You can now also use mod# in the resource file. Could use strstr and tolower for parse modifiers to be more robust. done. I have a 10 button mouse... +#define MAX_MOUSE_BUTTON 5 But laptop trackpads are normally 7, to include left and right scroll. I made everything dynamically allocated so you can have as many buttons as you want. The method I ended up using adds a bit of overhead at runtime handling each click to find the right actions to take, but it seemed negligible. The basic approach was to use an array of button numbers, an array of modifier masks, and an array of Resource*'s, all dynamically allocated, and find the index into the button numbers and mod masks that match what happened, then perform the actions in the corresponding Resource*. It ended up slightly more complicated to try and reduce the runtime overhead, but not much more. Jared 0001-Teaching-GTK-hid-to-use-mouse-resources.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB build changes
On Tue, Jun 2, 2009 at 3:54 PM, Dan McMahill d...@mcmahill.net wrote: ok, here is what I have found. [snip] Thanks for the lesson on maintainer mode, never really knew what it was all about. So we have 2 options that I've tested and both seem to work. 1) remove AM_MAINTAINER_MODE 2) now that we can detect if we're building from git sources then if we are building from git sources and we are building the docs then forcefully enable maintainer mode (along with a message so the user knows what has happened). I think I can go either way and would be curious about other opinions (opinions including some justification as to why). I would vote for #1, as I'm in the camp that doesn't buy the justification for maintainer mode; it seems like a hack for bad dependencies, the rules should only fire when necessary, and when they are necessary, why wouldn't you want them to fire? You're going to need all the tools anyway to build from git sources (unless all those ./autogen.sh generated files are in the repo, which feels wrong), so you aren't removing any build-time dependencies. I guess maybe it is more justified for a HUGE project where remaking them could take a really long time, and a spurious timestamp change or something could cause grief; however, I don't think pcb is big enough. Maybe keep maintainer mode but enable it by default and allow --disable-maintainer-mode, thus those who really don't want those rules in can disable it if they want? Although that may be too non-standard to ever really get used? pcb.info in the srcdir makes sense I guess. Can you manually add dependencies for version.texi beyond pcb.texi to account for included sources? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PCB PATCH] Teaching GTK hid to use mouse resources
PCB said: ghid_load_menus(): Mouse resources are currently ignored by the GTK HID. Please feel free to submit a patch to implement this! I had some free time over the weekend and have been wanting to get my hands dirty in the PCB code so I took a crack at this and wanted to get some feedback. Attached is a patch with a detailed commit message of what I did, but the general idea was to move the lesstif hid's handling of the mouse resources into a common hid file (which I called hid_resource) and have the gtk hid use that instead of being hardcoded. This way the hid's are only responsible for catching the button press, determining which modifier keys were active, then calling the common code to handle it. The common code does what the lesstif hid does, calls the actions defined in the resource file. In theory more common stuff could be moved to hid_resource, the code to find and load the resource file, for example, is nearly identical in both hids. I changed up the Mouse resource in gpcb-menu.res to match the hardcoded behavior of the gtk hid as closely as possible (see the commit message for details). I've played around with it a bit and it seems to be working, but as this my first time meddling with the code, I'm sure I missed some stuff. If anybody has time to look it over and/or try it out that would be great. Comments regarding the approach, formatting, style, etc. are all appreciated (I did my best to match the style of the surrounding code). Jared 0001-Teaching-GTK-hid-to-use-mouse-resources.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB build changes
On Fri, May 29, 2009 at 4:25 AM, Dan McMahill d...@mcmahill.net wrote:
There may be some rough edges left so I'd appreciate any feedback and
problem reports around this change.
Some comments:
I did a fresh clone of the git repo then ./autogen.sh ./configure
make. Which, if I understood your post correctly, should work now
(i.e. I don't need --enable-maintainer-mode or --disable-doc anymore).
However, this failed with:
restore=: backupdir=.am$$ \
am__cwd=`pwd` cd . \
rm -rf $backupdir mkdir $backupdir \
if (/bin/sh /home/jcasper/play/geda/pcb/pcb-clean/missing
--run makeinfo --version) /dev/null 21; then \
for f in pcb.info pcb.info-[0-9] pcb.info-[0-9][0-9]
pcb.i[0-9] pcb.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi \
cd $am__cwd; \
if /bin/sh /home/jcasper/play/geda/pcb/pcb-clean/missing --run
makeinfo -I . \
-o pcb.info pcb.texi; \
then \
rc=0; \
cd .; \
else \
rc=$?; \
cd . \
$restore $backupdir/* `echo ./pcb.info | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
pcb.texi:9: @include `version.texi': No such file or directory.
makeinfo: Removing output file `pcb.info' due to errors; use --force
to preserve.
make[3]: *** [pcb.info] Error 1
make[3]: Leaving directory `/home/jcasper/play/geda/pcb/pcb-clean/doc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/jcasper/play/geda/pcb/pcb-clean/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jcasper/play/geda/pcb/pcb-clean'
make: *** [all] Error 2
I noticed you removed version.texi with the comment that you have all
the tools and makefile rules for them to be regenrated anyway. So am
I missing something? make version.texi in the doc directory claims
Nothing to be done for 'version.texi'. and there is no version.texi
in the directory. A glance at the generated Makefile in doc and there
is only one rule explicitely for verison.texi:
'$(srcdir)/version.texi: # $(srcdir)/stamp-vti'. uncommenting the
dependency makes the build succeed, but I don't know enough about the
doc building system to know if that is the right thing to do (or how
to prevent it from being there, starting from the .am).
Another interesting thing to note is that when building in a seperate
build directory (not in the source tree), with the source tree in
../pcb-clean, it says 'makeinfo: Removing output file
`../../pcb-clean/doc/pcb.info' due to errors; use --force to
preserve.' i.e. it appears to be making pcb.info in the source
directory rather than the build directory, which seems wrong. Most
other generated stuff (*_size.texi, .png's, .gif's, and .pdf's) are
correctly generated in the build/doc directory.
Also, 'make distclean' removes
doc/{fractional_size,letter_size,metric_size,wire_size}.texi and
po/pcb.pot, which are tracked by git. Seems like all these are
generated files that can be removed from git (along with the others,
like version.texi, that you removed).
Let me know if there is anything I can do to help (or if I missed
something?). I may look at it more in depth later on tonight, to try
to figure out the right solution, if I get a chance
Jared
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: missing PCB GUIs
On Sun, May 31, 2009 at 6:17 PM, Ralf chunti1...@gmail.com wrote: I already installed all that's associated with the keyword PCB, and I kind of wonder if I missed a certain library or something here? I am not sure if anyone had any similar experience before? could someone please tell me what to do to fix this problem? There are two different guis for PCB, one built with the lesstif toolkit and one with the gtk toolkit. From the sounds of it, you are seeing the lesstif gui; I think you'll find the gtk gui more what you are expecting. I don't use Ubuntu, but I would imagine if you uninstall pcb-lesstif and make sure pcb-gtk is installed you'll get the gtk gui. You'll probably want to go through a tutorial/getting started guide as both gui's are much more powerful if you know the tricks. http://www.delorie.com/pcb/docs/gs/gs.html is a good one. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB PATCH: configure script issues
Hi all, Playing with some different builds of pcb tonight I noticed some issues with the configure script, and put together a quick patch to fix them (attached, hopefully gmail doesn't screw it up). First, the check for pkg-config was not happening unless dbus was enabled. This was causing later PKG_* calls to fail when dbus wasn't enabled, causing build problems. The pkg-config man page says, Note that if there is a possibility the first call to PKG_CHECK_MODULES might not happen, you should be sure to include an explicit call to PKG_PROG_PKG_CONFIG in your configure.ac. The attached patch puts a call to PKG_PROG_PKG_CONFIG() in at the top level and removes the AC_PATH_PROG call inside the if (enable_dbus). (PKG_PROG_PKG_CONFIG does a call to AC_PATH_TOOL internally) Second, the newly added toporouter output requires cairo, whose CFLAGS and LIBS were not being included in guis besides gtk, causing build problems. The patch adds a PKG_CHECK_MODULES for cairo if the toporouter output is enabled and adds CAIRO_CFLAGS and CAIRO_LIBS to CFLAGS and LIBS. Finally, the lpr hid depends on the ps hid being included to build, so just omitting ps from the --with-exporters would break the build. Instead of putting in a specific test, I added a more general feature of allowing a hid.conf to define deps which is a list of other hids that must be included. Once the HIDLIST is fully created, a small loop goes through and checks that each of the included hid's dependencies are met, erroring out if they are not. Dunno, maybe that was overkill, but it was just few lines. I'd be glad to fix up/edit the patch if there are problems, comments, suggestions, etc. I tried to match the style of other parts of the script as much as possible. Jared Casper 0001-Some-cleanup-of-configure-script.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Project sources web page update
I've always wondered why many of the packages on the Project Sources web page are so out of date. So in case it is just a matter of nobody taking the time to do it, I spent a few minutes and bumped the version numbers to the latest release (as best as I could tell). Attached is a patch for sources.html and a list of packages to download to geda.seul.org/dist (both assuming you still want to mirror the sources on geda.seul.org). Otherwise, may I suggest just removing the list of other sources that aren't kept up to date, lest somebody think gwave hasn't seen development since 2006, or that 0.8.5 is the latest Icarus Verilog, etc. Jared Casper jaredcas...@gmail.com http://prdownloads.sourceforge.net/gerbv/gerbv-2.2.0.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02-tools.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02-models-spice3f5.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02-models-ngspice17.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02-models-jspice3-2.5.tar.gz http://www.gnucap.org/devel/gnucap-2009-02-02-models-bsim.tar.gz ftp://icarus.com/pub/eda/verilog/v0.9/verilog-0.9.1.tar.gz ftp://icarus.com/pub/eda/verilog/v0.8/verilog-0.8.7.tar.gz http://prdownloads.sourceforge.net/gspiceui/gspiceui-v0.9.65.tar.gz http://gtkwave.sourceforge.net/gtkwave-3.2.1.tar.gz http://prdownloads.sourceforge.net/gwave/gwave-20080127.tar.gz http://prdownloads.sourceforge.net/gwave/gwave2-20090213.tar.gz http://prdownloads.sourceforge.net/ngspice/ng-spice-rework-18.tar.gz version-updates.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [iverilog] running the git source of Icarus Verilog
On Sat, Aug 16, 2008 at 12:55 PM, Günter Dannoritzer [EMAIL PROTECTED] wrote: So with the latest development snapshot it gave me an assertion, but with the git version a segmentation fault. I saw this behavior as well, so I don't think it is your setup. Something must have changed in git between the snapshot and your bug report that prevented the assertion from firing and it went on to segfault. Note that the bug has been fixed in git now (although for some reason I had to make clean then re make for it to pick up the new parsing code, maybe there is a bug in the Makefiles?) Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
