Good point about GDI, I wasn't aware about that restriction. Windows
does have fibers which are basically coroutines - I wonder if a separate
Windows implementation could use those. I don't see any such restriction
for fibers.
On Thu, Mar 02, 2017 at 03:58:01PM +0100, "Torsten Hüter" wrote:
> Chri
On 02.03.2017 15:58, "Torsten Hüter" wrote:
> Chris:
>>> With a proper implementation this should be indistinguishable from
>>> coroutines, including to wx.
>
> This is your opinion not mine, I'm not sure. Again, read the paragraph about
> secondary threads:
> http://docs.wxwidgets.org/3.1/overvi
Chris:
>> With a proper implementation this should be indistinguishable from
>> coroutines, including to wx.
This is your opinion not mine, I'm not sure. Again, read the paragraph about
secondary threads:
http://docs.wxwidgets.org/3.1/overview_thread.html
"[..] under Win32 a thread can only acce
On Thu, Mar 02, 2017 at 10:15:36AM +0100, "Torsten Hüter" wrote:
> Hi Chris,
>
> please read the mail archive (Jan 2016), I've already tried this and
> experimented with different coroutine implementations. I've tested of course
> a variant based on pthreads too.
>
> The major showstopper was
Hi Chris,
please read the mail archive (Jan 2016), I've already tried this and
experimented with different coroutine implementations. I've tested of course a
variant based on pthreads too.
The major showstopper was, that's not recommended to use threads for GUI work,
please read:
http://docs
Hi Chris,
please read the mail archive (Jan 2016), I've already tried this and experimented with different coroutine implementations.
Of course a variant based on pthreads too.
The major showstopper was, that's not recommended to use threads for GUI work, please read:
http://docs.wxwidg
My point is that threading could be used to implement a *drop-in
replacement*...not that the tool framework should be structured around
them, but that it continues to use coroutines, and we make a coroutine
library that is implemented using threads... :P
On Wed, Mar 01, 2017 at 04:32:39PM -0500, W
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
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. B
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 stre
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
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 futur
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 se
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
te
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.
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 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 e
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
1.62 works fine here
On 24 February 2017 at 02:07, 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
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
just fyi
https://bugs.launchpad.net/kicad/+bug/1658249
On 24 February 2017 at 00:38, Chris Pavlina 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, b
Heh, okay, I should have tested more. Seems GAL is quite completely
broken after this patch, do not apply :P
On Thu, Feb 23, 2017 at 06:38:39AM -0500, Chris Pavlina wrote:
> Backtrace attached. Boost is 1.63.0.
>
> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> > Hi Chris,
>
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 segfaul
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
> 408static
Hi,
pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
dereference in the coroutine code:
coroutine.h
408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr
)
409{
410const auto& args = *aArgsPtr;
411auto* cor = args.destination;
24 matches
Mail list logo
