Re: [Kicad-developers] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[jp charras]

Le 16/02/2022 à 19:38, Steven A. Falco a écrit :
I found "Fix overflow vulnerability in Gerbview" and possibly "Fix 
relative return with nullptr condition".  Are there other patches in 
the series, or are those two the only ones that are needed?


I tried grepping the log for CVE, but didn't find much...

Steve



3 fixes are needed. This one is needed:

"Fix float scaling to use single fn"




On 2/16/22 01:17 PM, Seth Hillbrand wrote:
Distributions that would like to release a patched version of 5.1, 
5.0 or 4.0 can cherry-pick the patch series.  They should apply cleanly.


Seth

On Wed, Feb 16, 2022 at 9:16 AM Steven A. Falco 
mailto:stevenfa...@gmail.com>> wrote:


    One additional question - I know that 5.1.12 was the last planned 
release in the 5.x series, and that 5.1.12 has the vulnerability.  
Currently, because of Fedora policy, both F34 and F35 still ship 5.1.12.


    I'll ask on the Fedora list if this event qualifies as an 
exception to the policy, but if not, how involved would it be to 
patch 5.1.12, or perhaps to spin a 5.1.13 just to fix this issue?


         Steve

    On 2/16/22 11:49 AM, Steven A. Falco wrote:
 > Excellent!  I'll note that on the Fedora bugs.
 >
 >  Thanks,
 >  Steve
 >
 > On 2/16/22 09:44 AM, Ian McInerney wrote:
 >> All 4 CVEs were fixed in the 6.0.2 release and the release 
announcement was updated last night to say this (to coincide with the 
public disclosure that happened today). There will be another email 
on the developer list later today with more details.

 >>
 >> -Ian
 >>
 >> On Wed, Feb 16, 2022 at 2:18 PM Steven A. Falco 
mailto:stevenfa...@gmail.com> 
>> wrote:

 >>
 >>     I've just received a large number of bugs against KiCad, 
supposedly due to CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, 
CVE-2022-23947.

 >>
 >>     I don't have time to look into them, but I wanted to make 
them known.  There are apparently also bugs for this on the gentoo 
site - here is one: https://bugs.gentoo.org/833426 
 >

 >>
 >>     Here are the Fedora bugs:
 >>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054956 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054957 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054959 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054960 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054955 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054973 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054974 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054979 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054980 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054958 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054972 
 
>
 >> https://bugzilla.redhat.com/show_bug.cgi?id=2054978 
 
>

 >>

Re: [Kicad-developers] strange, probably trivial, message formatting error

[jp charras]

Le 29/11/2021 à 15:48, Ian McInerney a écrit :

I ask because it is working in the non-translated English dialog I have:
image.png

-Ian


On Mon, Nov 29, 2021 at 2:31 PM Marco Ciampa  wrote:

On Mon, Nov 29, 2021 at 12:58:15PM +, Ian McInerney wrote:
> Did you include the newlines in the translated text?

Obviusly, gettext has a specific test that does not pass if
parameters or
newlines are different in source and translation.

Check it by yourself...

#: common/dialogs/dialog_global_lib_table_config.cpp:42
#, c-format
msgid ""
"KiCad has been run for the first time using the new %s library
table for\n"
"accessing libraries.  In order for KiCad to access %s libraries,\n"
"you must configure your global %s library table.  Please select
from one\n"
"of the options below.  If you are not sure which option to
select, please\n"
"use the default selection."
msgstr ""
"KiCad è stato eseguito per la prima volta usando la nuova tabella
librerie "
"%s\n"
"per l'accesso alle librerie.  Per permettere a KiCad di accedere
alle "
"librerie %s,\n"
"è necessario configurare la tabella librerie %s globale.
Selezionare una "
"delle\n"
"opzioni sottostanti.  Se non si sa quale opzione scegliere, usare
la\n"
"selezione predefinita."

-- 


Saluton,
Marco Ciampa


For me it is working in non translated and translated languages (French, 
Italian)


--
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] Tools for editing/creating UI elements in KiCad?

[jp charras]

Le 02/09/2021 à 16:35, Brian a écrit :

Hi Folks,

Reviving some conversation that's happened over the years...what are 
the favored tools for editing and/or creating the wxWidgets UI 
elements for KiCad?  Hopefully not "vi"...


On the one hand, I suppose I could always just go my own way with my 
own fork, but I'd like to wind up with something possibly 
re-integratable when I'm done (the current idea is creating a 
hand-assembly assistant -- a simple UI that will select/highlight 
parts in pcbnew to help me get my eyes on the right spot on the real 
board, and let me check off the parts as I place them, etc).


I found some discussion surrounding wxFormBuilder from 2008, and I 
know that CMake can generate project files for CodeLite, which 
features wxFormBuilder integration... so is that the recommended path?


Cheers,
-Brian 


Currently we are using wxFormBuilder3.9.0 to create dialogs.


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] Can't compile latest kicad

[jp charras]

Le 16/07/2021 à 13:15, Mark Roszko a écrit :

has_value was added in boost 1.68.

There is an argument we should be supporting boost 1.65 due to Ubuntu 18


Commit 25e9d177 should fix this issue.  Please test.


--
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] Any pointers to speed up the build

[jp charras]

Le 11/07/2021 à 14:59, Andrew Lutsenko a écrit :

Few things that can help
1. Disable qa tests build if you don't need them
2. Disable python scripting if you don't need it
3. Use MSVC if you are on windows. Their linker is a LOT faster than gcc.
4. Use more powerful hardware. Those steps take <10s on my pc but it's 
a 12 core 3900x.


Best,
Andrew

On Sun, Jul 11, 2021 at 5:35 AM Pradeepa Senanayake 
mailto:pradeepa@gmail.com>> wrote:


Hello Team,

I don't know whether this is normal, but even for a small change,
the application takes ~ 15 mins to build.

$ time make -j 5 install
...
...
real    14m51.815s
user    0m8.017s
sys     0m15.641s

The most time is spent in the linking process. (Following steps)

[ 98%] Linking CXX shared module _pcbnew.kiface
[ 98%] Built target pcbnew_kiface
[ 98%] Creating python's pcbnew native module _pcbnew.pyd for
command line use.
[ 98%] Built target pcbnew
[ 98%] Linking CXX executable qa_pcbnew_tools.exe
[ 98%] Linking CXX executable qa_pcbnew.exe
[ 98%] Built target pcbnew_python_module
[ 98%] Built target qa_pcbnew_tools
[100%] Built target qa_pcbnew

Is there a way to speed this up?

Thanks!
Best Regards,
Pradeepa Senanayake.
-



On Windows, if you are using msys2, use Release mode when you do not 
actually need the Debug build.


The Debug build creates slower binaries, and more annoying *very large* 
files.


use -DBUILD_SMALL_DEBUG_FILES=ON option on msys2 to build Debug versions.

On my computer (not very fast), link process takes one minute in Release 
mode, and no QA build.


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] Problem opening a PCB file

[jp charras]

Le 06/07/2021 à 17:55, Steven A. Falco a écrit :

On 7/6/21 11:30 AM, jp charras wrote:


Le 06/07/2021 à 17:17, Steven A. Falco a écrit :
I've found a project on github [1] that I am interested in, but I 
have not been able to open the PCB file correctly.  It seems that 
5.1 is too old to handle this file, but 5.99 has several issues, as 
described in [2].


It looks like the ground plane is not being processed properly.  I 
also noted that the three "zone" buttons on the left pane of pcb_new 
are grayed out, which seems very strange.


I'm not sure if the original project authors did something wrong. I 
see both a .pro and a .kicad_pro file in the directory, so they must 
have switched major releases at some point.  But I'd still expect 
pcb_new to be able to deal with the board file.


Steve

[1] 
https://github.com/phl0/MMDVM_HS_Dual_Hat/tree/master/hardware/r2.0-mini 


[2] https://gitlab.com/kicad/code/kicad/-/issues/8739



Just delete the .kicag_prl file, or reenable the visibility of objects.

Jean-Pierre CHARRAS


Thanks - that helps.  But something is still wrong.  When I toggle the 
pads and zones visibility to turn them on, I see the zones filled in, 
as expected.


But then, when I type ^B, I get 88 unrouted nets, and if I had "Show 
filled areas of zones" selected, the filled zone in the center of the 
board disappears although the zone outline remains.


So it seems that something is still wrong.

Steve - 


^B removes the zone fill. B rebuilds the zone fill.


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] Problem opening a PCB file

[jp charras]

Le 06/07/2021 à 17:17, Steven A. Falco a écrit :
I've found a project on github [1] that I am interested in, but I have 
not been able to open the PCB file correctly.  It seems that 5.1 is 
too old to handle this file, but 5.99 has several issues, as described 
in [2].


It looks like the ground plane is not being processed properly.  I 
also noted that the three "zone" buttons on the left pane of pcb_new 
are grayed out, which seems very strange.


I'm not sure if the original project authors did something wrong. I 
see both a .pro and a .kicad_pro file in the directory, so they must 
have switched major releases at some point.  But I'd still expect 
pcb_new to be able to deal with the board file.


Steve

[1] 
https://github.com/phl0/MMDVM_HS_Dual_Hat/tree/master/hardware/r2.0-mini

[2] https://gitlab.com/kicad/code/kicad/-/issues/8739



Just delete the .kicag_prl file, or reenable the visibility of objects.

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] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[jp charras]

Le 28/06/2021 à 16:14, Brian Piccioni a écrit :

JP

Thanks for the quick reply

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
$ find /mingw64/ -name *glew*
/mingw64/bin/glew32.dll
/mingw64/bin/glewinfo.exe
/mingw64/bin/libvtkglew-8.2.dll
/mingw64/include/GL/glew.h
/mingw64/include/GL/wglew.h
/mingw64/include/OGRE/RenderSystems/GL/GL/glew.h
/mingw64/include/OGRE/RenderSystems/GL/GL/wglew.h
/mingw64/include/vtk-8.2/vtkglew
/mingw64/include/vtk-8.2/vtkglew/include/GL/glew.h
/mingw64/include/vtk-8.2/vtkglew/include/GL/vtk_glew_mangle.h
/mingw64/include/vtk-8.2/vtkglew/include/GL/wglew.h
/mingw64/include/vtk-8.2/vtk_glew.h
/mingw64/lib/cmake/glew
/mingw64/lib/cmake/glew/glew-config.cmake
/mingw64/lib/cmake/glew/glew-targets-release.cmake
/mingw64/lib/cmake/glew/glew-targets.cmake
/mingw64/lib/cmake/vtk-8.2/Modules/vtkglew.cmake
/mingw64/lib/libglew32.a
/mingw64/lib/libglew32.dll.a
/mingw64/lib/libvtkglew-8.2.dll.a
/mingw64/lib/pkgconfig/glew.pc
/mingw64/share/licenses/glew

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
$ pacman -Ss glew
mingw32/mingw-w64-i686-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
mingw64/mingw-w64-x86_64-glew 2.2.0-2 [installed]
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
clang64/mingw-w64-clang-x86_64-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~




This is similar to what I see on my computer (but I have less files).

GLEW_LIBRARY should be found by cmake.

You can try the brute force (that helped me in some cases):

invoke cmake with the option:

-DGLEW_LIBRARY=/d/mingw/mingw64/lib

(expecting your mingw path is /d/mingw) to force the GLEW_LIBRARY path.


--
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] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[jp charras]

Le 28/06/2021 à 15:51, Brian Piccioni a écrit :

Hello

I have observed that Geographical Reannotation (my contribution) no 
longer seems to update the schematic. Manual "Update Schematic from 
PCB" seems to work so I assume there has been a modification to the 
Kiway commands. In order to track this down I need to set up build on 
msys2.


I have followed the instructions at 
https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to


pacman -S cmake
pacman -S gcc.

cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)

Glew is installed as per the instructions.

Any suggestions?

Brian


What the command "find /mingw64/ -name *glew*" find?

What the command "pacman -Ss glew" says.



--


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] *** SPAM *** Re: ngspice-34

[jp charras]

Le 03/02/2021 à 11:38, Carsten Schoenert a écrit :

Hello Holger,

Am 03.02.21 um 11:20 schrieb Holger Vogt:

I remember some time ago I tried to address the libtool versioning, but
I did not understand it, so abandoned it again.

libtool isn't really easy, yes, but the more complicated thing is to
integrate the things correctly into configure.ac and potential
Makefile(s).am.

If I'm feeling boring enough I can try to have look this. But ngspice
did already cost a lot of my brain in the past. :P


What about adding and distributing alongside of sharedspice.h a version
header file verngspice.h which contains only some version info?

That would for sure help for the problem Ian has written about, but it
doesn't solves the underlying real problem, a non versioned library.

To add such a version string you even don't need to add another header
file, there is already sharedspice.h available. It's easy to process
this as .h.in file while configure is running to add such a version
string. I can try to have a look at this as well.



OTOH, a version.h file is not a bad idea (read: for me a very good idea):

at least the name is already a useful comment and it request only a very 
few amount of work.


Many tools use this trick (for instance opencascade, and most of other 
tools we are using in Kicad), and one **big** advantage it works outside 
the libtool stuff.


--
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] Build problem of current master tree

[jp charras]

Le 02/01/2021 à 18:11, Carsten Schoenert a écrit :

Am 02.01.21 um 18:07 schrieb jp charras:

What is the problem with these files?

They are build in tree in case you do a configure out of tree?


They are already the final header files built from the corresponding .md
files.

In my eyes it's simply the wrong way to build files in another place
than I do configuring things, that's not expected by the user.


These files encode the md strings in .md source files. They where 
previously html encoded strings inside .h files.


But html strings are extremely hard to translate, and where replaced by 
md strings.


The reason they are inside the source is *exactly* the same as we have 
also  the .cpp icon files in sources.


All these files are automatically created from .md files or .svg files, 
and I do not remember any issue about them.


But we certainly cannot  expect a "user" who just translate strings to 
be able to build and compile Kicad. This is not (as you know) a basic thing.


We also cannot  expect a guy who try to build Kicad to also install (and 
perhaps build) the tools to create the .cpp icons files from the .svg files.


Users and developers are not always the same guys and do not have the 
same skill.


--

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] *** SPAM *** Re: Build problem of current master tree

[jp charras]

Le 02/01/2021 à 17:45, Carsten Schoenert a écrit :

Hi,

Am 02.01.21 um 17:17 schrieb jp charras:

Le 02/01/2021 à 17:09, Nick Østergaard a écrit :

FYI, there are still generated files in the source which are also
checked in to the source tree:

After a make clean:
deleted:    ../eeschema/dialogs/dialog_bom_help_md.h
deleted:    ../pcb_calculator/attenuators/bridget_tee_formula.h
deleted:    ../pcb_calculator/attenuators/pi_formula.h
deleted:    ../pcb_calculator/attenuators/splitter_formula.h
deleted:    ../pcb_calculator/attenuators/tee_formula.h
deleted:    ../pcb_calculator/eserie_help.h
deleted:  ../pcb_calculator/tracks_width_versus_current_formula.h


They are automatically generated but they must be available in sources
because they are  needed for translations.

can't they turned into something like '*foo_header.h.in' that get than
processed into the final header file?
By this the files are still available, or better their content, for
localization.


What is the problem with these files?

They are already the final header files built from the corresponding .md 
files.


--

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] Build problem of current master tree

[jp charras]

Le 02/01/2021 à 17:09, Nick Østergaard a écrit :
FYI, there are still generated files in the source which are also 
checked in to the source tree:


After a make clean:
deleted:    ../eeschema/dialogs/dialog_bom_help_md.h
deleted:    ../pcb_calculator/attenuators/bridget_tee_formula.h
deleted:    ../pcb_calculator/attenuators/pi_formula.h
deleted:    ../pcb_calculator/attenuators/splitter_formula.h
deleted:    ../pcb_calculator/attenuators/tee_formula.h
deleted:    ../pcb_calculator/eserie_help.h
deleted:  ../pcb_calculator/tracks_width_versus_current_formula.h



They are automatically generated but they must be available in sources 
because they are  needed for translations.


--
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] MSVC compile: missing s3d_plugin_oce.dll

[jp charras]

Le 02/12/2020 à 08:15, deve...@worldinone.at a écrit :


I copied over ALL of the dlls, just in case, and it did not help. If 
it is about dependencies, maybe I missed to install something in 
vcpkg. I installed the recommended libraries as per the web documentation:


boost cairo curl glew gettext glm icu ngspice opencascade opengl 
openssl python3 wxwidgets zlib.


Anything missing?

3d_plugin_oce.dll should be built by the kicad build process (as long as 
you have enabled OCE or OCC)


It should be copied to kicad/bin/plugins/3d



*Von:*Mark Roszko 
*Gesendet:* 21 November 2020 14:01
*An:* deve...@worldinone.at
*Cc:* KiCad Developers 
*Betreff:* Re: [Kicad-developers] MSVC compile: missing s3d_plugin_oce.dll

If the kiface file exists in that path, the failure to load is because 
you are missing more dependencies in the install\bin folder that need 
to be copied from vcpkg debug\bin or bin.


On Sat, Nov 21, 2020 at 3:00 AM > wrote:


I got it sorted out, partially. After copying the right jpeg62.dll
and lzmad.dll to the install directory for debug, KiCad started
all right.

When starting eeschema or pcbnew or anything loaded by kiway.cpp,
I get an error about failing *.kiface to load.

