Re: [Kicad-developers] Bus upgrades merge

[Diego Herranz]

Thanks, JP. I've created https://bugs.launchpad.net/kicad/+bug/1838140.

Cheers,
Diego

On Sat, 27 Jul 2019 at 15:03, jp charras  wrote:

> Le 27/07/2019 à 14:35, Diego Herranz a écrit :
> > Hi, all.
> >
> > I'm using nightlies and facing a weird bug with buses. I was wondering
> > whether it can be related to these bus upgrades.
> >
> > I've got a bus:
> > ROW0, ROW1, ROW2, ROW3, ROW4, ROW5, ROW6, ROW7, which on the PCB layout
> > becomes
> > ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW7 ???
> > It seems to be semi-random and I've seen other combinations too.
> >
> > I've managed to reduce the SCH to a minimal example (link below).
> > Further changes to this seem to fix it somehow, so I couldn't reduce it
> > anymore.
> > Note that one of the symbols is not on the official library so I've
> > included a local library.
> > I've tried replacing that symbol for a standard header, but that seems
> > to fix the problem, although I can't see anything wrong with the symbol
> > itself.
> >
> > Can anyone confirm that it is a bug and not something I'm doing wrong?
> > Is it related to this upgrade?
> > Please let me know how to proceed. I can report the bug on launchpad.
> >
> > Many thanks!
>
> I confirm there is a serious issue shown by this sample: the netlist is
> broken.
> Moreover, when I try to add a bus name ("ROW[0..7]") to the bus,
> Eeschema crashes.
> Looks like the bug has something to do with hierarchical labels.
>
> I do not see issues with the schematic.
>
> Please, report the bug on launchpad.
>
> >
> >  bus_bug.zip
> > <
> https://drive.google.com/file/d/1K7tWvM5M8F-Y-2bBwAPGBKG7O452hcrL/view?usp=drive_web
> >
> >
> >
> > Application: KiCad
> > Version: 6.0.0-unknown-6b031d9~100~ubuntu16.04.1, release build
> > Libraries:
> > wxWidgets 3.0.2
> > libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
> > Platform: Linux 4.4.0-157-generic x86_64, 64 bit, Little endian,
> wxGTK
> > Build Info:
> > wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
> > GTK+ 2.24
> > Boost: 1.58.0
> > OpenCASCADE Community Edition: 6.8.0
> > Curl: 7.47.0
> > Compiler: GCC 5.4.0 with C++ ABI 1009
> > Build settings:
> > KICAD_SCRIPTING=ON
> > KICAD_SCRIPTING_MODULES=ON
> > KICAD_SCRIPTING_PYTHON3=OFF
> > KICAD_SCRIPTING_WXPYTHON=ON
> > KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> > KICAD_SCRIPTING_ACTION_MENU=ON
> > BUILD_GITHUB_PLUGIN=ON
> > KICAD_USE_OCE=ON
> > KICAD_USE_OCC=OFF
> > KICAD_SPICE=ON
> >
> >
> > On Wed, 3 Apr 2019 at 19:01, Jon Evans  > > wrote:
> >
> > I can move to stdlib regex; I'll look in to that later this week.
> >
> > On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh  > > wrote:
> >
> > Tom,
> >
> > On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
> > > On 02/04/2019 17:27, Wayne Stambaugh wrote:
> > >> 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 lots of debugging code in all manner of
> > formats in
> > >> our source code.
> > >>
> > > @Wayne Can I somehow use wxLogTrace() on release builds?
> >
> > Unfortunately no.  All of the wxLog macros compile away in
> > release builds.
> >
> > >
> > > @Jon I just tried to build today's master and it complained
> about
> > > missing boost::regex library. There is regexp support in
> > libstdc++ in
> > > C++11, why go for boost?
> >
> > I got bit by this too on Debian.  I think boost packaging on
> > Debian is
> > in a state of flux the moment.  I see the boost-dev package is
> being
> > held back even when I do a dist-upgrade.  This is (was) the
> > package that
> > used to pull in all of boost and it's libraries.  Maybe there is
> > a new
> > meta package that does that.  I just installed boost-regex-dev
> > and all
> > was well.
> >
> > >
> > > Tom
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : 

Re: [Kicad-developers] Bus upgrades merge

[Diego Herranz]

Hi, all.

I'm using nightlies and facing a weird bug with buses. I was wondering
whether it can be related to these bus upgrades.

I've got a bus:
ROW0, ROW1, ROW2, ROW3, ROW4, ROW5, ROW6, ROW7, which on the PCB layout
becomes
ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW0, ROW7 ???
It seems to be semi-random and I've seen other combinations too.

I've managed to reduce the SCH to a minimal example (link below). Further
changes to this seem to fix it somehow, so I couldn't reduce it anymore.
Note that one of the symbols is not on the official library so I've
included a local library.
I've tried replacing that symbol for a standard header, but that seems to
fix the problem, although I can't see anything wrong with the symbol itself.

Can anyone confirm that it is a bug and not something I'm doing wrong?
Is it related to this upgrade?
Please let me know how to proceed. I can report the bug on launchpad.

Many thanks!

 bus_bug.zip



Application: KiCad
> Version: 6.0.0-unknown-6b031d9~100~ubuntu16.04.1, release build
> Libraries:
> wxWidgets 3.0.2
> libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
> Platform: Linux 4.4.0-157-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.58.0
> OpenCASCADE Community Edition: 6.8.0
> Curl: 7.47.0
> Compiler: GCC 5.4.0 with C++ ABI 1009
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=OFF
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> KICAD_SPICE=ON


On Wed, 3 Apr 2019 at 19:01, Jon Evans  wrote:

> I can move to stdlib regex; I'll look in to that later this week.
>
> On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh 
> wrote:
>
>> Tom,
>>
>> On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
>> > On 02/04/2019 17:27, Wayne Stambaugh wrote:
>> >> 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 lots of debugging code in all manner of formats
>> in
>> >> our source code.
>> >>
>> > @Wayne Can I somehow use wxLogTrace() on release builds?
>>
>> Unfortunately no.  All of the wxLog macros compile away in release builds.
>>
>> >
>> > @Jon I just tried to build today's master and it complained about
>> > missing boost::regex library. There is regexp support in libstdc++ in
>> > C++11, why go for boost?
>>
>> I got bit by this too on Debian.  I think boost packaging on Debian is
>> in a state of flux the moment.  I see the boost-dev package is being
>> held back even when I do a dist-upgrade.  This is (was) the package that
>> used to pull in all of boost and it's libraries.  Maybe there is a new
>> meta package that does that.  I just installed boost-regex-dev and all
>> was well.
>>
>> >
>> > Tom
>> >
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

I can move to stdlib regex; I'll look in to that later this week.

On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh  wrote:

> Tom,
>
> On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
> > On 02/04/2019 17:27, Wayne Stambaugh wrote:
> >> 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 lots of debugging code in all manner of formats in
> >> our source code.
> >>
> > @Wayne Can I somehow use wxLogTrace() on release builds?
>
> Unfortunately no.  All of the wxLog macros compile away in release builds.
>
> >
> > @Jon I just tried to build today's master and it complained about
> > missing boost::regex library. There is regexp support in libstdc++ in
> > C++11, why go for boost?
>
> I got bit by this too on Debian.  I think boost packaging on Debian is
> in a state of flux the moment.  I see the boost-dev package is being
> held back even when I do a dist-upgrade.  This is (was) the package that
> used to pull in all of boost and it's libraries.  Maybe there is a new
> meta package that does that.  I just installed boost-regex-dev and all
> was well.
>
> >
> > Tom
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Tom,

On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote:
> On 02/04/2019 17:27, Wayne Stambaugh wrote:
>> 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 lots of debugging code in all manner of formats in
>> our source code.
>>
> @Wayne Can I somehow use wxLogTrace() on release builds?

Unfortunately no.  All of the wxLog macros compile away in release builds.

> 
> @Jon I just tried to build today's master and it complained about
> missing boost::regex library. There is regexp support in libstdc++ in
> C++11, why go for boost?

I got bit by this too on Debian.  I think boost packaging on Debian is
in a state of flux the moment.  I see the boost-dev package is being
held back even when I do a dist-upgrade.  This is (was) the package that
used to pull in all of boost and it's libraries.  Maybe there is a new
meta package that does that.  I just installed boost-regex-dev and all
was well.

> 
> Tom
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Tomasz Wlostowski]

On 02/04/2019 17:27, Wayne Stambaugh wrote:
> 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 lots of debugging code in all manner of formats in
> our source code.
> 
@Wayne Can I somehow use wxLogTrace() on release builds?

@Jon I just tried to build today's master and it complained about
missing boost::regex library. There is regexp support in libstdc++ in
C++11, why go for boost?

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

Tom and I were both doing penance for having added one of those arrays, so it 
was time to get us out of Purgatory. ;)

> On 3 Apr 2019, at 13:37, Jon Evans  wrote:
> 
> Thanks Jeff!  Changes look good to me.
> 
> On Wed, Apr 3, 2019 at 6:28 AM Jeff Young  > wrote:
> Changes are in.  Jon (in particular) will want to pick them up soon.
> 
> An array of SCH_PIN (mapped by LIB_PIN*) was created which replaces:
> - the array of highlight flags
> - the array of pin positions
> - the array of brightened flags
> - the sparse array of dangling indices
> - the array (mapped by LIB_PIN*) of SCH_CONNECTION links
> 
> Cheers,
> Jeff.
> 
> 
> > On 2 Apr 2019, at 23:25, Wayne Stambaugh  > > wrote:
> > 
> > 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.
> >> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Thanks Jeff!  Changes look good to me.

On Wed, Apr 3, 2019 at 6:28 AM Jeff Young  wrote:

> Changes are in.  Jon (in particular) will want to pick them up soon.
>
> An array of SCH_PIN (mapped by LIB_PIN*) was created which replaces:
> - the array of highlight flags
> - the array of pin positions
> - the array of brightened flags
> - the sparse array of dangling indices
> - the array (mapped by LIB_PIN*) of SCH_CONNECTION links
>
> Cheers,
> Jeff.
>
>
> > On 2 Apr 2019, at 23:25, Wayne Stambaugh  wrote:
> >
> > 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.
> >>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

Changes are in.  Jon (in particular) will want to pick them up soon.

An array of SCH_PIN (mapped by LIB_PIN*) was created which replaces:
- the array of highlight flags
- the array of pin positions
- the array of brightened flags
- the sparse array of dangling indices
- the array (mapped by LIB_PIN*) of SCH_CONNECTION links

Cheers,
Jeff.


> On 2 Apr 2019, at 23:25, Wayne Stambaugh  wrote:
> 
> 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.
>> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

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.
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

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/2/2019 11:20 AM, Jeff Young wrote:
> Hi Wayne,
> 
> I’m not folding the connectivity data in; that’s stored in
> SCH_CONNECTION.  But we used to have a SCH_PIN_CONNECTION which allowed
> a SCH_COMPONENT’s pins to point to their SCH_CONNECTION.  (Until my
> change there was no SCH_PIN; we just used LIB_PIN and every time a
> component needed to specify something on a per-component basis, we’d add
> an array of those values indexed by pin.  Obviously after a while it
> turned into a mess.)
> 
> Cheers,
> Jeff.
> 
> 
>> On 2 Apr 2019, at 14:14, Wayne Stambaugh > > wrote:
>>
>> 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 netlist so would like to see how merging this into SCH_PIN is going
>> to work before we push this to the main repo.  I was always working
>> under the premise that these connectivity structures belonged to a
>> higher level abstraction of a SCHEMATIC object but your solution may be
>> better.  A coherent SCHEMATIC object is on my todo list as part of the
>> new schematic file format work.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/2/2019 8:43 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, highlight flags, brightened flags and now
>>> connections.  I’m promoting your SCH_PIN_CONNECTION to just SCH_PIN and
>>> rolling the other shadow data structures into it.  Hope to have
>>> something I can push later tonight.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
 On 2 Apr 2019, at 01:24, Jon Evans >>> 
 > wrote:

 I think I just fixed it, want to give it a try?

 On Mon, Apr 1, 2019 at 7:01 PM Jon Evans >>> 
 > wrote:

    OK. I have a hunch that I can fix it in a simpler way, so that you
    will never need to force the sheet.  I will check it out and let
    you know.

    On Mon, Apr 1, 2019 at 6:34 PM Jeff Young >>> 
    > wrote:

    For now I added a second boolean:

    wxString SCH_CONNECTION::Name( bool aIgnoreSheet, bool
 aForceSheet ) const



>    On 1 Apr 2019, at 23:19, Jon Evans  
>    > wrote:
>
>    I just realized that because of sch_connection.cpp:257 you
>    will never get the path prepended.
>    This is kind of a "bug" / undesirable given the feature you
>    want to implement.
>    I will think about how best to fix this when I'm back to my
>    dev machine later tonight...
>    You can manually prepend the path for now if you want to test
>    your change.
>
>    -Jon
>
>    On Mon, Apr 1, 2019 at 6:11 PM Jeff Young  
>    > wrote:
>
>    Cool, that nearly works.
>
>    The remaining snag is that Name() doesn’t prepend the
>    path to SCH_PIN_CONNECTION_Ts, but m_SelectedNetName does
>    have the path in it.  Is one of those in error, or do I
>    need to add the path on myself?
>
>
>>    On 1 Apr 2019, at 22:56, Jon Evans > 
>>    > wrote:
>>
>>    SCH_PIN_CONNECTION is a SCH_ITEM and so you can call
>>    Connection(path) on it
>>
>>    See: SCH_CONNECTION* SCH_ITEM::Connection( const
>>    SCH_SHEET_PATH& aPath )
>>
>>    On Mon, Apr 1, 2019 at 5:52 PM Jeff Young
>>    >  > wrote:
>>
>>    Hmm… I don’t see any link between a
>>    SCH_PIN_CONNECTION and a SCH_CONNECTION.
>>
>>>    On 1 Apr 2019, at 22:20, Jon Evans
>>>    >>  > wrote:
>>>
>>>    The pin should have a SCH_PIN_CONNECTION (via
>>>    SCH_COMPONENT:: m_pin_connections) which has a
>>>    SCH_CONNECTION which 

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

> ...  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.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

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 lots of debugging code in all manner of formats in
our source code.

Cheers,

Wayne

