Re: [Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

[Mark Roszko]

I can't see the pictures even on the non-proxied pages. It seems the build
job for doxygen isn't uploading them? That's a thing for Nick.

On Fri, Apr 5, 2019 at 9:51 PM Andrew Lutsenko  wrote:

> Thanks. When does it take effect? I'm still seeing 404.
> Also some pictures are not visible in the docs url that your commit
> proxy-passes to, like the object inheritance graph here
>
> https://kicad-downloads.s3.cern.ch/doxygen-python/classpcbnew_1_1BOARD__ITEM.html
>
> On Fri, Apr 5, 2019 at 6:42 PM Mark Roszko  wrote:
>
>> Fixed
>> https://github.com/KiCad/kicad-doc-website/commit/67d881642f96d587af3a8730dae54901238d5521
>>
>>
>> On Fri, Apr 5, 2019 at 6:36 PM Andrew Lutsenko 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct
>>> link to python api docs but all google searches point there and it's
>>> referenced  here
>>> .
>>> If they moved somewhere else there should be a 301 permanent redirect so
>>> that search engines eventually catch up.
>>>
>>> Regards,
>>> Andrew
>>>
>>> ___
>>> 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
>>>
>>
>>
>> --
>> Mark
>>
>

-- 
Mark
___
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] 404 on docs.kicad-pcb.org/doxygen-python/

[Andrew Lutsenko]

Thanks. When does it take effect? I'm still seeing 404.
Also some pictures are not visible in the docs url that your commit
proxy-passes to, like the object inheritance graph here
https://kicad-downloads.s3.cern.ch/doxygen-python/classpcbnew_1_1BOARD__ITEM.html

On Fri, Apr 5, 2019 at 6:42 PM Mark Roszko  wrote:

> Fixed
> https://github.com/KiCad/kicad-doc-website/commit/67d881642f96d587af3a8730dae54901238d5521
>
>
> On Fri, Apr 5, 2019 at 6:36 PM Andrew Lutsenko 
> wrote:
>
>> Hi all,
>>
>> I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct
>> link to python api docs but all google searches point there and it's
>> referenced  here
>> .
>> If they moved somewhere else there should be a 301 permanent redirect so
>> that search engines eventually catch up.
>>
>> Regards,
>> Andrew
>>
>> ___
>> 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
>>
>
>
> --
> Mark
>
___
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] 404 on docs.kicad-pcb.org/doxygen-python/

[Mark Roszko]

Fixed
https://github.com/KiCad/kicad-doc-website/commit/67d881642f96d587af3a8730dae54901238d5521


On Fri, Apr 5, 2019 at 6:36 PM Andrew Lutsenko  wrote:

> Hi all,
>
> I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct
> link to python api docs but all google searches point there and it's
> referenced  here
> .
> If they moved somewhere else there should be a 301 permanent redirect so
> that search engines eventually catch up.
>
> Regards,
> Andrew
>
> ___
> 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
>


-- 
Mark
___
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

[Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

[Andrew Lutsenko]

Hi all,

I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct link
to python api docs but all google searches point there and it's referenced
here
.
If they moved somewhere else there should be a 301 permanent redirect so
that search engines eventually catch up.

Regards,
Andrew
___
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] Possible error in project loading

[Wayne Stambaugh]

Hey Jeff,

Oh my!  This is embarrassing since git blamed me.  That should indeed be
ConfigSave().  It looks like a copy and past error on my part.  Nice catch.

Cheers,

Wayne

On 4/5/19 3:34 PM, Jeff Young wrote:
> Hi Wayne,
> 
> Could you take a look at lines 75:77 in prjconfig.cpp:
> 
> // Save the project file for the currently loaded project.
> if( m_active_project )
> Prj().ConfigLoad( PgmTop().SysSearch(), GeneralGroupName, 
> s_KicadManagerParams );
> 
> 
> If the comment is correct that should be ConfigSave(), not ConfigLoad(),
> right?
> 
> 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

[Kicad-developers] Possible error in project loading

[Jeff Young]

Hi Wayne,

Could you take a look at lines 75:77 in prjconfig.cpp:

// Save the project file for the currently loaded project.
if( m_active_project )
Prj().ConfigLoad( PgmTop().SysSearch(), GeneralGroupName, 
s_KicadManagerParams );