Debugging showed that in wxDynamicLibrary::Load, RawLoad is called
with the correct path (in my case



but that returns NULL, as it fails to load the library.
Unfortunately, RawLoad does not provide any error codes.

Is this the bug you mentioned? But then, the path passed to
RawLoad is correct, so I do not see what can be wrong here. Other
modules like ntdll, comctrl32 e.a. are loaded ok.

Only thing I can image is that – out of the blue - there’s a
problem with the path string. Is it a MSVC specific thing (the
nightlies obviously are built all right)? Ok, the nightlies are
built with wxwidgets 3.0.5

and I'm on wxwidgets 3.1.4. But one week or so ago, everything was
ok. Trouble started after upgrading vcpkg.

-Martin

*Von:*Mark Roszko mailto:mark.ros...@gmail.com>>
*Gesendet:* 16 November 2020 20:56
*An:* deve...@worldinone.at 
*Betreff:* Re: [Kicad-developers] MSVC compile: missing
s3d_plugin_oce.dll

Probably a few weeks waitI have it on my queue to revisit
vcpkg at some point and upstream also takes time to merge fixes.

It's just easier to copy the DLLs like I noted.

On Mon, Nov 16, 2020 at 2:45 PM mailto:deve...@worldinone.at>> wrote:

Ok. Can you notify me when it’s fixed? Thanks a lot!

-Martin

*Von:*Mark Roszko mailto:mark.ros...@gmail.com>>
*Gesendet:* Montag, 16. November 2020 20:14
*An:* deve...@worldinone.at 
*Cc:* KiCad Developers mailto:kicad-developers@lists.launchpad.net>>
*Betreff:* Re: [Kicad-developers] MSVC compile: missing
s3d_plugin_oce.dll

Ah it's a bug in vcpkg I need to fix upstream.

For now you'll need to include in your kicad install folder
for debug, the non-debug versions of freetype, zlib, bz2 and
libpng

On Mon, Nov 16, 2020 at 1:44 PM Mark Roszko
mailto:mark.ros...@gmail.com>> wrote:

Ah I've been meaning to fix that. There's something wrong
with the compilation settings and/or wxdynamiclibrary
loader that's causing it not to load DLLs from the
application's executable directory, very specifically for
the OCE plugin.

On Mon, Nov 16, 2020 at 6:22 AM mailto:deve...@worldinone.at>> wrote:

Compiling the current source (7043) with MSVC and the
proposed CMakeSettings.json I get a missing
s3d_plugin_oce.dll error when starting the 3D viewer.

What is wrong here?

-Martin.

___
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


-- 


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


--
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to 

Re: [Kicad-developers] V6 Usability suggestion

[jp charras]

Le 21/10/2020 à 18:44, Brian Piccioni a écrit :

Hello

The power new DRC is great. I believe it would be more usable if the

Board Setup -> Design Rules -> Violation Severity table

would be in alphabetical order.

Until the table has been configured there are a profligacy of DRC 
errors, many of which are novel. The errors have names but since the 
table is not in alphabetical order, finding them in the table to 
adjust (i.e. error to warning) is unnecessarily complicated.


A minor thing, obviously.


Unfortunately, even in a alphabetical order in English, it will be not 
ordered in other languages.


So the "good" order is something else than alphabetical.

Perhaps by topics.

--

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] Fwd: mingw64 build issue.

[jp charras]

 Message transféré 
Sujet : mingw64 build issue.
Date :  Sat, 26 Sep 2020 07:35:20 -
De :Frank Zeeman 
Répondre à :Frank Zeeman 
Pour :  jean-pierre charras 



I had to downgrade using
pacman -U
/var/cache/pacman/pkg/mingw-w64-x86_64-binutils-2.35-1-any.pkg.tar.zst

--
This message was sent from Launchpad by
Frank Zeeman (https://launchpad.net/~franzee)
using the "Contact this team's admins" link on the KiCad Developers team page
(https://launchpad.net/~kicad-developers).
For more information see
https://help.launchpad.net/YourAccount/ContactingPeople

___
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] mingw64 build issue.

[jp charras]

Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :

Is anyone else seeing the following error when building with MinGW64/msys2?

../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
relocation truncated to fit: R_X86_64_PC32 against `*ABS*'

I did some digging around and it looks like it's a bug in the context
assembly code but I've never seen the error before.  I tried downgrading
gcc from 10.2 to 10.1 but no luck.  It also happens when building the
5.1 branch.  It doesn't happen when building with MinGW32/msys2.

Thanks,

Wayne


I am not seeing this issue.

I have a recent (2 weeks) msys install, on a new computer, with W10 - 64bits



--
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] Help needed

[jp charras]

Le 25/09/2020 à 16:32, Jon Evans a écrit :
Can you run with ASAN on (KICAD_SANITIZE in CMake) and see if you get 
some info about why you get a segfault?


On Fri, Sep 25, 2020 at 10:28 AM Franck Jullien 
mailto:franck.jull...@gmail.com>> wrote:


Hi,

I'm working on the intersheets references functionality and I'm
struggling with a segfault.
Until now, I didn't try to remove iref from sheets. Now, I do this
with:

void SCH_EDIT_FRAME::RemoveAllIntersheetsRefs()
{
    SCH_SHEET_LIST sheets = Schematic().GetSheets();
    SCH_GLOBALLABEL* gLabel;

    m_labelTable.clear();

    for( const SCH_SHEET_PATH& sheet : sheets )
    {
        SCH_SCREEN* screen = sheet.LastScreen();

        for( SCH_ITEM* item : screen->Items() )
        {

            if( item->Type() == SCH_GLOBAL_LABEL_T )
            {
                gLabel = (SCH_GLOBALLABEL*)( item );
                SCH_IREF* iref = gLabel->GetIref();

                if( iref )
                {
                    gLabel->SetIref( nullptr );
                    gLabel->SetIrefSavedPosition( wxDefaultPosition );
                    screen->DeleteItem( iref );
                }
            }
        }
    }
}

As soon as I call DeleteItem (or RemoveFromScreen) I get a crash.
Is there something obvious I don't see ?

I still need to get familiar with screens, sheets, frames, canvas,
views

Thanks in advance.

Franck.



I am guessing screen->DeleteItem( iref ); remove an item from 
screen->Items()


Usually, when removing an item from a list, the pointers used to explore 
the list become invalid.


But screen->Items() is a rtree, and I am not experienced with rtrees.

I am unsure exploring all sheets is working well in complex hierarchies 
(complex hierarchies are hierarchies with a sheet instantiated more than 
once.


Probably exploring the screen list is enough.


--
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] Call for bitmap help

[jp charras]

Le 01/09/2020 à 19:37, Wayne Stambaugh a écrit :

I just committed[1] the support to edit symbols in place using the
symbol library editor.  I used the export symbol icon as a temporary
place holder but it's not ideal.  If someone has the time, I would
appreciate if you would make a bitmap that looks like the save footprint
in board bitmap in the footprint editor except with the Eeschema bitmap
as the background.  I can do this myself but my bitmap skills are weak
so it most likely wont look as good as most of the other bitmaps.
Thanks in advance for the help.

Cheers,

Wayne

[1]:
https://gitlab.com/kicad/code/kicad/-/commit/c9fa46ace834fc5733756552e94891d917c89a62


Hi Wayne,

My bitmap skills are rather low, but I just committed a new icon for Eeschema 
similar to the footprint editor bitmap

Cheers,

--

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] Build broken?

[jp charras]

Le 10/08/2020 à 11:18, Roberto Fernández Bautista a écrit :
> Hi Jon,
> 
> Thanks for that commit - it does appear that it fixed one compile issue, 
> however it appears there is
> a second one. Just to make sure it was nothing related to my branch, I pulled 
> latest from master
> (commit 370bc89d) and did a clean build on MSVC, resulting in the following 
> compile error:
> 
> Error C1083 Cannot open include file: 'Python.h': No such file or directory
> C:\src\kicad-sources\master\build\x64-Debug\master
> C:\src\kicad-sources\master\pcbnew\swig\python_scripting.h 37 
> 
> Thanks
> 
> Roberto.

I just coàmmitted a fix.


-- 
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] Master won't build

[jp charras]

Le 07/08/2020 à 05:41, Brian Piccioni a écrit :
> FYI I pulled master origin a few hours ago and it fails with
> 
> [ 98%] Linking CXX shared module _pcbnew.kiface
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(drc_rule_parser.cpp.obj):drc_rule_parser.cpp:(.text+0x7308):
> undefined reference to `DSNLEXER::findToken(std::__cxx11::basic_string std::char_traits,
> std::allocator > const&)'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635: 
> pcbnew/_pcbnew.kiface] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3402: 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> make: *** [Makefile:161: all] Error 2
> 
> I'm on Windows 10, MSYS,
> 
> I wiped the release directory and re-ran the script so it isn't likely a 
> cache issue.
> 
I just committed a fix.

-- 
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] Net Tie specification?

[jp charras]

Currently, the best doc about net ties ( and microwave components that
create similar problems) is:

https://lists.launchpad.net/kicad-developers/msg24455.html
([RFC] On net ties, microwave tools & custom pad shapes, altogether.)

Le 30/07/2020 à 01:59, Jon Evans a écrit :
> From this comment, maybe Simon has something that is not published yet?
> https://gitlab.com/kicad/code/kicad/-/merge_requests/85#note_282728454
> 
> On Wed, Jul 29, 2020 at 7:34 PM Seth Hillbrand  wrote:
>>
>> On Wed, Jul 29, 2020 at 4:16 PM Roberto Fernández Bautista 
>>  wrote:
>>>
>>> Hi all,
>>>
>>> I see from the road map that net ties are planned for v6 
>>> (https://gitlab.com/kicad/code/kicad/-/wikis/KiCad-6.0-Roadmap). In the 
>>> "current status" it mentions that the specification is in development.
>>>
>>> Could someone please send me a link to the work in progress, so I can add 
>>> some comments?
>>>
>>> Thanks
>>>
>>> Roberto.
>>>
>>
>> I think Simon had some ideas here but I don't recall seeing a specification 
>> document.
>>



-- 
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] Castellated edge support in v5.99

[jp charras]

Le 23/07/2020 à 14:19, Jon Evans a écrit :
> Local rules will be done with zones: you can give a name to a copper or
> keepout zone and use it to define a rule. If you want a zone that is
> only used to define a rule and has no other effect, use a keepout that
> has no restrictions set.
> 
> Regarding castellations, I think we should study an example case and see
> if it can be allowed easily with the current set of rules planned, and
> if not, add whatever is needed to make it so. I agree it's common enough
> that it should be not too hard to make castellations that pass DRC. 
> 
> -Jon
> 

There is (since 6 months) some pad fabrication properties (see pad
properties dialog), only enabled by the advanced config.

I just enabled this option (removed from the advanced config option.)

Castellated pad is one of these abrication properties.

These properties are stored in Gerber files, so they need to be a pad
property.

Currently, DRC does not use these properties (in fact only Castellated
pad can be used in DRC).

> 
> On Thu, Jul 23, 2020, 03:24 Eeli Kaikkonen  > wrote:
> 
> KiCad doesn't have any specific support for castellations, and doesn't
> need anything special because it's basically PTH pad on the edge. It
> works so-and-so in 5.1: it doesn't complain about pad copper which is
> too close to the edge, and it's even possible to add SMD pads to the
> footprint so that it's possible to route without DRC problems. (See
> https://forum.kicad.info/t/how-to-design-castellated-pins/23945 .)
> 
> However, this doesn't work so well in 5.99. DRC check handles pads
> like other copper and the only way to turn off errors is to ignore
> "Board edge clearance violations" altogether.
> 
> We could of course have some specific support for castellation, like
> marking footprints as castellation and then allowing copper and
> routing there. But I doubt this is what the team wants because it's a
> special case which can be solved otherwise (like local neckdown for
> tight IC's).
> 
> It' not clear to me how the local rules is going to be implemented.
> Will there be some kind of graphical polygon where I can define the
> rules with the DRC Rules editor? That would work for me if it's made
> easy enough.
> 
> I thought about being able to add certain kind of predefined rules
> without a need to write them. For example
> * Add a box around the area
> * Open the context menu on the box
> * It reveals menu item "Add Rules"
> * -> "Castellation"
> 
> Then it would allow the pads on the edge, and also routing and zone
> filling fully without caring about the edge line inside the pad
> boundaries (the rule system must of course support this!).
> 
> On the other hand, castellation is pretty much a de facto standard and
> it wouldn't hurt to support it as a special case. Even allowing THT
> pads on an edge where the hole is on the edge, too, would be enough to
> allow the same workflow than in 5.1.
> 
> Splitting board edge violations into two, pad and other, would also
> work. I never want to violate with traces, but sometimes in a tight
> design I have placed pads very near to the edge and trusted that the
> manufacturer removes copper if they want and there's still enough room
> for the component. This would also allow non-castellated edge plating
> with a footprint (which must otherwise be handled with local rules,
> like castellation).
> 
> Finally, being able to select a bunch of violation markers - for
> example for one footprint - and excluding them permanently could also
> work.
> 
> Eeli Kaikkonen
> 
> ___
> 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
> 


-- 
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] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[jp charras]

Le 23/07/2020 à 00:39, Jon Evans a écrit :
> If it is the commit I made that Ian points out, I won't be able to debug
> it very effectively.  I don't have a msys2 build environment, and it
> seems to work on all the platforms I do have.
> 
> On Wed, Jul 22, 2020 at 6:38 PM Wayne Stambaugh  > wrote:
> 
> No problem.  I'll file a issue report as soon as I determine the guilty
> commit.
> 

I tested a build on my W7 32bits install, with a recent msys2 version
(not the latest):

Application: KiCad

Version: (5.99.0-2385-g7067e42da-dirty), debug build

Libraries:
wxWidgets 3.1.3
libcurl/7.65.1 OpenSSL/1.1.1c (Schannel) zlib/1.2.11 brotli/1.0.7
libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.1

Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian,
wxMSW

Build Info:
Date: Jul 23 2020 08:48:19
wxWidgets: 3.1.3 (wchar_t,wx containers)
Boost: 1.73.0
OCE: 6.9.1
Curl: 7.70.0
ngspice: 31+
Compiler: GCC 10.1.0 with C++ ABI 1014

Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=ON
KICAD_STDLIB_DEBUG=OFF
KICAD_STDLIB_LIGHT_DEBUG=OFF
KICAD_SANITIZE=OFF


My swig version is 4.01.

I have the lot of compil warnings, but I do not have the link issue.

-- 
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] Auto-generated backup files: are they useful?

[jp charras]

Le 30/06/2020 à 00:13, hauptmech a écrit :
> 
> While I agree that it is not KiCad's job to do archival backups or version 
> control, I do think that KiCad should preserve the integrity of users data 
> through a crash. Even better if the work between the last save and the crash 
> is also preserved and recovered on restart.
> 
> I have had to use the backup files to recover data in the past. I have no 
> idea if that recovery was related to something that is now no longer a 
> possible issue.
> 
> 
> -Hauptmech
> 
> 

I am also thinking a backup can be useful when something unexpected happens.

Backups, like any security system, bothers you as long as you do not need to 
use them.
But you are happy to find them in case of trouble.

I like the way some CAD tools manage backup:
only one zip archive is created (for instance projectname_backup.zip) and 
contains all saved files
(in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
This is not a full project backup, just main files are saved.

This is not invasive (only one file, or a few .zip if one want to keep last n 
saved versions)
and is a security against  unexpected cases.

For me, backups are like a accident insurance: you need them and you hope never 
use them.

And about VCS use:

Many good electronics guys do not even know what is it, and have never compiled 
any source code.
Electronics world and Software world are not exactly the same world.

-- 
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] [Proposed Feature] GerbView - Mapping Gerbers w Altium extensions to KiCad PCB layers

[jp charras]

Le 20/06/2020 à 22:40, Jeff Young a écrit :
> Some answers below:
> 
>> On 20 Jun 2020, at 06:39, mailto:pjmo...@csi.com>> 
>> mailto:pjmo...@csi.com>> wrote:
>>
>> I wanted to add a feature to GerbView that relates to exporting a KiCad PCB 
>> file from loaded Gerbers.  I often use "Export to PCBNew..." to recreate 
>> boards from Gerbers, and many of them involve Gerbers generated by Protel, 
>> the progenitor to Altium.  Since Altium (and Protel) use specific file 
>> extensions for specfic layers, it's tedious to manually have to set each 
>> Gerber layer to the equivalent KiCad PCB layer.  Every time I use "Export to 
>> PCBNew..." I keep thinking how handy it would be if GerbView could recognize 
>> the file extensions and offer to map them to the appropriate KiCad PCB 
>> layers. 
>>
>> So, I've created a proof of concept that compiles into my local copy of 
>> GerbView, and I have a couple of questions:
>>
>> 1 - I made my changes directly in the file select_layers_to_pcb.cpp by 
>> adding a new member function to it.  The new function is called from and 
>> used within "initDialog()". Is it preferable to create a whole new source 
>> file/object for containing the new function (or functions if more are 
>> needed), or is it okay to add it directly into this existing file?  Or is 
>> this the sort of question best answered when someone is reviewing a 
>> submission?
> 
> Add it directly.
> 
>>
>> 2 - In the KiCad source code, I see a lot of text using the macro "_" to 
>> provide string translations, but there are also cases where the "wxT" macro 
>> (which I don't believe handles translations) is used instead.  Is there a 
>> rule of thumb for when to use "_", or is best to just always use it?
> 
> The translation framework can only handle 7-bit ASCII.  So any characters 
> above that must be broken out and used with the “wxT” macro (as well as 
> anything you don’t want translated, such as file tokens or the like).
> 

wxT creates  wide char string. It is used to create/initialize wxStrings.
It is now not mandatory for ASCII7 strings, but was needed for wxWidgets older 
than 3.0

>>
>> 3 - The source files I've looked at seem to use "ii" as the default integer 
>> index in loops, versus the more traditional "i".  Is this a KiCad thing, or 
>> something specific to whatever developer(s) worked in the code I've looked 
>> at?
> 
> It’s pretty random over a larger sample of code.  Use either.
> 

I am the guy who use ii, jj ... in loops.

This is a trick I learned a long time ago from a coworker:
using ii, jj in loops allows you to easily find/replace all occurrences of 
these variables in a text editor, when needed.
Good luck to find/replace occurrences of a variable named i or j ...

>>
>> 4 - The source files I've looked at only use the generic "int" as opposed to 
>> using more specific types such as "int32_t" or "int8_t".  Is the use of 
>> "stdint.h" not allowed/not encouraged?
> 
> I’ll let someone else field this.
> 
> Cheers,
> Jeff.


-- 
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] Build on msys2 fails : libngspice-x.dll not found in any executable path