On 4/2/2019 11:22 AM, John Beard wrote:
> 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 useless work, e.g. string
> formatting [1]
> * advanced configs, to enable more in-depth diagnostics (allows you to
> set a value, for example) [2]
> 
> Both of these methods have the advantage of #ifdefs that the code is
> always compiled in Debug mode, so you don't end up with rotten blocks
> of debug that's never compiled. Forcing a rebuild to enable debug is a
> very good way to ensure no-one uses it!
> 
> Caching the enablement of whatever trace/debug you need in a const
> bool should mean that you'd see any performance hit at all only in the
> very tightest of loops, if ever, when the debug is off.
> 
> Naturally, it can't save you from code being generally slower in Debug mode!
> 
> Cheers,
> 
> John
> 
> [1]: 
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_testing.html#trace-debug
> [2]: 
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_testing.html#advanced-configuration
> 
> On Tue, Apr 2, 2019 at 2:50 PM Wayne Stambaugh  wrote:
>>
>> 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 assuming you are performing a full netlist rebuild
>> after adding connectable objects so it may be better to rebuild the
>> netlist during idle periods or run the netlist builder in a separate thread.
>>
>> Wayne
>>
>> On 4/1/2019 8:34 AM, Jon Evans wrote:
>>> Speaking of that, if anyone wants to be adventurous, you can test
>>> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>>> In my testing, it is so fast as to be seamless on most machines with
>>> most designs.
>>> There are a few edge cases where the regeneration can take longer,
>>> especially on debug builds.
>>>
>>> I'm interested in collecting profile data (using perf or some other
>>> similar tool) from machines where this feature is annoyingly slow.
>>> My goal would be to enable it when the performance penalty is no more
>>> than ~100-150ms worst case in debug mode for real-time operations.
>>>
>>> Thanks,
>>> Jon
>>>
>>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh >> > wrote:
>>>
>>> No problem.  I wanted to get this merged so we can get some additional
>>> testing.  Hopefully you will be able to resolve the performance issues
>>> so we can have real time netlist generation and some of the nifty
>>> features that this will allow.
>>>
>>> On 3/31/2019 11:19 PM, Jon Evans wrote:
>>> > Thanks Wayne! Everything looks good to me.
>>> >
>>> > Glad to finally have this merged so that I can start building other
>>> > improvements on top of it.
>>> >
>>> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh
>>> mailto:stambau...@gmail.com>
>>> > >> wrote:
>>> >
>>> > Jon,
>>> >
>>> > I forgot to mention.  Please take a look and make sure I
>>> didn't muck
>>> > anything up when you get a chance.
>>> >
>>> > Wayne
>>> >
>>> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
>>> > > Jon,
>>> > >
>>> > > I merged your patch set into the master branch.  Thank you
>>> for all of
>>> > > your efforts.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Wayne
>>> > >
>>> > > On 3/31/19 7:50 PM, Jon Evans wrote:
>>> > >> Yes I just squashed the parts that dont compile on their own.
>>> > >>
>>> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh
>>> mailto:stambau...@gmail.com>
>>> > >
>>> > >> 
>>> >> > >>
>>> > >> Jon,
>>> > >>
>>> > >> I thought we decided to squash your patch set or did
>>> you just
>>> > squash
>>> > >> part of the patch set?  I see 17 separate patches the
>>> 

Re: [Kicad-developers] Bus upgrades merge

[John Beard]

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 useless work, e.g. string
formatting [1]
* advanced configs, to enable more in-depth diagnostics (allows you to
set a value, for example) [2]

Both of these methods have the advantage of #ifdefs that the code is
always compiled in Debug mode, so you don't end up with rotten blocks
of debug that's never compiled. Forcing a rebuild to enable debug is a
very good way to ensure no-one uses it!

Caching the enablement of whatever trace/debug you need in a const
bool should mean that you'd see any performance hit at all only in the
very tightest of loops, if ever, when the debug is off.

Naturally, it can't save you from code being generally slower in Debug mode!

Cheers,

John

[1]: 
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_testing.html#trace-debug
[2]: 
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_testing.html#advanced-configuration

On Tue, Apr 2, 2019 at 2:50 PM Wayne Stambaugh  wrote:
>
> 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 assuming you are performing a full netlist rebuild
> after adding connectable objects so it may be better to rebuild the
> netlist during idle periods or run the netlist builder in a separate thread.
>
> Wayne
>
> On 4/1/2019 8:34 AM, Jon Evans wrote:
> > Speaking of that, if anyone wants to be adventurous, you can test
> > real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
> > In my testing, it is so fast as to be seamless on most machines with
> > most designs.
> > There are a few edge cases where the regeneration can take longer,
> > especially on debug builds.
> >
> > I'm interested in collecting profile data (using perf or some other
> > similar tool) from machines where this feature is annoyingly slow.
> > My goal would be to enable it when the performance penalty is no more
> > than ~100-150ms worst case in debug mode for real-time operations.
> >
> > Thanks,
> > Jon
> >
> > On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh  > > wrote:
> >
> > No problem.  I wanted to get this merged so we can get some additional
> > testing.  Hopefully you will be able to resolve the performance issues
> > so we can have real time netlist generation and some of the nifty
> > features that this will allow.
> >
> > On 3/31/2019 11:19 PM, Jon Evans wrote:
> > > Thanks Wayne! Everything looks good to me.
> > >
> > > Glad to finally have this merged so that I can start building other
> > > improvements on top of it.
> > >
> > > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >> wrote:
> > >
> > > Jon,
> > >
> > > I forgot to mention.  Please take a look and make sure I
> > didn't muck
> > > anything up when you get a chance.
> > >
> > > Wayne
> > >
> > > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > > > Jon,
> > > >
> > > > I merged your patch set into the master branch.  Thank you
> > for all of
> > > > your efforts.
> > > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > > On 3/31/19 7:50 PM, Jon Evans wrote:
> > > >> Yes I just squashed the parts that dont compile on their own.
> > > >>
> > > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >
> > > >> 
> >  > > >>
> > > >> Jon,
> > > >>
> > > >> I thought we decided to squash your patch set or did
> > you just
> > > squash
> > > >> part of the patch set?  I see 17 separate patches the
> > archive
> > > you
> > > >> sent.
> > > >>
> > > >> Wayne
> > > >>
> > > >> On 3/31/19 7:39 PM, Jon Evans wrote:
> > > >>  > Attached!
> > > >>  >
> > > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> > > >> mailto:stambau...@gmail.com>
> > >
> > > 
> > 

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

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 happen in
~250ms in debug build (he reported much slower)
So, I'm also going to find some more testing machines with different
platforms to check what the worst case can be.

-Jon

On Tue, Apr 2, 2019 at 9:51 AM Wayne Stambaugh  wrote:

> 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 assuming you are performing a full netlist rebuild
> after adding connectable objects so it may be better to rebuild the
> netlist during idle periods or run the netlist builder in a separate
> thread.
>
> Wayne
>
> On 4/1/2019 8:34 AM, Jon Evans wrote:
> > Speaking of that, if anyone wants to be adventurous, you can test
> > real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
> > In my testing, it is so fast as to be seamless on most machines with
> > most designs.
> > There are a few edge cases where the regeneration can take longer,
> > especially on debug builds.
> >
> > I'm interested in collecting profile data (using perf or some other
> > similar tool) from machines where this feature is annoyingly slow.
> > My goal would be to enable it when the performance penalty is no more
> > than ~100-150ms worst case in debug mode for real-time operations.
> >
> > Thanks,
> > Jon
> >
> > On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh  > > wrote:
> >
> > No problem.  I wanted to get this merged so we can get some
> additional
> > testing.  Hopefully you will be able to resolve the performance
> issues
> > so we can have real time netlist generation and some of the nifty
> > features that this will allow.
> >
> > On 3/31/2019 11:19 PM, Jon Evans wrote:
> > > Thanks Wayne! Everything looks good to me.
> > >
> > > Glad to finally have this merged so that I can start building other
> > > improvements on top of it.
> > >
> > > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>
> wrote:
> > >
> > > Jon,
> > >
> > > I forgot to mention.  Please take a look and make sure I
> > didn't muck
> > > anything up when you get a chance.
> > >
> > > Wayne
> > >
> > > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > > > Jon,
> > > >
> > > > I merged your patch set into the master branch.  Thank you
> > for all of
> > > > your efforts.
> > > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > > On 3/31/19 7:50 PM, Jon Evans wrote:
> > > >> Yes I just squashed the parts that dont compile on their
> own.
> > > >>
> > > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >
> > > >> 
> >  > > >>
> > > >> Jon,
> > > >>
> > > >> I thought we decided to squash your patch set or did
> > you just
> > > squash
> > > >> part of the patch set?  I see 17 separate patches the
> > archive
> > > you
> > > >> sent.
> > > >>
> > > >> Wayne
> > > >>
> > > >> On 3/31/19 7:39 PM, Jon Evans wrote:
> > > >>  > Attached!
> > > >>  >
> > > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> > > >> mailto:stambau...@gmail.com>
> > >
> > > 
> > >>
> > > >>  >  >   > >
> > > 
> > 
> > > >> wrote:
> > > >>  >
> > > >>  > Jon,
> > > >>  >
> > > >>  > Would you please post the squashed patch to the
> > > mailing list
> > > >> so I can
> > > >>  > get it merged?
> > > >>  >
> > > >>  > 

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

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 assuming you are performing a full netlist rebuild
after adding connectable objects so it may be better to rebuild the
netlist during idle periods or run the netlist builder in a separate thread.

Wayne

On 4/1/2019 8:34 AM, Jon Evans wrote:
> Speaking of that, if anyone wants to be adventurous, you can test
> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
> In my testing, it is so fast as to be seamless on most machines with
> most designs.
> There are a few edge cases where the regeneration can take longer,
> especially on debug builds.
> 
> I'm interested in collecting profile data (using perf or some other
> similar tool) from machines where this feature is annoyingly slow.
> My goal would be to enable it when the performance penalty is no more
> than ~100-150ms worst case in debug mode for real-time operations.
> 
> Thanks,
> Jon
> 
> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh  > wrote:
> 
> No problem.  I wanted to get this merged so we can get some additional
> testing.  Hopefully you will be able to resolve the performance issues
> so we can have real time netlist generation and some of the nifty
> features that this will allow.
> 
> On 3/31/2019 11:19 PM, Jon Evans wrote:
> > Thanks Wayne! Everything looks good to me.
> >
> > Glad to finally have this merged so that I can start building other
> > improvements on top of it.
> >
> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >     Jon,
> >
> >     I forgot to mention.  Please take a look and make sure I
> didn't muck
> >     anything up when you get a chance.
> >
> >     Wayne
> >
> >     On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> >     > Jon,
> >     >
> >     > I merged your patch set into the master branch.  Thank you
> for all of
> >     > your efforts.
> >     >
> >     > Cheers,
> >     >
> >     > Wayne
> >     >
> >     > On 3/31/19 7:50 PM, Jon Evans wrote:
> >     >> Yes I just squashed the parts that dont compile on their own.
> >     >>
> >     >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh
> mailto:stambau...@gmail.com>
> >     >
> >     >> 
>  >     >>
> >     >>     Jon,
> >     >>
> >     >>     I thought we decided to squash your patch set or did
> you just
> >     squash
> >     >>     part of the patch set?  I see 17 separate patches the
> archive
> >     you
> >     >> sent.
> >     >>
> >     >>     Wayne
> >     >>
> >     >>     On 3/31/19 7:39 PM, Jon Evans wrote:
> >     >>  > Attached!
> >     >>  >
> >     >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> >     >>     mailto:stambau...@gmail.com>
> >
> >     
> >>
> >     >>  >    >
> >     
> 
> >     >> wrote:
> >     >>  >
> >     >>  >     Jon,
> >     >>  >
> >     >>  >     Would you please post the squashed patch to the
> >     mailing list
> >     >>     so I can
> >     >>  >     get it merged?
> >     >>  >
> >     >>  >     Thanks,
> >     >>  >
> >     >>  >     Wayne
> >     >>  >
> >     >>  >     On 3/31/19 3:07 PM, Jon Evans wrote:
> >     >>  >      > I went through and squashed the offending
> commits and
> >     >>     updated the
> >     >>  >     PRs.
> >     >>  >      >
> >     >>  >      > -Jon
> >     >>  >      >
> >     >>  >      > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> >     >>  >        >
> >     
> >>
> >     >>     

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

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 netlist so would like to see how merging this into SCH_PIN is going
to work before we push this to the main repo.  I was always working
under the premise that these connectivity structures belonged to a
higher level abstraction of a SCHEMATIC object but your solution may be
better.  A coherent SCHEMATIC object is on my todo list as part of the
new schematic file format work.

Cheers,

Wayne

On 4/2/2019 8:43 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, highlight flags, brightened flags and now
> connections.  I’m promoting your SCH_PIN_CONNECTION to just SCH_PIN and
> rolling the other shadow data structures into it.  Hope to have
> something I can push later tonight.
> 
> Cheers,
> Jeff.
> 
> 
>> On 2 Apr 2019, at 01:24, Jon Evans > > wrote:
>>
>> I think I just fixed it, want to give it a try?
>>
>> On Mon, Apr 1, 2019 at 7:01 PM Jon Evans > > wrote:
>>
>> OK. I have a hunch that I can fix it in a simpler way, so that you
>> will never need to force the sheet.  I will check it out and let
>> you know.
>>
>> On Mon, Apr 1, 2019 at 6:34 PM Jeff Young > > wrote:
>>
>> For now I added a second boolean:
>>
>> wxString SCH_CONNECTION::Name( bool aIgnoreSheet, bool aForceSheet ) 
>> const
>>
>>
>>
>>> On 1 Apr 2019, at 23:19, Jon Evans >> > wrote:
>>>
>>> I just realized that because of sch_connection.cpp:257 you
>>> will never get the path prepended.
>>> This is kind of a "bug" / undesirable given the feature you
>>> want to implement.
>>> I will think about how best to fix this when I'm back to my
>>> dev machine later tonight...
>>> You can manually prepend the path for now if you want to test
>>> your change.
>>>
>>> -Jon
>>>
>>> On Mon, Apr 1, 2019 at 6:11 PM Jeff Young >> > wrote:
>>>
>>> Cool, that nearly works.
>>>
>>> The remaining snag is that Name() doesn’t prepend the
>>> path to SCH_PIN_CONNECTION_Ts, but m_SelectedNetName does
>>> have the path in it.  Is one of those in error, or do I
>>> need to add the path on myself?
>>>
>>>
 On 1 Apr 2019, at 22:56, Jon Evans >>> > wrote:

 SCH_PIN_CONNECTION is a SCH_ITEM and so you can call
 Connection(path) on it

 See: SCH_CONNECTION* SCH_ITEM::Connection( const
 SCH_SHEET_PATH& aPath )

 On Mon, Apr 1, 2019 at 5:52 PM Jeff Young
 mailto:j...@rokeby.ie>> wrote:

 Hmm… I don’t see any link between a
 SCH_PIN_CONNECTION and a SCH_CONNECTION.

