Re: [Kicad-developers] GitLab migration

[Nick Østergaard]

What is the blocker for the libs to move to gitlab.
I was under the impression that the librarians where the people most keen
on moving to gitlab.

On Wed, 27 Nov 2019 at 21:39, Seth Hillbrand  wrote:

> On 11/27/19 11:42 AM, Rene Pöschl wrote:
>
> On 26/11/2019 21:54, Seth Hillbrand wrote:
>
> On 2019-11-26 12:41, Jeff Young wrote:
>
> OK, I’ve enabled 2FA.  Do I need to do something to get added back to
> the project?  (When I go to members, all I see are the bot, Seth and
> Wayne.)
>
> Cheers,
> Jeff.
>
> Hi Jeff-
>
> Wayne and the bot have permissions for the entire project.  I'm there
> while sorting out the transition work.  Coding permissions are specific
> to https://gitlab.com/kicad/code/ .  Library permissions are specific to
> https://gitlab.com/kicad/libraries/ , etc.
>
> If you'd like push permissions in libraries, you'll want to check with
> Rene.  I think Nick or Marek will be managing the website section
> (someone fill me in).  I'll also need to know who to assign to managing
> the documentation section (Nick also?).  Once I get the packaging
> section set up, we'll have folks in charge of their relative builds that
> we can run through the GitLab CI runner interface.
>
> -Seth
>
>
> Hi,
>
> well it seems i do not have access to the group either.
>
>
> Hi Rene-
>
> I've added you to the top-level group.  There is a sub-group called
> librarians where everyone goes but group permissions can only be assigned
> to repositories and not other groups (missed that part).
>
> Let me know if anything else looks amiss.
>
> I'm going to re-sync the repositories this weekend to see if we pick up
> any additional folks who are creating GitLab accounts.
>
> -Seth
>
>
> --
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> ___
> 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] QA broken for arcs

[Seth Hillbrand]

Hi Folks- 

It looks like a recent commit broke the QA tests for Arc bbox checks. 

../../qa/common/geometry/test_shape_arc.cpp(91): error: in
"ShapeArc/BasicCPAGeom": check KI_TEST::IsBoxWithinTol(
aArc.BBox(), aProps.m_bbox, pos_tol ) has failed for ( BOX[ [ 273 | 100
] + [ 27 | 100 ] ], BOX[ [ 100 | 100 ] + [ 200 | 100 ] ], 1 )
Failure occurred in a following context:
C(100,200) 0 - 30 degree
../../qa/common/geometry/test_shape_arc.cpp(91): error: in
"ShapeArc/BasicCPAGeom": check KI_TEST::IsBoxWithinTol(
aArc.BBox(), aProps.m_bbox, pos_tol ) has failed for ( BOX[ [ 273 | 100
] + [ 27 | 100 ] ], BOX[ [ 100 | 100 ] + [ 200 | 100 ] ], 1 )
Failure occurred in a following context:
C(100,200) 0 - 30 degree
../../qa/common/geometry/test_shape_arc.cpp(91): error: in
"ShapeArc/BasicCPAGeom": check KI_TEST::IsBoxWithinTol(
aArc.BBox(), aProps.m_bbox, pos_tol ) has failed for ( BOX[ [ -17320 |
 ] + [ 34640 | 1 ] ], BOX[ [ -17320 | 0 ] + [ 34640 | 2 ] ],
1 )
Failure occurred in a following context:
C(0,0) 30 + 120 degree
../../qa/common/geometry/test_shape_arc.cpp(91): error: in
"ShapeArc/BasicCPAGeom": check KI_TEST::IsBoxWithinTol(
aArc.BBox(), aProps.m_bbox, pos_tol ) has failed for ( BOX[ [ -17320 |
 ] + [ 34640 | 1 ] ], BOX[ [ -17320 | 0 ] + [ 34640 | 2 ] ],
1 )
Failure occurred in a following context:
C(0,0) 30 + 120 degree 

*** 4 failures are detected in the test module "Common library module
tests" 

KiCad Services Corporation 

Seth Hillbrand

LEAD DEVELOPER

+1-530-302-5483‬ [1]

Davis, CA

