Re: gEDA-user: Toporouter update?
-Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Anthony Blake Sent: Wednesday, March 17, 2010 9:14 PM To: wind...@oskay.net; gEDA user mailing list Subject: Re: gEDA-user: Toporouter update? On Thu, Mar 18, 2010 at 1:37 PM, Windell H. Oskay wind...@oskay.net wrote: ... btw, those toporouter guys are rather misleading with their results.. they show off pictures of boards which have been fixed up afterwards.. e.g., 20 mins of toporouter time, and 40 mins of hand editing for one of their boards. If that 20 minutes of toporouter time saves many hours of hand routing, then you're still way ahead. And while I'm on the subject of comparing autorouters.. I was looking at a Mentor license agreement the other day.. and I was shocked to see that they prohibit you from using it to compare results with other tools.. wtf.. Most database software companies have much the same restrictions. D ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB won't compile
Hi, 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. Levente -- Kovacs Levente kovacs.leve...@prolan.hu Voice: +36705071002 ___ 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
is that really building a 'motif' based frontend lol. On Thu, Mar 18, 2010 at 11:20 PM, Kovacs Levente leventel...@gmail.com wrote: Hi, 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. Levente -- Kovacs Levente kovacs.leve...@prolan.hu Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB won't compile
Ur? Not trendy enough for you? ;) -Dave On Mar 18, 2010, at 10:25 AM, timecop wrote: is that really building a 'motif' based frontend lol. On Thu, Mar 18, 2010 at 11:20 PM, Kovacs Levente leventel...@gmail.com wrote: Hi, 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. Levente -- Kovacs Levente kovacs.leve...@prolan.hu Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Dave McGuire Port Charlotte, FL ___ 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, Kovacs Levente writes: [...] 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) Change the line to read: ret = current_action-trigger_cb (argc, argv, px, py); instead of: ret = current_action-trigger_cb (argc, argv, x, y); Regards, Patrick ___ 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
On Thu, 18 Mar 2010 23:25:50 +0900 timecop time...@gmail.com wrote: is that really building a 'motif' based frontend lol. I miss some feature from the GTK HID: The layerlist, the toolbox, and the route style selection stuff can't be removed from the left. This waists space from the design. BTW, I'd add such feature to remove them. Everything is accessible from the menu. The next version of GTK will drop the support for tear-off menus. With the lesstif HID, I use it. I have two displays, and it helps me a lot. -- Kovacs Levente kovacs.leve...@prolan.hu Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB+GL Branches: URGENT WARNING
Dear all, It has come to my attention that my PCB+GL branches (starting from polygon_speedup onwards, contain a flaw which can in some circumstances result in subtly corrupted polygons - which can in turn ruin a finished board's connectivity. It is very important that until this is resolved, all those working with my experimental branches either: 1. Export their gerbers from git HEAD PCB rather than my branch. 2. Check their gerbers _incredibly_ carefully. 3. Disable some of the polygon speed-up functionality as follows: In src/polygon.c, you will find two lines: #define SUBTRACT_PIN_VIA_BATCH_SIZE 100 #define SUBTRACT_LINE_BATCH_SIZE 1 (Older versions of my branches had line batch size 1, but I cut back to 1 due to a similar bug). Change these to read: #define SUBTRACT_PIN_VIA_BATCH_SIZE 1 #define SUBTRACT_LINE_BATCH_SIZE 1 It appears this will work-around the issue for cases I've encountered, but unfortunately it will slow down polygon processing. I discovered this defect the hard way, with two boards on my bench needing awkward rework due to this problem. One was an obvious polygon corruption shorting out some tracks which I missed in gerbv.. the other was a pin which fails to clear its polygon on file-load, resulting in a short to ground-plane. I sincerely hope this has not bitten anyone else. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
On Thu, 2010-03-18 at 17:09 +1300, Anthony Blake wrote: Who's going to mentor you for GSOC purposes? Since Harry Eaton has never been shy with lots of really good criticism and comments regarding the toporouter (off list), I asked if he would be interested a few weeks ago.. Can you guys keep this on the geda-dev list in future.. it is always fun to see how things are progressing. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
Anthony Blake wrote: On Thu, Mar 18, 2010 at 12:56 PM, Windell H. Oskay wind...@oskay.net wrote: Also, can anyone think of a new name for the toporouter? There is already a commercial tool called the 'toporouter', which I don't want us to be confused with. untangler runtangler ( route untangler) grouter (gnu router) grout grout grout... groroute(gnu re-ripping organic route tool) growroute (gnu re-arranging organic wire router) goroute (gnu organic route tool) routeknot ( route knot want not) greenlight sigroute vinerouter liquidroute streamroute flowroute lamroute (laminar algorithm mapping router) ziptrace curveroute wraproute John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
On Thu, 2010-03-18 at 11:14 -0500, John Griessen wrote: Anthony Blake wrote: On Thu, Mar 18, 2010 at 12:56 PM, Windell H. Oskay wind...@oskay.net wrote: Also, can anyone think of a new name for the toporouter? There is already a commercial tool called the 'toporouter', which I don't want us to be confused with. untangler runtangler ( route untangler) grouter (gnu router) grout grout grout... groroute(gnu re-ripping organic route tool) growroute (gnu re-arranging organic wire router) goroute (gnu organic route tool) ^^^___ What does GNU have to do with any of this?? (g in gEDA is GPL, not GNU). routeknot ( route knot want not) greenlight -- Despite being the least router-ish of these names, I really like this one. sigroute vinerouter liquidroute ^^^___ avoid out of courtesy to the LiquidPCB folks streamroute flowroute lamroute (laminar algorithm mapping router) ziptrace curveroute wraproute -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ 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: Toporouter update?
Peter Clifton wrote: On Thu, 2010-03-18 at 11:14 -0500, John Griessen wrote: Anthony Blake wrote: On Thu, Mar 18, 2010 at 12:56 PM, Windell H. Oskay wind...@oskay.net wrote: Also, can anyone think of a new name for the toporouter? There is already a commercial tool called the 'toporouter', which I don't want us to be confused with. greenlight -- Despite being the least router-ish of these names, I really like this one. Hmm.. me too.. Since gEDA wasn't accepted into GSoC, I'm not going to be able to work on it as much as I would have liked unfortunately.. =( ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Branches: URGENT WARNING
On Thu, 2010-03-18 at 15:09 +, Peter Clifton wrote:
Dear all,
It has come to my attention that my PCB+GL branches (starting from
polygon_speedup onwards, contain a flaw which can in some
circumstances result in subtly corrupted polygons - which can in turn
ruin a finished board's connectivity.
Looks like this is due to poly_ContourInContour sometimes mistakenly
returning TRUE for touching contours. My sped-up polygon handling code
didn't appreciate that much. I've not yet identified whether this issue
can cause bugs in the git HEAD polygon handling.
The attached patch fixes the issue, but is painfully slow. Can anyone
suggest a better (faster) test for contour inside-ness which doesn't
sometimes return a false positive for touching contours?
[snip]
In src/polygon.c, you will find two lines:
#define SUBTRACT_PIN_VIA_BATCH_SIZE 100
#define SUBTRACT_LINE_BATCH_SIZE 1
(Older versions of my branches had line batch size 1, but I cut back
to 1 due to a similar bug).
Similar, but sadly unrelated. No magic bullet today.. the line issue
is (possibly) due to the gathering routines taking a wrong turn in the
infinitesimally touching case where various holes share edges.
I don't think it is a numerical stability / intersection topology
issue, rather errors in our / my handling of limiting cases.
Change these to read:
#define SUBTRACT_PIN_VIA_BATCH_SIZE 1
#define SUBTRACT_LINE_BATCH_SIZE 1
It appears this will work-around the issue for cases I've encountered,
but unfortunately it will slow down polygon processing.
For those looking to _use_ my branches, I'd recommend the above
workaround rather than re-fetching my branches with the attached patch
applied. The patch causes a huge slow-down due to its more obsessive
testing.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
From 5f8db06c35fabaeb29382f36cd3a1deaaaeac31d Mon Sep 17 00:00:00 2001
From: Peter Clifton pc...@cam.ac.uk
Date: Thu, 18 Mar 2010 20:43:58 +
Subject: [PATCH] Fix poly_ContourInContour() test not to return TRUE for touching contours
This test could previously return true for touching contours, such as:
__
|_ | :
: || :
:: /\ : || : Note that the bounding box of A is inside that of B,
:: / \ :/ \ : such that initial bounding box checks won't reject the
::/ A \/ B \: possibility of A being inside B.
::\/\/:
:: \ / :\ / :
::..\/..:.\/..:
When testing for insideness, the first point on A's contour is picked.
In this case, unfortunately being the touching X point between the two
contours. This point (correctly) returns as being inside B - and the
false presumption is that the whole A contour is inside B.
This commit introduces an unfortunately slow, but more robust test,
where we check each note in A for whether it is inside B. We return
as soon as we find an A node outside B, however this means the test
is VERY much slower for the case where A _is_ inside B.
---
src/polygon1.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/src/polygon1.c b/src/polygon1.c
index d9f6ce4..11e6146 100644
--- a/src/polygon1.c
+++ b/src/polygon1.c
@@ -2257,10 +2257,23 @@ poly_M_CheckInside (POLYAREA * p, Vector v0)
int
poly_ContourInContour (PLINE * poly, PLINE * inner)
{
+ VNODE *pt;
assert (poly != NULL);
assert (inner != NULL);
if (cntrbox_inside (inner, poly))
-return poly_InsideContour (poly, inner-head.point);
+{ /* FIXME: This is SLOW!!
+ * Check all points on the contour being tested, because we don't
+ * want to falsely return that two contours are inside each other
+ * if they just touch at a few points.
+ */
+ pt = inner-head;
+ do
+{
+ if (!poly_InsideContour (poly, pt-point))
+return 0;
+} while ((pt = pt-next) != inner-head);
+ return 1;
+}
return 0;
}
--
1.7.0
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
Can you guys keep this on the geda-dev list in future.. it is always fun to see how things are progressing. Certainly, if Anthony and I discuss anything now that GSoc is not to be. Previously, I couldn't subscribe or send to the geda-dev list (or user for that matter). That's why Anthony and I were discussing off list. It was a comcast thing. harry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
Harry Eaton wrote: Can you guys keep this on the geda-dev list in future.. it is always fun to see how things are progressing. Certainly, if Anthony and I discuss anything now that GSoc is not to be. I'm not going to stop working on the toporouter (greenlight?) just because Google didn't fund us. If people keep hassling me, I'll probably find the time for small commits here and there.. e.g., most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) Cheers, Anthony ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
On Mar 18, 2010, at 7:54 PM, Anthony Blake wrote: Can you guys keep this on the geda-dev list in future.. it is always fun to see how things are progressing. Certainly, if Anthony and I discuss anything now that GSoc is not to be. I'm not going to stop working on the toporouter (greenlight?) just because Google didn't fund us. If people keep hassling me, I'll probably find the time for small commits here and there.. e.g., most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) *hassle* *hassle hassle* -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
+1 *hassle* (i really like toporouter :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
I'm not going to stop working on the toporouter (greenlight?) just because Google didn't fund us. If people keep hassling me, I'll probably find the time for small commits here and there.. e.g., most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) Aside from hassling (hassle hassle hassle), please let us know what we can do to help out. I've shallower pockets than google, but perhaps some other folks here would also be willing to pitch in to help make it worth your while. ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter Update
I'm not going to stop working on the toporouter (greenlight?) just because Google didn't fund us. If people keep hassling me, I'll probably find the time for small commits here and there.. e.g., most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) Gosh, I was thinking about making a parody of your website comparing the two routers in pcb, where I would show test cases where boards had SMD parts on both sides and the toporouter couldn't route it but the autorouter could, then some with some existing hand-routing on the board, one with a ground plane going unused by the toporouter, etc. But I thought that would be mean so I didn't do it. (Even though I figured it would goad you in to fixing those problems). Seriously, I didn't think my criticisms were scathing, they were meant to be helpful. In any event, I'm still happy to give my blunt assessment and crazy ideas going forward. Cheers, harry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Branches: URGENT WARNING
Peter Clifton wrote: It has come to my attention that my PCB+GL branches (starting from polygon_speedup onwards, contain a flaw which can in some circumstances result in subtly corrupted polygons - which can in turn ruin a finished board's connectivity. Thanks for the warning! Luckily, I haven't been bitten by this bug, yet. Looks like this is due to poly_ContourInContour sometimes mistakenly returning TRUE for touching contours. You mean two polygons touching, but not solidly overlapping? For those looking to _use_ my branches, I'd recommend the above workaround rather than re-fetching my branches with the attached patch applied. Wouldn't it suffice to switch to the stable version of pcb for gerber output? The patch causes a huge slow-down due to its more obsessive testing. How about activating the obsessive tests only on export, or on explicit demand by the user? Say, with a button recalculate polygons. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter Update
Harry Eaton wrote: I'm not going to stop working on the toporouter (greenlight?) just because Google didn't fund us. If people keep hassling me, I'll probably find the time for small commits here and there.. e.g., most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) Gosh, I was thinking about making a parody of your website comparing the two routers in pcb, where I would show test cases where boards had SMD parts on both sides and the toporouter couldn't route it but the autorouter could, then some with some existing hand-routing on the board, one with a ground plane going unused by the toporouter, etc. But I thought that would be mean so I didn't do it. (Even though I figured it would goad you in to fixing those problems). Haha, don't worry, I can handle it.. I'm sure I would have had a come back.. But yes, in retrospect the website is crap.. I would like to replace it with a script that automatically generates the website (including all the images and results) each time I change the algorithms. I do stand by my decision to spend more effort on single layer performance before implementing vias though. My single layer performance improved considerably, for example on Windell's MeggyJr board, the wiring was reduced by over 30 inches by some changes. Not only that, *many* bugs were eliminated as I worked on single layers only.. those bugs would have been much harder to fix if the situation were complicated with vias. I actually found it a little frustrating that I was simultaneously being told by some people to implement vias, but also to spend time stabilizing and fixing existing code.. I just couldn't please everybody! Seriously, I didn't think my criticisms were scathing, they were meant to be helpful. In any event, I'm still happy to give my blunt assessment and crazy ideas going forward. Sorry, scathing was the wrong word.. What I meant was the criticism was well targeted and straight to the point (because of your knowledge of the internals of autorouters), which was hugely helpful (even if I didn't agree.. it was great to talk about the issues). In the cases where I didn't agree, I felt I needed to prove it, and that was the motivation for most of my commits last year. Thanks Harry =) Cheers, Anthony ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gpleda.org downtime this weekend (3/20 - 3/21)
Hi, I want to do an OS upgrade this weekend on gpleda.org. I don't expect long downtimes, but there might be a period of a couple hours of downtime. I'm not sure which day, but probably either Saturday afternoon/evening EST or Sunday. I'll send a note when things go down and when they come back. Let me know if this is a problem for anybody. Thanks, -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Branches: URGENT WARNING
On Fri, 2010-03-19 at 01:39 +0100, kai-martin knaak wrote: Peter Clifton wrote: It has come to my attention that my PCB+GL branches (starting from polygon_speedup onwards, contain a flaw which can in some circumstances result in subtly corrupted polygons - which can in turn ruin a finished board's connectivity. Thanks for the warning! Luckily, I haven't been bitten by this bug, yet. Looks like this is due to poly_ContourInContour sometimes mistakenly returning TRUE for touching contours. You mean two polygons touching, but not solidly overlapping? Not two separate polygons.. rather a single polygon with two touching holes. In my case, this was caused by two resistors with pins spaced such that their polygon clearances touched exactly. There had to be various other geometry around the touching case to cause it to manifest as well. For those looking to _use_ my branches, I'd recommend the above workaround rather than re-fetching my branches with the attached patch applied. Wouldn't it suffice to switch to the stable version of pcb for gerber output? Yes, although anyone using the pours variants of the code would still need the fix. The patch causes a huge slow-down due to its more obsessive testing. How about activating the obsessive tests only on export, or on explicit demand by the user? Say, with a button recalculate polygons. It needs to do it continuously or data-structures get corrupted. I think (and in agreement with Harry's comment), we just need to test one interior point of the polygon. Computing an interior point isn't totally trivial though. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GSoC -- Not accepted :-(
Stuart Brorson wrote in geda.devel: Why is the summer of code topic discussed on the developer list only? (Non-)acceptance to GSoC certainly matters to ordinary users, too. If you're interested, here's the list of accepted groups: http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010 ... Facebook ... Mozilla ... Gentoo Not exactly organizations I'd expect to need funding ;-) Browsing through the accepted applications almost all project goals would would make its little contribution to the potential success of one of the major google products -- many of them provide apps or software infrastructure for smart phones. (Selenium, coreboot, thousend parsec, NUI Group, etc). Unfortunately, the HTC dream wasn't designed with gschem and pcb... ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GSoC -- Not accepted :-(
On Fri, Mar 19, 2010 at 2:15 PM, kai-martin knaak k...@familieknaak.de wrote: If you're interested, here's the list of accepted groups: http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010 ... Facebook ... Mozilla ... Gentoo Not exactly organizations I'd expect to need funding ;-) Browsing through the accepted applications almost all project goals would would make its little contribution to the potential success of one of the major google products -- many of them provide apps or software infrastructure for smart phones. (Selenium, coreboot, thousend parsec, NUI Group, etc). Unfortunately, the HTC dream wasn't designed with gschem and pcb... A few of the accepted organizations seem a little odd.. I suspect someone just flicked through the pile of applications pulling out names they recognized.. There is even one accepted organization that seems like more of a feel good social club than an open source project.. I've been facepalming all morning. -- Anthony Blake ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
Anthony Blake wrote: greenlight -- Despite being the least router-ish of these names, I really like this one. Hmm.. me too.. I'd strongly suggest to invent a new word rather than take an existing buzzword. The term greenlight currently yields 1.5 Mio google hits. A greenlight router would be almost as invisible to internet searches as pcb ;-) Since gEDA wasn't accepted into GSoC, I'm not going to be able to work on it as much as I would have liked unfortunately.. =( So let's concentrate to the most blocking of all issues: If I got it right, these are the inability to deal with preexisting tracks and the missing way to confine the router to selected nets. If these issues were solved, even the router would already be valuable as an abbreviation during manual routing. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
On Fri, Mar 19, 2010 at 2:27 PM, kai-martin knaak k...@familieknaak.de wrote: So let's concentrate to the most blocking of all issues: If I got it right, these are the inability to deal with preexisting tracks and the missing way to confine the router to selected nets. If these issues were solved, even the router would already be valuable as an abbreviation during manual routing. The toporouter will already route a selection of nets if some nets are selected when the toporouter is invoked. But yes, if this worked with existing geometry it would be useful. Cheers, -- Anthony Blake ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
Anthony Blake wrote: The toporouter will already route a selection of nets if some nets are selected when the toporouter is invoked. Nice! ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
On Mar 18, 2010, at 9:15 PM, Anthony Blake wrote: Thanks for the offer =) On the one hand, I really want to finish the toporouter, and its hard while I'm studying full time.. so taking a funded break for a few weeks to work on the toporouter seems like a great option. On the other hand, there are a lot of other developers contributing code, and I'm not sure it would be fair if I received funding.. 1) It's YOUR autorouter. That makes you different in that regard. 2) If the only way you can contribute is with funding, and others are able to contribute without said funding, then, well, that's that. We're all friends here, I'm sure everyone understands. -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
On Fri, Mar 19, 2010 at 2:33 PM, kai-martin knaak k...@familieknaak.de wrote: Anthony Blake wrote: The toporouter will already route a selection of nets if some nets are selected when the toporouter is invoked. Nice! Also, it will only route on the currently visible layers. -- Anthony Blake ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 15, 2010, at 6:35 PM, Dan McMahill wrote: I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. I think your 2nd sentence hits the nail on the head. Simulator output can be for 2 things. 1) presentation like in a design review or a paper. When you get here, you're supposed to be done 2) this one is where the majority of the time is typically spent. debugging! Is the circuit hooked up right? Is it performing right? Why isn't it working right, why isn't it performing at the level you want. So think of the simulator and waveform viewer as a scope and a spectrum and network analyzer. The interactivity needs to be as easy in a waveform tool as it is in a scope. Since you have the disadvantages of model inaccuracies and simulation time being much longer than real time you want to further disadvantage yourself and you should take advantage of the zero-capacitance voltage probes, ideal current probes, gnucaps ability to access internals like diode junction current versus the charging current, etc. so why not do this with simulator output? This makes perfect sense of course. It's just that I've never even dreamed of doing that with a simulator. The concept just makes my head spin...in a good way. :) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: toporouter update
Anthony Blake wrote: most of my work last year was an answer to some scathing criticism from Harry.. I *had* to do something after that =) So, all we have to do is read the code, scratch our heads and find critiques to make and you'll be compelled to improve it? I may have to stay up late reading the code some... and send you some tip money too. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Toporouter update?
kai-martin knaak wrote: Anthony Blake wrote: greenlight --- I'd strongly suggest to invent a new word rather than take an existing buzzword. The term greenlight currently yields 1.5 Mio google hits. A greenlight router would be almost as invisible to internet searches as pcb ;-) Oh, it wouldn't be that bad. Pcb is the tool's category name as well as being a common term. Searching for greenlight router would narrow down just fine. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