> On 1 Apr 2019, at 22:20, Jon Evans
> mailto:j...@craftyjon.com>> wrote:
>
> The pin should have a SCH_PIN_CONNECTION (via
> SCH_COMPONENT:: m_pin_connections) which has a
> SCH_CONNECTION which is where the connectivity info
> is stored.
> You want SCH_CONNECTION::Name() to get you the
> final netname.
>
> On Mon, Apr 1, 2019 at 5:15 PM Jeff Young
> mailto:j...@rokeby.ie>> wrote:
>
> Name() appears to only be on SHEET_PINs
> though.  Or did I misread that?
>
>> On 1 Apr 2019, at 22:08, Jon Evans
>> mailto:j...@craftyjon.com>>
>> wrote:
>>
>> Hi Jeff,
>>
>> You can call Name() on the connection object
>> for the current sheet -- see
>> SCH_EDIT_FRAME::HighlightConnectionAtPosition() for
>> some reference code.
>> GetDefaultNetName does not include the sheet
>> path as it only returns candidate net names
>> for pins, not the final net names used for
>> netlisting.
>>
>> -Jon
>>
>> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young
>> mailto:j...@rokeby.ie>> wrote:
>>
>>

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

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, highlight flags, brightened flags and now
> connections.  I’m promoting your SCH_PIN_CONNECTION to just SCH_PIN and
> rolling the other shadow data structures into it.  Hope to have something I
> can push later tonight.
>
> Cheers,
> Jeff.
>
>
> On 2 Apr 2019, at 01:24, Jon Evans  wrote:
>
> I think I just fixed it, want to give it a try?
>
> On Mon, Apr 1, 2019 at 7:01 PM Jon Evans  wrote:
>
>> OK. I have a hunch that I can fix it in a simpler way, so that you will
>> never need to force the sheet.  I will check it out and let you know.
>>
>> On Mon, Apr 1, 2019 at 6:34 PM Jeff Young  wrote:
>>
>>> For now I added a second boolean:
>>>
>>> wxString SCH_CONNECTION::Name( bool aIgnoreSheet, bool aForceSheet ) const
>>>
>>>
>>>
>>> On 1 Apr 2019, at 23:19, Jon Evans  wrote:
>>>
>>> I just realized that because of sch_connection.cpp:257 you will never
>>> get the path prepended.
>>> This is kind of a "bug" / undesirable given the feature you want to
>>> implement.
>>> I will think about how best to fix this when I'm back to my dev machine
>>> later tonight...
>>> You can manually prepend the path for now if you want to test your
>>> change.
>>>
>>> -Jon
>>>
>>> On Mon, Apr 1, 2019 at 6:11 PM Jeff Young  wrote:
>>>
 Cool, that nearly works.

 The remaining snag is that Name() doesn’t prepend the path to
 SCH_PIN_CONNECTION_Ts, but m_SelectedNetName does have the path in
 it.  Is one of those in error, or do I need to add the path on myself?


 On 1 Apr 2019, at 22:56, Jon Evans  wrote:

 SCH_PIN_CONNECTION is a SCH_ITEM and so you can call Connection(path)
 on it

 See: SCH_CONNECTION* SCH_ITEM::Connection( const SCH_SHEET_PATH& aPath )

 On Mon, Apr 1, 2019 at 5:52 PM Jeff Young  wrote:

> Hmm… I don’t see any link between a SCH_PIN_CONNECTION and a
> SCH_CONNECTION.
>
> On 1 Apr 2019, at 22:20, Jon Evans  wrote:
>
> The pin should have a SCH_PIN_CONNECTION (via
> SCH_COMPONENT:: m_pin_connections) which has a SCH_CONNECTION which is
> where the connectivity info is stored.
> You want SCH_CONNECTION::Name() to get you the final netname.
>
> On Mon, Apr 1, 2019 at 5:15 PM Jeff Young  wrote:
>
>> Name() appears to only be on SHEET_PINs though.  Or did I misread
>> that?
>>
>> On 1 Apr 2019, at 22:08, Jon Evans  wrote:
>>
>> Hi Jeff,
>>
>> You can call Name() on the connection object for the current sheet --
>> see SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference 
>> code.
>> GetDefaultNetName does not include the sheet path as it only returns
>> candidate net names for pins, not the final net names used for 
>> netlisting.
>>
>> -Jon
>>
>> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young  wrote:
>>
>>> Hi Jon,
>>>
>>> I’m trying to integrate the pin highlighting stuff with your merge.
>>> I’ve added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags()
>>> which attempts to use the pin’s connection to see if it should be
>>> highlighted.
>>>
>>> However, I’m having two issues.
>>>
>>> 1) Is there a way to get the current netname?  I found
>>> GetDefaultNetName(), but that will only get the name that will be pushed
>>> from that pin, not the actual netname.
>>> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe
>>> that’s just because I’m calling the wrong routine.
>>>
>>> Thanks,
>>> Jeff.
>>>
>>>
>>> On 1 Apr 2019, at 13:34, Jon Evans  wrote:
>>>
>>> Speaking of that, if anyone wants to be adventurous, you can test
>>> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>>> In my testing, it is so fast as to be seamless on most machines with
>>> most designs.
>>> There are a few edge cases where the regeneration can take longer,
>>> especially on debug builds.
>>>
>>> I'm interested in collecting profile data (using perf or some other
>>> similar tool) from machines where this feature is annoyingly slow.
>>> My goal would be to enable it when the performance penalty is no
>>> more than ~100-150ms worst case in debug mode for real-time operations.
>>>
>>> Thanks,
>>> Jon
>>>
>>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh 
>>> wrote:
>>>
 No problem.  I wanted to get this merged so we can get some
 additional
 testing.  Hopefully you will be able to resolve the performance
 issues
 so we can have real time netlist generation and some of the nifty
 features that this will allow.

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

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 to just SCH_PIN and rolling the other shadow 
data structures into it.  Hope to have something I can push later tonight.

Cheers,
Jeff.


> On 2 Apr 2019, at 01:24, Jon Evans  wrote:
> 
> I think I just fixed it, want to give it a try?
> 
> On Mon, Apr 1, 2019 at 7:01 PM Jon Evans  > wrote:
> OK. I have a hunch that I can fix it in a simpler way, so that you will never 
> need to force the sheet.  I will check it out and let you know.
> 
> On Mon, Apr 1, 2019 at 6:34 PM Jeff Young  > wrote:
> For now I added a second boolean:
> 
> wxString SCH_CONNECTION::Name( bool aIgnoreSheet, bool aForceSheet ) const
> 
> 
>> On 1 Apr 2019, at 23:19, Jon Evans > > wrote:
>> 
>> I just realized that because of sch_connection.cpp:257 you will never get 
>> the path prepended.
>> This is kind of a "bug" / undesirable given the feature you want to 
>> implement.
>> I will think about how best to fix this when I'm back to my dev machine 
>> later tonight...
>> You can manually prepend the path for now if you want to test your change.
>> 
>> -Jon
>> 
>> On Mon, Apr 1, 2019 at 6:11 PM Jeff Young > > wrote:
>> Cool, that nearly works.
>> 
>> The remaining snag is that Name() doesn’t prepend the path to 
>> SCH_PIN_CONNECTION_Ts, but m_SelectedNetName does have the path in it.  Is 
>> one of those in error, or do I need to add the path on myself?
>> 
>> 
>>> On 1 Apr 2019, at 22:56, Jon Evans >> > wrote:
>>> 
>>> SCH_PIN_CONNECTION is a SCH_ITEM and so you can call Connection(path) on it
>>> 
>>> See: SCH_CONNECTION* SCH_ITEM::Connection( const SCH_SHEET_PATH& aPath )
>>> 
>>> On Mon, Apr 1, 2019 at 5:52 PM Jeff Young >> > wrote:
>>> Hmm… I don’t see any link between a SCH_PIN_CONNECTION and a SCH_CONNECTION.
>>> 
 On 1 Apr 2019, at 22:20, Jon Evans >>> > wrote:
 
 The pin should have a SCH_PIN_CONNECTION (via SCH_COMPONENT:: 
 m_pin_connections) which has a SCH_CONNECTION which is where the 
 connectivity info is stored.
 You want SCH_CONNECTION::Name() to get you the final netname.
 
 On Mon, Apr 1, 2019 at 5:15 PM Jeff Young >>> > wrote:
 Name() appears to only be on SHEET_PINs though.  Or did I misread that?
 
> On 1 Apr 2019, at 22:08, Jon Evans  > wrote:
> 
> Hi Jeff,
> 
> You can call Name() on the connection object for the current sheet -- see 
> SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference code.
> GetDefaultNetName does not include the sheet path as it only returns 
> candidate net names for pins, not the final net names used for netlisting.
> 
> -Jon
> 
> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young  > wrote:
> Hi Jon,
> 
> I’m trying to integrate the pin highlighting stuff with your merge.  I’ve 
> added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which 
> attempts to use the pin’s connection to see if it should be highlighted.
> 
> However, I’m having two issues.
> 
> 1) Is there a way to get the current netname?  I found 
> GetDefaultNetName(), but that will only get the name that will be pushed 
> from that pin, not the actual netname.
> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s 
> just because I’m calling the wrong routine.
> 
> Thanks,
> Jeff.
> 
> 
>> On 1 Apr 2019, at 13:34, Jon Evans > > wrote:
>> 
>> Speaking of that, if anyone wants to be adventurous, you can test 
>> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>> In my testing, it is so fast as to be seamless on most machines with 
>> most designs.
>> There are a few edge cases where the regeneration can take longer, 
>> especially on debug builds.
>> 
>> I'm interested in collecting profile data (using perf or some other 
>> similar tool) from machines where this feature is annoyingly slow.
>> My goal would be to enable it when the performance penalty is no more 
>> than ~100-150ms worst case in debug mode for real-time operations.
>> 
>> Thanks,
>> Jon
>> 
>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh > > wrote:
>> No problem.  I wanted to get this merged so we can get some additional
>> testing.  Hopefully you will be able to resolve the performance issues
>> so we can have real time netlist generation and 

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

Hmm… I don’t see any link between a SCH_PIN_CONNECTION and a SCH_CONNECTION.

> On 1 Apr 2019, at 22:20, Jon Evans  wrote:
> 
> The pin should have a SCH_PIN_CONNECTION (via SCH_COMPONENT:: 
> m_pin_connections) which has a SCH_CONNECTION which is where the connectivity 
> info is stored.
> You want SCH_CONNECTION::Name() to get you the final netname.
> 
> On Mon, Apr 1, 2019 at 5:15 PM Jeff Young  > wrote:
> Name() appears to only be on SHEET_PINs though.  Or did I misread that?
> 
>> On 1 Apr 2019, at 22:08, Jon Evans > > wrote:
>> 
>> Hi Jeff,
>> 
>> You can call Name() on the connection object for the current sheet -- see 
>> SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference code.
>> GetDefaultNetName does not include the sheet path as it only returns 
>> candidate net names for pins, not the final net names used for netlisting.
>> 
>> -Jon
>> 
>> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young > > wrote:
>> Hi Jon,
>> 
>> I’m trying to integrate the pin highlighting stuff with your merge.  I’ve 
>> added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which 
>> attempts to use the pin’s connection to see if it should be highlighted.
>> 
>> However, I’m having two issues.
>> 
>> 1) Is there a way to get the current netname?  I found GetDefaultNetName(), 
>> but that will only get the name that will be pushed from that pin, not the 
>> actual netname.
>> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s 
>> just because I’m calling the wrong routine.
>> 
>> Thanks,
>> Jeff.
>> 
>> 
>>> On 1 Apr 2019, at 13:34, Jon Evans >> > wrote:
>>> 
>>> Speaking of that, if anyone wants to be adventurous, you can test real-time 
>>> by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>>> In my testing, it is so fast as to be seamless on most machines with most 
>>> designs.
>>> There are a few edge cases where the regeneration can take longer, 
>>> especially on debug builds.
>>> 
>>> I'm interested in collecting profile data (using perf or some other similar 
>>> tool) from machines where this feature is annoyingly slow.
>>> My goal would be to enable it when the performance penalty is no more than 
>>> ~100-150ms worst case in debug mode for real-time operations.
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh >> > wrote:
>>> No problem.  I wanted to get this merged so we can get some additional
>>> testing.  Hopefully you will be able to resolve the performance issues
>>> so we can have real time netlist generation and some of the nifty
>>> features that this will allow.
>>> 
>>> On 3/31/2019 11:19 PM, Jon Evans wrote:
>>> > Thanks Wayne! Everything looks good to me.
>>> > 
>>> > Glad to finally have this merged so that I can start building other
>>> > improvements on top of it.
>>> > 
>>> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh >> > 
>>> > >> wrote:
>>> > 
>>> > Jon,
>>> > 
>>> > I forgot to mention.  Please take a look and make sure I didn't muck
>>> > anything up when you get a chance.
>>> > 
>>> > Wayne
>>> > 
>>> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
>>> > > Jon,
>>> > >
>>> > > I merged your patch set into the master branch.  Thank you for all 
>>> > of
>>> > > your efforts.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Wayne
>>> > >
>>> > > On 3/31/19 7:50 PM, Jon Evans wrote:
>>> > >> Yes I just squashed the parts that dont compile on their own.
>>> > >>
>>> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh >> > 
>>> > >
>>> > >>  
>>> > >> > >>
>>> > >> Jon,
>>> > >>
>>> > >> I thought we decided to squash your patch set or did you just
>>> > squash
>>> > >> part of the patch set?  I see 17 separate patches the archive
>>> > you
>>> > >> sent.
>>> > >>
>>> > >> Wayne
>>> > >>
>>> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
>>> > >>  > Attached!
>>> > >>  >
>>> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
>>> > >> mailto:stambau...@gmail.com> 
>>> > >
>>> >  
>>> > >>
>>> > >>  >  
>>> > >
>>> >  
>>> > 

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Hi Jeff,

You can call Name() on the connection object for the current sheet -- see
SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference code.
GetDefaultNetName does not include the sheet path as it only returns
candidate net names for pins, not the final net names used for netlisting.

-Jon

On Mon, Apr 1, 2019 at 5:02 PM Jeff Young  wrote:

> Hi Jon,
>
> I’m trying to integrate the pin highlighting stuff with your merge.  I’ve
> added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which
> attempts to use the pin’s connection to see if it should be highlighted.
>
> However, I’m having two issues.
>
> 1) Is there a way to get the current netname?  I found
> GetDefaultNetName(), but that will only get the name that will be pushed
> from that pin, not the actual netname.
> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s
> just because I’m calling the wrong routine.
>
> Thanks,
> Jeff.
>
>
> On 1 Apr 2019, at 13:34, Jon Evans  wrote:
>
> Speaking of that, if anyone wants to be adventurous, you can test
> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
> In my testing, it is so fast as to be seamless on most machines with most
> designs.
> There are a few edge cases where the regeneration can take longer,
> especially on debug builds.
>
> I'm interested in collecting profile data (using perf or some other
> similar tool) from machines where this feature is annoyingly slow.
> My goal would be to enable it when the performance penalty is no more than
> ~100-150ms worst case in debug mode for real-time operations.
>
> Thanks,
> Jon
>
> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh 
> wrote:
>
>> No problem.  I wanted to get this merged so we can get some additional
>> testing.  Hopefully you will be able to resolve the performance issues
>> so we can have real time netlist generation and some of the nifty
>> features that this will allow.
>>
>> On 3/31/2019 11:19 PM, Jon Evans wrote:
>> > Thanks Wayne! Everything looks good to me.
>> >
>> > Glad to finally have this merged so that I can start building other
>> > improvements on top of it.
>> >
>> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh > > > wrote:
>> >
>> > Jon,
>> >
>> > I forgot to mention.  Please take a look and make sure I didn't muck
>> > anything up when you get a chance.
>> >
>> > Wayne
>> >
>> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
>> > > Jon,
>> > >
>> > > I merged your patch set into the master branch.  Thank you for
>> all of
>> > > your efforts.
>> > >
>> > > Cheers,
>> > >
>> > > Wayne
>> > >
>> > > On 3/31/19 7:50 PM, Jon Evans wrote:
>> > >> Yes I just squashed the parts that dont compile on their own.
>> > >>
>> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh <
>> stambau...@gmail.com
>> > 
>> > >> >>
>> wrote:
>> > >>
>> > >> Jon,
>> > >>
>> > >> I thought we decided to squash your patch set or did you just
>> > squash
>> > >> part of the patch set?  I see 17 separate patches the archive
>> > you
>> > >> sent.
>> > >>
>> > >> Wayne
>> > >>
>> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
>> > >>  > Attached!
>> > >>  >
>> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
>> > >> mailto:stambau...@gmail.com>
>> > >
>> > >>  > > >
>> > > > >> wrote:
>> > >>  >
>> > >>  > Jon,
>> > >>  >
>> > >>  > Would you please post the squashed patch to the
>> > mailing list
>> > >> so I can
>> > >>  > get it merged?
>> > >>  >
>> > >>  > Thanks,
>> > >>  >
>> > >>  > Wayne
>> > >>  >
>> > >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
>> > >>  >  > I went through and squashed the offending commits
>> and
>> > >> updated the
>> > >>  > PRs.
>> > >>  >  >
>> > >>  >  > -Jon
>> > >>  >  >
>> > >>  >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
>> > >>  > mailto:stambau...@gmail.com>
>> > >
>> > >> 
>> > >>
>> > >>  >  > > >  > > >
>> > >> 
>> > 

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