[jp charras]

Le 25/05/2020 à 15:33, Brian Piccioni a écrit :
> Unfortunately, while we seem to get past the libngspice-0.dll problem with 
> the fix, the old workaround  for the python problem no longer works.
> 
> cmake -DCMAKE_BUILD_TYPE=Debug \
> -DKICAD_SCRIPTING=OFF\  I believe this used to get around 
> the pyhton mismatch.
> -G "Eclipse CDT4 - Unix Makefiles" \
> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> -DMSYS=TRUE \
> ../kicad
> 
> 
> Throws the library mismatch error.
> 
> 
> $ cmake -DCMAKE_BUILD_TYPE=Debug \
>> -DKICAD_SCRIPTING=OFF\
>> -G "Eclipse CDT4 - Unix Makefiles" \
>> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
>> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
>> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
>> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
>> -DMSYS=TRUE \
>> ../kicad
> -- Eclipse version is set to 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if 
> this is wrong.
> -- KiCad install dir: 
> -- Enabling warning -Wsuggest-override
> -- Enabling warning -Wduplicated-branches
> -- Enabling warning -Wduplicated-cond
> -- Enabling error for -Wvla
> -- Enabling warning -Wimplicit-fallthrough
> -- Enabling error for -Wreturn-type
> -- Enabling warning -Wshadow
> -- Check for installed GLEW -- found
> info: libngspice shared lib found: C:/msys64/mingw64/bin/libngspice-0.dll
> 
> -- Check for installed Python Interpreter -- found
> -- Python module install path: lib/python2.7/site-packages
> CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
>   wxPython/Phoenix does not appear to be installed on the system
> Call Stack (most recent call first):
>   CMakeLists.txt:740 (find_package)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeOutput.log".
> See also 
> "C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeError.log".
> 

I do not see this issue.

FindwxPython is not called if cmake is called with -DKICAD_SCRIPTING=OFF
(or DKICAD_SCRIPTING_WXPYTHON=OFF)
Try to delete CMakeCacke.txt and rerun cmake.


-- 
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] Build on msys2 fails : libngspice-x.dll not found in any executable path

[jp charras]

Le 23/05/2020 à 17:55, jp charras a écrit :
> Le 23/05/2020 à 17:35, Wayne Stambaugh a écrit :
>> There is definitely something wrong but I'm not sure where the issue is.
>>  I downgraded both cmake a couple of versions but cmake started
>> complaining about missing libraries.  I even modified Findngspice.cmake
>> with the absolute path to libngspice-0.dll and it still didn't work so
>> something is definitely broken.  I'm may try a full clean reinstall of
>> msys2 when I have a *lot* of free time so I don't know when that will
>> happen.  For all of you windows devs using msys2, you might want to hold
>> off updating until this issue is resolved.
>>
>>
> I also tried the last msys version.
> I found 2 issues:
> this issue: libngspice-0.dll is not found even if it is in path.
> This is an issue but one can invoke cmake with option 
> -DNGSPICE_DLL=
> The other issue is the fact the last msys version comes with wxWidgets 3.05 
> compiled with gcc10
> but wxPython was not rebuild and there is an ABI issue.
> 
> 

I just committed a fix for the libngspice-x.dll issue.
I am not entirely convinced this is a msys issue.
However, the wxPython problem is a msys issue.

-- 
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] Build on msys2 fails : libngspice-x.dll not found in any executable path

[jp charras]

Le 23/05/2020 à 17:35, Wayne Stambaugh a écrit :
> There is definitely something wrong but I'm not sure where the issue is.
>  I downgraded both cmake a couple of versions but cmake started
> complaining about missing libraries.  I even modified Findngspice.cmake
> with the absolute path to libngspice-0.dll and it still didn't work so
> something is definitely broken.  I'm may try a full clean reinstall of
> msys2 when I have a *lot* of free time so I don't know when that will
> happen.  For all of you windows devs using msys2, you might want to hold
> off updating until this issue is resolved.
> 
> 
I also tried the last msys version.
I found 2 issues:
this issue: libngspice-0.dll is not found even if it is in path.
This is an issue but one can invoke cmake with option 
-DNGSPICE_DLL=
The other issue is the fact the last msys version comes with wxWidgets 3.05 
compiled with gcc10
but wxPython was not rebuild and there is an ABI issue.


-- 
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] KiCad website

[jp charras]

Le 23/05/2020 à 15:26, Wayne Stambaugh a écrit :
> I don't know if it was intentional (I'm guessing not) but the KiCad
> website looks completely different today on Firefox and Chrome (see
> attached screen shot).  Clicking on the topic links doesn't even take me
> to the correct page.
> 
> Thanks,
> 
> Wayne
> 

Be sure you are using:
https://kicad-pcb.org
and not the old link https://www.kicad-pcb.org


-- 
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] Eeschema annotate block / specific component types proposal

[jp charras]

Le 07/05/2020 à 20:15, Jeff Young a écrit :
> Hi James,
> 
> You might first want to download one of the nightlies (5.99) and play with 
> it.  Block selections are gone: eeschema now has a “normal” selection model 
> where you click on things and/or drag-select and they get highlighted.
> 
> So from the GUI perspective you’d just need to add the options to the Scope 
> section of the Annotate dialog.
> 
> I believe there’s already a Wishlist item for this in the issue database.
> 
> I suck at git, so you don’t want to know what I do for branching, etc. ;)
> 
> Cheers,
> Jeff.
> 

Annotating just a selected area is not trivial:

- What about multi-units components: for instance what about renaming 2 of 5 
units when one unit is the unit handling the power pins?
this is the best way to break a design.
- What about complex hierarchies: selecting an area selects in fact as many 
areas as sheet instances.

- and what about multi-units components in complex hierarchies.

Good luck with block annotation.

-- 
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] 5.1 branch freeze

[jp charras]

Le 06/05/2020 à 00:09, Nick Østergaard a écrit :
> Mmm, when you mean branch freeze, I assume you really mean that we
> have a string freeze for the branch.
> 
> I am sorta wondering why we can't enable the CI, for example. [1]
> 
> Also as a heads up, there a couple of critical issues for the 5.1.6
> milestone being added after 5.1.6-rc1 [2], most importantly [3] and
> [4].
> 
> [1] https://gitlab.com/kicad/code/kicad/-/merge_requests/198#note_337036264
> [2] https://gitlab.com/groups/kicad/code/-/milestones/1
> [3] https://gitlab.com/kicad/code/kicad/-/issues/4328
> [4] https://gitlab.com/kicad/code/kicad/-/issues/4284
> 

I cannot reproduce the crashes, both on W7 and Kubuntu 18.04LTS.
issue 4328 can be depending on libraries or Window manager (or can be fixed 
since 5.1.5.0 version).
issue 4284 can be related to some multi-threading seg-fault, very hard to 
reproduce.


-- 
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] DRC changes

[jp charras]

Le 26/04/2020 à 16:15, Jeff Young a écrit :
> Hi JP,
> 
> Did they report the same number of errors?
> 
> Thanks,
> Jeff.
> 

No:
The old algo reports 0 error.
The new reports a lot.
I am thinking there is an issue with rectangular or round/rect pads rotated by 
+- 90 deg.


-- 
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] DRC changes

[jp charras]

Le 26/04/2020 à 14:27, Jeff Young a écrit :
> I have added code to many DRC errors which shows the minimum clearance, its 
> source, and the actual clearance.
> 
> The old DRC code was pretty heavily optimised around the idea of only needing 
> to know if the clearance was violated (and not by how much), so a lot of it 
> has been re-written.  For this reason the new code is currently in a branch 
> (jeffDRC).
> 
> I’d appreciate some testing on it if anyone gets a chance.  (More on the DRC 
> errors themselves than the new reporting.)
> 
> Cheers,
> Jeff.
> 
> PS: feel free to report issues here in email, or in 
> https://gitlab.com/kicad/code/kicad/-/issues/2313.
> 

Hi Jeff,
I just tested it.

The old DRC code was pretty heavily optimized around the idea of only needing 
to know if the clearance was violated because the calculation time
is *much* faster than calculating actual distances.
I tested the calculation time on the same (a 16 layers large board) with both 
DRC versions:
To test tracks clearance:
Current algo: 14 s.
Your new algo: 4 m

This is really a blocking problem.

-- 
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] Removal of some globals

[jp charras]

Le 05/04/2020 à 17:20, Jeff Young a écrit :
> I had to remove some globals from Eeschema that were causing problems 
> (default line width, text size, wire thickness, bus thickness etc.).
> 
> It was a large change (as these things always are), so let me know if you see 
> anything odd.
> 
> Cheers,
> Jeff.

Hi Jeff:
a typo in function:
int LIB_CIRCLE::GetPenSize() const
is missing the return statement.


-- 
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] Please be kind towards translators

[jp charras]

Le 05/04/2020 à 10:55, jp charras a écrit :
> Le 05/04/2020 à 10:49, Marco Ciampa a écrit :
>> Hello devs,
>> I often see many messages like those of the newly merged Altinium importer:
>>
>>  stream has no properties
>>  stream was not parsed correctly
>>
>> etc.
>>
>> for the sake of reducing traslation strings, could you please add a %s
>> template variable string and reduce the strings accordingly?
>>
>> TIA
>>
>> Best regards
>>
> 
> 
> Better:
> If they are mainly messages like errors or not yet added features in import
> they should not be translatable.
> (for instance "Board6 stream is not fully parsed").
> 

I just removed the I18N mark of strings used in debug messages.

-- 
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] Please be kind towards translators

[jp charras]

Le 05/04/2020 à 10:49, Marco Ciampa a écrit :
> Hello devs,
> I often see many messages like those of the newly merged Altinium importer:
> 
>  stream has no properties
>  stream was not parsed correctly
> 
> etc.
> 
> for the sake of reducing traslation strings, could you please add a %s
> template variable string and reduce the strings accordingly?
> 
> TIA
> 
> Best regards
> 


Better:
If they are mainly messages like errors or not yet added features in import
they should not be translatable.
(for instance "Board6 stream is not fully parsed").

-- 
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] [commit 85c2e0d2] pcbnew/drc/drc_tree_model.cpp

[jp charras]

Le 04/03/2020 à 10:44, BERTRAND Joël a écrit :
>   Hello,
> 
>   With gcc version 9.2.1 20200224, current master compilation fails with :
> 
> /home/bertrand/git/kicad/pcbnew/drc/drc_tree_model.cpp:201:54: error:
> operands to ?: have different types ‘const wxString’ and ‘const wxChar*’
> {aka ‘const wchar_t*’}
>   201 | excluded ? _(
> "Excluded " ) : wxEmptyString,
>   |
> ~^~
> /home/bertrand/git/kicad/pcbnew/drc/drc_tree_model.cpp:201:54: note:
> and each type can be converted to the other
> 
>   This patch was introduced by 85c2e0d2. I haven't tried to build kicad
> with older version of gcc.
> 
>   Best regards,
> 
>   JB

I just committed a fix for that, and for other issues on Windows (colliding 
definitions)


-- 
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] Who has access to confidential issues?

[jp charras]

Le 28/02/2020 à 14:03, Seth Hillbrand a écrit :
> On 2020-02-28 04:59, Eeli Kaikkonen wrote:
> 
>> On Fri, Feb 28, 2020 at 1:55 PM jp charras > <mailto:jp.char...@wanadoo.fr>> wrote:
>>
>> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
>>
>>
>> -- 
>> Jean-Pierre CHARRAS
>>
>>  
>> That issue exists but is confidential. I have access to it ( I'm a 
>> maintainer in the bugsquad group) . But don't the developers have access to 
>> confidential issues? Obviously it shouldn't be so.
>  
> Developers have access.  But they do need to be logged into GitLab to see the 
> confidential issues.  @JP, @Tom, please let me know if you are and still 
> can't see the issue.
>  
> -S
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 

Yes, once logged I have access to this bug report.

-- 
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] pcbnew extremly slow

[jp charras]

Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
> BERTRAND Joël a écrit :
>> Seth Hillbrand a écrit :
>>
>>> Hi Joël-
>>>
>>> Please open an issue report at
>>> https://gitlab.com/kicad/code/kicad/issues and attach the project.
>>>
>>
>> Done.
>> https://gitlab.com/kicad/code/kicad/issues/3955
> 
>   I have simplified my schematic (I have deleted bus labels and grouped
> some subcircuits to reduce sheets by 4), result is the same.
> 

Calculation time is closely related to pad count, not sheet count.

Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.


-- 
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] Fedora build failures

[jp charras]

Le 17/02/2020 à 16:12, Steven A. Falco a écrit :
> The Fedora Copr builds are failing with the following error.  Is anyone else 
> seeing this?
> 
> Steve
> 
> cd /builddir/build/BUILD/kicad-r17610-2ca16c0b/qa/eeschema && /usr/bin/c++  
> -DBOOST_TEST_DYN_LINK -DDEBUG -DEESCHEMA -DGLM_FORCE_CTOR_INIT 
> -DHAVE_STDINT_H 

I committed the fix a few hours ago.
Compil should work now.


-- 
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] Internal units in the KiCAD source code

[jp charras]

Le 13/02/2020 à 20:08, jp charras a écrit :
> Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit :
>> Hi Johannes,
>>
>> Thank you for your suggestion but the internal units for each format
>> were chosen for a specific reason.  There really is no justifiable
>> reason to change them as they have been carefully selected based on the
>> requirements of the objects they represent.  Conversion code is provided
>> for each internal unit so plotting to standard units such as
>> millimeters, inches, etc is trivial.  I'm not opposed to adding support
>> for changing the plot units.  I am opposed to changing the internal units.
>>
>> Cheers,
>>
>> Wayne
> 
> I fully agree with Wayne.
> 
> Why these different units (I am talking only about coordinates, not angles):
> Pcbnew uses 1nm.
> Due to the fact a "int" is widely used in code for many calculations, the 
> actual size of a board is roughly
> INT_MAX / 1.414 with a margin: say INT_MAX/2.
> Why INT_MAX / 1.414?
> Because we need to calculate distances (and inside a square, the max dist is 
> INT_MAX / 1.414) and we also
> need margins.

Sorry:
the max dist is INT_MAX inside a square having a size of INT_MAX / 1.414

-- 
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] Internal units in the KiCAD source code

[jp charras]

Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit :
> Hi Johannes,
> 
> Thank you for your suggestion but the internal units for each format
> were chosen for a specific reason.  There really is no justifiable
> reason to change them as they have been carefully selected based on the
> requirements of the objects they represent.  Conversion code is provided
> for each internal unit so plotting to standard units such as
> millimeters, inches, etc is trivial.  I'm not opposed to adding support
> for changing the plot units.  I am opposed to changing the internal units.
> 
> Cheers,
> 
> Wayne

I fully agree with Wayne.

Why these different units (I am talking only about coordinates, not angles):
Pcbnew uses 1nm.
Due to the fact a "int" is widely used in code for many calculations, the 
actual size of a board is roughly
INT_MAX / 1.414 with a margin: say INT_MAX/2.
Why INT_MAX / 1.414?
Because we need to calculate distances (and inside a square, the max dist is 
INT_MAX / 1.414) and we also
need margins.
So I am expecting 1 nm allows boards up to 1 meter length, not much more.

From the max bord size  POV, 10nm is a better choice for board max size, but 
creates rounding issues during conversion
between inches and mm (see tools/test-nm-biu-to-ascii-mm-round-tripping.cpp)

*Do not expect* using a 64 bit coordinate: many calculations already use int64 
for intermediate calculations using int32 coordinates.
Especially our Clipper polygon library.

Gerbview uses 10nm because some Gerber files use large coordinates and the 
conversion between inches and mm
is not as important as in Pcbnew.

New Eeschema uses 100 nm because this is also a good choice for a schematic 
(some users use very larges sheet sizes)

> 
> On 2/13/20 9:32 AM, Johannes Pfister wrote:
>> The KiCAD code uses all kinds of different units for distances.
>> Amongst other things I found:
>>   nm: pcbnew internal units
>>   10nm: Gerbview internal units
>>   100nm EEschema internal units
>>   1um: PL-Editor internal units
>>   0.1mil (2.54um): SetViewport
>>   1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils
>> And the native File formats use mm (pcbnew) and mil (EEschema).
>> Something like SVG exports in 0.1 mil steps. I think that this is not
>> very consistent and something like a PLOTTER class needs to handle
>> different IU-sizes.
>>
>> My idea is to rewrite the internal units so that nm are used
>> everywhere inside the source code, and only parts that write or read
>> files and display data to or read data from the user should convert it
>> to another unit system. I don't want to change any file formats.
>> That would make it a bit more straightforward, more consistent, metric
>> and an SVG-Plotter would use a metric step size. The disadvantage
>> would be that there would be an about 2m or 4m limit in every
>> direction, assuming int is 32 bit, which is AFAIK true for all
>> platforms KiCAD current supports.
>>
>> Before i rewrite code, can you say what you guys think about it?
>>
>>
>> Johannes Pfister
>>
>> ___
>> 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
> 


-- 
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] Two patches to submit (eeschema)

