Anthony Blake wrote:
On Mon, Dec 6, 2010 at 4:18 AM, Armin Faltl armin.fa...@aon.at wrote:
Anthony Blake wrote:
Yes, if you were having difficulty with the END_LOOP macro, I can
understand why you didn't venture any deeper into the code.
I had no difficulty finding or
Am 06.12.2010 um 12:55 schrieb Armin Faltl:
Markus, did you realize by now, that drill file optimization is
actually
the NP-hard 'traveling salesman problem'? Tons of literature and
algorithms exist for it ;-)
Sure it is, and the original algorithm is back in place. Admittedly,
I only
On Mon, 2010-12-06 at 16:58 +1100, Stephen Ecob wrote:
If you use (or intend to use) lib dmalloc with PCB you will find the
following useful.
I've uploaded a patch against current heaad to sourceforge, ID
#3129279, described as follows:
Looks useful, I will push it, however, please explain
On Mon, 2010-12-06 at 14:18 +0100, Markus Hitter wrote:
The unfortunate thing about such commodity issues is, some people
built up a somewhat unfriendly attitude against any code changes at
all.
Sometimes there are some good reasons against code changes:
- huge increase in complexity
On Monday 06 Dec 2010 13:31:09 Peter Clifton wrote:
I did loose some respect for the dmalloc author(s) when I noticed on
their page they can't spell Microsoft Windows correctly. Windoze
In general, valgrind (probably not even conceived of when dmalloc was
first written), is a much more
Am 06.12.2010 um 16:32 schrieb Stefan Salewski:
Sometimes there are some good reasons against code changes:
- huge increase in complexity for minimal gain. gcc 4.x may be an
example for this -- for some architectures there was not much gain
from
3.x, for microcontrollers there was some
On 12/05/2010 05:03 PM, Anthony Blake wrote:
Along with the fact that no one is
helping me, the rate at which I've been chopping and changing
algorithms as I experiment with them is the reason I haven't
documented anything yet.
I'll be able to help more when I get some manufacturing business
On Dec 6, 2010, at 9:24 AM, Markus Hitter wrote:
Am 06.12.2010 um 16:32 schrieb Stefan Salewski:
Sometimes there are some good reasons against code changes:
- huge increase in complexity for minimal gain. gcc 4.x may be an
example for this -- for some architectures there was not much
First heads-up, some MORE renames!
local_customisation_no_pours -pcb+gl_experimental ---
SPLIT: Just the graphics stuff
-local_customisation_pcb+gl ---
SPLIT: Just my local stuff
local_customisation-
On Tue, Dec 7, 2010 at 12:31 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Mon, 2010-12-06 at 16:58 +1100, Stephen Ecob wrote:
If you use (or intend to use) lib dmalloc with PCB you will find the
following useful.
I've uploaded a patch against current heaad to sourceforge, ID
#3129279,
The start page of glpeda.org currently says:
/--
To get up and running as fast as possible, new users should install the
gEDA Binary Suite, which can be obtained from the download page.
\--
IMHO, an install via the local distribution is a lot faster and less
error
On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote:
Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could
expose latent bugs in the 71 callers of the mymem allocators.
I'm happy to proceed either way. What is your preference ?
Let me push a big patch nuking the My* allocation
On Tue, 2010-12-07 at 00:48 +, Peter Clifton wrote:
On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote:
Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could
expose latent bugs in the 71 callers of the mymem allocators.
I'm happy to proceed either way. What is your
On Tue, Dec 7, 2010 at 11:48 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote:
Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could
expose latent bugs in the 71 callers of the mymem allocators.
I'm happy to proceed either way. What
Peter Clifton wrote:
If you just want to build (and not make new commits), you can just
checkout the remote branch as follows:
git checkout origin/BRANCH_NAME
Thanks.
I'll try to add some portions of this potion to the wiki.
and since I started rendering with perspective, that
produces
On 07/12/10 11:55, Peter Clifton wrote:
On Tue, 2010-12-07 at 00:48 +, Peter Clifton wrote:
On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote:
Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could
expose latent bugs in the 71 callers of the mymem allocators.
I'm happy to
Joshua E. Lansford wrote:
The tool attached
(refdes_renum_slot) uses the same arguments as refdes_renum
except that when it finds components with a slot attributes,
it will pare them together and give them the same refdes.
What does your tool do on a renumber run, when it comes across
On Tue, 2010-12-07 at 11:58 +1100, Stephen Ecob wrote:
On Tue, Dec 7, 2010 at 11:48 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote:
Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could
expose latent bugs in the 71 callers of
On Tue, 2010-12-07 at 01:58 +0100, kai-martin knaak wrote:
and since I started rendering with perspective, that
produces a size discrepancy between layers depending on their depth.
Ah, this puts the visuals into perspective ;-)
I see what you did there.. very funny ;)
Thanks for the
I count 54 locations in head that call MyStrdup()
A run time check of calls to MyStrdup() shows:
create.c:197 made 0 NULL calls, 48 good calls
create.c:219 made 0 NULL calls, 32 good calls
create.c:238 made 0 NULL calls, 1 good calls
create.c:240 made 0 NULL calls, 1 good calls
create.c:286 made
So calls with a NULL pointer are rare, but there are at least 3
callers that require tolerance of it.
I wouldn't call 3% rare. Uncommon, perhaps, but given who those three
callers are, it's far more significant than mere numbers show.
___
I propose the following solution:
1. replace all calls to MyCalloc() with calls to calloc()
2. replace all calls to MyMalloc() with calls to malloc()
3. replace all calls to MyRealloc() with calls to realloc()
4. replace all calls to SaveFree() with calls to free()
5. retain the MYFREE() macro as
5. retain the MYFREE() macro as its pointer clearing side effect is required
8. Instead of simply retaining MYFREE(p) (point 5), we could replace
each use of it with an explicit:
free(p);
p = NULL;
Is this MY prefix actually in the code?
Most sane places call the kind of free your'e
Is this MY prefix actually in the code?
It's free software, you could just look at the code yourself.
Yes, the MY prefix is used in pcb, otherwise why would we be talking
about it?
___
geda-user mailing list
geda-user@moria.seul.org
On Tue, Dec 7, 2010 at 3:06 PM, timecop time...@gmail.com wrote:
5. retain the MYFREE() macro as its pointer clearing side effect is required
8. Instead of simply retaining MYFREE(p) (point 5), we could replace
each use of it with an explicit:
free(p);
p = NULL;
Is this MY prefix actually
I just submitted a patch for some memory leaks that have been annoying
me. The soureforge id is #3131063:
https://sourceforge.net/tracker/?func=detailaid=3131063group_id=73743atid=538813
Most users won't have noticed these leaks as only around 1MB is leaked
each time a new PCB is loaded. The
Date: Mon, 06 Dec 2010 01:13:49 +
From: Peter Clifton pc...@cam.ac.uk
Subject: Re: gEDA-user: Random thoughts on the future interface of PCB
[...]
Anyhow.. if there is some patch / fix you're referring to specifically,
ping it back up and someone might take an interest. I'll acknowledge
Agreed, and I had a similar experience. I was hoping to get a review or just
some comments on a couple of patches I submitted (3114991, 3117075). Now I
can understand that it was probably in an off beat area and not the topic du
jour, so I went ahead and posted it to the patches tracker. No
28 matches
Mail list logo