The pin should have a SCH_PIN_CONNECTION (via
SCH_COMPONENT:: m_pin_connections) which has a SCH_CONNECTION which is
where the connectivity info is stored.
You want SCH_CONNECTION::Name() to get you the final netname.

On Mon, Apr 1, 2019 at 5:15 PM Jeff Young  wrote:

> Name() appears to only be on SHEET_PINs though.  Or did I misread that?
>
> On 1 Apr 2019, at 22:08, Jon Evans  wrote:
>
> Hi Jeff,
>
> You can call Name() on the connection object for the current sheet -- see
> SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference code.
> GetDefaultNetName does not include the sheet path as it only returns
> candidate net names for pins, not the final net names used for netlisting.
>
> -Jon
>
> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young  wrote:
>
>> Hi Jon,
>>
>> I’m trying to integrate the pin highlighting stuff with your merge.  I’ve
>> added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which
>> attempts to use the pin’s connection to see if it should be highlighted.
>>
>> However, I’m having two issues.
>>
>> 1) Is there a way to get the current netname?  I found
>> GetDefaultNetName(), but that will only get the name that will be pushed
>> from that pin, not the actual netname.
>> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s
>> just because I’m calling the wrong routine.
>>
>> Thanks,
>> Jeff.
>>
>>
>> On 1 Apr 2019, at 13:34, Jon Evans  wrote:
>>
>> Speaking of that, if anyone wants to be adventurous, you can test
>> real-time by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>> In my testing, it is so fast as to be seamless on most machines with most
>> designs.
>> There are a few edge cases where the regeneration can take longer,
>> especially on debug builds.
>>
>> I'm interested in collecting profile data (using perf or some other
>> similar tool) from machines where this feature is annoyingly slow.
>> My goal would be to enable it when the performance penalty is no more
>> than ~100-150ms worst case in debug mode for real-time operations.
>>
>> Thanks,
>> Jon
>>
>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh 
>> wrote:
>>
>>> No problem.  I wanted to get this merged so we can get some additional
>>> testing.  Hopefully you will be able to resolve the performance issues
>>> so we can have real time netlist generation and some of the nifty
>>> features that this will allow.
>>>
>>> On 3/31/2019 11:19 PM, Jon Evans wrote:
>>> > Thanks Wayne! Everything looks good to me.
>>> >
>>> > Glad to finally have this merged so that I can start building other
>>> > improvements on top of it.
>>> >
>>> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh >> > > wrote:
>>> >
>>> > Jon,
>>> >
>>> > I forgot to mention.  Please take a look and make sure I didn't
>>> muck
>>> > anything up when you get a chance.
>>> >
>>> > Wayne
>>> >
>>> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
>>> > > Jon,
>>> > >
>>> > > I merged your patch set into the master branch.  Thank you for
>>> all of
>>> > > your efforts.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Wayne
>>> > >
>>> > > On 3/31/19 7:50 PM, Jon Evans wrote:
>>> > >> Yes I just squashed the parts that dont compile on their own.
>>> > >>
>>> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh <
>>> stambau...@gmail.com
>>> > 
>>> > >> >>
>>> wrote:
>>> > >>
>>> > >> Jon,
>>> > >>
>>> > >> I thought we decided to squash your patch set or did you
>>> just
>>> > squash
>>> > >> part of the patch set?  I see 17 separate patches the
>>> archive
>>> > you
>>> > >> sent.
>>> > >>
>>> > >> Wayne
>>> > >>
>>> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
>>> > >>  > Attached!
>>> > >>  >
>>> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
>>> > >> mailto:stambau...@gmail.com>
>>> > >
>>> > >>  > > stambau...@gmail.com>
>>> > >> > >> wrote:
>>> > >>  >
>>> > >>  > Jon,
>>> > >>  >
>>> > >>  > Would you please post the squashed patch to the
>>> > mailing list
>>> > >> so I can
>>> > >>  > get it merged?
>>> > >>  >
>>> > >>  > Thanks,
>>> > >>  >
>>> > >>  > Wayne
>>> > >>  >
>>> > >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
>>> > >>  >  > I went through and squashed the offending commits
>>> and
>>> > >> updated the
>>> > >>  > PRs.
>>> > >>  >  >
>>> > >>  >  > -Jon
>>> > >>  >  >
>>> > >>  >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
>>> > 

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

Name() appears to only be on SHEET_PINs though.  Or did I misread that?

> On 1 Apr 2019, at 22:08, Jon Evans  wrote:
> 
> Hi Jeff,
> 
> You can call Name() on the connection object for the current sheet -- see 
> SCH_EDIT_FRAME::HighlightConnectionAtPosition() for some reference code.
> GetDefaultNetName does not include the sheet path as it only returns 
> candidate net names for pins, not the final net names used for netlisting.
> 
> -Jon
> 
> On Mon, Apr 1, 2019 at 5:02 PM Jeff Young  > wrote:
> Hi Jon,
> 
> I’m trying to integrate the pin highlighting stuff with your merge.  I’ve 
> added some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which 
> attempts to use the pin’s connection to see if it should be highlighted.
> 
> However, I’m having two issues.
> 
> 1) Is there a way to get the current netname?  I found GetDefaultNetName(), 
> but that will only get the name that will be pushed from that pin, not the 
> actual netname.
> 2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s 
> just because I’m calling the wrong routine.
> 
> Thanks,
> Jeff.
> 
> 
>> On 1 Apr 2019, at 13:34, Jon Evans > > wrote:
>> 
>> Speaking of that, if anyone wants to be adventurous, you can test real-time 
>> by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
>> In my testing, it is so fast as to be seamless on most machines with most 
>> designs.
>> There are a few edge cases where the regeneration can take longer, 
>> especially on debug builds.
>> 
>> I'm interested in collecting profile data (using perf or some other similar 
>> tool) from machines where this feature is annoyingly slow.
>> My goal would be to enable it when the performance penalty is no more than 
>> ~100-150ms worst case in debug mode for real-time operations.
>> 
>> Thanks,
>> Jon
>> 
>> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh > > wrote:
>> No problem.  I wanted to get this merged so we can get some additional
>> testing.  Hopefully you will be able to resolve the performance issues
>> so we can have real time netlist generation and some of the nifty
>> features that this will allow.
>> 
>> On 3/31/2019 11:19 PM, Jon Evans wrote:
>> > Thanks Wayne! Everything looks good to me.
>> > 
>> > Glad to finally have this merged so that I can start building other
>> > improvements on top of it.
>> > 
>> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh > > 
>> > >> wrote:
>> > 
>> > Jon,
>> > 
>> > I forgot to mention.  Please take a look and make sure I didn't muck
>> > anything up when you get a chance.
>> > 
>> > Wayne
>> > 
>> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
>> > > Jon,
>> > >
>> > > I merged your patch set into the master branch.  Thank you for all of
>> > > your efforts.
>> > >
>> > > Cheers,
>> > >
>> > > Wayne
>> > >
>> > > On 3/31/19 7:50 PM, Jon Evans wrote:
>> > >> Yes I just squashed the parts that dont compile on their own.
>> > >>
>> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh > > 
>> > >
>> > >>  
>> > > > >>
>> > >> Jon,
>> > >>
>> > >> I thought we decided to squash your patch set or did you just
>> > squash
>> > >> part of the patch set?  I see 17 separate patches the archive
>> > you
>> > >> sent.
>> > >>
>> > >> Wayne
>> > >>
>> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
>> > >>  > Attached!
>> > >>  >
>> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
>> > >> mailto:stambau...@gmail.com> 
>> > >
>> >  
>> > >>
>> > >>  >  
>> > >
>> >  
>> > 
>> > >> wrote:
>> > >>  >
>> > >>  > Jon,
>> > >>  >
>> > >>  > Would you please post the squashed patch to the
>> > mailing list
>> > >> so I can
>> > >>  > get it merged?
>> > >>  >
>> > >>  > Thanks,
>> > >>  >
>> > >>  > Wayne
>> > >>  >
>> > >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
>> > >>  >  > I went through and squashed the offending commits and
>> > >> updated the
>> > >>  > PRs.
>> > 

Re: [Kicad-developers] Bus upgrades merge

[Jeff Young]

Hi Jon,

I’m trying to integrate the pin highlighting stuff with your merge.  I’ve added 
some code to SCH_EDIT_FRAME::SetCurrentSheetHighlightFlags() which attempts to 
use the pin’s connection to see if it should be highlighted.

However, I’m having two issues.

1) Is there a way to get the current netname?  I found GetDefaultNetName(), but 
that will only get the name that will be pushed from that pin, not the actual 
netname.
2) When I do get a name it’s missing the beginning ‘/‘.  But maybe that’s just 
because I’m calling the wrong routine.

Thanks,
Jeff.


> On 1 Apr 2019, at 13:34, Jon Evans  wrote:
> 
> Speaking of that, if anyone wants to be adventurous, you can test real-time 
> by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
> In my testing, it is so fast as to be seamless on most machines with most 
> designs.
> There are a few edge cases where the regeneration can take longer, especially 
> on debug builds.
> 
> I'm interested in collecting profile data (using perf or some other similar 
> tool) from machines where this feature is annoyingly slow.
> My goal would be to enable it when the performance penalty is no more than 
> ~100-150ms worst case in debug mode for real-time operations.
> 
> Thanks,
> Jon
> 
> On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh  > wrote:
> No problem.  I wanted to get this merged so we can get some additional
> testing.  Hopefully you will be able to resolve the performance issues
> so we can have real time netlist generation and some of the nifty
> features that this will allow.
> 
> On 3/31/2019 11:19 PM, Jon Evans wrote:
> > Thanks Wayne! Everything looks good to me.
> > 
> > Glad to finally have this merged so that I can start building other
> > improvements on top of it.
> > 
> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh  > 
> > >> wrote:
> > 
> > Jon,
> > 
> > I forgot to mention.  Please take a look and make sure I didn't muck
> > anything up when you get a chance.
> > 
> > Wayne
> > 
> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > > Jon,
> > >
> > > I merged your patch set into the master branch.  Thank you for all of
> > > your efforts.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 3/31/19 7:50 PM, Jon Evans wrote:
> > >> Yes I just squashed the parts that dont compile on their own.
> > >>
> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh  > 
> > >
> > >>  
> >  > >>
> > >> Jon,
> > >>
> > >> I thought we decided to squash your patch set or did you just
> > squash
> > >> part of the patch set?  I see 17 separate patches the archive
> > you
> > >> sent.
> > >>
> > >> Wayne
> > >>
> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
> > >>  > Attached!
> > >>  >
> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> > >> mailto:stambau...@gmail.com> 
> > >
> >  
> > >>
> > >>  >  
> > >
> >  
> > 
> > >> wrote:
> > >>  >
> > >>  > Jon,
> > >>  >
> > >>  > Would you please post the squashed patch to the
> > mailing list
> > >> so I can
> > >>  > get it merged?
> > >>  >
> > >>  > Thanks,
> > >>  >
> > >>  > Wayne
> > >>  >
> > >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
> > >>  >  > I went through and squashed the offending commits and
> > >> updated the
> > >>  > PRs.
> > >>  >  >
> > >>  >  > -Jon
> > >>  >  >
> > >>  >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> > >>  > mailto:stambau...@gmail.com> 
> > >
> >  
> > >>
> > >>  
> > >
> >  
> >  > >>  >  > 

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Speaking of that, if anyone wants to be adventurous, you can test real-time
by defining CONNECTIVITY_REAL_TIME and CONNECTIVITY_PROFILE.
In my testing, it is so fast as to be seamless on most machines with most
designs.
There are a few edge cases where the regeneration can take longer,
especially on debug builds.

I'm interested in collecting profile data (using perf or some other similar
tool) from machines where this feature is annoyingly slow.
My goal would be to enable it when the performance penalty is no more than
~100-150ms worst case in debug mode for real-time operations.

Thanks,
Jon

On Mon, Apr 1, 2019 at 7:37 AM Wayne Stambaugh  wrote:

> No problem.  I wanted to get this merged so we can get some additional
> testing.  Hopefully you will be able to resolve the performance issues
> so we can have real time netlist generation and some of the nifty
> features that this will allow.
>
> On 3/31/2019 11:19 PM, Jon Evans wrote:
> > Thanks Wayne! Everything looks good to me.
> >
> > Glad to finally have this merged so that I can start building other
> > improvements on top of it.
> >
> > On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh  > > wrote:
> >
> > Jon,
> >
> > I forgot to mention.  Please take a look and make sure I didn't muck
> > anything up when you get a chance.
> >
> > Wayne
> >
> > On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > > Jon,
> > >
> > > I merged your patch set into the master branch.  Thank you for all
> of
> > > your efforts.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 3/31/19 7:50 PM, Jon Evans wrote:
> > >> Yes I just squashed the parts that dont compile on their own.
> > >>
> > >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh  > 
> > >> >>
> wrote:
> > >>
> > >> Jon,
> > >>
> > >> I thought we decided to squash your patch set or did you just
> > squash
> > >> part of the patch set?  I see 17 separate patches the archive
> > you
> > >> sent.
> > >>
> > >> Wayne
> > >>
> > >> On 3/31/19 7:39 PM, Jon Evans wrote:
> > >>  > Attached!
> > >>  >
> > >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> > >> mailto:stambau...@gmail.com>
> > >
> > >>  > 
> >  > >> wrote:
> > >>  >
> > >>  > Jon,
> > >>  >
> > >>  > Would you please post the squashed patch to the
> > mailing list
> > >> so I can
> > >>  > get it merged?
> > >>  >
> > >>  > Thanks,
> > >>  >
> > >>  > Wayne
> > >>  >
> > >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
> > >>  >  > I went through and squashed the offending commits
> and
> > >> updated the
> > >>  > PRs.
> > >>  >  >
> > >>  >  > -Jon
> > >>  >  >
> > >>  >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> > >>  > mailto:stambau...@gmail.com>
> > >
> > >> 
> > >>
> > >>  >  >  >   > >
> > >> 
> > 
> wrote:
> > >>  >  >
> > >>  >  > If that's the case then it may make the most
> > sense to
> > >> squash
> > >>  > everything
> > >>  >  > into a single commit.
> > >>  >  >
> > >>  >  > On 3/31/19 2:17 PM, Jon Evans wrote:
> > >>  >  >  > That one was very late and would be easy to
> > squash.
> > >>  > However, some
> > >>  >  > of the
> > >>  >  >  > very early commits in the branch were split
> > up for
> > >> review
> > >>  >  > purposes and
> > >>  >  >  > not intended to be built on their own.
> > >>  >  >  >
> > >>  >  >  > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
> > >>  > mailto:stambau...@gmail.com>
> > >
> > >> 
> > >>
> > >>  >  > 

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

