[Kicad-developers] macOS nightly builds no longer supporting 10.11
Hi folks! I've been unable to keep 10.11 builds going. I'm certain it's possible, but 10.11 is out of security updates and has been for a bit, so I don't feel too bad about bumping the lower version to 10.12. I should be be spending more time getting 10.15 working, not keeping 10.11 working. :) If this is a problem for anyone here, or predicted to be a problem with users, please let me know. I'll be migrating the nightly builds this week, and then adjusting the kicad-mac-builder README accordingly. Thanks! Adam ___ 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] common/tool/tool_dispatcher needs fixing.
I’ve pushed some code (and put my fire-suit on). Cheers, Jeff. > On 9 Jul 2019, at 21:10, Jeff Young wrote: > > Hmm… now I know why it doesn’t indicate handled for other stuff: it’s > difficult to get that information back from the coroutine. But I think a bug > fix I made earlier for the PassEvent stuff may give us a proxy for “handled”. > >> On 9 Jul 2019, at 21:07, Jeff Young wrote: >> >> Hi JP, >> >> This code definitely seems to have evolved a bit over time. ProcessEvent() >> specifically returns true only if it was a hotkey that was handled, and not >> for anything else. But I can’t find any code that benefits from that, so I >> suspect it’s vestigial. >> >> I think the best thing to do is to make it uniform (with respect to the Mac) >> and meet expectations (regarding the handled flag), and then fix the fallout >> from whatever it was that we didn’t understand about how it was supposed to >> work. >> >> I’ll play with it a bit before committing to make sure nothing’s /really/ >> broken. >> >> Cheers, >> Jeff. >> >> >>> On 9 Jul 2019, at 19:09, jp charras wrote: >>> >>> Hi Jeff, >>> >>> Sorry to bother you, but could you have a look into this file, and >>> especially into void TOOL_DISPATCHER::DispatchWxEvent( wxEvent& aEvent ). >>> >>> There are 2 things that need fixing (related to key event handling), >>> because our key event handler has bugs: >>> >>> 1 - the first is related to ESC key: >>> if a ESC key is typed, first avent is set: >>> evt = TOOL_EVENT( TC_COMMAND, TA_CANCEL_TOOL ); >>> and later: >>> m_toolMgr->ProcessEvent( *evt ); returns false: this is a bug. >>> Obviously, the key event is handled, and this line should return true. >>> (I recently added a workaround, but fixing the bug is better) >>> A golden rule on wxWidgets is: skip the key event if not handled by a >>> window or frame or..., or do not skip it when handled. >>> >>> 2 - the second issue is OSX specific: >>> Have a look to line 492 to 495: >>> the char event is not skipped ( when not handled ) on OSX. >>> I am thinking this is incorrect (at least in Debug mode it should be >>> skipped when not handled). >>> I am guessing this ugly hack comes from the time the tool dispatcher was >>> broken, and skip any key event, even when it was handled (and that was a >>> serious bug). >>> This is fortunately no longer the case. >>> But this conditional compilation creates a difference between OSX and >>> other OS. >>> We don't need that. >>> And it explains why you did not see some bugs related to hotkeys. >>> >>> 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 >> >> >> ___ >> 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] Strange program version numbering in KiCad
Hello Nick, Am 09.07.19 um 21:57 schrieb Nick Østergaard: > I have a hard time to understand how 5.99 is better to describe a > development version. 6.00 was already a bad way to describe it. > People also were confused. To me .99 seems very arbitrary. Why not > .1234? simply your mind is interpreting this different than .99. ;) GTK+ is doing this scheme with .90 to .99 for quite a while and this is *oneway* to do it. https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ KiCad is not the first project that needs to find it's own agreement on the versioning. (And wont be the last.) I'm personally not that happy with the usage of the 'git describe' command and the reading of tags from the tree. It was never a good approach in my eyes and it is currently really horrible for users to interpret the numbering schema. Even the current HEAD on the stable branch has a wrong number starting with. Why not hard-code the prefix within the CMake scripting voodoo like done in probably the majority of recent project that using autotools for configuration and add the commit count and id as a suffix like done now already? And a prefix '6.0-dev' or 'master-dev' is always better than the current solution. -- Regards Carsten Schoenert ___ 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] Strange program version numbering in KiCad
An option could be to prepend the branch name via something like: git symbolic-ref -q --short HEAD To the git describe --long we already have. On Tue, 9 Jul 2019 at 21:57, Nick Østergaard wrote: > > I have a hard time to understand how 5.99 is better to describe a > development version. 6.00 was already a bad way to describe it. People > also were confused. To me .99 seems very arbitrary. Why not .1234? > > On Mon, 8 Jul 2019 at 23:20, Eeli Kaikkonen wrote: > > > > > > > > ma 8. heinäk. 2019 klo 23.47 Nick Østergaard (oe.n...@gmail.com) kirjoitti: > >> > >> How is a number like 99 being any better than the latest release tag? > >> > > > > Did you read the original post, about the current problem? What is the > > "latest release tag"? 5.1.0 or 5.1.2? Number like 5.99 is unambiguous (and > > more clearly points to the next number, 6.0). Like this, my other > > suggestions were that the latest or the next release tag wouldn't be used > > at all for development versions. The reason is that it would be clear and > > unambiguous for all possible purposes. > > > > To add to the original suggestion: -dev ending could be added to make it > > even more clear that it's a development version, but can it create problems > > for Linux or other package numbering schemes? Probably not, 5.99.0-dev is > > smaller than 5.99.1-dev if 5.99-dev would be used for a release candidate. > > I wouldn't like using 5.99.0 and then 6.0-rc1 because in alphabetical order > > 6.0 comes before 6.0-rc1. Therefore 5.99.0, 5.99.1 etc. would be the > > easiest and least ambiguous solution. > > > > 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
Re: [Kicad-developers] common/tool/tool_dispatcher needs fixing.
Hmm… now I know why it doesn’t indicate handled for other stuff: it’s difficult to get that information back from the coroutine. But I think a bug fix I made earlier for the PassEvent stuff may give us a proxy for “handled”. > On 9 Jul 2019, at 21:07, Jeff Young wrote: > > Hi JP, > > This code definitely seems to have evolved a bit over time. ProcessEvent() > specifically returns true only if it was a hotkey that was handled, and not > for anything else. But I can’t find any code that benefits from that, so I > suspect it’s vestigial. > > I think the best thing to do is to make it uniform (with respect to the Mac) > and meet expectations (regarding the handled flag), and then fix the fallout > from whatever it was that we didn’t understand about how it was supposed to > work. > > I’ll play with it a bit before committing to make sure nothing’s /really/ > broken. > > Cheers, > Jeff. > > >> On 9 Jul 2019, at 19:09, jp charras wrote: >> >> Hi Jeff, >> >> Sorry to bother you, but could you have a look into this file, and >> especially into void TOOL_DISPATCHER::DispatchWxEvent( wxEvent& aEvent ). >> >> There are 2 things that need fixing (related to key event handling), >> because our key event handler has bugs: >> >> 1 - the first is related to ESC key: >> if a ESC key is typed, first avent is set: >> evt = TOOL_EVENT( TC_COMMAND, TA_CANCEL_TOOL ); >> and later: >> m_toolMgr->ProcessEvent( *evt ); returns false: this is a bug. >> Obviously, the key event is handled, and this line should return true. >> (I recently added a workaround, but fixing the bug is better) >> A golden rule on wxWidgets is: skip the key event if not handled by a >> window or frame or..., or do not skip it when handled. >> >> 2 - the second issue is OSX specific: >> Have a look to line 492 to 495: >> the char event is not skipped ( when not handled ) on OSX. >> I am thinking this is incorrect (at least in Debug mode it should be >> skipped when not handled). >> I am guessing this ugly hack comes from the time the tool dispatcher was >> broken, and skip any key event, even when it was handled (and that was a >> serious bug). >> This is fortunately no longer the case. >> But this conditional compilation creates a difference between OSX and >> other OS. >> We don't need that. >> And it explains why you did not see some bugs related to hotkeys. >> >> 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 > > > ___ > 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] common/tool/tool_dispatcher needs fixing.
Hi JP, This code definitely seems to have evolved a bit over time. ProcessEvent() specifically returns true only if it was a hotkey that was handled, and not for anything else. But I can’t find any code that benefits from that, so I suspect it’s vestigial. I think the best thing to do is to make it uniform (with respect to the Mac) and meet expectations (regarding the handled flag), and then fix the fallout from whatever it was that we didn’t understand about how it was supposed to work. I’ll play with it a bit before committing to make sure nothing’s /really/ broken. Cheers, Jeff. > On 9 Jul 2019, at 19:09, jp charras wrote: > > Hi Jeff, > > Sorry to bother you, but could you have a look into this file, and > especially into void TOOL_DISPATCHER::DispatchWxEvent( wxEvent& aEvent ). > > There are 2 things that need fixing (related to key event handling), > because our key event handler has bugs: > > 1 - the first is related to ESC key: > if a ESC key is typed, first avent is set: > evt = TOOL_EVENT( TC_COMMAND, TA_CANCEL_TOOL ); > and later: > m_toolMgr->ProcessEvent( *evt ); returns false: this is a bug. > Obviously, the key event is handled, and this line should return true. > (I recently added a workaround, but fixing the bug is better) > A golden rule on wxWidgets is: skip the key event if not handled by a > window or frame or..., or do not skip it when handled. > > 2 - the second issue is OSX specific: > Have a look to line 492 to 495: > the char event is not skipped ( when not handled ) on OSX. > I am thinking this is incorrect (at least in Debug mode it should be > skipped when not handled). > I am guessing this ugly hack comes from the time the tool dispatcher was > broken, and skip any key event, even when it was handled (and that was a > serious bug). > This is fortunately no longer the case. > But this conditional compilation creates a difference between OSX and > other OS. > We don't need that. > And it explains why you did not see some bugs related to hotkeys. > > 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 ___ 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] Strange program version numbering in KiCad
I have a hard time to understand how 5.99 is better to describe a development version. 6.00 was already a bad way to describe it. People also were confused. To me .99 seems very arbitrary. Why not .1234? On Mon, 8 Jul 2019 at 23:20, Eeli Kaikkonen wrote: > > > > ma 8. heinäk. 2019 klo 23.47 Nick Østergaard (oe.n...@gmail.com) kirjoitti: >> >> How is a number like 99 being any better than the latest release tag? >> > > Did you read the original post, about the current problem? What is the > "latest release tag"? 5.1.0 or 5.1.2? Number like 5.99 is unambiguous (and > more clearly points to the next number, 6.0). Like this, my other suggestions > were that the latest or the next release tag wouldn't be used at all for > development versions. The reason is that it would be clear and unambiguous > for all possible purposes. > > To add to the original suggestion: -dev ending could be added to make it even > more clear that it's a development version, but can it create problems for > Linux or other package numbering schemes? Probably not, 5.99.0-dev is smaller > than 5.99.1-dev if 5.99-dev would be used for a release candidate. I wouldn't > like using 5.99.0 and then 6.0-rc1 because in alphabetical order 6.0 comes > before 6.0-rc1. Therefore 5.99.0, 5.99.1 etc. would be the easiest and least > ambiguous solution. > > 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
[Kicad-developers] common/tool/tool_dispatcher needs fixing.
Hi Jeff, Sorry to bother you, but could you have a look into this file, and especially into void TOOL_DISPATCHER::DispatchWxEvent( wxEvent& aEvent ). There are 2 things that need fixing (related to key event handling), because our key event handler has bugs: 1 - the first is related to ESC key: if a ESC key is typed, first avent is set: evt = TOOL_EVENT( TC_COMMAND, TA_CANCEL_TOOL ); and later: m_toolMgr->ProcessEvent( *evt ); returns false: this is a bug. Obviously, the key event is handled, and this line should return true. (I recently added a workaround, but fixing the bug is better) A golden rule on wxWidgets is: skip the key event if not handled by a window or frame or..., or do not skip it when handled. 2 - the second issue is OSX specific: Have a look to line 492 to 495: the char event is not skipped ( when not handled ) on OSX. I am thinking this is incorrect (at least in Debug mode it should be skipped when not handled). I am guessing this ugly hack comes from the time the tool dispatcher was broken, and skip any key event, even when it was handled (and that was a serious bug). This is fortunately no longer the case. But this conditional compilation creates a difference between OSX and other OS. We don't need that. And it explains why you did not see some bugs related to hotkeys. 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] Strange program version numbering in KiCad
ti 9. heinäk. 2019 klo 19.45 Simon Richter (simon.rich...@hogyros.de) kirjoitti: > I still think it is a bit confusing to have a tag > on something that is not a release. > "git tag" reveals to me that 5.1.0-dev is already a tag, and it's not a release. Right? 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
Re: [Kicad-developers] Strange program version numbering in KiCad
Hi, On Tue, Jul 09, 2019 at 09:26:11AM -0400, Steven A. Falco wrote: > I'd vote for the .99 approach, assuming I get a vote. :-) The main difficulty is the way the version number generation is implemented. We use "git describe" to get the name of the last tag, then add the number of commits and the commit ID. So, if we wanted to have .99 in the version number somewhere, there'd have to be a tag "5.99" on some intermediate version. I guess I could special-case that in the delivery pipeline so that it doesn't get uploaded as a stable release, but I still think it is a bit confusing to have a tag on something that is not a release. Simon ___ 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] Compil issue due to commit 36f1d023
Oops, those were supposed to be tool IDs.
I’ve pushed another commit. Let me know if it still doesn’t compile (the LLDB
compiler is much more aggressive about auto-type-casting).
> On 9 Jul 2019, at 16:44, jp charras wrote:
>
> This commit creates 2 similar issues:
> the first issue is:
>
> F:/kicad-launchpad/git_testing/pcbnew/tools/edit_tool.cpp:1299:24:
> error: cannot convert 'const wxString' to 'const string&' {aka 'const
> std::__cxx11::basic_string&'}
> 1299 | frame()->PushTool( _( "Select reference point for the
> copy..." ) );
> |^
> ||
> |const wxString
> In file included from
> F:/kicad-launchpad/git_testing/include/pcb_base_frame.h:38,
> from
> F:/kicad-launchpad/git_testing/pcbnew/pcb_base_edit_frame.h:28,
> from
> F:/kicad-launchpad/git_testing/pcbnew/pcb_edit_frame.h:26,
> from
> F:/kicad-launchpad/git_testing/pcbnew/tools/edit_tool.cpp:34:
> F:/kicad-launchpad/git_testing/include/eda_draw_frame.h:310:47: note:
> initializing argument 1 of 'virtual void EDA_DRAW_FRAME::PushTool(const
> string&)'
> 310 | virtual void PushTool( const std::string& actionName );
>
>
> I have also some trouble with a translated string trying to be stored in
> a std::string.
> This is not possible.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Compil issue due to commit 36f1d023
This commit creates 2 similar issues:
the first issue is:
F:/kicad-launchpad/git_testing/pcbnew/tools/edit_tool.cpp:1299:24:
error: cannot convert 'const wxString' to 'const string&' {aka 'const
std::__cxx11::basic_string&'}
1299 | frame()->PushTool( _( "Select reference point for the
copy..." ) );
|^
||
|const wxString
In file included from
F:/kicad-launchpad/git_testing/include/pcb_base_frame.h:38,
from
F:/kicad-launchpad/git_testing/pcbnew/pcb_base_edit_frame.h:28,
from
F:/kicad-launchpad/git_testing/pcbnew/pcb_edit_frame.h:26,
from
F:/kicad-launchpad/git_testing/pcbnew/tools/edit_tool.cpp:34:
F:/kicad-launchpad/git_testing/include/eda_draw_frame.h:310:47: note:
initializing argument 1 of 'virtual void EDA_DRAW_FRAME::PushTool(const
string&)'
310 | virtual void PushTool( const std::string& actionName );
I have also some trouble with a translated string trying to be stored in
a std::string.
This is not possible.
--
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] Strange program version numbering in KiCad
On 7/8/19 10:41 PM, Reece R. Pollack wrote: > On 7/8/19 10:36 PM, Kevin Cozens wrote: >> On 2019-07-08 5:10 p.m., Dino Ghilardi wrote: >>> think about the linux kernel versioning number scheme: even subversion >>> number means stable release. Odd subversion number means >>> experimental/development branch. >> >> The kernel used to follow the odd/even numbering scheme but they stopped >> doing that during the 2 series of kernels. It is possible they are doing it >> again. I haven't looked at kernel release numbering in quite a few years. >> > No. That was abandoned years ago, after the release of 2.6, in favor of a > stream of smaller, incremental steps rather than periodic huge jumps that > took years to be adopted. The 3.0 release could easily have been numbered > 2.6.40, being only an incremental change over 2.6.39. I'd vote for the .99 approach, assuming I get a vote. :-) Steve ___ 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] Crash Reporter
Tom, On 7/9/19 2:41 AM, Tomasz Wlostowski wrote: > On 06/07/2019 21:10, Ian McInerney wrote: >> Tom, >> >> Not to pile on the questions, but does the linux stack trace support >> exist in the entire 3.0.x line, or how far back does it go? Currently, >> the minimum version searched by cmake is 3.0.0, and some major linux >> distros only have 3.0.2 (Debian Stable, EPEL6/7, and Ubuntu 16.04 to >> name a few). > > Hi, > > Under liunx stack trace works fine in 3.0.2. Under Windows it's not > implemented at all (unless using a crazy hack self-exception-raising > hack that works only under MSVC). > > I can work this around by having our own Windows stack walker - after > all the whole purpose of the crash reporter was easy debug reports for > Windows users. Under Linux everyone knows how to use a debugger, > otherwise it's impossible to work ;-) I'm assuming that you mean that you are going to pull the wxDebugReporter code from the 3.1 branch of wxWidgets which can be removed once wxWidgets 3.2 becomes the default. If it's any more than that, I would rather wait until 3.2 is available. > > Tom > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
