Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Nick Østergaard]

Thank you very much, I will try to remember it after the weekend.

2018-03-17 0:46 GMT+01:00 Seth Hillbrand :

> Hi Nick-
>
> I finally found a moment to figure out Docker and get this up and running
> in your build configuration.
>
> Please take a look when you have a chance and let me know if you have any
> issues with this patch.
>
> Best-
> Seth
>
> 2018-02-10 <20%2018%2002%2010> 7:12 GMT-08:00 Seth Hillbrand <
> seth.hillbr...@gmail.com>:
>
>> Nick was having an unknown issue but I haven't heard back from him on
>> whether the issue was resolved by doing a clean cmake.  If it isn't then
>> I'll need to address that.
>>
>> Nick did you have a chance to test that?
>>
>> -S
>>
>> 2018-02-10 <20%2018%2002%2010> 6:18 GMT-08:00 Wayne Stambaugh <
>> stambau...@gmail.com>:
>>
>>> Seth,
>>>
>>> What is the current status of this patch?  I would like to get it merged
>>> before rc1 so the package devs can test it.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 01/30/2018 02:12 PM, Seth Hillbrand wrote:
>>> > Nick-
>>> >
>>> > Thanks for the test.  I'm attaching revised patch that allows multiple
>>> > OpenCASCADE installations on a single machine.
>>> >
>>> > I've tested with a few different OpenCASCADE versions down to 6.8 with
>>> > no issues installed alongside OCE 0.17.  You can choose which you want
>>> > to link by using either "-DKICAD_USE_OCE" or "-DKICAD_USE_OCC".  If
>>> both
>>> > are specified, "-DKICAD_USE_OCC" will override.
>>> >
>>> > I corrected the cmake message display to be less doubled and correctly
>>> > show the library location.
>>> >
>>> > I've also added the OCC version and type to the about window version
>>> info.
>>> >
>>> > The "Based on" line was taken from
>>> > (https://github.com/FreeCAD/FreeCAD/blob/master/src/FCConfig.h) when
>>> > trying to determine how FreeCAD likes to refer to themselves.  The
>>> > actual FindOpenCascade.cmake file did not have a copyright header
>>> > attached but falls under the license from
>>> > (https://github.com/FreeCAD/FreeCAD/blob/master/COPYING).  I note
>>> that I
>>> > had it written as "FreeCAD CADx development system".  I've corrected
>>> > this to read "FreeCAD CAx development system".
>>> >
>>> > I'm not sure to what the "CheckSymbolExists" line is referring.  I
>>> don't
>>> > see it on my machine.
>>> >
>>> > -Seth
>>> >
>>> > 2018-01-29 14:30 GMT-08:00 Nick Østergaard >> > >:
>>> >
>>> > Hi Seth,
>>> >
>>> > I just took the patch for a testrun and will state some comments
>>> below.
>>> >
>>> > This looks a bit strange:
>>> >
>>> > -- Boost version: 1.66.0
>>> > -- -- OpenCASCADE Community Edition has been found.
>>> > -- -- Found OCE/OpenCASCADE version: 6.8.0
>>> > -- -- OCE/OpenCASCADE include directory:
>>> > /opt/oce/lib/oce-0.17/../../include/oce
>>> > -- -- OCE/OpenCASCADE shared libraries directory:
>>> > -- Check for installed Python Interpreter -- found
>>> >
>>> > The messages are with double -- and the shared libs.
>>> >
>>> > But an improvement with your patch over what is currently in kicad
>>> > is that it found OCE on my system without explicitly specifind
>>> > OCE_DIR. But how do I make it use OCCT when I also have OCE
>>> installed?
>>> >
>>> > What does CADx mean in that header?
>>> >
>>> > What is this about?
>>> > -- Looking for
>>> > /home/amazingdude/kicad-source-mirror/build_seths_occt_patc
>>> h_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
>>> > -- Looking for
>>> > /home/amazingdude/kicad-source-mirror/build_seths_occt_patc
>>> h_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
>>> > - not found
>>> >
>>> > I tried to test it with removing oce and just have occt installed
>>> > and got something like this:
>>> > -- Found OCC: /opt/opencascade/inc (found version "6.9.1")
>>> > -- -- Found OCE/OpenCASCADE version: 6.9.1
>>> > -- -- OCE/OpenCASCADE include directory: /opt/opencascade/inc
>>> > -- -- OCE/OpenCASCADE shared libraries directory:
>>> /opt/opencascade/lib
>>> >
>>> > It did not build against community/opencascade 6.9.1-7. I got the
>>> > following error in a clean build dir.
>>> >
>>> > $ make kicad2step -j1
>>> > [  0%] Linking CXX executable kicad2step
>>> > /usr/bin/ld: cannot find -lTKMesh
>>> > /usr/bin/ld: cannot find -lTKernel
>>> > /usr/bin/ld: cannot find -lTKG2d
>>> > /usr/bin/ld: cannot find -lTKG3d
>>> > /usr/bin/ld: cannot find -lTKMath
>>> > /usr/bin/ld: cannot find -lTKIGES
>>> > /usr/bin/ld: cannot find -lTKSTL
>>> > /usr/bin/ld: cannot find -lTKXSBase
>>> > /usr/bin/ld: cannot find -lTKBin
>>> > /usr/bin/ld: cannot find -lTKBO
>>> > /usr/bin/ld: cannot find -lTKCDF
>>> > /usr/bin/ld: cannot find -lTKBRep
>>> > /usr/bin/ld: cannot find -lTKTopAlgo
>>> > /usr/bin/ld: cannot find -lTKGeomAlgo
>>> > /usr/bin/ld: cannot find -lTKGeomBase
>>> 

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Seth Hillbrand]

Hi Nick-

I finally found a moment to figure out Docker and get this up and running
in your build configuration.

Please take a look when you have a chance and let me know if you have any
issues with this patch.

Best-
Seth

2018-02-10 7:12 GMT-08:00 Seth Hillbrand :

> Nick was having an unknown issue but I haven't heard back from him on
> whether the issue was resolved by doing a clean cmake.  If it isn't then
> I'll need to address that.
>
> Nick did you have a chance to test that?
>
> -S
>
> 2018-02-10 6:18 GMT-08:00 Wayne Stambaugh :
>
>> Seth,
>>
>> What is the current status of this patch?  I would like to get it merged
>> before rc1 so the package devs can test it.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 01/30/2018 02:12 PM, Seth Hillbrand wrote:
>> > Nick-
>> >
>> > Thanks for the test.  I'm attaching revised patch that allows multiple
>> > OpenCASCADE installations on a single machine.
>> >
>> > I've tested with a few different OpenCASCADE versions down to 6.8 with
>> > no issues installed alongside OCE 0.17.  You can choose which you want
>> > to link by using either "-DKICAD_USE_OCE" or "-DKICAD_USE_OCC".  If both
>> > are specified, "-DKICAD_USE_OCC" will override.
>> >
>> > I corrected the cmake message display to be less doubled and correctly
>> > show the library location.
>> >
>> > I've also added the OCC version and type to the about window version
>> info.
>> >
>> > The "Based on" line was taken from
>> > (https://github.com/FreeCAD/FreeCAD/blob/master/src/FCConfig.h) when
>> > trying to determine how FreeCAD likes to refer to themselves.  The
>> > actual FindOpenCascade.cmake file did not have a copyright header
>> > attached but falls under the license from
>> > (https://github.com/FreeCAD/FreeCAD/blob/master/COPYING).  I note that
>> I
>> > had it written as "FreeCAD CADx development system".  I've corrected
>> > this to read "FreeCAD CAx development system".
>> >
>> > I'm not sure to what the "CheckSymbolExists" line is referring.  I don't
>> > see it on my machine.
>> >
>> > -Seth
>> >
>> > 2018-01-29 14:30 GMT-08:00 Nick Østergaard > > >:
>> >
>> > Hi Seth,
>> >
>> > I just took the patch for a testrun and will state some comments
>> below.
>> >
>> > This looks a bit strange:
>> >
>> > -- Boost version: 1.66.0
>> > -- -- OpenCASCADE Community Edition has been found.
>> > -- -- Found OCE/OpenCASCADE version: 6.8.0
>> > -- -- OCE/OpenCASCADE include directory:
>> > /opt/oce/lib/oce-0.17/../../include/oce
>> > -- -- OCE/OpenCASCADE shared libraries directory:
>> > -- Check for installed Python Interpreter -- found
>> >
>> > The messages are with double -- and the shared libs.
>> >
>> > But an improvement with your patch over what is currently in kicad
>> > is that it found OCE on my system without explicitly specifind
>> > OCE_DIR. But how do I make it use OCCT when I also have OCE
>> installed?
>> >
>> > What does CADx mean in that header?
>> >
>> > What is this about?
>> > -- Looking for
>> > /home/amazingdude/kicad-source-mirror/build_seths_occt_
>> patch_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
>> > -- Looking for
>> > /home/amazingdude/kicad-source-mirror/build_seths_occt_
>> patch_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
>> > - not found
>> >
>> > I tried to test it with removing oce and just have occt installed
>> > and got something like this:
>> > -- Found OCC: /opt/opencascade/inc (found version "6.9.1")
>> > -- -- Found OCE/OpenCASCADE version: 6.9.1
>> > -- -- OCE/OpenCASCADE include directory: /opt/opencascade/inc
>> > -- -- OCE/OpenCASCADE shared libraries directory:
>> /opt/opencascade/lib
>> >
>> > It did not build against community/opencascade 6.9.1-7. I got the
>> > following error in a clean build dir.
>> >
>> > $ make kicad2step -j1
>> > [  0%] Linking CXX executable kicad2step
>> > /usr/bin/ld: cannot find -lTKMesh
>> > /usr/bin/ld: cannot find -lTKernel
>> > /usr/bin/ld: cannot find -lTKG2d
>> > /usr/bin/ld: cannot find -lTKG3d
>> > /usr/bin/ld: cannot find -lTKMath
>> > /usr/bin/ld: cannot find -lTKIGES
>> > /usr/bin/ld: cannot find -lTKSTL
>> > /usr/bin/ld: cannot find -lTKXSBase
>> > /usr/bin/ld: cannot find -lTKBin
>> > /usr/bin/ld: cannot find -lTKBO
>> > /usr/bin/ld: cannot find -lTKCDF
>> > /usr/bin/ld: cannot find -lTKBRep
>> > /usr/bin/ld: cannot find -lTKTopAlgo
>> > /usr/bin/ld: cannot find -lTKGeomAlgo
>> > /usr/bin/ld: cannot find -lTKGeomBase
>> > /usr/bin/ld: cannot find -lTKPrim
>> > /usr/bin/ld: cannot find -lTKSTEP
>> > /usr/bin/ld: cannot find -lTKSTEPBase
>> > /usr/bin/ld: cannot find -lTKSTEPAttr
>> > /usr/bin/ld: cannot find -lTKFeat
>> > /usr/bin/ld: cannot find -lTKCAF
>> > /usr/bin/ld: cannot find -lTKXCAF
>> > /usr/bin/ld: 

Re: [Kicad-developers] [PATCH] - File format shim for clearance data

[hauptmech]

While i would still like to see this (my) shim go in, I agree with wayne.
Until/unless a less brittle approach is used for the parser, it's better to
signal a problem painfully and maintain the integrity of the file.

I have to admit that when i first heard the s-expressions idea I assumed
that the intention was to use a lisp like virtual machine for loading and
maintaining design data. I've used vm's for data storage before (lua and
python), and it's great. Parsing is free and you can jam in functions and
other data when needed.



On 17 Mar 2018 07:17, "Jeff Young"  wrote:

> Hi Wayne,
>
> Patch reverted.
>
> However, I think your concern is misplaced.  If we want to prevent
> dataloss (ie: from reading a 6.0 file into 5.0), then we should warn the
> user based on the version string (and give them a chance to say “I still
> want to open”).
>
> But either way, actually failing to read the file leaves the user in a
> pickle (especially when it’s easy enough for them to try out a nightly that
> may very well be ahead of their stable).
>
> (And for that reason I think it’s important to put it into 5.0, as
> otherwise it won’t help until we start making 7.0 file format changes.)
>
> Cheers,
> Jeff.
>
> > On 16 Mar 2018, at 18:00, Wayne Stambaugh  wrote:
> >
> > Jeff,
> >
> > Please revert this patch.  Any changes to the board file parser and/or
> > formatter need to be discussed before the changes are committed.  It has
> > been the intention that the board parser be pendantic by design to
> > prevent data loss by ignoring unknown formatting.  Allowing anything
> > outside of the expected formatting in the board file is not something
> > that I want to introduce without some discussion.  Even should we decide
> > to accept this patch, I would prefer we put it off until v6.
> >
> > That being said, the patch fails to build on windows with following
> error:
> >
> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: In
> > member function 'void PCB_PARSER::parseUnknown()':
> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12:
> > error: request for member 'LogText' in '__acrt_iob_func(2)', which is of
> > pointer type  FILE* {aka _iobuf*}' (maybe you meant to use '->' ?)
> > stderr.LogText( msg );
> >^~~
> >
> > Cheers,
> >
> > Wayne
> >
> > On 3/16/2018 1:08 PM, Jeff Young wrote:
> >> Perhaps somewhat germane to this discussion I have removed the
> strict-format nags from the PCB parser.  It now logs warnings to stderr but
> otherwise ignores structures it doesn’t understand.
> >>
> >> I’m not sure that helps hauptmech much as if the file is subsequently
> written the unknown markup will be lost, but I thought I’d mention it.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>> On 7 Mar 2018, at 20:12, hauptmech  wrote:
> >>>
> >>> Hi Thomasz,
> >>>
> >>> I hope I'm able to address you concerns. I'm stuck using kicad stable
> in many situations. I brought clearances up for discussion last July but no
> one moved on it, nor are they required to. Clearance management is a major
> pain point for me so I wrote a fix. This patch will let us (me and the
> people I collaborate with) work using version 5, but open and close files
> written with a version patched with clearance handling code.
> >>>
> >>> I believe that code exactly like this will go into version 6. Getting
> it in earlier makes a huge difference to me, so I'm submitting it.
> >>>
> >>> On 07/03/18 23:30, Tomasz Wlostowski wrote:
>  Hi hauptmech,
> 
>  I'm sorry but IMHO we can't accept your patch:
>  - it changes the file format while we are already in feature freeze.
>  This is a way too big change to accept for the V5.
> >>>
> >>> This patch simply adds tokens to the file format. No clearance data is
> saved for files that use the netclass only. Files without clearance tokens
> continue to remain without them.
> >>>
> >>> Yes it is a backward compatible file format change, but it does no
> harm to V5 files already in the wild.
> >>>
>  - we are planning to overhaul the clearance/design rules system in V6.
>  Storing the clearance *DIRECTLY* for each track segment/via will
>  conflict with any more sophisticated design rule management system.
> 
> >>> I'm glad you are planning this. I am sure that regardless of the
> sophistication of the rule system, you will store clearance directly for
> exactly the same reason that track width is stored directly now. There are
> always exceptions to the rules.
> >>>
> >>> If kicad choose a direction that does not store clearances per item,
> then it is easy to rip these few lines back out.
> >>>
> >>> Did this answer your existing concerns about this patch? Are there any
> other concerns you have about this patch?
> >>>
> >>>
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : 

Re: [Kicad-developers] [PATCH] - File format shim for clearance data

[Jeff Young]

Hi Wayne,

Patch reverted.

However, I think your concern is misplaced.  If we want to prevent dataloss 
(ie: from reading a 6.0 file into 5.0), then we should warn the user based on 
the version string (and give them a chance to say “I still want to open”).

But either way, actually failing to read the file leaves the user in a pickle 
(especially when it’s easy enough for them to try out a nightly that may very 
well be ahead of their stable).

(And for that reason I think it’s important to put it into 5.0, as otherwise it 
won’t help until we start making 7.0 file format changes.)

Cheers,
Jeff.

> On 16 Mar 2018, at 18:00, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> Please revert this patch.  Any changes to the board file parser and/or
> formatter need to be discussed before the changes are committed.  It has
> been the intention that the board parser be pendantic by design to
> prevent data loss by ignoring unknown formatting.  Allowing anything
> outside of the expected formatting in the board file is not something
> that I want to introduce without some discussion.  Even should we decide
> to accept this patch, I would prefer we put it off until v6.
> 
> That being said, the patch fails to build on windows with following error:
> 
> C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: In
> member function 'void PCB_PARSER::parseUnknown()':
> C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12:
> error: request for member 'LogText' in '__acrt_iob_func(2)', which is of
> pointer type  FILE* {aka _iobuf*}' (maybe you meant to use '->' ?)
> stderr.LogText( msg );
>^~~
> 
> Cheers,
> 
> Wayne
> 
> On 3/16/2018 1:08 PM, Jeff Young wrote:
>> Perhaps somewhat germane to this discussion I have removed the strict-format 
>> nags from the PCB parser.  It now logs warnings to stderr but otherwise 
>> ignores structures it doesn’t understand.
>> 
>> I’m not sure that helps hauptmech much as if the file is subsequently 
>> written the unknown markup will be lost, but I thought I’d mention it.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 7 Mar 2018, at 20:12, hauptmech  wrote:
>>> 
>>> Hi Thomasz,
>>> 
>>> I hope I'm able to address you concerns. I'm stuck using kicad stable in 
>>> many situations. I brought clearances up for discussion last July but no 
>>> one moved on it, nor are they required to. Clearance management is a major 
>>> pain point for me so I wrote a fix. This patch will let us (me and the 
>>> people I collaborate with) work using version 5, but open and close files 
>>> written with a version patched with clearance handling code.
>>> 
>>> I believe that code exactly like this will go into version 6. Getting it in 
>>> earlier makes a huge difference to me, so I'm submitting it.
>>> 
>>> On 07/03/18 23:30, Tomasz Wlostowski wrote:
 Hi hauptmech,
 
 I'm sorry but IMHO we can't accept your patch:
 - it changes the file format while we are already in feature freeze.
 This is a way too big change to accept for the V5.
>>> 
>>> This patch simply adds tokens to the file format. No clearance data is 
>>> saved for files that use the netclass only. Files without clearance tokens 
>>> continue to remain without them.
>>> 
>>> Yes it is a backward compatible file format change, but it does no harm to 
>>> V5 files already in the wild.
>>> 
 - we are planning to overhaul the clearance/design rules system in V6.
 Storing the clearance *DIRECTLY* for each track segment/via will
 conflict with any more sophisticated design rule management system.
 
>>> I'm glad you are planning this. I am sure that regardless of the 
>>> sophistication of the rule system, you will store clearance directly for 
>>> exactly the same reason that track width is stored directly now. There are 
>>> always exceptions to the rules.
>>> 
>>> If kicad choose a direction that does not store clearances per item, then 
>>> it is easy to rip these few lines back out.
>>> 
>>> Did this answer your existing concerns about this patch? Are there any 
>>> other concerns you have about this patch?
>>> 
>>> 
>>> 
>>> ___
>>> 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] [PATCH] - File format shim for clearance data

[Wayne Stambaugh]

Jeff,

Please revert this patch.  Any changes to the board file parser and/or
formatter need to be discussed before the changes are committed.  It has
been the intention that the board parser be pendantic by design to
prevent data loss by ignoring unknown formatting.  Allowing anything
outside of the expected formatting in the board file is not something
that I want to introduce without some discussion.  Even should we decide
to accept this patch, I would prefer we put it off until v6.

That being said, the patch fails to build on windows with following error:

C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: In
member function 'void PCB_PARSER::parseUnknown()':
C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12:
error: request for member 'LogText' in '__acrt_iob_func(2)', which is of
pointer type  FILE* {aka _iobuf*}' (maybe you meant to use '->' ?)
 stderr.LogText( msg );
^~~

Cheers,

Wayne

On 3/16/2018 1:08 PM, Jeff Young wrote:
> Perhaps somewhat germane to this discussion I have removed the strict-format 
> nags from the PCB parser.  It now logs warnings to stderr but otherwise 
> ignores structures it doesn’t understand.
> 
> I’m not sure that helps hauptmech much as if the file is subsequently written 
> the unknown markup will be lost, but I thought I’d mention it.
> 
> Cheers,
> Jeff.
> 
>> On 7 Mar 2018, at 20:12, hauptmech  wrote:
>>
>> Hi Thomasz,
>>
>> I hope I'm able to address you concerns. I'm stuck using kicad stable in 
>> many situations. I brought clearances up for discussion last July but no one 
>> moved on it, nor are they required to. Clearance management is a major pain 
>> point for me so I wrote a fix. This patch will let us (me and the people I 
>> collaborate with) work using version 5, but open and close files written 
>> with a version patched with clearance handling code.
>>
>> I believe that code exactly like this will go into version 6. Getting it in 
>> earlier makes a huge difference to me, so I'm submitting it.
>>
>> On 07/03/18 23:30, Tomasz Wlostowski wrote:
>>> Hi hauptmech,
>>>
>>> I'm sorry but IMHO we can't accept your patch:
>>> - it changes the file format while we are already in feature freeze.
>>> This is a way too big change to accept for the V5.
>>
>> This patch simply adds tokens to the file format. No clearance data is saved 
>> for files that use the netclass only. Files without clearance tokens 
>> continue to remain without them.
>>
>> Yes it is a backward compatible file format change, but it does no harm to 
>> V5 files already in the wild.
>>
>>> - we are planning to overhaul the clearance/design rules system in V6.
>>> Storing the clearance *DIRECTLY* for each track segment/via will
>>> conflict with any more sophisticated design rule management system.
>>>
>> I'm glad you are planning this. I am sure that regardless of the 
>> sophistication of the rule system, you will store clearance directly for 
>> exactly the same reason that track width is stored directly now. There are 
>> always exceptions to the rules.
>>
>> If kicad choose a direction that does not store clearances per item, then it 
>> is easy to rip these few lines back out.
>>
>> Did this answer your existing concerns about this patch? Are there any other 
>> concerns you have about this patch?
>>
>>
>>
>> ___
>> 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] [PATCH] - File format shim for clearance data

[Jeff Young]

Perhaps somewhat germane to this discussion I have removed the strict-format 
nags from the PCB parser.  It now logs warnings to stderr but otherwise ignores 
structures it doesn’t understand.

I’m not sure that helps hauptmech much as if the file is subsequently written 
the unknown markup will be lost, but I thought I’d mention it.

Cheers,
Jeff.

> On 7 Mar 2018, at 20:12, hauptmech  wrote:
> 
> Hi Thomasz,
> 
> I hope I'm able to address you concerns. I'm stuck using kicad stable in many 
> situations. I brought clearances up for discussion last July but no one moved 
> on it, nor are they required to. Clearance management is a major pain point 
> for me so I wrote a fix. This patch will let us (me and the people I 
> collaborate with) work using version 5, but open and close files written with 
> a version patched with clearance handling code.
> 
> I believe that code exactly like this will go into version 6. Getting it in 
> earlier makes a huge difference to me, so I'm submitting it.
> 
> On 07/03/18 23:30, Tomasz Wlostowski wrote:
>> Hi hauptmech,
>> 
>> I'm sorry but IMHO we can't accept your patch:
>> - it changes the file format while we are already in feature freeze.
>> This is a way too big change to accept for the V5.
> 
> This patch simply adds tokens to the file format. No clearance data is saved 
> for files that use the netclass only. Files without clearance tokens continue 
> to remain without them.
> 
> Yes it is a backward compatible file format change, but it does no harm to V5 
> files already in the wild.
> 
>> - we are planning to overhaul the clearance/design rules system in V6.
>> Storing the clearance *DIRECTLY* for each track segment/via will
>> conflict with any more sophisticated design rule management system.
>> 
> I'm glad you are planning this. I am sure that regardless of the 
> sophistication of the rule system, you will store clearance directly for 
> exactly the same reason that track width is stored directly now. There are 
> always exceptions to the rules.
> 
> If kicad choose a direction that does not store clearances per item, then it 
> is easy to rip these few lines back out.
> 
> Did this answer your existing concerns about this patch? Are there any other 
> concerns you have about this patch?
> 
> 
> 
> ___
> 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 0/8] fixing various small spelling issues

