Re: gEDA-user: PCB: simple FreeType fonts implementation -- update?
On 05/13/2011 01:55 PM, Colin D Bennett wrote: It looked to me like most of the work was done in the patch but it was left to rot! In fact it was not. I was rebasing it next time few nights ago. Perhaps the only thing left to be done is to embed the font files in the .pcb file so that it doesn't depend on system fonts (future-proofing files, exchanging between systems, etc.). This thing was not left. the fonts may be embedded or referenced (the latter may be a requirement of the font licensing terms); and system independence was (sort of) ensured with using a fixed version of FreeType included with the patch set. What was left is a decent support of combining characters for scripts like Indic or polytonic Greek; this would probably require building another library (pango is the nearest candidate). Any chance to revive this? The characters may look great, but nobody really needs it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where is pcb-20100929 for Win32 ?
On 05/10/2011 12:50 PM, Bob Paddock wrote: Why are individuals who are trying to help the project being held to a higher standard that the projects own download page? Because they are not. anybody who distributes binaries must provide the corresponding source. http://pcb.gpleda.org/ 's download link does not contain GTK sources, sources of compilers or sources for the Windows operating system. http://pcb.gpleda.org doesn't contan any binaries. Doesn't PCB's source code actually predate the GPL? No, it doesn't. When and who put it under GPL? Its original author, Thomas Nau, in the previous millenium; every new piece of code since then was put under the same license, and no contributor suggested anything different. All of this legal crap just takes the fun and desire out of working on the project. It also ensures that my contribution won't be used to mistreat you. Best wishes, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: skip drc
On 03/11/2011 10:51 AM, Levente Kovacs wrote: On Thu, 10 Mar 2011 17:47:58 + Could you please upload it to the tracker? It might get more attention. I'd really see it checked into the HEAD. Every time I compile a new PCB, I have to patch. Browsing the source, I see that there is some movement to support non-copper layers. I don't know the state of that. Still I think it is a good feature. I see it is useful now, but how will it extend into the future? I think pushing it would be harmful if we had to completely replace it with incompatible set of new features. The attribute, PCB::skip-drc, doesn't only turns off DRC by itself, it also makes the layer invisible for connection lookups. is there any sane way to explain this in the documentation (and I believe this feature must be documented when pushed into master)? And yes, I shall put it to the tracker within few nights (if nobody else); I'd just like to know whether anybody has smart ideas about it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: skip drc
Hi, On 03/10/2011 12:42 PM, Levente Kovacs wrote: I have rewritten the skip_drc patch (originally written by Ineiev) to apply to the current git HEAD. Thank you! it would be nice if someone added corresponding bits of documentation to the patch. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pads, mask and solder paste
Stephen Ecob wrote: I've added this patch to the corresponding LaunchPad bug, #718342 My opinion is that the patch improves PCB's generation of the solder paste and has a very low risk of creating undesired side effects. I recommend it for early incorporation into GIT head. I'll push it tomorrow if nobody minds. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
On 2/20/11, Stephen Ecob silicon.on.inspirat...@gmail.com wrote: On Mon, Feb 21, 2011 at 1:51 PM, Kai-Martin Knaak k...@lilalaser.de wrote: Congrats to your new status! The geda project got a new dev! This is really good news :-) +1 :-) Thanks to the whole community! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: DRC does not correctly check pad clearance
On 2/19/11, Kai-Martin Knaak k...@lilalaser.de wrote:
I can confirm for fairly recent versions of pcb and pcb+gl.
In your example, DRC starts to complain at 7.1 mil. That is, 2 mil
too late. The discrepancy grows as the clearance grows. With an
11 mil gap I had to ask for 14.1 mil minimum distance to receive
DRC errors.
It looks like Bloat in IsLineInPolygon() should be doubled like in the
attachment.
diff --git a/src/find.c b/src/find.c
index 615659d..a819b4a 100644
--- a/src/find.c
+++ b/src/find.c
@@ -2670,7 +2670,7 @@ IsLineInPolygon (LineTypePtr Line, PolygonTypePtr Polygon)
return false;
if (TEST_FLAG(SQUAREFLAG,Line)(Line-Point1.X==Line-Point2.X||Line-Point1.Y==Line-Point2.Y))
{
- BDimension wid = (Line-Thickness + Bloat + 1) / 2;
+ BDimension wid = (Line-Thickness + 1) / 2 + Bloat;
LocationType x1, x2, y1, y2;
x1 = MIN (Line-Point1.X, Line-Point2.X) - wid;
@@ -2684,7 +2684,7 @@ IsLineInPolygon (LineTypePtr Line, PolygonTypePtr Polygon)
Box-Y1 = Polygon-Clipped-contours-ymax + Bloat
Box-Y2 = Polygon-Clipped-contours-ymin - Bloat)
{
- if (!(lp = LinePoly (Line, Line-Thickness + Bloat)))
+ if (!(lp = LinePoly (Line, Line-Thickness + Bloat * 2)))
return FALSE; /* error */
return isects (lp, Polygon, true);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
Kai-Martin Knaak wrote: I can confirm, that this patch removes the problem both in git-head and in Peters gl version. :-) Thank you! On minor nit: The wasn't attached but part of the body of the email. So I had to copy-pasted it to a patch file. This patch file did not apply right away. The reason was, that the body gets mangled on its course. Some component seems to have replaced tabs with spaces. Unfortunately, one of the matching lines contained a tab... Sorry; I'll bear the issue in mind in the future. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
Kai-Martin Knaak wrote: Ineiev wrote: I made a wrong assumption (segs variable should be at least 1). diff --git a/src/polygon.c b/src/polygon.c I can confirm, that this patch removes the problem both in git-head and in Peters gl version. :-) Pushed to git-head. Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
Peter Clifton wrote: On Wed, 2011-02-16 at 05:27 +0100, Kai-Martin Knaak wrote: The current head of his pcb+gl branch omits some polygons in my layouts. See the attached screen shots. The working copy of pcb+gl was pulled from repo.or.cz on December 6th. Unfortunately, I wasn't able to locate the the exact version I pulled, or the commit that started the regression. Urm - I think the bug got into git HEAD too. I think this commit has caused a regression, but I'm not quite sure why. commit 2d8dc8a3a3a55158b4e6278dd9f40588e4111c2d Author: Ineiev ine...@users.berlios.de Date: Sun Dec 12 00:28:48 2010 -0500 [PATCH] fix bug 2793480 (vias/arcs-to-polygon clearances) frac_circle(): introduce radius_adjustment factor to make the polygon outline the arc rather than connet points on the arc ArcPolyNoIntersect(): compute number of segments so that polygon diverges from the arc no more than 0.02 of required thickness; adjust outer arc radius like in frac_circle() Any ideas why? I made a wrong assumption (segs variable should be at least 1). diff --git a/src/polygon.c b/src/polygon.c index c552f3c..0235495 100644 --- a/src/polygon.c +++ b/src/polygon.c @@ -498,8 +498,8 @@ ArcPolyNoIntersect (ArcType * a, BDimension thick) ry = MAX (a-Height - half, 0); segs = 1; if(thick 0) -segs = a-Delta * M_PI / 360 - * sqrt(sqrt((double)rx*rx + (double)ry*ry)/delta_th/2/thick); +segs = MAX (segs, a-Delta * M_PI / 360 + * sqrt(sqrt((double)rx*rx + (double)ry*ry)/delta_th/2/thick)); segs = MAX(segs, a-Delta / ARC_ANGLE); ang = a-StartAngle; ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: dev account (polygon regression in pcb+gl)
Peter Clifton wrote: On Sat, 2011-02-19 at 19:02 +, Ineiev wrote: Lets make this your first commit once you get a developer account setup. You will need to provide Ales the public half of an SSH key you generate Attached (not sure whether any steps are needed to ensure its' integrity). and setup .ssh/config with these lines: Host git.gpleda.org... Thanks! ssh-rsa B3NzaC1yc2EBIwAAAgEA3DHk7bDnFmQPQah/qsn9ze3rDbM31jQmRt3ZLWiARnXwivt5jML6aqO1ziZTeIua7R+FZFG6anmcGaRDJU3SySpZtpeKbeadvL59yCuNGderYTu7O3kwhbwcpku+8M2fbHJx3dBog7A3LI9j6Odeeo9UdQ524AvcBjbIWrVd4S2I5/mNfc1UXUPegI2OSUocEAixRchcTTW6aEm0jOwrT2f2BuK91XcpS+C/Zm8d0nG7gckauMRulTFzEV1PdT5z9abJRHMlMgbLa18fHl5kZEh3rKJM3P6WpbjbX1hWwOEz18cVGRSqfUQaUS0hYmX9zsJnUZKiXhg4E1S4VEMtaGhLx6twmxx8s3wf9mIyVp0j72Sz1P/rYtSrzMt5FzRV2WA05/BMakeKCcSnFi6G2AkU/xqTIQhw+oMPE6FIZug1PavdZOFz1EkFwNyE+PDPjC/DIaPPE6WiFT2m2wQTuRziq/9KxWupugH3pEHP/p+vIB08SzG5tp9RjLxaLeLuZTE4oUVLCIleGMe8A3c4dMQ4jI0c/G978hlb2cZmlEP+ucBHL3lYhWXEiA51LFlNGlTmSTVZXNAiIKJMy8gvSdpfk72KXT4X2QzfVUc/e+wW5iDUEBKE5vFGkevHCxzxS9bCNL1tY64d3E5sh8kZejY7N9122JN/L8VcvGCjnKU= d...@xbl3p.blpx.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: If you also think the PCB lower-case letter 's' is ugly, here's a replacement
On 11/22/10, Mark Rages markra...@gmail.com wrote: On Mon, Nov 22, 2010 at 1:29 PM, Colin D Bennett co...@gibibit.com wrote: How hard would it be to make use of the freetype library to handle all vector-based fonts? I imagine the font outlines could be converted to line elements fairly easily... ? pcb's fonts are special: they are a single line wide. When you need the smallest letters that a given silk process can print legibly, you want those single-line fonts. For larger fonts, freetype would be great, and save us the machinations of creating the text in inkscape or something and importing it with pstoedit. Discuss also using QCAD fonts, please. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: batch testing gschem features
On 10/12/10, Peter TB Brett pe...@peter-b.co.uk wrote:
Why oh why doesn't gschem --version DTRT?
Peter :-(
Does it mean that a change like in the attachment has any chance
in future gschem development?
Cheers,
Ineiev
From 13ca491fba616a0cc0e8457d32d05529c4daa405 Mon Sep 17 00:00:00 2001
From: ineiev d...@desdichado.(none)
Date: Tue, 12 Oct 2010 15:13:14 +0400
Subject: [PATCH] display version string in verbose mode
---
gschem/src/parsecmd.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gschem/src/parsecmd.c b/gschem/src/parsecmd.c
index 8b72d6a..4ccdacc 100644
--- a/gschem/src/parsecmd.c
+++ b/gschem/src/parsecmd.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111 USA
*/
#include config.h
+#include version.h
#include stdio.h
#ifdef HAVE_UNISTD_H
@@ -111,5 +112,10 @@ int parse_commandline(int argc, char *argv[])
verbose_mode = FALSE;
}
+ if (verbose_mode) {
+printf(gEDA/gschem version %s%s.%s\n, PREPEND_VERSION_STRING,
+PACKAGE_DOTTED_VERSION, PACKAGE_DATE_VERSION);
+ }
+
return(optind);
}
--
1.6.0.4
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: batch testing gschem features
Hello,
I want to make some documentation regenerate itself with different
versions of gschem. it outputs EPS figures using a script like this:
(load gschem-lightbg)
(output-orientation portrait)
(output-type extents no margins)
(output-color enabled)
(output-text ps)
(paper-size 0.0 0.0)
(gschem-use-rc-values)
(gschem-postscript dummyfilename.eps)
(gschem-exit)
The hard part is to force the color map with light background; in newer
versions (since geda-1.5.2) we use
(load (build-path geda-rc-path print-colormap-lightbg))
for this purpose.
Perhaps the right way would be to test which script works,
however, when gschem -s test.scm test.sch is invoked
with the wrong script, it breaks the script execution, and
I have to close it manually.
Then I thought that the right script can be determined
parsing the version string:
echo (gschem-exit) quit.scm
gschem_version=$(${GSCHEM} -s quit.scm 21 |grep version|sed s/.* //)
and so on. this approach worked at least since geda-1.1.2.
unfortunately, since geda-1.5.3 gschem doesn't output
the version to stdout. it probably means that the sequence
will break when the commands to load the color map change again.
Any ideas?
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: Some code-cleanup-patches
Hello, Felix Ruoff wrote: The second one (0004...) introduces the gtk-default-dialog for 'overwrite-existing-file - confirmation'. gtk_file_chooser_get_do_overwrite_confirmation() was introduced in gtk-2.8; PCB current requirement is 2.4.0. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GNUduino - Arduino made with gEDA
Hi, jeffrey antony wrote: The lock names is not set. If possible can you just download the pcb file ( http://github.com/jeffreyantony/GNUduino/blob/master/GNUduino.pcb )and try to move the component descriptors? So you can easily provide a solution for me. I tried a lot but no use. I tried to move the descriptors and saw just one problem: when there is a copper line under the silkscreen you select the line rather than the text. this can be avoided switching off the copper layer. Hope that helps, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On 10/7/10, DJ Delorie d...@delorie.com wrote: Cross-compiler is not a component of the operating system on which the executable runs. Nearly every embedded OS comes *with* a cross compiler. It just doesn't happen to run *on* the embedded OS. One could argue that such a cross compiler is a component of the embedded OS. Most probably, yes, when somebody supplies the toolchain; do you think one also could argue when nobody does? Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb crooked traces
Andrew Poelstra wrote: On Fri, Oct 08, 2010 at 06:31:33PM +0800, Steven Michalske wrote: If so... Guys change the converters and have at your hearts content. It should be a 2 hour patch. Then we have file-format compatibility to deal with, and I'm sure there are weird cases that implicitly depend on the base unit (which should be rooted out at some point anyway, I know). I don't think it would be a 2 hour patch: 100., .01, 10. and so on are used in many places to convert from PCB units to mils or inches; there is no couple of macros used consistently for this purpose. Now for conversion errors, are you really seeing errors in your metric PCBs? Maybe not, but we -do- see the cursor position given as 8., 7. instead of whole numbers, and these long strings overlap the GUI sometimes (I put a patch on the tracker about this when I first got here.) Hard to read, and irritating. I deal with it without changing PCB units: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-annoyingdecimals.squashed (and BTW the Lesstif HID provides another way to avoid that tail of nines). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
John Griessen wrote: On 10/06/2010 10:30 AM, John Doty wrote: You don't need to deliver *any* source code unless it is requested by the user. OK. Let me rephrase that to, What would I need to make available to comply with GPLv3 for a GPLv3 library delivered as part of an open hardware system?. I'm wanting to clarify the difference between GCC used to make the system's delivered code and libopenstm32 used to make the system's delivered code, where parts of libopenstm32 are included in the output. I'm thinking I would need to make available libopenstm32 source, but not GCC source. Actually, the GPLv3 includes an exception about compilers: However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. (unmodified) GCC for sure is a generally available free program. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
DJ Delorie wrote: I have: http://gpl-violations.org/faq/sourcecode-faq.html. And yes, Harald Welte has made some vendors to distribute their sources with entire toolchain. Unusual, since the compiler... part of the GPL was specifically added for DJGPP, which is not normally distributed... with the operating system. Yes, it is; because cross-compilers are unusual. Even Microsoft's compiler is not normally distributed with the operating system. The ... removes too many words and changes the meaning of that clause. IMHO that part of the GPL means that if you use, for example, libc from a standard compiler, you need not include libc in your source set, unless you include the whole compiler too (i.e. a modified compiler/libc). The key wording is normally distributed with the major components, not normally distributed with the operating system. True. the GPLv2 reads: major components (compiler, kernel, and so on) of the operating system on which the executable runs. Cross-compiler is not a component of the operating system on which the executable runs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20100929 released
Great!
Now let me suggest some kind of Patchlevel 0.
Most of these patches deal with well-known issues
discussed on the list or on the tracker; some of them
are years old.
Of course, there are lots of more patches e.g. on the tracker;
I just randomly picked some obvious ones that were not likely
to cause strong objections.
The developers have no resources to push them into master;
however, the users could collect them and release inofficially.
If somebody is interested, we could discuss what we want
to be included, and what we don't; if nobody is interested,
I'll just stack more patches than otherwise expected and
use them locally.
Best wishes,
Ineiev
From 9b8d3cda761b1a719d10768cd34d4908c70023a5 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sun, 12 Sep 2010 08:14:14 +
Subject: [PATCH 01/12] RectPoly: check arguments to avoid empty polygons
fixes PCB segfaults when running DRC #3064413
---
src/polygon.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/polygon.c b/src/polygon.c
index 586e8cc..72e65d5 100644
--- a/src/polygon.c
+++ b/src/polygon.c
@@ -330,8 +330,8 @@ RectPoly (LocationType x1, LocationType x2, LocationType
y1, LocationType y2)
PLINE *contour = NULL;
Vector v;
- assert (x2 x1);
- assert (y2 y1);
+ if (x1 = x2 || y1 = y2)
+return NULL;
v[0] = x1;
v[1] = y1;
if ((contour = poly_NewContour (v)) == NULL)
--
1.6.5.2
From 1e25441acaa40ceff0518e71b6d5f87cbc322bb8 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.sourceforge.net
Date: Fri, 20 Feb 2009 20:19:01 +0300
Subject: [PATCH 02/12] misfix annoying decimals bug 1741659
bug report by Kai-Martin Knaak
also make polar coordinates less verbous
---
src/hid/gtk/gui-misc.c | 88 ++-
1 files changed, 63 insertions(+), 25 deletions(-)
diff --git a/src/hid/gtk/gui-misc.c b/src/hid/gtk/gui-misc.c
index a607a69..5ffbbd6 100644
--- a/src/hid/gtk/gui-misc.c
+++ b/src/hid/gtk/gui-misc.c
@@ -1,10 +1,8 @@
-/* $Id$ */
-
/*
*COPYRIGHT
*
* PCB, interactive printed circuit board design
- * Copyright (C) 1994,1995,1996 Thomas Nau
+ * Copyright (C) 1994,1995,1996,2009 Thomas Nau
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -42,8 +40,6 @@
#include dmalloc.h
#endif
-RCSID ($Id$);
-
#define DEFAULT_CURSORSHAPEGDK_CROSSHAIR
#define CUSTOM_CURSOR_CLOCKWISE(GDK_LAST_CURSOR + 10)
@@ -549,6 +545,53 @@ ghid_set_status_line_label (void)
ghid_status_line_set_text (text);
}
+/* returns an auxiliary value needed to adjust mm grid.
+ the adjustment is needed to prevent ..99 tails in position labels.
+
+ All these are a workaround to precision lost
+ because of double-integer transform
+ while fitting Crosshair to grid in crosshair.c
+
+ There is another way to fix: report mm dimensions with %.3f, like
+ in the Lesstif hid; but this reduces the information
+ */
+static double
+ghid_get_grid_factor(void)
+{
+ /* when grid units are mm, they shall be an integer of
+1 mm / grid_factor_per_mm */
+ const int grid_factor_per_mm = 1;/*min grid is .1 um PCB unit*/
+ if (Settings.grid_units_mm)
+return floor (PCB-Grid * COOR_TO_MM * grid_factor_per_mm +.5) /
+grid_factor_per_mm;
+ return 0;
+}
+/* transforms a pcb coordinate to selected units
+ adjusted to the nearest grid point for mm grid */
+static double
+ghid_grid_pcb_to_units (double x, double grid_factor)
+{
+ double x_scaled = (Settings.grid_units_mm? COOR_TO_MM: 1./100) * x;
+ double nearest_gridpoint;
+
+ if (PCB-Grid 4.5)/*nothing to adjust: the grid is too fine */
+return x_scaled;
+ /* adjustment is not needed for inches
+ probably because x/100 is always 'integer' enough */
+ if (!Settings.grid_units_mm)
+return x_scaled;
+ nearest_gridpoint = floor (x / PCB-Grid + .5);
+ /* honour snapping to an unaligned object */
+ if (fabs (nearest_gridpoint * PCB-Grid - x) 1)
+return x_scaled;
+ /* without mm-adjusted grid_factor
+ (return floor (x / PCB-Grid + .5) * PCB-Grid * COOR_TO_MM),
+ the bug appears for 0.1 or 0.05 mm grid at coordinates more than 4000 mm.
+ grid_factor makes the stuff work at least up to 254 m,
+ which is 100 times more than maximum board size as of Aug 2010. */
+ return nearest_gridpoint * grid_factor;
+}
+
/* ---
* output of cursor position
*/
@@ -556,32 +599,27 @@ void
ghid_set_cursor_position_labels (void)
{
gchar text[128];
+ int prec = Settings.grid_units_mm ? 4: 2;
+ double grid_factor = ghid_get_grid_factor();
if (Marked.status)
-{double scale, dx, dy, r, a;
- scale = Settings.grid_units_mm ? COOR_TO_MM: 1. / 100;
- dx = (Crosshair.X - Marked.X) * scale;
- dy = (Marked.Y
Re: gEDA-user: Zero length pins
On 9/28/10, kai-martin knaak k...@familieknaak.de wrote: So flexible, that it can't deal properly with µ and ?, let alone right to left scripting, or Chinese. What do you mean? gschem renders both Arabic and Chinese texts without visible problems. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb minor release, C++ and Gtk cleanup
Kai-Martin Knaak wrote: And please, please apply as much of Peter Cliftons pcb version as possible before you start. It is not only about the openGL and 3D hack for visuals, but a huge bag of little useful improvements. Let's not loose them on the way. I hope this won't break the Lesstif HID. Peter's branch is still several times slower than elder GUIs on all my machines, which makes the GL-based renderer actually unusable for me. Kind regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB DRC crash with due to bloat / shrink breaking gemoetry
On 9/12/10, Peter Clifton pc...@cam.ac.uk wrote:
On Sun, 2010-09-12 at 06:57 +, ineiev wrote:
Peter Clifton wrote:
I think the rule it is triggering on in this case is probably bogus, and
the Shrink parameter should not apply to a pad solid inside a polygon.
IMHO DRC should report an error if pad width is less than minimum trace
width.
...
I'm still not sure the DRC check is correct though.
It probably would be more correct when the pad is merged
into a polygon to check whether the width of the resulting copper
is more than minimum, however, PCB code seems to lack proper
routines to check this. For example, DRC happily ignores
Potential for broken trace in the attached file due
to incorrect check in IsPolygonInPolygon:
/* first check if both bounding boxes intersect. If not, return quickly */
if (P1-Clipped-contours-xmin - Bloat P2-Clipped-contours-xmax ||
P1-Clipped-contours-xmax + Bloat P2-Clipped-contours-xmin ||
P1-Clipped-contours-ymin - Bloat P2-Clipped-contours-ymax ||
P1-Clipped-contours-ymax + Bloat P2-Clipped-contours-ymin)
return false;
The check only works in some cases when the overlapping areas of
the polygons touch the bounding box limits.
And this is a different misfeature.
Also, we'll have to
do a cursory scan to ensure that nothing is trying to call with x2 x1
or y2 y1. I realise there are/were asserts to this effect, but since
hardly anyone build PCB with debugging asserts disabled, you can never
be 100% sure!
Or ensure that the results of RectPoly are checked. I find single
place to modify:
diff --git a/src/polygon.c b/src/polygon.c
index 586e8cc..108b585 100644
--- a/src/polygon.c
+++ b/src/polygon.c
@@ -1644,12 +1644,13 @@ r_NoHolesPolygonDicer (POLYAREA * pa,
}
else
{
- POLYAREA *poly2, *left, *right;
+ POLYAREA *poly2, *left = pa, *right = NULL;
/* make a rectangle of the left region slicing through the
middle of the first hole */
poly2 = RectPoly (p-xmin, (p-next-xmin + p-next-xmax) / 2,
p-ymin, p-ymax);
- poly_AndSubtract_free (pa, poly2, left, right);
+ if (poly2)
+ poly_AndSubtract_free (pa, poly2, left, right);
if (left)
{
POLYAREA *cur, *next;
Kind regards,
Ineiev
poly.pcb
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 DRC crash with due to bloat / shrink breaking gemoetry
Peter Clifton wrote: On Mon, 2010-09-13 at 06:00 +, Ineiev wrote: Or ensure that the results of RectPoly are checked. I find single place to modify: Shouldn't be a problem in the dicer. From recollection, poly_* boollean routines check for NULL one one of the two input polygons, and will return the appropriate result for the requested boolean operation. poly_AndSubtract_free appears to assert rather than check. In addition, I'm fairly sure the dicer won't generate bad rect polygons. It won't, if the square of the polygon is non-zero: poly2 = RectPoly (p-xmin, (p-next-xmin + p-next-xmax) / 2, p-ymin, p-ymax); ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB DRC crash with due to bloat / shrink breaking gemoetry
Peter Clifton wrote: Perhaps someone might like to take a stab at fixing this bug: https://sourceforge.net/tracker/index.php?func=detailaid=3064413group_id=73743atid=538811 I've triaged the cause of the crash, but don't really have the energy to start digging into the DRC engine's rules. I think the rule it is triggering on in this case is probably bogus, and the Shrink parameter should not apply to a pad solid inside a polygon. IMHO DRC should report an error if pad width is less than minimum trace width. Still, the test needs fixing, and there could be other legitimate cases where the geometry is broken just enough by the shrink / bloat parameter to cause problems. Why not just fix RectPoly this way: diff --git a/src/polygon.c b/src/polygon.c index 586e8cc..72e65d5 100644 --- a/src/polygon.c +++ b/src/polygon.c @@ -330,8 +330,8 @@ RectPoly (LocationType x1, LocationType x2, LocationType y1, LocationType y2) PLINE *contour = NULL; Vector v; - assert (x2 x1); - assert (y2 y1); + if (x1 = x2 || y1 = y2) +return NULL; v[0] = x1; v[1] = y1; if ((contour = poly_NewContour (v)) == NULL) Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On 9/6/10, Peter Clifton pc...@cam.ac.uk wrote:
...
confusing non-copper with skip-drc is
probably a bad idea.
...
Thank you, your suggestion is really reasonable.
I renamed the attribute to PCB::non-copper
and corrected the variable name and comments accordingly;
probably it does not make the patch perfect,
but I have no better idea at the moment.
Regards,
Ineiev
From 5ec7e281f01fa09b041537e4f4eb8237cda1cc9c Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Tue, 7 Sep 2010 10:30:44 +0400
Subject: [PATCH] recognize PCB::non-copper layer attribute
layers with `PCB::non-copper' attribute are excluded
from DRC (both copper- and silkscreen-specific) and connection lookup
---
src/action.c |2 +-
src/action.h |2 ++
src/find.c | 23 +--
src/global.h |2 ++
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/action.c b/src/action.c
index 32e294c..2936080 100644
--- a/src/action.c
+++ b/src/action.c
@@ -6957,7 +6957,7 @@ find_element_by_refdes (char *refdes)
return NULL;
}
-static AttributeType *
+AttributeType *
lookup_attr (AttributeListTypePtr list, const char *name)
{
int i;
diff --git a/src/action.h b/src/action.h
index ee116e8..7b64e05 100644
--- a/src/action.h
+++ b/src/action.h
@@ -46,4 +46,6 @@ void warpNoWhere (void);
/* In gui-misc.c */
bool ActionGetLocation (char *);
void ActionGetXY (char *);
+AttributeType * lookup_attr (AttributeListTypePtr list, const char *name);
+
#endif
diff --git a/src/find.c b/src/find.c
index 593be70..17f042f 100644
--- a/src/find.c
+++ b/src/find.c
@@ -81,6 +81,7 @@
#include global.h
+#include action.h
#include crosshair.h
#include data.h
#include draw.h
@@ -826,6 +827,8 @@ LookupLOConnectionsToPVList (bool AndRats)
/* now all lines, arcs and polygons of the several layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-non_copper)
+ continue;
info.layer = layer;
/* add touching lines */
if (setjmp (info.env) == 0)
@@ -1173,6 +1176,8 @@ LookupPVConnectionsToLOList (bool AndRats)
/* loop over all layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-non_copper)
+ continue;
/* do nothing if there are no PV's */
if (TotalP + TotalV == 0)
{
@@ -2900,6 +2905,18 @@ ListsEmpty (bool AndRats)
return (empty);
}
+static void
+reassign_non_copper_flags (void)
+{
+ int layer;
+
+ for (layer = 0; layer max_layer; layer++)
+{
+ LayerTypePtr l = LAYER_PTR (layer);
+ l-non_copper = lookup_attr ((l-Attributes), PCB::non-copper) != NULL;
+}
+}
+
/* ---
* loops till no more connections are found
*/
@@ -2907,6 +2924,7 @@ static bool
DoIt (bool AndRats, bool AndDraw)
{
bool new = false;
+ reassign_non_copper_flags ();
do
{
/* lookup connections; these are the steps (2) to (4)
@@ -3349,6 +3367,7 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
/* check if there are any pins or pads at that position */
+ reassign_non_copper_flags ();
type
= SearchObjectByLocation (LOOKUP_FIRST, ptr1, ptr2, ptr3, X, Y, Range);
@@ -3365,8 +3384,8 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
int laynum = GetLayerNumber (PCB-Data,
(LayerTypePtr) ptr1);
- /* don't mess with silk objects! */
- if (laynum = max_layer)
+ /* don't mess with silk and other non-conducting objects! */
+ if (laynum = max_layer || ((LayerTypePtr)ptr1)-non_copper)
return;
}
}
diff --git a/src/global.h b/src/global.h
index bb78abc..bb82b79 100644
--- a/src/global.h
+++ b/src/global.h
@@ -301,6 +301,8 @@ typedef struct /* holds information about one layer */
char *Color, /* color */
*SelectedColor;
AttributeListType Attributes;
+ int non_copper; /* whether to ignore the layer when looking up connections
+ and checking against copper-specific design rules */
}
LayerType, *LayerTypePtr;
--
1.6.0.4
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB DRC arcs (was: Functional blocks...)
On 9/4/10, Windell H. Oskay wind...@oskay.net wrote: On Sep 4, 2010, at 4:30 AM, Ineiev wrote: Hello, DJ; On 9/4/10, DJ Delorie d...@delorie.com wrote: Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. Could you elaborate on the arcs, please? what it doesn't do? I've been running into trouble with the DRC and arcs, myself. I discovered it when doing some simple tests of the toporouter-- certain arcs produce DRC errors when there clearly is none-- says that there isn't 10 mils of clearance when there obviously is much more than that. Doh! Bad link. Correct one is: http://evilmadscientist.com/source/temp/topo_puzzle.pcb Thank you! arguably it is not the arc, it's the squared pin. Cheers, Ineiev diff --git a/src/find.c b/src/find.c index 593be70..f340962 100644 --- a/src/find.c +++ b/src/find.c @@ -149,8 +149,8 @@ RCSID ($Id$); #define IS_PV_ON_ARC(PV, Arc) \ (TEST_FLAG(SQUAREFLAG, (PV)) ? \ IsArcInRectangle( \ - (PV)-X -MAX(((PV)-Thickness+1)/2 +Bloat,0), (PV)-Y -MAX(((PV)-Thickness+1)/2 +Bloat,0), \ - (PV)-X +MAX(((PV)-Thickness+1)/2 +Bloat,0), (PV)-Y +MAX(((PV)-Thickness+1)/2 +Bloat,0), \ + (PV)-X -MAX(((PV)-Thickness+1)/2,0), (PV)-Y -MAX(((PV)-Thickness+1)/2,0), \ + (PV)-X +MAX(((PV)-Thickness+1)/2,0), (PV)-Y +MAX(((PV)-Thickness+1)/2,0), \ (Arc)) : \ IsPointOnArc((PV)-X,(PV)-Y,MAX((PV)-Thickness/2.0 + fBloat,0.0), (Arc))) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On 9/3/10, Stefan Salewski m...@ssalewski.de wrote:
On Fri, 2010-09-03 at 11:53 +0200, Pawel Kusmierski wrote:
Can I get pcb to either treat a layer other than the default silk as
non-metal
(so it would not short pads and mess up nets),
No, currently we have only one silk layer. You may miss-use other
copper layers for that task -- it may work when that layer is not in
your real copper layer groups, but unfortunately it still connects to
vias and can generate shorts.
Probably this patch may be used as a workaround.
Put your non-copper layer into a distinct layer group
(File-Preferences-Layers, Groups Tab), add to the layer an attribute
named PCB::skip-drc (Edit-Edit attributes of-Current Layer),
and PCB should skip the layer during DRC and connections lookup.
Kind regards
From 1bec53aea09312b99ee14c40fe7efcaa80158467 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sat, 4 Sep 2010 14:12:46 +0400
Subject: [PATCH] recognize PCB::skip-drc layer attribute
layers with `PCB::skip-drc' attribute are excluded
from DRC and connection lookup
---
src/action.c |2 +-
src/action.h |2 ++
src/find.c | 23 +--
src/global.h |1 +
4 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/action.c b/src/action.c
index 32e294c..2936080 100644
--- a/src/action.c
+++ b/src/action.c
@@ -6957,7 +6957,7 @@ find_element_by_refdes (char *refdes)
return NULL;
}
-static AttributeType *
+AttributeType *
lookup_attr (AttributeListTypePtr list, const char *name)
{
int i;
diff --git a/src/action.h b/src/action.h
index ee116e8..7b64e05 100644
--- a/src/action.h
+++ b/src/action.h
@@ -46,4 +46,6 @@ void warpNoWhere (void);
/* In gui-misc.c */
bool ActionGetLocation (char *);
void ActionGetXY (char *);
+AttributeType * lookup_attr (AttributeListTypePtr list, const char *name);
+
#endif
diff --git a/src/find.c b/src/find.c
index 593be70..ac94f4b 100644
--- a/src/find.c
+++ b/src/find.c
@@ -81,6 +81,7 @@
#include global.h
+#include action.h
#include crosshair.h
#include data.h
#include draw.h
@@ -826,6 +827,8 @@ LookupLOConnectionsToPVList (bool AndRats)
/* now all lines, arcs and polygons of the several layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
info.layer = layer;
/* add touching lines */
if (setjmp (info.env) == 0)
@@ -1173,6 +1176,8 @@ LookupPVConnectionsToLOList (bool AndRats)
/* loop over all layers */
for (layer = 0; layer max_layer; layer++)
{
+ if (LAYER_PTR (layer)-no_drc)
+ continue;
/* do nothing if there are no PV's */
if (TotalP + TotalV == 0)
{
@@ -2900,6 +2905,18 @@ ListsEmpty (bool AndRats)
return (empty);
}
+static void
+reassign_no_drc_flags (void)
+{
+ int layer;
+
+ for (layer = 0; layer max_layer; layer++)
+{
+ LayerTypePtr l = LAYER_PTR (layer);
+ l-no_drc = lookup_attr ((l-Attributes), PCB::skip-drc) != NULL;
+}
+}
+
/* ---
* loops till no more connections are found
*/
@@ -2907,6 +2924,7 @@ static bool
DoIt (bool AndRats, bool AndDraw)
{
bool new = false;
+ reassign_no_drc_flags ();
do
{
/* lookup connections; these are the steps (2) to (4)
@@ -3349,6 +3367,7 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
/* check if there are any pins or pads at that position */
+ reassign_no_drc_flags ();
type
= SearchObjectByLocation (LOOKUP_FIRST, ptr1, ptr2, ptr3, X, Y, Range);
@@ -3365,8 +3384,8 @@ LookupConnection (LocationType X, LocationType Y, bool AndDraw,
int laynum = GetLayerNumber (PCB-Data,
(LayerTypePtr) ptr1);
- /* don't mess with silk objects! */
- if (laynum = max_layer)
+ /* don't mess with non-conducting objects! */
+ if (laynum = max_layer || ((LayerTypePtr)ptr1)-no_drc)
return;
}
}
diff --git a/src/global.h b/src/global.h
index bb78abc..1c7ca26 100644
--- a/src/global.h
+++ b/src/global.h
@@ -301,6 +301,7 @@ typedef struct /* holds information about one layer */
char *Color, /* color */
*SelectedColor;
AttributeListType Attributes;
+ int no_drc; /* whether to ignore the layer when checking the design rules */
}
LayerType, *LayerTypePtr;
--
1.6.0.2
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
Hello, DJ; On 9/4/10, DJ Delorie d...@delorie.com wrote: Our DRC engine could use a complete rewrite. It doesn't get arcs right, for example. Could you elaborate on the arcs, please? what it doesn't do? Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Color silk layers in pcb
On 9/4/10, DJ Delorie d...@delorie.com wrote: Ineiev, thanks for the patch, it applied fine. However, I'm unable to find the (Edit-Edit attributes of-Current Layer). Is it placed somewhere else, or can I manually edit the .pcb file for the same result? I'm using pcb source tree from git, version 1.99z. Do you have a local ~/.pcb/gpcb-menu.res or something? The .pcb file format is documented in the doc/pcb.pdf generated file, including the Attributes() syntax. In case your gpcb-menu.res lacks this item, you can issue the action through (Window-Command entry), the command is 'Attributes(Layer)'. Hope that helps ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Adding options for manufacturer
Hi, On 5/27/10, Jose Luis Diaz Bernabe jldiazm...@gmail.com wrote: I'm new in PCB, and PCB manual suggested use vendor file to specify set of sizes for a PCB manufacturers. But I'd like to know how change defaults of individual layers gerbers as: top layer: mirror; units: mm, etc. and produce it? Too I'd like to know how to add options to drills files: supress LZ, presicion, absolute, etc.? Some options are supported by the patchset at http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/gerber. they are not going to be merged mainstream because the feature is rarely useful and often confusing (there also was some discussion at http://sourceforge.net/tracker/?func=detailaid=2156903group_id=73743atid=538813). Hope that helps ___ 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)
Hi,
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
0001 makes PCB reinserts the text into the tree when the length may be changed;
0002 aligns the default symbols on solder side (t.pcb is a test case).
If any of the devs have any
suggestions for how I can better contribute to PCB, I'd be glad to
hear it.
I second.
Cheers,
Ineiev
From b7af7773d5edb9110c96f538e9b050c582d4bd56 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sat, 7 Mar 2009 08:12:21 +0300
Subject: [PATCH] misfix a bug of edit text action
re-insert the text object into the rtree when it's size may change
HOW TO REPRODUCE
Put a short text (o); change it's name (N in default GTK shortcuts)
to something much longer (longlonglonglong text);
(1) zoom in at the end of the text; the text disappears
(2) click at the end of the text; the text is not selected/deselected
---
src/change.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/change.c b/src/change.c
index 4d42bc3..70bec00 100644
--- a/src/change.c
+++ b/src/change.c
@@ -1066,10 +1066,12 @@ ChangeTextName (LayerTypePtr Layer, TextTypePtr Text)
return (NULL);
EraseText (Layer, Text);
RestoreToPolygon (PCB-Data, TEXT_TYPE, Layer, Text);
+ r_delete_entry (Layer-text_tree, (BoxTypePtr) Text);
Text-TextString = NewName;
/* calculate size of the bounding box */
SetTextBoundingBox (PCB-Font, Text);
+ r_insert_entry (Layer-text_tree, (BoxTypePtr) Text, 0);
ClearFromPolygon (PCB-Data, TEXT_TYPE, Layer, Text);
DrawText (Layer, Text, 0);
return (old);
--
1.6.0.4
From 90ea11d2c6aef91906a123d2da13dd29dc2c9ab2 Mon Sep 17 00:00:00 2001
From: Ineiev ine...@users.berlios.de
Date: Sat, 28 Feb 2009 11:41:20 +0300
Subject: [PATCH] misfix default symbol on solder
the symbol was shifted
HOW TO REPRODUCE
Remove a symbol from the font embedded in a PCB file;
put a text using undefined symbol in the solder layer;
rotate it
In the unpatched version the default symbol is shifted relatively
to the text; in the patched it is aligned correctly
---
src/draw.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/draw.c b/src/draw.c
index d06813d..98d2e05 100644
--- a/src/draw.c
+++ b/src/draw.c
@@ -1594,6 +1594,14 @@ DrawTextLowLevel (TextTypePtr Text, int min_line_width)
RotateBoxLowLevel (defaultsymbol, 0, 0, Text-Direction);
+ if (TEST_FLAG (ONSOLDERFLAG, Text))
+ {
+ defaultsymbol.X1 = SWAP_SIGN_X (defaultsymbol.X1);
+ defaultsymbol.Y1 = SWAP_SIGN_Y (defaultsymbol.Y1);
+ defaultsymbol.X2 = SWAP_SIGN_X (defaultsymbol.X2);
+ defaultsymbol.Y2 = SWAP_SIGN_Y (defaultsymbol.Y2);
+ }
+
/* add offset and draw box */
defaultsymbol.X1 += Text-X;
defaultsymbol.Y1 += Text-Y;
--
1.6.0.4
t.pcb
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 patches (was: [PATCH 1/7] PCB localization)
Jared Casper wrote: If it makes it any easier. All five of these patches can be pulled from: git://github.com/jaredcasper/pcb.git Thank you. _I_ shall. ___ 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.
Hello,
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.
2. Run rename-bool.sh with the pcb source as the working dir. This
replaces switches all .c and .h files over to using bool, true,
and false. It then goes to work on the .y and .l files. My sed
fu is weak, so it only does the replacement in the top and
bottom sections of those files. There is not much to change in
the middle sections, and step 3 sorts it out.
I forgot to mention that this script can be used with git filter-branch.
If one has some existing commits that haven't been pushed, one can
convert them over to bool like so:
git filter-branch --tree-filter rename-bool.sh HEAD...${HASH}
Replacing ${HASH} with the hash of the most recent commit shared with
the main repository. This *should* remove merge conflicts to do with
bool.
Why not apply it to your local branch instead of PCB master?
Best wishes,
Ineiev
___
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.
Hi, On 5/26/10, Robert Spanton rspan...@zepler.net wrote: I started working on stuff in the PCB source, and found that it uses a typedef called 'Boolean' rather than the c99 bool type. Please find three patches that transition PCB over to using the c99 bool in the following directory: http://srobo.org/~rspanton/geda/pcb-bools/ What are the advantages? is current implementation broken for some platform, modern or future? The PCB build scripts tell the compiler to use the 'gnu99' standard (C99 with GNU extensions) I believe it does not in general case, and current sources do build with c89 compilers as far as I know. Kind regards, Ineiev ___ 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
Hi; 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 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. It works for me with autoconf-2.63, automake-1.10.2; that is, nothing changes. Some of patches from my collection will need to be rebased manually, but I have no other objections. Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB 2009 snapshot, two bugs
On 4/3/10, Stefan Salewski m...@ssalewski.de wrote: And if we move a label we get always Request for bounding box of unsupported type 1024 in Log Window. Looks like http://sourceforge.net/tracker/?func=detailaid=2893717group_id=73743atid=538811 Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Funny pad rotation
On 3/23/10, DJ Delorie d...@delorie.com wrote: Looks like a fundamental design issue. We use the X layer to draw lines, which includes pads, but with the tiny offsets in the x,y points, we end up passing two points to the X layer that have the same coordinates, so it draws a zero-angle line. If you zoom in far enough, eventually rotates the pad on the screen. To get this right, we'd have to somehow calculate when X is going to do the wrong thing based on our scaling, and draw those lines as polygons instead, so that we can do the math with more precision. I thought it was a very well-known feature; it was reported in 2007 (http://sourceforge.net/tracker/?func=detailaid=1800872group_id=73743atid=538811); I support a patch for rectifying it here: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-dspdances.squashed Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Funny pad rotation
Hi, On 3/25/10, Peter Clifton pc...@cam.ac.uk wrote: Patch looks good, but I'm not sure it is necessary to pass 5 vertices (manually closing the polygon). Quite right, thank you; I've updated it in repo.or.cz: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-dspdances.squashed Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB won't compile
Hello, On 3/18/10, Kovacs Levente leventel...@gmail.com wrote: I couldn't compile a fresh copy of PCB cloned from git. It fails with: hid/lesstif/menu.c: In function ‘lesstif_call_action’: hid/lesstif/menu.c:856: error: ‘x’ undeclared (first use in this function) hid/lesstif/menu.c:856: error: (Each undeclared identifier is reported only once hid/lesstif/menu.c:856: error: for each function it appears in.) hid/lesstif/menu.c:856: error: ‘y’ undeclared (first use in this function) I have no idea what can be wrong, so I have no suggestion. Sorry. x and y in that line should evidently be px and py. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Making circles in PCB
Hello; On 2/26/10, timecop time...@gmail.com wrote: It can't be that simple or else someone would have done it alreay. On Fri, Feb 26, 2010 at 1:12 PM, DJ Delorie d...@delorie.com wrote: I think the first thing before this discussion gets out of hand is to asap add clicking x/y to set center and clicking again to set radius or just popping up a dialogbox to set radius/correct XY after one click in 'circle' tool mode. Go ahead. Actually, it is not that hard. here is a very old patch modifying arc tool: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/ineiev-arctool Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB GIT: missing members in SettingType
Hello; It looks like some parts of recent changes were not actually pushed: diff --git a/src/global.h b/src/global.h index 1462e50..3794448 100644 --- a/src/global.h +++ b/src/global.h @@ -635,6 +635,8 @@ typedef struct /* some resources... */ *ScriptFilename,/* PCB Actions script to execute on startup */ *ActionString, /* PCB Actions string to execute on startup */ *FabAuthor, /* Full name of author for FAB drawings */ + *GnetlistProgram, /* gnetlist program name */ + *MakeProgram, /* make program name */ *InitialLayerStack; /* If set, the initial layer stack is set to this */ Boolean DumpMenuFile;/* dump internal menu definitions */ LocationType PinoutOffsetX, /* offset of origin */ Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Test gschem bug...
On 1/19/10, DJ Delorie d...@delorie.com wrote: I personally recommend people never use the 3b/3c method of distributing sources (written offer for three years) as it sets you up for a DDNS - *anyone* can ask you for the sources, and you *must* provide them at cost. OTOH that is a chance to make reasonable money from the program; the must does not impose any strict terms and I believe the distributor can eventually provide even 10,000,000,000 copies if needed. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Test gschem bug...
On 1/21/10, DJ Delorie d...@delorie.com wrote: You must not charge more than actual costs, so you're not going to profit on the distribution. A DDOS would just use up all your time. You are right; thanks for explanations. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: DC power feed on xDSL circuits
Hello, Michael, On 1/14/10, Michael Sokolov msoko...@ivan.harhan.org wrote: 1. What is the benefit from having the DC blocking capacitor across the centre split in the transformer's primary winding? What harm would there be if someone took that capacitor off the BOM and simply shorted those pins on the transformer to make the primary winding effectively non-split? My guess is that in some cases there may be unintended DC bias which could put the transformer core into non-linear region. I think if DC conductivity is needed it should be provided with another part. 2. Suppose that I do want my CO-side terminal unit to provide DC power feed on the line - say, to power a mid-span repeater. Where would I need to connect my DC power source? Would it need to be connected across the centre split of the line transformer's primary winding in parallel with the cap, or would it simply go across the copper pair instead? As I understand, it should _not_ be connected across the centre split for the same reason (DC current will run through the transformer). Some of those SDSL transformers (which are all custom parts) were apparently designed for fairly high DC current, so it seems like connecting the DC power source (or load) across the centre split is the way it's done. I have no idea; probably, those transformers could be used for different purposes. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB line limit of 255 in pcb
On 12/26/09, Anthony Shanks yamazak...@gmail.com wrote: When loading up a netlist file, PCB complains if a single line is over 255 characters and cuts out the rest of the line. I have a net with lots of components connected to it (gnd) and the line ends up being way over 255 characters. The workaround I have done is to split the net into two nets with identical names (both named gnd), but pcb also doesn't play nice with this as it doesn't rat the nets properly to gnd and it I manually connect the new nets together it complains about the nets being short. Of course they are shorted but they have the same name. Have you tried to split lines with `\'? Hope that helps, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Beginner Confusion
On 12/26/09, Tim Golden timgol...@bandtechnology.com wrote: I have never used printed circuit board software before. http://www.gpleda.org/sources.html claims that the development version is 1.5.4 and that the stable version is 1.6.0 Shouldn't the development version be a 1.7.x type of number based on a stable 1.6? I did download the 1.5.4 version and successfully built it but do not seem to have the m4 element libraries so that I don't have resistor footprints for instance. I've discovered this in working through Bill Wilson's tutorial page AFAIK M4 footprints are in a different package, PCB (http://sourceforge.net/projects/pcb). Hope that helps, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerbv failure to parse sample gerber file (data attached)
On 12/18/09, timecop time...@gmail.com wrote:
Gerbv and libgerbv (lastest git version as well) fails to parse the
attached files.
Try the attachment. gerbv does not recognises D2 as D02,
despite the format documents this option.
The patch does not fixes all issues with these files, though.
These are opened fine by other viewers ex. ViewMate etc.
Gerbv seems to think its not a gerber file, though it is 247x
Actually, the files are not quite orthodoxal; e.g. gnd.gbr begins with *.
Thanks,
Ineiev
diff --git a/src/gerber.c b/src/gerber.c
index bba2211..d91b6e1 100644
--- a/src/gerber.c
+++ b/src/gerber.c
@@ -805,11 +805,11 @@ gerber_is_rs274x_p(gerb_file_t *fd, gboolean *returnFoundBinary)
found_ADD = TRUE;
dprintf (found_ADD\n);
}
- if (g_strstr_len(buf, len, D00)) {
+ if (g_strstr_len(buf, len, D00) || g_strstr_len(buf, len, D0)) {
found_D0 = TRUE;
dprintf (found_D0\n);
}
- if (g_strstr_len(buf, len, D02)) {
+ if (g_strstr_len(buf, len, D02) || g_strstr_len(buf, len, D2)) {
found_D2 = TRUE;
dprintf (found_D2\n);
}
@@ -904,10 +904,10 @@ gerber_is_rs274d_p(gerb_file_t *fd)
if (g_strstr_len(buf, len, %ADD)) {
found_ADD = TRUE;
}
- if (g_strstr_len(buf, len, D00)) {
+ if (g_strstr_len(buf, len, D00) || g_strstr_len(buf, len, D2)) {
found_D0 = TRUE;
}
- if (g_strstr_len(buf, len, D02)) {
+ if (g_strstr_len(buf, len, D02) || g_strstr_len(buf, len, D2)) {
found_D2 = TRUE;
}
if (g_strstr_len(buf, len, M0)) {
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerbv failure to parse sample gerber file (data attached)
On 12/18/09, timecop time...@gmail.com wrote: At least they're visible now. Does it show them correctly? Here are other things in gnd.gbr making gerbv uneasy: (1) missing M02* in end of file; (2) I think this string is invalid: %AD*% (3) Gerbv seems not to parse the aperture macro (AMD24_Thermal) correctly; probably this is not a valid definition not because it does not end in *% (* and % are separated with a newline). Actually, I have no idea on how good is Gerbv macro apertures support (I believe this is too complicated feature to use it it production). Kind regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerbv failure to parse sample gerber file (data attached)
On 12/18/09, Ineiev ine...@gmail.com wrote:
Try the attachment. gerbv does not recognises D2 as D02,
despite the format documents this option.
Awfully sorry, typo in one of the modified lines.
diff --git a/src/gerber.c b/src/gerber.c
index bba2211..d91b6e1 100644
--- a/src/gerber.c
+++ b/src/gerber.c
@@ -805,11 +805,11 @@ gerber_is_rs274x_p(gerb_file_t *fd, gboolean *returnFoundBinary)
found_ADD = TRUE;
dprintf (found_ADD\n);
}
- if (g_strstr_len(buf, len, D00)) {
+ if (g_strstr_len(buf, len, D00) || g_strstr_len(buf, len, D0)) {
found_D0 = TRUE;
dprintf (found_D0\n);
}
- if (g_strstr_len(buf, len, D02)) {
+ if (g_strstr_len(buf, len, D02) || g_strstr_len(buf, len, D2)) {
found_D2 = TRUE;
dprintf (found_D2\n);
}
@@ -904,10 +904,10 @@ gerber_is_rs274d_p(gerb_file_t *fd)
if (g_strstr_len(buf, len, %ADD)) {
found_ADD = TRUE;
}
- if (g_strstr_len(buf, len, D00)) {
+ if (g_strstr_len(buf, len, D00) || g_strstr_len(buf, len, D0)) {
found_D0 = TRUE;
}
- if (g_strstr_len(buf, len, D02)) {
+ if (g_strstr_len(buf, len, D02) || g_strstr_len(buf, len, D2)) {
found_D2 = TRUE;
}
if (g_strstr_len(buf, len, M0)) {
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerbv failure to parse sample gerber file (data attached)
On 12/18/09, Julian thepurl...@gmail.com wrote: The thermals seem to be rendering fine with git...I'm not sure if ineiev is using an older version? I'm sorry, I just thought Gerbv _might_ have some trouble with it, I was not sure at all. Thank you for exemplary support, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb print bottom from the command line
Hi, On 12/8/09, Kai-Martin Knaak k...@familieknaak.de wrote: I am still looking for a way to print the bottom of my layouts from the command line. The action SwapSides does not seem to work when used with the eps HID: pcb -x eps --action-string 'SwapSides()' foobar.pcb Any hints? Well, if you want really _any_ hints, what about this branch: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/kai-martin-scriptaction IIRC, this topic was discussed several times here, have you got anything new? Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
On 11/15/09, Ineiev ine...@gmail.com wrote:
That resulted in arc.bis.patch.
Then, eliminate two precision losses.
I feel I ought to stop here: the patch fixes
many more bugs than originally reported.
Cheers,
Ineiev
diff --git a/src/find.c b/src/find.c
index 1962234..6fb62b6 100644
--- a/src/find.c
+++ b/src/find.c
@@ -1327,11 +1327,61 @@ PVTouchesLine (LineTypePtr line)
return (False);
}
+/* reduce arc start angle and delta to 0..360 */
+static void
+normalize_angles (int *sa, int *d)
+{
+ if (*d 0)
+{
+ *sa += *d;
+ *d = - *d;
+}
+ if (*d 360) /* full circle */
+*d = 360;
+ if (*sa 0)
+*sa = 360 - ((-*sa) % 360);
+ if (*sa = 360)
+*sa %= 360;
+}
+
+static int
+radius_crosses_arc (double x, double y, ArcTypePtr arc)
+{
+ double alpha = atan2 (y - arc-Y, -x + arc-X) * RAD_TO_DEG;
+ int sa = arc-StartAngle, d = arc-Delta;
+
+ normalize_angles (sa, d);
+ if (alpha 0)
+alpha += 360;
+ if ((double)sa = alpha)
+return (double)(sa + d) = alpha;
+ return (double)(sa + d - 360) = alpha;
+}
+
+static void
+get_arc_ends (double *box, ArcTypePtr arc)
+{
+ double ca, sa, angle;
+
+ angle = arc-StartAngle;
+ angle *= M180;
+ ca = cos (angle);
+ sa = sin (angle);
+ box[0] = arc-X - arc-Width * ca;
+ box[1] = arc-Y + arc-Height * sa;
+
+ angle = arc-StartAngle + arc-Delta;
+ angle *= M180;
+ ca = cos (angle);
+ sa = sin (angle);
+ box[2] = arc-X - arc-Width * ca;
+ box[3] = arc-Y + arc-Height * sa;
+}
/* ---
* check if two arcs intersect
* first we check for circle intersections,
* then find the actual points of intersection
- * and test them to see if they are on both arcs
+ * and test them to see if they are on arcs
*
* consider a, the distance from the center of arc 1
* to the point perpendicular to the intersecting points.
@@ -1355,18 +1405,32 @@ PVTouchesLine (LineTypePtr line)
static Boolean
ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
{
- register float x, y, dx, dy, r1, r2, a, d, l, t, t2;
- register LocationType pdx, pdy;
- BoxTypePtr box;
- BoxType box1, box2;
+ double x, y, dx, dy, r1, r2, a, d, l, t, t1, t2, dl;
+ LocationType pdx, pdy;
+ double box[4];
+
+ t = 0.5 * Arc1-Thickness + fBloat;
+ if (t 0) /* too thin arc */
+return (False);
+ t2 = 0.5 * Arc2-Thickness;
+ t1 = t2 + fBloat;
+ if (t1 0) /* too thin arc */
+return (False);
+ /* try the end points first */
+ get_arc_ends (box, Arc1);
+ if (IsPointOnArc ((float) box[0], (float) box[1], (float)t, Arc2)
+ || IsPointOnArc ((float) box[2], (float) box[3], (float)t, Arc2))
+return (True);
+ get_arc_ends (box, Arc2);
+ if (IsPointOnArc ((float) box[0], (float) box[1], (float)t1, Arc1)
+ || IsPointOnArc ((float) box[2], (float) box[3], (float)t1, Arc1))
+return (True);
pdx = Arc2-X - Arc1-X;
pdy = Arc2-Y - Arc1-Y;
l = pdx * pdx + pdy * pdy;
- t = MAX (0.5 * Arc1-Thickness + fBloat, 0.0);
- t2 = 0.5 * Arc2-Thickness;
/* concentric arcs, simpler intersection conditions */
- if (l == 0.0)
+ if (l 0.5)
{
if ((Arc1-Width - t = Arc2-Width - t2
Arc1-Width - t =
@@ -1374,82 +1438,93 @@ ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
|| (Arc1-Width + t =
Arc2-Width - t2 Arc1-Width + t = Arc2-Width + t2))
{
- if ((Arc2-BoundingBox.X1 +
- MAX (Arc2-Thickness + Bloat,
-0) = Arc1-BoundingBox.X1
-Arc2-BoundingBox.X1 =
- Arc1-BoundingBox.X2
-Arc2-BoundingBox.Y1 +
- MAX (Arc2-Thickness + Bloat,
-0) = Arc1-BoundingBox.Y1
-Arc2-BoundingBox.Y1 =
- Arc1-BoundingBox.Y2)
- || (Arc2-BoundingBox.X2 +
- MAX (Arc2-Thickness +
- Bloat,
- 0) =
- Arc1-BoundingBox.X1
- Arc2-BoundingBox.X2 =
- Arc1-BoundingBox.X2
- Arc2-BoundingBox.Y2 +
- MAX (Arc2-Thickness +
- Bloat,
- 0) =
- Arc1-BoundingBox.Y1
- Arc2-BoundingBox.Y2 = Arc1-BoundingBox.Y2))
-return (True);
+ int sa1 = Arc1-StartAngle, d1 = Arc1-Delta;
+ int sa2 = Arc2-StartAngle, d2 = Arc2-Delta;
+ /* NB the endpoints have already been checked,
+ so we just compare the angles */
+
+ normalize_angles (sa1, d1);
+ normalize_angles (sa2, d2);
+ /* cases like sa1 == sa2 are catched when checking the endpoints */
+ if (sa1 sa2)
+ {
+ if (sa1 sa2 + d2)
+ return (True);
+ if (sa1 + d1 360 sa1 + d1 - 360 sa2)
+ return (True);
+ }
+ if (sa2 sa1)
+ {
+ if (sa2 sa1 + d1)
+ return (True);
+ if (sa2 + d2 360 sa2 + d2 - 360 sa1)
+ return (True);
+ }
}
return (False
Re: gEDA-user: How do I fill?
On 12/3/09, Jim j...@fayettedigital.com wrote: I've poked at some documentation, what tutorials I could find and Googled for geda fill and haven't yet found instructions on filling. Is it called something else in pcb lingo? Try polygons. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb [PATCH] Added ActionSetViasTented to allow for setting the solder mask of vias to be fully tented.
On 11/30/09, Gabriel Paubert paub...@iram.es wrote:
Now what's the difference between that command and a more generic
SetViaMask with zero for the mask size
Good point.
Cheers,
Ineiev
From d216ed3d969b0b2a6d9134dd0bfbaa6e07e77f76 Mon Sep 17 00:00:00 2001
From: Bert Timmerman bert.timmer...@xs4all.nl
Date: Sun, 29 Nov 2009 10:24:26 +0100
Subject: [PATCH] Add SetMask action
Action to allow for setting of a solder mask {,gap} for
{selected, all} pins, vias and pads.
Sets the mask for the pin/via or pad, of all
or selected pins and/or pads to the required value.
What you can do is this:
* Optionally the mask layer.
* Select everything that needs the mask distance value.
* :SetMask(gap,selected,pins,vias,8,mil) to change them to that amount.
For all pins, vias and pads to set the mask distance you can do this:
* Enable the mask layer.
* :SetMask(gap,8,mil) to change them all to that amount.
---
src/action.c | 150 ++
1 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/src/action.c b/src/action.c
index 6b979d3..46637fc 100644
--- a/src/action.c
+++ b/src/action.c
@@ -4357,6 +4357,153 @@ ActionMinClearGap (int argc, char **argv, int x, int y)
/* --- */
+static const char setmask_syntax[] =
+ SetMask([Gap,] [Selected,] [(vias|pins|pads),]... value);
+
+static const char setmask_help[] =
+ Sets the mask to the given value.;
+
+/* %start-doc actions SetMask
+
+...@table @code
+
+...@item Gap
+Set mask gap relative to the copper rather than absolute value
+of mask aperture.
+
+...@item Selected
+Set mask of selected objects rather than all on the board
+
+...@item vias, pins, pads
+Select types of objects. When none is issued, all types are assumed.
+
+...@item value
+This can be increment (when begins with `+' or `-') or absolute value
+(start with `=' to force), followed by optional units (mil or mm),
+e.g. SetMask(=+10,mil). When no units follow,
+PCB internal units (1/100 mil) are assumed.
+
+...@end table
+
+There is a MinMaskGap() action to increase the mask gap to vendor
+minimum requirements.
+
+%end-doc */
+
+static int
+ActionSetMask (int argc, char **argv, int x, int y)
+{
+ char *delta = NULL;
+ char *units = NULL;
+ Boolean absolute;
+ int value, mask;
+ int flags = 0;
+ int ac = 0;
+ int vias = 0, pins = 0, pads = 0, gap = 0;
+
+
+ if (ac argc strcasecmp (argv[ac], gap) == 0)
+{
+ gap = !0;
+ ac++;
+}
+
+ if (ac argc strcasecmp (argv[ac], selected) == 0)
+{
+ flags = SELECTEDFLAG;
+ ac++;
+}
+ while (ac argc)
+{
+ if (!strcasecmp (argv[ac], vias))
+vias = !0;
+ else if (!strcasecmp (argv[ac], pads))
+pads = !0;
+ else if (!strcasecmp (argv[ac], pins))
+pins = !0;
+ else break;
+ ac++;
+}
+
+ if (ac = argc)
+{
+ Message (_(SetMask: mask value must be provided\n));
+ AFAIL (setmask);
+}
+
+ /* no object type selection issued - assume all */
+ if (!(vias || pads || pins))
+vias = pads = pins = !0;
+
+ delta = ARG (ac);
+ ac++;
+ units = ARG (ac);
+ if (++ac argc)
+{
+ Message (_(SetMask: too many arguments\n));
+ AFAIL (setmask);
+}
+
+ value = 2 * GetValue (delta, units, absolute);
+ if (absolute !value)
+value = -1;
+
+ SaveUndoSerialNumber ();
+ if (pins || pads)
+ELEMENT_LOOP (PCB-Data);
+{
+ if (pins)
+ PIN_LOOP (element);
+ {
+ if (flags !TEST_FLAGS (flags, pin))
+ continue;
+ mask = value;
+ if (gap absolute)
+ mask += pin-Thickness;
+
+ ChangeObjectMaskSize (PIN_TYPE, element, pin, 0,
+mask, absolute);
+ RestoreUndoSerialNumber ();
+ }
+ END_LOOP; /* PIN_LOOP */
+ if (pads)
+ PAD_LOOP (element);
+ {
+ if (flags !TEST_FLAGS (flags, pad))
+ continue;
+ mask = value;
+ if (gap absolute)
+ mask += pad-Thickness;
+ ChangeObjectMaskSize (PAD_TYPE, element, pad, 0,
+mask, absolute);
+ RestoreUndoSerialNumber ();
+ }
+ END_LOOP; /* PAD_LOOP */
+}
+END_LOOP; /* ELEMENT_LOOP */
+ if (vias)
+VIA_LOOP (PCB-Data);
+{
+ if (flags !TEST_FLAGS (flags, via))
+ continue;
+ mask = value;
+ if (gap absolute)
+ mask += via-Thickness;
+ ChangeObjectMaskSize (VIA_TYPE, via, 0, 0,
+ mask, absolute);
+ RestoreUndoSerialNumber ();
+}
+END_LOOP; /* VIA_LOOP */
+ if (Bumped)
+{
+ IncrementUndoSerialNumber ();
+ gui-invalidate_all ();
+}
+ return 0;
+}
+
+/* --- */
+
static const char changepinname_syntax[] =
ChangePinName(ElementName,PinNumber,PinName);
@@ -6919,6 +7066,9 @@ HID_Action action_action_list[] = {
{SaveTo, 0, ActionSaveTo,
saveto_help, saveto_syntax}
,
+ {SetMask, 0, ActionSetMask,
+ setmask_help, setmask_syntax}
+ ,
{SetSquare, 0, ActionSetSquare
Re: gEDA-user: [Patch] pcb Added ActionSetMaskGap for setting solder mask gap
On 11/29/09, Bert Timmerman bert.timmer...@xs4all.nl wrote:
This patch is as requested in:
http://archives.seul.org/geda/user/Oct-2008/msg00088.html
Thanks!
I don't know if this is *exactly* what DJ meant but it works for me.
I'm afraid it may not work when invoked without
the Selected argument (the same issue as with SetViasTented);
and probably a second optional
group of arguments, (pins|pads|vias) to select objects type,
can be useful.
And another patch.
This one is created from a fresh branch so it should be able to apply
without the former patch.
SetViasTented(All) should be actually spelled
as SetViasTented(), and it seems not to work;
I'd also slightly refactor arguments
handling and other things.
Best regards,
Ineiev
From 63156621274735352e65ab0fba1cb09ffc9224c0 Mon Sep 17 00:00:00 2001
From: Bert Timmerman bert.timmer...@xs4all.nl
Date: Sun, 29 Nov 2009 10:24:26 +0100
Subject: [PATCH 1/2] Added ActionSetMaskGap
Action to allow for setting of a solder mask gap for
{Selected, all} pins, vias and pads.
Sets the mask gap between the pin/via or pad edge and the mask edge, of all
or selected pins and/or pads to the required value.
What you can do is this:
* Enable the mask layer.
* Select everything that needs the mask distance value.
* :SetMaskGap(Selected,pins,vias,8,mil) to change them all to that amount.
For all pins, vias and pads to set the mask distance you can do this:
* Enable the mask layer.
* :SetMaskGap(8,mil) to change them all to that amount.
---
src/action.c | 130 ++
1 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/src/action.c b/src/action.c
index 6b979d3..140efe4 100644
--- a/src/action.c
+++ b/src/action.c
@@ -4357,6 +4357,133 @@ ActionMinClearGap (int argc, char **argv, int x, int y)
/* --- */
+static const char setmaskgap_syntax[] =
+ SetMaskGap([Selected,] [(vias|pins|pads),]... value);
+
+static const char setmaskgap_help[] =
+ Sets the mask to the given distance (value) from pins/vias and pads.;
+
+/* %start-doc actions SetMaskGap
+
+What you can do is this:
+
+...@enumerate
+
+...@item Optionally enable the mask layer.
+
+...@item Select everything that needs the mask distance value.
+
+...@item :SetMaskGap(Selected,vias,pins,8,mil) to change
+them all to that amount.
+
+...@end enumerate
+
+For all pins, vias and pads to set the mask distance you can do this:
+
+...@enumerate
+
+...@item Enable the mask layer.
+
+...@item :SetMaskGap(8,mil) to change them all to that amount.
+
+...@end enumerate
+
+There is a MinMaskGap() action to increase the mask gap to vendor
+minimum requirements.
+
+%end-doc */
+
+static int
+ActionSetMaskGap (int argc, char **argv, int x, int y)
+{
+ char *delta = NULL;
+ char *units = NULL;
+ Boolean r;
+ int value;
+ int flags = 0;
+ int ac = 0;
+ int vias = 0, pins = 0, pads = 0;
+
+ if (argc 1)
+AFAIL (setmaskgap);
+
+ if (strcasecmp (argv[ac], Selected) == 0)
+{
+ flags = SELECTEDFLAG;
+ ac++;
+}
+ while (ac argc)
+{
+ if (!strcasecmp (argv[ac], vias))
+vias = !0;
+ else if (!strcasecmp (argv[ac], pads))
+pads = !0;
+ else if (!strcasecmp (argv[ac], pins))
+pins = !0;
+ else break;
+ ac++;
+}
+ /* no object type selection issued - assume all */
+ if (!(vias || pads || pins))
+vias = pads = pins = !0;
+
+ if (ac = argc) /* no value given */
+AFAIL (setmaskgap);
+
+ delta = ARG (ac);
+ ac++;
+ units = ARG (ac);
+ if (++ac argc) /* too many arguments */
+AFAIL (setmaskgap);
+
+ value = 2 * GetValue (delta, units, r);
+
+ SaveUndoSerialNumber ();
+ if (pins || pads)
+ELEMENT_LOOP (PCB-Data);
+{
+ if (pins)
+ PIN_LOOP (element);
+ {
+ if (flags !TEST_FLAGS (flags, pin))
+ continue;
+ ChangeObjectMaskSize (PIN_TYPE, element, pin, 0,
+pin-Thickness + value, 1);
+ RestoreUndoSerialNumber ();
+ }
+ END_LOOP; /* PIN_LOOP */
+ if (pads)
+ PAD_LOOP (element);
+ {
+ if (flags !TEST_FLAGS (flags, pad))
+ continue;
+ ChangeObjectMaskSize (PAD_TYPE, element, pad, 0,
+pad-Thickness + value, 1);
+ RestoreUndoSerialNumber ();
+ }
+ END_LOOP; /* PAD_LOOP */
+}
+END_LOOP; /* ELEMENT_LOOP */
+ if (vias)
+VIA_LOOP (PCB-Data);
+{
+ if (flags !TEST_FLAGS (flags, via))
+ continue;
+ ChangeObjectMaskSize (VIA_TYPE, via, 0, 0,
+ via-Thickness + value, 1);
+ RestoreUndoSerialNumber ();
+}
+END_LOOP; /* VIA_LOOP */
+ if (Bumped)
+{
+ IncrementUndoSerialNumber ();
+ gui-invalidate_all ();
+}
+ return 0;
+}
+
+/* --- */
+
static const char changepinname_syntax[] =
ChangePinName(ElementName,PinNumber,PinName);
@@ -6919,6 +7046,9 @@ HID_Action action_action_list[] = {
{SaveTo, 0, ActionSaveTo,
saveto_help
Re: gEDA-user: Dsub15 HD
On 11/27/09, Gabriel Paubert paub...@iram.es wrote: On Fri, Nov 27, 2009 at 07:40:54AM +0100, Bert Timmerman wrote: IMHO, it's is a major pitah that pcb doesn't allow for interactive entering/changing these values in the popup dialog (that is present values in entry boxes instead of text labels). Seconded! Maybe I should scratch that itch myself. I encourage you. I second; please post it here if you do it. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Dsub15 HD
On 11/27/09, Ethan Swint eswint.r...@verizon.net wrote:
On 11/27/2009 01:43 AM, DJ Delorie wrote:
I set my mask clearance to be 3 mil away from the copper, that's what
most fabs want.
Do you (or some one else) have a script that will edit the
pins/pads/vias on the board and automagically set the mask clearance to
your desired value (e.g. 3 mils each side, +600 PCB units to the
pad/pin/via copper). On my last board, I modified the numbers in a text
editor, but a pearl script would be much easier. It would be a help if
anyone had a bit of parser already written... (Don't build when you can
steal!)
Two months ago I did something similar this way:
#! /bin/awk -f
!/\tPin/ { print }
/\tPin/ {delta=600;
if ($3+delta$5) print; else
print \t$1 $2 $3 $4 $3+delta $6 $7 $8 $9 $10;
}
#! /bin/awk -f
!/\tPad/ { print }
/\tPad/ {delta=600;
if ($5+delta$7) print; else
print \t$1 $2 $3 $4 $5 $6 $5+delta $8 $9 $10;
}
(two scripts: for pins and for pads to set minimum mask clearance
to 3 mil (delta/2/(100 PCB units/mil))
Such things are done in a minute, they don't need any special tool.
HTH,
Ineiev
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: AutoRouter
On 11/27/09, Stefan Salewski m...@ssalewski.de wrote: All my knowledge is from this list: toporouter works more or less fine with boards with no existing traces. So I used tut1.pcb, deleted all existing traces and polygons (all in top and bottom layer), pressed key O to optimize rats nest and :toporouter(). Toporouter uses the active layers for traces, so I deactivate layers called unused before. That was my mistake. I tried to route partially routed board. thanks! I can see no PNG files, not in my working directory, not in /tmp or similar places. Just checked the sources; looks like all places where that output might occur are commented out. And yes, PNG output is enabled and works. Actually, the features are not related. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: AutoRouter
On 11/27/09, Stefan Salewski m...@ssalewski.de wrote: OK, --enable-toporouter-output is for debugging. But for PCB20091103 I do see no difference if built with --enable-toporouter-output or --disable-toporouter-output. The last time I tried it, the toporouter action resulted in some PNG files. I have checked with GTK and Lesstif GUI and tut1.pcb -- final routing result is fine when traces are copied back to pcb program. Could you please elaborate on this (I mean sequence of the user's actions). I have never been skillful enouth to get something like you mention. Or only if --enable-debug is set at the same time? It there only a visible effect of --enable-toporouter-output for the experimental OpenGL branch? Or only if --enable-debug is set at the same time? All three should work independently. HTH, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] Selection of objects
On 11/24/09, Torsten Wagner torsten.wag...@gmail.com wrote: Oh really, lets see I just need to find out about the PCB-development principles No need; I think it would be too long --- probably several years; personally, your humble servant knows very little about it; also, you actually don't need to care about other people's principles when writing your local patches. Need to get familiar with the programming language of choice Which is C. Create the desired functions Just edit the existing ones; and in this particular case it is not that hard IMO. Patch a recent git... But I thought you are somewhat familiar with git. Debug...debug...debug...debug... This is what we are doing with all programs we use, isn't it? AFAIK, PCB has never had any `stable' release. Submit the patches Easier than write your recent post. Sound easy right... :) Maybe I will post something... maybe... someday... You are welcome; my point was that this is probably one the one of most natural ways in this case. Kind regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: More questions about pcb
On 11/24/09, Atommann atomm...@gmail.com wrote: Hi, Second question, is there a ruler tool in pcb? I observe the coordinate and make subtraction. Ctrl-M in default bindings marks a point, then dx, dy, phi and r are shown near the coordinates - top right in GTK, low left in Lesstif. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb20091103, --enable-m4lib-png, but no png pictures
On 11/23/09, Stefan Salewski m...@ssalewski.de wrote: Seems to be a bug. Old pcb20081128 gives me the png previews, so it should not be a problem of my box. Tested with --enable-m4lib-png or --enable-m4lib-png=yes in combination with various other options. No previews. Thank you, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: DRC segfault on a ratline
003Aborted Sigh, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB: DRC segfault on a ratline
Hello; I just fed tut1.pcb from PCB distribution to DRC and got another segmentation fault. diff --git a/src/find.c b/src/find.c index 1962234..d5f1332 100644 --- a/src/find.c +++ b/src/find.c @@ -4417,6 +4417,7 @@ BuildObjectList (int *object_count, long int **object_id_list, int **object_type case VIA_TYPE: case PAD_TYPE: case ELEMENT_TYPE: +case RATLINE_TYPE: *object_count = 1; *object_id_list = malloc (sizeof (long int)); *object_type_list = malloc (sizeof (int)); @@ -4425,6 +4426,10 @@ BuildObjectList (int *object_count, long int **object_id_list, int **object_type return; default: + fprintf (stderr, + _(Internal error in BuildObjectList: unknown thing_type %i\n), + thing_type); + fprintf (stderr,_( This must result in a segmentation fault..\n)); return; } } Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: DRC segfault on a ratline
On 11/19/09, Peter Clifton pc...@cam.ac.uk wrote: I tried it, and couldn't reproduce a crash, neither under gdb or valgrind. What are the steps to reproduce? I had reproduced it faultlessly on two different machines with different GUIs before I reported; after your post I went to a third and reproduced it so that now I'm quite sure I have tested all three GUIs, the batch, the Lesstif and the GTK one. I run pcb tut1.pcb and enter `:drc'; with GTK it segfaults instantly, with other GUIs you have to skip several errors. I'm willing to accept that the patch might be good; I was not quite sure; I just pointed to the offending code. but I'm curious what code-path was executing, and what the DRC error was which triggered the issue.. When BuildObjectList is called with thing_type being unenumerated, it returns NULL in object_id_list, then the program free()s it and that does not make a segmentation fault, because standard free() is so generous about NULLs. However, when we have got an unenumerated thing_type, object_type_list remains unassigned, and eo sunt leones. why is a RATLINE playing a part in a DRC violation? I didn't know; perhaps, because ratlines may be included in the report. From my quick scan of find.c, I can't see any DRC checks which ought to involve rat-lines. But I can see `SetThing (RATLINE_TYPE'; it is indirectly issued from many places. As far as I can see, ignoring an object type - and just returning is should not be fatal - unless perhaps the fact nothing is returned - causes a crash elsewhere. If that is the case, I want to fix it. I don't feel nullifying object_type_list would be a more correct solution; they both may be combined, though. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Feature Request Status-Terminal instead of dialogue and info boxes
On 11/18/09, Frank Bergmann frank.g...@frajasalo.de wrote: On Tue, 17 Nov 2009 19:24:48 +, Peter Clifton wrote: On Tue, 2009-11-17 at 18:35 +, Ineiev wrote: On 11/17/09, Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2009-11-17 at 14:11 +, Ineiev wrote: Does it work with the recent graphical DRC view? Yes, as you can see, it does, it was written for it. Mainly it was written for keeping all in one window and the log content available even if the log will be closed. I'm sorry, I expressed wrong. I should have say it's greatest advantage for me was that it made GTK DRC usable again with my window manager. IMO, the best solution would be to grab the code of the GDL library (docking library), and figure out how to use that to make various pieces of the GTK HID PCB GUI dockable. Ok, I'll take a closer look at it. Actually, the existing patch does work for me. I have no strong feeling it would be more convenient if PCB had other pieces detachable; probably because I have no experience of using programs with this feature implemented. Just my two kopeeks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Black background on pcb
On 11/19/09, Ben Jackson b...@ben.com wrote: On Wed, Nov 18, 2009 at 03:37:47PM -0800, Anthony Shanks wrote: Yes GTK. I thought I looked in that menu but only saw you can change the colors of the pcb layers, I didn't see an option for background. I guess I must have missed it. I'll check when I get home from work and I'll give your colors a try, thanks. There was a bug that I fixed semi-recently that required a restart after changing some of the colors (such as background). Try that (or an upgrade ;-) if you don't get immediate results. And for those who use Lesstif: pcb --grid-color white --background-color black works with both GTK and Lesstif guis. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GIT: tracking inter-file moves
On 11/16/09, Ben Jackson b...@ben.com wrote: Git stores entire files and trees. It doesn't record diffs at all. [snip] So what you'd really want as a feature is not 'tracking' but the ability for merge to track functions across files just like it currently can across renames. Thank you, I think now I have got the right idea; and how do you typically invoke such means? Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GIT: tracking inter-file moves
On 11/16/09, Peter Clifton pc...@cam.ac.uk wrote: (Wow, that is a lot of code changes!) The life is hard. Looks like many of them are ready to push, e.g. update addresses, dates, rm $Id$s etc..? Probably yes, but I believe that two patches are almost pointless per se. You see, I'm not a developer to say whether they are ready to push; I just think that they implement the feature; I can't essentially improve them any more without external feedback, either from developers or from users. I can't review properly at the moment though.. Well, it will be reviewed the next time. Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Feature Request Status-Terminal instead of dialogue and info boxes
On 11/17/09, Torsten Wagner torsten.wag...@gmail.com wrote: As wrote in an earlier post, I use a tiling window manager. [snip] Normally 3-5 lines of text are enough to show an experienced user what is going on with the program. I think you may want to use this Frank Bergmann patch (I like it very much) http://sourceforge.net/tracker/?func=detailaid=2779826group_id=73743atid=538813 from PCB Sourceforge patch tracker, ID 2779826, posted 2009-04-23 19:58. Other open source projects who utilise such a termial window use embedded python, lua or some other scripting language which gives very powerful scripting features. I'd like to have a wider scripting capabilities in PCB, but only if it doesn't decrease it's portability; I certainly don't want the program to have new hard dependencies. BTW, could you find the post about scripting plugin in the list archives and review it (IIRC it appeared this spring or summer)? Furthermore, this creates a central place for all kind of messages makes it easy for a community driven project to help by state :If you are going to post about a problem, please add the terminal history to your post. I believe this typically won't help very much; there is --verbose option, but it is not used very often. Kind regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Feature Request Status-Terminal instead of dialogue and info boxes
On 11/17/09, Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2009-11-17 at 14:11 +, Ineiev wrote: I think you may want to use this Frank Bergmann patch (I like it very much) http://sourceforge.net/tracker/?func=detailaid=2779826group_id=73743atid=538813 from PCB Sourceforge patch tracker, ID 2779826, posted 2009-04-23 19:58. Can you attach a screen-shot of it in use (or put one up somewhere).. I've not got the time to build fetch and build with the patch, but I'm interested to see what is being discussed. http://ineiev.users.sourceforge.net/pcb/graph/info.view.png Does it work with the recent graphical DRC view? Yes, as you can see, it does, it was written for it. The new view has two tabs --- for DRC errors and for messages, there are also small buttons above it to `detach' it (it becomes a distinct window), close, clear logs and so on. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB GIT: tracking inter-file moves
Rebasing some of PCB branches (among them, the patchset about layer colours, recently suggested by Stefan Salewski) against master, I've noticed that some functions moved yesterday from src/hid/gtk/gtkhid-main.c to src/hid/gtkhid-gdk.c, and learnt that GIT does not track the changes when the content is moved between files (not by default). Is there any means to automate such tracking? Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GIT: tracking inter-file moves
On 2009-11-16 at 10:32 AM Peter Clifton pc...@cam.ac.uk wrote: On Mon, 2009-11-16 at 09:23 +, Ineiev wrote: Is there any means to automate such tracking? Ah.. sorry - I didn't mean to break your patches! Never mind; it is essentially unavoidable thing. I use stgit, which allows me to push and pop patches. You can stg init and stg uncommit from a branch which is not already an stgit branch. Once I tried it and decided not to use it; I didn't see essential gains and another level of complexity just confused me; I didn't understand GIT then, and I didn't like that using some git commands pushed stgit in a state which I could not repair. Pop all the patches [snip] Keep repeating this for all the patches in the stack then stg delete temp-revert-gtkhid-main-changes Thank you, I think I understand the general technique. I read git-rebase man page and noticed --merge option and thought it might make the process somewhat easier. I'll certainly try it next time; have you any experience with it? Since I caused it.. if you have difficulties, remind me where to fetch your branch from (as it was), and I'll have a go at fixing it tonight or tomorrow some time. I've rebased it already; however, I as usual shall be very grateful if you checkout it and tell me what is bad in that branch. (it is in Gitorious, git clone git://gitorious.org/~ineiev/pcb/clon_ineieva.git should work). Thanks, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
On 11/14/09, Ineiev ine...@gmail.com wrote: On 11/13/09, Peter Clifton pc...@cam.ac.uk wrote: On Fri, 2009-11-13 at 20:33 +, Ineiev wrote: On 11/13/09, Ineiev ine...@gmail.com wrote: Next versions: fixed signs of second atan2 arguments; no DRC errors on whole teardropped OSDCU board. Shall I push this then? Certainly, not (yet). Something I find hard when people post patches to the email lists, is knowing when they are declared ready, tested etc.. I'm inexpressibly happy this is not my problem. I guess you've tested the corner cases of two arcs which _should_ touch? I think I'll run some tests today. So I built a montecarlo; fixed some ugly unrealistic cases like thin arc merged in bloat and arc-Delta-360; run the program (aat.c) several hours on different machines including ifctfvax.Harhan.ORG and gcc55.fsffrance.org; that discovered no errors, though the number of points was not very high (a thousand or slightly more): the reference functions are really slow. That resulted in arc.bis.patch. I tested it also with already mentioned teardropped OSDCU.pcb and t1.pcb. And n2.pcb is a little modest present for those developers who are curious about segmentation faults concerned with polygons: just a ring, an arc and a tetragon produce segmentation faults on loading PCB (24669073abf8a2ebc52d4644e3da4a9d3401d4b5). Any ideas? Ineiev aat.c Description: Binary data arc.bis.patch Description: Binary data n2.pcb 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: gEDA-dev: Arc intersection connectivity bug
On 11/14/09, michalwd1979 michalwd1...@o2.pl wrote: One more note about teardrops. The plugin is really nice and helpful for home-made boards. It helps keep all the connections right and prevents lifting up tracks when holes are drilled a bit off-center. And produces lots of arcs to test DRC routines! Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
On Thu, 2009-11-12 at 20:06 +, Ineiev wrote:
Probably the function should be rewritten almost completely.
I'll try tomorrow.
And this is what comes in the attachment.
First, I suggest computations against the centerlines
of arcs; this simplifies the geometry and does not
impose limitations because we have no square-ended arcs.
The general method is to use IsPointOnArc to test several
candidates and return false if all tests results are negative.
Thus, the suggested sequence is:
(1) check the ends of each arc against the other arc.
this is done unconditionally, as it would be needed
in all groups of cases (2)..(4) under certain conditions.
generally, the nearest distance from one arc to
another is achieved either on an end of the first
or the second arc, or on the line connecting
the centers of the arcs.
(2) check concentric arcs.
it is treated now almost correctly; but
the bounding boxes are irrelevant; also,
I'd s/l == 0\.0/l 0\.5/ because I believe
that the compiler should have freedom to optimise
the former to false.
(3) check non-intersecting centerlines. test
the nearest to the other arc's center
point of circle (if it is included into the arc)
against the other arc; this is the only candidate
besides the arc endpoints for this case.
(4) check intersecting arcs. try points of intersections
against the other arc (if these points of intersection
lie on the arc), for each arc and
each point of intersection.
Other suggestions? any ideas?
diff --git a/src/find.c b/src/find.c
index b24512a..ca12b93 100644
--- a/src/find.c
+++ b/src/find.c
@@ -1327,11 +1327,45 @@ PVTouchesLine (LineTypePtr line)
return (False);
}
+static int
+radius_crosses_arc (float x, float y, ArcTypePtr arc)
+{
+ float alpha = atan2 (y - arc-Y, x - arc-X) * 180 / M_PI, start, delta;
+
+ start = (float) fmod (arc-StartAngle, 360);
+ delta = arc-Delta;
+ if (alpha 0)
+alpha += 360;
+ if (start 0)
+start += 360;
+ if (delta 0)
+{
+ start += delta;
+ delta = -delta;
+}
+ return (start alpha start + delta alpha);
+}
+/* reduce arc start angle and delta to 0..360 */
+static void
+normalize_angles (int *sa, int *d)
+{
+ if (*d 0)
+{
+ *sa = *sa + *d;
+ *d = - *d;
+}
+ if (*d 360) /* full circle */
+*d = 360;
+ if (*sa 0)
+*sa = 360 - ((-*sa) % 360);
+ if (*sa = 360)
+*sa %= 360;
+}
/* ---
* check if two arcs intersect
* first we check for circle intersections,
* then find the actual points of intersection
- * and test them to see if they are on both arcs
+ * and test them to see if they are on arcs
*
* consider a, the distance from the center of arc 1
* to the point perpendicular to the intersecting points.
@@ -1355,18 +1389,29 @@ PVTouchesLine (LineTypePtr line)
static Boolean
ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
{
- register float x, y, dx, dy, r1, r2, a, d, l, t, t2;
- register LocationType pdx, pdy;
+ float x, y, dx, dy, r1, r2, a, d, l, t, t1, t2, dl;
+ LocationType pdx, pdy;
BoxTypePtr box;
- BoxType box1, box2;
pdx = Arc2-X - Arc1-X;
pdy = Arc2-Y - Arc1-Y;
l = pdx * pdx + pdy * pdy;
t = MAX (0.5 * Arc1-Thickness + fBloat, 0.0);
t2 = 0.5 * Arc2-Thickness;
+ t1 = MAX (t2 + fBloat, 0.0);
+ /* try the end points first */
+ box = GetArcEnds (Arc1);
+ if (IsPointOnArc ((float) box-X1, (float) box-Y1, t, Arc2)
+ || IsPointOnArc ((float) box-X2, (float) box-Y2, t, Arc2))
+return (True);
+
+ box = GetArcEnds (Arc2);
+ if (IsPointOnArc ((float) box-X1, (float) box-Y1, t1, Arc1)
+ || IsPointOnArc ((float) box-X2, (float) box-Y2, t1, Arc1))
+return (True);
+
/* concentric arcs, simpler intersection conditions */
- if (l == 0.0)
+ if (l 0.5)
{
if ((Arc1-Width - t = Arc2-Width - t2
Arc1-Width - t =
@@ -1374,36 +1419,66 @@ ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
|| (Arc1-Width + t =
Arc2-Width - t2 Arc1-Width + t = Arc2-Width + t2))
{
- if ((Arc2-BoundingBox.X1 +
- MAX (Arc2-Thickness + Bloat,
-0) = Arc1-BoundingBox.X1
-Arc2-BoundingBox.X1 =
- Arc1-BoundingBox.X2
-Arc2-BoundingBox.Y1 +
- MAX (Arc2-Thickness + Bloat,
-0) = Arc1-BoundingBox.Y1
-Arc2-BoundingBox.Y1 =
- Arc1-BoundingBox.Y2)
- || (Arc2-BoundingBox.X2 +
- MAX (Arc2-Thickness +
- Bloat,
- 0) =
- Arc1-BoundingBox.X1
- Arc2-BoundingBox.X2 =
- Arc1-BoundingBox.X2
- Arc2-BoundingBox.Y2 +
- MAX (Arc2-Thickness +
- Bloat,
- 0) =
- Arc1
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
On 11/13/09, Peter Clifton pc...@cam.ac.uk wrote: The OpenGL hid won't render that properly, but that is my bug ;). I just assumed rx == ry == radius, and clearly that might not be the case if people start editing their files manually ;) This is not the greatest bug about elliptic arcs; IMO the most important that they were never DRCed correctly, and most probably won't be in forseeable future. I really hate this feature of the PCB file format. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
On 11/13/09, Gabriel Paubert paub...@iram.es wrote: On Fri, Nov 13, 2009 at 01:42:33AM +, Peter Clifton wrote: Anyway, right now you won't be able to produce the corresponding photoplotter files. While as far as I know Gerber only allows circular interpolation: http://www.artwork.com/gerber/274x/rs274xrevd_e.pdf it may be possible to produce elliptical arcs by using the SF command (scaling factor). Neither the PCB nor the Gerber file format allow to describe ellipses with arbitrary orientation. IMO if PCB would fully support such complicated curves, it would better support something general like beziers; it would not be much harder, but more useful. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
And this is another fix --- for IsPointOnArc(). The sample o.pcb is an extraction of teardropped OSDCU board. Cheers, Ineiev o.pcb Description: Binary data 0001-fix-IsPointOnArc.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: gEDA-dev: Arc intersection connectivity bug
On 11/13/09, Ineiev ine...@gmail.com wrote: And this is another fix --- for IsPointOnArc(). The sample o.pcb is an extraction of teardropped OSDCU board. Next versions: fixed signs of second atan2 arguments; no DRC errors on whole teardropped OSDCU board. Pardon for offtopic, Ineiev 0002-fix-ArcArcIntersect.patch Description: Binary data 0003-fix-IsPointOnArc.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 attributes [was: pcb... working on ebuild, PCB.. layer colors]
On 11/8/09, Peter Clifton pc...@cam.ac.uk wrote: BTW, Please bug me if you have any outstanding patches I promised to review / apply. I recall layer colours.. Very good; the patches are in Gitorious; this should work: git clone git://gitorious.org/~ineiev/pcb/clon_ineieva.git cd clon_ineieva git checkout -b attributes origin/attributes Since last post some minor cleanup was done, the most significant part of which is making arguments of actions case-insensitive; feel free to review it and give any feedback (which I'd actually wanted to address to everybody, not just to Peter). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA-dev: Arc intersection connectivity bug
(I'm sorry, the mailer threw the message to spam) On 11/11/09, Peter Clifton pc...@cam.ac.uk wrote: It looks like the teardrop plugin's use of arbitrary angle arcs has exposed a bug in the the intersection calculation of arcs. (And their bounding boxes look to be wrong as well). I don't think the bounding boxes are wrong (the boxes of the lines on the same board are `widened' in a similar way), it is the check that is not strictly correct. I _hate_ arcs and related geometry.. they caused me no end of grief in gschem, so I'm not feeling keen to dig into the code and debug it myself! Arcs are OK, unless they are ellipsoidal; in that case they can't survive rotation by arbitrary angles. Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA and pcb status and minigration from Eagle
On 11/12/09, Peter Clifton pc...@cam.ac.uk wrote: On Thu, 2009-11-12 at 07:40 +, Ineiev wrote: * some complicated features should be used with caution; e.g. sometimes polygons may disappear when you move from one part of the board to another or even produce a segmentation fault Urm.. when was the last time you saw either of those things happen? If it was recently, and you have a test-case, I'd be _very_ interested to see it. Segfault --- probably never, but in May there was a report: http://sourceforge.net/tracker/?func=detailaid=2796086group_id=73743atid=538811 It does not reproduce with current PCB. please check and close the item. Errors like Error while clipping PBO_SUB: 3 Just leaked in Subract and Error while clipping PBO_ISECT: 3 Just leaked in ClipOriginal -- several times this week. It was when I either moved a part over a polygon or the polygon itself (most probably this is 0 bits of information for you, though); I'll report if I find a way to reproduce this reliably. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange PCB warning
On 11/12/09, Peter Clifton pc...@cam.ac.uk wrote: On Thu, 2009-11-12 at 17:16 +, Ineiev wrote: Sorry, forgot to scale atan2 result: Is this patch still needed if the bounding-boxes were correct? They _are_ correct: they include the arc with her clearance. if they didn't include clearance, additional test is nonetheless needed: e.g. arcs like these: \ \ \ \--- \ have intersecting bounding boxes. Why does the arc intersection test use the bounding boxes anyway.. is it just a short-cut to avoid computing a more expensive geometric test in case the supposed circle intersection was outside the other arc's bounding box? I think, yes (at least, this was _my_ intension). Does your patch explicitly allow for the thickness of the drawn arc? You are right. The function computes the intersection points of two arcs of zero width: the first is has radius r1+arc1-Width+bloat, the second has the radius r2+arc2-Width. When they are situated like this: \ - \ \ |\ \ (let them be close enough to want a DRC error, but the arc with the center of the inner arc and radius r+arc-Width+bloat not intersect the arc with the center of the outer one and radius r+arc-Width) Then both current procedure and suggested patch shall miss the error: both when arc1 is the inner arc and when arc1 is the outer one. (this is another bug, though). Probably the function should be rewritten almost completely. I'll try tomorrow. Regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange PCB warning
On 11/12/09, Ineiev ine...@gmail.com wrote:
The function computes the intersection points of two arcs of zero width:
the first is has radius r1+arc1-Width+bloat, the second has the radius
r2+arc2-Width.
Sorry, r1 and r2 were arc{1,2}-Width and Width was Thickness/2
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange PCB warning
On 11/11/09, Stefan Salewski m...@ssalewski.de wrote:
On Wed, 2009-11-11 at 20:21 +0100, Stefan Salewski wrote:
On Wed, 2009-11-11 at 19:09 +0100, michalwd1979 wrote:
http://www.ssalewski.de/tmp/t1.pcb
Maybe related to your teardrops or area fill?
Reduced to
http://www.ssalewski.de/tmp/t3.pcb
Seems related to arc elements?
False alarm in ArcArcIntersect because the arcs have got intersecting
BoundingBoxes.
diff --git a/src/find.c b/src/find.c
index b24512a..46f2b3d 100644
--- a/src/find.c
+++ b/src/find.c
@@ -1327,6 +1327,24 @@ PVTouchesLine (LineTypePtr line)
return (False);
}
+static int
+radius_crosses_arc (float x, float y, ArcTypePtr arc)
+{
+ float alpha = atan2 (y - arc-Y, x - arc-X), start, delta;
+
+ start = (float) fmod (arc-StartAngle, 360);
+ delta = arc-Delta;
+ if (alpha 0)
+alpha += 360;
+ if (start 0)
+start += 360;
+ if (delta 0)
+{
+ start += delta;
+ delta = -delta;
+}
+ return (start alpha start + delta alpha);
+}
/* ---
* check if two arcs intersect
* first we check for circle intersections,
@@ -1424,7 +1442,9 @@ ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
x + dy = Arc2-BoundingBox.X1
x + dy = Arc2-BoundingBox.X2
y - dx = Arc2-BoundingBox.Y1 y - dx = Arc2-BoundingBox.Y2)
-return (True);
+if (radius_crosses_arc (x + dy, y - dx, Arc1)
+radius_crosses_arc (x + dy, y - dx, Arc2))
+ return (True);
if (x - dy = Arc1-BoundingBox.X1
x - dy = Arc1-BoundingBox.X2
@@ -1433,7 +1453,9 @@ ArcArcIntersect (ArcTypePtr Arc1, ArcTypePtr Arc2)
x - dy = Arc2-BoundingBox.X1
x - dy = Arc2-BoundingBox.X2
y + dx = Arc2-BoundingBox.Y1 y + dx = Arc2-BoundingBox.Y2)
-return (True);
+if (radius_crosses_arc (x - dy, y + dx, Arc1)
+radius_crosses_arc (x - dy, y + dx, Arc2))
+ return (True);
/* try the end points in case the ends don't actually pierce the
outer radii */
box = GetArcEnds (Arc1);
Thanks,
Ineiev
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20091103
On 11/7/09, Chitlesh GOORAH chitlesh.goo...@gmail.com wrote: Ok, I prefer to dump a pcb-doc package then. The thing is I have been receiving a lot of complains from people have a slow internet connection that FEL is way too big to download. So I think I'll trade it with a subpackage. Yes, sizes of modern distributions is what lawyers call `act of God'. some ten years ago when I bought a CD set, it contained all I needed; now it looks like `install a basic system and download the rest what you want'; and why would I bother myself to buy the disk if I had Internet connections everywhere? quite unsolvable problem. - [docs]Add getting started guide I like it as it will help me spin off a major release notes for FEL-13 based on it. e.g for FEL-12 http://chitlesh.fedorapeople.org/papers/FEL12ReleaseNotes.pdf Looks impressive; however, will you remove the line or add declared getting started guide? I'm sorry my language was not clear. BTW, gs.ps seems to me to be unreasonably large (79 MB, whereas all the rest installed files use 16 MB on disk, includin gs.pdf); can you confirm this or report a different result? Best regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA and pcb status and minigration from Eagle
On 11/12/09, Torsten Wagner torsten.wag...@gmail.com wrote: like style with fancy pretty 3d windows (e.g., KDE) to a minimalistic design and the command-line (e.g., awesome wm). My favourite is ratpoison. I killed more and more proprietary programs and replaced bloated GUI-programs by KISS(keep it simple stupid)-versions. Thank you both for the former and for the latter. Now, it is time to look again into EDA. Initially, I believe that according to my work habits, gEDA and pcb might be more suitable to me then KiCad. However, I can not see the ongoing usage and development of this projects in the near future. I saw actual releases for both packages but do not know whether there is really an active development in progress. It is, and it's very intensive; for details, you can look at the GIT logs and gEDA mailing lists archives. Package management systems of different distributions ship rather old versions and the blogosphere and Internet is rather quite about this packages. Many people on this list are used to build gEDA programs from sources, either released or GIT heads. Furthermore, can I do all the stuff I was used to do in eagle with gEDA and pcb ? Are there any shortcuts or limitations ? Any program has limitations. I don't feel competent in other parts of gEDA (the toolset covers an area which is too wide for me); for PCB the most essential are (of course, this is just my deeply personal opinion): * some lack of layers flexibility (no blind and buried vias, same design rules for all layers, limited quantity and functions of non-copper layers) * texts in non-latin scripts are not supported; there may be only one font per board * some complicated features should be used with caution; e.g. sometimes polygons may disappear when you move from one part of the board to another or even produce a segmentation fault You can ask here if you want to know about a particular feature. How mature and stable are the suite yet ? Can it be really considered for serious work ? I think these are questions you should answer youself after testing the programs. There are people on this list (and I believe, off this list) who do use these programs for serious work; nobody can tell you if you'll want to use them for your particular design. As for me I have no problem to get my hand dirty and crawl around in config- files and text-files. I even will love to see that maybe one or another task can be done by simply writing some text-files in emacs (or vi to avoid a war). For Eagle, I liked the little command line at the bottom of the window, which allowed me to type in comments rather then clicking and searching around in GUI-settings. If there is something like this in gschem or pcb I would be happy to use it. It is: AFAIK gschem uses guile; in PCB the scripting abilities are not so rich; as another way, processing PCB files with sed/awk/perl is used. There were a plugin written by igor2 ig...@inno.bme.hu (http://archives.seul.org/geda/user/May-2009/msg00371.html) to integrate PCB with many different languages like python and lua, though I can't provide any details about it. HTH; probably, someone else will answer better than me, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20091103
Chitlesh GOORAH chitlesh.goo...@gmail.com wrote: I see the build places refcard to the docdir. Is it outdated or legacy documentation? In PCB's GUI there is already a Key Bindings menu. I believe this one entails uptodate key bindings rather than the refcard. If it is outdated, then I think it should be removed from pcb sources. I wonder if it builds unbroken (there is a recent report on SF tracker). Again in the make install process, pcb.html, pcb.ps and pcb.pdf are dumped into docdir. I think that everyone is using a modern linux distro with a pdf reader install by default on every desktop environment. I think you are not quite right. not everyone. even not everyone on this list. So is it wise to ship only the pcb.pdf ? This will decrease the size of the pcb RPM/deb to be downloaded by the user. pcb.pdf is the only one shipped by fedora rpms. What do you think ? Following http://www.gnu.org/server/fsf-html-style-sheet.html, I think that it is wise to offer a document in as many formats as supported. even when running a desktop with XWindow system I typically prefer documentation in text format, and I could explain why. You are free to decide whether users of your GNU/Linux distribution will benefit from including or removing documentation in particular formats, but I believe the OS-neutral tarball should include and install all of them. BTW, what packagers from different distros are going to do with this NEWS entry?: - [docs]Add getting started guide Best regards, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20091103 for Gentoo, working on ebuild
Stefan Salewski m...@ssalewski.de wrote: autoroute.c:3431: warning: ‘add_clearance’ defined but not used djopt.c:2461: warning: ‘nudge_corner’ defined but not used draw.c:381: warning: passing argument 3 of ‘DrawSilk’ discards qualifiers from pointer target type file.c:1129: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result report.c:680: warning: no return statement in function returning non-void rtree.c:203: warning: ‘__r_tree_is_good’ defined but not used hid/common/actions.c:88: warning: passing argument 1 of ‘hid_register_actions_context’ discards qualifiers from pointer target type hid/common/hidnogui.c:279: warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result hid/common/hidnogui.c:303: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result hid/common/hidnogui.c:321: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result hid/gtk/gui-dialog.c:101: warning: format not a string literal and no format arguments hid/gtk/gui-dialog.c:145: warning: format not a string literal and no format arguments hid/gtk/gui-top-window.c:2512: warning: format not a string literal and no format arguments Very nice reports (see attachment). hid/gtk/gui-dialog.c:172: warning: format not a string literal and no format arguments Should be like it is: the function semantics differ from the printf() ones. flags.c:226: warning: cast from pointer to integer of different size OffsetOf() shall not overflow even 16 bits when MAX_LAYERS 2048. parse_l.l:198: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result parse_l.c:1508: warning: ‘input’ defined but not used res_lex.l:64: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result res_lex.c:1139: warning: ‘input’ defined but not used Parser generator artifacts IMVHO. /usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer /usr/include/bits/string3.h:153: warning: call to __builtin___strncat_chk might overflow destination buffer No idea. hid/common/actions.c:214: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result hid/common/actions.c:215: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result If an error occurs while writing into stderr, probably the most useful reaction is to ignore it. hid/png/png.c:313: warning: ‘save_flags.f’ may be used uninitialized in this function One of the least PNG exporter issues addressed by this branch: http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/kai-martin-scriptaction Thanks, Ineiev 0001-fix-some-warnings-suggested-by-Stefan-Salewski.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: how to turn texts upside-down?
Peter Clifton pc...@cam.ac.uk wrote As Peter mentioned, you still need to disable to code to flip 180 degree rotated text back upright. grep for 180 in the files: libgeda/src/o_text_basic.c gschem/src/o_text.c There might be other places too, such as the text editing dialogues, but I'm not certain. Thanks, I'll look. Is this in Cyrillic, or Latin typeface? I wonder if the I18N rendering will do the right thing when thrown the appropriate UTF-8. It's Cyrillic; with recent gschem versions, it just works (though, have no idea about how the fonts should be installed). Do you have any example you could show us, as I'm having difficulty visualising the requirement. The attached cyrtest.sch (and exported from it cyrtest.png) is a rough approximation of a standard title. The label in the left upper corner is the document identifier, it duplicates the text in the lower right corner; that text in the left upper corner should be rotated like in cyr.png (done manually with gimp). Thanks a lot to all, Ineiev cyrtest.sch Description: Binary data attachment: cyrtest.pngattachment: cyr.png ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, I lost my layer colors
On Sun, 01 Nov 2009 Peter Clifton pc...@x: * Subject: Re: gEDA-dev: gEDA-cvs: pcb.git: branch: master updated commit 149ff2e16560e85e2f060c89020da121eb83f1b6 Author: Ineiev ine...@ Commit: DJ Delorie d...@xxx add attributes to layers Fix memory leaks of attributes May I humbly beg to CC such messages to gEDA-user? you see, I'm too nasty person to be subscribed to gEDA-dev and I usually don't read the archives; it is mere occasion that I read this message (I was curious about when pcb-20091101 is coming). PLEASE don't commit multiple fixes like this in the same patch. The finer grained our commits, the easier it is to use git bisect to track regressions and bug fixes. This is true, the proper way was to fix the leaks in one patch and introduce layer attributes in a subsequent one; however, DJ asked about single patch, and I didn't want to add _buggy_ support for layer attributes; nonetheless, I explained how to get even that buggy support. Also, I'm sure if someone had suggested splitting the patch in this thread, the desired result would follow in few hours if not less. Thanks and most sincere apologises, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, I lost my layer colors
On 10/24/09, Ineiev ine...@gmail.com wrote: I've just pushed another revision of the patch set to gitorious; A week later: just rebased against Dan's preparations to pcb-20091101; hardwired GTK background-color button in a more consistent way. Cheers ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB, I lost my layer colors
On 10/31/09, DJ Delorie d...@delorie.com wrote: A week later: just rebased against Dan's preparations to pcb-20091101; Can we get a patch that *just* adds support for reading, storing, and writing layer-specific Attribute()s ? Sure: the first patch in the set, format-patch output is attached (if you are really against the `fix memory leaks' part, discard the changes in src/mymem.c). I'd like to see that get into the next snapshot so that we have a little more backwards compatibility when we add the colors. Very nice IMO. Thanks, Ineiev 0001-add-attributes-to-layers.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: GTK SwapSides [was: Information on PCB]
On 10/27/09, Ineiev ine...@gmail.com wrote:
On 10/27/09, Peter Clifton pc...@cam.ac.uk wrote:
On Tue, 2009-10-27 at 05:47 +, Ineiev wrote:
On 10/27/09, Ineiev ine...@gmail.com wrote:
BTW, it seems to me that it does not really changes the groups
visibility: I press Tab with `component' layer from the component
group active and see the same `component' above all; the pads
are shown from the right side, though. am I doing
something wrong? I stack the patches on top of current master.
You might want Settings.ShowSolder or something like that.
Thanks, I'll check.
Actually,
diff --git a/src/hid/gtk/gtkhid-main.c b/src/hid/gtk/gtkhid-main.c
index 5472f10..3058e07 100644
--- a/src/hid/gtk/gtkhid-main.c
+++ b/src/hid/gtk/gtkhid-main.c
@@ -1995,20 +1995,22 @@ SwapSides (int argc, char **argv, int x, int y)
Settings.ShowSolderSide = !Settings.ShowSolderSide;
if (Settings.ShowSolderSide)
{
- if (active_group == comp_group comp_showing !solder_showing)
+ if (active_group == comp_group)
{
- ChangeGroupVisibility (PCB-LayerGroups.Entries[comp_group][0], 0,
-0);
+ if (comp_showing !solder_showing)
+ ChangeGroupVisibility (PCB-LayerGroups.Entries[comp_group][0], 0,
+ 0);
ChangeGroupVisibility (PCB-LayerGroups.Entries[solder_group][0], 1,
1);
}
}
else
{
- if (active_group == solder_group solder_showing !comp_showing)
+ if (active_group == solder_group)
{
- ChangeGroupVisibility (PCB-LayerGroups.Entries[solder_group][0], 0,
-0);
+ if (solder_showing !comp_showing)
+ ChangeGroupVisibility (PCB-LayerGroups.Entries[solder_group][0], 0,
+ 0);
ChangeGroupVisibility (PCB-LayerGroups.Entries[comp_group][0], 1,
1);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb flip-sides
On 10/29/09, DJ Delorie d...@delorie.com wrote: I think the fundamental problem is that we're mixing core actions (like setting the layer stackup) with GUI actions (like which side we're viewing). Sure. I feel this should remain unavoidable. That's why the png exporter has it's own other side option. offtopic To be exact, the Ben mode of png exporter, which is somewhat confusing IMVHO (why not in both modes? and what is --as-shown for, then?) /offtopic Perhaps we could extend the option which sets the visible layer stack to figure out (or specify) which side we're looking at, to at least set the side flag (but not any gui-specific flip/rotate settings)? With my short-sighted mind I think I'd rather make --action-string SwapSides a legal option (currently, it segfaults with both GTK and Lesstif GUIs); or (less intrusive and less elegant) add an action which would work for this particular case; it seems to me that this would be slightly more uniform from the user's point of view, even the latter case, because it will fit also the batch GUI usage (that action would work both from command-line and interactively, whereas the option may be issued once per PCB run). Though, by no means I'll mind if someone adds such an option, and probably we (me and Kai-Martin) shall really use it. This is the option you use with, for example, the eps exporter to specify the layer stacking order. That way, we can set the which side is up flag separately from the GUI actions to arbitrarily reposition the board. Otherwise, we'd need to put the board orientation in the core, and that would complicate things like the GLX 3-d view, which has tons of position information, at the expense of simpler exporters like Gerber which don't have a board orientation. But now it is not put in the core: both Lesstif and GTK have their own flags for flip-x and flip-y; in it is only ShowSolderSide that is in the core; I don't see why this must not be extented into the future. And actually I was not speaking about modifying PCB at all, I explained (in high degree, to myself) how the task may be accomplished with current PCB. Thanks, Ineiev ___ 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 10/27/09, Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2009-10-27 at 05:47 +, Ineiev wrote: On 10/27/09, Ineiev ine...@gmail.com wrote: Try the attached patch; it introduces SwapSides_nogui action for such Awfully sorry, forgot to commit a typo fix; and there is no need in `compatible' with GTK and Lesstif hids arguments parsing. BTW, it seems to me that it does not really changes the groups visibility: I press Tab with `component' layer from the component group active and see the same `component' above all; the pads are shown from the right side, though. am I doing something wrong? I stack the patches on top of current master. You might want Settings.ShowSolder or something like that. Thanks, I'll check. To be honest though, I'm not sure it is that desirable to have a generic swap sides action in the core - since for some exporters, it would be meaningless. Extrapolating, SwapSides should not change any core variables, so no exporter might know what side is actually shown. --photo-flip- options do implement this approach, OTOH I believe that the exporters that don't need some state values e.g. layer colours or visibility are just free to ignore them; there is nothing wrong in letting them read full state. probably there is no strict rule. I certainly wouldn't call it _nogui... either it is a sufficient interface for all applications (possibly requiring a new API in the HID structure to call into the GUI), or it should not go in. Actually, I wrote it for batch GUI (in hid/batch/batch.c), but then realised that exactly the same might be suitable for Kai-Martin case, too (after renaming the action to avoid names conflict); I just asked if it worked for him. Certainly, it would be nice if there were single action for all, though I'm not quite sure that I want HID interface to grow in this particular case (which would mean another string in every hid, while most of them will never use it) --- I'm afraid it will become unreasonably long some day. Just my impression which often is wrong. I'll try to refactor the code if you think it's worth doing. ___ 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 10/27/09, Kai-Martin Knaak k...@familieknaak.de wrote: On Mon, 26 Oct 2009 03:52:46 +, Peter Clifton wrote: It does -- sort of. The command pcb -x eps --action-string 'DISPLAY(Value)' --eps-file foo.eps bar.pcb does indeed output a layout with values displayed, even if the last saved version of pcb showed refdeses. However, not all actions have the expected effect with the export eps export HID. For example, --action-string 'SwapSides()' does not seem to change the output in any way. This particular action string option works fine if I present it to the GTK HID. My version of the patch showed the same room for improvement. Does the action itself know whether or not the current HID is a GUI? Try the attached patch; it introduces SwapSides_nogui action for such purposes. use it with --as-shown exporter option. Well, it shows pads from the wrong side, but this is probably an exporter feature, not the patch one. Cheers, Ineiev 0001-Add-SwapSides_nogui-action.patch Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