If the comment is correct that should be ConfigSave(), not ConfigLoad(), right?

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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Andy Peters]

> On Apr 4, 2019, at 5:16 PM, Tomasz Wlostowski  
> wrote:
> 
> Hi,
> 
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.

Total wishlist here, but how about implementing a signal-integrity simulator in 
Kicad?

I realize this is like wishing for the moon.

-a
___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Wayne Stambaugh]

Tom,

On 4/5/19 12:41 PM, Wayne Stambaugh wrote:
> On 4/5/19 12:24 PM, Tomasz Wlostowski wrote:
>> On 05/04/2019 18:04, Wayne Stambaugh wrote:
>>> Tom,
>>>
>>> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
 Hi,

 We needed to do some signal/power integrity simulations on one of our
 Kicad designs and in order to do that, we needed to convert a Kicad PCB
 to Hyperlynx format. Luckily, the format is simple, all text and well
 documented in [1], so here comes a patch that adds a Hyperlynx exporter.

 Notes:
 - since Kicad doesn't have a concept of board stackup (permittivities,
 loss tangent, dielectric types, etc.), the exporter writes a dummy
 stackup. Edit it to match the PCB spec in Hyperlynx.
 - no support for offset pad holes, slotted pad holes,
 trapezoid/polygonal pads (it seems HL format doesn't support such
 features or I need to figure out how to emulate them).
 - no support for thermal pads (yet)
 - no error reporting.

 Looking forward to your feedback & wish you happy testing,
 Tom

 [1] http://www.ibis.org/birds/bird33.txt
>>>
>>> Your patch built and tested without issue.  I just have a few minor
>>> comments:
>>>
>>> Please remove all commented out debugging output code and one instance
>>> of wxLogDebug unless you are planning to some additional debugging in
>>> the future.  In which case, use wxLogTrace.
>>>
>>> Per section 4.2 in the coding policy[1], in source files there should be
>>> 2 blank lines between functions except when they are in the class
>>> definition in which case there should be 1 blank line.  I also saw a
>>> couple of if{} statements with missing blank lines above.
>>>
>>> It is no longer necessary to wrap strings with the wxT() macro when
>>> using the wxString assignment operator.
>>>
>>> The OUPUTFORMATTER::Print function can throw an IO_ERROR exception.  If
>>> you don't handle this, KiCad will most likely crash when it occurs.  It
>>> would be a good idea to add a try/catch block in
>>> HYPERLYNX_EXPORTER::Run() and return false when a exception is caught.
>>>
>>> The copyright dates in the qa files are 2018.
>>
>> Thanks Wayne,
>>
>> It looks my settings for VSCode formatter don't catch all Kicad Coding
>> Style rules. Need to fix that ;-). I'll push a version with fixes
>> (including error handling via exceptions).
>>
>> Tom
>>
>> PS. We need to think about factoring out the exporters (including their
>> private settings dialogs) to some sort of plugins...
>>
> 
> A plugin architecture for board exporters is a great idea.  This would
> be an ideal candidate for a true external plugin architecture similar to
> the 3D model plugin.  Maybe there is code that can be factored out into
> a base external plugin object that can be reused for other plugins.
> 
> Wayne
> 

One other thing I noticed is it looks like the VSCode formatter is
wrapping at 100.  The coding policy states 99 so you might want to
change your formatter settings.  There were a few places in your patch
where I noticed that the code wrapped by exactly one character.

___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Wayne Stambaugh]