No problem.  I wanted to get this merged so we can get some additional
testing.  Hopefully you will be able to resolve the performance issues
so we can have real time netlist generation and some of the nifty
features that this will allow.

On 3/31/2019 11:19 PM, Jon Evans wrote:
> Thanks Wayne! Everything looks good to me.
> 
> Glad to finally have this merged so that I can start building other
> improvements on top of it.
> 
> On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh  > wrote:
> 
> Jon,
> 
> I forgot to mention.  Please take a look and make sure I didn't muck
> anything up when you get a chance.
> 
> Wayne
> 
> On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > Jon,
> >
> > I merged your patch set into the master branch.  Thank you for all of
> > your efforts.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 3/31/19 7:50 PM, Jon Evans wrote:
> >> Yes I just squashed the parts that dont compile on their own.
> >>
> >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh  
> >> >> wrote:
> >>
> >>     Jon,
> >>
> >>     I thought we decided to squash your patch set or did you just
> squash
> >>     part of the patch set?  I see 17 separate patches the archive
> you
> >> sent.
> >>
> >>     Wayne
> >>
> >>     On 3/31/19 7:39 PM, Jon Evans wrote:
> >>  > Attached!
> >>  >
> >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> >>     mailto:stambau...@gmail.com>
> >
> >>  > 
>  >> wrote:
> >>  >
> >>  >     Jon,
> >>  >
> >>  >     Would you please post the squashed patch to the
> mailing list
> >>     so I can
> >>  >     get it merged?
> >>  >
> >>  >     Thanks,
> >>  >
> >>  >     Wayne
> >>  >
> >>  >     On 3/31/19 3:07 PM, Jon Evans wrote:
> >>  >      > I went through and squashed the offending commits and
> >>     updated the
> >>  >     PRs.
> >>  >      >
> >>  >      > -Jon
> >>  >      >
> >>  >      > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> >>  >     mailto:stambau...@gmail.com>
> >
> >>     
> >>
> >>  >      >    >
> >>     
>  wrote:
> >>  >      >
> >>  >      >     If that's the case then it may make the most
> sense to
> >>     squash
> >>  >     everything
> >>  >      >     into a single commit.
> >>  >      >
> >>  >      >     On 3/31/19 2:17 PM, Jon Evans wrote:
> >>  >      >      > That one was very late and would be easy to
> squash.
> >>  >     However, some
> >>  >      >     of the
> >>  >      >      > very early commits in the branch were split
> up for
> >>     review
> >>  >      >     purposes and
> >>  >      >      > not intended to be built on their own.
> >>  >      >      >
> >>  >      >      > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
> >>  >     mailto:stambau...@gmail.com>
> >
> >>     
> >>
> >>  >      >      
> >>     >
> 
> >>      >>  >      >      >  
> >>     >
> 
> >>     >>
> >>  >        >
> >>     
> > wrote:
>   

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Thanks Wayne! Everything looks good to me.

Glad to finally have this merged so that I can start building other
improvements on top of it.

On Sun, Mar 31, 2019 at 9:42 PM Wayne Stambaugh 
wrote:

> Jon,
>
> I forgot to mention.  Please take a look and make sure I didn't muck
> anything up when you get a chance.
>
> Wayne
>
> On 3/31/19 9:38 PM, Wayne Stambaugh wrote:
> > Jon,
> >
> > I merged your patch set into the master branch.  Thank you for all of
> > your efforts.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 3/31/19 7:50 PM, Jon Evans wrote:
> >> Yes I just squashed the parts that dont compile on their own.
> >>
> >> On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh  >> > wrote:
> >>
> >> Jon,
> >>
> >> I thought we decided to squash your patch set or did you just squash
> >> part of the patch set?  I see 17 separate patches the archive you
> >> sent.
> >>
> >> Wayne
> >>
> >> On 3/31/19 7:39 PM, Jon Evans wrote:
> >>  > Attached!
> >>  >
> >>  > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
> >> mailto:stambau...@gmail.com>
> >>  > >>
> >> wrote:
> >>  >
> >>  > Jon,
> >>  >
> >>  > Would you please post the squashed patch to the mailing list
> >> so I can
> >>  > get it merged?
> >>  >
> >>  > Thanks,
> >>  >
> >>  > Wayne
> >>  >
> >>  > On 3/31/19 3:07 PM, Jon Evans wrote:
> >>  >  > I went through and squashed the offending commits and
> >> updated the
> >>  > PRs.
> >>  >  >
> >>  >  > -Jon
> >>  >  >
> >>  >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> >>  > mailto:stambau...@gmail.com>
> >> >
> >>  >  >  >
> >>  wrote:
> >>  >  >
> >>  >  > If that's the case then it may make the most sense to
> >> squash
> >>  > everything
> >>  >  > into a single commit.
> >>  >  >
> >>  >  > On 3/31/19 2:17 PM, Jon Evans wrote:
> >>  >  >  > That one was very late and would be easy to squash.
> >>  > However, some
> >>  >  > of the
> >>  >  >  > very early commits in the branch were split up for
> >> review
> >>  >  > purposes and
> >>  >  >  > not intended to be built on their own.
> >>  >  >  >
> >>  >  >  > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
> >>  > mailto:stambau...@gmail.com>
> >> >
> >>  >  >  >>   >> >>
> >>  >  >  >  >>   >> >
> >>  > 
> >> 
> wrote:
> >>  >  >  >
> >>  >  >  > When was the code that did not build on msvc
> >>  > introduced?  If
> >>  >  > was early
> >>  >  >  > then it might make sense to squash everything.
> >>  > Otherwise, it
> >>  >  > may be
> >>  >  >  > worthwhile squashing from the commit where the
> >> build
> >>  > error was
> >>  >  >  > introduced to and including the commit where
> >> the build
> >>  > error
> >>  >  > was fixed.
> >>  >  >  >  I don't have a preference one way or the
> >> other.  I'm
> >>  > open to
> >>  >  >  > suggestion.
> >>  >  >  >
> >>  >  >  > On 3/31/19 11:14 AM, Jon Evans wrote:
> >>  >  >  > > Seth, I split up the initial rebased branch
> >> to make
> >>  > review
> >>  >  > a bit
> >>  >  >  > > easier.  I could squash everything into one
> >> huge
> >>  > commit if
> >>  >  > you'd
> >>  >  >  > prefer.
> >>  >  >  > >
> >>  >  >  > > On Sun, Mar 31, 2019 at 9:56 AM Seth
> Hillbrand
> >>  >  > mailto:s...@hillbrand.org>
> >> >
> >>  > 
> >> >>
> >>  >  >  >  >>   >> >
> >>  > 

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Jon,

I forgot to mention.  Please take a look and make sure I didn't muck 
anything up when you get a chance.


Wayne

On 3/31/19 9:38 PM, Wayne Stambaugh wrote:

Jon,

I merged your patch set into the master branch.  Thank you for all of 
your efforts.


Cheers,

Wayne

On 3/31/19 7:50 PM, Jon Evans wrote:

Yes I just squashed the parts that dont compile on their own.

On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh > wrote:


    Jon,

    I thought we decided to squash your patch set or did you just squash
    part of the patch set?  I see 17 separate patches the archive you 
sent.


    Wayne

    On 3/31/19 7:39 PM, Jon Evans wrote:
 > Attached!
 >
 > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
    mailto:stambau...@gmail.com>
 > >> 
wrote:

 >
 >     Jon,
 >
 >     Would you please post the squashed patch to the mailing list
    so I can
 >     get it merged?
 >
 >     Thanks,
 >
 >     Wayne
 >
 >     On 3/31/19 3:07 PM, Jon Evans wrote:
 >      > I went through and squashed the offending commits and
    updated the
 >     PRs.
 >      >
 >      > -Jon
 >      >
 >      > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
 >     mailto:stambau...@gmail.com>
    >
 >      > 
          >
 >      >     If that's the case then it may make the most sense to
    squash
 >     everything
 >      >     into a single commit.
 >      >
 >      >     On 3/31/19 2:17 PM, Jon Evans wrote:
 >      >      > That one was very late and would be easy to squash.
 >     However, some
 >      >     of the
 >      >      > very early commits in the branch were split up for
    review
 >      >     purposes and
 >      >      > not intended to be built on their own.
 >      >      >
 >      >      > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
 >     mailto:stambau...@gmail.com>
    >
 >      >      >>
 >      >      >  >
 >     
     wrote:
 >      >      >
 >      >      >     When was the code that did not build on msvc
 >     introduced?  If
 >      >     was early
 >      >      >     then it might make sense to squash everything.
 >     Otherwise, it
 >      >     may be
 >      >      >     worthwhile squashing from the commit where the
    build
 >     error was
 >      >      >     introduced to and including the commit where
    the build
 >     error
 >      >     was fixed.
 >      >      >      I don't have a preference one way or the
    other.  I'm
 >     open to
 >      >      >     suggestion.
 >      >      >
 >      >      >     On 3/31/19 11:14 AM, Jon Evans wrote:
 >      >      >     > Seth, I split up the initial rebased branch
    to make
 >     review
 >      >     a bit
 >      >      >     > easier.  I could squash everything into one 
huge

 >     commit if
 >      >     you'd
 >      >      >     prefer.
 >      >      >     >
 >      >      >     > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand
 >      >     mailto:s...@hillbrand.org>
    >
 >     
    >>
 >      >      >      >
 >     
          >      >     > 
 >     >
    
 >     >>
 >      >     
    >
 >     
    > wrote:
 >      >      >     >
 >      >      >     >     Am 2019-03-30 17:33, schrieb Simon 
Richter:

 >      >  

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Jon,

I merged your patch set into the master branch.  Thank you for all of 
your efforts.


Cheers,

Wayne

On 3/31/19 7:50 PM, Jon Evans wrote:

Yes I just squashed the parts that dont compile on their own.

On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh > wrote:


Jon,

I thought we decided to squash your patch set or did you just squash
part of the patch set?  I see 17 separate patches the archive you sent.

Wayne

On 3/31/19 7:39 PM, Jon Evans wrote:
 > Attached!
 >
 > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh
mailto:stambau...@gmail.com>
 > >> wrote:
 >
 >     Jon,
 >
 >     Would you please post the squashed patch to the mailing list
so I can
 >     get it merged?
 >
 >     Thanks,
 >
 >     Wayne
 >
 >     On 3/31/19 3:07 PM, Jon Evans wrote:
 >      > I went through and squashed the offending commits and
updated the
 >     PRs.
 >      >
 >      > -Jon
 >      >
 >      > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
 >     mailto:stambau...@gmail.com>
>
 >      > 
      >
 >      >     If that's the case then it may make the most sense to
squash
 >     everything
 >      >     into a single commit.
 >      >
 >      >     On 3/31/19 2:17 PM, Jon Evans wrote:
 >      >      > That one was very late and would be easy to squash.
 >     However, some
 >      >     of the
 >      >      > very early commits in the branch were split up for
review
 >      >     purposes and
 >      >      > not intended to be built on their own.
 >      >      >
 >      >      > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
 >     mailto:stambau...@gmail.com>
>
 >      >      >>
 >      >      >  >
 >     
 wrote:
 >      >      >
 >      >      >     When was the code that did not build on msvc
 >     introduced?  If
 >      >     was early
 >      >      >     then it might make sense to squash everything.
 >     Otherwise, it
 >      >     may be
 >      >      >     worthwhile squashing from the commit where the
build
 >     error was
 >      >      >     introduced to and including the commit where
the build
 >     error
 >      >     was fixed.
 >      >      >      I don't have a preference one way or the
other.  I'm
 >     open to
 >      >      >     suggestion.
 >      >      >
 >      >      >     On 3/31/19 11:14 AM, Jon Evans wrote:
 >      >      >     > Seth, I split up the initial rebased branch
to make
 >     review
 >      >     a bit
 >      >      >     > easier.  I could squash everything into one huge
 >     commit if
 >      >     you'd
 >      >      >     prefer.
 >      >      >     >
 >      >      >     > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand
 >      >     mailto:s...@hillbrand.org>
>
 >     
>>
 >      >      >      >
 >     
      >      >     > 
 >     >

 >     >>
 >      >     
>
 >     
> wrote:
 >      >      >     >
 >      >      >     >     Am 2019-03-30 17:33, schrieb Simon Richter:
 >      >      >     >     > Hi Wayne,
 >      >      >     >     >
 >      >      >     >     > On 30.03.19 21:30, Wayne Stambaugh wrote:
 >      >      >     >     >
   

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Yes I just squashed the parts that dont compile on their own.

On Sun, Mar 31, 2019, 19:48 Wayne Stambaugh  wrote:

> Jon,
>
> I thought we decided to squash your patch set or did you just squash
> part of the patch set?  I see 17 separate patches the archive you sent.
>
> Wayne
>
> On 3/31/19 7:39 PM, Jon Evans wrote:
> > Attached!
> >
> > On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh  > > wrote:
> >
> > Jon,
> >
> > Would you please post the squashed patch to the mailing list so I can
> > get it merged?
> >
> > Thanks,
> >
> > Wayne
> >
> > On 3/31/19 3:07 PM, Jon Evans wrote:
> >  > I went through and squashed the offending commits and updated the
> > PRs.
> >  >
> >  > -Jon
> >  >
> >  > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> >  > >>
> wrote:
> >  >
> >  > If that's the case then it may make the most sense to squash
> > everything
> >  > into a single commit.
> >  >
> >  > On 3/31/19 2:17 PM, Jon Evans wrote:
> >  >  > That one was very late and would be easy to squash.
> > However, some
> >  > of the
> >  >  > very early commits in the branch were split up for review
> >  > purposes and
> >  >  > not intended to be built on their own.
> >  >  >
> >  >  > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> >  > >
> >  >  > 
> >  >  >  >
> >  >  > When was the code that did not build on msvc
> > introduced?  If
> >  > was early
> >  >  > then it might make sense to squash everything.
> > Otherwise, it
> >  > may be
> >  >  > worthwhile squashing from the commit where the build
> > error was
> >  >  > introduced to and including the commit where the build
> > error
> >  > was fixed.
> >  >  >  I don't have a preference one way or the other.  I'm
> > open to
> >  >  > suggestion.
> >  >  >
> >  >  > On 3/31/19 11:14 AM, Jon Evans wrote:
> >  >  > > Seth, I split up the initial rebased branch to make
> > review
> >  > a bit
> >  >  > > easier.  I could squash everything into one huge
> > commit if
> >  > you'd
> >  >  > prefer.
> >  >  > >
> >  >  > > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand
> >  > mailto:s...@hillbrand.org>
> > >
> >  >  > 
> > >>
> >  >  > >  >   > >
> >  > 
> >  wrote:
> >  >  > >
> >  >  > > Am 2019-03-30 17:33, schrieb Simon Richter:
> >  >  > > > Hi Wayne,
> >  >  > > >
> >  >  > > > On 30.03.19 21:30, Wayne Stambaugh wrote:
> >  >  > > >
> >  >  > > >> Is this the last of it?  If so, I will
> attempt to
> >  > get this
> >  >  > merged
> >  >  > > >> tomorrow.
> >  >  > > >
> >  >  > > > Compiles fine on msys2 and msvc. Not all
> > intermediate
> >  >  > commits compile,
> >  >  > > > but I'm not sure anyone does git-bisect anyway.
> >  >  > >
> >  >  > > I use git bisect frequently.  Please do not push
> >  > commits that
> >  >  > do not
> >  >  > > compile.  This has been done previously and it
> added
> >  > hours to
> >  >  > fixing a
> >  >  > > single bug in 5.0.1.
> >  >  > >
> >  >  > > -S
> >  >  > >
> >  >  > > ___
> >  >  > > Mailing list:
> > https://launchpad.net/~kicad-developers
> >  >  > > Post to :
> > kicad-developers@lists.launchpad.net
> > 
> >  >  > >
> >  >  >  > 
> >  > 

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Jon,