[jp charras]

Le 10/02/2020 à 19:37, Ian McInerney a écrit :
> Sylwester,
> 
> Would it be possible for you to submit these are two merge requests to the 
> KiCad GitLab repository: https://gitlab.com/kicad/code/kicad/-/tree/master. 
> We have started to use the merge requests to better track and review the 
> patches that are submitted.
> 
> Thanks,
> -Ian
> 
> On Mon, Feb 10, 2020 at 5:27 PM Sylwester Kocjan  > wrote:
> 
> Hi,
> 
> I have two patches to submit:
> 
> 1. Three new types of sources have been implemented in dialog_spice_model.
> 
> 2. One minor bug is fixed (removing less than zero rows from grid)
> and one small improvement is added (ESC will close netlist window
> in simulation).
> 
> I'd appreciate if you could take a look at it and comment.
> 
> Best regards,
> Sylwester

Hi, Sylwester,

I have 2 remarks:
- patches need to be rebased to the latest master version.
They are clearly not up to date.
- I am not thrilled by quitting the simulator frame by Escape:
This is not a dialog.
This is a tool like the schematic editor or the symbol editor.

Thanks for you work.

-- 
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] Repeat request for help from icon maintainer.

[jp charras]

Le 04/02/2020 à 17:32, Brian Piccioni a écrit :
> JP
> 
> Thanks for this.
> 
> Unfortunately, inkscape and pngcrush seem to be a work in process on Msys.
> 
> If I install the package
> 
>     $ pacman -S mingw-w64-x86_64-inkscape
> 
> and run inkscape I get the error
> 
>     $ inkscape
>     C:/msys64/mingw64/bin/inkscape.exe: error while loading shared
> libraries: libpoppler-89.dll: cannot open shared object file: No such
> file or directory
> 
> If I build inkscape in MSYS and run make install I get
> 
>     [  0%] Built target potrace
>     make[2]: Entering directory '/home/bjpic/debug'
>     [  0%] Creating 48 pixel tall
> C:/msys64/home/bjpic/debug/bitmaps_png/tmp/wizard_add_fplib_icon.png
>     Unknown option --without-gui
>     [  0%] Creating 16 pixel tall
> C:/msys64/home/bjpic/debug/bitmaps_png/tmp/folder.png
>     Unknown option --without-gui
>     [  0%] Creating cleaned file
> C:/msys64/home/bjpic/kicad/bitmaps_png/png_16/folder.png
> 
> running inkscape --without-gui causes the same error.
> 
> Similarly, installing the pngcrush package in msys2 pacman -S
> mingw-w64-x86_64-pngcrush results in the warning
> 
> $ pngcrush
> Warning: versions are different between png.h and png.c
>   png.h version: 1.6.34
>   png.c version: 1.6.37
> 
> Making pngcrush under msys2 fails with a forced error.
> 
> In general it seems that many related utilities under Msys2 are a dogs
> breakfasts.
> 
> Perhaps for the moment it would be best if I simply made my bitmaps
> manually.
> 
> Brian
> 

I have no issues with inkscape and pngcrush.
However:
- Inkscape is installed from binaries coming from Inkscape site.
- pngcrush was built on msys2 by me from pngcrush sources.
This is a very small program and it is easy to build on msys2.
However, to build it, remove (or comment) the line 33 in zutil.h
"typedef long ptrdiff_t;  /* guess -- will be caught if guess is wrong */"
to avoid a conflict with a mingw included file.

the first useful line of my script running cmake is:
export PATH=$WXMSW:$PATH:/d/inkscape:/d/pngcrush

You will have to remove inkscape from msys2.

Attached, my msys2 script to run cmake.

Good luck...

> 
> On 2020-02-04 9:34 a.m., jp charras wrote:
>> Le 04/02/2020 à 15:06, Brian Piccioni a écrit :
>>> Hello
>>>
>>> I emailed earlier because when I follow the directions to create a new
>>> icon under MSYS2 it fails.
>>>
>>> This means that either
>>>
>>> 1) the directions are wrong or
>>> 2) I am following them incorrectly.
>>>
>>> Perhaps an icon maintainer can get in contact with me and work through
>>> this?
>>>
>>> I basically need to clone the icons annotate_right_down and
>>> annotate_down_right rotated 90, 180, and 270 degrees. Not complicated.
>>>
>>> thanks
>>>
>>>
>>> Brian
>> Hi Brian,
>>
>> To build the .cpp files the option MAINTAIN_PNGS must be set to ON in
>> makefiles.
>>
>> So:
>> 1 - To avoid cache issues, delete your current CMakeCache.txt file in
>> your build directory.
>> 2 - Run cmake as before, with option -DMAINTAIN_PNGS=ON to recreated the
>> makefiles
>>
>> After that you should be able to rebuild/create the .cpp bitmap files.
>>
> 
> ___
> 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
#! /bin/sh

rm -f CMakeCache.txt
WXMSW=/d/wxWidgets-3.1.3/Release_dll
export PATH=$WXMSW:$PATH:/d/inkscape:/d/pngcrush

KICAD_DIR=/e/kicad

OPT0=-DKICAD_SCRIPTING_ACTION_MENU=OFF
OPT1=-DKICAD_SCRIPTING=OFF
OPT2=-DKICAD_SCRIPTING_MODULES=OFF
OPT3=-DKICAD_SCRIPTING_WXPYTHON=OFF
OPT4=-DOPENSSL_ROOT_DIR=/mingw32
OPT5=-DBUILD_GITHUB_PLUGIN=ON
OPT6=-DMAINTAIN_PNGS=ON
OPT7=-DBUILD_SMALL_DEBUG_FILES=ON
OPT8=-DKICAD_SPICE=ON
OPT9=-DNGSPICE_ROOT_DIR=/c/Spice
OPT10=-DKICAD_USE_OCE=ON
OPT11=-DOCE_DIR=/g/opencascade/lib_oce/cmake
OPT12=-DKICAD_BUILD_QA_TESTS=OFF
#OPT13=-DKICAD_STDLIB_DEBUG=ON
OPT13=-DKICAD_STDLIB_LIGHT_DEBUG=ON
OPT14=-DKICAD_SANITIZE=OFF


INSTALL_DIR=-DCMAKE_INSTALL_PREFIX=$KICAD_DIR
PYTH_INST_DIR=-DPYTHON_SITE_PACKAGE_PATH=$KICAD_DIR/lib/python2.7/site-packages

#Debug Release Relwithdebinfo Minsizerel
#BUILD_TYPE=Debug
BUILD_TYPE=Release

cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=$BUILD_TYPE\
$OPT0 $OPT1 $OPT2 $OPT3 $OPT4 $OPT5 $OPT6 $OPT7 $OPT8 $OPT9 $OPT10 $OPT11 
$OPT12 $OPT13 $OPT14\
$INSTALL_DIR $PYTH_INST_DIR ../../
___
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] Repeat request for help from icon maintainer.

[jp charras]

Le 04/02/2020 à 15:06, Brian Piccioni a écrit :
> Hello
> 
> I emailed earlier because when I follow the directions to create a new
> icon under MSYS2 it fails.
> 
> This means that either
> 
> 1) the directions are wrong or
> 2) I am following them incorrectly.
> 
> Perhaps an icon maintainer can get in contact with me and work through
> this?
> 
> I basically need to clone the icons annotate_right_down and
> annotate_down_right rotated 90, 180, and 270 degrees. Not complicated.
> 
> thanks
> 
> 
> Brian
Hi Brian,

To build the .cpp files the option MAINTAIN_PNGS must be set to ON in
makefiles.

So:
1 - To avoid cache issues, delete your current CMakeCache.txt file in
your build directory.
2 - Run cmake as before, with option -DMAINTAIN_PNGS=ON to recreated the
makefiles

After that you should be able to rebuild/create the .cpp bitmap files.

-- 
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] Proper way to report bugs on branches

[jp charras]

Le 28/01/2020 à 17:15, jp charras a écrit :
> Le 28/01/2020 à 15:32, Seth Hillbrand a écrit :
>> No need.  It has already been reported with reproduction steps here
>> https://gitlab.com/kicad/code/kicad/issues/3811
>>
>> If you find a bug, use the standard bug reporting procedure but only
>> report bugs there that reproduce in master.
>>
>> If you find a bug that doesn't exist in master but does exist in the MR,
>> then add a thread to the MR with the reproduction steps.
>>
>> Thanks-
>> Seth
>>
> 
> In fact, issue 3811 is the result of an other (much more annoying) issue.
> 
> Each time you save your .sch files, the order of items inside the file
> is changed, even if you just load and save your schematic, without any
> actual change.
> 
> The result is:
> 
> - One cannot compare anymore the old and new file: they are very different.
> - Because the order of units of a given component in the file has
> changed, when the file is reloaded, the timestamp of the component in
> netlist changes (I am guessing this is the timestamp of the first unit
> found in list that is picked).
> 

After test:

This issue was created when replacing DLIST in Eeschema.


>> On 2020-01-28 08:04, Brian Piccioni wrote:
>>> Jp
>>>
>>> Actually, that is the bug: every time I hit F8 one or more of RN3,
>>> RN4, RN5, and RN6 are shown as new components on the PCB. It deletes
>>> the old RNs and put new ones with the same name.
>>>
>>> I got RN3, RN4 then RN3, RN4,  RN5 and RN6, then RN3, etc.
>>>
>>> Every time I hit F8 the thing rips up those RNs.
>>>
>>> This schematic has only had one sheet ever.
>>>
>>> I shall recompile the master branch and try and boil down the
>>> schematic to something simple to test.
>>>
>>> Brian



-- 
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] Proper way to report bugs on branches

[jp charras]

Le 28/01/2020 à 15:32, Seth Hillbrand a écrit :
> No need.  It has already been reported with reproduction steps here
> https://gitlab.com/kicad/code/kicad/issues/3811
> 
> If you find a bug, use the standard bug reporting procedure but only
> report bugs there that reproduce in master.
> 
> If you find a bug that doesn't exist in master but does exist in the MR,
> then add a thread to the MR with the reproduction steps.
> 
> Thanks-
> Seth
> 

In fact, issue 3811 is the result of an other (much more annoying) issue.

Each time you save your .sch files, the order of items inside the file
is changed, even if you just load and save your schematic, without any
actual change.

The result is:

- One cannot compare anymore the old and new file: they are very different.
- Because the order of units of a given component in the file has
changed, when the file is reloaded, the timestamp of the component in
netlist changes (I am guessing this is the timestamp of the first unit
found in list that is picked).

> On 2020-01-28 08:04, Brian Piccioni wrote:
>> Jp
>>
>> Actually, that is the bug: every time I hit F8 one or more of RN3,
>> RN4, RN5, and RN6 are shown as new components on the PCB. It deletes
>> the old RNs and put new ones with the same name.
>>
>> I got RN3, RN4 then RN3, RN4,  RN5 and RN6, then RN3, etc.
>>
>> Every time I hit F8 the thing rips up those RNs.
>>
>> This schematic has only had one sheet ever.
>>
>> I shall recompile the master branch and try and boil down the
>> schematic to something simple to test.
>>
>> Brian
>>
>>
>>
>> On 2020-01-28 3:36 a.m., jp charras wrote:
>>> Le 28/01/2020 à 01:10, Brian Piccioni a écrit :
>>>> Hello
>>>>
>>>> I have been using Kicad while working on re-annotation (hopefully
>>>> Alexander's merge request will soon be accepted and I can dust off
>>>> mine).
>>>>
>>>> I have been using branches of the current master. I have noticed a few
>>>> issues which I think are significant and not related to Alexander's
>>>> work
>>>> (or mine).
>>>>
>>>> For example, when I hit F8 in eeSchema to update my PCB it resolutely
>>>> demands to update some of my resistor network symbols unless I select
>>>> "Update footprint associations by existing references". This seems to
>>>> happen no matter how many time I let it update those RNs.
>>>>
>>>> Should I used the standard bug reporting system or is there a special
>>>> way to deal with these?
>>>>
>>>> Brian
>>> Components with multi units have one sheet path (unique ID) by unit.
>>> But a footprint has only one sheet path.
>>> So only one sheet path must be picked among candidates.
>>>
>>> Looks to me the way the sheet path is chosen has changed between stable
>>> and master version.
>>>
>>> This is an annoying change, but not an actual "bug".
>>> However fixing it is a good idea.
>>>
>>> My personal opinion is the:
>>> "Update footprint associations by existing references"
>>> should be the default.
>>> and the other option only used after re-annotation (the unique id is not
>>> an obvious parameter for users, because it is a "shadowed" parameter).
>>>
>>> Once the board is updated, you should not see this issue (of course
>>> using the same eeschema version).
>>>
>>
>> ___
>> 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
> 
> 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] Proper way to report bugs on branches

[jp charras]

Le 28/01/2020 à 01:10, Brian Piccioni a écrit :
> Hello
> 
> I have been using Kicad while working on re-annotation (hopefully
> Alexander's merge request will soon be accepted and I can dust off mine).
> 
> I have been using branches of the current master. I have noticed a few
> issues which I think are significant and not related to Alexander's work
> (or mine).
> 
> For example, when I hit F8 in eeSchema to update my PCB it resolutely
> demands to update some of my resistor network symbols unless I select
> "Update footprint associations by existing references". This seems to
> happen no matter how many time I let it update those RNs.
> 
> Should I used the standard bug reporting system or is there a special
> way to deal with these?
> 
> Brian

Components with multi units have one sheet path (unique ID) by unit.
But a footprint has only one sheet path.
So only one sheet path must be picked among candidates.

Looks to me the way the sheet path is chosen has changed between stable
and master version.

This is an annoying change, but not an actual "bug".
However fixing it is a good idea.

My personal opinion is the:
"Update footprint associations by existing references"
should be the default.
and the other option only used after re-annotation (the unique id is not
an obvious parameter for users, because it is a "shadowed" parameter).

Once the board is updated, you should not see this issue (of course
using the same eeschema version).

-- 
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] How to show pad in pcbnew by clicking pin in eeschema

[jp charras]

Le 20/01/2020 à 17:19, Jon Evans a écrit :
> This does appear to have broken at some point.  Filed an issue for it:
> https://gitlab.com/kicad/code/kicad/issues/3791
> 
> -Jon

Fixed.

> 
> On Mon, Jan 20, 2020 at 11:10 AM Dick Hollenbeck  > wrote:
> 
> Quick help,
> 
> When I click on a pin in eeschema I get the disambiguating menu and
> then I say "pin" choice.
> 
> But over in pcbnew I get all pads highlighted rather than the single
> pad corresponding to
> the pin.
> 
> This behaviour ain't like it used to be.  So is this broken or is
> there some other user
> action required to get the pad highlighted via cross-probing.
> 
> Thanks,
> 
> Dick

-- 
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] New Feature: Pad property.

[jp charras]

Hi All,

FYI, I just added a new feature, only used in Gerber files:
Pad property.


This is a pad property for fabrication, used in latest Gerber file
specification (copper layers plots and drill files)

Property is a pad info used mainly for fabrication or test.
Currently, supported properties are:
BGA property (variant of SMD pad)
Fiducial (global to the board or local to the footprint)
Test Point
Heat sink (for thermal pads)
Castellated.

They are attributes in Gerber files.
They are not used in the board editor.

Because the pad property (unless it is set to "none") modify the
kicad_pcb and/or kicad_mod files, this new feature is available only if:
UsePadProperty=1
is added in the "kicad_advanced" config file.

Note: "kicad_advanced" config file has an other option:
UsePinFunction=1
that stores (and displays) pin names in pads.
This info can be useful when routing a board, and are used in Gerber
placement files.

-- 
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] QA broken for arcs

[jp charras]

Le 03/01/2020 à 20:57, Seth Hillbrand a écrit :
> Hi Folks-
> 
> It looks like a recent commit broke the QA tests for Arc bbox checks.

Commit 5707e6eac should fix this issue.

> 
> 
> ../../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 KiCad Services Corporation Logo
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com     i...@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
> 


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

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 >> <mailto:jp.char...@wanadoo.fr>> 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 >> <mailto:s...@kipro-pcb.com>
>>> > <mailto:s...@kipro-pcb.com <mailto: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

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  <mailto:jp.char...@wanadoo.fr>> 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  <mailto:s...@kipro-pcb.com>
> > <mailto:s...@kipro-pcb.com <mailto: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
> >
> >     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)

[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  <mailto:jp.char...@wanadoo.fr>> 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  <mailto:s...@kipro-pcb.com>
> > <mailto:s...@kipro-pcb.com <mailto: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
> >
> >     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
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto: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
> <mailto: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)

[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] Question about gerber job file numeric format

[jp charras]

Le 28/12/2019 à 14:37, Mark Roszko a écrit :
> But that 1.600 is not a double/floating number, it  truncated from the
> double of 1.600088817841970012523233890533447265625
> 
> The entire complaint I believe is when it comes to serializing to JSON
> in 99% of software of all languages, you do not apply custom
> formatting to convert doubles to having less digits, you literally
> store the data type as is for what's considered a JSON "number".
> Otherwise we should be storing the float as string and applying the
> custom formatting in the conversion to string.

OK.

I am thinking we have to use a reasonable and readable notation (like in
all our kicad files).

To encode a board thickness,  1.600 is readable.
1.600088817841970012523233890533447265625 is just ridiculous
(for any value in a config file).

