Re: [Kicad-developers] Some first impressions on our tool framework
Tom, On 5/7/2019 9:36 AM, Tomasz Wlostowski wrote: > On 07/05/2019 07:47, Wayne Stambaugh wrote: >> >> On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote: >>> On 06/05/2019 09:48, Jeff Young wrote: 1) I hate the coroutines. They truncate backtraces in the debugger. >>> >>> Hi, >>> >>> How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on >>> Windows? I have working implementation of the latter already in the MSVC >>> branch. Are there any reasons to not use ucontext under Linux/OSX? >>> >>> Tom >>> >> >> I don't think we should be tackling this for v6. Our v6 task list is >> plenty long already. Let's shelve this discussion until v7 so we can >> take our time and come up with a plan that wont be too disruptive. > > Hi Wayne, > > I don't have any plans to rewrite the coroutine code during V6 > development cycle or doing any other radical changes. The only stuff I > want to add is: > - winfiber backend (already done), which removes assembly code for > Win32/Win64 - the last obstacle for easy MSVC builds. I'm assuming this wont break gcc builds on windows. > - proper caller address in the stack frame (so that Jeff will see full > stack traces) > > Both of these changes are relatively minor. > > Cheers, > 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
Re: [Kicad-developers] Some first impressions on our tool framework
On 07/05/2019 07:47, Wayne Stambaugh wrote: > > On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote: >> On 06/05/2019 09:48, Jeff Young wrote: >>> 1) I hate the coroutines. They truncate backtraces in the debugger. >> >> Hi, >> >> How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on >> Windows? I have working implementation of the latter already in the MSVC >> branch. Are there any reasons to not use ucontext under Linux/OSX? >> >> Tom >> > > I don't think we should be tackling this for v6. Our v6 task list is > plenty long already. Let's shelve this discussion until v7 so we can > take our time and come up with a plan that wont be too disruptive. Hi Wayne, I don't have any plans to rewrite the coroutine code during V6 development cycle or doing any other radical changes. The only stuff I want to add is: - winfiber backend (already done), which removes assembly code for Win32/Win64 - the last obstacle for easy MSVC builds. - proper caller address in the stack frame (so that Jeff will see full stack traces) Both of these changes are relatively minor. Cheers, 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
Re: [Kicad-developers] Some first impressions on our tool framework
On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote: > On 06/05/2019 09:48, Jeff Young wrote: >> 1) I hate the coroutines. They truncate backtraces in the debugger. > > Hi, > > How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on > Windows? I have working implementation of the latter already in the MSVC > branch. Are there any reasons to not use ucontext under Linux/OSX? > > Tom > I don't think we should be tackling this for v6. Our v6 task list is plenty long already. Let's shelve this discussion until v7 so we can take our time and come up with a plan that wont be too disruptive. Cheers, Wayne ___ 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] Some first impressions on our tool framework
Am 2019-05-06 21:02, schrieb Tomasz Wlostowski: On 06/05/2019 09:48, Jeff Young wrote: 1) I hate the coroutines. They truncate backtraces in the debugger. Hi, How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on Windows? I have working implementation of the latter already in the MSVC branch. Are there any reasons to not use ucontext under Linux/OSX? I'm sure you've seen this: https://www.boost.org/doc/libs/1_70_0/libs/context/doc/html/context/performance.html tldr; ucontext_t is really a bummer, performance-wise. Maybe we look into Boost::Fiber? It is stack-ful and as long as we stick to the the defined API, we should not hit the issues we had in the past with the low-level stuff. -S ___ 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] Some first impressions on our tool framework
Hi, On 07.05.19 03:02, Tomasz Wlostowski wrote: > How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on > Windows? I have working implementation of the latter already in the MSVC > branch. Are there any reasons to not use ucontext under Linux/OSX? Technically, these APIs are deprecated on OSX in favour of Grand Central Dispatch, but I doubt they will be going anywhere. Simon signature.asc Description: OpenPGP digital signature ___ 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] Some first impressions on our tool framework
On 06/05/2019 09:48, Jeff Young wrote: > 1) I hate the coroutines. They truncate backtraces in the debugger. Hi, How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on Windows? I have working implementation of the latter already in the MSVC branch. Are there any reasons to not use ucontext under Linux/OSX? 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
Re: [Kicad-developers] Some first impressions on our tool framework
That would be very cool, because a lot of the rest of the framework is really nice. > On 6 May 2019, at 18:22, Tomasz Wlostowski wrote: > > On 06/05/2019 09:48, Jeff Young wrote: >> 1) I hate the coroutines. They truncate backtraces in the debugger. > > Hi Jeff, > > I'm thinking how to improve this. Perhaps we can 'fix' a fake stack > frame that will allow the debugger to unwind the stack past the > coroutine entry point... > > 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
Re: [Kicad-developers] Some first impressions on our tool framework
On 06/05/2019 09:48, Jeff Young wrote: > 1) I hate the coroutines. They truncate backtraces in the debugger. Hi Jeff, I'm thinking how to improve this. Perhaps we can 'fix' a fake stack frame that will allow the debugger to unwind the stack past the coroutine entry point... 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
Re: [Kicad-developers] Some first impressions on our tool framework
Jeff, On 5/6/19 10:48 AM, Jeff Young wrote: > 1) I hate the coroutines. They truncate backtraces in the debugger. I'm not a big fan either but apparently they were the best solution for the P router design. I don't know if that is still the case or if we even tried a different solution at the time. Given the maintenance issues over the years with the coroutines context switching code, I would be willing to bet that an equally robust solution that didn't involve coroutines would not be frowned upon. I'm sure Tom is getting tired of fixing the context switching code. Wait until someone files a bug report that the RiscV chip context switching code has to be added to support that platform across multiple compilers. ;) > > 2) Having individual event loops for drawing, moving, etc. hugely improves > encapsulation. This has always been my preferred solution assuming we can pull it off with out any degradation of the P router performance. It always seemed to me that dovetailing event handlers in the event handler stack would be a simple way to provide tool specific behavior without having to fall back to coroutines or threads but I never tried it so I cannot say for sure if this is possible or not. > > 3) The improved encapsulation does make debugging easier overall. It’s still > a pity about (1) though.> > 4) It can be a bit hard to remember all the moving pieces required. (Hotkey > translation, action definition, transistion, etc.) I think this is true with event driven designs in general. Although coroutines add another layer of complexity on top of that. You can just as easily create the same issue by yielding in the middle of an event handler. I don't claim to be an authority on all of this but I know the issues that we have had to deal with. I don't want to spend time on this during v6 development but it's something we could take a look at during v7. Wayne > > Cheers, > Jeff. > ___ > 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] Some first impressions on our tool framework
1) I hate the coroutines. They truncate backtraces in the debugger. 2) Having individual event loops for drawing, moving, etc. hugely improves encapsulation. 3) The improved encapsulation does make debugging easier overall. It’s still a pity about (1) though. 4) It can be a bit hard to remember all the moving pieces required. (Hotkey translation, action definition, transistion, etc.) Cheers, Jeff. ___ 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