I thought we decided to squash your patch set or did you just squash 
part of the patch set?  I see 17 separate patches the archive you sent.


Wayne

On 3/31/19 7:39 PM, Jon Evans wrote:

Attached!

On Sun, Mar 31, 2019 at 7:28 PM Wayne Stambaugh > wrote:


Jon,

Would you please post the squashed patch to the mailing list so I can
get it merged?

Thanks,

Wayne

On 3/31/19 3:07 PM, Jon Evans wrote:
 > I went through and squashed the offending commits and updated the
PRs.
 >
 > -Jon
 >
 > On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh
mailto:stambau...@gmail.com>
 > >> wrote:
 >
 >     If that's the case then it may make the most sense to squash
everything
 >     into a single commit.
 >
 >     On 3/31/19 2:17 PM, Jon Evans wrote:
 >      > That one was very late and would be easy to squash.
However, some
 >     of the
 >      > very early commits in the branch were split up for review
 >     purposes and
 >      > not intended to be built on their own.
 >      >
 >      > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh
mailto:stambau...@gmail.com>
 >     >
 >      > 
      >
 >      >     When was the code that did not build on msvc
introduced?  If
 >     was early
 >      >     then it might make sense to squash everything. 
Otherwise, it

 >     may be
 >      >     worthwhile squashing from the commit where the build
error was
 >      >     introduced to and including the commit where the build
error
 >     was fixed.
 >      >      I don't have a preference one way or the other.  I'm
open to
 >      >     suggestion.
 >      >
 >      >     On 3/31/19 11:14 AM, Jon Evans wrote:
 >      >     > Seth, I split up the initial rebased branch to make
review
 >     a bit
 >      >     > easier.  I could squash everything into one huge
commit if
 >     you'd
 >      >     prefer.
 >      >     >
 >      >     > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand
 >     mailto:s...@hillbrand.org>
>
 >      >     
>>
 >      >     >  >
 >     
 wrote:
 >      >     >
 >      >     >     Am 2019-03-30 17:33, schrieb Simon Richter:
 >      >     >     > Hi Wayne,
 >      >     >     >
 >      >     >     > On 30.03.19 21:30, Wayne Stambaugh wrote:
 >      >     >     >
 >      >     >     >> Is this the last of it?  If so, I will attempt to
 >     get this
 >      >     merged
 >      >     >     >> tomorrow.
 >      >     >     >
 >      >     >     > Compiles fine on msys2 and msvc. Not all
intermediate
 >      >     commits compile,
 >      >     >     > but I'm not sure anyone does git-bisect anyway.
 >      >     >
 >      >     >     I use git bisect frequently.  Please do not push
 >     commits that
 >      >     do not
 >      >     >     compile.  This has been done previously and it added
 >     hours to
 >      >     fixing a
 >      >     >     single bug in 5.0.1.
 >      >     >
 >      >     >     -S
 >      >     >
 >      >     >     ___
 >      >     >     Mailing list:
https://launchpad.net/~kicad-developers
 >      >     >     Post to     :
kicad-developers@lists.launchpad.net

 >     >
 >      >     
 >     >>
 >      >     >     
 >     >
 >      >     
 >           >     >     

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Jon,

Would you please post the squashed patch to the mailing list so I can 
get it merged?


Thanks,

Wayne

On 3/31/19 3:07 PM, Jon Evans wrote:

I went through and squashed the offending commits and updated the PRs.

-Jon

On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh > wrote:


If that's the case then it may make the most sense to squash everything
into a single commit.

On 3/31/19 2:17 PM, Jon Evans wrote:
 > That one was very late and would be easy to squash. However, some
of the
 > very early commits in the branch were split up for review
purposes and
 > not intended to be built on their own.
 >
 > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh mailto:stambau...@gmail.com>
 > >> wrote:
 >
 >     When was the code that did not build on msvc introduced?  If
was early
 >     then it might make sense to squash everything.  Otherwise, it
may be
 >     worthwhile squashing from the commit where the build error was
 >     introduced to and including the commit where the build error
was fixed.
 >      I don't have a preference one way or the other.  I'm open to
 >     suggestion.
 >
 >     On 3/31/19 11:14 AM, Jon Evans wrote:
 >     > Seth, I split up the initial rebased branch to make review
a bit
 >     > easier.  I could squash everything into one huge commit if
you'd
 >     prefer.
 >     >
 >     > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand
mailto:s...@hillbrand.org>
 >     >
 >     > 
     >
 >     >     Am 2019-03-30 17:33, schrieb Simon Richter:
 >     >     > Hi Wayne,
 >     >     >
 >     >     > On 30.03.19 21:30, Wayne Stambaugh wrote:
 >     >     >
 >     >     >> Is this the last of it?  If so, I will attempt to
get this
 >     merged
 >     >     >> tomorrow.
 >     >     >
 >     >     > Compiles fine on msys2 and msvc. Not all intermediate
 >     commits compile,
 >     >     > but I'm not sure anyone does git-bisect anyway.
 >     >
 >     >     I use git bisect frequently.  Please do not push
commits that
 >     do not
 >     >     compile.  This has been done previously and it added
hours to
 >     fixing a
 >     >     single bug in 5.0.1.
 >     >
 >     >     -S
 >     >
 >     >     ___
 >     >     Mailing list: https://launchpad.net/~kicad-developers
 >     >     Post to     : kicad-developers@lists.launchpad.net

 >     >
 >     >     
 >     >>
 >     >     Unsubscribe : https://launchpad.net/~kicad-developers
 >     >     More help   : https://help.launchpad.net/ListHelp
 >     >
 >     >
 >     > ___
 >     > Mailing list: https://launchpad.net/~kicad-developers
 >     > Post to     : kicad-developers@lists.launchpad.net

 >     >
 >     > Unsubscribe : https://launchpad.net/~kicad-developers
 >     > More help   : https://help.launchpad.net/ListHelp
 >     >
 >
 >     ___
 >     Mailing list: https://launchpad.net/~kicad-developers
 >     Post to     : kicad-developers@lists.launchpad.net

 >     >
 >     Unsubscribe : https://launchpad.net/~kicad-developers
 >     More help   : https://help.launchpad.net/ListHelp
 >



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Seth Hillbrand]

Thanks Jon!-SOn Mar 31, 2019 12:07 PM, Jon Evans  wrote:I went through and squashed the offending commits and updated the PRs.-JonOn Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh  wrote:If that's the case then it may make the most sense to squash everything
into a single commit.

On 3/31/19 2:17 PM, Jon Evans wrote:
> That one was very late and would be easy to squash. However, some of the
> very early commits in the branch were split up for review purposes and
> not intended to be built on their own. 
> 
> On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh  stambau...@gmail.com>> wrote:
> 
>     When was the code that did not build on msvc introduced?  If was early
>     then it might make sense to squash everything.  Otherwise, it may be
>     worthwhile squashing from the commit where the build error was
>     introduced to and including the commit where the build error was fixed.
>      I don't have a preference one way or the other.  I'm open to
>     suggestion.
> 
>     On 3/31/19 11:14 AM, Jon Evans wrote:
>     > Seth, I split up the initial rebased branch to make review a bit
>     > easier.  I could squash everything into one huge commit if you'd
>     prefer.
>     >
>     > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand      s...@hillbrand.org>
>     > s...@hillbrand.org s...@hillbrand.org>>> wrote:
>     >
>     >     Am 2019-03-30 17:33, schrieb Simon Richter:
>     >     > Hi Wayne,
>     >     >
>     >     > On 30.03.19 21:30, Wayne Stambaugh wrote:
>     >     >
>     >     >> Is this the last of it?  If so, I will attempt to get this
>     merged
>     >     >> tomorrow.
>     >     >
>     >     > Compiles fine on msys2 and msvc. Not all intermediate
>     commits compile,
>     >     > but I'm not sure anyone does git-bisect anyway.
>     >
>     >     I use git bisect frequently.  Please do not push commits that
>     do not
>     >     compile.  This has been done previously and it added hours to
>     fixing a
>     >     single bug in 5.0.1.
>     >
>     >     -S
>     >
>     >     ___
>     >     Mailing list: https://launchpad.net/~kicad-developers
>     >     Post to     : kicad-developers@lists.launchpad.net
>     kicad-developers@lists.launchpad.net>
>     >     kicad-developers@lists.launchpad.net
>     kicad-developers@lists.launchpad.net>>
>     >     Unsubscribe : https://launchpad.net/~kicad-developers
>     >     More help   : https://help.launchpad.net/ListHelp
>     >
>     >
>     > ___
>     > Mailing list: https://launchpad.net/~kicad-developers
>     > Post to     : kicad-developers@lists.launchpad.net
>     kicad-developers@lists.launchpad.net>
>     > Unsubscribe : https://launchpad.net/~kicad-developers
>     > More help   : https://help.launchpad.net/ListHelp
>     >
> 
>     ___
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@lists.launchpad.net
>     kicad-developers@lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

I went through and squashed the offending commits and updated the PRs.

-Jon

On Sun, Mar 31, 2019 at 2:22 PM Wayne Stambaugh 
wrote:

> If that's the case then it may make the most sense to squash everything
> into a single commit.
>
> On 3/31/19 2:17 PM, Jon Evans wrote:
> > That one was very late and would be easy to squash. However, some of the
> > very early commits in the branch were split up for review purposes and
> > not intended to be built on their own.
> >
> > On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh  > > wrote:
> >
> > When was the code that did not build on msvc introduced?  If was
> early
> > then it might make sense to squash everything.  Otherwise, it may be
> > worthwhile squashing from the commit where the build error was
> > introduced to and including the commit where the build error was
> fixed.
> >  I don't have a preference one way or the other.  I'm open to
> > suggestion.
> >
> > On 3/31/19 11:14 AM, Jon Evans wrote:
> > > Seth, I split up the initial rebased branch to make review a bit
> > > easier.  I could squash everything into one huge commit if you'd
> > prefer.
> > >
> > > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand  > 
> > > >> wrote:
> > >
> > > Am 2019-03-30 17:33, schrieb Simon Richter:
> > > > Hi Wayne,
> > > >
> > > > On 30.03.19 21:30, Wayne Stambaugh wrote:
> > > >
> > > >> Is this the last of it?  If so, I will attempt to get this
> > merged
> > > >> tomorrow.
> > > >
> > > > Compiles fine on msys2 and msvc. Not all intermediate
> > commits compile,
> > > > but I'm not sure anyone does git-bisect anyway.
> > >
> > > I use git bisect frequently.  Please do not push commits that
> > do not
> > > compile.  This has been done previously and it added hours to
> > fixing a
> > > single bug in 5.0.1.
> > >
> > > -S
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> > >  > >
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

If that's the case then it may make the most sense to squash everything
into a single commit.

On 3/31/19 2:17 PM, Jon Evans wrote:
> That one was very late and would be easy to squash. However, some of the
> very early commits in the branch were split up for review purposes and
> not intended to be built on their own. 
> 
> On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh  > wrote:
> 
> When was the code that did not build on msvc introduced?  If was early
> then it might make sense to squash everything.  Otherwise, it may be
> worthwhile squashing from the commit where the build error was
> introduced to and including the commit where the build error was fixed.
>  I don't have a preference one way or the other.  I'm open to
> suggestion.
> 
> On 3/31/19 11:14 AM, Jon Evans wrote:
> > Seth, I split up the initial rebased branch to make review a bit
> > easier.  I could squash everything into one huge commit if you'd
> prefer.
> >
> > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand  
> > >> wrote:
> >
> >     Am 2019-03-30 17:33, schrieb Simon Richter:
> >     > Hi Wayne,
> >     >
> >     > On 30.03.19 21:30, Wayne Stambaugh wrote:
> >     >
> >     >> Is this the last of it?  If so, I will attempt to get this
> merged
> >     >> tomorrow.
> >     >
> >     > Compiles fine on msys2 and msvc. Not all intermediate
> commits compile,
> >     > but I'm not sure anyone does git-bisect anyway.
> >
> >     I use git bisect frequently.  Please do not push commits that
> do not
> >     compile.  This has been done previously and it added hours to
> fixing a
> >     single bug in 5.0.1.
> >
> >     -S
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> >     Post to     : kicad-developers@lists.launchpad.net
> 
> >      >
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

That one was very late and would be easy to squash. However, some of the
very early commits in the branch were split up for review purposes and not
intended to be built on their own.

On Sun, Mar 31, 2019, 14:16 Wayne Stambaugh  wrote:

> When was the code that did not build on msvc introduced?  If was early
> then it might make sense to squash everything.  Otherwise, it may be
> worthwhile squashing from the commit where the build error was
> introduced to and including the commit where the build error was fixed.
>  I don't have a preference one way or the other.  I'm open to suggestion.
>
> On 3/31/19 11:14 AM, Jon Evans wrote:
> > Seth, I split up the initial rebased branch to make review a bit
> > easier.  I could squash everything into one huge commit if you'd prefer.
> >
> > On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand  > > wrote:
> >
> > Am 2019-03-30 17:33, schrieb Simon Richter:
> > > Hi Wayne,
> > >
> > > On 30.03.19 21:30, Wayne Stambaugh wrote:
> > >
> > >> Is this the last of it?  If so, I will attempt to get this merged
> > >> tomorrow.
> > >
> > > Compiles fine on msys2 and msvc. Not all intermediate commits
> compile,
> > > but I'm not sure anyone does git-bisect anyway.
> >
> > I use git bisect frequently.  Please do not push commits that do not
> > compile.  This has been done previously and it added hours to fixing
> a
> > single bug in 5.0.1.
> >
> > -S
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

When was the code that did not build on msvc introduced?  If was early
then it might make sense to squash everything.  Otherwise, it may be
worthwhile squashing from the commit where the build error was
introduced to and including the commit where the build error was fixed.
 I don't have a preference one way or the other.  I'm open to suggestion.

On 3/31/19 11:14 AM, Jon Evans wrote:
> Seth, I split up the initial rebased branch to make review a bit
> easier.  I could squash everything into one huge commit if you'd prefer.
> 
> On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand  > wrote:
> 
> Am 2019-03-30 17:33, schrieb Simon Richter:
> > Hi Wayne,
> >
> > On 30.03.19 21:30, Wayne Stambaugh wrote:
> >
> >> Is this the last of it?  If so, I will attempt to get this merged
> >> tomorrow.
> >
> > Compiles fine on msys2 and msvc. Not all intermediate commits compile,
> > but I'm not sure anyone does git-bisect anyway.
> 
> I use git bisect frequently.  Please do not push commits that do not
> compile.  This has been done previously and it added hours to fixing a
> single bug in 5.0.1.
> 
> -S
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Seth, I split up the initial rebased branch to make review a bit easier.  I
could squash everything into one huge commit if you'd prefer.