www.kipro-pcb.com [2]i...@kipro-pcb.com

https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]

 

Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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] Printing size_t on MSW (%zu)

[Jon Evans]

I'm guessing because mingw is providing a special implementation for printf
(and related functions) that supports %zu instead of linking to the old C89
one, but the GCC attribute checker is not aware of that.

On Fri, Jan 3, 2020 at 12:43 PM jp charras  wrote:

> After some tests:
>
> printf("test %zu", size_t(1) );
>
> works, and there is no compil warning.
>
> Functions that generate a warning about %zu format are:
> StrPrintf()
> OUTPUTFORMATTER::Print()
> (see richio.h)
>
> they have the attribute:
> __attribute__ ((format (printf, 2, 3)))
> or
> __attribute__ ((format (printf, 3, 4)))
>
> And therefore GCC verify the format and the variable argument list, like
> for a printf.
>
> For some reason, %zu is seen as valid for printf, but not for functions
> having the printf attribute.
>
>
> Le 03/01/2020 à 16:16, Mark Roszko a écrit :
> > wxWidgets has a interesting maze of macros to determine how to do
> > printf on Windows. I wonder what it ends up doing. There is a special
> > case just for MINGW32 but not MINGW64.
> >
> >
> https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84
> >
> >
> > On Fri, Jan 3, 2020 at 10:05 AM jp charras 
> wrote:
> >>
> >> Le 03/01/2020 à 15:58, Jon Evans a écrit :
> >>> So maybe it's a 32-bits vs 64-bits thing.
> >>> If you add a line like
> >>> #define __USE_MINGW_ANSI_STDIO 1
> >>> at the top of that source file, does it work?
> >>
> >> No.
> >> I still have the compil message:
> >> warning: unknown conversion type character 'z' in format [-Wformat=]
> >>
> >>>
> >>> On Fri, Jan 3, 2020 at 9:32 AM jp charras  >>> > wrote:
> >>>
> >>> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> >>> > I found it defined in
> >>> >
> >>>
>  C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> >>> > on my machine.
> >>> > @JP -- what platform did you use (Windows version / MSYS version
> /
> >>> etc)
> >>> > where you saw the issue?
> >>>
> >>> I confirm the %zu is not working on my install.
> >>>
> >>> m_out->Print( aNestLevel+1, "(drawings %zu)\n",
> >>> aBoard->Drawings().size() );
> >>>
> >>> generates the warning:
> >>> warning: unknown conversion type character 'z' in format
> [-Wformat=]
> >>>
> >>> on my install:
> >>>
> >>> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little
> endian,
> >>> wxMSW
> >>> Build Info:
> >>> wxWidgets: 3.1.3 (wchar_t,wx containers)
> >>> Boost: 1.71.0
> >>> OpenCASCADE Community Edition: 6.8.0
> >>> Curl: 7.66.0
> >>> Compiler: GCC 9.2.0 with C++ ABI 1013
> >>>
> >>> And I never saw %zu working on my W7 32 bits install.
> >>>
> >>>
> >>> >
> >>> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand <
> s...@kipro-pcb.com
> >>> 
> >>> > >> wrote:
> >>> >
> >>> > On 2020-01-02 17:19, Jon Evans wrote:
> >>> >
> >>> > > Hi all,
> >>> > >
> >>> > > Context:
> >>> > >
> >>>
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> >>> > >
> >>> > > I have heard there are issues using "%zu" format specifier
> on
> >>> > > Windows/mingw, because mingw links against a very old
> >>> Windows library
> >>> > > that does not support the C99 standard.
> >>> > >
> >>> > > I have also heard that this isn't an issue anymore because
> of
> >>> > > __USE_MINGW_ANSI_STDIO in wxWidgets.
> >>> > >
> >>> > > I tried to reproduce this problem on my Windows 10 machine
> but
> >>> > couldn't
> >>> > > -- using %zu works fine.
> >>> > >
> >>> > > Does anyone know if this is still a problem on any of our
> >>> supported
> >>> > > platforms?
> >>> > >
> >>> > > Thanks,
> >>> > > -Jon--
> 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

Re: [Kicad-developers] Printing size_t on MSW (%zu)