On 4/5/19 12:24 PM, Tomasz Wlostowski wrote:
> On 05/04/2019 18:04, Wayne Stambaugh wrote:
>> Tom,
>>
>> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
>>> Hi,
>>>
>>> We needed to do some signal/power integrity simulations on one of our
>>> Kicad designs and in order to do that, we needed to convert a Kicad PCB
>>> to Hyperlynx format. Luckily, the format is simple, all text and well
>>> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
>>>
>>> Notes:
>>> - since Kicad doesn't have a concept of board stackup (permittivities,
>>> loss tangent, dielectric types, etc.), the exporter writes a dummy
>>> stackup. Edit it to match the PCB spec in Hyperlynx.
>>> - no support for offset pad holes, slotted pad holes,
>>> trapezoid/polygonal pads (it seems HL format doesn't support such
>>> features or I need to figure out how to emulate them).
>>> - no support for thermal pads (yet)
>>> - no error reporting.
>>>
>>> Looking forward to your feedback & wish you happy testing,
>>> Tom
>>>
>>> [1] http://www.ibis.org/birds/bird33.txt
>>
>> Your patch built and tested without issue.  I just have a few minor
>> comments:
>>
>> Please remove all commented out debugging output code and one instance
>> of wxLogDebug unless you are planning to some additional debugging in
>> the future.  In which case, use wxLogTrace.
>>
>> Per section 4.2 in the coding policy[1], in source files there should be
>> 2 blank lines between functions except when they are in the class
>> definition in which case there should be 1 blank line.  I also saw a
>> couple of if{} statements with missing blank lines above.
>>
>> It is no longer necessary to wrap strings with the wxT() macro when
>> using the wxString assignment operator.
>>
>> The OUPUTFORMATTER::Print function can throw an IO_ERROR exception.  If
>> you don't handle this, KiCad will most likely crash when it occurs.  It
>> would be a good idea to add a try/catch block in
>> HYPERLYNX_EXPORTER::Run() and return false when a exception is caught.
>>
>> The copyright dates in the qa files are 2018.
> 
> Thanks Wayne,
> 
> It looks my settings for VSCode formatter don't catch all Kicad Coding
> Style rules. Need to fix that ;-). I'll push a version with fixes
> (including error handling via exceptions).
> 
> Tom
> 
> PS. We need to think about factoring out the exporters (including their
> private settings dialogs) to some sort of plugins...
> 

A plugin architecture for board exporters is a great idea.  This would
be an ideal candidate for a true external plugin architecture similar to
the 3D model plugin.  Maybe there is code that can be factored out into
a base external plugin object that can be reused for other plugins.

Wayne

___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 18:04, Wayne Stambaugh wrote:
> Tom,
> 
> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> We needed to do some signal/power integrity simulations on one of our
>> Kicad designs and in order to do that, we needed to convert a Kicad PCB
>> to Hyperlynx format. Luckily, the format is simple, all text and well
>> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
>>
>> Notes:
>> - since Kicad doesn't have a concept of board stackup (permittivities,
>> loss tangent, dielectric types, etc.), the exporter writes a dummy
>> stackup. Edit it to match the PCB spec in Hyperlynx.
>> - no support for offset pad holes, slotted pad holes,
>> trapezoid/polygonal pads (it seems HL format doesn't support such
>> features or I need to figure out how to emulate them).
>> - no support for thermal pads (yet)
>> - no error reporting.
>>
>> Looking forward to your feedback & wish you happy testing,
>> Tom
>>
>> [1] http://www.ibis.org/birds/bird33.txt
> 
> Your patch built and tested without issue.  I just have a few minor
> comments:
> 
> Please remove all commented out debugging output code and one instance
> of wxLogDebug unless you are planning to some additional debugging in
> the future.  In which case, use wxLogTrace.
> 
> Per section 4.2 in the coding policy[1], in source files there should be
> 2 blank lines between functions except when they are in the class
> definition in which case there should be 1 blank line.  I also saw a
> couple of if{} statements with missing blank lines above.
> 
> It is no longer necessary to wrap strings with the wxT() macro when
> using the wxString assignment operator.
> 
> The OUPUTFORMATTER::Print function can throw an IO_ERROR exception.  If
> you don't handle this, KiCad will most likely crash when it occurs.  It
> would be a good idea to add a try/catch block in
> HYPERLYNX_EXPORTER::Run() and return false when a exception is caught.
> 
> The copyright dates in the qa files are 2018.

Thanks Wayne,

It looks my settings for VSCode formatter don't catch all Kicad Coding
Style rules. Need to fix that ;-). I'll push a version with fixes
(including error handling via exceptions).

Tom

PS. We need to think about factoring out the exporters (including their
private settings dialogs) to some sort of plugins...




___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Wayne Stambaugh]

Tom,