On Sun, Mar 31, 2019 at 9:56 AM Seth Hillbrand  wrote:

> Am 2019-03-30 17:33, schrieb Simon Richter:
> > Hi Wayne,
> >
> > On 30.03.19 21:30, Wayne Stambaugh wrote:
> >
> >> Is this the last of it?  If so, I will attempt to get this merged
> >> tomorrow.
> >
> > Compiles fine on msys2 and msvc. Not all intermediate commits compile,
> > but I'm not sure anyone does git-bisect anyway.
>
> I use git bisect frequently.  Please do not push commits that do not
> compile.  This has been done previously and it added hours to fixing a
> single bug in 5.0.1.
>
> -S
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Simon Richter]

Hi,

On 31.03.19 15:55, Seth Hillbrand wrote:

> I use git bisect frequently.  Please do not push commits that do not
> compile.  This has been done previously and it added hours to fixing a
> single bug in 5.0.1.

It's probably trivial:

commit f67d243c368659798828dde87d9cf562c9176694
Author: Jon Evans 
Date:   Sat Mar 30 15:35:46 2019 -0400

Remove debug code

Notes:
pass

commit f21bf3d43a824d19784d8cd70fe25e492882f2d0
Author: Jon Evans 
Date:   Sat Mar 30 14:18:29 2019 -0400

Revert "Remove unnecessary calls to TestDanglingEnds()"

This reverts commit d93e3894f2bcd6239862ac9eae0cb2f994b9d52a.

Notes:
pass

commit 8f2d569c0aa4765938e7196e67ca514b16e0d4fa
Author: Jon Evans 
Date:   Sat Mar 30 12:26:03 2019 -0400

Disable real-time connectivity updates for now

Notes:
pass

commit 10d28a5ab71b64b29e1e5ba9c83e6bac16b0b7a1
Author: Jon Evans 
Date:   Sat Mar 30 12:20:00 2019 -0400

Remove unnecessary calls to TestDanglingEnds()

Notes:
pass

commit 528c7b584a6a15bc18e0f8c89ca9cebe32f562c3
Author: Jon Evans 
Date:   Sat Mar 30 11:57:30 2019 -0400

Don't call OnModify() before placing new parts

Notes:
pass

commit 5a5171dafce226232c80959017cf3b9e2e348e08
Author: Jon Evans 
Date:   Sat Mar 30 11:52:16 2019 -0400

Don't update graph when entering/leaving sheets

Notes:
pass

commit 49819c875b1d2671e98c8a11a7bc69917c2a02c9
Author: Jon Evans 
Date:   Thu Mar 28 21:15:36 2019 -0400

Restore ERC checks that were accidentally removed

Notes:
pass

commit cb4d82a84c6f6acefe32f563ddf4a92bcb568203
Author: Jon Evans 
Date:   Wed Mar 27 23:36:35 2019 -0400

Improve naming of weak subgraphs

Notes:
pass

commit 59337bf89d5d4329f4e8895acdabf95b0d26d158
Author: Jon Evans 
Date:   Tue Mar 26 23:02:21 2019 -0400

Revert "Don't prepend "/" for nets at the top level"

This reverts commit fa9533222f7d33eee5f3fa2320bd9f3167e28076.

Notes:
pass

commit b95b86b59e3ea2c2dcfef0c7184d56700a06514c
Author: Jon Evans 
Date:   Sat Mar 23 19:29:48 2019 -0400

Don't prepend "/" for nets at the top level

Notes:
pass

commit d414e285c57b5c2fbfb119dbcd1f4c2f95c4507e
Author: Jon Evans 
Date:   Sat Mar 23 17:34:27 2019 -0400

Refactor how at-load schematic normalization is called

Notes:
pass

commit 3fe474950ed95ac32d60b3458d7e71f9f9532862
Author: Jon Evans 
Date:   Sat Mar 23 16:53:26 2019 -0400

Add missing junctions during schematic cleanup

Notes:
pass

commit 6b1b7950fc70f095c502ca5df1928d23f3dbab39
Author: Jon Evans 
Date:   Sat Mar 23 15:43:33 2019 -0400

Suppress ERC warnings about multiple labels if the text is the same

Notes:
pass

commit c5cb7d4b6f0fb90f1c222aeb7ef4f202790233c3
Author: Jon Evans 
Date:   Sat Mar 23 14:21:25 2019 -0400

Don't connect bus entries and bus labels that happen to overlap

Notes:
pass

commit 8174c1b770fe5a8884ec63ab76d9d43945c29caa
Author: Jon Evans 
Date:   Mon Mar 18 20:19:00 2019 -0400

Bump file format version

Notes:
pass

commit e7c98752a09a19d60db5093e3da87f27b5f136e3
Author: Jon Evans 
Date:   Mon Mar 18 19:02:24 2019 -0400

Try harder to reassign copper zones on netlist import

Notes:
pass

commit 8186514b8d4249837b9b0554dd0a6da87447cdec
Author: Jon Evans 
Date:   Mon Mar 18 18:38:55 2019 -0400

Clean up cruft in netlist export

Notes:
pass

commit f974af83677bf8f31edd7ea3345bf98120e796cc
Author: Jon Evans 
Date:   Mon Mar 18 18:38:06 2019 -0400

Fix a few issues with hierarchical propagation

Notes:
pass

commit a71f0485dd676b9066c9fea6d48e6c9c4aed554e
Author: Jon Evans 
Date:   Sun Mar 17 22:07:32 2019 -0400

Fix undo handling of SchematicCleanUp

Notes:
pass

commit fcb878bd827b11f8fa3067939858a6c47f564df3
Author: Jon Evans 
Date:   Sun Mar 17 17:19:21 2019 -0400

Fix false assert when CONNECTIVITY_DEBUG is enabled

Notes:
pass

commit 0475b78350922f785dc34d82f573695b0a24bf1c
Author: Jon Evans 
Date:   Sun Mar 17 16:36:48 2019 -0400

Fix issues with bus unfolding position

Notes:
pass

commit 2b79e9473bf9c1b34f8ddfcce8746378bd04249c
Author: Jon Evans 
Date:   Sun Mar 17 15:47:37 2019 -0400

Support bus entries with highlighting

Notes:
pass

commit e034212606acc1e809ab40363746dd1842fc6c54
Author: Jon Evans 
Date:   Sun Mar 17 15:40:20 2019 -0400

Don't generate connections between two bus-wire entries

Notes:
pass

commit b89c1db0c09106e52b83ecf82bce85ce3b150d6b
Author: Jon Evans 
Date:   Sun Mar 17 15:15:08 2019 -0400

Begin refactoring netlist creation

Notes:
pass

commit 3c0306e250d42a3bb652932f149544689242f4ae
Author: Jon Evans 
Date:   Sun Mar 17 14:30:19 2019 -0400

Fix issue where some power symbols would show up in netlist

Notes:
pass

commit d09cfdd28385560dc9c1e60c5be3bfcffbc962e9
Author: Jon Evans 
Date:   Mon Mar 11 17:39:05 2019 -0400

Bus upgrades: file format changes

Notes:
pass

commit 47c7e8fbd0eb2cc85c5d4fcc503cf78dc64b2c9d
Author: Jon Evans 
Date:   Mon Mar 

Re: [Kicad-developers] Bus upgrades merge

[Seth Hillbrand]

Am 2019-03-30 17:33, schrieb Simon Richter:

Hi Wayne,

On 30.03.19 21:30, Wayne Stambaugh wrote:

Is this the last of it?  If so, I will attempt to get this merged 
tomorrow.


Compiles fine on msys2 and msvc. Not all intermediate commits compile,
but I'm not sure anyone does git-bisect anyway.


I use git bisect frequently.  Please do not push commits that do not 
compile.  This has been done previously and it added hours to fixing a 
single bug in 5.0.1.


-S

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Simon Richter]

Hi Wayne,

On 30.03.19 21:30, Wayne Stambaugh wrote:

> Is this the last of it?  If so, I will attempt to get this merged tomorrow.

Compiles fine on msys2 and msvc. Not all intermediate commits compile,
but I'm not sure anyone does git-bisect anyway.

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Is this the last of it?  If so, I will attempt to get this merged tomorrow.

Cheers,

Wayne

On 3/30/19 3:35 PM, Jon Evans wrote:
> Oops! fixed.
> 
> On Sat, Mar 30, 2019 at 3:03 PM Simon Richter  > wrote:
> 
> Hi Jon,
> 
> On 30.03.19 19:23, Jon Evans wrote:
> 
> > Rebased my branch (like I mentioned before, JP's usability
> concerns have
> > been addressed for the moment by disabling immediate update until
> I can
> > come up with a better long-term fix)
> 
> Fails to build on MSVC, because there is an
> 
>        asm("nop;");
> 
> statement at connection_graph.cpp:771, presumably you are using that one
> as a breakpoint?
> 
>    Simon
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Oops! fixed.

On Sat, Mar 30, 2019 at 3:03 PM Simon Richter 
wrote:

> Hi Jon,
>
> On 30.03.19 19:23, Jon Evans wrote:
>
> > Rebased my branch (like I mentioned before, JP's usability concerns have
> > been addressed for the moment by disabling immediate update until I can
> > come up with a better long-term fix)
>
> Fails to build on MSVC, because there is an
>
>asm("nop;");
>
> statement at connection_graph.cpp:771, presumably you are using that one
> as a breakpoint?
>
>Simon
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Simon Richter]

Hi Jon,

On 30.03.19 19:23, Jon Evans wrote:

> Rebased my branch (like I mentioned before, JP's usability concerns have
> been addressed for the moment by disabling immediate update until I can
> come up with a better long-term fix)

Fails to build on MSVC, because there is an

   asm("nop;");

statement at connection_graph.cpp:771, presumably you are using that one
as a breakpoint?

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Rebased my branch (like I mentioned before, JP's usability concerns have
been addressed for the moment by disabling immediate update until I can
come up with a better long-term fix)

On Sat, Mar 30, 2019 at 1:07 PM jp charras  wrote:

> Le 30/03/2019 à 13:33, Wayne Stambaugh a écrit :
> > Jon,
> >
> > I wanted to test complex hierarchy bus net connections which I just
> > haven't had time to look at.  JP, did you check this during your
> > testing?  If so and you didn't find any issues, then I will merge this
> > as soon as I get a chance.  If not, then I would like to test this and
> > make sure there are no issues before we merge it.
> >
> > Cheers,
> >
> > Wayne
>
>
> Yes I tested it with a few large projects an a large and complex (4
> sheets using the same file) hierarchy (but only one sample)
> I already sent to Jon this test project (unfortunately not free).
>
> I did not see issues with the latest code.
>
> However I found a usability issue (noticeable with large projects):
> I am guessing the netlist is updated after each schematic change.
> On my computer (not a slow computer) for large designs this update after
> each change takes 1 to 2 seconds on W7 32bits.
> This is a bit annoying.
>
> But the actual issue is the fact there are too many useless updates,
> especially before a symbol is actually added to the schematic:
> When I tray to add a new symbol (from the Place symbol tool or from the
> hotkey "C") it looks like there is an update when the symbol is loaded
> (but not yet placed) and during placement each time the symbol is
> modifed (rotated, mirrored, converted...).
>
> I also see this delay when entering or leaving a hierarchical sheet.
>
> For large designs, this could be blocking.
> Perhaps the immediate update could be disabled (option?) for large designs.
>
> (Jon already knows that)
>
>
> --
> Jean-Pierre CHARRAS
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Simon Richter]

Hi,

On 30.03.19 17:27, Jon Evans wrote:

> I have fixed a few issues, but since I can't be sure there are not still
> performance issues in some situations, I have disabled real-time
> connectivity updates for now so that this issue won't hold up the merge.
> I will revisit this after any other outstanding issues are fixed.

Late to the party, but if anyone wants Windows binaries to test:

https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/306/

This is the bus_upgrades_merge branch rebased on top of current master
(there were two simple conflicts).

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

I have fixed a few issues, but since I can't be sure there are not still
performance issues in some situations, I have disabled real-time
connectivity updates for now so that this issue won't hold up the merge.
I will revisit this after any other outstanding issues are fixed.

On Sat, Mar 30, 2019 at 10:40 AM Jon Evans  wrote:

> JP also just mentioned some performance issues that I'm going to look in
> to. I'll probably just hide the real-time connectivity updates behind a
> flag for now, and re-enable them with performance improvements after the
> branch is merged.
>
> -Jon
>
> On Sat, Mar 30, 2019, 08:34 Wayne Stambaugh  wrote:
>
>> Jon,
>>
>> I wanted to test complex hierarchy bus net connections which I just
>> haven't had time to look at.  JP, did you check this during your
>> testing?  If so and you didn't find any issues, then I will merge this
>> as soon as I get a chance.  If not, then I would like to test this and
>> make sure there are no issues before we merge it.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 3/29/2019 11:54 PM, Jon Evans wrote:
>> > Has anyone else been doing any testing?  I have resolved some issues
>> > that JP found, but haven't heard from anyone else.
>> >
>> > -Jon
>> >
>> > On Fri, Mar 22, 2019 at 5:08 PM Wayne Stambaugh > > > wrote:
>> >
>> > I did some testing and the changes appear to have resolved the
>> original
>> > issues I found.  One thing I did not test was complex hierarchical
>> bus
>> > expansion.  Has anyone else tested this yet?  I hope to get to it
>> over
>> > the weekend.  It's definitely something that should be tested
>> before we
>> > give it our final blessing.
>> >
>> > Wayne
>> >
>> > On 3/22/19 4:57 PM, Seth Hillbrand wrote:
>> > > Am 2019-03-22 16:51, schrieb Seth Hillbrand:
>> > >
>> > >> adjust but I'm seeing show stoppers.
>> > >
>> > > ** not ** seeing show stoppers.
>> > >
>> > > -S
>> > >
>> > > ___
>> > > Mailing list: https://launchpad.net/~kicad-developers
>> > > Post to : kicad-developers@lists.launchpad.net
>> > 
>> > > Unsubscribe : https://launchpad.net/~kicad-developers
>> > > More help   : https://help.launchpad.net/ListHelp
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > 
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

JP also just mentioned some performance issues that I'm going to look in
to. I'll probably just hide the real-time connectivity updates behind a
flag for now, and re-enable them with performance improvements after the
branch is merged.

-Jon

On Sat, Mar 30, 2019, 08:34 Wayne Stambaugh  wrote:

