kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

We all have our preferred solutions the problem at hand.  I personally
didn't see any reason to not use events.  I have a sneaking suspicion
that the context switching was done to isolate the coder from having to
deal with events directly which on the surfaces seems like a good idea
but causes it's own set of design issues when executed within an event
driven application.  My preference would have been to have the tool
objects be derived from wxEventHandler (or abstracted out to work with
different event systems) and inserted between the canvas and the main
window event handler on the wxWidgets event handler stack.  Since no one
else stepped up to resolve the issues, the person who resolved them wins. ;)

On 3/1/2017 12:01 PM, Chris Pavlina wrote:
> I know I've suggested this before and been shot down, but I'm still
> pretty convinced a coroutine library could be made that makes use of
> native threading support. This would be totally portable to all
> platforms!
> 
> I don't have the time to POC it myself, I already have a kicad todo list
> miles long. But it seems to me that if we were to spawn a thread for
> each coroutine, lock them all to the same core via CPU affinity to avoid
> any caching issues, and use a global lock and simple scheduler to
> interleave the coroutines (i.e.  when a coroutine yields, it really sets
> a lock and waits for it to unlock), it should work just fine..
> 
> On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote:
>> That's the one is was thinking about!  AArch64 is coming fast so we only
>> do ourselves a disservice by not supporting it.  In fact, there is now a
>> aarch64 device available designed with KiCad.  It would be ironic if
>> KiCad couldn't run on it due to lack of support.  SPARC and PPC may not
>> be main stream but if we can support them by using an already vetted
>> library, than that is my preference.
>>
>> On 3/1/2017 10:25 AM, Chris Pavlina wrote:
>>> Ah, crap. Missed that. Don't think I have one lying about anymore to
>>> volunteer... :(
>>>
>>> On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote:
>>>> On 01.03.2017 16:19, Chris Pavlina wrote:
>>>>> Wayne *please* tell me you won't block something that fixes macOS
>>>>> support and eliminates future boost API problems (which we've had
>>>>> SEVERAL problems with in the past) because of a lack of support for
>>>>> bloody *SPARC and PPC*. If there is a single user using KiCad on these
>>>>> platforms I would like to see them.
>>>>>
>>>> Hi Chris,
>>>>
>>>> Boost does support aarch64, I just lack a compiler/machine to test that...
>>>>
>>>> Cheers,
>>>> T.
>>>>> Now, the lack of support for aarch64 is a disappointment, but it looks
>>>>> like boost currently doesn't support that either.
>>>>>
>>>>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
>>>>>> On 01.03.2017 15:58, Wayne Stambaugh wrote:
>>>>>>> I am in favor of this if and only if we have equivalent or better
>>>>>>> architecture coverage compared to the boost context library.  If not,
>>>>>>> than I am opposed to it.
>>>>>>>
>>>>>> Hi Wayne,
>>>>>>
>>>>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
>>>>>> test the sparc/PPC ports for obvious reasons. I could  add linux
>>>>>> sparc/PPC support but without testing, since I don't have a suitable
>>>>>> machine.
>>>>>>
>>>>>> For the moment, libcontext works on every OS/CPU we officially support.
>>>>>>
>>>>>> Cheers,
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>> On 3/1/2017 9:32 AM, Chris Pavlina wrote:
>>>>>>>> I am in favor of this.
>>>>>>>>
>>>>>>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
>>>>>>>>> I will do my best, but I really cannot promise any time slot for looking
>>>>>>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
>>>>>>>>> The number of #ifdefs in tge current coroutine code makes eyes pop out,
>>>>>>>>> and I am afraid with the new issue we would be forced to add "#ifdef
>>>>>>>>> __APPLE__" to this horrible mess.
>>>>>>>
>>>>>>> This probably could have been hidden using cmake.  It typically takes
>>>>>>> more effort to do it this way but it results in cleaner source code.
>>>>>>>
>>>>>>>>>
>>>>>>>>> This way we should be immune to future boost::context changes. The
>>>>>>>>> drawback is, we are on our own if there is a new architecture to
>>>>>>>>> support. On the other hand, how often a new architecture becomes popular
>>>>>>>>> enough to care about it?
>>>>>>>>>
>>>>>>>>> To sum up: I would switch to libcontext and stop worrying.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Orson
>>>>>>>>>
>>>>>>>>> 1. https://github.com/twlostow/libcontext
>>>>>>>>>
>>>>>>>>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
>>>>>>>>>> This is a known issue.  I believe the last valid version of boost that
>>>>>>>>>> doesn't cause a crash is 1.61.  Anything after that causes this issue on
>>>>>>>>>> all platforms not just osx.  @Orson or @Tom, any chance you could take a
>>>>>>>>>> look at this to see what boost changed in the context library?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Wayne
>>>>>>>>>>
>>>>>>>>>> On 2/23/2017 6:49 AM, Simon Wells wrote:
>>>>>>>>>>> just fyi
>>>>>>>>>>>
>>>>>>>>>>> https://bugs.launchpad.net/kicad/+bug/1658249
>>>>>>>>>>>
>>>>>>>>>>> On 24 February 2017 at 00:38, Chris Pavlina <pavlina.chris@xxxxxxxxx> wrote:
>>>>>>>>>>>> Backtrace attached. Boost is 1.63.0.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
>>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would you give more details about the problem? Boost version, backtrace?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Orson
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
>>>>>>>>>>>>>> dereference in the coroutine code:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> coroutine.h
>>>>>>>>>>>>>> 408    static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr )
>>>>>>>>>>>>>> 409    {
>>>>>>>>>>>>>> 410        const auto& args = *aArgsPtr;
>>>>>>>>>>>>>> 411        auto* cor = args.destination;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> aArgsPtr is null and I don't understand WHY. However, I was able to make
>>>>>>>>>>>>>> things appear to work by short-circuiting this function if the argument
>>>>>>>>>>>>>> is null.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Patch attached. It Works For Me™, but I'd like someone who knows the
>>>>>>>>>>>>>> coroutine code to look and make sure I haven't made a mess of things.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>