[jp charras]

After some tests:

printf("test %zu", size_t(1) );

works, and there is no compil warning.

Functions that generate a warning about %zu format are:
StrPrintf()
OUTPUTFORMATTER::Print()
(see richio.h)

they have the attribute:
__attribute__ ((format (printf, 2, 3)))
or
__attribute__ ((format (printf, 3, 4)))

And therefore GCC verify the format and the variable argument list, like
for a printf.

For some reason, %zu is seen as valid for printf, but not for functions
having the printf attribute.


Le 03/01/2020 à 16:16, Mark Roszko a écrit :
> wxWidgets has a interesting maze of macros to determine how to do
> printf on Windows. I wonder what it ends up doing. There is a special
> case just for MINGW32 but not MINGW64.
> 
> https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84
> 
> 
> On Fri, Jan 3, 2020 at 10:05 AM jp charras  wrote:
>>
>> Le 03/01/2020 à 15:58, Jon Evans a écrit :
>>> So maybe it's a 32-bits vs 64-bits thing.
>>> If you add a line like
>>> #define __USE_MINGW_ANSI_STDIO 1
>>> at the top of that source file, does it work?
>>
>> No.
>> I still have the compil message:
>> warning: unknown conversion type character 'z' in format [-Wformat=]
>>
>>>
>>> On Fri, Jan 3, 2020 at 9:32 AM jp charras >> > wrote:
>>>
>>> Le 03/01/2020 à 15:10, Jon Evans a écrit :
>>> > I found it defined in
>>> >
>>> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
>>> > on my machine.
>>> > @JP -- what platform did you use (Windows version / MSYS version /
>>> etc)
>>> > where you saw the issue?
>>>
>>> I confirm the %zu is not working on my install.
>>>
>>> m_out->Print( aNestLevel+1, "(drawings %zu)\n",
>>> aBoard->Drawings().size() );
>>>
>>> generates the warning:
>>> warning: unknown conversion type character 'z' in format [-Wformat=]
>>>
>>> on my install:
>>>
>>> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
>>> wxMSW
>>> Build Info:
>>> wxWidgets: 3.1.3 (wchar_t,wx containers)
>>> Boost: 1.71.0
>>> OpenCASCADE Community Edition: 6.8.0
>>> Curl: 7.66.0
>>> Compiler: GCC 9.2.0 with C++ ABI 1013
>>>
>>> And I never saw %zu working on my W7 32 bits install.
>>>
>>>
>>> >
>>> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand >> 
>>> > >> wrote:
>>> >
>>> > On 2020-01-02 17:19, Jon Evans wrote:
>>> >
>>> > > Hi all,
>>> > >
>>> > > Context:
>>> > >
>>> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
>>> > >
>>> > > I have heard there are issues using "%zu" format specifier on
>>> > > Windows/mingw, because mingw links against a very old
>>> Windows library
>>> > > that does not support the C99 standard.
>>> > >
>>> > > I have also heard that this isn't an issue anymore because of
>>> > > __USE_MINGW_ANSI_STDIO in wxWidgets.
>>> > >
>>> > > I tried to reproduce this problem on my Windows 10 machine but
>>> > couldn't
>>> > > -- using %zu works fine.
>>> > >
>>> > > Does anyone know if this is still a problem on any of our
>>> supported
>>> > > platforms?
>>> > >
>>> > > Thanks,
>>> > > -Jon-- 
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] Printing size_t on MSW (%zu)

[jp charras]