> Jon,
>
> I wanted to test complex hierarchy bus net connections which I just
> haven't had time to look at.  JP, did you check this during your
> testing?  If so and you didn't find any issues, then I will merge this
> as soon as I get a chance.  If not, then I would like to test this and
> make sure there are no issues before we merge it.
>
> Cheers,
>
> Wayne
>
> On 3/29/2019 11:54 PM, Jon Evans wrote:
> > Has anyone else been doing any testing?  I have resolved some issues
> > that JP found, but haven't heard from anyone else.
> >
> > -Jon
> >
> > On Fri, Mar 22, 2019 at 5:08 PM Wayne Stambaugh  > > wrote:
> >
> > I did some testing and the changes appear to have resolved the
> original
> > issues I found.  One thing I did not test was complex hierarchical
> bus
> > expansion.  Has anyone else tested this yet?  I hope to get to it
> over
> > the weekend.  It's definitely something that should be tested before
> we
> > give it our final blessing.
> >
> > Wayne
> >
> > On 3/22/19 4:57 PM, Seth Hillbrand wrote:
> > > Am 2019-03-22 16:51, schrieb Seth Hillbrand:
> > >
> > >> adjust but I'm seeing show stoppers.
> > >
> > > ** not ** seeing show stoppers.
> > >
> > > -S
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[jp charras]

Le 30/03/2019 à 13:33, Wayne Stambaugh a écrit :
> Jon,
> 
> I wanted to test complex hierarchy bus net connections which I just
> haven't had time to look at.  JP, did you check this during your
> testing?  If so and you didn't find any issues, then I will merge this
> as soon as I get a chance.  If not, then I would like to test this and
> make sure there are no issues before we merge it.
> 
> Cheers,
> 
> Wayne


Yes I tested it with a few large projects an a large and complex (4
sheets using the same file) hierarchy (but only one sample)
I already sent to Jon this test project (unfortunately not free).

I did not see issues with the latest code.

However I found a usability issue (noticeable with large projects):
I am guessing the netlist is updated after each schematic change.
On my computer (not a slow computer) for large designs this update after
each change takes 1 to 2 seconds on W7 32bits.
This is a bit annoying.

But the actual issue is the fact there are too many useless updates,
especially before a symbol is actually added to the schematic:
When I tray to add a new symbol (from the Place symbol tool or from the
hotkey "C") it looks like there is an update when the symbol is loaded
(but not yet placed) and during placement each time the symbol is
modifed (rotated, mirrored, converted...).

I also see this delay when entering or leaving a hierarchical sheet.

For large designs, this could be blocking.
Perhaps the immediate update could be disabled (option?) for large designs.

(Jon already knows that)


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

Jon,

I wanted to test complex hierarchy bus net connections which I just
haven't had time to look at.  JP, did you check this during your
testing?  If so and you didn't find any issues, then I will merge this
as soon as I get a chance.  If not, then I would like to test this and
make sure there are no issues before we merge it.

Cheers,

Wayne

On 3/29/2019 11:54 PM, Jon Evans wrote:
> Has anyone else been doing any testing?  I have resolved some issues
> that JP found, but haven't heard from anyone else.
> 
> -Jon
> 
> On Fri, Mar 22, 2019 at 5:08 PM Wayne Stambaugh  > wrote:
> 
> I did some testing and the changes appear to have resolved the original
> issues I found.  One thing I did not test was complex hierarchical bus
> expansion.  Has anyone else tested this yet?  I hope to get to it over
> the weekend.  It's definitely something that should be tested before we
> give it our final blessing.
> 
> Wayne
> 
> On 3/22/19 4:57 PM, Seth Hillbrand wrote:
> > Am 2019-03-22 16:51, schrieb Seth Hillbrand:
> >
> >> adjust but I'm seeing show stoppers.
> >
> > ** not ** seeing show stoppers.
> >
> > -S
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

Has anyone else been doing any testing?  I have resolved some issues that
JP found, but haven't heard from anyone else.

-Jon

On Fri, Mar 22, 2019 at 5:08 PM Wayne Stambaugh 
wrote:

> I did some testing and the changes appear to have resolved the original
> issues I found.  One thing I did not test was complex hierarchical bus
> expansion.  Has anyone else tested this yet?  I hope to get to it over
> the weekend.  It's definitely something that should be tested before we
> give it our final blessing.
>
> Wayne
>
> On 3/22/19 4:57 PM, Seth Hillbrand wrote:
> > Am 2019-03-22 16:51, schrieb Seth Hillbrand:
> >
> >> adjust but I'm seeing show stoppers.
> >
> > ** not ** seeing show stoppers.
> >
> > -S
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Wayne Stambaugh]

I did some testing and the changes appear to have resolved the original
issues I found.  One thing I did not test was complex hierarchical bus
expansion.  Has anyone else tested this yet?  I hope to get to it over
the weekend.  It's definitely something that should be tested before we
give it our final blessing.

Wayne

On 3/22/19 4:57 PM, Seth Hillbrand wrote:
> Am 2019-03-22 16:51, schrieb Seth Hillbrand:
> 
>> adjust but I'm seeing show stoppers.
> 
> ** not ** seeing show stoppers.
> 
> -S
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Seth Hillbrand]

Am 2019-03-22 16:51, schrieb Seth Hillbrand:


adjust but I'm seeing show stoppers.


** not ** seeing show stoppers.

-S

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Seth Hillbrand]

Am 2019-03-12 17:11, schrieb Jon Evans:

https://code.launchpad.net/~craftyjon/kicad/+git/kicad/+merge/364346

On Tue, Mar 12, 2019 at 4:32 PM Seth Hillbrand 
wrote:


Am 2019-03-11 18:03, schrieb Jon Evans:

Rebased branch is located here:
https://github.com/craftyjon/kicad/tree/bus_upgrades_merge
I've also attached a patchset for convenience.

-Jon


Hi Jon-

Any chance you could you make a launchpad branch with a merge
request
for this?  I'd like to ask some specific questions and merge request

makes that easier to clarify the question.

Thanks!
Seth


Hi All-

I've been running Jon's latest code for a few days now and haven't had 
issues.  Larger testing will likely reveal some things we want to adjust 
but I'm seeing show stoppers.


Best-
Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Jon Evans]

https://code.launchpad.net/~craftyjon/kicad/+git/kicad/+merge/364346

On Tue, Mar 12, 2019 at 4:32 PM Seth Hillbrand  wrote:

> Am 2019-03-11 18:03, schrieb Jon Evans:
> > Rebased branch is located here:
> > https://github.com/craftyjon/kicad/tree/bus_upgrades_merge
> > I've also attached a patchset for convenience.
> >
> > -Jon
>
> Hi Jon-
>
> Any chance you could you make a launchpad branch with a merge request
> for this?  I'd like to ask some specific questions and merge request
> makes that easier to clarify the question.
>
> Thanks!
> Seth
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge

[Seth Hillbrand]

Am 2019-03-11 18:03, schrieb Jon Evans:

Rebased branch is located here:
https://github.com/craftyjon/kicad/tree/bus_upgrades_merge
I've also attached a patchset for convenience.

-Jon


Hi Jon-

Any chance you could you make a launchpad branch with a merge request 
for this?  I'd like to ask some specific questions and merge request 
makes that easier to clarify the question.


Thanks!
Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bus upgrades merge (was: V6 merge priority)

[Wayne Stambaugh]

Jon,

On 3/11/2019 9:55 AM, Jon Evans wrote:
> Hi Wayne,
> 
> I will rebase and post an updated branch soon.

Thanks!  I should have time to review and test this weekend.

> I will also generally be available to fix any bugs although will be
> offline for a few days at a time here and there for travel.
> 
> If you would prefer, I could put the bus aliases feature behind a flag
> so that it is effectively disabled, and then bring it back with the new
> file format.  I'm not sure whether or not that would be easier than
> adding the field to the old format before you start work on the new format.

I appreciate the offer but I don't think this will be necessary.  It's
going to be a while before I get around to coding the schematic file
format.  It will give users a chance to test the new feature and get it
stabilized before I merge it into the new file format.  I have a bunch
of under the hood stuff to change (units and inheritance) and the new
symbol library file format before I start on the new schematic file format.

> 
> -Jon
> 
> On Mon, Mar 11, 2019 at 8:54 AM Wayne Stambaugh  > wrote:
> 
> Hey Jon,
> 
> On 3/9/2019 5:58 PM, Jon Evans wrote:
> > Hi Wayne and the rest of the team,
> >
> > My code is located here:
> > https://github.com/craftyjon/kicad/tree/bus_upgrades
> > (I can rebase/format this as a patchset to make review easier if
> needed)
> 
> Please rebase it when you get a chance.  It certainly will be easier to
> review and merge when it's rebased against the latest changes in the dev
> branch.
> 
> >
> > Documentation updates are in this branch:
> > https://github.com/craftyjon/kicad-doc/tree/bus_upgrades
> >
> > Unfortunately, I've been very busy in the past few months and have not
> > had time to perform regular testing of my branch beyond checking
> that it
> > compiles as I merge upstream changes into it.
> > Since the branch has been feature complete for some time now, I would
> > not be terribly surprised if a bug or two has crept in due to the rest
> > of the code moving forward.
> 
> Once I merge this, will you be available to fix bugs as the pop up?
> Until the rest of the team understands your code, you will be the best
> candidate to get bugs fixed quickly.
> 
> >
> > Please be aware that this branch contains an entirely new netlist
> > generator in order to support the new features.
> > This is exciting for the speed and feature improvements it makes
> > possible, but scary because of the consequences of getting
> anything wrong!
> > I have put in place a quality control check
> > (see NETLIST_EXPORTER_KICAD::WriteNetlist) that attempts to catch any
> > corner cases that I have not found already where the new algorithm is
> > inconsistent from the old, but there is always room for error here.
> > My thoughts were to keep in this code in master for some period of
> time
> > after merge, and then disable it or put it behind some flag after we
> > have more confidence in the new algorithm.  I welcome other
> suggestions
> > here.
> > I would like it to get more visibility and testing so that any defects
> > can be corrected before merge, so that people who run nightly builds
> > don't suffer unnecessarily.
> 
> I will build and test your code as soon as you get it rebased.  If any
> of the other devs have time to test this, I would appreciate and extra
> set of eyes on this code.  It has the potential to be really disruptive
> so the more testing we can get up front, the better.
> 
> > The new netlist exporter has also only been implemented for the KiCad
> > netlist format (not OrCad / CadStar / PSpice) as I wanted to get
> > review/approval of the new system before converting over the other
> > exporters.
> >
> > It's also worth noting that one of the new features does introduce a
> > schematic file format addition (bus aliases).
> > It would be possible to rip out this portion of the changes and
> stage it
> > for later merge if that were desirable.
> 
> I forgot about the bus aliases changes.  I really wanted to avoid making
> changes to the existing schematic file format if possible.  Given that
> your work is done and I haven't even started working on the new file
> format code, I'm willing to accept this change and update the new
> schematic file format accordingly.
> 
> >
> > Best,
> > Jon
> >
> > On Sat, Mar 9, 2019 at 2:42 PM jp charras  
> > >> wrote:
> >
> >     Le 09/03/2019 à 19:03, Wayne Stambaugh a écrit :
> >     > Rather than try to figure out every possible merge
> combination, I'm
> >     > going to prioritize things serially per editor.  The highest
>  

Re: [Kicad-developers] Bus upgrades merge (was: V6 merge priority)

[Nick Østergaard]

If you do decide to merge but disable by default, please consider to use
the kicad_advanced config.

man. 11. mar. 2019 15.06 skrev Jon Evans :

> Hi Wayne,
>
> I will rebase and post an updated branch soon.
> I will also generally be available to fix any bugs although will be
> offline for a few days at a time here and there for travel.
>
> If you would prefer, I could put the bus aliases feature behind a flag so
> that it is effectively disabled, and then bring it back with the new file
> format.  I'm not sure whether or not that would be easier than adding the
> field to the old format before you start work on the new format.
>
> -Jon
>
> On Mon, Mar 11, 2019 at 8:54 AM Wayne Stambaugh 
> wrote:
>
>> Hey Jon,
>>
>> On 3/9/2019 5:58 PM, Jon Evans wrote:
>> > Hi Wayne and the rest of the team,
>> >
>> > My code is located here:
>> > https://github.com/craftyjon/kicad/tree/bus_upgrades
>> > (I can rebase/format this as a patchset to make review easier if needed)
>>
>> Please rebase it when you get a chance.  It certainly will be easier to
>> review and merge when it's rebased against the latest changes in the dev
>> branch.
>>
>> >
>> > Documentation updates are in this branch:
>> > https://github.com/craftyjon/kicad-doc/tree/bus_upgrades
>> >
>> > Unfortunately, I've been very busy in the past few months and have not
>> > had time to perform regular testing of my branch beyond checking that it
>> > compiles as I merge upstream changes into it.
>> > Since the branch has been feature complete for some time now, I would
>> > not be terribly surprised if a bug or two has crept in due to the rest
>> > of the code moving forward.
>>
>> Once I merge this, will you be available to fix bugs as the pop up?
>> Until the rest of the team understands your code, you will be the best
>> candidate to get bugs fixed quickly.
>>
>> >
>> > Please be aware that this branch contains an entirely new netlist
>> > generator in order to support the new features.
>> > This is exciting for the speed and feature improvements it makes
>> > possible, but scary because of the consequences of getting anything
>> wrong!
>> > I have put in place a quality control check
>> > (see NETLIST_EXPORTER_KICAD::WriteNetlist) that attempts to catch any
>> > corner cases that I have not found already where the new algorithm is
>> > inconsistent from the old, but there is always room for error here.
>> > My thoughts were to keep in this code in master for some period of time
>> > after merge, and then disable it or put it behind some flag after we
>> > have more confidence in the new algorithm.  I welcome other suggestions
>> > here.
>> > I would like it to get more visibility and testing so that any defects
>> > can be corrected before merge, so that people who run nightly builds
>> > don't suffer unnecessarily.
>>
>> I will build and test your code as soon as you get it rebased.  If any
>> of the other devs have time to test this, I would appreciate and extra
>> set of eyes on this code.  It has the potential to be really disruptive
>> so the more testing we can get up front, the better.
>>
>> > The new netlist exporter has also only been implemented for the KiCad
>> > netlist format (not OrCad / CadStar / PSpice) as I wanted to get
>> > review/approval of the new system before converting over the other
>> > exporters.
>> >
>> > It's also worth noting that one of the new features does introduce a
>> > schematic file format addition (bus aliases).
>> > It would be possible to rip out this portion of the changes and stage it
>> > for later merge if that were desirable.
>>
>> I forgot about the bus aliases changes.  I really wanted to avoid making
>> changes to the existing schematic file format if possible.  Given that
>> your work is done and I haven't even started working on the new file
>> format code, I'm willing to accept this change and update the new
>> schematic file format accordingly.
>>
>> >
>> > Best,
>> > Jon
>> >
>> > On Sat, Mar 9, 2019 at 2:42 PM jp charras > > > wrote:
>> >
>> > Le 09/03/2019 à 19:03, Wayne Stambaugh a écrit :
>> > > Rather than try to figure out every possible merge combination,
>> I'm
>> > > going to prioritize things serially per editor.  The highest
>> priority
>> > > are changes those that will or potentially impact later features.
>> > >
>> > > Jon's netlist work would be the obvious candidate for the
>> schematic
>> > > editor.  Jon, please post the url of your git repo so we can
>> > review the
>> > > your changes.
>> > >
>> > > JP, don't you have some new pad work queued up?  I would think
>> this
>> > > would impact things like Tom's router improvements.  If so, then
>> this
>> > > should be the first board editor change that gets merged.  I would
>> > like
>> > > to take a look at the changes before we merge this.
>> > >
>> > > Once things stabilize, I will open up the next two feature merges.
>> > >