On Sat, 24 Dec 2016 04:40:20 +0100 Vincent Torri said:
> you will have anyway #ifdef because of the [win32 | fd]_handler_add()
> in ethumb_slave, so...
that also shouldn't be there. no fd handlers for stdin etc. no it the portable
way with thread+feedback.
yes - an abstraction would be good but
you will have anyway #ifdef because of the [win32 | fd]_handler_add()
in ethumb_slave, so...
On Sat, Dec 24, 2016 at 1:45 AM, Carsten Haitzler wrote:
> On Fri, 23 Dec 2016 12:50:34 +0100 Vincent Torri
> said:
>
>> On Fri, Dec 23, 2016 at 11:23 AM, Andrii Kroitor
>> wrote:
>> >
>> > On 23.12.
On Fri, 23 Dec 2016 12:50:34 +0100 Vincent Torri said:
> On Fri, Dec 23, 2016 at 11:23 AM, Andrii Kroitor
> wrote:
> >
> > On 23.12.16 06:35, Vincent Torri wrote:
> >> hey
> >>
> >> i don't like the idea of getc/ungetc in the thread, imho it's a bad hack
> >> you do that for ethumb_slave, i gues
On Fri, Dec 23, 2016 at 11:23 AM, Andrii Kroitor wrote:
>
> On 23.12.16 06:35, Vincent Torri wrote:
>> hey
>>
>> i don't like the idea of getc/ungetc in the thread, imho it's a bad hack
>> you do that for ethumb_slave, i guess, but i think that the wait for
>> input should be in ethumb slave, with
On 23.12.16 06:35, Vincent Torri wrote:
> hey
>
> i don't like the idea of getc/ungetc in the thread, imho it's a bad hack
> you do that for ethumb_slave, i guess, but i think that the wait for
> input should be in ethumb slave, with a thread and ReadConsole(). and
> not the hack you did
>
> Vince
hey
i don't like the idea of getc/ungetc in the thread, imho it's a bad hack
you do that for ethumb_slave, i guess, but i think that the wait for
input should be in ethumb slave, with a thread and ReadConsole(). and
not the hack you did
Vincent
---
lorddrew pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=053613db5277708f81de5b4e088155c127ba8ec9
commit 053613db5277708f81de5b4e088155c127ba8ec9
Author: Andrii Kroitor
Date: Wed Dec 21 15:08:58 2016 +0200
ecore: fix wait for stdin on Windows