On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
> Hi,
> 
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
> 
> Notes:
> - since Kicad doesn't have a concept of board stackup (permittivities,
> loss tangent, dielectric types, etc.), the exporter writes a dummy
> stackup. Edit it to match the PCB spec in Hyperlynx.
> - no support for offset pad holes, slotted pad holes,
> trapezoid/polygonal pads (it seems HL format doesn't support such
> features or I need to figure out how to emulate them).
> - no support for thermal pads (yet)
> - no error reporting.
> 
> Looking forward to your feedback & wish you happy testing,
> Tom
> 
> [1] http://www.ibis.org/birds/bird33.txt

Your patch built and tested without issue.  I just have a few minor
comments:

Please remove all commented out debugging output code and one instance
of wxLogDebug unless you are planning to some additional debugging in
the future.  In which case, use wxLogTrace.

Per section 4.2 in the coding policy[1], in source files there should be
2 blank lines between functions except when they are in the class
definition in which case there should be 1 blank line.  I also saw a
couple of if{} statements with missing blank lines above.

It is no longer necessary to wrap strings with the wxT() macro when
using the wxString assignment operator.

The OUPUTFORMATTER::Print function can throw an IO_ERROR exception.  If
you don't handle this, KiCad will most likely crash when it occurs.  It
would be a good idea to add a try/catch block in
HYPERLYNX_EXPORTER::Run() and return false when a exception is caught.

The copyright dates in the qa files are 2018.

[1]:http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#blank_lines

___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[John Beard]

Hi Tom,

Ah right. I thought that was a unit test at first because it's under
the "unit tests" section of the Cmake. I don't think it's useless to
have it, as it provides an easy hook for quick testing. Clicking
though the GUI is certainly painful! Since your test is actually a
"utility tool" rather than a unit test, maybe a tool in
qa/pcbnew_tools?

So: qa/pcbnew_tools/tools/hyperlynx_export.cpp

Also would need some command line handling (in and out file, at
least). This avoids expanding build times too much, as you're only
adding a single cpp to the tools executable, not a whole new
statically-linked executable.

Cheers,

John

On Fri, Apr 5, 2019 at 3:55 PM Tomasz Wlostowski
 wrote:
>
> On 05/04/2019 16:48, John Beard wrote:
> > Hi Tom,
> >
> > Can the hyperlink export test not exist in the existing qa_pcbnew
> > test? The code is all in pcbnew's library, so why not just mirror the
> > source layout and put your test as
> > "qa/pcbnew/exporters/test_export_hyperlynx.cpp"?
> >
> > Otherwise we will eventually have dozens and dozens of tiny unit test
> > executables all in need of CMake files and linking.
> >
> > OTOH, if the hyperlynx stuff was a separate library, then it would
> > make sense to have a separate test exec. At that point, we'd
> > presumably have shared libs anyway.
>
> Hi John,
>
> It's just my internal test program that I accidentally put in the patch.
> I don't like clicking through the pcbnew GUI just to test the exporter.
> There's no formal unit tests for the exporter yet, I'll remove it from
> the final commit.
>
> 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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 16:48, John Beard wrote:
> Hi Tom,
> 
> Can the hyperlink export test not exist in the existing qa_pcbnew
> test? The code is all in pcbnew's library, so why not just mirror the
> source layout and put your test as
> "qa/pcbnew/exporters/test_export_hyperlynx.cpp"?
> 
> Otherwise we will eventually have dozens and dozens of tiny unit test
> executables all in need of CMake files and linking.
> 
> OTOH, if the hyperlynx stuff was a separate library, then it would
> make sense to have a separate test exec. At that point, we'd
> presumably have shared libs anyway.

Hi John,

It's just my internal test program that I accidentally put in the patch.
I don't like clicking through the pcbnew GUI just to test the exporter.
There's no formal unit tests for the exporter yet, I'll remove it from
the final commit.

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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[John Beard]

Hi Tom,

Can the hyperlink export test not exist in the existing qa_pcbnew
test? The code is all in pcbnew's library, so why not just mirror the
source layout and put your test as
"qa/pcbnew/exporters/test_export_hyperlynx.cpp"?

Otherwise we will eventually have dozens and dozens of tiny unit test
executables all in need of CMake files and linking.

OTOH, if the hyperlynx stuff was a separate library, then it would
make sense to have a separate test exec. At that point, we'd
presumably have shared libs anyway.

