gEDA-user: pcjc2 tessellation
On 11/09/10 07:59, Peter Clifton wrote:
On Fri, 2010-09-10 at 14:16 -0400, Windell H. Oskay wrote:
On Fri, Sep 10, 2010 at 01:31:48AM +0100, Peter Clifton wrote:
PS.. have you tried any of the GL stuff?
http://www2.eng.cam.ac.uk/~pcjc2/geda/trans_poly.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-1.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-2.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-3.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-4.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-5.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-6.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-7.png
Wow. These screenshots are incredible.
Thanks!
Please excuse my naive question, but is this something that the rest of us
can expect to see in PCB someday?
Some day.. eventually. It is a slow work in progress to get the code
clean enough to push into git HEAD. In the mean time, the branch is
before_pours in this repository:
git://repo.or.cz/geda-pcb/pcjc2.git
I've been working slowly to get the OpenGL stuff to co-exist with a
standard GDK build, but for the moment that isn't finished.
Hi,
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
In bo_contour_to_traps(), i get num_events = contour-Count = 0,
so i must be missing something. Here's the test i was trying:
void
borast(void)
{
Vector v;
v[0] = 0;// x
v[1] = 0;// y
PLINE *contour = poly_NewContour(v);
v[0] = 1;// x
v[1] = 0;// y
VNODE *node = poly_CreateNode(v);
VNODE *after = contour-head;
poly_InclVertex(after, node);
v[0] = 1;// x
v[1] = 1;// y
VNODE *node2 = poly_CreateNode(v);
poly_InclVertex(node, node2);
borast_traps_t traps;
bo_contour_to_traps(contour, traps);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: GL on non-accelerated hardware?
Hi, Is there any drawbacks running the GL renderer on system without hardware openGL support? Thanks, Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Logos and graphics.. [WAS: Re: Where is pcb-20100929 for Win32 ?]
On Sun, 2011-05-15 at 22:34 -0700, Colin D Bennett wrote: On Wed, 11 May 2011 11:43:50 +0100 Peter Clifton pc...@cam.ac.uk wrote: I've not seen PCB crash due to bad pstoedit polygons before though - if you have an example which is reproducible, please send it to me. I just re-tested and it is more tolerant now than previously. I think your pcb+gl stuff improved things. IIRC it would always crash on git HEAD, but now it only crashes if --enable-debug is given, with pcb: polygon.c:317: original_poly: Assertion `poly_Valid (np)' failed. (If you still care to see the pcb file causing this, I can send it to you.) Yes, it would be worth looking at. pstoedit is probably emitting a self-intersecting polygon, but until I've tested it I can't be sure. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GL on non-accelerated hardware?
On Mon, 2011-05-16 at 10:45 +0200, Kovacs Levente wrote: Hi, Is there any drawbacks running the GL renderer on system without hardware openGL support? It would be slower than the non-GL version, due to the software emulation of the graphics calls. Your X11 driver might have had 2D acceleration for the non-GL version's rendering calls, for example. Even if the non-GL calls were software drawn, the GL ones are still more complicated. Anyway, it would be worth testing to check. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
See suggestion inline with the code:
In bo_contour_to_traps(), i get num_events = contour-Count = 0,
so i must be missing something. Here's the test i was trying:
void
borast(void)
{
Vector v;
v[0] = 0;// x
v[1] = 0;// y
PLINE *contour = poly_NewContour(v);
v[0] = 1;// x
v[1] = 0;// y
VNODE *node = poly_CreateNode(v);
VNODE *after = contour-head;
poly_InclVertex(after, node);
v[0] = 1;// x
v[1] = 1;// y
VNODE *node2 = poly_CreateNode(v);
poly_InclVertex(node, node2);
After the last vertex in a contour, you need to finish preparing the
contour, with a call to:
poly_PreContour (contour, TRUE); /* TRUE turns optimisation for redundant
nodes on, FALSE should work too */
This calculates the contour's area, figures out what order you defined
the edges in (winding order), and constructs an r-tree of the edges (to
make the contour participate faster in boolean operations)
borast_traps_t traps;
bo_contour_to_traps(contour, traps);
}
--
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)
signature.asc
Description: This is a digitally signed message part
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Keyboard shortcut in pcb to increase line width
Mike Bushroe wrote: And when I select a line and try s, S, CTRL-s, CTRL-S, l' L + +CTRL-+, nothing happens. Don't select the line, pin, pad or text. Just let the mouse hover over the object you want to increase and press [s] key. [CTRL-s] will decrease the the size or line width. You can find a list of shortcuts the menu Info - Key_Binding A more comprehensive list is at http://geda.seul.org/wiki/geda:pcb-quick_reference ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 16/05/11 19:26, Peter Clifton wrote:
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
Hi,
I've looked in cairo before but never much got the hang of it
in detail.
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
I've always been interested in CAD programs and thought of making
a schematic/pcb one from scratch.
One thing i'm eternally conflicted with is relying on video-card
hardware that is closed source.
The problem with the free drivers is that when you send it polygons,
it could end up software rendering them, and you have no way of knowing
in advance if the performance will totally suck.
If you just generate pixels from scanline rendering in software,
this can be done directly from a list of arbitrarily intersecting
lines without requiring the bentley-ottmann polygon generator step.
You generate the whole window pixmap yourself and send that to the
screen.
Using this, i could avoid openGL. However, if an open hardware
accelerated openGL came along i was happy with, then i would need
to use the bentley-ottmann step to generate polygons, but i don't
understand that bit of code in detail, even though i've read the
paper. If i understood it in detail, then i could look closer at
how pcjc2 works and maybe improve something.
See suggestion inline with the code:
In bo_contour_to_traps(), i get num_events = contour-Count = 0,
so i must be missing something. Here's the test i was trying:
void
borast(void)
{
Vector v;
v[0] = 0;// x
v[1] = 0;// y
PLINE *contour = poly_NewContour(v);
v[0] = 1;// x
v[1] = 0;// y
VNODE *node = poly_CreateNode(v);
VNODE *after =contour-head;
poly_InclVertex(after, node);
v[0] = 1;// x
v[1] = 1;// y
VNODE *node2 = poly_CreateNode(v);
poly_InclVertex(node, node2);
After the last vertex in a contour, you need to finish preparing the
contour, with a call to:
poly_PreContour (contour, TRUE); /* TRUE turns optimisation for
redundant nodes on, FALSE should work too */
This calculates the contour's area, figures out what order you defined
the edges in (winding order), and constructs an r-tree of the edges (to
make the contour participate faster in boolean operations)
borast_traps_t traps;
bo_contour_to_traps(contour,traps);
}
Thanks muchly:)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GL on non-accelerated hardware?
On Mon, 16 May 2011 10:17:34 +0100 Peter Clifton pc...@cam.ac.uk wrote: It would be slower than the non-GL version, due to the software emulation of the graphics calls. Your X11 driver might have had 2D acceleration for the non-GL version's rendering calls, for example. Even if the non-GL calls were software drawn, the GL ones are still more complicated. Anyway, it would be worth testing to check. I give it a test on my netbook later this week. Levente -- Kovacs Levente leventel...@gmail.com Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 16/05/11 19:26, Peter Clifton wrote:
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
Hi,
In poly_PreContour(), the sign of the winding area is found by
summing the area of each box formed by consecutive points. It is
not clear if this method is valid. Is there a reference paper?
double area = 0;
...
do {
area += (double) (p-point[0] - c-point[0]) * (p-point[1] +
c-point[1]);
}
I think better if:
int area = 0;
...
do {
area += p-point[0]*c-point[1] - c-point[0]*p-point[1];
/* http://en.wikipedia.org/wiki/Polygon#Area_and_centroid */
}
because it calculates the total winding area of a polygon.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB crash
When I load the attached footprint to the buffer, and I say Break buffer elements to pieces PCB segfaults: leva@nowhere:~/git/library/electronic/footprint$ gdb --args pcb GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/pcb...done. (gdb) run Starting program: /usr/local/bin/pcb [Thread debugging using libthread_db enabled] [New Thread 0xb5eb5b70 (LWP 8220)] [New Thread 0xb54ffb70 (LWP 8221)] [New Thread 0xb4cfeb70 (LWP 8222)] [Thread 0xb4cfeb70 (LWP 8222) exited] [Thread 0xb5eb5b70 (LWP 8220) exited] *** glibc detected *** /usr/local/bin/pcb: double free or corruption (!prev): 0x085a70b8 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xdfa591] /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xdfbde8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xdfeecd] /usr/local/bin/pcb(SmashBufferElement+0x57a)[0x8080d9a] /usr/local/bin/pcb[0x806c43c] /usr/local/bin/pcb(hid_actionv+0xb4)[0x80e2284] /usr/local/bin/pcb[0x80e2652] /usr/local/bin/pcb[0x81164c8] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x7c)[0x974dcc] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2)[0x967252] /usr/lib/libgobject-2.0.so.0(+0x1f99d)[0x97b99d] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x754)[0x97cdb4] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0x97d256] /usr/lib/libgtk-x11-2.0.so.0(+0x64da5)[0x2ebda5] /usr/lib/libgtk-x11-2.0.so.0(gtk_action_activate+0x8d)[0x2edead] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x7c)[0x974dcc] /usr/lib/libgobject-2.0.so.0(+0x98b9)[0x9658b9] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2)[0x967252] /usr/lib/libgobject-2.0.so.0(+0x1f23a)[0x97b23a] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x754)[0x97cdb4] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0x97d256] /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_activate+0x95)[0x4f53e5] /usr/lib/libgtk-x11-2.0.so.0(gtk_menu_shell_activate_item+0x120)[0x3d39a0] /usr/lib/libgtk-x11-2.0.so.0(+0x14e31f)[0x3d531f] /usr/lib/libgtk-x11-2.0.so.0(+0x143c64)[0x3cac64] /usr/lib/libgtk-x11-2.0.so.0(+0x13d424)[0x3c4424] /usr/lib/libgobject-2.0.so.0(+0x98b9)[0x9658b9] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2)[0x967252] /usr/lib/libgobject-2.0.so.0(+0x1f5e6)[0x97b5e6] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x5d3)[0x97cc33] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0x97d256] /usr/lib/libgtk-x11-2.0.so.0(+0x26a636)[0x4f1636] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xcd)[0x3bca5d] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x307)[0x3bde07] /usr/lib/libgdk-x11-2.0.so.0(+0x5639a)[0x6b239a] /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1d5)[0x1f85e5] /lib/libglib-2.0.so.0(+0x3f2d8)[0x1fc2d8] /lib/libglib-2.0.so.0(g_main_loop_run+0x187)[0x1fc817] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb9)[0x3be3c9] /usr/local/bin/pcb(ghid_do_export+0x5d)[0x8119d4d] /usr/local/bin/pcb(main+0x920)[0x80ab3c0] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xda5bd6] /usr/local/bin/pcb[0x8067c71] === Memory map: 0011-0012b000 r-xp 08:01 1001788/lib/ld-2.11.1.so 0012b000-0012c000 r--p 0001a000 08:01 1001788/lib/ld-2.11.1.so 0012c000-0012d000 rw-p 0001b000 08:01 1001788/lib/ld-2.11.1.so 0012d000-0012e000 r-xp 00:00 0 [vdso] 0012e000-0013 r-xp 08:01 1018146 /lib/tls/i686/cmov/libdl-2.11.1.so 0013-00131000 r--p 1000 08:01 1018146 /lib/tls/i686/cmov/libdl-2.11.1.so 00131000-00132000 rw-p 2000 08:01 1018146 /lib/tls/i686/cmov/libdl-2.11.1.so 00132000-00156000 r-xp 08:01 1018147 /lib/tls/i686/cmov/libm-2.11.1.so 00156000-00157000 r--p 00023000 08:01 1018147 /lib/tls/i686/cmov/libm-2.11.1.so 00157000-00158000 rw-p 00024000 08:01 1018147 /lib/tls/i686/cmov/libm-2.11.1.so 00158000-0018f000 r-xp 08:01 1001800/lib/libdbus-1.so.3.4.0 0018f000-0019 r--p 00036000 08:01 1001800/lib/libdbus-1.so.3.4.0 0019-00191000 rw-p 00037000 08:01 1001800/lib/libdbus-1.so.3.4.0 00191000-001a6000 r-xp 08:01 1018175 /lib/tls/i686/cmov/libpthread-2.11.1.so 001a6000-001a7000 r--p 00014000 08:01 1018175 /lib/tls/i686/cmov/libpthread-2.11.1.so 001a7000-001a8000 rw-p 00015000 08:01 1018175 /lib/tls/i686/cmov/libpthread-2.11.1.so 001a8000-001aa000 rw-p 00:00 0 001aa000-001b1000 r-xp 08:01 1018177 /lib/tls/i686/cmov/librt-2.11.1.so 001b1000-001b2000 r--p 6000 08:01 1018177 /lib/tls/i686/cmov/librt-2.11.1.so 001b2000-001b3000 rw-p 7000 08:01 1018177 /lib/tls/i686/cmov/librt-2.11.1.so
Re: gEDA-user: pcjc2 tessellation
On Mon, 2011-05-16 at 22:59 +1000, Russell Shaw wrote:
On 16/05/11 19:26, Peter Clifton wrote:
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
Hi,
In poly_PreContour(), the sign of the winding area is found by
summing the area of each box formed by consecutive points. It is
not clear if this method is valid. Is there a reference paper?
double area = 0;
...
do {
area += (double) (p-point[0] - c-point[0]) * (p-point[1] +
c-point[1]);
}
Rearranging this:
(p-point[0] - c-point[0]) * (p-point[1] + c-point[1])
p-point[0] * (p-point[1] + c-point[1]) - c-point[0] * (p-point[1] +
c-point[1])
p-point[0] * p-point[1] + p-point[0] * c-point[1]) - c-point[0] *
p-point[1] - c-point[0] * c-point[1]
PX.PY + PX * CY- CX * PY
- CX * CY
So we have an undesired (PX*PY - CX * CY) term added for each triangle
in addition to the correct PX * CY - CX * PY. As we circle the whole
contour, these terms do cancel out, probably giving the correct result
in the end.
I think better if:
int area = 0;
...
do {
area += p-point[0]*c-point[1] - c-point[0]*p-point[1];
/* http://en.wikipedia.org/wiki/Polygon#Area_and_centroid */
}
That is also correct, and looks a lot nicer than the PCB code.
I can't think why we do it the way we do, but it could just be a
mistake.
I can't think of any normalising benefit the extra terms would have in
preventing overflow or anything like that. Please feel to chime in if
you know otherwise.
Send a patch to fix it up?
--
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)
signature.asc
Description: This is a digitally signed message part
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On Mon, 2011-05-16 at 21:38 +1000, Russell Shaw wrote: Hi, I've looked in cairo before but never much got the hang of it in detail. Its complex code implementing some hard to understand algorithms! One thing i'm eternally conflicted with is relying on video-card hardware that is closed source. PCB+GL works very nicely on Intel graphics HW, with completely a open source driver stack. It works even better on Nvidia ;) If you just generate pixels from scanline rendering in software, this can be done directly from a list of arbitrarily intersecting lines without requiring the bentley-ottmann polygon generator step. You generate the whole window pixmap yourself and send that to the screen. Using this, i could avoid openGL. However, if an open hardware accelerated openGL came along i was happy with, then i would need to use the bentley-ottmann step to generate polygons, but i don't understand that bit of code in detail, even though i've read the paper. If i understood it in detail, then i could look closer at how pcjc2 works and maybe improve something. I don't throw GL polygons, I still use the Bentley-Ottman step, as you can see. GL polygon primitives require convex, hole free polygons only, and our are not guaranteed to be. Some clever people are doing more complex polygon rasterisation in GL shaders I believe. Best wishes, -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Reinventing the wheel
I've always been interested in CAD programs and thought of making a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set just because. Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 16, 2011, at 10:44 AM, DJ Delorie wrote: I've always been interested in CAD programs and thought of making a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set just because. Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Why not start with the existing tools and just rewrite the parts you're interested in? License? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) Might interfere with someones script running someplace? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An idea: rework design support...
On May 14, 2011, at 11:08 PM, DJ Delorie wrote: To counter that.. I see no compelling reason to keep it though. We'll need it more when we add layer types. Real physical layers have material properties, thickness, and perhaps others. They don't have types. Given we'll probably end up keeping the irksome things, can we swap the terminology around? Yup. I think we decided sheets was the best term for what is now known as layers. Sheets are views of the design. They are not a direct representation of the physical structure. They are derived data, not fundamental. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
On Mon, 16 May 2011 15:48:29 +0200 Kovacs Levente leventel...@gmail.com wrote: When I load the attached footprint to the buffer, and I say Break buffer elements to pieces PCB segfaults: Confirmed with git HEAD 39dd5f6cd91ec9032c6d2e3ca543e3f8f6cf0e4a on amd64 (Ubuntu 11.04). GDB and Valgrind logs attached. Regards, Colin cdb@svelte:~/Code/pcb/work$ gdb --args src/pcb GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/cdb/Code/pcb/work/src/pcb...done. (gdb) run Starting program: /home/cdb/Code/pcb/work/src/pcb [Thread debugging using libthread_db enabled] sh: /home/cdb/Code/pcb/work/src/../share/pcb/ListLibraryContents.sh: not found [New Thread 0x7fffe9bc8700 (LWP 8411)] [New Thread 0x7fffe93c7700 (LWP 8412)] [New Thread 0x7fffe105a700 (LWP 8415)] [New Thread 0x7fffe0859700 (LWP 8416)] [Thread 0x7fffe0859700 (LWP 8416) exited] [Thread 0x7fffe9bc8700 (LWP 8411) exited] [New Thread 0x7fffe0859700 (LWP 8417)] [New Thread 0x7fffe9bc8700 (LWP 8418)] [New Thread 0x7fffe0058700 (LWP 8419)] [New Thread 0x7fffdf857700 (LWP 8420)] [New Thread 0x7fffdf056700 (LWP 8421)] [New Thread 0x7fffde855700 (LWP 8422)] [New Thread 0x7fffde054700 (LWP 8423)] [New Thread 0x7fffdd853700 (LWP 8424)] [New Thread 0x7fffdd052700 (LWP 8425)] [Thread 0x7fffdf056700 (LWP 8421) exited] [Thread 0x7fffdf857700 (LWP 8420) exited] [Thread 0x7fffde855700 (LWP 8422) exited] [Thread 0x7fffe105a700 (LWP 8415) exited] [Thread 0x7fffe0058700 (LWP 8419) exited] [Thread 0x7fffe9bc8700 (LWP 8418) exited] [Thread 0x7fffe0859700 (LWP 8417) exited] [Thread 0x7fffdd853700 (LWP 8424) exited] [Thread 0x7fffde054700 (LWP 8423) exited] [New Thread 0x7fffde054700 (LWP 8426)] [Thread 0x7fffde054700 (LWP 8426) exited] [New Thread 0x7fffde054700 (LWP 8427)] [Thread 0x7fffde054700 (LWP 8427) exited] [New Thread 0x7fffde054700 (LWP 8428)] [New Thread 0x7fffdd853700 (LWP 8429)] [Thread 0x7fffde054700 (LWP 8428) exited] [Thread 0x7fffdd052700 (LWP 8425) exited] Program received signal SIGSEGV, Segmentation fault. _int_free (av=0x7fffe420, p=0x7fffe4031030) at malloc.c:4942 4942malloc.c: No such file or directory. in malloc.c (gdb) bt #0 _int_free (av=0x7fffe420, p=0x7fffe4031030) at malloc.c:4942 #1 0x7238e8e3 in __libc_free (mem=value optimized out) at malloc.c:3738 #2 0x0043d9da in SmashBufferElement (Buffer=value optimized out) at buffer.c:929 #3 0x00427247 in ActionPasteBuffer (argc=1, argv=0xf4cd70, x=value optimized out, y=value optimized out) at action.c:6065 #4 0x0049c1bd in hid_actionv (name=value optimized out, argc=1, argv=0xf4cd70) at hid/common/actions.c:246 #5 0x0049c578 in hid_parse_actionstring ( rstr=0x922970 PasteBuffer(Restore), require_parens=1 '\001') at hid/common/actions.c:330 #6 0x004ce63a in ghid_menu_cb (action=value optimized out, data=value optimized out) at hid/gtk/gui-top-window.c:623 #7 0x74d3781c in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x74d49019 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x74d52258 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x74d5241f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 ---Type return to continue, or q return to quit--- #11 0x76821103 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x74d3781c in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x74d487e3 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x74d52258 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x74d5241f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x7fffe9dedc68 in ?? () from /usr/lib/libdbusmenu-gtk.so.3 #17 0x74d3781c in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x74d49019 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x74d52258 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x74d5241f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x7fffe9bd1c15 in dbusmenu_menuitem_handle_event () from /usr/lib/libdbusmenu-glib.so.3 #22 0x7fffe9bd31c7 in ?? () from /usr/lib/libdbusmenu-glib.so.3 #23 0x76e334eb in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ---Type return to continue, or q return to
Re: gEDA-user: Reinventing the wheel
Why not start with the existing tools and just rewrite the parts you're interested in? License? True. One of the benefits of the GPL is that people can bsae their work off existing work, but not everyone wants to offer that benefit to others. I really don't feel bad for people who need to start from scratch due to a desire not to share their code, though. Their choice, their pain. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: physics Re: Reinventing the wheel
John Doty j...@noqsi.com writes: Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. Epicycles are no less physics than Keplers Laws. They described the observed ephemerides of planets just fine (for the time). Kepler replaced them by ellipses because he found the math turns out easier that way, but there is no more physics in there than in Ptolemaeus math. It is often the case that the wrong choice of reference frame makes the math more complicated, but not necessarily wrong. Currently we believe that Einstein got the math right, at least as precise as we can measure. Does that make the GRT more physics than Kelpers laws or epicycles? You are right, though, epicycles are no good foundation to go any further, neither is general relativity. Kepler may fit just fine, simple Euklidian geometry in a plane. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
Colin D Bennett wrote: When I load the attached footprint to the buffer, and I say Break buffer elements to pieces PCB segfaults: Confirmed with git HEAD 39dd5f6cd91ec9032c6d2e3ca543e3f8f6cf0e4a on amd64 (Ubuntu 11.04). The footprint converts fine for Peters pcb+gl (dowloaded on 05.04.2011) and for PCB from git (on 23.02.2011) ---)(kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Pressing = key causes PCB to freeze for a few minutes
Peter Clifton wrote:
the two '=' or remove the whole part 'a={= Key=}', what will
remove this key-binding for this menu-item.
Yes, I can recommend removing this key binding.
I do in my local builds for the same reason, plus the fact that
sometimes the optimiser makes mistakes and causes shorts on my boards!
Another candidate is the short cut to Auto-Optimize. This is supposed
to be Shift+=. However, on German keyboards you have to type [shift-0]
to get the = character. What would I type to get Shift+= ?
---)kaimartin(---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
footprint converts fine for PCB fetched from GIT on 2011-03-29 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 16, 2011, at 10:21 AM, DJ Delorie d...@delorie.com wrote: Why not start with the existing tools and just rewrite the parts you're interested in? License? True. One of the benefits of the GPL is that people can bsae their work off existing work, but not everyone wants to offer that benefit to others. Biggest determent to the open source is now GPLv3 Private companies are now turned away from GPLv3. As it has some nasty clauses in it for their IP. In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple and many of the other players. The latest revision of the gpl threatens input from companies. Another reason to reinvent the wheel is when the wheel is not exactly what you need. http://www.youtube.com/watch?v=CjcyHicm3NAfeature=youtube_gdata_player http://www.rotacaster.com.au/ I really don't feel bad for people who need to start from scratch due to a desire not to share their code, though. Their choice, their pain. Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. ___ 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: Reinventing the wheel
Biggest determent to the open source is now GPLv3 OT here, since our stuff is still GPLv2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Mon, 2011-05-16 at 12:44 -0400, DJ Delorie wrote: I've always been interested in CAD programs and thought of making a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set just because. Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) I have no idea whom you cite, sorry. Many people dream about designing and building an own house -- and most computer science students dream about writing a compiler from scratch -- at the beginning of the education. Later they learn how difficult it is (writing a good one for a complicated language) and do something easier. Of course, only a very young child can do really something from scratch -- older people always build on existing knowledge, even when they write new code. Reasons for writing from scratch: - licenses - other programming language - other GUI toolkit - other operating system - other target audience (Fritzing has other target than gEDA/PCB/KICAD - learning - fun CLANG -- gcc , wayland -- xfree86, inkscape -- xfig -- a few promising rewrites from scratch. I think for learning purposes writing something from scratch is always a good decision. In most cases improving existing software is much more pragmatic. In my opinion, writing a PCB layout tool from scratch is very much work -- at least 5k hours for a very smart guy. (A group of people may need much more than 5k hours total, because they have to agree on language and Toolkit before starting and may waste much time with discussions.) For a simple schematics editor the task is much easier in these days, we have support through nice OO languages like Ruby or Python, GUI Toolkits like GTK or QT, and drawing support by libraries like cairo. So it was my idea that writing a (basic) gschem clone can be done in 1k hours resulting in about 15k lines of code. I started writing just for fun in last summer, now after about 400 hours of work I think that my initial estimation was not too bad, I think 25% is done. But I am still learning GTK, Cairo and Ruby, so progress was slow. If I really should finish that work, what is the benefit? 15k lines of code instead of 120k, only Ruby code, instead of C mixed with guile, and a smarter user interface. Not much, but maybe a better skeleton for other contributors? I don't know. Today, I think that working on the PCB (Topo)-Router instead of a gschem clone would have been a much more valuable task. But until one year ago Anthony's progress was so awesome, that it was my feeling that I had not much to offer in that direction. Now Anthony an his router has vanished -- but still I think that that task is better suited for really smart people, smarter than me. From time to time, when I have contact to a smart one with interests in electronics and programming, I tell him about that topic. Now that Anthony's homepage has disappeared, it is even more difficult to catch smart guys. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
On Mon, 16 May 2011 23:10:30 +0200 Kai-Martin Knaak k...@lilalaser.de wrote: Colin D Bennett wrote: When I load the attached footprint to the buffer, and I say Break buffer elements to pieces PCB segfaults: Confirmed with git HEAD 39dd5f6cd91ec9032c6d2e3ca543e3f8f6cf0e4a on amd64 (Ubuntu 11.04). The footprint converts fine for Peters pcb+gl (dowloaded on 05.04.2011) and for PCB from git (on 23.02.2011) I bisected the bug and determined it was introduced 2011-04-30 by the following commit: git commit: 2ce35292b9e96da38cb56878005aba20891689eb committer: Peter Clifton pc...@cam.ac.uk timestamp: Sat 2011-04-30 19:19:22 +0100 message: Convert board objects to GLists of g_slice allocated memory This enables pointers for these objects to be immutable during their lifetime, which is a _huge_ benefit for some operations. Having otherwise was becoming VERY tiresome, and was a perenial source of bugs tripping up novice and experts of the codebase alike. Due to the risks associated with modifying the structure being iterated over, this patch makes the relevant *_LOOP macros iterate over a shallow copy of the underlying GList. This is slight overkill for many cases, but until we have identified which do not modify the data-structures it is wise to keep as we are. Thanks to pcb's action scripting it was easy to do an automated test for my bisection script with src/pcb --action-string LoadFrom(ElementToBuffer,/tmp/RES400.fp) PasteBuffer(Restore) Quit() Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: physics Re: Reinventing the wheel
On Mon, 2011-05-16 at 20:52 +0200, Stephan Boettcher wrote: John Doty j...@noqsi.com writes: Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. Epicycles are no less physics than Keplers Laws. Epicycles really reminds me to gEDA. Both were great at their time, both still work. But today we can imagine more elegant tools. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
On Mon, 2011-05-16 at 15:22 -0700, Colin D Bennett wrote: On Mon, 16 May 2011 23:10:30 +0200 I bisected the bug and determined it was introduced 2011-04-30 by the following commit: git commit: 2ce35292b9e96da38cb56878005aba20891689eb committer: Peter Clifton pc...@cam.ac.uk timestamp: Sat 2011-04-30 19:19:22 +0100 message: Convert board objects to GLists of g_slice allocated memory Thanks for the bisect. TBH, I could have guessed with 99% certainty it would be that commit which caused the issue, but I didn't have chance to look at it earlier. I'll try and fix it shortly. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Monday 16 May 2011, Steven Michalske wrote: But lawyers can use that clause as a loophole to invalidate legitimate patents. Minor side effect of lawyers can use that clause as a loophole to invalidate ILLegitimate patents ... which outnumber the ligitimate ones a million to one. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 16, 2011, at 2:45 PM, DJ Delorie d...@delorie.com wrote: Biggest determent to the open source is now GPLv3 OT here, since our stuff is still GPLv2 Sorry for the OT bit, but v2 got a black eye from v3, commercially that is. I know of two companies shying away from all gpl, because of the or later clause in v2 and how you can apply v3 to it. Is that still in our gpl v2 license? But the whole bit countering your issues with reinventing the wheel, was on your topic. ___ 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: Reinventing the wheel
Steven Michalske wrote: In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. The notion of software patents is by no means obvious. In fact, it is subject to serous doubt. See the undulating tale of conflicting judgments by the (European) Court of Justice. Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple Neither of them is notorious for their contributions to the gcc code base. They both have the resources to roll their own compiler from scratch. Why don't they? and many of the other players. like the FSF? The latest revision of the gpl threatens input from companies. smells like FUD Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. There is no such clause in GPL3 The cases of openoffice shows how important the absence of loopholes in the GPL is to the continuous freedom of open sources software is. Oracle demonstrated how big players try to chain software written by others to their legal stronghold. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Sorry for the OT bit, but v2 got a black eye from v3, commercially that is. I know of two companies shying away from all gpl, because of the or later clause in v2 and how you can apply v3 to it. Is that still in our gpl v2 license? That phrase does not allow the user to change the licence, it merely allows them to use terms from a newer one. The license remains GPLv2 even if they do that. However, it applies to *distribution* not *reception* so if the company chooses v2.1 or v2.0 as their means, the recipient cannot retroactively apply v3.0 to them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
On Tue, 17 May 2011 00:10:07 +0100 Peter Clifton pc...@cam.ac.uk wrote: I'll try and fix it shortly. Peter, Thank you. Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On May 16, 2011, at 4:25 PM, al davis ad...@freeelectron.net wrote: On Monday 16 May 2011, Steven Michalske wrote: But lawyers can use that clause as a loophole to invalidate legitimate patents. Minor side effect of lawyers can use that clause as a loophole to invalidate ILLegitimate patents ... which outnumber the ligitimate ones a million to one. A software licence should not be used for this purpose... As a person with patents, I can't afford to contribute substantual code back, but I can use all the code I want. Because my patents are legitimate. But this is straying from this lists topic. I wish the best of luck to those that wish to reinvent this wheel, a gpl compatible library with a less restrictive licence bsd, MIT, etc... Could be used to extend pcb and gschem. And allow commercial interests to support us. ___ 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: Reinventing the wheel
On May 16, 2011, at 4:30 PM, Kai-Martin Knaak k...@lilalaser.de wrote: Steven Michalske wrote: In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. The notion of software patents is by no means obvious. In fact, it is subject to serous doubt. See the undulating tale of conflicting judgments by the (European) Court of Justice. The clauses are not limited to just software patents. Imagine building hardware with gschem, 100% legal and your design is yours. Now, you accidentally included a symbol with a gpl licence. Now I know we release the bulk of our symbols with explicitly free use licenes. But I may have used tom's that was pure gpl. And Tom saw my Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple Neither of them is notorious for their contributions to the gcc code base. They both have the resources to roll their own compiler from scratch. Why don't they? and many of the other players. like the FSF? The latest revision of the gpl threatens input from companies. smells like FUD Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. There is no such clause in GPL3 The cases of openoffice shows how important the absence of loopholes in the GPL is to the continuous freedom of open sources software is. Oracle demonstrated how big players try to chain software written by others to their legal stronghold. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
hit send too soon On May 16, 2011, at 4:30 PM, Kai-Martin Knaak k...@lilalaser.de wrote: Steven Michalske wrote: In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. The notion of software patents is by no means obvious. In fact, it is subject to serous doubt. See the undulating tale of conflicting judgments by the (European) Court of Justice. Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple Neither of them is notorious for their contributions to the gcc code base. They both have the resources to roll their own compiler from scratch. Why don't they? It is used as an argument for the gpl. With quotes of, without the gpl gcc would not have c++ or the objective c compiler. But I can't stand behind that statement, because it assumes the worst out of everybody. Apple has released lots of core technologies without the demands of gpl distribution rules. Launchd, clang and llvm, libdispach, blocks(closures) for c code, part of clang, Webkit. And many others. and many of the other players. like the FSF? The latest revision of the gpl threatens input from companies. smells like FUD It's from lawyers, that are paid to protect patents. Where I work we had big review processes to protect ourselvs from violating the v2 license, now we have an explicit ban. Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. This is not in the gpl, but often with the users/developers perception. How dare you make money off of my code, and not give the changes back to me. There is no such clause in GPL3 The cases of openoffice shows how important the absence of loopholes in the GPL is to the continuous freedom of open sources software is. Oracle demonstrated how big players try to chain software written by others to their legal stronghold. And not having loopholes is a good thing, no disagreement. But here the gpl did the same thing, put in a patent, and everyone gets free access to it and your related patents. That put a loophole in the patent system. Realistically there should be no patented material in the code. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash
On Tue, 2011-05-17 at 00:10 +0100, Peter Clifton wrote: On Mon, 2011-05-16 at 15:22 -0700, Colin D Bennett wrote: On Mon, 16 May 2011 23:10:30 +0200 I bisected the bug and determined it was introduced 2011-04-30 by the following commit: ... I'll try and fix it shortly. Now fixed - thanks for the alertness guys! -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: physics Re: Reinventing the wheel
On May 16, 2011, at 12:52 PM, Stephan Boettcher wrote: John Doty j...@noqsi.com writes: Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. Epicycles are no less physics than Keplers Laws. They described the observed ephemerides of planets just fine (for the time). Kepler replaced them by ellipses because he found the math turns out easier that way, but there is no more physics in there than in Ptolemaeus math. Yes there is. If you discover an asteroid, the first thing you'll do is fit the orbit to a Keplerian ellipse. Kepler's laws capture the essential physics of closed, stable solar orbits quite well. To fit to epicycles, you need lots of observations over many orbits, but a Keplerian ellipse can be determined from a small segment of an orbit. Much simpler and quicker. It is often the case that the wrong choice of reference frame makes the math more complicated, but not necessarily wrong. Currently we believe that Einstein got the math right, at least as precise as we can measure. Does that make the GRT more physics than Kelpers laws or epicycles? With just one more parameter per body than Kepler, Newtonian physics can capture the essence of many more kinds of orbits: not just ellipses around the sun, but moons, perturbed orbits, parabolas, hyperbolas, and chaotic orbits. That's the power of real physics: epicycles can't do anything like that. GR extends this even farther. It makes a huge difference to get the foundations right. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