> 
> On Sat, Dec 28, 2019 at 8:01 AM jp charras  wrote:
>>
>> Le 24/12/2019 à 21:43, Jon Evans a écrit :
>>> OK, so both the JSON format itself and the Ucamco gerber format (which
>>> is not necessarily the same as the job file format, but hey) specify
>>> storing doubles.
>>> But, the examples in the Ucamco doc, and KiCad itself, do not store doubles.
>>>
>>> I have to imagine that the gerber job file format is so new that it
>>> isn't entrenched in anyone's workflow yet, and if it is, they are not
>>> relying on this quirk of KiCad's implementation (but anything is possible).
>>> The only way to get KiCad's behavior is through manual formatting of
>>> JSON, so anyone who writes software that parses job files through a JSON
>>> parsing library is going to have those values "upcasted" anyway.
>>>
>>> My personal opinion is that we should bite the bullet and change the
>>> behavior to comply with the standard (i.e. store doubles), and also
>>> suggest to Ucamco that they revise the job file spec to be more explicit
>>> about this.
>>>
>>> Perhaps JP should weigh in on this as well.
>>>
>>> -Jon
>>
>> Sorry for the delay.
>>
>> I am unsure to understand the meaning of
>> "KiCad itself do not store doubles"
>> (in gerber job files)
>>
>> A line like:
>> "BoardThickness":  1.600,
>>
>> stores a double:
>> AFAIK,  "1.600" is of course a floating number, and also a double, not
>> an integer.
>>
>> In job files, most of values (board sizes, layers thickness, clearances)
>> are "mechanical" values.
>>
>> A reasonable precision is the micron for this kind of parameters.
>>
>> No need to use nanometers.
>> So values are written using 3 digits for the mantissa.
>>
>> Using the notation:
>> "BoardThickness":  1600e-3,
>> is perfectly valid, but useless and less readable.
>>
>> FYI, using 6 digits (1 nanometer) in other Gerber files is needed to
>> avoid coordinates truncation.
>>
>> 3 digits is certainly enough to fabricate a board.
>> Unfortunately, truncation slightly modify polygon coordinates, and this
>> truncation can (and frequently does) create self intersecting polygons.
>> (self intersecting polygons are illegal).
>>
>> --
>> 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] Question about gerber job file numeric format

[jp charras]

Le 24/12/2019 à 21:43, Jon Evans a écrit :
> OK, so both the JSON format itself and the Ucamco gerber format (which
> is not necessarily the same as the job file format, but hey) specify
> storing doubles.
> But, the examples in the Ucamco doc, and KiCad itself, do not store doubles.
> 
> I have to imagine that the gerber job file format is so new that it
> isn't entrenched in anyone's workflow yet, and if it is, they are not
> relying on this quirk of KiCad's implementation (but anything is possible).
> The only way to get KiCad's behavior is through manual formatting of
> JSON, so anyone who writes software that parses job files through a JSON
> parsing library is going to have those values "upcasted" anyway.
> 
> My personal opinion is that we should bite the bullet and change the
> behavior to comply with the standard (i.e. store doubles), and also
> suggest to Ucamco that they revise the job file spec to be more explicit
> about this.
> 
> Perhaps JP should weigh in on this as well.
> 
> -Jon

Sorry for the delay.

I am unsure to understand the meaning of
"KiCad itself do not store doubles"
(in gerber job files)

A line like:
"BoardThickness":  1.600,

stores a double:
AFAIK,  "1.600" is of course a floating number, and also a double, not
an integer.

In job files, most of values (board sizes, layers thickness, clearances)
are "mechanical" values.

A reasonable precision is the micron for this kind of parameters.

No need to use nanometers.
So values are written using 3 digits for the mantissa.

Using the notation:
"BoardThickness":  1600e-3,
is perfectly valid, but useless and less readable.

FYI, using 6 digits (1 nanometer) in other Gerber files is needed to
avoid coordinates truncation.

3 digits is certainly enough to fabricate a board.
Unfortunately, truncation slightly modify polygon coordinates, and this
truncation can (and frequently does) create self intersecting polygons.
(self intersecting polygons are illegal).

-- 
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] [PATCH] Drop "const" that breaks Windows-specific code

[jp charras]

Le 06/12/2019 à 11:28, Simon Richter a écrit :
> ---
>  common/gestfich.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

I already fixed this issue.

-- 
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] What does "when in doubt do it opposite than certain other pcb tool" stand for?

[jp charras]

Le 26/11/2019 à 18:45, Seth Hillbrand a écrit :
> On 2019-11-26 09:43, Andy Peters wrote:
> 
>> On Nov 26, 2019, at 10:41 AM, Seth Hillbrand  wrote:
>>
>> On 2019-11-26 09:05, Tomasz Wlostowski wrote:
>> On 22/11/2019 17:42, Rene Pöschl wrote:
>> I would assume this is referencing version 6 of eagle. The current
>> versions of eagle are actually something that can (in some aspects) be
>> used as a good example. I would therefore assume that this sentence is
>> simply out of date and could be removed or at least reworded. I don't
>> have access to that webpage, but whoever has, feel free to
>> remove it.
>> Tom
>> _
> 
> Which website are we talking about?  I followed Rene's link but it just
> went to the Doxygen site and I don't see that statement there.
> It's here: http://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> -a
> 
> 
> Perfect, thanks Andy!  I've removed the section.  It will propagate to
> the website in a few hours.
> 
> -Seth
> 

Perfect.

FYI, you could see this sentence just like a private joke between CERN
guys and core developers when it was written, about trying to mimic an
existing ECAD tool.

-- 
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] GitLab migration

[jp charras]

Le 25/11/2019 à 17:53, Kevin Cozens a écrit :
> On 2019-11-25 11:03 a.m., Seth Hillbrand wrote:
>> 2FA would be using something like Google Authenticator on your phone,
>> a YubiKey or SMS message code to verify your login on a computer in
>> addition to the password.
> 
> It may not affect me as I'm a user of KiCad and occasional reporter of
> bugs. What gitlab activities would require 2FA? Reading the link
> supplied about 2FA says it would send a message to a phone. I don't
> have, or want, a cell phone. How would requiring 2FA affect others
> without a cell phone who want to use the gitlab repo site?
> 

I am also like Kevin:
I don't have, or want, a cell phone (or any Google account).

A simple password is not perfect, but at least it is easy to use and
works from any computer install.
Kicad gitlab repo is for a FOSS development.
It is not for Fort Knox access management.

-- 
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] Using OPT types

[jp charras]

Le 24/11/2019 à 18:09, Wayne Stambaugh a écrit :
> On 11/24/19 7:12 AM, Jeff Young wrote:
>> Personally I hate OPT (because it’s somewhat harder to read and 
>> more-than-somewhat harder to debug).
> 
> I tend to agree with Jeff.  The older I get, the less I like having to
> dig around the code base to figure out what is going on because
> templated code does tend to be less fun to debug.
>>
>> I also dislike auto, except in the case of stl::’s overly-verbose iterators. 
>>  Again, they make the code harder to read more often than not.
> 
> I'm seriously rethinking typedefs as well.  I can never seem to remember
> the type they represent so I have to dig around the source to figure out
> the actual type.  I'm thinking just typing out the full type is easier
> in the shortened typedefed version which was most likely only created to
> save some typing.
> 
>>
>> Maybe I’m just showing my age….
> 
> Funny how age changes your perspective.
> 

I full agree with Jeff and Wayne:
auto (and OPT) obfuscate the code.
As Jeff said, auto is useful only in the case of stl::’s overly-verbose
iterators.

I already had to fix bugs in code using auto due to this obfuscation.

>>
>>> On 24 Nov 2019, at 11:13, Ian McInerney  wrote:
>>>
>>> What is the current consensus on using OPT types in the code? I know there 
>>> are some instances where we are already using them from the Boost library 
>>> (since our C++ version isn't high enough to include them), but is that 
>>> considered a good type to use more of?
>>>
>>> I am curious, because I am thinking of replumbing the position storage in 
>>> the tool events to use OPTs for the position, because that will allow for 
>>> cleaner handling of the position in the tools, and also because I need to 
>>> pass the positions into the selection routines, and being able to pass an 
>>> OPT will greatly simplify things (I think).
>>>
>>> -Ian


-- 
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] Back annotate references from PCB

[jp charras]

Le 24/11/2019 à 07:58, Alexander Shuklin a écrit :
> Hi Eeli and Brian,
> Sorry for delay, unfortunately I cannot answer too often.
> 
>> It has occurred to me (Alexander please chime in) that once back annotation 
>> has been solved subject to all the issues raised by Wayne and others that it 
>> would be a general solution.
> 
> Unfortunately no. All stuff mentioned by Wayne is has to be
> implemented in back-annotation, that's situations which back
> annotation will have to care about, otherwise it will be crap. I meant
> I see some general tool as geometrical (geographical?) re-annotation
> in pcbnew, which do left->right top->down or opposite directions being
> in C++ GUI, but if you want re-annotate in some different manner, you
> are free to use python scripts, as you could easily back annotate
> after that.
> 
>> Can this do other kinds of changes than just annotation? I'm thinking of 
>> changing the footprint or value
> 
> Of course that's possible, and not a big deal to add this into
> back-annotation algorithm. I just think how to do it better. I would
> say we will need to have some GUI for that then. I mean, you probably
> want to choose what do you want to back-annotate... or maybe not. And
> unfortunately at this point you cannot do that with python, as there
> no python scripts in schematic editor. If it will be useful, I can do
> that of course. Eeli, what I would suggest, I believe in few days I
> will make draft commit and mark it (Work In Progress) to show how It
> works, and we could discuss how it's gonna work with values and
> footprints it will not be a big deal to change it.

Back annotation imply undo/redo feature.
It locks like it will be not trivial.

> 
> On Sat, 23 Nov 2019 at 21:03, Brian Piccioni
>  wrote:
>>
>> It has occurred to me (Alexander please chime in) that once back annotation 
>> has been solved subject to all the issues raised by Wayne and others that it 
>> would be a general solution.
>>
>>
>>
>> Of course, this would end up being a sizeable change to Kicad since the 
>> various edit functions, etc., who have to be modified to incorporate the 
>> feature.
>>
>>
>>
>> Like you I often fiddle with different packages and values and I typically 
>> switch to eeSchema, make the change, then hit F8 to update the PCB. It seems 
>> to me it would be easier for the appropriate changes to simply be reflected 
>> back to the schematic.
>>
>>
>>
>> Brian
>>
>>
>>
>> From: Eeli Kaikkonen
>> Sent: November 23, 2019 12:56 PM
>> To: kicad-developers
>> Subject: Re: [Kicad-developers] Back annotate references from PCB
>>
>>
>>
>>
>>
>>
>>
>> la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) 
>> kirjoitti:
>>
>> By having a single integrated tool analogous to “Update PCB From Schematic” 
>> can ensure coherency.
>>
>> Can this do other kinds of changes than just annotation? I'm thinking of 
>> changing the footprint or value. For example I could use Change Footprint 
>> feature in pcbnew and propagate that change to eeschema. That's not so 
>> difficult to do in eeshcema and update the board, but often it would feel 
>> much more natural to e.g. test if 0402 R package would be physically better 
>> for some situation than 0603 and then update the shcematic based on the 
>> board if it fits.
>>
>>
>>
>> Eeli Kaikkonen
>>
>>
>>
>> ___
>> 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
> 


-- 
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] INFO: added a enhancement: schematic pin function stored in pads.

[jp charras]

I just added a enhancement in Pcbnew:
After updating the PCB from schematic, the pin names (pin functions) are
now stored in Pads.

When not empty, they are shown in the message panel (bottom of the pcb
editor frame) among other pad settings (like netname).

This enhancement is due to the fact Gerber files can use (in the
metadata parameters) this info (it is shown by Gerbview) and Pick and
Place files in Gerber format also use this info.
In P files it is especially useful to help to verify is some
components (like diodes, polarized capacitor) are correctly oriented.

However, because storing pin function in pads modify the .kicad_pcb file
format, currently this new info is saved in files *only* if the line
UsePinFunction=1
is added to the "kicad_advanced" config file, in the folder where other
kicad config files are stored.
(until this enhancement is fully tested and fully defined)
If stored, the .kicad_pcb file is no longer readable by "old" versions.

.kicad_mod files do not store this info, as it is closely linked to the
net info, so no change for them.


-- 
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] Back annotate references from PCB

[jp charras]

Le 23/11/2019 à 00:05, ja...@veith.net a écrit :
>> On 22.11.19 21:12, Wayne Stambaugh wrote:
>> What Jeff described is the simplest case.  Where things really get
>> interesting is when you start sharing schematic files between projects.
> 
> Imho multiple use of a schematic requires separate instance data.
> Similar problem for the recently discussed variant/do not fit where
> the values are different instead reference designators. Could imagine
> both, e.g. a filter circuit used multiple times for different frequency
> whether its on the same board or not. If used outside project, the
> project file could link instance data to schematic. Penalty is not
> having complete schematics in one file.

I agree: sharing the same schematic file between projects projects is
the best way to break the projects.

For instance:
- projects can have different libraries using the same library nickname,
and having different symbols having the same lib id between projects.
- alternate references (AR lines) exist only for complex hierarchies
when the same file has more than one instance in the same project
- when the hierarchy is not complex, only the F0 field (reference)
stores the reference.
So, changing it in a project breaks the other project if this sheet is
shared between projects.
And there are more subtle cases (what about swapping 2 units in a
multi-unit component in a project?)

So sharing a sheet file between projects is just madness.

-- 
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] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

[jp charras]

Le 11/11/2019 à 01:12, Ian McInerney a écrit :
> JP,
> 
> Are you running this on your 3.0 or 3.1 build of wxwidgets? That looks
> like there is an issue with their autosize calculation not factoring in
> the width of the sorting bitmap.
> 
> -Ian
> 

I am using wxWidgets 3.1.3 currently.

(I sometimes rebuild Kicad with wxPython on wxWidgets 3.0.4, for tests)


> On Thu, 7 Nov 2019, 14:37 jp charras,  <mailto:jp.char...@wanadoo.fr>> wrote:
> 
> Le 06/11/2019 à 23:18, Mikołaj Wielgus a écrit :
> > Hello,
> >
> > I have submitted two patches on Launchpad some time ago. I would
> like to
> > ask for feedback.
> >
> > Links:
> > https://bugs.launchpad.net/kicad/+bug/1841144
> > https://bugs.launchpad.net/kicad/+bug/1016464
> >
> > Best Regards,
> > Mikołaj Wielgus
> 
> Hi Mikołaj,
> 
> First, thanks for your contribution.
> 
> I had a look into your patches.
> 
> I do not seen big problems, but I suggest a few enhancements:
> -  Project manager multiple selection options:
> When deleting a list of files, a confirmation is asked for each file.
> Only one confirmation is enough.
> When deleting a list of files, a instance of the editor is opened for
> each file.
> All editors are able to open more than one file, so I suggest only one
> instance of the editor opening all files.
> 
> - Pcbnew drill sizes statistics:
> It display pads with no holes. The filter to select pads:
> if( pad->GetAttribute() != PAD_ATTRIB_SMD )
> is incorrect
> (other pads can have no hole).
> the filter must test only the hole size.
> A minor cosmetic issue:
> The columns sizes are too small:
> When sorting a column, the column label is not readable (see X size
> column in attached files).
> 
> They are minor issues.
> Can you fix them.
> 
> Thanks.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> <mailto: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] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

[jp charras]

Le 11/11/2019 à 01:04, Mikołaj Wielgus a écrit :
> - Pcbnew drill sizes statistics:
> I've modified the filter and also made the last two columns expand to
> fit the remaining space during grid creation and window resizing.
> 
> As for the column sizes: they are assigned with the wxGrid::AutoSize()
> method built-into WxWidgets. Because of that, I'm reluctant to add any
> arbitrary values to the column sizes. Also, it's not uncommon for column
> widths to be partially concealed in GUI applications (they sometimes
> take a lot more space than the table values themselves). The grid is
> resizable, so if the user wants to check the label, they will be able to
> resize it easily.
> 
> Furthermore, on my operating system, I don't have my column labels
> concealed when sorted.
> 
> Because of this, I think it will be better if you tweak the column
> widths yourself to make them work as desired in your environment (if you
> aren't convinced by my argument). This can be done easily by iterating
> over all columns and adding a constant to each one's width right after
> the m_gridDrills->AutoSize(); line.
> 
> Please let me know if you have any better idea how to address this.
> 
> Best Regards,
> Mikołaj Wielgus
> 

Hi Mikołaj,

Thanks for your contribution.

I committed your patch (with a minor change to avoid a wxWidgets alert).

AFAIK, we always have some issues with column sizing in wxGrid
(depending on the platform and wxWidgets version)

In this case, this sizing problem is a minor issue.

> 
> On Thu, Nov 7, 2019 at 3:37 PM jp charras  <mailto:jp.char...@wanadoo.fr>> wrote:
> 
> Le 06/11/2019 à 23:18, Mikołaj Wielgus a écrit :
> > Hello,
> >
> > I have submitted two patches on Launchpad some time ago. I would
> like to
> > ask for feedback.
> >
> > Links:
> > https://bugs.launchpad.net/kicad/+bug/1841144
> > https://bugs.launchpad.net/kicad/+bug/1016464
> >
> > Best Regards,
> > Mikołaj Wielgus
> 
> Hi Mikołaj,
> 
> First, thanks for your contribution.
> 
> I had a look into your patches.
> 
> I do not seen big problems, but I suggest a few enhancements:
> -  Project manager multiple selection options:
> When deleting a list of files, a confirmation is asked for each file.
> Only one confirmation is enough.
> When deleting a list of files, a instance of the editor is opened for
> each file.
> All editors are able to open more than one file, so I suggest only one
> instance of the editor opening all files.
> 
> - Pcbnew drill sizes statistics:
> It display pads with no holes. The filter to select pads:
> if( pad->GetAttribute() != PAD_ATTRIB_SMD )
> is incorrect
> (other pads can have no hole).
> the filter must test only the hole size.
> A minor cosmetic issue:
> The columns sizes are too small:
> When sorting a column, the column label is not readable (see X size
> column in attached files).
> 
> They are minor issues.
> Can you fix them.
> 
> Thanks.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> <mailto: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] [PATCH v3] [NEW] eeschema: Allow hierarchy navigator to stay open