Le 03/01/2020 à 16:02, Ian McInerney a écrit :
> JP, is that mingw32 directly, or was it provided by mingw-w64
> indirectly? It appears that mingw32 (the original compiler version)
> doesn't have the compatibility enabled but the forked version mingw-w64
> does. (there was discussion about this on the mingw users mailing
> list: 
> https://osdn.net/projects/mingw/lists/archive/users/2019-January/000202.html).
> 
> -Ian

I am using mingw32 only.
The tools installed by pacman are something like mingw-w64-i686-xxx

> 
> On Fri, Jan 3, 2020 at 2:32 PM jp charras  > wrote:
> 
> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> >
> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> > on my machine.
> > @JP -- what platform did you use (Windows version / MSYS version /
> etc)
> > where you saw the issue?
> 
> I confirm the %zu is not working on my install.
> 
> m_out->Print( aNestLevel+1, "(drawings %zu)\n",
> aBoard->Drawings().size() );
> 
> generates the warning:
> warning: unknown conversion type character 'z' in format [-Wformat=]
> 
> on my install:
> 
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
> wxMSW
> Build Info:
>     wxWidgets: 3.1.3 (wchar_t,wx containers)
>     Boost: 1.71.0
>     OpenCASCADE Community Edition: 6.8.0
>     Curl: 7.66.0
>     Compiler: GCC 9.2.0 with C++ ABI 1013
> 
> And I never saw %zu working on my W7 32 bits install.
> 
> 
> >
> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  
> > >> wrote:
> >
> >     On 2020-01-02 17:19, Jon Evans wrote:
> >
> >     > Hi all,
> >     >
> >     > Context:
> >     >
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> >     >
> >     > I have heard there are issues using "%zu" format specifier on
> >     > Windows/mingw, because mingw links against a very old
> Windows library
> >     > that does not support the C99 standard.
> >     >
> >     > I have also heard that this isn't an issue anymore because of
> >     > __USE_MINGW_ANSI_STDIO in wxWidgets.
> >     >
> >     > I tried to reproduce this problem on my Windows 10 machine but
> >     couldn't
> >     > -- using %zu works fine.
> >     >
> >     > Does anyone know if this is still a problem on any of our
> supported
> >     > platforms?
> >     >
> >     > Thanks,
> >     > -Jon
> >
> >     I learned that this was a problem from JP.  See commit
> >     https://gitlab.com/kicad/code/kicad/commit/17b18637f
> >
> >     Perhaps he can shed some light on the specifics.
> >
> >     -S
> >


-- 
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] Printing size_t on MSW (%zu)

[Mark Roszko]

wxWidgets has a interesting maze of macros to determine how to do
printf on Windows. I wonder what it ends up doing. There is a special
case just for MINGW32 but not MINGW64.

https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84


On Fri, Jan 3, 2020 at 10:05 AM jp charras  wrote:
>
> Le 03/01/2020 à 15:58, Jon Evans a écrit :
> > So maybe it's a 32-bits vs 64-bits thing.
> > If you add a line like
> > #define __USE_MINGW_ANSI_STDIO 1
> > at the top of that source file, does it work?
>
> No.
> I still have the compil message:
> warning: unknown conversion type character 'z' in format [-Wformat=]
>
> >
> > On Fri, Jan 3, 2020 at 9:32 AM jp charras  > > wrote:
> >
> > Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > > I found it defined in
> > >
> > C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> > > on my machine.
> > > @JP -- what platform did you use (Windows version / MSYS version /
> > etc)
> > > where you saw the issue?
> >
> > I confirm the %zu is not working on my install.
> >
> > m_out->Print( aNestLevel+1, "(drawings %zu)\n",
> > aBoard->Drawings().size() );
> >
> > generates the warning:
> > warning: unknown conversion type character 'z' in format [-Wformat=]
> >
> > on my install:
> >
> > Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
> > wxMSW
> > Build Info:
> > wxWidgets: 3.1.3 (wchar_t,wx containers)
> > Boost: 1.71.0
> > OpenCASCADE Community Edition: 6.8.0
> > Curl: 7.66.0
> > Compiler: GCC 9.2.0 with C++ ABI 1013
> >
> > And I never saw %zu working on my W7 32 bits install.
> >
> >
> > >
> > > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  > 
> > > >> wrote:
> > >
> > > On 2020-01-02 17:19, Jon Evans wrote:
> > >
> > > > Hi all,
> > > >
> > > > Context:
> > > >
> > https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> > > >
> > > > I have heard there are issues using "%zu" format specifier on
> > > > Windows/mingw, because mingw links against a very old
> > Windows library
> > > > that does not support the C99 standard.
> > > >
> > > > I have also heard that this isn't an issue anymore because of
> > > > __USE_MINGW_ANSI_STDIO in wxWidgets.
> > > >
> > > > I tried to reproduce this problem on my Windows 10 machine but
> > > couldn't
> > > > -- using %zu works fine.
> > > >
> > > > Does anyone know if this is still a problem on any of our
> > supported
> > > > platforms?
> > > >
> > > > Thanks,
> > > > -Jon
> > >
> > > I learned that this was a problem from JP.  See commit
> > > https://gitlab.com/kicad/code/kicad/commit/17b18637f
> > >
> > > Perhaps he can shed some light on the specifics.
> > >
> > > -S
> > >
> > >
> > > Seth Hillbrand
> > > KiCad Services Corporation
> > > https://www.kipro-pcb.com
> > > +1 530 302 5483 | +1 212 603 9372
> > >
> > > ___
> > > 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
> > >
> >
> >
> > --
> > 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
> >
>
>
> --
> 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