[Nick Østergaard]

For reference, this patch series have been merged.

2018-02-25 13:17 GMT+01:00 :

> From: Carsten Schoenert 
>
> While working on the packaging of KiCad 5 for Debian the lintian QS tool
> found some spelling error which I fixed mostly by this series.
> The patches are made against the tag 5.0.0-rc1.
>
> I made small but a lot of patches which fixing only one specific
> spelling issue. If you agree on the fixes feel free to merge all commits
> into one before applying.
>
> If you disagree with some fixes just drop the patch.
>
> Regards
> Carsten
>
> Carsten Schoenert (8):
>   fix misspelled 'accesing' -> 'accessing'
>   fix misspelled 'Appearence' -> 'Appearance'
>   fix misspelled 'Modifed' -> 'Modified'
>   fix misspelled 'neeeded' -> 'needed'
>   fix misspelled 'Occassionally' -> 'Occasionally'
>   fix misspelled 'occured' -> 'occurred'
>   fix misspelled 'streching' -> stretching
>   fix misspelled 'Unkown' -> 'Unknown'
>
>  common/gal/opengl/gl_builtin_shaders.cpp |  4 ++--
>  eeschema/drc_erc_item.cpp|  2 +-
>  eeschema/sch_eagle_plugin.cpp| 16
> 
>  include/tool/tool_manager.h  |  2 +-
>  pcbnew/board_netlist_updater.cpp |  2 +-
>  pcbnew/dialogs/dialog_freeroute_exchange_help.html   |  2 +-
>  pcbnew/dialogs/dialog_keepout_area_properties_base.fbp   |  2 +-
>  .../dialogs/dialog_non_copper_zones_properties_base.fbp  |  2 +-
>  pcbnew/dimension.cpp |  2 +-
>  pcbnew/pcbnew_config.cpp |  2 +-
>  10 files changed, 18 insertions(+), 18 deletions(-)
>
> --
> 2.16.1
>
>
> ___
> 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] [PATCH] Add/modify python APIs for querying available pcbnew footprints