[jp charras]

Le 10/11/2019 à 17:33, Franck Jullien a écrit :
> Le jeu. 7 nov. 2019 à 21:51,  a écrit :
>>
>> From: Franck Jullien 
>>
>> User can now decide to keep the hierarchy navigator open while working
>> on a schematic. This behavior can be configured in
>> eeschema->preferences->eeschema->Editing options.
>>
>> Signed-off-by: Franck Jullien 
>> ---
>>
>> v2: fix coding style
>> v3: fix memory leak after Wayne review
> 
> I need to work on it again. If the navigator stays open and you add a
> new page, the hierarchy is not updated.
> I'll be back with a v4 :)
> 
> Franck.

Hi Franck,

This is the main problem with not modal dialogs: they have to take in
account changes made in an other frame, and this is not always easy.

(Here: adding/renaming/deleting a hierarchical sheet)

Remember: your patches must be in a attached file.
Patch texts inside a mail cannot be used (are broken for patch utilities).


-- 
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] Symbol library code changes

[jp charras]

Le 06/11/2019 à 21:34, Wayne Stambaugh a écrit :
> I finally finish up the initial attempt at simple inheritance for the
> symbol library code.  The change is non-trivial and will likely have
> some unexpected side affects that I missed.  I pushed the branch to my
> personal repo[1] and I would like a few pair of extra eyes on it before
> I merge it into master.  If you prefer, I can set up a merge request
> from this branch in Launchpad.
> 
> The biggest user facing change is that the concept of aliases is gone
> which means internally, the LIB_ALIAS object has been removed and all of
> the information it managed was moved into LIB_PART.  This actually
> simplified some of the UI code but made the LIB_MANAGER and LIB_PART
> object code more complicated.  The symbol library editor works
> significantly different now.  When you select a derived part (formerly a
> LIB_ALIAS), it will show the parent symbol that it was derived from
> darkened and all of the edit features disabled.  Until the new symbol
> file format is done and writing to the legacy symbol file format is
> deprecated, this restriction will have to remain in place.  The
> properties editor no longer has an aliases panel and is limited to what
> it can change in the derived or parent symbols depending on which symbol
> is currently being edited.  I suspect this will be the biggest stumbling
> block for existing users so if you can think of a better way to handle
> this, I'm open to suggestion.  The other thing that I am concerned about
> is symbol library editing.  There were a lot of LIB_MANAGER object
> changes which I am not 100% confident in.
> 
> Just a couple of other internal changes to be aware of:
> 
> A flattened copy of the symbol is used in SCH_COMPONENT instead of
> relying on the weak reference to the library symbol.  This way we don't
> have to worry about the shared pointer disappearing and causing issues.
> However, this will require that we be diligent about updating modified
> symbol libraries in the schematic.  Otherwise, the schematic could
> change the next time it is loaded.  I'm open to changing this back if we
> think it's going to be an issue.
> 
> There is now a compare function for the LIB_PART object which can be
> rather tricky.  I created a new test suite inside the current LIB_PART
> test file so if you change anything, please run the test to ensure
> nothing gets broken.  I also added a bunch of other new tests for the
> LIB_PART object.
> 
> I added code to DIALOG_SHIM to allow the caller to reset the last dialog
> size when hiding dialog control state changes between dialog instances.
> We have some dialog windows that are not the correct default size
> depending on which controls are shown so there is now a convenient way
> to address this.
> 
> Please let me know if you find anything so I can get it fixed and merged
> into master.  The next step is to convert the schematic internal units
> from 1mil to 10nm.  Once that step is complete, I will knock out the new
> symbol library format.  Thanks in advance for the help.
> 
> Cheers,
> 
> Wayne
> 
> [1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge
>

Hi Wayne,

I did not really have a look into the code, but I encountered an issue
in DIALOG_EDIT_COMPONENT_IN_LIBRARY dialog: the page 0 is incorrectly
drawn (the page 1 is drawn as background of page 0).

Attached a patch that fixes this issue (already encountered in
simulation options frame).

To remove a page from a wxNotebook, using Hide() is incorrect: one can
hide a widget inside a page, not the page itself.
(RemovePage must be used instead)

Hide() the panel can work on some platforms, but not all.
Moreover Show() the panel draws this panel in the background of the
active panel!
Strange result...

Thanks.

-- 
Jean-Pierre CHARRAS
 eeschema/dialogs/dialog_edit_component_in_lib.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/eeschema/dialogs/dialog_edit_component_in_lib.cpp 
b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
index 0e3edcf67..2add8156c 100644
--- a/eeschema/dialogs/dialog_edit_component_in_lib.cpp
+++ b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
@@ -684,10 +684,11 @@ void DIALOG_EDIT_COMPONENT_IN_LIBRARY::OnSizeGrid( 
wxSizeEvent& event )
 
 void DIALOG_EDIT_COMPONENT_IN_LIBRARY::syncControlStates( bool aIsAlias )
 {
+// Remove the not wanted notebook page.
+// *Do not use* Hide(), it is suitable to hide a widget,
+// but it is not suitable to hide a notebook page (that is not a widget)
 if( aIsAlias )
-m_PanelFootprintFilter->Hide();
-else
-m_PanelFootprintFilter->Show();
+m_NoteBook->RemovePage( 1 );
 
 bSizerLowerBasicPanel->Show( !aIsAlias );
 bButtonSize->Show( !aIsAlias );
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : 

Re: [Kicad-developers] LOCALE_IO thread-local

[jp charras]

Le 21/06/2019 à 23:25, Seth Hillbrand a écrit :
> Hi Devs-
> 
> We currently have an RAII locale switch (LOCALE_IO) that swaps the
> global locale to allow floating point handling with decimal points
> instead of a commas.  Because it changes the global locale, we need to
> be very careful about allowing the user interface to update during the
> time that it is temporarily set.
> 
> The attached patch moves the locale setting into a thread-local setting,
> allowing us to use standard threading and UI updates.
> 
> There are no functionality changes in this patch.  This is merely a
> change in the calling structure that will allow future cleaning of the
> LOCALE_IO distribution in the code.
> 
> I'd greatly appreciate any windows testing.
> 
> Thanks-
> Seth

Hi Seth,

What is the status of this change?

-- 
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] New lead developer announcement

[jp charras]

> On 11/7/19 12:14 PM, Wayne Stambaugh wrote:
>> I am happy to announce that the KiCad project now has a new member of
>> the lead development team.  Ian McInerney has accepted an invitation to
>> become a member of the lead development team.  Ian's contributions have
>> earned him this privilege and we are grateful for his efforts.  Please
>> join me in congratulating Ian and welcoming in his new role.
>>
>> Cheers,
>>
>> Wayne

Welcome, Ian.


-- 
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] [PATCH] Pcbnew drill sizes statistics & Project manager multiple selection options

[jp charras]

Le 06/11/2019 à 23:18, Mikołaj Wielgus a écrit :
> Hello,
> 
> I have submitted two patches on Launchpad some time ago. I would like to
> ask for feedback.
> 
> Links:
> https://bugs.launchpad.net/kicad/+bug/1841144
> https://bugs.launchpad.net/kicad/+bug/1016464
> 
> Best Regards,
> Mikołaj Wielgus

Hi Mikołaj,

First, thanks for your contribution.

I had a look into your patches.

I do not seen big problems, but I suggest a few enhancements:
-  Project manager multiple selection options:
When deleting a list of files, a confirmation is asked for each file.
Only one confirmation is enough.
When deleting a list of files, a instance of the editor is opened for
each file.
All editors are able to open more than one file, so I suggest only one
instance of the editor opening all files.

- Pcbnew drill sizes statistics:
It display pads with no holes. The filter to select pads:
if( pad->GetAttribute() != PAD_ATTRIB_SMD )
is incorrect
(other pads can have no hole).
the filter must test only the hole size.
A minor cosmetic issue:
The columns sizes are too small:
When sorting a column, the column label is not readable (see X size
column in attached files).

They are minor issues.
Can you fix them.

Thanks.


-- 
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] KICAD_USE_FONT_REDUCED_SET question

[jp charras]

Le 19/10/2019 à 07:03, Seth Hillbrand a écrit :
> On 2019-10-09 02:26, jp charras wrote:
>>
>> Hi Seth,
>>
>> Here is a test showing the memory used by pcbnew, with and without CJK
>> font (I used the Windows monitor resources):
>>
>> Initial state:
>> Available memory: 2280 Mb
>> Kicad is compiled in Release version.
>>
>> pcbnew loaded, without CJK:
>> Available memory: 2153 Mb
>> pcbnew + fp viewer loaded, without CJK:
>> Available memory: 2139 Mb
>> Pcbnew+Eeschema, without CJK:
>> Available memory: 2060 Mb
>>
>> pcbnew loaded, with CJK:
>> Available memory: 1590 Mb
>> pcbnew + fp viewer loaded, without CJK:
>> Available memory: 1537 Mb
>> Pcbnew+Eeschema, with CJK:
>> Available memory: 1176 Mb
>>
>> So, the CJK font takes roughly 900Mb at run time when runnning Eeschema
>> + Pcbnew.
>>
>> It explains why I am running out of memory.
>> There is certainly room for optimization.
>>
> 
> Hi JP-
> 
> I pushed an optimization for this.  Can you let me know if it helps the
> memory usage for you?
> 
> Best-
> Seth
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 

Hi Seth,

This is *much* better, now.

The memory test gives:

Initial state: Available memory: 2527 Mb
 Kicad is compiled in Release version.

pcbnew loaded, with CJK:
 Available memory: 2365 Mb
 pcbnew + fp viewer loaded, with CJK:
 Available memory: 2349 Mb
 Pcbnew+Eeschema, with CJK:
 Available memory: 2260 Mb

Thanks.

-- 
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] Should gerber files in protel format use same name? (PATCH?)

[jp charras]

Le 16/10/2019 à 09:36, Nick Østergaard a écrit :
> A related issue was brought up on
> https://forum.kicad.info/t/gerber-filenames-with-protel-extensions/14177
> 
> I think the manufacturer should only make it a warning not an error. I
> assume their reasoning is that they want to make sure only one project
> is embedded in the gerber package they have, but I don't think that is
> a fair way to determine if it is the same project.
> 
> I think having the layer names in the file name helps to verify that
> the layer is correct when viewed in a gerber viewer.
> 
> I don't think the patch is good as is, as it changes the behaviour of
> the protel file name extensions unconditionally. I think it should be
> added as a option, but we already do have a lot of options. I think
> you are better of using a python script for plotting and packing it up
> as you like it. See for example
> https://github.com/KiCad/kicad-source-mirror/blob/master/demos/python_scripts_examples/gen_gerber_and_drill_files_board.py
> 
> Don't your fab support X2 and gerber job files?
> 
I agree with Nick:

Protel extensions is outdated (and inconsistent) since a long time.

Please use X2 support and Gerber job files.

"they demand drill files to be same precision as gerbers (for example
4:5). Can you confirm that proper Excellon format should be 3:3 precision"

I confirm the best format is the decimal format, not x:y format.
Excellon files have no way to specify the format actually used in files.

The only one doc on Excellon format (this is a user manual of a CNC
machine) says the metric format is 3:3 (units = micrometer) or 3:4 (or
of course decimal format that avoid this issue.

The Excellon format is not related to Gerber format (they are 2
different formats, although based on G commands)

For recent doc on drill files see:
https://www.ucamco.com/files/downloads/file/305/the_xnc_file_format_specification.pdf

Looks to me your manufacturer want files just like Altium does.
But Kicad is not Altium.


> On Wed, 16 Oct 2019 at 09:16, Alexander Shuklin  wrote:
>>
>> Hi,
>> sorry, I'm not quite sure with that topic, as I never worked with
>> protel gerber format before. My PCB manufacturer started to use some
>> online tool to check gerbers
>> (https://www.frontline-pcb.com/products/sales/insight-pcb-overview.html)
>> and now they demand to send them files with protel extensions. But
>> that tool expect all files with same name. But now if you switch "use
>> protel extensions" in KiCad, it generate something like :
>> project_name-F_Cu.gtl
>> project_name-B_Cu.gbl
>> If "project_name.gtl" is the proper way, can you please apply my patch?
>> btw, Altium creates similar to "project_name.gtl"
>>
>> And another question:
>> For some reason they demand drill files to be same precision as
>> gerbers (for example 4:5). Can you confirm that proper Excellon format
>> should be 3:3 precision? In that case, I would send bug report to
>> them.
>> ___
>> 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
> 


-- 
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] Footprint keepout zone merge review

[jp charras]

Le 09/10/2019 à 00:00, Wayne Stambaugh a écrit :
> Seth,
> 
> Please let me finish testing and reviewing the latest changes before you
> merge it.  Sorry about the delay in responding.  I have been busy
> putting the finishing touches on the LIB_PART refactor for the upcoming
> symbol library file format changes.  I should have an answer by the end
> of the day tomorrow.
> 
> Cheers,
> 
> Wayne
> 

Unfortunately, I have crashes if I add a zone keepout to a footprint,
and trying to refill zones, or move the footprint or undoing the editon
(not always exactly the same command, but always crashes in one of these
commands.

To reproduce:
- Load pic_programmer demo board.
- edit P3 (Ctrl+E)
- add a keepout zone on F.Cu+B.Cu and Keep out tracks, vias and zones.
- save in board.
- Try to refill zones (and or move P3) and if no crash try undo change.

It crashes every time on my W7-32bits install.

By the way: the zone keepout layer choice is F.Cu and/or B.Cu
The All copper layer option should be added.


> On 10/8/19 5:13 PM, Seth Hillbrand wrote:
>> Hi Folks-
>>
>> There's a merge request from Ross Schlaikjer[1] that looks like it is
>> ready for merging.  I've looked it over and the current version looks
>> ready.  This is a file format change, so I'd like to get a second set of
>> eyes before we push.
>>
>>
>> There's some auto-format stuff that I'll clean up in the merge, so this
>> request is just for functionality and/or implementation comments.
>>
>>
>> Thanks-
>>
>> Seth
>>
>>
>> [1] 
>> https://code.launchpad.net/~ross-schlaikjer/kicad/+git/kicad/+merge/361410
>>
>>
>>  
>>
>> Seth Hillbrand
>>
>> Chief Technologist
>>
>> KiCad Services Corporation
>>
>> Twitter Twitter        LinkedIn 
>> LinkedIn
>>     
>>

-- 
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] KICAD_USE_FONT_REDUCED_SET question

[jp charras]

Le 07/10/2019 à 20:07, Seth Hillbrand a écrit :
> Hi JP-
> 
> 
> I noticed that you added an option to disable the CJK ideographs
> in 34b26a0ac because you were seeing out of memory issues under OpenGL. 
> The stroke fonts should only be loading on the system heap (4.5MB for
> the current CJK set), so if it's leaking into the video memory, I'd like
> to address that.
> 
> 
> Can you provide additional information about the symptoms you are seeing
> and I can see about fixing this?
> 
> 
> Thanks!
> 
> Seth
> 

First, note I am using a Windows 32 bits (4Gb of managed memory)
I did not yet tested it on my Linux install (a 64 bits version + 8Gb memory)

Debugging this kind of issue is not easy on Windows, due to the poor
performances of gdb under msys.

The crash happens most of time when opening (using opengl) eeschema +
board editor + the footprint viewer (or the footprint editor) and does
not depend on the loaded project (a empty project crashes).

It never happens with the previous font (no CJK ideographs)

It happens not always at the same point so if a error message is
displayed (it happens sometimes), it is not always the same.

I tried to see what happens under gdb.

I am sure I had a out of memory on a malloc call and a crash at:
noncached_container.cpp, line 41

I also am pretty sure I had a out of memory on a malloc in
cached_container_ram.cpp in CACHED_CONTAINER_RAM ctor.

I am thinking, but I am not sure, I saw also a leaking into the video
memory, but most of crashes look like this is a main memory leak.

The stroke fonts data is loaded on the system heap, but I am thinking it
generate *much more* memory allocation (hundred of Mb allocated) to be
drawn by the opengl engine.

(I do not have issues if Eeschema uses the Cairo engine)

I'll try to make more tests and try to provide additional information,
and see the memory allocation difference between CJK and non CJK fonts.

Thanks.

> 
> 
>   
> 
> Seth Hillbrand
> 
> Chief Technologist
> 
> KiCad Services Corporation
> 
> Twitter Twitter     LinkedIn 
> LinkedIn
>  
> 
>               
> 
>   +1 530 302 5483  | +1 212 603 9372 
> 
>   www.kipro-pcb.com 
>   Davis, CA


-- 
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] [Patch] Update build documentation with debugging options

[jp charras]

Le 05/10/2019 à 19:11, Ian McInerney a écrit :
> This is purely a documentation update for the dev docs. It adds the new
> debugging options that enable GLib assertions, the Address Sanitizer and
> Valgrind support into the documentation so they are accessible and
> documented.
> 
> -Ian
> 

I committed your patch.
Thanks for your contribution.


-- 
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] Commit 0a829c328e90f550994a7660b310630a5aa02361 not compiling ("undefined reference to `PgmOrNull()'")

[jp charras]

Le 05/10/2019 à 12:20, Dino Ghilardi a écrit :
> Hello,
> 
> Latest commit (master branch) is not compiling giving an
> "undefined reference to `PgmOrNull()'" error during make

Should be fixed now.

