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
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: [email protected]
> > To: e
> >
> > I've been working on this f
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: [email protected]
> > 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: [email protected]
> To: e
>
> I've been working on this for a while and now have things in a pretty good
> state. I just pushed a
> 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: [email protected]
> To: Andrew Williams
> Enlightenment developer list
>
> On Wed, 20 Dec
On Wed, 20 Dec 2017 13:27:06 +0900 Jean-Philippe André said:
> On Wed, Dec 20, 2017 at 12:41 PM, Carsten Haitzler
> wrote:
>
> > On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André
> > said:
> >
> > > On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler > >
> > > wrote:
> > >
> > > > On Mon,
On Wed, 20 Dec 2017 18:36:30 + Andrew Williams said:
> Since this came in the core_loop example is no longer working correctly.
> https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c
>
> There are a few ERR about timers being dead and objects having parents
On Wed, 20 Dec 2017 13:23:22 +0900 Jean-Philippe André said:
> On Wed, Dec 20, 2017 at 12:36 PM, Carsten Haitzler
> wrote:
>
> > On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André
> > said:
> >
> > > On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler > >
> > > wrote:
> > >
> > > > On Tue,
Since this came in the core_loop example is no longer working correctly.
https://git.enlightenment.org/tools/examples.git/tree/reference/c/core/src/core_event.c
There are a few ERR about timers being dead and objects having parents that
didn't happen before.
Additionally a EFL_LOOP child of mainlo
On Wed, Dec 20, 2017 at 12:41 PM, Carsten Haitzler
wrote:
> On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André
> said:
>
> > On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler >
> > wrote:
> >
> > > On Mon, 18 Dec 2017 20:16:49 +0900 Jean-Philippe André <
> [email protected]>
> > > said:
>
On Wed, Dec 20, 2017 at 12:36 PM, Carsten Haitzler
wrote:
> On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André
> said:
>
> > On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler >
> > wrote:
> >
> > > On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André <
> [email protected]>
> > > said:
>
On Wed, 20 Dec 2017 11:58:21 +0900 Jean-Philippe André said:
> On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler
> wrote:
>
> > 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,
On Wed, 20 Dec 2017 11:19:30 +0900 Jean-Philippe André said:
> On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler
> wrote:
>
> > On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André
> > said:
> >
> > > Hey raster,
> > >
> > > I'm confused by something, see ecore_test_ecore_main_loop_timer_in
On Wed, Dec 20, 2017 at 11:01 AM, Carsten Haitzler
wrote:
> 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 Mess
On Wed, Dec 20, 2017 at 11:10 AM, Carsten Haitzler
wrote:
> On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André
> said:
>
> > Hey raster,
> >
> > I'm confused by something, see ecore_test_ecore_main_loop_timer_inner,
> > and ecore_test_ecore_main_loop_event_recursive.
> > This test runs the m
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: [E-devel] ecore / efl loop work
> > > > Local Ti
On Tue, 19 Dec 2017 11:53:13 +0900 Jean-Philippe André said:
> Hey raster,
>
> I'm confused by something, see ecore_test_ecore_main_loop_timer_inner,
> and ecore_test_ecore_main_loop_event_recursive.
> This test runs the main loop inside the main loop, which the documentation
> says you shouldn'
Hey raster,
I'm confused by something, see ecore_test_ecore_main_loop_timer_inner,
and ecore_test_ecore_main_loop_event_recursive.
This test runs the main loop inside the main loop, which the documentation
says you shouldn't do. The test case passes because it's badly written
(marks the success va
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
> > > UTC Time: December 15, 2017 5:30 AM
> > > F
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: [email protected]
> > To: e
>
>
>
> > there are internals tha
> 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: [email protected]
> To: e
> there are internals that need some cleaning up like internal use of
> ecore_timer, ecore_idler. ne
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
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
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
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
> > > 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
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
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
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
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
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
On 19/12/12 14:17, Eduardo Lima (Etrunko) wrote:
> Can you backport this please? :)
>
I cannot currently because I do not have any of the 1.7 branch checked
out ... If someone Does have those and some free time, then please do
backport this :)
dh
> On Wed, Dec 19, 2012 at 12:00 PM, Christopher
Can you backport this please? :)
On Wed, Dec 19, 2012 at 12:00 PM, Christopher Michael
wrote:
> Hi Alex,
>
> I found a spare moment today (don't ask me how lol) to have a look at
> this :) ... In svn it goes ;)
>
> Thanks :)
>
> dh
>
> On 18/12/12 09:09, Chris Michael wrote:
>> Alex,
>>
>> Thank
Hi Alex,
I found a spare moment today (don't ask me how lol) to have a look at
this :) ... In svn it goes ;)
Thanks :)
dh
On 18/12/12 09:09, Chris Michael wrote:
> Alex,
>
> Thank you for the patch :) Sadly I cannot take a look at it right now (busy
> with some other things), but I will place
Alex,
Thank you for the patch :) Sadly I cannot take a look at it right now (busy
with some other things), but I will place it in my queue and get to it
probably after Christmas break.
Cheers,
dh
-Original Message-
From: Alex Wu [mailto:[email protected]]
Sent: 17 December 2012
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
hey
On Mon, Nov 5, 2012 at 11:50 AM, Leif Middelschulte
wrote:
> Hello everyone, especially vincent!
>
> I'm trying to package the latest release of the efl (up to elemetary) for
> the mac os brew package manager (https://github.com/mxcl/homebrew).
>
> Sadly ecore fails during compilation. Appare
On 02/11/12 02:33, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 1 Nov 2012 18:53:32 -0200 Gustavo Sverzut Barbieri
> said:
>
>> Hi all,
>>
>> As I always complain, the problems with those "easy" solutions such as EO
>> macro and types hell is when you have incorrect usage. While the correct
On Fri, 2 Nov 2012 01:55:42 -0200 Gustavo Sverzut Barbieri
said:
> On Thu, Nov 1, 2012 at 10:33 PM, Carsten Haitzler wrote:
>
> > On Thu, 1 Nov 2012 18:53:32 -0200 Gustavo Sverzut Barbieri
> > said:
> >
> > > Hi all,
> > >
> > > As I always complain, the problems with those "easy" solutions suc
On Thu, Nov 1, 2012 at 10:33 PM, Carsten Haitzler wrote:
> On Thu, 1 Nov 2012 18:53:32 -0200 Gustavo Sverzut Barbieri
> said:
>
> > Hi all,
> >
> > As I always complain, the problems with those "easy" solutions such as EO
> > macro and types hell is when you have incorrect usage. While the correc
On Fri, Nov 2, 2012 at 9:33 AM, Carsten Haitzler wrote:
> On Thu, 1 Nov 2012 18:53:32 -0200 Gustavo Sverzut Barbieri
> said:
>> As I always complain, the problems with those "easy" solutions such as EO
>> macro and types hell is when you have incorrect usage. While the correct
>> path is all nice
On Thu, 1 Nov 2012 18:53:32 -0200 Gustavo Sverzut Barbieri
said:
> Hi all,
>
> As I always complain, the problems with those "easy" solutions such as EO
> macro and types hell is when you have incorrect usage. While the correct
> path is all nice and simple, the incorrect is tricky to solve.
>
On Fri, Nov 2, 2012 at 5:53 AM, Gustavo Sverzut Barbieri
wrote:
> As I always complain, the problems with those "easy" solutions such as EO
> macro and types hell is when you have incorrect usage. While the correct
> path is all nice and simple, the incorrect is tricky to solve.
>
> Consider the f
On Wed, Oct 31, 2012 at 1:37 AM, Patryk Kaczmarek wrote:
> I had find strange behaviour in two functions, ecore_thread_check and
> ecore_thread_cancel, while argument is NULL both returns TRUE.
> That is correct or something should be fixed?
Well, not really defined (as it doesn't really make se
in
On Tue, Oct 30, 2012 at 8:30 AM, rustyBSD wrote:
> Le 15/10/2012 18:57, rustyBSD a écrit :
> > Le 15/10/2012 10:03, Vincent Torri a écrit :
> >> > Maxime: you can separate code with the _WIN32 macro. Can you update
> >> > ecore and write a patch that use lstat on non win32 ?
> > Ok.
> So, wh
Le 15/10/2012 18:57, rustyBSD a écrit :
> Le 15/10/2012 10:03, Vincent Torri a écrit :
>> > Maxime: you can separate code with the _WIN32 macro. Can you update
>> > ecore and write a patch that use lstat on non win32 ?
> Ok.
So, what's new ??
---
Le 15/10/2012 10:03, Vincent Torri a écrit :
> Maxime: you can separate code with the _WIN32 macro. Can you update
> ecore and write a patch that use lstat on non win32 ?
Ok.
--- ecore_file.c 2012-10-15 18:53:22.594116119 +0200
+++ ecore_file.c 2012-10-15 18:52:46.668671104 +0200
@@ -399,22 +399,2
On Sat, 06 Oct 2012 13:21:27 +0200 rustyBSD said:
> Hi,
> I looked at the ecore_file_recursive_rm() function
> (in ecore/src/lib/ecore_file/), and I wonder why this
> is so ugly/complicated.
>
> We are doing a readlink() and two stat(). Why not simply
> do a lstat() ?
>
> It takes less memory a
On Sat, Oct 6, 2012 at 2:11 PM, rustyBSD wrote:
> Le 06/10/2012 14:03, Vincent Torri a écrit :
>>> Hi,
>>> > I looked at the ecore_file_recursive_rm() function
>>> > (in ecore/src/lib/ecore_file/), and I wonder why this
>>> > is so ugly/complicated.
>>> >
>>> > We are doing a readlink() and two st
1 - 100 of 466 matches
Mail list logo