[miles mccoo]

Note: I have attempted to follow the kicad coding standards. Surely,
there's something  that I missed.
Please, instead of: "syntax error. Please see the coding guidelines",
please give an idea of the nature of things I missed. ;-)


This change adds the python apis: GetLogicalLibs and FootprintInfo. Extends
FootprintEnumerate

*GetLogicalLibs* will return the list of available footprint libraries
*FootprintEnumerate* lists the footprints in a library. It used to only
take a path to a .pretty library. Now,
it also excepts a library name
*FootprintInfo* will return basic information about a particular footprint
(num pads...)



*A couple of interesting ways in which this patch may be different from
other python interface patches:*
created the file autodoc.i which gives help messages (docstrings as they
are called in python) for the new APIs. The default docstrings generated by
SWIG are often not that helpful. knowing that a function takes a string is
not enough. What should that string contain. It seemed to me these messages
should be together.

created the file swig_typemaps.i: a vector, by default is returned as
a point to a vector instance. in swig_typemaps.i should go directives for
when to expand stl templates as well as customized transformations of
helper classes.

exposed pcb_edit_frame pointer stored in pcbnew_scripting_helpers to other
parts of the SWIG files. This doesn't expose it to python. pcb_edit_frame
has a lot of interesting methods and also many that should be excluded.