Cheers,

John

On Fri, Apr 5, 2019 at 1:16 AM Tomasz Wlostowski
 wrote:
>
> Hi,
>
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
>
> Notes:
> - since Kicad doesn't have a concept of board stackup (permittivities,
> loss tangent, dielectric types, etc.), the exporter writes a dummy
> stackup. Edit it to match the PCB spec in Hyperlynx.
> - no support for offset pad holes, slotted pad holes,
> trapezoid/polygonal pads (it seems HL format doesn't support such
> features or I need to figure out how to emulate them).
> - no support for thermal pads (yet)
> - no error reporting.
>
> Looking forward to your feedback & wish you happy testing,
> Tom
>
> [1] http://www.ibis.org/birds/bird33.txt
> ___
> 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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Wayne Stambaugh]

Tom,

On 4/5/19 10:40 AM, Tomasz Wlostowski wrote:
> On 05/04/2019 02:16, Tomasz Wlostowski wrote:
>> Hi,
>>
>> We needed to do some signal/power integrity simulations on one of our
>> Kicad designs and in order to do that, we needed to convert a Kicad PCB
>> to Hyperlynx format. Luckily, the format is simple, all text and well
>> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
> 
> Anybody opposed to merging this?
> 
> Tom
> 

Please give me a chance to a least review and test the.  I should be
able to take a look at by the end of the day.

Cheers,

Wayne

___
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] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 02:16, Tomasz Wlostowski wrote:
> Hi,
> 
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.

Anybody opposed to merging this?

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] "auto" policy

[Jon Evans]

This all sounds good to me.  I'm the author of that offending line and am
happy to update my code accordingly.

-Jon

On Fri, Apr 5, 2019 at 8:58 AM Wayne Stambaugh  wrote:

>
> On 4/5/19 6:39 AM, Jeff Young wrote:
> > Do we have a policy on when to use auto?
>
> No but we should create one since I'm seeing it being used fairly often.
>
> >
> > Personally, I like it when it removes repetition.  For instance:
> >
> > auto pin = new SCH_PIN();
>
> I'm fine with this since the type is obvious.
>
> >
> >
> > And I like it when it removes stupid template things like std::pair<>:
> >
> > for( auto it : my_unordered_map )
>
> I'm fine with this as well since an iterator is implied and life is too
> short to be typing out iterator types.
>
> >
> >
> > But I don’t like it in other cases.  This reduces readability for me:
> >
> > auto pos = pin->GetPosition();
>
> I don't like this either.  I have no idea what type GetPosition()
> returns and I really don't want to have to look it up.
>
> >
> >
> > However, I’m just one voice, and the idea of when something is a “stupid
> > template thing” and when it isn’t is admittedly pretty ill-defined.
> >
> > How do others feel?
> >
> > 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
>
___
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] Auto zoom-to-fit and the symbol editor

[Wayne Stambaugh]

This seems like a perfectly acceptable solution to me.  You may also
want to add this option to the symbol viewer as well.  I'm sure someone
will request that as well.

On 4/5/19 9:08 AM, John Beard wrote:
> Hi Jeff,
> 
> I think the current default is somewhat reasonable. If editing a
> multi-unit part with substantially similar units, you are probably as
> likely to want to keep your current zoom as reset it. And zoom reset
> is a single keypress for when it isn't.
> 
> As this is likely to be one of those things which have opposing camps
> based on the library in question and the workflows, having a way to
> configure it seems to me uncontroversial. There is probably space for
> a button, but perhaps just a prefs UI will do (and then you can have
> independent zoom lock for "symbol change" and "unit change
> separately")?
> 
> Cheers,
> 
> John
> 
> 
> 
> On Fri, Apr 5, 2019 at 1:16 PM Jeff Young  wrote:
>>
>> When picking a new symbol we zoom-to-fit it.  However, when picking a 
>> different unit of the symbol being edited we don’t.
>>
>> A user has complained about this[1].  However, it’s not clear to me on 
>> balance which would be better.  If you had a large symbol and were zoomed in 
>> on a particular area and needed to edit that area in multiple units, and 
>> auto-zoom-to-fit might be very annoying.  On the other hand, if one unit has 
>> stuff outside the bounding box of other units you might miss that.
>>
>> Opinions on which would be better?
>>
>> Cheers,
>> Jeff.
>>
>> [1] https://bugs.launchpad.net/kicad/+bug/1823180
>> ___
>> 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] Auto zoom-to-fit and the symbol editor

