Hi Peter,
Thanks for your help. I tried your advice and found the problem. Turns
out there must be some glitch in EXA acceleration that causes it to
spend 96% of processor time doing memcpy; google led me to some people
with memcpy problems related to EXA. So I changed to XAA acceleration
and
On Oct 9, 2010, at 6:44 PM, John Griessen wrote:
> On 10/09/2010 08:14 PM, Dave N6NZ wrote:
>> KiCAD -- I haven't tried it myself, so I don't know much about it's
>> capabilities.
>
> When I first looked at it a couple of years ago it was a small group,
> but now it seems to have critical mass
On 10/09/2010 08:14 PM, Dave N6NZ wrote:
KiCAD -- I haven't tried it myself, so I don't know much about it's
capabilities.
When I first looked at it a couple of years ago it was a small group,
but now it seems to have critical mass -- about 12 developers.
It's a integrated-through-GUI kind of
On 10/04/2010 01:11 AM, DJ Delorie wrote:
>
>> After porting pcb_spawnvp (in src/action.c) to Windows, it built fine on
>> Ubuntu using my cross-compiler build script (minipack). I'll work on a
>> patch. Fortunately, the Windows API already provides an implementation
>> of spawnvp.
>
> Excelle
I thought maybe it was FreePCB.
Rick
At 09:14 PM 10/9/2010, you wrote:
KiCAD -- I haven't tried it myself, so I don't know much about it's
capabilities.
-dave
On Oct 9, 2010, at 3:48 PM, Rick Collins wrote:
> I assume one is gEDA... what is the other?
>
> Rick
>
>
> At 01:56 AM 10/9/2010,
KiCAD -- I haven't tried it myself, so I don't know much about it's
capabilities.
-dave
On Oct 9, 2010, at 3:48 PM, Rick Collins wrote:
> I assume one is gEDA... what is the other?
>
> Rick
>
>
> At 01:56 AM 10/9/2010, you wrote:
>> Good on you. It really gripes me when open hardware proje
On Sat, 2010-10-09 at 23:29 +0200, Felix Ruoff wrote:
> Hello,
>
> today I am trying to make patches from my recent days work. I am new to
> git, so it takes much more time than I expected...
> But, here are two more patches.
>
> The first one (0002...) removes some unused functions from the gtk
On Sat, 2010-10-09 at 13:34 +0200, Karl Hammar wrote:
> If you don't show the solder layer (View->Shown Layers->Solder, or ctrl-2),
> it is easier, because then you won't by mistake grab a copper trace.
Or select "Settings->Only Names" which will lock out everything except
text from being moved.
On Oct 9, 2010, at 5:41 PM, DJ Delorie wrote:
>>>
>>> I'm surprised we're still discussing this *at all*.
>>
>> You can't build a solid system on a shaky foundation. This is
>> precisely the kind of thing we need to get right, or it will
>> continue to cause unexpected artifacts to appear.
>
>
Probably KiCad.
On Sun, Oct 10, 2010 at 7:48 AM, Rick Collins wrote:
> I assume one is gEDA... what is the other?
>
> Rick
>
>
> At 01:56 AM 10/9/2010, you wrote:
>>
>> Good on you. It really gripes me when open hardware projects use
>> something like Eagle for the schematic/pcb flow. The curr
At 03:36 PM 10/9/2010, you wrote:
Rick Collins writes:
> To be perfectly correct, anyone who needs more than 84x84 inch boards
> will need to recompile PCB with 64-bit units. If it is me, I have no
> idea how to, so I can not. But I don't plan to. If I need boards
> larger than 84x84 inches,
At 06:51 AM 10/9/2010, you wrote:
Rick Collins:
> At 05:04 PM 10/8/2010, you wrote:
> >Rick Collins:
> > > At 02:28 PM 10/8/2010, you wrote:
> > > >Andrew Poelstra:
> > > > > On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
...
> >With integer types you get aliasing artifacts, which a
At 05:44 AM 10/9/2010, you wrote:
Is this seriously turning into a pissing match
So stop pissing on each other. I'm getting tired of the
blow-by. This goes for Armin as well. Is there some reason we can't
keep this civil?
Rick
___
geda-user
At 04:22 AM 10/9/2010, you wrote:
Rick Collins wrote:
Yes, it is about tolerance... and error. How much error will be
introduced into a design if the system rounds all metric
measurements to 0.01 mils? How much tolerance is
acceptable? When you can answer these two questions for all
desig
I assume one is gEDA... what is the other?
Rick
At 01:56 AM 10/9/2010, you wrote:
Good on you. It really gripes me when open hardware projects use
something like Eagle for the schematic/pcb flow. The current object
of my derision for doing that is the RepRap foundation. Today there
are at
> > I'm surprised we're still discussing this *at all*.
>
> You can't build a solid system on a shaky foundation. This is
> precisely the kind of thing we need to get right, or it will
> continue to cause unexpected artifacts to appear.
I think we got it right the first time we discussed it way
On Oct 9, 2010, at 11:18 AM, DJ Delorie wrote:
>
>> I am surprised by the efficiency debate.
>
> I'm surprised we're still discussing this *at all*.
You can't build a solid system on a shaky foundation. This is precisely the
kind of thing we need to get right, or it will continue to cause une
On Oct 9, 2010, at 10:28 AM, Kevin Vermeer wrote:
> What can we do to gEDA to make it more accessible to these
> folks?
IMHO, the OP is on the right track. It will take less energy and time to
simply fork the designs and push them out to a public repo than to lobby with
the originators.
DJ Delorie wrote:
>
>> I am surprised by the efficiency debate.
>
> I'm surprised we're still discussing this *at all*.
I think/hope, this is future developers getting a feel for
the project :-)
---<)kaimartin(>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/
Hello,
today I am trying to make patches from my recent days work. I am new to
git, so it takes much more time than I expected...
But, here are two more patches.
The first one (0002...) removes some unused functions from the gtk-gui-code.
The second one (0004...) introduces the gtk-default-di
Hello all,
Thanks for the appreciation you have given. The main reason for me to
redesign the Arduino was the closed tool used in its present design.
Open Hardware projects should use free software for their designs. Even
the tool used for hardware design must be open or else wh
Hello,
attached is a patch, witch will replace the implemented recent-file-list
of gschem by a recent-file-list, which used gtk-default-functions.
Why do I think this patch is useful?
- This patch reduces the code-size of about 200 lines (smaller code,
easier to read & debug).
- No external
Rick Collins writes:
> To be perfectly correct, anyone who needs more than 84x84 inch boards
> will need to recompile PCB with 64-bit units. If it is me, I have no
> idea how to, so I can not. But I don't plan to. If I need boards
> larger than 84x84 inches, I will hire one of you to either la
On Sat, 2010-10-09 at 19:36 +0200, Armin Faltl wrote:
> IMO, a high resolution raster image of the layers and pdf of the
> schematic would qualify
> as open HW without problems.
So each binary executable can be considered open source -- we can
manipulate it with a hex editor, maybe with an assem
Kevin Vermeer wrote:
2. Necessary Software
If the hardware requires software, embedded or otherwise, to operate
properly and fulfill its essential functions, then the documentation
requirement must also include at least one of the following: The
necessary software, rele
On Sat, Oct 9, 2010 at 1:56 AM, Dave N6NZ <[1]n...@arrl.net> wrote:
Good on you. It really gripes me when open hardware projects use
something like Eagle for the schematic/pcb flow. The current object
of my derision for doing that is the RepRap foundation. Today there
are
On Sat, 2010-10-09 at 11:06 -0600, John Doty wrote:
>
> I am surprised by the efficiency debate. I would think that for pcb,
> the vast bulk of calculation involves rendering graphics in device
DRC checks, clearing polygons,...
Auto-Router may be distinct problem, I think Anthony did export/imp
Very nice design. I see you have managed to keep it to a single layer
board. Very tough to do with so many signal pins. Now I need to design
a shield for it that control motor driver H-bridges to control a
practice robot for our FIRST FRC competition!
Mike
_
> I am surprised by the efficiency debate.
I'm surprised we're still discussing this *at all*.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Oct 9, 2010, at 4:30 AM, Karl Hammar wrote:
>>
>> but scaled integers are a bit easier to use and understand,
>
> Yes (but we are talking about internal values, the user don't have to
> "see" them, only the developers, think of todays "1mm").
In an open source toolkit, the distinction betw
Hello,
I found a small bug on moving over a menu-item in gschem which has
submenu-items. This is, e.g., the recent-file-menu. The log-window gives
some warnings because this menu-items have no action defined. The
appended patch fixes this.
It would be nice, if one ore more of you can test t
On Oct 9, 2010, at 3:25 AM, Armin Faltl wrote:
>
>
> Edward Hennessy wrote:
>> On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote:
>>
>>> To express the many-to-many relation between parts and symbols it uses
>>> a table called "device". This is fed by the infamous device attribute
>>> in the sym
Andrew:
> On Sat, Oct 09, 2010 at 12:22:52PM +0200, Karl Hammar wrote:
> > You cannot dissmiss floating point on the ground of rounding error
> > when in fact the rounding error of integers (aliasing, truncation)
> > are in fact greater.
> >
> > You cannot dissmiss floating point on the ground of
On Sat, 2010-10-09 at 08:37 -0700, Andrew Poelstra wrote:
> that your 254-nm mils will no longer be accurate.
>
Will you make chips? I think they are already below 32nm.
Confused with um?
Sorry, I will not follow this discussion, I am sure the smart PCB
developers will do it right. But my feel
> Once you get past the 52 digits in an IEEE-754 double
How would such numbers be represented in a file?
One of gEDA/PCB's strengths is they are easy to script.
Scripting (u)ints seems a lot easier.
--
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.c
> $ ./testb
> Loop time for x++
> int32_t 2.429795
> int64_t 2.664763
>
> Loop time for x *= 5
> int32_t 2.641352
> int64_t 4.079825
We're not storing our core units as doubles.
We do a *lot* of "Px = Cx * m + b" type of operations; scalar
multiplication is going to be a factor. We also do a
Andrew Poelstra wrote:
I think we should also test sin and cos -- and since for integers,
there will be casts involved on either side, I suspect there will
be a performance hit.
Also sqrt and pow. (In Lisp, isqrt beats sqrt, but I just tested
in C (gcc -O3 -lm), and sqrt wins by a factor of 10
On Sat, Oct 09, 2010 at 12:22:52PM +0200, Karl Hammar wrote:
>
> You cannot dissmiss floating point on the ground of rounding error
> when in fact the rounding error of integers (aliasing, truncation)
> are in fact greater.
>
> You cannot dissmiss floating point on the ground of a "non exact"
> e
On Sat, Oct 09, 2010 at 04:02:37PM +0200, Karl Hammar wrote:
>
> As you can see from above:
> int32_t is fastest for simple + and *
> double has an almost constant operator time
>
> The performance choise is between int32_t and double:
> for "+" int32_t wins with a factor 2, and for "*" doubl
On Sat, 2010-10-09 at 00:24 -0700, jeffrey antony wrote:
> Hello ,
> 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 eas
timecop:
> Does anyone on this list honestly believe that in 2010 a difference
> between "slow emulated 64bit" and "native 64bit" integer on any
> hardware made in the last decade is going to be even noticeable.
...
You have to test to know, and you can get a first impression by
this simplistic te
Does anyone on this list honestly believe that in 2010 a difference
between "slow emulated 64bit" and "native 64bit" integer on any
hardware made in the last decade is going to be even noticeable. Just
make it 64bit and be done with it. Those who still use PCB on 386 can
use the old version.
It se
> Then Armin can have his long long, I can have my
> doubles, some can have their int64_t, and most can have their simple
> int.
Sounds like a support nightmare in the making.
uint_fast32_t
http://www.dinkumware.com/manuals/?manual=compleat&page=stdint.html#uint_fast32_t
With a compiler that pro
Armin Faltl:
> DJ Delorie wrote:
> >> Please forgive my ignorance, but can't one just define a 64bit
> >> integer on a 32bit system?
> > Yes, but there's a loss of performance if you do that.
> if one really is anal about it, use 'long long int' which is an 80-bit
> integer on Intel
> machines and
jeffrey antony:
...
> 1) I have some problems with the PCB files in this design. I am not
> able to move component descriptors. At present many of the component
> descriptors are overlapped (eg: R4 and LED14). Please let me know
> how to move these. In gschem moving the component descriptors are
>
DJ Delorie:
> The root cause of the problem is that the grid setting is a floating
> point number.
...
No, the problem is that the grid setting (e.g.) cannot be exactly
represented in *either* integers or floats (with the current basic
unit).
Regards,
/Karl Hammar
-
Aspö Data
Lilla Aspö
Rick Collins:
> At 05:04 PM 10/8/2010, you wrote:
> >Rick Collins:
> > > At 02:28 PM 10/8/2010, you wrote:
> > > >Andrew Poelstra:
> > > > > On Fri, Oct 08, 2010 at 11:46:39AM +0200, Armin Faltl wrote:
...
> >With integer types you get aliasing artifacts, which actually is a
> >rounding error. We h
John Doty:
> Karl Hammar wrote:
> > So, in what way are floats worse than ints (I'm talking about
> > representaion, not about performance) and why could we not "reasonably
> > use floating-point"?
> The problem is that in engineering documentation, dimensions are
> generally given as decimal fra
timecop wrote:
Is this seriously turning into a pissing match
you name it, you get it: it's no longer about technical arguments, it's
about the amount of shit one can produce: you won!!!
___
geda-user mailing list
geda-user@moria.seul.org
http:/
Edward Hennessy wrote:
On Apr 29, 2010, at 2:14 AM, Armin Faltl wrote:
To express the many-to-many relation between parts and symbols it uses
a table called "device". This is fed by the infamous device attribute
in the symbol libraries. There's nothing wrong in the theory of DB-design
with
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
Andrew Poelstra:
> On Fri, Oct 08, 2010 at 11:04:59PM +0200, Karl Hammar wrote:
> >
> > Please, I was commenting about the misunderstandings about
> > "floating-point", not about mils and mm's.
> >
> > With integer types you get aliasing artifacts, which actually is a
> > rounding error. We have
Is this seriously turning into a pissing match between the year a
professional filesystem was released vs a home brew hack? NTFS in 1993
was lightyears ahead of anything Lunix had to offer. Undelete, anyone?
How about being able to delete a 20gb file without locking entire
system up?
Hi timecop,
your first message I just deleted which is a rare exception on this
list. Since DJ did, I'll waste some seconds and joules on you:
a) 2010 - 16 = 1994
b) http://en.wikipedia.org/wiki/Ext2 -> Jan 1993, 1 file max 2TB
c) the first versions of NTFS had limits completly different than no
Only slow on a 386.
Oh, I forgot. Most of Lunix enthusiasts are still using that.
On 9 Oct 2010 18:23, "Levente Kovacs" <[1]leventel...@gmail.com> wrote:
> On Fri, 8 Oct 2010 14:55:10 -0400
> DJ Delorie <[2...@delorie.com> wrote:
>
>> Yes, but there's a loss of performance if
On Fri, 8 Oct 2010 14:55:10 -0400
DJ Delorie wrote:
> Yes, but there's a loss of performance if you do that.
So, I'd put there a compiling option like 'enable huge boards (might be slow
on 32bit systems)
Levente
___
geda-user mailing list
geda-use
Rick Collins wrote:
Yes, it is about tolerance... and error. How much error will be
introduced into a design if the system rounds all metric measurements
to 0.01 mils? How much tolerance is acceptable? When you can answer
these two questions for all designs and all users you can't expect
a
DJ Delorie wrote:
Please forgive my ignorance, but can't one just define a 64bit
integer on a 32bit system?
Yes, but there's a loss of performance if you do that.
if one really is anal about it, use 'long long int' which is an 80-bit
integer on Intel
machines and they are handled by
DJ Delorie wrote:
I'm guessing they're around 0.5 to 1.0 meter, based on the size of the
drill machines..
I think for my vendor at least on multilayer boards the limiting factor
is the lamination press.
It's using a vacuum chamber to get the air out of the laminate, so no
moving in any directi
Hello ,
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.
60 matches
Mail list logo