Thank you to Orson (Maciej Sumiński) and Jeff Young for their hints in this
thread:
https://lists.launchpad.net/kicad-developers/msg34925.html




Miles



for personal reference: patch 7/8
From 3c898d25be636c9a8556c03de3158f4ac02d88b7 Mon Sep 17 00:00:00 2001
From: Miles McCoo 
Date: Fri, 16 Mar 2018 16:20:05 +0100
Subject: [PATCH 2/2] Add/modify python APIs for querying available pcbnew
 footprints
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"

This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


This change adds the python apis: GetLogicalLibs and FootprintInfo. Extends FootprintEnumerate

GetLogicalLibs will return the list of available footprint libraries
FootprintEnumerate lists the footprints in a library. It used to only take a path to a .pretty library. Now,
it also excepts a library name
FootprintInfo will return basic information about a particular footprint (num pads...)

A couple of interesting ways in which this patch may be different from other python interface patches:
created the file autodoc.i which gives help messages (docstrings as they are called in python) for the new APIs. The default docstrings generated by SWIG are often not that helpful. knowing that a function takes a string is not enough. What should that string contain. It seemed to me these messages should be together.

created the file swig_typemaps.i: a vector, by default is returned as a point to a vector instance. in swig_typemaps.i should go directives for when to expand stl templates as well as customized transformations of helper classes.