[John Beard]

Hi Jeff,

I think the current default is somewhat reasonable. If editing a
multi-unit part with substantially similar units, you are probably as
likely to want to keep your current zoom as reset it. And zoom reset
is a single keypress for when it isn't.

As this is likely to be one of those things which have opposing camps
based on the library in question and the workflows, having a way to
configure it seems to me uncontroversial. There is probably space for
a button, but perhaps just a prefs UI will do (and then you can have
independent zoom lock for "symbol change" and "unit change
separately")?

Cheers,

John



On Fri, Apr 5, 2019 at 1:16 PM Jeff Young  wrote:
>
> When picking a new symbol we zoom-to-fit it.  However, when picking a 
> different unit of the symbol being edited we don’t.
>
> A user has complained about this[1].  However, it’s not clear to me on 
> balance which would be better.  If you had a large symbol and were zoomed in 
> on a particular area and needed to edit that area in multiple units, and 
> auto-zoom-to-fit might be very annoying.  On the other hand, if one unit has 
> stuff outside the bounding box of other units you might miss that.
>
> Opinions on which would be better?
>
> Cheers,
> Jeff.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1823180
> ___
> 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] "auto" policy

[Wayne Stambaugh]

On 4/5/19 6:39 AM, Jeff Young wrote:
> Do we have a policy on when to use auto?

No but we should create one since I'm seeing it being used fairly often.

> 
> Personally, I like it when it removes repetition.  For instance:
> 
>     auto pin = new SCH_PIN();  

I'm fine with this since the type is obvious.

> 
> 
> And I like it when it removes stupid template things like std::pair<>:
> 
>     for( auto it : my_unordered_map )

I'm fine with this as well since an iterator is implied and life is too
short to be typing out iterator types.

> 
> 
> But I don’t like it in other cases.  This reduces readability for me:
> 
>     auto pos = pin->GetPosition();

I don't like this either.  I have no idea what type GetPosition()
returns and I really don't want to have to look it up.

> 
> 
> However, I’m just one voice, and the idea of when something is a “stupid
> template thing” and when it isn’t is admittedly pretty ill-defined.
> 
> How do others feel?
> 
> 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] Merge schedule

[Wayne Stambaugh]

Jeff,

I can't think of any reason not to clean up the SCH_ and LIB_ Draw()
routines unless I'm missing something.  It might be useful to merge this
to the 5.1 branch once it is proven to be stable.  This will help keep
merge conflicts to a minimum.

Wayne

On 4/5/19 6:09 AM, Jeff Young wrote:
> I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw() 
> routines to remove the interactivity features (since they’re now print-only).
> 
> Should I merge it now?
> 
> Cheers,
> Jeff.
> 
> https://git.launchpad.net/~jeyjey/kicad/commit/?id=ef6b71b3335080a5e3c4cd98e70d42f2f8f1132f
> ___
> 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] "auto" policy

[John Beard]

Hi,

I think auto is useful when it avoids repetition of useless things,
and doubly so for things where the type is unwieldy, like iterators,
and, particularly, lambdas. For example:

auto up = std::make_unique( ... ); // or make_shared
auto it = aVec.begin(); // or cbegin or returns from std::find, etc
auto lambda = []() { return 42; }; // only Cthulu knows how to type this
for( const auto& x : container ); // where x is not a "usual" type,
and not immediately clear
auto& item = static_cast( other ); // ITEM& is clearly the type here

For places were the type is *not* obvious from the immediate context
(probably the same line), I do not suggest auto. Basically any where
you'd need to check the function signature. (I am probably guilty a
few of these):

auto x = item.GetX(); // what is X? int? float? double? type-safe
dimension? a class?

Also I think that if we are putting a pointer in an auto, we should
use the "star" to make this clear, as KiCad (IMO rightfully) does not
make pointer-ness clear with something like Hungarian notation. I.e.
"plain auto" means "a thing", for example, int, a class, or
std::unique_ptr. "auto*" means a pointer and "auto&" is a reference to
a thing.