> 
> I tried also using:
> git clean-fx
> make clean
> cmake ../
> make -j7
> 
> may be something is missing from the commit?
> 
> Platform: Debian Linux.
> Commit 0a829c328e90f550994a7660b310630a5aa02361.
> 
> Full error Message:
> 
> ../../../common/libpcbcommon.a(class_board.cpp.o): In function
> `BOARD::ComputeBoundingBox(bool) const':
> class_board.cpp:(.text+0x1ec9): undefined reference to `PgmOrNull()'
> class_board.cpp:(.text+0x1ed7): undefined reference to `PgmOrNull()'
> ../../../common/libpcbcommon.a(class_board.cpp.o): In function
> `BOARD::ComputeBoundingBox(bool) const [clone .constprop.440]':
> class_board.cpp:(.text._ZNK5BOARD18ComputeBoundingBoxEb.constprop.440[_ZNK5BOARD14GetBoundingBoxEv]+0x2d6):
> undefined reference to `PgmOrNull()'
> class_board.cpp:(.text._ZNK5BOARD18ComputeBoundingBoxEb.constprop.440[_ZNK5BOARD14GetBoundingBoxEv]+0x2e4):
> undefined reference to `PgmOrNull()'
> collect2: error: ld returned 1 exit status
> qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/build.make:328:
> recipe for target 'qa/gal/gal_pixel_alignment/test_gal_pixel_alignment'
> failed
> make[2]: *** [qa/gal/gal_pixel_alignment/test_gal_pixel_alignment] Error 1
> CMakeFiles/Makefile2:4060: recipe for target
> 'qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/all'
> failed
> make[1]: ***
> [qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/all]
> Error 2
> Makefile:149: recipe for target 'all' failed
> 
> 
> 
> Cheers, Dino
> 


-- 
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] Commit 0a829c328e90f550994a7660b310630a5aa02361 not compiling ("undefined reference to `PgmOrNull()'")

[jp charras]

Le 05/10/2019 à 13:07, Ian McInerney a écrit :
> I am somewhat confused by the reason for needing to introduce the new
> function in that commit. Does this crash happen when running the Python
> from inside Pcbnew or when trying to run Pcbnew python bindings from the
> system Python prompt?

The crash happens  when trying to run Pcbnew python bindings from the
system Python prompt.

(You can try to runt the demo plot_board.py).

> 
> This seems to be treating a symptom in the Python code, specifically
> that there is no Pgm struct created for some reason. I would think this
> would actually cause issues in more functions than just the
> ComputeBoundingBox() function though, so this seems like it would be a
> fairly invasive fix to make across the code base.
> 
> 
> -Ian
> 

The Pgm struct is not created when running a python code outside Kicad.
(It is created when running Pcbnew from an application)

Currently, ComputeBoundingBox() is the only one function that calls
Pgm() without being running from Kicad.

Of course, Pgm() is called in a lot of places, but not in function that
can be called from a python script.

I will be happy to know a method not invasive (I tried to modify Pgm(),
but this is invasive).

A basic fix is to remove the call to Pgm() in ComputeBoundingBox()
because it fixes a very very minor issue, and creates a much more
annoying issue.

In fact one cannot call Pgm() in any function that can be called by a
python script from the Python prompt.


> On Sat, Oct 5, 2019 at 12:20 PM Dino Ghilardi  > wrote:
> 
> Hello,
> 
> Latest commit (master branch) is not compiling giving an
> "undefined reference to `PgmOrNull()'" error during make
> 
> I tried also using:
> git clean-fx
> make clean
> cmake ../
> make -j7
> 
> may be something is missing from the commit?
> 
> Platform: Debian Linux.
> Commit 0a829c328e90f550994a7660b310630a5aa02361.
> 
> Full error Message:
> 
> ../../../common/libpcbcommon.a(class_board.cpp.o): In function
> `BOARD::ComputeBoundingBox(bool) const':
> class_board.cpp:(.text+0x1ec9): undefined reference to `PgmOrNull()'
> class_board.cpp:(.text+0x1ed7): undefined reference to `PgmOrNull()'
> ../../../common/libpcbcommon.a(class_board.cpp.o): In function
> `BOARD::ComputeBoundingBox(bool) const [clone .constprop.440]':
> 
> class_board.cpp:(.text._ZNK5BOARD18ComputeBoundingBoxEb.constprop.440[_ZNK5BOARD14GetBoundingBoxEv]+0x2d6):
> 
> undefined reference to `PgmOrNull()'
> 
> class_board.cpp:(.text._ZNK5BOARD18ComputeBoundingBoxEb.constprop.440[_ZNK5BOARD14GetBoundingBoxEv]+0x2e4):
> 
> undefined reference to `PgmOrNull()'
> collect2: error: ld returned 1 exit status
> 
> qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/build.make:328:
> 
> recipe for target 'qa/gal/gal_pixel_alignment/test_gal_pixel_alignment'
> failed
> make[2]: *** [qa/gal/gal_pixel_alignment/test_gal_pixel_alignment]
> Error 1
> CMakeFiles/Makefile2:4060: recipe for target
> 'qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/all'
> 
> failed
> make[1]: ***
> [qa/gal/gal_pixel_alignment/CMakeFiles/test_gal_pixel_alignment.dir/all]
> 
> Error 2
> Makefile:149: recipe for target 'all' failed
> 
> 
> 
> Cheers, Dino
> 
> ___
> 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
> 


-- 
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] [Patch] Pcb Calculator: Convert tracks width versus current formula

[jp charras]

Le 04/10/2019 à 17:15, Jakub Kozdon a écrit :
> Hi Jean-Pierre,
> 
> This came from discussion on bug 1818998. I hope that this patch will
> work correctly.
> 
> I will also look at eeschema/dialogs/dialog_bom_help.html
> 
> Jakub
> 

Hi Jakub,

Your patch works fine, and I committed it.

Thanks for your contribution.

-- 
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] [Patch] Handle Cvpcb save actions immediately

[jp charras]

Le 18/09/2019 à 10:13, Ian McInerney a écrit :
> Ping.
> 
> On Mon, Sep 9, 2019 at 7:05 AM Ian McInerney  > wrote:
> 
> This patch updates Cvpcb to run the save actions immediately when
> the buttons are pressed. If they are not run immediately, then the
> user may see the handle unsaved changes dialog (which if they
> clicked on OK is not what they are expecting), which will allow them
> to veto the close event. The event generated by the OK button is
> non-vetoable though, so showing this dialog can lead to an assertion.
> 
> -Ian
> 

I forgot your patch in my commit 9ceca583.

I committed you fix.

Thanks.


-- 
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] [Patch] Overbright view in 3D legacy render

[jp charras]

Le 08/09/2019 à 12:44, Michal Jahelka a écrit :
> This patch adds missing material parameter m_Emissive set to (0,0,0) in
> kicad/3d-viewer/3d_rendering/3d_render_ogl_legacy/c3d_render_ogl_legacy.cpp.
> Before this was PCB overbrighted (especially solder mask) and sometimes
> with bad colors. With raytracing was everything OK, but raytracing is
> very slow (on all my computers).
> 
> Before patch:
> 
> After patch it looks normal as in previous versions:
> 
> Adding patch for v 5.1.4 and for 5.1.5 and modified files.
> 

Hi Michal,

I committed your fix.
I never saw your issue, but OTOH clearly initializing the m_Emissive
parameter is certainly good.

Thanks.


-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

Le 06/09/2019 à 12:04, Michael Kavanagh a écrit :
> Hi JP,
> 
> This will be a great addition to KiCad, and I'm excited to see this
> progress. Now it's merged into master, would you prefer feedback on
> the mailing list or bug reports?
> 
> In any case, the panel display seems to be broken on macOS (I do not
> remember this issue when the dialog was standalone, however I do agree
> with the panel being part of Board Setup). Please see the attached
> screenshot. It was already mentioned above but I also believe wxGrid
> would be better for this, and other commercial EDA tools all use grid
> controls for this functionality.
> 
> I can submit a bug report if you prefer.
> 
> Cheers,
> Michael
> 

Hi Michael,

For feedback, the mailing list is good for be: the layer stack manager
is still a moving target.

For bugs, of course, a bug report is better.

About macOS:

I tested the Layer Stack Manager on W7 and Linux Kubuntu 18.04/KDE.
But I am unable to test it on macOS.
So I am expecting macOS guys will be able to fix these specific issues.

To answer your question about using wxGrid:
I agree wxGrid should be better, but unfortunately it does not works fine:
I used it is the first version, but I had so many issues (after spending
too many time to try to fix them) (read: having a barely usable dialog)
I gave up and replaced it by a wxFlexGridSizer.
The main advantage of a wxFlexGridSizer is: it works.

Perhaps other commercial EDA tools use a grid control, but perhaps not a
wxGrid.

-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

I just committed the Layer Stack Manager feature.

Some comments below:

Le 03/09/2019 à 20:47, Evan Shultz a écrit :
> A few comments from the peanut gallery using Simon's "497" build...
> 
> Some things Seth suggested that I support and don't see:
> - Units could be shown once at the top of the panel or in each column
> header instead of each cell of the table. That would reduce clutter a
> bit and shorten the string that needs to go into each cell.
> - Moving the right-side stuff (impedance control and board finish) into
> a separate panel of the dialog would allow the table to be wider. It's
> awfully cramped right now.
> - Alternating a color across each row would make the table easier to
> visually parse.
> 
> And some suggestions from me, as a knucklehead who has ran into many
> issues with stackup:
> 1. In the left pane of the dialog, there is a mix of "Stack-up" and
> "Stackup".

Fixed

> 2. Dielectric layers are the only items in the Name column that do not
> start with a capital letter.

Fixed

> 3. This panel and the popups use a mix of sentence capitalization, camel
> case, and capitalizing every word. While it doesn't impair understanding
> the panel's purpose, it doesn't look polished.
> 4. The "X" column is not salient. It is the only column header with a
> popup, and that's required because the function is opaque. Along with
> the comment above about expanding the table, using a more verbose term
> (or an icon?) for this column would be nice.

Good idea.

> 5. There are tables in the Defaults > Text & Graphics and Design Rules >
> Net Classes panels. Having column dividers makes the table much easier
> to read. Adhering to that style, I suspect, would improve readability of
> the stackup table.

The layer stack panel does not use a wxGrid.
My first implementation used a wxGrid, but I had a lot of issues.

> 6. I don't see the value of the "Board thickness" textbox at the top
> left. It changes the dielectric layer thicknesses when clicking the Set
> Dielectric Thickness button, but it sets the thickness of all dielectric
> layers equal. I have rarely seen this done in practice and never for an
> impedance-controlled board. This button seems to be mainly of value for
> simple boards with low layer counts. For a 2- or 4-layer board it's not
> much of a burden for the user to set the dielectric thickness manually
> to whatever they want, or leave it alone as the user probably doesn't
> care, and I can't imagine a high layer count board using controlled
> impedances having all dieletric layers with the same thickness. So this
> button doesn't seem useful to me. It's likely I'm daft and just don't
> get it.
> 7. One use for this is to specify the materials to be used by the board
> vendor. Picking a dielectric material type not in the list means keying
> in the parameters manually, probably after selecting "FR4". This can get
> tedious. It would be nice to have a list of materials, perhaps from an
> external file which could be shared company-wide, with approved
> materials (NanYa NP-175FR, ITEQ IT-180A, etc.). Selecting one of these
> materials would import the proper parameters. Perhaps an entire stackup,
> and just the stackup, could be imported from a file or existing board.


User defined dielectric material is not yet available.

I'll add it later.

> 8. Along with the above, allowing a custom name for the dielectric layer
> lets the user better communicate design intent to the board vendor. And
> if a custom material can be named once, perhaps it could appear as a
> selectable material in the list so other dielectric layers could use the
> same material with just a click. I get that keeping things in sync would
> then be a pain but I'm trying to imagine ways to avoid manually typing
> in the same info many times.

Good idea.
However it need a modifcation of .gbrjob specifications.

> 9. Another equally important use for this table is to select track width
> for single-ended and diff pair tracks (and in both broadside- and
> edge-coupled DPs). This table is a logical place to report all three
> impedances in new columns so the user can select the stackup, and then
> design constraints, before routing begins. While I can understand this
> being a later piece of the puzzle, I mention it in case there's anything
> that makes sense to do now.

Do not dream: one can calculate impedance only is basic cases.

> 10. It would be convenient if the copper thickness could be selected in
> ounces, even if that was converted to a mm thickness after selecting a
> value from the pulldown list. Selecting copper thicknesses (with custom
> names) and board finishes is another obvious set of selections that
> could be included in a company configuration as mentioned above.

You can enter a value with units: for instance 1oz instead of 0.035mm

> 11. Additionally, selecting the thickness on outer layers does not
> capture if the thickness is fully copper or copper plated up to the
> specified thickness. 

[Kicad-developers] Commit c8a6878 breaks compilation on msys2

[jp charras]

common.h does not compile with msys2/gcc 9.1.0

Here is the error message:

In file included from D:/wxWidgets-3.1.1/include/wx/defs.h:851,
 from D:/wxWidgets-3.1.1/include/wx/wx.h:14,
 from E:/kicad-launchpad/gerber_dev/include/common.h:37,
 from
E:/kicad-launchpad/gerber_dev/polygon/math_for_graphics.cpp:8:
E:/kicad-launchpad/gerber_dev/include/common.h: In function 'constexpr
ret_type KiROUND(fp_type)':
E:/kicad-launchpad/gerber_dev/include/common.h:118:5: error: 'asm' in
'constexpr' function
  118 | wxASSERT( ret <= std::numeric_limits::max()

Looks to me using wxASSERT here creates this issue.
(I replaced wxASSERT by a printf controlled by the same condition to
compile Kicad)

-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

Le 02/09/2019 à 14:06, Simon Richter a écrit :
> Hi,
> 
>> Please test and comment.
>> I want to commit this feature soon.
> 
> Builds on msys2 and msvc are on the way:
> 
> https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/495/
> https://jenkins.simonrichter.eu/job/windows-kicad-msvc-patch/142/
> 
> There should be binaries there for easier testing soon.
> 
>Simon

Thanks.


-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

I just finished the version of board stack manager that should fix all
issues and remarks previously made, and has some tests to avoid
incorrect parameters.
The patch is against latest master branch version (5.99.0-48)

The stackup settings is now in the board settings dialog.

Note also the board settings dialog has a flaw:
All panels are working on the current board settings instead of a "local
copy" of these settings.
If when validating settings in panels a veto is generated by a panel
(due to a incorrect parameter) all changes made by previous panels are
already committed, and if canceling the changes, some are committed, and
some others not.
My patch does not fix this issue, that is specific to the dialog, not
the stack manager.

Please test and comment.
I want to commit this feature soon.

-- 
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] 5.1.5 RC?

[jp charras]

Le 30/08/2019 à 16:35, Nick Østergaard a écrit :
> What was the command that could be added the the schematic to make
> ngspice print the version info about itself in the output text shown
> in the bottom of the simulator window?
> 

Hi Nick,
You can try:

.control
version
.endc

It works for me with ngspice-30

-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

Le 13/08/2019 à 18:52, Wayne Stambaugh a écrit :
> JP,
> 
> I took a look at your patch and I have a few comments.
> 
> Shouldn't the stack up dialog just be another panel the the board setup
> dialog?  I would think this information is part of the board setup but I
> could be wrong.
> 
> If the stack up information is part of the board setup then it should be
> in the "setup" section of the file format as well instead of a separate
> section.
> 
> Change the "board_stackup" token to "stackup".  Board is implied.
> 
> I'm not sure "dielectric_constrains" is necessarily clear.  Maybe
> "control_dielectric" would be more clear although I'm open to suggestion.
> 
> The dialog layout definitely needs improved.  The board thickness
> control has the units appended in the edit control along with the units
> displayed using static text.  The layer color swatches are not aligned
> with the rest of the layer row controls.  The color comboboxes are
> cutoff on GTK.  The capitalization is incorrect for the check box and
> sizer strings.
> 
> All in all, it's a good first step.  I'm sure this will be improved over
> time to cover other board stack up parameters.
> 
> Cheers,
> 
> Wayne
> 

Wayne and Seth, thanks for your input.

I attached a new version of the  Layer Stack Manager that fixes some issues.

A few comments on the dialog (also for @Seth):
I have fixed some issues (the issue with wxBitmapComboBox is a wxGTK
bug: I added a workaround)
Currently the  Layer Stack Manager uses its own dialog.
However the main code uses a wxPanel, so it can be easily moved in the
Preferences or the Board setup dialogs.

But I am not convinced the Preferences or the Board setup is the right
place for this stack manager:

 1- the Layer Setup in board setup is already a list with many info.
Adding more widgets on each line will create usability issues.

 2- these (layer setup and stack manager) panels are already not easy to
use when setting the copper layer count to 32.

3- the layer setup manages info for the board editor.
the stack manager manages info only for the CAM tools (currently, the
.gbrjob file) and none of the settings in  this stack manager are used
by the board editor (but some will be used by the 3D viewer).
I do not see a good reason to merge the layer setup the stack manager.
Moreover, in the future, the layer setup should manage more info (when
the possibility to add custom layers is added)

4- Once the stack manager is added to Pcbnew, the board thickness
setting will be removed from the Layer setup panel.

5- A good place for this stack manager could be inside a CAM tool that
allows to create all files (Gerber, drill files and gbrjob file) in one
command, with the same settings.
The the current stack manager dialog should be seen only as a temporary
dialog.

What about merging the code to master, and using advanced config to
enable it, although it is not really finished?

Thanks.

