On Mon, 05 Mar 2018 17:25:09 -0500 Cedric Bail said:
> On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri wrote:
>
>
>
> > Well, I already mentioned this to you in irc, but replying here just
> > to make my point:
> >
> > I think the design is upside down, trying to make life easier at some
On Tue, 6 Mar 2018 10:37:10 -0300 Gustavo Sverzut Barbieri
said:
> On Tue, Mar 6, 2018 at 5:40 AM, Carsten Haitzler wrote:
> > On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri
> > said:
> >
> >> On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler
> >> wrote:
> >> > I just pushed:
> >> >
On Tue, Mar 6, 2018 at 5:40 AM, Carsten Haitzler wrote:
> On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri
>
> said:
>
>> On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler
>> wrote:
>> > I just pushed:
>> >
>> > eb0b826776b60e0d97218242a5c285d146fb6f3b
>> >
>> > https://git.enlightenm
On Mon, 5 Mar 2018 11:00:27 -0300 Gustavo Sverzut Barbieri
said:
> On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler wrote:
> > I just pushed:
> >
> > eb0b826776b60e0d97218242a5c285d146fb6f3b
> >
> > https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd
>
On March 5, 2018 6:00 AM, Gustavo Sverzut Barbieri wrote:
> Well, I already mentioned this to you in irc, but replying here just
> to make my point:
>
> I think the design is upside down, trying to make life easier at some
> point resulted in messy at the other side.
>
> okay, call it a task,
On Sat, Mar 3, 2018 at 2:02 AM, Carsten Haitzler wrote:
> I just pushed:
>
> eb0b826776b60e0d97218242a5c285d146fb6f3b
>
> https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd
>
> I wrote up a high level design document and description here for an idea of
I just pushed:
eb0b826776b60e0d97218242a5c285d146fb6f3b
https://git.enlightenment.org/core/efl.git/commit/?id=1bdd9e4dd15fc27da43b50fd29bfb1b0b30ef6bd
I wrote up a high level design document and description here for an idea of how
it works:
https://phab.enlightenment.org/w/efl-loops-threads/
I
On Fri, 22 Dec 2017 12:09:37 -0500 Cedric Bail said:
> Original Message
>
> > Subject: [E-devel] ecore / efl loop work
> > Local Time: December 14, 2017 9:30 PM
> > UTC Time: December 15, 2017 5:30 AM
> > From: ras...@rasterman.com
> > To:
On Fri, 22 Dec 2017 11:58:37 -0500 Cedric Bail said:
> > Original Message
> > Subject: Re: [E-devel] ecore / efl loop work
> > Local Time: December 20, 2017 5:30 PM
> > UTC Time: December 21, 2017 1:30 AM
> > From: ras...@rasterman.com
> > To
Original Message
> Subject: [E-devel] ecore / efl loop work
> Local Time: December 14, 2017 9:30 PM
> UTC Time: December 15, 2017 5:30 AM
> From: ras...@rasterman.com
> To: e
>
> I've been working on this for a while and now have things in a pretty goo
> Original Message
> Subject: Re: [E-devel] ecore / efl loop work
> Local Time: December 20, 2017 5:30 PM
> UTC Time: December 21, 2017 1:30 AM
> From: ras...@rasterman.com
> To: Andrew Williams
> Enlightenment developer list
>
> On Wed, 20 Dec
> ras...@rasterman.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail
> > said:
> > > > > >
> > > > > > > > Original M
; > > >
> > > > > On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <
> > > j...@videolan.org>
> > > > > said:
> > > > >
> > > > > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <
> > &g
right when someone could iterate or run a loop from
> > any
> > > > point in the call tree (inside a clicked callback/event from a button
> > or
> > > > the
> > > > pixel get callback or glview paint callback etc. etc.)... imagine the
> > hell
&
t; > wrote:
> > > > >
> > > > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail
> > said:
> > > > > >
> > > > > > > > Original Message
> > > > > > > > Subject: [E-deve
André <
> j...@videolan.org>
> > > said:
> > >
> > > > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler <
> ras...@rasterman.com
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, 15 Dec 2017 14:29:22 -0500
> > the
> > > pixel get callback or glview paint callback etc. etc.)... imagine the
> hell
> > > that
> > > is trying to nest loops like this anywhere and everywhere? the advice
> > > stands:
> > >
> > > "don't do this". :) ma
gt; >
> > > wrote:
> > >
> > > > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
> > > >
> > > > > > Original Message
> > > > > > Subject: [E-devel] ecore / efl loop work
> > > &
e this anywhere and everywhere? the advice
> > stands:
> >
> > "don't do this". :) making it work universally is insanely hard without
> > something failing somewhere.
> >
>
>
> > > On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André
said:
> > >
> > > > > ---- Original Message
> > > > > Subject: [E-devel] ecore / efl loop work
> > > > > Local Time: December 14, 2017 9:30 PM
> > > > > UTC Time: December 15, 2017 5:30 AM
> > > > > From: r
ere? the advice
> stands:
>
> "don't do this". :) making it work universally is insanely hard without
> something failing somewhere.
>
> > On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André
> > wrote:
> >
> > >
> > >
> > > On S
On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André said:
> On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler
> wrote:
>
> > On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
> >
> > > > Original Message ----
> > > > Subject:
ewhere.
> On Mon, Dec 18, 2017 at 8:16 PM, Jean-Philippe André
> wrote:
>
> >
> >
> > On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler
> > wrote:
> >
> >> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
> >>
> >> > > -
Dec 16, 2017 at 12:20 PM, Carsten Haitzler
> wrote:
>
>> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
>>
>> > > ---- Original Message
>> > > Subject: [E-devel] ecore / efl loop work
>> > > Local Time: December 14, 2
On Sat, Dec 16, 2017 at 12:20 PM, Carsten Haitzler
wrote:
> On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
>
> > > Original Message
> > > Subject: [E-devel] ecore / efl loop work
> > > Local Time: December 14, 2017 9:30 PM
> >
On Fri, 15 Dec 2017 14:29:22 -0500 Cedric Bail said:
> > Original Message
> > Subject: [E-devel] ecore / efl loop work
> > Local Time: December 14, 2017 9:30 PM
> > UTC Time: December 15, 2017 5:30 AM
> > From: ras...@rasterman.com
> > To:
> Original Message
> Subject: [E-devel] ecore / efl loop work
> Local Time: December 14, 2017 9:30 PM
> UTC Time: December 15, 2017 5:30 AM
> From: ras...@rasterman.com
> To: e
> there are internals that need some cleaning up like internal use of
>
On Fri, 15 Dec 2017 13:58:08 +0100 Vincent Torri said:
> On Fri, Dec 15, 2017 at 1:04 PM, Carsten Haitzler
> wrote:
> > On Fri, 15 Dec 2017 11:31:39 + Vincent Torri
> > said:
> >
> >> On Fri, Dec 15, 2017 at 11:13 AM, Carsten Haitzler
> >> wrote:
> >> > On Fri, 15 Dec 2017 07:07:53 +0100 V
On Fri, Dec 15, 2017 at 1:04 PM, Carsten Haitzler wrote:
> On Fri, 15 Dec 2017 11:31:39 + Vincent Torri
> said:
>
>> On Fri, Dec 15, 2017 at 11:13 AM, Carsten Haitzler
>> wrote:
>> > On Fri, 15 Dec 2017 07:07:53 +0100 Vincent Torri
>> > said:
>> >
>> >> On Fri, Dec 15, 2017 at 6:30 AM, Car
On Fri, 15 Dec 2017 11:31:39 + Vincent Torri said:
> On Fri, Dec 15, 2017 at 11:13 AM, Carsten Haitzler
> wrote:
> > On Fri, 15 Dec 2017 07:07:53 +0100 Vincent Torri
> > said:
> >
> >> On Fri, Dec 15, 2017 at 6:30 AM, Carsten Haitzler
> >> wrote:
> >> > I've been working on this for a whil
On Fri, Dec 15, 2017 at 11:13 AM, Carsten Haitzler wrote:
> On Fri, 15 Dec 2017 07:07:53 +0100 Vincent Torri
> said:
>
>> On Fri, Dec 15, 2017 at 6:30 AM, Carsten Haitzler
>> wrote:
>> > I've been working on this for a while and now have things in a pretty good
>> > state. I just pushed a commi
On Fri, 15 Dec 2017 07:07:53 +0100 Vincent Torri said:
> On Fri, Dec 15, 2017 at 6:30 AM, Carsten Haitzler
> wrote:
> > I've been working on this for a while and now have things in a pretty good
> > state. I just pushed a commit that does a huge amount of this (not all - see
> > 5dd52fd09b7d79c7
On Fri, Dec 15, 2017 at 6:30 AM, Carsten Haitzler wrote:
> I've been working on this for a while and now have things in a pretty good
> state. I just pushed a commit that does a huge amount of this (not all - see
> 5dd52fd09b7d79c70b3134423a87aa6400a2d994). But it's a huge step to efl loop
> objec
I've been working on this for a while and now have things in a pretty good
state. I just pushed a commit that does a huge amount of this (not all - see
5dd52fd09b7d79c70b3134423a87aa6400a2d994). But it's a huge step to efl loop
objects really being self contained.
efl loop fd didn't handle windows
On Sun, 26 Nov 2017 10:20:26 -0200 Gustavo Sverzut Barbieri
said:
> On Sun, Nov 26, 2017 at 2:08 AM, Carsten Haitzler
> wrote:
> >> You don't need that, just use Efl_Class.. that's it. no need to
> >> "type_new", no need to "event_get". Use *any* Efl_Class, then:
> >
> > Yes - I thought it over
On Sun, Nov 26, 2017 at 2:08 AM, Carsten Haitzler wrote:
>> You don't need that, just use Efl_Class.. that's it. no need to
>> "type_new", no need to "event_get". Use *any* Efl_Class, then:
>
> Yes - I thought it over more. a @class function can do this type-safely. pass
> in a loop obj and class
On Sat, 25 Nov 2017 20:59:08 -0200 Gustavo Sverzut Barbieri
said:
> On Thu, Nov 23, 2017 at 10:42 PM, Carsten Haitzler
> wrote: [...]
> >> - broadcast events: use Eo as below:
> >>
> >>* no "event type", just event object (which as its Efl_Class, of
> >> course);
> >
> > that was the idea. y
On Fri, Nov 24, 2017 at 12:17 AM, Jean-Philippe André wrote:
> Hi,
>
> Honestly I'm a bit confused by the use of promise/future as the core since
> ecore events aren't single-shot by definition (yes, some of them are). But
> that's beyond the point for my email.
my point is that you handle as sin
On Thu, Nov 23, 2017 at 10:42 PM, Carsten Haitzler wrote:
[...]
>> - broadcast events: use Eo as below:
>>
>>* no "event type", just event object (which as its Efl_Class, of course);
>
> that was the idea. you allocate a new event type (get an int or handle). you
> then GET the event type obje
Hi,
Honestly I'm a bit confused by the use of promise/future as the core since
ecore events aren't single-shot by definition (yes, some of them are). But
that's beyond the point for my email.
In C++ Felipe implemented eo event callbacks like this:
event_add(event_type, object, functor);
funct
On Thu, 23 Nov 2017 10:12:40 -0200 Gustavo Sverzut Barbieri
said:
> my proposal on this whole topic is a bit different and hopefully simpler:
>
> - one time, single shot (ecore jobs): reimplement as promises/future.
> currently they are done on top of events (to avoid changing the
> ecore_main.c
my proposal on this whole topic is a bit different and hopefully simpler:
- one time, single shot (ecore jobs): reimplement as promises/future.
currently they are done on top of events (to avoid changing the
ecore_main.c), of course this needs to be reversed. Simple and clean.
Just need core chang
Hi,
I talked to raster for clarification.
2017-11-22 14:57 GMT+09:00 Carsten Haitzler :
> So we had a partly done move to efl_loop. it still was all built on top of
> the
> main loop globals. If this is all done right then we can have multiple
> loops
> (e.g. one per thread) and that is a good t
So we had a partly done move to efl_loop. it still was all built on top of the
main loop globals. If this is all done right then we can have multiple loops
(e.g. one per thread) and that is a good thing.
So I've been fixing that. I've done just about all the globals in ecore EXCEPT
ecore events. I
On 09/08/16 19:20, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 9, 2016 at 12:31 PM, Tom Hacohen wrote:
>> On 09/08/16 16:24, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Aug 9, 2016 at 9:21 AM, Tom Hacohen wrote:
On 08/08/16 21:25, Gustavo Sverzut Barbieri wrote:
> Hi all,
>
> N
On Fri, Aug 12, 2016 at 4:47 AM, Carsten Haitzler wrote:
> On Thu, 11 Aug 2016 10:09:27 -0300 Gustavo Sverzut Barbieri
> said:
[...] big snippet about protocol specific classes [...]
> hmm i would just say "do http/https" and nothing more. if we want ftp - make
> it
> a new interface. it may r
On Thu, 11 Aug 2016 10:09:27 -0300 Gustavo Sverzut Barbieri
said:
> On Thu, Aug 11, 2016 at 4:17 AM, Carsten Haitzler
> wrote:
> >> * Eo.Base change to Eo.Loop_User
> >> * data event: payload: conn (?), size, data. Remove conn, since the
> >> event callback provides it.
> >
> > shouldn't we us
On Thu, Aug 11, 2016 at 4:17 AM, Carsten Haitzler wrote:
>> * Eo.Base change to Eo.Loop_User
>> * data event: payload: conn (?), size, data. Remove conn, since the
>> event callback provides it.
>
> shouldn't we use binbufs? :) same discussion as for efl.net core. :)
could be, as you can se
On Mon, 8 Aug 2016 17:25:27 -0300 Gustavo Sverzut Barbieri
said:
> Hi all,
>
> Now it's time to review Ecore_Con_Url towards a better API and then
> provide that as a Eo object. The current ecore_con_url will stay the
> same, but the new one can have some enhancements or simplifications if
> nee
On Tue, Aug 9, 2016 at 12:31 PM, Tom Hacohen wrote:
> On 09/08/16 16:24, Gustavo Sverzut Barbieri wrote:
>> On Tue, Aug 9, 2016 at 9:21 AM, Tom Hacohen wrote:
>>> On 08/08/16 21:25, Gustavo Sverzut Barbieri wrote:
Hi all,
Now it's time to review Ecore_Con_Url towards a better API a
On 09/08/16 16:24, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 9, 2016 at 9:21 AM, Tom Hacohen wrote:
>> On 08/08/16 21:25, Gustavo Sverzut Barbieri wrote:
>>> Hi all,
>>>
>>> Now it's time to review Ecore_Con_Url towards a better API and then
>>> provide that as a Eo object. The current ecore_c
On Tue, Aug 9, 2016 at 9:21 AM, Tom Hacohen wrote:
> On 08/08/16 21:25, Gustavo Sverzut Barbieri wrote:
>> Hi all,
>>
>> Now it's time to review Ecore_Con_Url towards a better API and then
>> provide that as a Eo object. The current ecore_con_url will stay the
>> same, but the new one can have som
On 08/08/16 21:25, Gustavo Sverzut Barbieri wrote:
> Hi all,
>
> Now it's time to review Ecore_Con_Url towards a better API and then
> provide that as a Eo object. The current ecore_con_url will stay the
> same, but the new one can have some enhancements or simplifications if
> needed.
>
> Before g
Hi all,
Now it's time to review Ecore_Con_Url towards a better API and then
provide that as a Eo object. The current ecore_con_url will stay the
same, but the new one can have some enhancements or simplifications if
needed.
Before going into the review, the core question will be to have a
single
Hello
On 10/24/14 07:30, Jean-Philippe André wrote:
> Hi
>
> On Fri, Oct 24, 2014 at 9:10 AM, Viacheslav Reutskiy
> wrote:
>
>> Hi everyone.
>>
>> I have one little question about Ecore Thread.
>> I need to stop the running thread and get
>> notified, I mean call callback, about it event.
>>
>>
Hi
On Fri, Oct 24, 2014 at 9:10 AM, Viacheslav Reutskiy
wrote:
> Hi everyone.
>
> I have one little question about Ecore Thread.
> I need to stop the running thread and get
> notified, I mean call callback, about it event.
>
> Ecore Thread has the function ecore_thread_close(),
> but if this fun
Hi everyone.
I have one little question about Ecore Thread.
I need to stop the running thread and get
notified, I mean call callback, about it event.
Ecore Thread has the function ecore_thread_close(),
but if this func not stopped the thread, Ecore
Thread waits until thread is finished, and then
> > > CC'ing Beber here as he controls the base system. Beber, we sometimes
> > > have the situation that pulseaudio does not seem to run which will
> > > fail some of our tests. Did you see any problems with pulseaudio on
> > > our slaves?
> >
> > Pulseaudio is not started as a daemon on any slav
Hello.
On Tue, 2014-03-04 at 11:33, Bertrand Jacquin wrote:
> Also,
>
> What does mean :
>
> ERR<25276>:ecore_con lib/ecore_con/ecore_con_dns.c:92 _ecore_con_dns_check()
> resolve failed: No such file or directory
>
> and
>
> ERR<25823>:eo lib/eo/eo.c:340 _eo_dov_internal() in
> tests/ecore/
Hello.
On Tue, 2014-03-04 at 11:31, Bertrand Jacquin wrote:
> Hi,
>
> > CC'ing Beber here as he controls the base system. Beber, we sometimes
> > have the situation that pulseaudio does not seem to run which will
> > fail some of our tests. Did you see any problems with pulseaudio on
> > our slav
On 04/03/14 13:44, Jean-Philippe André wrote:
> Hey,
>
> 2014-03-04 19:31 GMT+09:00 Bertrand Jacquin :
>
>> Hi,
>>
>>> CC'ing Beber here as he controls the base system. Beber, we sometimes
>>> have the situation that pulseaudio does not seem to run which will
>>> fail some of our tests. Did you see
Hey,
2014-03-04 19:31 GMT+09:00 Bertrand Jacquin :
> Hi,
>
> > CC'ing Beber here as he controls the base system. Beber, we sometimes
> > have the situation that pulseaudio does not seem to run which will
> > fail some of our tests. Did you see any problems with pulseaudio on
> > our slaves?
>
> P
Also,
What does mean :
ERR<25276>:ecore_con lib/ecore_con/ecore_con_dns.c:92 _ecore_con_dns_check()
resolve failed: No such file or directory
and
ERR<25823>:eo lib/eo/eo.c:340 _eo_dov_internal() in
tests/ecore/ecore_test_ecore_audio.c:514: Can't execute function
Ecore_Audio_In:ECORE_AUDIO_OB
Hi,
> CC'ing Beber here as he controls the base system. Beber, we sometimes
> have the situation that pulseaudio does not seem to run which will
> fail some of our tests. Did you see any problems with pulseaudio on
> our slaves?
Pulseaudio is not started as a daemon on any slave and have never be
Hello.
On Tue, 2014-03-04 at 16:09, Jean-Philippe André wrote:
> Hey Tom,
>
>
> 2014-03-03 23:15 GMT+09:00 Tom Hacohen :
>
> > Ecore suite hangs here, and has been like this for a while. Could some
> > ecore borker that broke it in the last few months fix it already?
> >
>
>
> Although I'm pr
Hey Tom,
2014-03-03 23:15 GMT+09:00 Tom Hacohen :
> Ecore suite hangs here, and has been like this for a while. Could some
> ecore borker that broke it in the last few months fix it already?
>
Although I'm probably not the borker you are referring to...
I'm really wondering in what context you
Ecore suite hangs here, and has been like this for a while. Could some
ecore borker that broke it in the last few months fix it already?
Thanks.
#0 0x75ea0fb3 in __select_nocancel () from /usr/lib/libc.so.6
#1 0x768c462f in _ecore_main_select (timeout=-1) at
../../src/lib/ecor
Hi Rajesh,
I have previously applied to this same email on the wayland-devel list.
"
Those APIs do not exist inside Ecore_Wayland yet. There is no concept of
NetWM in wayland yet so that API was never added. Getting the current
window which has focus would depend on the current shell. Due to no
On Thu, 20 Feb 2014 10:19:41 + (GMT) Rajesh PS said:
> Hello,
> We are porting an application to use ecore wayland. The requirement is to
> get the pid of the application which has the currrent focus window.
> ecore_x_window_focus_get and ecore_x_netwm_pid_get were used
>
> However ecore
Hello,
We are porting an application to use ecore wayland. The requirement is to get
the pid of the application which has the currrent focus window.
ecore_x_window_focus_get and ecore_x_netwm_pid_get were used
However ecore wayland apis does not seem to have something equivalent. Could
anyon
On Tue, Nov 5, 2013 at 7:04 PM, Tom Hacohen wrote:
> On 05/11/13 00:21, Cedric BAIL wrote:
>> On Mon, Nov 4, 2013 at 11:00 PM, Tom Hacohen wrote:
>>> As you may have noticed, Cedric committed Ecore Coroutine a while back.
>>> I don't know why we need our coroutine implementation, and I don't thin
On Tue, Nov 5, 2013 at 8:04 AM, Tom Hacohen wrote:
> /* The idea of this trick come from libcoroutine */
> /* __jmpbuf[6] == stack pointer */
> /* __jmpbuf[7] == program counter */
> coro->context->env[0].__jmpbuf[6] = ((uintptr_t)(&coro->stack));
> coro->context->env[0].__jmpbuf[
On 05/11/13 00:21, Cedric BAIL wrote:
> Hello,
>
> On Mon, Nov 4, 2013 at 11:00 PM, Tom Hacohen wrote:
>> As you may have noticed, Cedric committed Ecore Coroutine a while back.
>> I don't know why we need our coroutine implementation, and I don't think
>> anyone uses or will ever use it. Those as
Hello,
On Mon, Nov 4, 2013 at 11:00 PM, Tom Hacohen wrote:
> As you may have noticed, Cedric committed Ecore Coroutine a while back.
> I don't know why we need our coroutine implementation, and I don't think
> anyone uses or will ever use it. Those aside, the current coroutine
> implementation on
On Mon, 04 Nov 2013 14:00:21 + Tom Hacohen said:
> Hey guys,
>
> As you may have noticed, Cedric committed Ecore Coroutine a while back.
> I don't know why we need our coroutine implementation, and I don't think
> anyone uses or will ever use it. Those aside, the current coroutine
> implem
+1
On Mon, Nov 4, 2013 at 12:00 PM, Tom Hacohen wrote:
> Hey guys,
>
> As you may have noticed, Cedric committed Ecore Coroutine a while back.
> I don't know why we need our coroutine implementation, and I don't think
> anyone uses or will ever use it. Those aside, the current coroutine
> impleme
die
On Mon, Nov 4, 2013 at 12:00 PM, Tom Hacohen wrote:
> Hey guys,
>
> As you may have noticed, Cedric committed Ecore Coroutine a while back.
> I don't know why we need our coroutine implementation, and I don't think
> anyone uses or will ever use it. Those aside, the current coroutine
> implem
Hey guys,
As you may have noticed, Cedric committed Ecore Coroutine a while back.
I don't know why we need our coroutine implementation, and I don't think
anyone uses or will ever use it. Those aside, the current coroutine
implementation only works on Linux and relies on very hackish
implementa
On 08/08/13 21:47, Mike McCormack wrote:
> On 08/08/2013 09:59 PM, Christopher Michael wrote:
>
>> Are you ok if I fix this (use g_source_remove_poll there). Or are you
>> already planning to fix this ??
>
Fixed upstream now :)
> Go ahead and fix it. I've just started a new job, and am a bit sho
On 08/08/2013 09:59 PM, Christopher Michael wrote:
> Are you ok if I fix this (use g_source_remove_poll there). Or are you
> already planning to fix this ??
Go ahead and fix it. I've just started a new job, and am a bit short on
time right now. I did manage to get efl/ecore building (gah! bull
On 08/08/13 12:03, Mike McCormack wrote:
> On 08/08/2013 07:27 PM, Christopher Michael wrote:
>> I believe that I have discovered a problem with the glib integration
>> into ecore main loop. Basically the issue is this:
>>
>> _ecore_main_fdh_poll_add is calling g_source_add_poll (which seems correc
Random bug spotting in this case, though I can confirm that the integration
is still totally functional.
On Thu, Aug 8, 2013 at 12:03 PM, Mike McCormack wrote:
> On 08/08/2013 07:27 PM, Christopher Michael wrote:
> > I believe that I have discovered a problem with the glib integration
> > into e
On 08/08/2013 07:27 PM, Christopher Michael wrote:
> I believe that I have discovered a problem with the glib integration
> into ecore main loop. Basically the issue is this:
>
> _ecore_main_fdh_poll_add is calling g_source_add_poll (which seems correct)
>
> BUT
>
> _ecore_main_fdh_poll_del is call
I believe that I have discovered a problem with the glib integration
into ecore main loop. Basically the issue is this:
_ecore_main_fdh_poll_add is calling g_source_add_poll (which seems correct)
BUT
_ecore_main_fdh_poll_del is callback g_source_add_poll also (which
smells wrong).
Shouldn't t
Re:
CCLD libecore_x_xlib.la
../../../../libtool: line 6003: cd: NONE: No such file or directory
libtool: link: cannot determine absolute directory name of `NONE'
make[6]: *** [libecore_x_xlib.la] Error 1
Francris3 wrote:
i build fine efl from git, only debug disabled because of weird circul
i build fine efl from git, only debug disabled because of weird circular
deps
you can remove all *.la files from /usr/lib , /usr/local/lib. i think this
will fix your error
On Wed, 10 Jul 2013 19:57:36 +0300, Michael Hughes
wrote:
> In trying to compile ecore 1.7.7 on Fedora 19 32-bit, I a
On Wed, 10 Jul 2013 12:57:36 -0400 Michael Hughes said:
> In trying to compile ecore 1.7.7 on Fedora 19 32-bit, I am stumped by this:
>
>CCLD libecore_x_xlib.la
> ../../../../libtool: line 6003: cd: NONE: No such file or directory
> libtool: link: cannot determine absolute directory name o
In trying to compile ecore 1.7.7 on Fedora 19 32-bit, I am stumped by this:
CCLD libecore_x_xlib.la
../../../../libtool: line 6003: cd: NONE: No such file or directory
libtool: link: cannot determine absolute directory name of `NONE'
make[6]: *** [libecore_x_xlib.la] Error 1
make[6]: Leaving
On Fri, Jan 4, 2013 at 7:13 AM, Sebastian Dransfeld wrote:
> When running binaries in efl tree ecore evas does not find it's engines
>
> It tries to find them in:
> /e/efl/src/lib/ecore_evas/.libs/ecore_evas/engines/
> but they are in
> /e/efl/src/modules/ecore_evas/engines//.libs
>
> And there is
On Fri, 04 Jan 2013 10:13:34 +0100 Sebastian Dransfeld
said:
> When running binaries in efl tree ecore evas does not find it's engines
>
> It tries to find them in:
> /e/efl/src/lib/ecore_evas/.libs/ecore_evas/engines/
> but they are in
> /e/efl/src/modules/ecore_evas/engines//.libs
>
> And the
When running binaries in efl tree ecore evas does not find it's engines
It tries to find them in:
/e/efl/src/lib/ecore_evas/.libs/ecore_evas/engines/
but they are in
/e/efl/src/modules/ecore_evas/engines//.libs
And there is no MODULE_ARCH in the path either when in tree
S.
-
>>> -Original Message-
>>> From: Alex Wu [mailto:zhiwen...@linux.intel.com]
>>> Sent: 17 December 2012 03:20 AM
>>> To: 'Enlightenment developer list'
>>> Cc: eduardo.de.barros.l...@intel.com; wayland-de...@lists.fre
> -Original Message-
>> From: Alex Wu [mailto:zhiwen...@linux.intel.com]
>> Sent: 17 December 2012 03:20 AM
>> To: 'Enlightenment developer list'
>> Cc: eduardo.de.barros.l...@intel.com; wayland-de...@lists.freedesktop.org
>> Subject: [E-devel] ecore-
27;
> Cc: eduardo.de.barros.l...@intel.com; wayland-de...@lists.freedesktop.org
> Subject: [E-devel] ecore-wayland: (version2) Fix monitoring ECORE_FD_WRITE
> defaultly on wayland display fd lead to 100% cpu usage
>
> Hi all,
> To fix the regression reported at
> http://trac.enlightenment.or
03:20 AM
To: 'Enlightenment developer list'
Cc: eduardo.de.barros.l...@intel.com; wayland-de...@lists.freedesktop.org
Subject: [E-devel] ecore-wayland: (version2) Fix monitoring ECORE_FD_WRITE
defaultly on wayland display fd lead to 100% cpu usage
Hi all,
To fix the regression report
Hi all,
To fix the regression reported at
http://trac.enlightenment.org/e/ticket/1993, I cooked the version 2 of
this patch. Please checkout it out.
From e4ff96104075c972b24752e6799ac88acceccd48 Mon Sep 17 00:00:00 2001
From: Alex Wu
Date: Mon, 17 Dec 2012 11:05:11 +0800
Subject: [PATCH] ecore-way
...
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discove
On Fri, Dec 14, 2012 at 4:30 PM, Konno, Joe wrote:
>
> Hey gang, see bug #1993 -- this patch appears to have introduced a
> stability regression, see the bug in Trac. I'll be posting revert
> progress and findings on that bug.
Thanks for the heads up Joe. I reverted the patch in both trunk and
st
Hey gang, see bug #1993 -- this patch appears to have introduced a
stability regression, see the bug in Trac. I'll be posting revert
progress and findings on that bug.
On 2012-12-07 09:39 AM, Eduardo Lima (Etrunko) wrote:
> On Fri, Dec 7, 2012 at 3:41 AM, Alex Wu wrote:
>> Hi,
>>
>> In ecore_wl
On Fri, Dec 7, 2012 at 3:41 AM, Alex Wu wrote:
> Hi,
>
> In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE flag
> make CPU usage 100%. This is true for all efl app running on wayland.
>
> The proper way to monitor the ECORE_FD_WRITE is when the
> wl_display_flush() return value < 0
1 - 100 of 588 matches
Mail list logo