auto* newed = new TYPE(); // but prefer unique_ptr where sensible
auto* item = thing.GetItem(); // this could be null
auto& thing = thing.GetThing(); // this definitely exists

I think there is a (weak) case to be made for the following
construction, which disallows uninitialised variables, but "looks
funny":

auto x = size_t{ 42 };
size_t x = 42; // can lose "= 42" and still compile.

But compilers and static analysers are usually fairly "on it" with
uninitialised variables these days, so it's not that exciting, and
it's certainly not a common idiom.

TL;DR, IMO, use auto only when it is clearer than writing the type out.

Cheers,

John

On Fri, Apr 5, 2019 at 12:00 PM jp charras  wrote:
>
> Le 05/04/2019 à 12:39, Jeff Young a écrit :
> > Do we have a policy on when to use auto?
> >
> > Personally, I like it when it removes repetition.  For instance:
> >
> > auto pin = new SCH_PIN();
> >
> >
> > And I like it when it removes stupid template things like std::pair<>:
> >
> > for( auto it : my_unordered_map )
> >
> >
> > But I don’t like it in other cases.  This reduces readability for me:
> >
> > auto pos = pin->GetPosition();
> >
> >
> > However, I’m just one voice, and the idea of when something is a “stupid
> > template thing” and when it isn’t is admittedly pretty ill-defined.
> >
> > How do others feel?
> >
> > Cheers,
> > Jeff.
>
> I am thinking auto should be not used for basic types (bool, int ...)
> and very usual types (wxPoint, wxString, std::string) because it
> obfuscate these types without benefit.
> Of course, obfuscation depends of the context.
>
> But I agree it is really very useful for iterators.
>
> --
> 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

___
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

[Kicad-developers] Auto zoom-to-fit and the symbol editor

[Jeff Young]

When picking a new symbol we zoom-to-fit it.  However, when picking a different 
unit of the symbol being edited we don’t.

A user has complained about this[1].  However, it’s not clear to me on balance 
which would be better.  If you had a large symbol and were zoomed in on a 
particular area and needed to edit that area in multiple units, and 
auto-zoom-to-fit might be very annoying.  On the other hand, if one unit has 
stuff outside the bounding box of other units you might miss that.

Opinions on which would be better?

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1823180
___
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] "auto" policy

[jp charras]

Le 05/04/2019 à 12:39, Jeff Young a écrit :
> Do we have a policy on when to use auto?
> 
> Personally, I like it when it removes repetition.  For instance:
> 
>     auto pin = new SCH_PIN();  
> 
> 
> And I like it when it removes stupid template things like std::pair<>:
> 
>     for( auto it : my_unordered_map )
> 
> 
> But I don’t like it in other cases.  This reduces readability for me:
> 
>     auto pos = pin->GetPosition();
> 
> 
> However, I’m just one voice, and the idea of when something is a “stupid
> template thing” and when it isn’t is admittedly pretty ill-defined.
> 
> How do others feel?
> 
> Cheers,
> Jeff.

I am thinking auto should be not used for basic types (bool, int ...)
and very usual types (wxPoint, wxString, std::string) because it
obfuscate these types without benefit.
Of course, obfuscation depends of the context.

But I agree it is really very useful for iterators.

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

[Kicad-developers] "auto" policy

[Jeff Young]

Do we have a policy on when to use auto?

Personally, I like it when it removes repetition.  For instance:

auto pin = new SCH_PIN();  


And I like it when it removes stupid template things like std::pair<>:

for( auto it : my_unordered_map )


But I don’t like it in other cases.  This reduces readability for me:

auto pos = pin->GetPosition();


However, I’m just one voice, and the idea of when something is a “stupid 
template thing” and when it isn’t is admittedly pretty ill-defined.

How do others feel?

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

[Kicad-developers] Merge schedule

[Jeff Young]

I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw() routines 
to remove the interactivity features (since they’re now print-only).

Should I merge it now?

Cheers,
Jeff.

https://git.launchpad.net/~jeyjey/kicad/commit/?id=ef6b71b3335080a5e3c4cd98e70d42f2f8f1132f
___
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