> On 8/10/19 7:18 AM, jp charras wrote:
>> Since a long time, I started (slowly...) a layer stack manager.
>> The purpose is to allow users to define (for board fabrication) some
>> important parameters like:
>> - tech, copper and dielectric thickness
>> - color of some tech layers
>> - dielectric material
>> - board constraints.
>>
>> All of these parameters are in the .gbrjob file generated when plotting
>> gbr files.
>> Note also these parameters are not used in the board editor, only used
>> to fabricate the board.
>>
>> the dialog is available from the "Tools" menu.
>>
>> The ultimate purpose is to have something like a CAM tool to manage info
>> about the board fabrication and to create files needed to fabricate the
>> board all in once.
>> This is mandatory to ensure all files (gbr files, gbrjob files,
>> placement files and some others) are created at the same time, and use
>> the same settings.
>> The first step is this layer Stack Manager.
>>
>> Please test and comment.
>> Note also the dialog is not very good, but it is good enough (i hope) to
>> test the feature.
>> The main result of these settings is in the .gbrjob file.
>> Thanks.
>>
>>
>> ___
>> 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
> 


-- 
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] [Patch] Fix some memory leaks

[jp charras]

Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
> Sounds like a plan.  If there are not bug reports against this over the
> next month, I'll will cherry-pick it into 5.1.
> 
> Wayne

I am not sure this issue exists in 5.1.

AFAIK it comes from moving code from our DLIST to std::deque, only in
master branch.

Our DLIST dtor manages (when it has the ownership) the items deletion.
But std::deque does not delete the items, so the code using std::deque
has to delete these items.

> 
> On 8/12/19 3:47 PM, Ian McInerney wrote:
>> Wayne, lets let this settle in master for a while to make sure that no
>> issues due to object lifetime surface.
>>
>> -Ian
>>
>> On Mon, Aug 12, 2019 at 9:20 PM Wayne Stambaugh > > wrote:
>>
>> Ian,
>>
>> I merged your patch.  I'm guessing this should be cherry-picked into the
>> 5.1 branch.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 8/11/19 4:42 PM, Ian McInerney wrote:
>> > I was noticing there were some memory leaks inside the board/module
>> > classes that got somewhat extreme in some cases (I saw ~300MB leaked
>> > from opening and closing cvpcb in Eeschema when run without a project
>> > manager). This patch adds some deletion to the destructors of the
>> > board/module classes, so they now will delete their sub items.
>> >
>> > I believe these classes are the respective owners of those pointers to
>> > the sub items, and my testing doesn't show any problems with this, but
>> > if anyone can see a case where deleting these sub items on destruction
>> > might be an issue, let me know.
>> >
>> > -Ian
>> >
>> > ___
>> > 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
> 


-- 
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] [RFC] Comments for a Layer Stack Manager in Pcbnew

[jp charras]

Since a long time, I started (slowly...) a layer stack manager.
The purpose is to allow users to define (for board fabrication) some
important parameters like:
- tech, copper and dielectric thickness
- color of some tech layers
- dielectric material
- board constraints.

All of these parameters are in the .gbrjob file generated when plotting
gbr files.
Note also these parameters are not used in the board editor, only used
to fabricate the board.

the dialog is available from the "Tools" menu.

The ultimate purpose is to have something like a CAM tool to manage info
about the board fabrication and to create files needed to fabricate the
board all in once.
This is mandatory to ensure all files (gbr files, gbrjob files,
placement files and some others) are created at the same time, and use
the same settings.
The first step is this layer Stack Manager.

Please test and comment.
Note also the dialog is not very good, but it is good enough (i hope) to
test the feature.
The main result of these settings is in the .gbrjob file.
Thanks.

-- 
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] 5.1.3 release

[jp charras]

Hi Wayne,

If the 5.1.3 is built from tag 5.1.3 (jul 25) version, there is a very
annoying bug:
Bug #1838446

This bug was fixed the Jul 31.

This bug make impossible updating footprints, both from the dialog and
from schematic, because the new footprint is not at the right place (the
old footprint coordinate) but it is placed at the mouse cursor location.


-- 
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] Eeschema selection

[jp charras]

Le 01/08/2019 à 06:54, Jeff Young a écrit :
> Hi JP,
> 
> I’ve pushed another version which uses the platform selection colour (blue on 
> OSX).  Let me know how that looks on your machine.
> 
> Cheers,
> Jeff.
> 

Much better now.
Thanks.

> 
>> On 30 Jul 2019, at 12:04, jp charras  wrote:
>>
>> Le 30/07/2019 à 05:01, Jeff Young a écrit :
>>> Hi Nhat,
>>>
>>> The colours of the “shadows” are the same as the elements themselves —
>>> so they can be configured the normal way.
>>>
>>> And yes, the shadow width scales with the zoom factor.  It’s not 100%
>>> the same across all zoom sizes as it looks more consistent if it’s
>>> bumped up a little a larger zooms.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>
>> Hi Jeff,
>> On my computer some selected items (symbols and fields, wires and lines)
>> have the same look (the difference is not really noticeable) as when not
>> selected, so I cannot say if a wire or symbol is select or not.
>>
>> Selected bitmaps are very visible (although the rectangular area is
>> incorrectly sized.
>>
>> Perhaps the the rectangular area trick could be used for symbols.
>>
>> I do not have a strong idea for wires and lines.
>>
>> -- 
>> Jean-Pierre CHARRAS


-- 
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] Tool processing & RunHotKey return

[jp charras]

y: command  action: action cmd-str: pcbnew.InteractiveSelection.Clear
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::processEvent
>> handled: true  category: command  action: action cmd-str:
>> pcbnew.InteractiveSelection.Clear
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::processEvent
>> category: command  action: activate cmd-str: pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchInternal
>> category: command  action: activate cmd-str: pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchInternal
>> Waking tool pcbnew.InteractiveSelection for event: category: command
>>  action: activate cmd-str: pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchInternal
>> handled: false  category: command  action: activate cmd-str:
>> pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchActivation
>> category: command  action: activate cmd-str: pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchActivation
>> Running tool pcbnew.LengthTuner for event: category: command  action:
>> activate cmd-str: pcbnew.LengthTuner
>> 11:32:28 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::processEvent
>> handled: true  category: command  action: activate cmd-str:
>> pcbnew.LengthTuner
>> 11:32:29 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchInternal
>> handled: true  category: command  action: activate cmd-str:
>> pcbnew.LengthTuner.TuneDiffPair
>> 11:32:29 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::dispatchActivation
>> category: command  action: activate cmd-str: pcbnew.LengthTuner.TuneDiffPair
>> 11:32:29 AM: Trace: (KICAD_TOOL_STACK) TOOL_MANAGER::processEvent
>> handled: true  category: command  action: activate cmd-str:
>> pcbnew.LengthTuner.TuneDiffPair
>>
>>
>> From the comment about the second search step (action_manager.cpp:101),
>> it sounds like this was added because of the shifted key problem. This
>> doesn't seem like a good solution to the problem though, because it
>> causes more issues with other keys as well (for instance, if nothing is
>> assigned to shift+A, then it just runs the hotkey for A instead).
>>
>> Is there a reason not to just skip all keyboard events with the shift
>> modifier that happen in a wxEVT_CHAR_HOOK event? That way they will
>> continue processing and generate the wxEVT_CHAR, and we don't have to
>> have every tool skipping the keyboard events (which I am also seeing
>> some issues with in the routing tool). I think that would also mean the
>> second hotkey search step could be removed, fixing the issues it is
>> creating.
>>
>> I have been doing all of this testing on GTK, so I am not familar with
>> any of the Windows/Mac processing that it does, so is any of this key
>> translation also platform specific?
>>
>> -Ian
>>
>> On Sun, Jul 28, 2019 at 2:27 PM jp charras > <mailto:jp.char...@wanadoo.fr>> wrote:
>>
>> Le 28/07/2019 à 02:22, Jeff Young a écrit :
>> > I think JP ran into this earlier, so he might know more about it.
>>
>> In fact issue I h=worked on was the fact the Char events where no
>> correctly skipped.
>>
>> If I correctly understand the issue related by this mail, this is a
>> dispatch issue.
>>
>> I am thinking I already saw this issue.
>> The key event dispatch incorrectly try to dispatch the key events:
>> For me it try to find an action that matches the corresponding hotkey in
>> its lists, regardless the fact the action is attached to the active
>> frame (the frame having the focus) or not.
>> If this is true, this dispatch behavior is really not correct:
>> Only actions depending on the active frame must be taken in account.
>> This is what the wxWidgets menu accelerators work.
>>
>>
>> Now, about wxEVT_CHAR_HOOK and wxEVT_CHAR events (and related hotkeys):
>> Among differences between these events, there is one major diff:
>> wxEVT_CHAR_HOOK identify the keyboard key (i.e. the not shifted key
>> code).
>> wxEVT_CHAR identify the key code (depending on the fact the shift key is
>> pressed or not).
>> They are very different for keys that have 2 very different key codes.
>>
>> I explain:
>>
>> On a French keyboard, all "digit" keys have 2 key code (like in many
>> other keyboards), but digit keys are shifted.
>> For instance the '3' key is also the '"' key.
>

Re: [Kicad-developers] Eeschema selection

[jp charras]

Le 30/07/2019 à 05:01, Jeff Young a écrit :
> Hi Nhat,
> 
> The colours of the “shadows” are the same as the elements themselves —
> so they can be configured the normal way.
> 
> And yes, the shadow width scales with the zoom factor.  It’s not 100%
> the same across all zoom sizes as it looks more consistent if it’s
> bumped up a little a larger zooms.
> 
> Cheers,
> Jeff.
> 

Hi Jeff,
On my computer some selected items (symbols and fields, wires and lines)
have the same look (the difference is not really noticeable) as when not
selected, so I cannot say if a wire or symbol is select or not.

Selected bitmaps are very visible (although the rectangular area is
incorrectly sized.

Perhaps the the rectangular area trick could be used for symbols.

I do not have a strong idea for wires and lines.

-- 
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] Tool processing & RunHotKey return

[jp charras]

Le 28/07/2019 à 02:22, Jeff Young a écrit :
> I think JP ran into this earlier, so he might know more about it.

In fact issue I h=worked on was the fact the Char events where no
correctly skipped.

If I correctly understand the issue related by this mail, this is a
dispatch issue.

I am thinking I already saw this issue.
The key event dispatch incorrectly try to dispatch the key events:
For me it try to find an action that matches the corresponding hotkey in
its lists, regardless the fact the action is attached to the active
frame (the frame having the focus) or not.
If this is true, this dispatch behavior is really not correct:
Only actions depending on the active frame must be taken in account.
This is what the wxWidgets menu accelerators work.


Now, about wxEVT_CHAR_HOOK and wxEVT_CHAR events (and related hotkeys):
Among differences between these events, there is one major diff:
wxEVT_CHAR_HOOK identify the keyboard key (i.e. the not shifted key code).
wxEVT_CHAR identify the key code (depending on the fact the shift key is
pressed or not).
They are very different for keys that have 2 very different key codes.

I explain:

On a French keyboard, all "digit" keys have 2 key code (like in many
other keyboards), but digit keys are shifted.
For instance the '3' key is also the '"' key.
In other words '3' and '3' use the same key ( I will call it 3")
'3' needs to type SHIFT + 3" key
'"' needs to type the 3" key

Now what about wxEVT_CHAR_HOOK:
wxEVT_CHAR_HOOK returns the key '"' with the modifier Shift.
wxEVT_CHAR returns the key '3' with the modifier Shift.

As a result: to show the 3D viewer in PCBNEW:
- on an English keyboard you use Alt+3
- on an French keyboard you use Alt+"

And I am not sure this is a bug in wxWidgets:
some other applications have this annoying behavior, for instance
Firefox and its zoom commands (but I used also a few other apps showing
this behavior).

> 
> Another issue might be that at the end of the tool loop the event will get 
> skipped which will send it to wxWidgets for processing (at which point it 
> will probably come back as a hotkey again).  We might already have logic to 
> deal with that, but it’s something to look out for.
> 
> At the end of the day, though, we need to design around what is “right”.  If 
> what’s right breaks other stuff then we need to fix the other stuff.
> 
> Cheers,
> Jeff.
> 
>> On 27 Jul 2019, at 17:48, Ian McInerney  wrote:
>>
>> In the tool dispatcher currently, if any action is associated with a key 
>> combination (even if the action is not handled by any active tools) then a 
>> key event with that combination will not progress further than the 
>> dispatchHotKey function in the dispatcher. For instance, this means that the 
>> letter 'B' will not make it into any of the dispatchInternal calls inside 
>> any program (e.g. eeschema, pleditor, cvpcb, etc.) because it is assigned to 
>> a pcbnew action to refill the zones, even when those other programs do not 
>> use that action at all so it goes unhandled in the dispatchHotkey function. 
>> That event therefore is inaccessible in any tool loops that may be running.
>>
>> Is there a reason the dispatchHotkey logic looks only at the fact an action 
>> with that hotkey exists rather than if any tool has handled the associated 
>> action? For my work in cvpcb it would be better if it were the latter, so 
>> that any key events not handled by the tools continue processing (e.g. for 
>> down/up/left/right keys, single letter keys, etc.). It should be possible to 
>> know if the action is handled by the hotkey handler, since they actions are 
>> spawned immediately and the handled return value is then available.
>>
>> Would a change to this system break any of the existing tool loops? e.g., 
>> are any unable to cope with receiving key pressed events (I don't think any 
>> would be problematic, since some keys such as 'C' don't have an associated 
>> action and would therefore generate key pressed events in them)?
>>
>> -Ian
>> ___
>> 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
> 


-- 
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] fp-info-cache question

[jp charras]

Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
> On 2019-07-23 13:38, jp charras wrote:
>> Le 23/07/2019 à 19:22, Jeff Young a écrit :
>>> Hi Seth,
>>>
>>> I think that would work.  And you’re right — there probably aren’t
>>> enough project libs to require a cache for them.
>>
>> I am not sure to understand.
>>
>> The cache is by lib table, or by library file?
>> This is very different: if it is by lib table, I am thinking lib table
>> projects require a cache.
> 
> The cache uses the combined global + project lib tables right now and
> stores in the project directory.  I am proposing making the cache only
> for the global lib table and store it next to the global library table
> and not cache the project library files at all.
> 
> Alternatively, we could merge the cache and the table files.  Global
> library table file gets the global cache, project library table file
> gets the project-specific cache.
> 
> Thoughts?
> 
> -Seth
> 

Yes: why tho remove the project-specific libs cache?
2 separate caches for global libs and project is a good idea.

The best is to have a cache for global libs and a project cache for libs
not in global table.

Ideally, global libs could be only really a few libs like power and
device (for eeschema) or resistors, capacitors and a few other for
footprints

Therefore, local lib tables could have more libs than the global table.

The alternate way is for me the way to go.

-- 
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] fp-info-cache question

[jp charras]

Le 23/07/2019 à 19:22, Jeff Young a écrit :
> Hi Seth,
> 
> I think that would work.  And you’re right — there probably aren’t enough 
> project libs to require a cache for them.

I am not sure to understand.

The cache is by lib table, or by library file?
This is very different: if it is by lib table, I am thinking lib table
projects require a cache.

> 
> I’m knee-deep in the router right now, though, so someone else would have to 
> do it.
> 
> Cheers,
> Jeff.
> 



-- 
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] [PATCH] Board statistics dialog

[jp charras]

Le 22/07/2019 à 10:13, Alexander Shuklin a écrit :
> Hi!
> I'll have a look to add vias count to dialog.
> There's some questions:
> 
> 1)I don't have too much experience with wxdialogs. There was commit on
> master, which says:
>>> remove settings for fg/bg color: the result is unpredictable: was
> black texts on black background on my computer.
> And now I have all tables with data just in white boxes. Is it how it
> meant to be, or just some misbehavior on different systems? I use
> archlinux x64 OS.
> there's screenshot in attachment

Colors and fonts in dialogs depend on Window Managers, selected themes,
selected fonts ... on the user computer.

We already have issues in dialogs when forcing colors and/or fonts.
So a golden rule is to avoid forcing fonts and colors when not mandatory.

On my computer, the initial colors selection give me just a black box
for the full dialog.

> 
> 2) Can we use something like _( "Height" ) + ":" for translation, not _(
> "Height:" )? As far as I understand, now we will need to have 2
> translations, first for "Height" and second for "Height:" but that's
> basically same word.
> 

An other golden rule is *never* create a string by concatenation of words:
- One can translate a full sentence, but usually not a list of
concatenated words: the translation is never a word to word change.
- Are you sure "Height" and "Height:" are basically the same word
("Height" + ":") in any language in any context?

-- 
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] MOD_VIRTUAL flag

[jp charras]

Le 22/07/2019 à 06:03, Jeff Young a écrit :
> This flag tells us that there’s no physical object for a pick-n-place 
> machine.  But is it also true that there’s no corresponding symbol in the 
> schematic, or are there some virtual footprints that would have a symbol?
> 
> What about some microwave elements, for instance?  Do they have symbols?

"Virtual" footprint means the physical "component" is made only by the
drawings on the board.

Therefore:
- These fp have (usually) no 3D shapes, and the component should be not
in BOM.
- They of course have a symbol in schematic.

In fact any footprint connected to a at least one net *should* have its
corresponding symbol in schematic.
(I am thinking all footprints should have a corresponding symbol because
in many cases these fp need a unique refdes: for instance to import them
to a .dsn file)

Microwave elements, and edge connector cards are often virtual, if only
a drawing is enough to create them.
Net ties are virtual and *need* a symbol.

However, Microwave elements and Net ties connecting 2 or more different
nets are not easy to use in Pcbnew:
See this thread
https://lists.launchpad.net/kicad-developers/msg24455.html
to know what is missing in Pcbnew (the Tomasz's proposal is exactly what
is needed in Eeschema/Pcbnew).


Mechanical holes can be virtual or not:
A mechanical hole with a screw inserted inside it should be not virtual.

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