Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]
To give another example: the wxWidgets team knows that better HiDPI support is needed, and has been working on it. I don't have access to a system where I would prefer to run at a scaling factor other than 1, so I'm not sure what issues you see. If you report them, we can determine: - is the issue in wx or kicad? - if in wx, is the wx team already tracking it? We usually do not have the resources to fix upstream wxWidgets bugs ourselves, except for cases where we can make fixes to our fork for macOS or Windows (the burden is obviously higher to get something upstreamed for Linux users). However, if we at least know that a problem exists upstream, than we can track it and volunteer devs who may have time to work on it can find it. -Jon On Mon, Nov 8, 2021 at 11:49 AM Jon Evans wrote: > I certainly agree with a stability drive, I would just caution to not > assume that the devs see the same issues you do, and therefore are ignoring > the stability problems you see. > > > Finally, I know issues that are GTK or WX based might be hard or even > impossible for Kicad to fix, but in the past I have often found it best to > fix them (if possible) anyway because they could be hiding other issues, > either in a wood-trees way or because of side effects. The same applies to > warnings from the compiler, etc. > > I agree with this in principle, but in practice, some of these issues are > either inconsequential (such as the GTK warnings), very hard to figure out > how to fix, or both. > We always welcome people to work on these issues, but if they don't result > in an actual impact to KiCad users, and they are hard to fix (or require > upstream changes to fix), it is hard to prioritize them internally in the > KiCad dev team. > > -Jon > > On Mon, Nov 8, 2021 at 11:46 AM Ruth Ivimey-Cook wrote: > >> Jon, >> >> I realize there was a lot of content, but I also know that little of it >> was of very much use, because in most cases the issues seen have not been >> repeatable. I will see what I can do, though. >> >> Mostly, this mail was about making the case for the devs to agree to a >> stability drive, and go looking for problems. >> >> Finally, I know issues that are GTK or WX based might be hard or even >> impossible for Kicad to fix, but in the past I have often found it best to >> fix them (if possible) anyway because they could be hiding other issues, >> either in a wood-trees way or because of side effects. The same applies to >> warnings from the compiler, etc. >> >> Regards, >> >> Ruth >> >> >> On 08/11/2021 16:38, Jon Evans wrote: >> >> Hi Ruth, >> >> Thanks for the notes. There is a lot of content in your email, and I >> worry it will get lost if it doesn't get split up into multiple issues on >> the issue tracker. >> >> Some of the issues you mention (GTK warnings, ASan issues related to >> Python, etc) are known issues and we don't plan to fix them at this time >> because we don't think they relate to any actual stability issues that >> KiCad users will experience or observe when running a release build. Some >> of these are caused by wxWidgets itself, and some will be fixed when we >> move away from SWIG for the Python API in V7. >> >> Any of the issues you mention that are actually KiCad issues should get >> addressed if possible. However, each of them will require its own >> discussion thread, maybe including more specific reproduction steps, >> example projects that cause the issue, etc. We'd really appreciate it if >> you could report the crashes and other misbehavior you see on GitLab (or >> via the Report Bug entry in the Help menu) one by one, so that they can be >> addressed. >> >> Best, >> Jon >> >> On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook wrote: >> >>> From my recent experience with self-built flatpak versions of KiCad 5.99 >>> (head), I love the recent changes in the program. >>> >>> I also feel there is an amount of work still needed to improve >>> stability. I would suggest people use the program from a debug build with >>> address sanitisation enabled, which among other things enables the Wx >>> assertions. (I would encourage devs to include more assertions in the kicad >>> code as well!) >>> >>> I have had several crashes recently, though only a few repeatably. There >>> is a bug somewhere in the pcb track drag code when lots of suggested track >>> segments are being created/deleted, perhaps to do with an out of bounds >>> (indexing) error; there is a bug that can put "-1" in the Line Style of >>> netclasses and perhaps in other properties too (reported elsewhere); there >>> is a bug somewhere that spams the console with "pixman_region32_init_rect: >>> Invalid rectangle passed" when accessing menus; there is another that threw >>> this: >>> >>> /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp, >>> _Alloc>::const_reference std::vector<_Tp, >>> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = >>> VECTOR2; _Alloc = std::allocator >; st
Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]
I certainly agree with a stability drive, I would just caution to not assume that the devs see the same issues you do, and therefore are ignoring the stability problems you see. > Finally, I know issues that are GTK or WX based might be hard or even impossible for Kicad to fix, but in the past I have often found it best to fix them (if possible) anyway because they could be hiding other issues, either in a wood-trees way or because of side effects. The same applies to warnings from the compiler, etc. I agree with this in principle, but in practice, some of these issues are either inconsequential (such as the GTK warnings), very hard to figure out how to fix, or both. We always welcome people to work on these issues, but if they don't result in an actual impact to KiCad users, and they are hard to fix (or require upstream changes to fix), it is hard to prioritize them internally in the KiCad dev team. -Jon On Mon, Nov 8, 2021 at 11:46 AM Ruth Ivimey-Cook wrote: > Jon, > > I realize there was a lot of content, but I also know that little of it > was of very much use, because in most cases the issues seen have not been > repeatable. I will see what I can do, though. > > Mostly, this mail was about making the case for the devs to agree to a > stability drive, and go looking for problems. > > Finally, I know issues that are GTK or WX based might be hard or even > impossible for Kicad to fix, but in the past I have often found it best to > fix them (if possible) anyway because they could be hiding other issues, > either in a wood-trees way or because of side effects. The same applies to > warnings from the compiler, etc. > > Regards, > > Ruth > > > On 08/11/2021 16:38, Jon Evans wrote: > > Hi Ruth, > > Thanks for the notes. There is a lot of content in your email, and I > worry it will get lost if it doesn't get split up into multiple issues on > the issue tracker. > > Some of the issues you mention (GTK warnings, ASan issues related to > Python, etc) are known issues and we don't plan to fix them at this time > because we don't think they relate to any actual stability issues that > KiCad users will experience or observe when running a release build. Some > of these are caused by wxWidgets itself, and some will be fixed when we > move away from SWIG for the Python API in V7. > > Any of the issues you mention that are actually KiCad issues should get > addressed if possible. However, each of them will require its own > discussion thread, maybe including more specific reproduction steps, > example projects that cause the issue, etc. We'd really appreciate it if > you could report the crashes and other misbehavior you see on GitLab (or > via the Report Bug entry in the Help menu) one by one, so that they can be > addressed. > > Best, > Jon > > On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook wrote: > >> From my recent experience with self-built flatpak versions of KiCad 5.99 >> (head), I love the recent changes in the program. >> >> I also feel there is an amount of work still needed to improve stability. >> I would suggest people use the program from a debug build with address >> sanitisation enabled, which among other things enables the Wx assertions. >> (I would encourage devs to include more assertions in the kicad code as >> well!) >> >> I have had several crashes recently, though only a few repeatably. There >> is a bug somewhere in the pcb track drag code when lots of suggested track >> segments are being created/deleted, perhaps to do with an out of bounds >> (indexing) error; there is a bug that can put "-1" in the Line Style of >> netclasses and perhaps in other properties too (reported elsewhere); there >> is a bug somewhere that spams the console with "pixman_region32_init_rect: >> Invalid rectangle passed" when accessing menus; there is another that threw >> this: >> >> /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp, >> _Alloc>::const_reference std::vector<_Tp, >> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = >> VECTOR2; _Alloc = std::allocator >; std::vector<_Tp, >> _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp, >> _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' >> failed. >> >> ... but where from I know not. There is another in eeschema to do with >> replacing a symbol footprint using the footprint chooser, though I cannot >> replicate it and the trace (below) is unhelpful. >> >> The memory leak detector shows a lot of memory leaks on exit, though >> mostly related to Python Eval and to Wx fonts / pango. This latter group >> might be all Wx, fontconfig or pango's fault, not kicad -- >> wxCairoContext::GetTextExtent is one common denominator, >> wxWindow::GetCharHeight is another. [[ I did attempt to compile with >> wxwindows head, which is significantly advanced over the 3.1.5 currently >> being used, but sadly wxpython doesn't build against head (probably not a >> big thing - there's a patch already which
Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]
Jon, I realize there was a lot of content, but I also know that little of it was of very much use, because in most cases the issues seen have not been repeatable. I will see what I can do, though. Mostly, this mail was about making the case for the devs to agree to a stability drive, and go looking for problems. Finally, I know issues that are GTK or WX based might be hard or even impossible for Kicad to fix, but in the past I have often found it best to fix them (if possible) anyway because they could be hiding other issues, either in a wood-trees way or because of side effects. The same applies to warnings from the compiler, etc. Regards, Ruth On 08/11/2021 16:38, Jon Evans wrote: Hi Ruth, Thanks for the notes. There is a lot of content in your email, and I worry it will get lost if it doesn't get split up into multiple issues on the issue tracker. Some of the issues you mention (GTK warnings, ASan issues related to Python, etc) are known issues and we don't plan to fix them at this time because we don't think they relate to any actual stability issues that KiCad users will experience or observe when running a release build. Some of these are caused by wxWidgets itself, and some will be fixed when we move away from SWIG for the Python API in V7. Any of the issues you mention that are actually KiCad issues should get addressed if possible. However, each of them will require its own discussion thread, maybe including more specific reproduction steps, example projects that cause the issue, etc. We'd really appreciate it if you could report the crashes and other misbehavior you see on GitLab (or via the Report Bug entry in the Help menu) one by one, so that they can be addressed. Best, Jon On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cookwrote: From my recent experience with self-built flatpak versions of KiCad 5.99 (head), I love the recent changes in the program. I also feel there is an amount of work still needed to improve stability. I would suggest people use the program from a debug build with address sanitisation enabled, which among other things enables the Wx assertions. (I would encourage devs to include more assertions in the kicad code as well!) I have had several crashes recently, though only a few repeatably. There is a bug somewhere in the pcb track drag code when lots of suggested track segments are being created/deleted, perhaps to do with an out of bounds (indexing) error; there is a bug that can put "-1" in the Line Style of netclasses and perhaps in other properties too (reported elsewhere); there is a bug somewhere that spams the console with "pixman_region32_init_rect: Invalid rectangle passed" when accessing menus; there is another that threw this: /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = VECTOR2; _Alloc = std::allocator >; std::vector<_Tp, _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed. ... but where from I know not. There is another in eeschema to do with replacing a symbol footprint using the footprint chooser, though I cannot replicate it and the trace (below) is unhelpful. The memory leak detector shows a lot of memory leaks on exit, though mostly related to Python Eval and to Wx fonts / pango. This latter group might be all Wx, fontconfig or pango's fault, not kicad -- wxCairoContext::GetTextExtent is one common denominator, wxWindow::GetCharHeight is another. [[ I did attempt to compile with wxwindows head, which is significantly advanced over the 3.1.5 currently being used, but sadly wxpython doesn't build against head (probably not a big thing - there's a patch already which might just need extending). Probably worth pursuing a
Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]
Hi Ruth, Thanks for the notes. There is a lot of content in your email, and I worry it will get lost if it doesn't get split up into multiple issues on the issue tracker. Some of the issues you mention (GTK warnings, ASan issues related to Python, etc) are known issues and we don't plan to fix them at this time because we don't think they relate to any actual stability issues that KiCad users will experience or observe when running a release build. Some of these are caused by wxWidgets itself, and some will be fixed when we move away from SWIG for the Python API in V7. Any of the issues you mention that are actually KiCad issues should get addressed if possible. However, each of them will require its own discussion thread, maybe including more specific reproduction steps, example projects that cause the issue, etc. We'd really appreciate it if you could report the crashes and other misbehavior you see on GitLab (or via the Report Bug entry in the Help menu) one by one, so that they can be addressed. Best, Jon On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook wrote: > From my recent experience with self-built flatpak versions of KiCad 5.99 > (head), I love the recent changes in the program. > > I also feel there is an amount of work still needed to improve stability. > I would suggest people use the program from a debug build with address > sanitisation enabled, which among other things enables the Wx assertions. > (I would encourage devs to include more assertions in the kicad code as > well!) > > I have had several crashes recently, though only a few repeatably. There > is a bug somewhere in the pcb track drag code when lots of suggested track > segments are being created/deleted, perhaps to do with an out of bounds > (indexing) error; there is a bug that can put "-1" in the Line Style of > netclasses and perhaps in other properties too (reported elsewhere); there > is a bug somewhere that spams the console with "pixman_region32_init_rect: > Invalid rectangle passed" when accessing menus; there is another that threw > this: > > /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp, > _Alloc>::const_reference std::vector<_Tp, > _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = > VECTOR2; _Alloc = std::allocator >; std::vector<_Tp, > _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp, > _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' > failed. > > ... but where from I know not. There is another in eeschema to do with > replacing a symbol footprint using the footprint chooser, though I cannot > replicate it and the trace (below) is unhelpful. > > The memory leak detector shows a lot of memory leaks on exit, though > mostly related to Python Eval and to Wx fonts / pango. This latter group > might be all Wx, fontconfig or pango's fault, not kicad -- > wxCairoContext::GetTextExtent is one common denominator, > wxWindow::GetCharHeight is another. [[ I did attempt to compile with > wxwindows head, which is significantly advanced over the 3.1.5 currently > being used, but sadly wxpython doesn't build against head (probably not a > big thing - there's a patch already which might just need extending). > Probably worth pursuing a little though. ]] > > The python leaks are mostly from dictresize, and I think they result from > old dict memory, rather than being directly freed on resize, being added to > the keys_free_list and then never freed from that. See > https://github.com/python/cpython/blob/9942f42a93ccda047fd3558c47b822e99afe10c0/Objects/dictobject.c#L1281 > . In turn this would suggest _PyDict_ClearFreeList / _PyDict_Fini is > never called. > > I also think there is a regression: when selecting things at a Via, the > Via itself is always selected and the normal select-what menu list doesn't > appear. This makes it impossible to select anything within the area of a > Via unless you move the Via first. The select-what does appear in other > cases. I'm not 100% sure, but I think I've seen similar behaviour where > tracks are selected when a graphic line could also have been selected. I > may be wrong there though. > > Relating to Wx and HiDPI displays, even compiled with wx 3.1.5, many of > the text widgets are too small (by roughly the factor of the DPI adjustment > my display is using, 1.75) and either in consequence or also, the default > window sizes are also too small, not encompassing their content. > > Finally, I have frequently been surprised by windows being raised or not > raised. For example, I did a DRC check last night having not started > eeschema in that session. The previous session had crashed, so when DRC > started eeschema, eeschema posted an 'oops' message dialog asking to > recover. All well and good, except the pcbnew window obscured both eeschema > and its oops dialog, and pcbnew was left hung as if it had died. I did > eventually realize it hadn't, and why, but it was not at all obvious. > > Another weirdness is
[Kicad-developers] Stability drive? [was Re: Version 6 release schedule]
From my recent experience with self-built flatpak versions of KiCad 5.99 (head), I love the recent changes in the program. I also feel there is an amount of work still needed to improve stability. I would suggest people use the program from a debug build with address sanitisation enabled, which among other things enables the Wx assertions. (I would encourage devs to include more assertions in the kicad code as well!) I have had several crashes recently, though only a few repeatably. There is a bug somewhere in the pcb track drag code when lots of suggested track segments are being created/deleted, perhaps to do with an out of bounds (indexing) error; there is a bug that can put "-1" in the Line Style of netclasses and perhaps in other properties too (reported elsewhere); there is a bug somewhere that spams the console with "pixman_region32_init_rect: Invalid rectangle passed" when accessing menus; there is another that threw this: /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = VECTOR2; _Alloc = std::allocator >; std::vector<_Tp, _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed. ... but where from I know not. There is another in eeschema to do with replacing a symbol footprint using the footprint chooser, though I cannot replicate it and the trace (below) is unhelpful. The memory leak detector shows a lot of memory leaks on exit, though mostly related to Python Eval and to Wx fonts / pango. This latter group might be all Wx, fontconfig or pango's fault, not kicad -- wxCairoContext::GetTextExtent is one common denominator, wxWindow::GetCharHeight is another. [[ I did attempt to compile with wxwindows head, which is significantly advanced over the 3.1.5 currently being used, but sadly wxpython doesn't build against head (probably not a big thing - there's a patch already which might just need extending). Probably worth pursuing a little though. ]] The python leaks are mostly from dictresize, and I think they result from old dict memory, rather than being directly freed on resize, being added to the keys_free_list and then never freed from that. See https://github.com/python/cpython/blob/9942f42a93ccda047fd3558c47b822e99afe10c0/Objects/dictobject.c#L1281 . In turn this would suggest _PyDict_ClearFreeList / _PyDict_Fini is never called. I also think there is a regression: when selecting things at a Via, the Via itself is always selected and the normal select-what menu list doesn't appear. This makes it impossible to select anything within the area of a Via unless you move the Via first. The select-what does appear in other cases. I'm not 100% sure, but I think I've seen similar behaviour where tracks are selected when a graphic line could also have been selected. I may be wrong there though. Relating to Wx and HiDPI displays, even compiled with wx 3.1.5, many of the text widgets are too small (by roughly the factor of the DPI adjustment my display is using, 1.75) and either in consequence or also, the default window sizes are also too small, not encompassing their content. Finally, I have frequently been surprised by windows being raised or not raised. For example, I did a DRC check last night having not started eeschema in that session. The previous session had crashed, so when DRC started eeschema, eeschema posted an 'oops' message dialog asking to recover. All well and good, except the pcbnew window obscured both eeschema and its oops dialog, and pcbnew was left hung as if it had died. I did eventually realize it hadn't, and why, but it was not at all obvious. Another weirdness is that if I add a new part in eeschema, then update pcbnew, once I say 'do update', the eeschema window is raised with the part highlighted, obscuring the update dialog and its dialog with its close button. It is easy to recover from this but also startling and a bit annoying - I don't need eeschema to be raised and highlight the part in that case, ever. I hope this report is somewhat useful, Best wishes, Ruth $ flatpak run --devel org.kicad.KiCad.Nightly 04:35:27: Debug: ScreenToClient cannot work when toplevel window is not shown 04:35:37: Debug: ScreenToClient cannot work when toplevel window is not shown ==2==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default to
Re: [Kicad-developers] Version 6 release schedule
Hi Jan and José, Unfortunately I don't have a status update for you on the pybind11 API. I'm going to investigate fixing the regressions in the SWIG API so that your plugins can access the board design settings again. Best, Jon On Mon, Nov 1, 2021 at 6:04 AM Jan Mrázek wrote: > Hello Wayne and others, > > I am really looking forward for the release. As a maintainer of several > KiCAD plugins, I would like to add support for KiCAD 6 to them before > it is released so my users can migrate right away. However, the last > time I wanted to add the support I run into a problem of missing Python > API due to the migration from SWIG to Pybind. > > Could you (or anyone else) give me a brief overview (or point me to > relevant sources) where can I learn how was the API changed so I can > adapt my plugins? I was trying to learn about it from the commits, but I > wasn't able to learn anything due to the tremendous commit rate (I > admire the whole team for that), so this is why I am reaching out to you. > > Also, what can we expect in v6? And what will lack? I noticed that some > of the Python API relevant issues, that I consider as essential, still > left open and have no updates in them: > > - Pbnew Python API: Cannot to set board design settings > (https://gitlab.com/kicad/code/kicad/-/issues/6885) > - Python: Missing API for setting board aux origin > (https://gitlab.com/kicad/code/kicad/-/issues/8836) > - Eeschema python library > (https://gitlab.com/kicad/code/kicad/-/issues/2077) > > Jan > > On 28. 10. 21 23:09, Wayne Stambaugh wrote: > > The lead development team has agreed on a version 6 release schedule > > as follows: > > > > > > - String freeze November 1. > > - Tag RC1 on November 15. > > - All repos frozen on December 14. > > - Tag all repos with 6.0.0 on December 15. > > - 6.0.0 release announcement December 31 (maybe the day before Christmas > > just for fun). > > - Branch V6 and open master for new feature development on January 1. > > > > Our goal is to stick to that as closely as possible so if you have any > > outstanding work, please use this schedule as a reference to get it done. > > > > Going forward, we will be following the new stable release policy[1] > > which will move us to an annual release schedule. > > > > Thank you everyone for your continued support of the KiCad project. > > Hopefully the version 6 release will go reasonably smoothly and we can > > get started on version 7 in 2022. > > > > Cheers, > > > > Wayne > > > > [1]: https://dev-docs.kicad.org/en/rules-guidelines/release-policy/ > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Note to packagers: new data dependency for KiCad PCM
Hi Carsten, Sorry I was not clear, yes this is a dependency for the main binaries so it should go in the main package if you have multiple packages. Best, Jon On Mon, Nov 8, 2021 at 2:53 AM Carsten Schoenert wrote: > Hello Jon, > > Am 08.11.21 um 03:30 schrieb Jon Evans: > > Hi all, > > > > We just turned the plugin and content manager (PCM) feature on for all > > users. > > > > To work properly, this feature needs an additional directory packaged: > > > > $KICAD_DATA/schemas > > > > If your packaging scripts already grab everything inside $KICAD_DATA, > > you should not need to do anything. If you manually package each > > subdirectory (resources, scripting, template, etc) then please add the > > schemas directory to the list. > > which package should contain this new folder? > I guess the KiCad main application, am I right? > > -- > Regards > Carsten > > ___ > Mailing list: https://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