-- 
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] Printing size_t on MSW (%zu)

[jp charras]

Le 03/01/2020 à 15:58, Jon Evans a écrit :
> So maybe it's a 32-bits vs 64-bits thing.
> If you add a line like
> #define __USE_MINGW_ANSI_STDIO 1
> at the top of that source file, does it work?

No.
I still have the compil message:
warning: unknown conversion type character 'z' in format [-Wformat=]

> 
> On Fri, Jan 3, 2020 at 9:32 AM jp charras  > wrote:
> 
> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> >
> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> > on my machine.
> > @JP -- what platform did you use (Windows version / MSYS version /
> etc)
> > where you saw the issue?
> 
> I confirm the %zu is not working on my install.
> 
> m_out->Print( aNestLevel+1, "(drawings %zu)\n",
> aBoard->Drawings().size() );
> 
> generates the warning:
> warning: unknown conversion type character 'z' in format [-Wformat=]
> 
> on my install:
> 
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
> wxMSW
> Build Info:
>     wxWidgets: 3.1.3 (wchar_t,wx containers)
>     Boost: 1.71.0
>     OpenCASCADE Community Edition: 6.8.0
>     Curl: 7.66.0
>     Compiler: GCC 9.2.0 with C++ ABI 1013
> 
> And I never saw %zu working on my W7 32 bits install.
> 
> 
> >
> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  
> > >> wrote:
> >
> >     On 2020-01-02 17:19, Jon Evans wrote:
> >
> >     > Hi all,
> >     >
> >     > Context:
> >     >
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> >     >
> >     > I have heard there are issues using "%zu" format specifier on
> >     > Windows/mingw, because mingw links against a very old
> Windows library
> >     > that does not support the C99 standard.
> >     >
> >     > I have also heard that this isn't an issue anymore because of
> >     > __USE_MINGW_ANSI_STDIO in wxWidgets.
> >     >
> >     > I tried to reproduce this problem on my Windows 10 machine but
> >     couldn't
> >     > -- using %zu works fine.
> >     >
> >     > Does anyone know if this is still a problem on any of our
> supported
> >     > platforms?
> >     >
> >     > Thanks,
> >     > -Jon
> >
> >     I learned that this was a problem from JP.  See commit
> >     https://gitlab.com/kicad/code/kicad/commit/17b18637f
> >
> >     Perhaps he can shed some light on the specifics.
> >
> >     -S
> >
> >
> >     Seth Hillbrand
> >     KiCad Services Corporation
> >     https://www.kipro-pcb.com
> >     +1 530 302 5483 | +1 212 603 9372
> >
> >     ___
> >     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
> >
> 
> 
> -- 
> 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
> 


-- 
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] Printing size_t on MSW (%zu)

[Ian McInerney]

JP, is that mingw32 directly, or was it provided by mingw-w64 indirectly?
It appears that mingw32 (the original compiler version) doesn't have the
compatibility enabled but the forked version mingw-w64 does. (there was
discussion about this on the mingw users mailing list:
https://osdn.net/projects/mingw/lists/archive/users/2019-January/000202.html
).

-Ian

On Fri, Jan 3, 2020 at 2:32 PM jp charras  wrote:

> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> > C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> > on my machine.
> > @JP -- what platform did you use (Windows version / MSYS version / etc)
> > where you saw the issue?
>
> I confirm the %zu is not working on my install.
>
> m_out->Print( aNestLevel+1, "(drawings %zu)\n", aBoard->Drawings().size()
> );
>
> generates the warning:
> warning: unknown conversion type character 'z' in format [-Wformat=]
>
> on my install:
>
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
> wxMSW
> Build Info:
> wxWidgets: 3.1.3 (wchar_t,wx containers)
> Boost: 1.71.0
> OpenCASCADE Community Edition: 6.8.0
> Curl: 7.66.0
> Compiler: GCC 9.2.0 with C++ ABI 1013
>
> And I never saw %zu working on my W7 32 bits install.
>
>
> >
> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  > > wrote:
> >
> > On 2020-01-02 17:19, Jon Evans wrote:
> >
> > > Hi all,
> > >
> > > Context:
> > >
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> > >
> > > I have heard there are issues using "%zu" format specifier on
> > > Windows/mingw, because mingw links against a very old Windows
> library
> > > that does not support the C99 standard.
> > >
> > > I have also heard that this isn't an issue anymore because of
> > > __USE_MINGW_ANSI_STDIO in wxWidgets.
> > >
> > > I tried to reproduce this problem on my Windows 10 machine but
> > couldn't
> > > -- using %zu works fine.
> > >
> > > Does anyone know if this is still a problem on any of our supported
> > > platforms?
> > >
> > > Thanks,
> > > -Jon
> >
> > I learned that this was a problem from JP.  See commit
> > https://gitlab.com/kicad/code/kicad/commit/17b18637f
> >
> > Perhaps he can shed some light on the specifics.
> >
> > -S
> >
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > ___
> > 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
> >
>
>
> --
> 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

Re: [Kicad-developers] Printing size_t on MSW (%zu)

[Jon Evans]

So maybe it's a 32-bits vs 64-bits thing.
If you add a line like
#define __USE_MINGW_ANSI_STDIO 1
at the top of that source file, does it work?

On Fri, Jan 3, 2020 at 9:32 AM jp charras  wrote:

> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> > C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> > on my machine.
> > @JP -- what platform did you use (Windows version / MSYS version / etc)
> > where you saw the issue?
>
> I confirm the %zu is not working on my install.
>
> m_out->Print( aNestLevel+1, "(drawings %zu)\n", aBoard->Drawings().size()
> );
>
> generates the warning:
> warning: unknown conversion type character 'z' in format [-Wformat=]
>
> on my install:
>
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
> wxMSW
> Build Info:
> wxWidgets: 3.1.3 (wchar_t,wx containers)
> Boost: 1.71.0
> OpenCASCADE Community Edition: 6.8.0
> Curl: 7.66.0
> Compiler: GCC 9.2.0 with C++ ABI 1013
>
> And I never saw %zu working on my W7 32 bits install.
>
>
> >
> > On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  > > wrote:
> >
> > On 2020-01-02 17:19, Jon Evans wrote:
> >
> > > Hi all,
> > >
> > > Context:
> > >
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> > >
> > > I have heard there are issues using "%zu" format specifier on
> > > Windows/mingw, because mingw links against a very old Windows
> library
> > > that does not support the C99 standard.
> > >
> > > I have also heard that this isn't an issue anymore because of
> > > __USE_MINGW_ANSI_STDIO in wxWidgets.
> > >
> > > I tried to reproduce this problem on my Windows 10 machine but
> > couldn't
> > > -- using %zu works fine.
> > >
> > > Does anyone know if this is still a problem on any of our supported
> > > platforms?
> > >
> > > Thanks,
> > > -Jon
> >
> > I learned that this was a problem from JP.  See commit
> > https://gitlab.com/kicad/code/kicad/commit/17b18637f
> >
> > Perhaps he can shed some light on the specifics.
> >
> > -S
> >
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > ___
> > 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
> >
>
>
> --
> 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

Re: [Kicad-developers] Printing size_t on MSW (%zu)

[Jon Evans]

I found it defined in
C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h on
my machine.
@JP -- what platform did you use (Windows version / MSYS version / etc)
where you saw the issue?

On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  wrote:

> On 2020-01-02 17:19, Jon Evans wrote:
>
> > Hi all,
> >
> > Context:
> > https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> >
> > I have heard there are issues using "%zu" format specifier on
> > Windows/mingw, because mingw links against a very old Windows library
> > that does not support the C99 standard.
> >
> > I have also heard that this isn't an issue anymore because of
> > __USE_MINGW_ANSI_STDIO in wxWidgets.
> >
> > I tried to reproduce this problem on my Windows 10 machine but couldn't
> > -- using %zu works fine.
> >
> > Does anyone know if this is still a problem on any of our supported
> > platforms?
> >
> > Thanks,
> > -Jon
>
> I learned that this was a problem from JP.  See commit
> https://gitlab.com/kicad/code/kicad/commit/17b18637f
>
> Perhaps he can shed some light on the specifics.
>
> -S
>
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> ___
> 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] Printing size_t on MSW (%zu)

[jp charras]

Le 03/01/2020 à 15:10, Jon Evans a écrit :
> I found it defined in
> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> on my machine.
> @JP -- what platform did you use (Windows version / MSYS version / etc)
> where you saw the issue?

I confirm the %zu is not working on my install.

m_out->Print( aNestLevel+1, "(drawings %zu)\n", aBoard->Drawings().size() );

generates the warning:
warning: unknown conversion type character 'z' in format [-Wformat=]

on my install:

Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
wxMSW
Build Info:
wxWidgets: 3.1.3 (wchar_t,wx containers)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.8.0
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013

And I never saw %zu working on my W7 32 bits install.


> 
> On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand  > wrote:
> 
> On 2020-01-02 17:19, Jon Evans wrote:
> 
> > Hi all,
> >
> > Context:
> > https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
> >
> > I have heard there are issues using "%zu" format specifier on
> > Windows/mingw, because mingw links against a very old Windows library
> > that does not support the C99 standard.
> >
> > I have also heard that this isn't an issue anymore because of
> > __USE_MINGW_ANSI_STDIO in wxWidgets.
> >
> > I tried to reproduce this problem on my Windows 10 machine but
> couldn't
> > -- using %zu works fine.
> >
> > Does anyone know if this is still a problem on any of our supported
> > platforms?
> >
> > Thanks,
> > -Jon
> 
> I learned that this was a problem from JP.  See commit
> https://gitlab.com/kicad/code/kicad/commit/17b18637f
> 
> Perhaps he can shed some light on the specifics.
> 
> -S
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> 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
> 


-- 
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] thoughts on hierarchical schematics

[Tjeerd Pinkert]

My text:
---
license: CC BY-SA 4.0
Copyright (add name when editing/extending):
Tjeerd J. Pinkert, 2020
 contact:  alumnus.utwente.nl>
---

Dear Quabache, Eeli, list

It took me a while to answer, reading below might explain why.

Ouabache Designworks  wrote:
-
> Kicad implemented hierarchy in a way that was different than how it
> was usually done by the rest of the industry.  The fix is to see how
> everyone does it and do it the same way.

I would not agree with that on forehand. Industry is not always thinking
for an as broad scope as can be potentially covered by Kicad and
industry can have other drivers than pure customer interest, e.g. market
policy / vendor lock in, that might influence the way software is designed.

Thinking about the electronics design one can designate several stages
of refinement as far as I see it.

1. (Abstract) Component: a drawing of the key function of an electronics
part. This drawing includes the electrical ports of the component as
wire ends.
2 Ports: a definition of each port for use by the schematics capture
program. The program could otherwise not "find" the ports.

These two are typically combined in a basic component in the library.
The ports typically extending the drawing (having both a graphical and
organisational component).

3. Schematic: Graphical representation of components and their
interconnections that form a larger electrical unit.

The schematic is the basic representation of an electrical circuit. This
can e.g. be an op-amp circuit. The schematic does not necessarily say
anything about the properties of the circuit, but it gives a hint in the
direction in which the equations of the circuit behaviour might develop.
The list of connections is generated from the schematic, this list will
have only the connections, but no component values.

4. Parametrisation: The (implicit or explicit) assignment of
mathematical models for each component and the component values.