exposed pcb_edit_frame pointer stored in pcbnew_scripting_helpers to other parts of the SWIG files. This doesn't expose it to python. pcb_edit_frame has a lot of interesting methods and also many that should be excluded.

Thank you to Orson (Maciej Sumiński) and Jeff Young for their hints.
---
 pcbnew/CMakeLists.txt|   2 +
 pcbnew/swig/autodoc.i|  47 
 pcbnew/swig/footprint.i  | 125 ++-
 pcbnew/swig/pcbnew.i |   8 ++
 pcbnew/swig/pcbnew_scripting_helpers.cpp |   6 ++
 pcbnew/swig/pcbnew_scripting_helpers.h   |   1 +
 pcbnew/swig/swig_typemaps.i  |  96 
 7 files changed, 281 insertions(+), 4 deletions(-)
 create mode 100644 pcbnew/swig/autodoc.i
 create mode 100644 pcbnew/swig/swig_typemaps.i


--2.7.4
Content-Type: text/x-patch; name="0002-Add-modify-python-APIs-for-querying-available-pcbnew.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0002-Add-modify-python-APIs-for-querying-available-pcbnew.patch"

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc11..310c79e 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -439,6 +439,7 @@ if( KICAD_SCRIPTING )   # Generate pcbnew.py and pcbnew_wrap.cxx using swig
 DEPENDS plotcontroller.h
 DEPENDS exporters/gendrill_Excellon_writer.h
 DEPENDS swig/pcbnew.i
