Jeff,
This makes sense to me so go ahead an push this to the main repo when
it's ready.
Wayne
On 4/2/19 11:47 AM, Jeff Young wrote:
>> ... I'm assuming SCH_PIN objects will only live inside the SCH_COMPONENT
>> object.
>
> Correct.
>
> Cheers,
> Jeff.
>
Hi all,
I found a way to avoid doing the wxCursor static init, which seems to
have pleased the pointer fairies. I have checked it builds on Windows
and Linux.
It should now be possible to write unit tests for eeschema in the same
way that tests are written for pcbnew and libcommon.
I have commit
Jeff,
This makes sense to me. I'm assuming SCH_PIN objects will only live
inside the SCH_COMPONENT object. I cannot see where a SCH_PIN object
would be needed anywhere else. It might be useful to hide the SCH_PIN
ctor to prevent unwanted construction by unauthorized code.
Cheers,
Wayne
On 4/
> ... I'm assuming SCH_PIN objects will only live inside the SCH_COMPONENT
> object.
Correct.
Cheers,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.n
We should always be using wxLogTrace. Using printf and cout are
meaningless on windows and wxLogDebug means that your debugging output
is always spewed on debug builds even when it's not needed. I haven't
made the draconian move of making this policy but maybe I should since
we seem to be leaving
Hi,
Just a quick plug for two fairly useful ways to "modularise" debug to
prevent insane amounts of logging overhead:
* trace masking, so you can turn on only what is needed to log. If you
want to conditionally trace more complex data, you can use
wxLog::IsAllowedTraceMask to prevent doing useles
Running in a separate thread is one avenue I'm exploring.
Right now in my testing, release builds are very fast (usually well below
100ms)
JP raised some concerns because in his testing (using debug builds) it was
unacceptably slow.
I have tested on his designs with my computer, and rebuilds happ
Jon,
I would think 100-150mS in release builds would be sufficient.
Obviously faster would be better because any perceptible delay is going
to annoy users. The problem with debug builds is they can vary
significantly depending on the platform and the amount of debugging
print output. I'm assumin
Jeff,
Before you push this to the main repo, please push the changes to your
personal launchpad repo so I see what you are changing. I'm not sure
merging these "shadow data structures" into SCH_PIN is necessarily the
correct thing to do. The connectivity information really depends on the
full ne
That sounds good, thanks!
-Jon
On Tue, Apr 2, 2019 at 8:44 AM Jeff Young wrote:
> Hi Jon,
>
> Just a heads-up, you might want to delay any changes to this stuff till I
> get a chance to merge.
>
> Over the years we’ve collected 5 shadow data structures for pins:
> locations, dangling states, hi
Hi Jon,
Just a heads-up, you might want to delay any changes to this stuff till I get a
chance to merge.
Over the years we’ve collected 5 shadow data structures for pins: locations,
dangling states, highlight flags, brightened flags and now connections. I’m
promoting your SCH_PIN_CONNECTION t
11 matches
Mail list logo