After this step a complete model for simulation should be available
since all equations are (implicitly or explicitly) known. Note that this
is normally the scope of a circuit simulator's schematic capture tool.
The ability to include explicit circuit models could call for close
integration with e.g. ng-spice since a double efford would be a pitty. I
think the current approach of "magic attributes" to components could
become a more integrated domain? (E.g. store the transistor model
together with it's values as a complete parametrisation item).

5. Specification: The assignment of specific parts to the components
that electrically match (or can match) the mathematical description
given in the parametrisation.

This step can still be rather abstract, e.g. in the design of chips this
can be a predefined transistor or resistor type from a library, or the
application of assigned parameters to a parametrisable transistor model,
e.g. length and width of a MOSFET to a mosfet design. On the other hand
it can be the selection of a transistor from types offered by a vendor
resulting in a (partial) MF / MPN combination.

6. Mechanisation: The assignment of the mechanical form factor of the
selected part. Of importance here are the shape of the electrical
connections, the overall shape of the component or package of the
component. So basically shape, potentially also connection position.

This form factor is the basis for the selection of footprints for the
PCB design. It can also be the basis for a mechanical support (e.g. when
selecting the form factor of coils for a 100 kW transmitter), or maybe
both, when selecting a transformer that needs electrical connections but
also mechanical supports.

Usage of steps 4 to 6 can have several orders of application, which a
good tool should all support. Some ways that I can think of are:
* assignment of value (4) and mechanical form factor (6) for a resistor.
  The model (4) is implicit (R=U/I), no parasitics. Part specification
  (5) takes place when a buying decision is made based on (4) and (6) in
  the BOM.
* specification of a transistor part (5). The parametrisation (4)
  (simulation model and model parameters) is based on the selected
  component. A mechanical form factor (6) is chosen based on dissipation
  calculated from simulation.
* assignment of the mechanical form factor (6) of a resistor. The value
  and specific part are defined based on experimental results (e.g. in
  prototyping a microwave circuit where the suitability of certain parts
  is being compared).

For a PCB design only step 6 is needed directly after step 3. These
properties are sort of parallel, but not always, since for a PCB the
mechanisation chosen might allow several parametrisations and/or
concretisations even multiple concretisations with the same parametrisation.

From step 6 on on, one should be in the PCB layout tool when a PCB is
involved. Or in the drawing tools for mask design when doing chip
design. For PCB design the steps 

Re: [Kicad-developers] Printing size_t on MSW (%zu)

[Seth Hillbrand]

On 2020-01-02 17:19, Jon Evans wrote:


Hi all,

Context: 
https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682


I have heard there are issues using "%zu" format specifier on 
Windows/mingw, because mingw links against a very old Windows library 
that does not support the C99 standard.


I have also heard that this isn't an issue anymore because of 
__USE_MINGW_ANSI_STDIO in wxWidgets.


I tried to reproduce this problem on my Windows 10 machine but couldn't 
-- using %zu works fine.


Does anyone know if this is still a problem on any of our supported 
platforms?


Thanks,
-Jon


I learned that this was a problem from JP.  See commit 
https://gitlab.com/kicad/code/kicad/commit/17b18637f


Perhaps he can shed some light on the specifics.

-S


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

___
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] Printing size_t on MSW (%zu)

[Ian McInerney]

Is __USE_MINGW_ANSI_STDIO actually defined in the wxWidgets builds we use?
A quick search through their codebase for that symbol only shows them
testing for it and never actually defining it.

-Ian

On Fri, Jan 3, 2020 at 1:20 AM Jon Evans  wrote:

> Hi all,
>
> Context:
> https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
>
> I have heard there are issues using "%zu" format specifier on
> Windows/mingw, because mingw links against a very old Windows library that
> does not support the C99 standard.
>
> I have also heard that this isn't an issue anymore because of
> __USE_MINGW_ANSI_STDIO in wxWidgets.
>
> I tried to reproduce this problem on my Windows 10 machine but couldn't --
> using %zu works fine.
>
> Does anyone know if this is still a problem on any of our supported
> platforms?
>
> Thanks,
> -Jon
> ___
> 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