+DEPENDS swig/autodoc.i
 DEPENDS swig/board.i
 DEPENDS swig/board_connected_item.i
 DEPENDS swig/board_design_settings.i
@@ -456,6 +457,7 @@ if( KICAD_SCRIPTING )   # Generate pcbnew.py and pcbnew_wrap.cxx using swig
 DEPENDS swig/pad.i
 DEPENDS 

Re: [Kicad-developers] small typo

[Wayne Stambaugh]

Marco,

Please send patches created using `git format-patch` as attachments.  It
makes life easier for lead devs to merge your changes.  I went ahead and
fixed this and gave you credit for the fix.  Thanks for catching this typo.

Cheers,

Wayne

On 03/15/2018 05:34 PM, Marco Ciampa wrote:
> Here is a small typo:
> 
> diff --git a/gerbview/toolbars_gerber.cpp b/gerbview/toolbars_gerber.cpp
> index 2c774baad..58e3c9163 100644
> --- a/gerbview/toolbars_gerber.cpp
> +++ b/gerbview/toolbars_gerber.cpp
> @@ -524,7 +524,7 @@ void GERBVIEW_FRAME::OnUpdateCoordType( wxUpdateUIEvent& 
> aEvent )
>  m_optionsToolBar->SetToolShortHelp( ID_TB_OPTIONS_SHOW_POLAR_COORD,
>  
> m_DisplayOptions.m_DisplayPolarCood ?
>  _( "Turn rectangular coordinates 
> on" ) :
> -_( "Tunn polar coordinates on" ) 
> );
> +_( "Turn polar coordinates on" ) 
> );
>  }
> 
> TIA
> 

___
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