Re: [E-devel] promises...

[The Rasterman]

On Wed, 20 Jul 2016 14:47:19 +0100 Tom Hacohen  said:

> On 20/07/16 14:41, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 20 Jul 2016 10:44:09 +0100 Tom Hacohen  said:
> >
> >> On 20/07/16 00:50, Carsten Haitzler (The Rasterman) wrote:
> >>> On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen  
> >>> said:
> >>>
>  On 27/06/16 17:56, Cedric BAIL wrote:
> > On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen 
> > wrote:
> >> On 19/06/16 02:52, Carsten Haitzler wrote:
> >>> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen 
> >>> said:
>  On 17/06/16 03:53, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen 
> > 
> > said:
> >
> > 
> >
> > as i said... i don't think we need a promise on these objects. we
> > already have an object to store the value/state of the load. it can
> > already call event cb's when these actions succeed or fail. we have
> > done this with preload for years already. if you do another file_set
> > it does cancel the previous one by definition (the only q is if that
> > means you have to call a load fail callback of some sort).
> >
> > this is what i mean by "let's not use promises here because at this
> > stage they do not help, just cause more work, complexity etc.".
> 
>  I 100% agree on this, we don't need to use promise for file_set!
>  Using file set was just an example though for the life-cycle issue.
>  The life-cycle is the problem I was addressing here, and I don't
>  think it's solved in any way but my last example.
> >>>
> >>> i dislike making people have to del their promises when they can be
> >>> taken care of by themselves. look at timeouts and jobs. they are
> >>> promises now and if you have to create a job that returns a promise...
> >>> then have to del it but it will later be called... that just looks
> >>> WRONG. reading such code makes it look broken. it'll be confusing to
> >>> people to no end. having a single ref and that ref is unreffed after
> >>> then/else is called will be just fine. only allow a single then and/or
> >>> else cb to be set up. :)
> >>
> >> I suggested we do the same we do for proxies.
> >> p = file_set()
> >> p.then() // unrefs p
> >>
> >> While:
> >> p = eo_ref(file_set())
> >> p.then()
> >> p.then()
> >> p.then()
> >> eo_unref(p) is allowed and encouraged.
> >
> > Which is basically my proposition added the promise_use for when you
> > want to be able to call cancel on it and enable also the possibility
> > to actually make promise optional. Also this way we can merge sync (In
> > the sense that any further request on the same object that require the
> > result of that said promise) and async API instead of doubling our
> > number of symbol as you did suggest in a previous post. Should I count
> > that as me agreeing on Tom proposal ? Sounds weird !
> >
> 
>  We are on a streak, we also agreed on something else the other day.
> 
>  I flagged this to follow it up, but unfortunately this got no other
>  replies. What's the status? Is this going forward? Do people like it?
> 
>  I went through the rest of the thread, there was nothing there that
>  seemed to negate this, or a better alternative. What's the status of
>  promises following this thread?
> >>>
> >>> i'm mostly fine with it except promise_use - i don't see why really. the
> >>> then/else cb should handle clearing your stored promise handle. you can
> >>> use a weak ref if needed too there.
> >>>
> >>>
> >>
> >> My whole proposal is based on the lifecycle solution, so if you are
> >> saying weakref, it seems like you are against it. A weak ref can't work
> >> anyway, because that means people won't be able to copy the variable
> >> (which users may) because then the weak ref won't work...
> >
> > ummm.. they can copy/get the variable in the then/else cb's. after - no.
> > because if you use a weak ref the ref now should be NULL (unless you add an
> > extra eo_ref  on the promise before setting then/else).
> >
> 
> You misunderstood me and maybe I misunderstood what you meant before.
> 
> I believe what you wanted is:
> 
> efl_file_set(..., )
> // p is now a weak ref
> ...
> // p is now automatically null because the object has been deleted.
> 
> If this is indeed what you meant, then I was right, and it'll lead to 
> broken evilness.

no. i actually mean eo_weak_ref()/eo_wref_*(). using that.

mydata->p = whatever_async_do(); // returns a promise
eo_weak_ref(&(mydata->p));
eo_promise_then(mydata->p, then_cb, else_cb); // here on then/else may becalled
// here promise could be invalid BUT the wo weak ref will 

Re: [E-devel] promises...

[Tom Hacohen]

On 20/07/16 14:41, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 20 Jul 2016 10:44:09 +0100 Tom Hacohen  said:
>
>> On 20/07/16 00:50, Carsten Haitzler (The Rasterman) wrote:
>>> On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen  said:
>>>
 On 27/06/16 17:56, Cedric BAIL wrote:
> On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
>> On 19/06/16 02:52, Carsten Haitzler wrote:
>>> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen 
>>> said:
 On 17/06/16 03:53, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen 
> said:
>
> 
>
> as i said... i don't think we need a promise on these objects. we
> already have an object to store the value/state of the load. it can
> already call event cb's when these actions succeed or fail. we have
> done this with preload for years already. if you do another file_set
> it does cancel the previous one by definition (the only q is if that
> means you have to call a load fail callback of some sort).
>
> this is what i mean by "let's not use promises here because at this
> stage they do not help, just cause more work, complexity etc.".

 I 100% agree on this, we don't need to use promise for file_set! Using
 file set was just an example though for the life-cycle issue. The
 life-cycle is the problem I was addressing here, and I don't think it's
 solved in any way but my last example.
>>>
>>> i dislike making people have to del their promises when they can be
>>> taken care of by themselves. look at timeouts and jobs. they are
>>> promises now and if you have to create a job that returns a promise...
>>> then have to del it but it will later be called... that just looks
>>> WRONG. reading such code makes it look broken. it'll be confusing to
>>> people to no end. having a single ref and that ref is unreffed after
>>> then/else is called will be just fine. only allow a single then and/or
>>> else cb to be set up. :)
>>
>> I suggested we do the same we do for proxies.
>> p = file_set()
>> p.then() // unrefs p
>>
>> While:
>> p = eo_ref(file_set())
>> p.then()
>> p.then()
>> p.then()
>> eo_unref(p) is allowed and encouraged.
>
> Which is basically my proposition added the promise_use for when you
> want to be able to call cancel on it and enable also the possibility
> to actually make promise optional. Also this way we can merge sync (In
> the sense that any further request on the same object that require the
> result of that said promise) and async API instead of doubling our
> number of symbol as you did suggest in a previous post. Should I count
> that as me agreeing on Tom proposal ? Sounds weird !
>

 We are on a streak, we also agreed on something else the other day.

 I flagged this to follow it up, but unfortunately this got no other
 replies. What's the status? Is this going forward? Do people like it?

 I went through the rest of the thread, there was nothing there that
 seemed to negate this, or a better alternative. What's the status of
 promises following this thread?
>>>
>>> i'm mostly fine with it except promise_use - i don't see why really. the
>>> then/else cb should handle clearing your stored promise handle. you can use
>>> a weak ref if needed too there.
>>>
>>>
>>
>> My whole proposal is based on the lifecycle solution, so if you are
>> saying weakref, it seems like you are against it. A weak ref can't work
>> anyway, because that means people won't be able to copy the variable
>> (which users may) because then the weak ref won't work...
>
> ummm.. they can copy/get the variable in the then/else cb's. after - no.
> because if you use a weak ref the ref now should be NULL (unless you add an
> extra eo_ref  on the promise before setting then/else).
>

You misunderstood me and maybe I misunderstood what you meant before.

I believe what you wanted is:

efl_file_set(..., )
// p is now a weak ref
...
// p is now automatically null because the object has been deleted.

If this is indeed what you meant, then I was right, and it'll lead to 
broken evilness.

For example:

efl_file_set(..., )
pd->file_set = p;
...
// p is now automatically null *BUT* pd->file_set is pointing to a 
deleted object. BAD!!!


However, the behaviour you want to achieve is easy to do to an extent, 
you can just defer the unref to an ecore job/idler. This means that the 
promise will unref itself after the user has finished using it, and they 
will be allowed to ref if they so wish. This is essentially the hacky 
version of what I suggested before, and I wouldn't recommend it. I'd 
prefer doing what I suggested.

Hope things are more clear.


>> Just 

Re: [E-devel] promises...

[The Rasterman]

On Wed, 20 Jul 2016 10:44:09 +0100 Tom Hacohen  said:

> On 20/07/16 00:50, Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen  said:
> >
> >> On 27/06/16 17:56, Cedric BAIL wrote:
> >>> On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
>  On 19/06/16 02:52, Carsten Haitzler wrote:
> > On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen 
> > said:
> >> On 17/06/16 03:53, Carsten Haitzler wrote:
> >>> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen 
> >>> said:
> >>>
> >>> 
> >>>
> >>> as i said... i don't think we need a promise on these objects. we
> >>> already have an object to store the value/state of the load. it can
> >>> already call event cb's when these actions succeed or fail. we have
> >>> done this with preload for years already. if you do another file_set
> >>> it does cancel the previous one by definition (the only q is if that
> >>> means you have to call a load fail callback of some sort).
> >>>
> >>> this is what i mean by "let's not use promises here because at this
> >>> stage they do not help, just cause more work, complexity etc.".
> >>
> >> I 100% agree on this, we don't need to use promise for file_set! Using
> >> file set was just an example though for the life-cycle issue. The
> >> life-cycle is the problem I was addressing here, and I don't think it's
> >> solved in any way but my last example.
> >
> > i dislike making people have to del their promises when they can be
> > taken care of by themselves. look at timeouts and jobs. they are
> > promises now and if you have to create a job that returns a promise...
> > then have to del it but it will later be called... that just looks
> > WRONG. reading such code makes it look broken. it'll be confusing to
> > people to no end. having a single ref and that ref is unreffed after
> > then/else is called will be just fine. only allow a single then and/or
> > else cb to be set up. :)
> 
>  I suggested we do the same we do for proxies.
>  p = file_set()
>  p.then() // unrefs p
> 
>  While:
>  p = eo_ref(file_set())
>  p.then()
>  p.then()
>  p.then()
>  eo_unref(p) is allowed and encouraged.
> >>>
> >>> Which is basically my proposition added the promise_use for when you
> >>> want to be able to call cancel on it and enable also the possibility
> >>> to actually make promise optional. Also this way we can merge sync (In
> >>> the sense that any further request on the same object that require the
> >>> result of that said promise) and async API instead of doubling our
> >>> number of symbol as you did suggest in a previous post. Should I count
> >>> that as me agreeing on Tom proposal ? Sounds weird !
> >>>
> >>
> >> We are on a streak, we also agreed on something else the other day.
> >>
> >> I flagged this to follow it up, but unfortunately this got no other
> >> replies. What's the status? Is this going forward? Do people like it?
> >>
> >> I went through the rest of the thread, there was nothing there that
> >> seemed to negate this, or a better alternative. What's the status of
> >> promises following this thread?
> >
> > i'm mostly fine with it except promise_use - i don't see why really. the
> > then/else cb should handle clearing your stored promise handle. you can use
> > a weak ref if needed too there.
> >
> >
> 
> My whole proposal is based on the lifecycle solution, so if you are 
> saying weakref, it seems like you are against it. A weak ref can't work 
> anyway, because that means people won't be able to copy the variable 
> (which users may) because then the weak ref won't work...

ummm.. they can copy/get the variable in the then/else cb's. after - no.
because if you use a weak ref the ref now should be NULL (unless you add an
extra eo_ref  on the promise before setting then/else).

> Just to reiterate, the suggested API:
> 
> p = file_set()
> p.then() //unrefs p
> 
> and
> 
> p = eo_ref(file_set())
> p.then()
> p.then()
> p.then()
> eo_unref(p) // unrefs p
> 
> Will be the ways to use it.
> 
> 
> Just as a side comment: I still don't like the use of promises in the 
> efl. :)
> 
> --
> Tom.
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list

Re: [E-devel] promises...

[Tom Hacohen]

On 20/07/16 00:50, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen  said:
>
>> On 27/06/16 17:56, Cedric BAIL wrote:
>>> On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
 On 19/06/16 02:52, Carsten Haitzler wrote:
> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  
> said:
>> On 17/06/16 03:53, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen 
>>> said:
>>>
>>> 
>>>
>>> as i said... i don't think we need a promise on these objects. we
>>> already have an object to store the value/state of the load. it can
>>> already call event cb's when these actions succeed or fail. we have
>>> done this with preload for years already. if you do another file_set it
>>> does cancel the previous one by definition (the only q is if that means
>>> you have to call a load fail callback of some sort).
>>>
>>> this is what i mean by "let's not use promises here because at this
>>> stage they do not help, just cause more work, complexity etc.".
>>
>> I 100% agree on this, we don't need to use promise for file_set! Using
>> file set was just an example though for the life-cycle issue. The
>> life-cycle is the problem I was addressing here, and I don't think it's
>> solved in any way but my last example.
>
> i dislike making people have to del their promises when they can be taken
> care of by themselves. look at timeouts and jobs. they are promises now
> and if you have to create a job that returns a promise... then have to
> del it but it will later be called... that just looks WRONG. reading such
> code makes it look broken. it'll be confusing to people to no end. having
> a single ref and that ref is unreffed after then/else is called will be
> just fine. only allow a single then and/or else cb to be set up. :)

 I suggested we do the same we do for proxies.
 p = file_set()
 p.then() // unrefs p

 While:
 p = eo_ref(file_set())
 p.then()
 p.then()
 p.then()
 eo_unref(p) is allowed and encouraged.
>>>
>>> Which is basically my proposition added the promise_use for when you
>>> want to be able to call cancel on it and enable also the possibility
>>> to actually make promise optional. Also this way we can merge sync (In
>>> the sense that any further request on the same object that require the
>>> result of that said promise) and async API instead of doubling our
>>> number of symbol as you did suggest in a previous post. Should I count
>>> that as me agreeing on Tom proposal ? Sounds weird !
>>>
>>
>> We are on a streak, we also agreed on something else the other day.
>>
>> I flagged this to follow it up, but unfortunately this got no other
>> replies. What's the status? Is this going forward? Do people like it?
>>
>> I went through the rest of the thread, there was nothing there that
>> seemed to negate this, or a better alternative. What's the status of
>> promises following this thread?
>
> i'm mostly fine with it except promise_use - i don't see why really. the
> then/else cb should handle clearing your stored promise handle. you can use a
> weak ref if needed too there.
>
>

My whole proposal is based on the lifecycle solution, so if you are 
saying weakref, it seems like you are against it. A weak ref can't work 
anyway, because that means people won't be able to copy the variable 
(which users may) because then the weak ref won't work...

Just to reiterate, the suggested API:

p = file_set()
p.then() //unrefs p

and

p = eo_ref(file_set())
p.then()
p.then()
p.then()
eo_unref(p) // unrefs p

Will be the ways to use it.


Just as a side comment: I still don't like the use of promises in the 
efl. :)

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen  said:

> On 27/06/16 17:56, Cedric BAIL wrote:
> > On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
> >> On 19/06/16 02:52, Carsten Haitzler wrote:
> >>> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  
> >>> said:
>  On 17/06/16 03:53, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen 
> > said:
> >
> > 
> >
> > as i said... i don't think we need a promise on these objects. we
> > already have an object to store the value/state of the load. it can
> > already call event cb's when these actions succeed or fail. we have
> > done this with preload for years already. if you do another file_set it
> > does cancel the previous one by definition (the only q is if that means
> > you have to call a load fail callback of some sort).
> >
> > this is what i mean by "let's not use promises here because at this
> > stage they do not help, just cause more work, complexity etc.".
> 
>  I 100% agree on this, we don't need to use promise for file_set! Using
>  file set was just an example though for the life-cycle issue. The
>  life-cycle is the problem I was addressing here, and I don't think it's
>  solved in any way but my last example.
> >>>
> >>> i dislike making people have to del their promises when they can be taken
> >>> care of by themselves. look at timeouts and jobs. they are promises now
> >>> and if you have to create a job that returns a promise... then have to
> >>> del it but it will later be called... that just looks WRONG. reading such
> >>> code makes it look broken. it'll be confusing to people to no end. having
> >>> a single ref and that ref is unreffed after then/else is called will be
> >>> just fine. only allow a single then and/or else cb to be set up. :)
> >>
> >> I suggested we do the same we do for proxies.
> >> p = file_set()
> >> p.then() // unrefs p
> >>
> >> While:
> >> p = eo_ref(file_set())
> >> p.then()
> >> p.then()
> >> p.then()
> >> eo_unref(p) is allowed and encouraged.
> >
> > Which is basically my proposition added the promise_use for when you
> > want to be able to call cancel on it and enable also the possibility
> > to actually make promise optional. Also this way we can merge sync (In
> > the sense that any further request on the same object that require the
> > result of that said promise) and async API instead of doubling our
> > number of symbol as you did suggest in a previous post. Should I count
> > that as me agreeing on Tom proposal ? Sounds weird !
> >
> 
> We are on a streak, we also agreed on something else the other day.
> 
> I flagged this to follow it up, but unfortunately this got no other 
> replies. What's the status? Is this going forward? Do people like it?
> 
> I went through the rest of the thread, there was nothing there that 
> seemed to negate this, or a better alternative. What's the status of 
> promises following this thread?

i'm mostly fine with it except promise_use - i don't see why really. the
then/else cb should handle clearing your stored promise handle. you can use a
weak ref if needed too there.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 27/06/16 17:56, Cedric BAIL wrote:
> On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
>> On 19/06/16 02:52, Carsten Haitzler wrote:
>>> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  said:
 On 17/06/16 03:53, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  
> said:
>
> 
>
> as i said... i don't think we need a promise on these objects. we already
> have an object to store the value/state of the load. it can already call
> event cb's when these actions succeed or fail. we have done this with
> preload for years already. if you do another file_set it does cancel the
> previous one by definition (the only q is if that means you have to call a
> load fail callback of some sort).
>
> this is what i mean by "let's not use promises here because at this stage
> they do not help, just cause more work, complexity etc.".

 I 100% agree on this, we don't need to use promise for file_set! Using
 file set was just an example though for the life-cycle issue. The
 life-cycle is the problem I was addressing here, and I don't think it's
 solved in any way but my last example.
>>>
>>> i dislike making people have to del their promises when they can be taken 
>>> care
>>> of by themselves. look at timeouts and jobs. they are promises now and if 
>>> you
>>> have to create a job that returns a promise... then have to del it
>>> but it will later be called... that just looks WRONG. reading such code 
>>> makes
>>> it look broken. it'll be confusing to people to no end. having a single ref 
>>> and
>>> that ref is unreffed after then/else is called will be just fine. only 
>>> allow a
>>> single then and/or else cb to be set up. :)
>>
>> I suggested we do the same we do for proxies.
>> p = file_set()
>> p.then() // unrefs p
>>
>> While:
>> p = eo_ref(file_set())
>> p.then()
>> p.then()
>> p.then()
>> eo_unref(p) is allowed and encouraged.
>
> Which is basically my proposition added the promise_use for when you
> want to be able to call cancel on it and enable also the possibility
> to actually make promise optional. Also this way we can merge sync (In
> the sense that any further request on the same object that require the
> result of that said promise) and async API instead of doubling our
> number of symbol as you did suggest in a previous post. Should I count
> that as me agreeing on Tom proposal ? Sounds weird !
>

We are on a streak, we also agreed on something else the other day.

I flagged this to follow it up, but unfortunately this got no other 
replies. What's the status? Is this going forward? Do people like it?

I went through the rest of the thread, there was nothing there that 
seemed to negate this, or a better alternative. What's the status of 
promises following this thread?

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Mon, 27 Jun 2016 15:55:02 -0700 Cedric BAIL  said:

> On Sat, Jun 25, 2016 at 7:12 AM, Carsten Haitzler 
> wrote:
> > On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
> >  said:
> > i think a big difference is our view of promises. to me a promise is an
> > OBJECT that REPRESENTS the async action (and then is responsible for
> > calling the correct callbacks and for storing the value until all such
> > callbacks are called etc. etc.). you (and cedric) keep referring to
> > promises as async values. at least in every language binding they are
> > OBJECTS. they have methods on them (p.then(), and to cancel p.cancel() for
> > starters).
> 
> This pretty much explain all disagreement and missunderstanding here.
> I haven't realized until you said so that you expected to use
> "promise" in that way. This match closely what you have done with
> "vpath" in fact and not at all what is understood to be a promise
> (a.k.a. a container for a future value) in most language. I am not a
> fan at all of inventing our own concept that doesn't match the rest of
> the world, but my strongest reserve is that I think this lead to more
> problem than it solves.

ummm errr at least eina_promise was exactly that - an object you can set up
then's, progress cb's, store a value AND call a cancel method on. that's
precisely the implementation and it looks like an object to me. the moment you
are doing things like

p.then(x)
p.else(x)
p.cancel()

etc. - that's an object, not a value. a promise represents an async action, NOT
a value, because it has cancel(). you CANNOT cancel a value. you CAN cancel an
ACTION. and i'll repeat using promises to replace job and timer objects... is
making a promise be an object. you have to be able to cancel jobs and timeouts
and so... it's an object. in js and c++ promises (futures) are OBJECTS with
methods you call on them. our promises already don't match - we have cancel.
the others do not. we have to accept the fact our promises wont totally match.
otherwise make them match to the lowest common denominator in all languages.
cancelling is not possible in c++ or in js (es 6). but if you want to make
our promises match every language then promises are useless for efl. without
being able to cancel then then i say dump them.

> First the problem that this does solve. As there is no owner of the
> write side of the promise, only internal use, you do not have this
> lifecycle problem at all and as you also advocate for only one
> listener, it means you also avoid the problem of having to keep the n
> user of it happy. This solve the lifecycle issue I have been
> discribing since the start with using eo for this purpose.

even if you have multiple then's - the promise stays alive until all then's are
executed. it's an extension of the same principle. still no lifecycle issue
UNLESS you insist on the promise being around after all then's (or else's)
then... ref it one more time and presto. :) it stays around. that's why i don't
see a lifecycle issue. it's  simple. 99% of uses will be a single then or else
callm and even if it's multiple it's still simple.

now the WRITE side does need to track lifetime of the promise. because the code
being given the promise (or future) can cancel it or delete it (deletion should
cancel anyway), then writer HAS to track this to know when to stop doing their
work.

this is where splitting into promise writer and promise (it's better to ca them
writer than owner). if the promise obj is deleted it can let the writer know
and whoever is doing the async promise work can poll for this every "step" and
stop doing work if the promise is gone. throw away existing work and abort.

> The most important problem I see. If the operation is to be done from
> the inside of the promise, using it in object like efl.canvas.image,
> means that either you get efl.canvas.image to have a priviledge access
> to the internal of the promise, so that you can force its resolve on
> demand, or you need to implement a wait on most promise with the risk
> of ending in deadlock. That and the fact it doesn't match what other
> language are providing, are in my opinion the biggest problem I see
> with this idea.

well c++ expects a wait... :) it doesn't think of a mainloop. it seemingly
thinks that "conceptually" there is some thread or child process doing the work
and you can sit on a blocking "read" for the result. that this is an expected
design pattern when using promises/futures.

> Also in most case where we use promise at the moment they are
> literrally under the control of another object as they are just
> delivering a result for an existing object. The only case where we

but this pattern is killed with jobs and timeouts.

> could use this behavior at some advantage is for Eio promise, but even
> then I am not to sure of the outcome. We could in that case extend
> signals for filtering and sorting on the 

Re: [E-devel] promises...

[Cedric BAIL]

On Sat, Jun 25, 2016 at 7:12 AM, Carsten Haitzler  wrote:
> On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
>  said:
> i think a big difference is our view of promises. to me a promise is an OBJECT
> that REPRESENTS the async action (and then is responsible for calling the
> correct callbacks and for storing the value until all such callbacks are 
> called
> etc. etc.). you (and cedric) keep referring to promises as async values. at
> least in every language binding they are OBJECTS. they have methods on them
> (p.then(), and to cancel p.cancel() for starters).

This pretty much explain all disagreement and missunderstanding here.
I haven't realized until you said so that you expected to use
"promise" in that way. This match closely what you have done with
"vpath" in fact and not at all what is understood to be a promise
(a.k.a. a container for a future value) in most language. I am not a
fan at all of inventing our own concept that doesn't match the rest of
the world, but my strongest reserve is that I think this lead to more
problem than it solves.

First the problem that this does solve. As there is no owner of the
write side of the promise, only internal use, you do not have this
lifecycle problem at all and as you also advocate for only one
listener, it means you also avoid the problem of having to keep the n
user of it happy. This solve the lifecycle issue I have been
discribing since the start with using eo for this purpose.

The most important problem I see. If the operation is to be done from
the inside of the promise, using it in object like efl.canvas.image,
means that either you get efl.canvas.image to have a priviledge access
to the internal of the promise, so that you can force its resolve on
demand, or you need to implement a wait on most promise with the risk
of ending in deadlock. That and the fact it doesn't match what other
language are providing, are in my opinion the biggest problem I see
with this idea.

Also in most case where we use promise at the moment they are
literrally under the control of another object as they are just
delivering a result for an existing object. The only case where we
could use this behavior at some advantage is for Eio promise, but even
then I am not to sure of the outcome. We could in that case extend
signals for filtering and sorting on the promise (progress should be
part of the default property of a promise as this follow ES6), but
this become something bindings have to care about. This is going to be
tricky when we are chaining promise. What happen to this events once
put into an all/race/chain promise ? Whatever extention we use on a
promise, it will be tricky to have them available outside of C.

On the other hand sticking with a more classic promise/future
container concept, we can avoid the problematic exposition of wait and
the risk of a deadlock as any object that would require to resolve a
promise could force it internally. It also means that instead of
having a one promise that does everything like vpath, you go by
chaining them. A first one that resolve an uri to an Eina.File and in
the then of that promise you set the file on the destination object.
This means that the destination object doesn't need to resolve a file
download before it is done and you have no dead lock.

Now I can see that extending the promise/write side could be useful in
some case and not risky as it is hidden from bindings completely as
they only needs to actually expose a future. So when you actually
extend a promise/write side it stay actually hidden from the binding
and doesn't create any trouble there. Thinking more about it the main
issue we were facing with using Eo and its lifecycle is that we wanted
to save on performance by merging the promise and future together.
This lead to having an ownership problem, with parenting and reference
counting issue. If everytime you call future_get you get a new Eo
object connected to the promise, but not the actual promise itself,
this solve all problem too. This solve the refcounting and parenting
issue as the one who get the future is actually the one who own the
future. This will increase the pressure on eo_add, but whatever.

The promise/writer side will be an eolian object and can be inherited
from. The future/reader side is I think to tricky and risky at this
stage to allow it to be inherited from. As we clearly split both side,
I think the future/reader side should be an Eo object only. In the
future, if we are confident enough and find use case for exposing it
as an eolian object and make it inheritable, we will still be able to
do it, but for the time being, it is much more safe to not provide
that feature.
-- 
Cedric BAIL

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their 

Re: [E-devel] promises...

[Cedric BAIL]

On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen  wrote:
> On 19/06/16 02:52, Carsten Haitzler wrote:
>> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  said:
>>> On 17/06/16 03:53, Carsten Haitzler wrote:
 On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  said:



 as i said... i don't think we need a promise on these objects. we already
 have an object to store the value/state of the load. it can already call
 event cb's when these actions succeed or fail. we have done this with
 preload for years already. if you do another file_set it does cancel the
 previous one by definition (the only q is if that means you have to call a
 load fail callback of some sort).

 this is what i mean by "let's not use promises here because at this stage
 they do not help, just cause more work, complexity etc.".
>>>
>>> I 100% agree on this, we don't need to use promise for file_set! Using
>>> file set was just an example though for the life-cycle issue. The
>>> life-cycle is the problem I was addressing here, and I don't think it's
>>> solved in any way but my last example.
>>
>> i dislike making people have to del their promises when they can be taken 
>> care
>> of by themselves. look at timeouts and jobs. they are promises now and if you
>> have to create a job that returns a promise... then have to del it
>> but it will later be called... that just looks WRONG. reading such code makes
>> it look broken. it'll be confusing to people to no end. having a single ref 
>> and
>> that ref is unreffed after then/else is called will be just fine. only allow 
>> a
>> single then and/or else cb to be set up. :)
>
> I suggested we do the same we do for proxies.
> p = file_set()
> p.then() // unrefs p
>
> While:
> p = eo_ref(file_set())
> p.then()
> p.then()
> p.then()
> eo_unref(p) is allowed and encouraged.

Which is basically my proposition added the promise_use for when you
want to be able to call cancel on it and enable also the possibility
to actually make promise optional. Also this way we can merge sync (In
the sense that any further request on the same object that require the
result of that said promise) and async API instead of doubling our
number of symbol as you did suggest in a previous post. Should I count
that as me agreeing on Tom proposal ? Sounds weird !
-- 
Cedric BAIL

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 22/06/16 06:34, Carsten Haitzler wrote:
> On Mon, 20 Jun 2016 18:07:46 +0100 Tom Hacohen  said:
>
>> On 19/06/16 02:27, Carsten Haitzler wrote:
>>> On Fri, 17 Jun 2016 09:41:39 +0100 Tom Hacohen  said:
>>>
 On 17/06/16 03:28, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen  
> said:
>
>> On 03/06/16 20:17, Cedric BAIL wrote:
>> 
> also promises should become eo objects with event cb's
> so they work just like everything else. i can ref, unref, delete and
> whatever them like everything else.
>>>
>>> As said above, this does work. Example with event :
>>> eo_promise = efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>>>
>>> In this 3 lines, there is already 2 case in which that fail. First if,
>>> the object is done before the callback is set, data are lost and there
>>> is no way to get any event. Ofcourse, we can override the behavior of
>>> events on this eo_promise completely. Now let's imagine, that we
>>> actually do always store the events, so that everytime someone
>>> register a callback we can send the event. Still you can't auto del
>>> the object at any point in time, you have to force the user to
>>> implement the eo_del and to always provide both a then and cancel
>>> callback.
>>>
>>> Other possibility, it is an event on the object itself.
>>> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
>>> efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>>>
>>> Same again, this can not work. The first group of event handler,
>>> promise_callbacks1(), may actually be triggered by a previously
>>> running promise on the object, so you have to first forcefully stop
>>> the previous operation. This would add complexity. And still the
>>> second callback has the same issue as the previous case, if it is a
>>> normal eo event, it could have been triggered before any callback get
>>> registered and the event be lost... Same story short, doesn't work.
>>>
>>
>> I'm currently reading through the thread, and I didn't see anything
>> mentioned about this other than a casual remark you made, so just wanted
>> to make it crystal clear regarding implementing it as an Eo object.
>> The whole point/magic of inheritance is that you can and are supposed to
>> override functions if needed. Overriding callback add to call the
>> callback immediately upon addition (if already done) is how I would
>> implement promise callbacks. It's clean, easy and as intended. This is
>> definitely not a problem.
>
> just for convenience i think having a special eo_promise_then(obj, cb1,
> cb2, data); may be best as its the simplest and is not pretending to ADD
> a cb in the name. it sets it explicitly. this needs special treatment
> like the eo event callbacks of course.
>
> but using an eo event is possible by override indeed, but here is the
> issue. you have to wait until either "then" or "else" or both are set.
> since you set one then set another... you will have to always add one of
> them as a NULL or dummy cb just to do this. having a single method/func
> set both makes more sense. in fact this likely needs manual
> binding/.handling per language anyway. i'm really only thinking of eo
> events for EXTRA features like progress events on a promise that happen
> before the success/fail cb's above.
>
>

 This is explained better in my reply to the initial post of this thread,
 but essentially you don't. What you are missing, and why life-cycle can
 be pretty broken, and why this doesn't matter is that you can register a
 few "then" and a few "cancel" in promises. That is actually the power of
 promises, that you can chain them and use them for a few things. This is
 dealt with nicely. See the post I mentioned.
>>>
>>> register a few then/else cb's on the same promise? at least that should not
>>> be possible (it should not work). on;y one else/then cb (zero or one of
>>> each).
>>>
>>>
>>
>> Why not? Anyhow, as I said, that is very common in js land and how race
>> and all are probably implemented.
>
> eh? well eina_promise allowed only a single then... which i think is the 
> sanest
> way here. limit it to one. the reason is that otherwise you never know when 
> the
> promise is finished its setup. you need a special done() call on the promise
> then to tell it you're done attaching callbacks. e.g. for the case it's an
> async load but the load finds the target in an in-memory cache already and
> wants to immediately call the then func - when does 

Re: [E-devel] promises...

[Tom Hacohen]

On 19/06/16 02:52, Carsten Haitzler wrote:
> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  said:
>
>> On 17/06/16 03:53, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  said:
>>>
 Lets start with life-cycle: Eo is great, and I think using Eo is the
 right way to go, but unfortunately that doesn't solve our life-cycle
 issue. When do promises die?

 p = efl_file_set()...
 // Delete here if file has been set?
 promise_then_add(p, cb)
 // Delete here if file has been set?
 promise_then_add(p, cb2);
 // Delete here if file has been set?
 ... // a million years into the future
 // Delete here if file has been set?
>>>
>>> the way i see it is you need to set both then and else at the same time so
>>>
>>>   p = efl_file_set()
>>>   eo_promise_then(p, sucess_cb, fail_cb, NULL);
>>>   // p may be deleted at this point since on success or failure it is
>>> deleted // do not depend on p after you have set then/else cb's. ensure if
>>> you need to // access the cb that you add a DEL event cb to the promise to
>>> track it OR if // you HAVE to have it then add an eo_ref(p) before
>>> eo_promise_then()
>>
>> Unfortunately, I don't think that works well in real life. It'll be a
>> source of many bugs. The problem is that:
>> p = ...
>> eo_promise_then(...)
>> eo_promise_then(...)
>
> we have eoid to help here... but who would ad 2 then's. we should have the 
> 2n'd
> then be an error so it'll ERR() saying then is set twice. then the programmer
> gets that message every time their code runs and they know to not do it and
> sometimes if the promise is deleted eoid will ten barf on the id, but you'll
> keep working.
>
> make the then only be ae to set cb's once at all. problem solved.

We talked about it on IRC, there are cases. In JS in particularly it's 
very common to do:
p.then().then().then()
I don't remember exact uses for that, but a more obvious usage is:
download1.then(tick_a_v)
download2.then(tick_a_v)
all(download1, download2, tick_the_main_v)
race(download1, timeout, timeout_err)
race(download1, timout, timeout_err)

It's very cheap to deal with if they are eo events.

>
>> Will work in many case, until it doesn't sometime when we change
>> something internally, or when the stars align just right and the promise
>> evaluates immediately. This is very dangerous. This is more common than
>> you think, and will become even more common. In JS, the usage often
>> looks like:
>> p.then(...).then(efl_provided_helper_cb).then(other_efl_cb).
>>
>>>
 There is just no sensible way to do it automatically. You will *always*
 have to unref, so following the above example:

 p = efl_file_set()
 ... // All of the code before
 eo_del(p); // It'll only die here

 Which won't work because then ignoring efl_file_set's output won't be
 allowed.
>>>
>>> well that's kind of the problem. with no then/else the promise has to stay
>>> around forever holding the return value. you can't ignore it if its a
>>> return. if it's
>>>
>>>   p = eo_add(NULL, PROMISE);
>>>   // do aother promise setup here like
>>>   eo_promise_then(p, done_cb, NULL, NULL);
>>>   elf_file_set(obj, file, key, );
>>>
>>> then it can set up the promise in efl_file_set. if you do
>>>
>>>   efl_file_set(obj, file, key, NULL);
>>>
>>> then we say "we don't care about the async result". perhaps it can now be
>>> sync by default if you do this?
>>
>> Look at my suggestion below, I already solved this problem.
>>
>>>
 The only sensible way of doing it, I guess, is to force a wrapper of
 some sort, so the code above becomes:
 p = eo_ref(efl_file_set());
 ... // Code from before
 eo_del(p);

 Or probably for extra safety (like marking the promise was actually
 used, and not just implicitly with a ref, this will allow us to block
 then/cancel registration and be more safe).

 p = efl_promise_use(efl_file_set());
 ... // Code from before
 eo_del(p);

 efl_promise_use will set a flag in the promise so that
 p = efl_file_set();
 promise_then_add(p); // This will fail because the flag wasn't set.

 So that's safe and probably the way to go. This will let us manage
 life-cycle correctly.
>>>
>>> i think that's more complex than the above i suggest. the problem is if you
>>> pass in a promise... this now affects all of our file_set or any api that
>>> can or should be async.
>>>
>>> as i said... i don't think we need a promise on these objects. we already
>>> have an object to store the value/state of the load. it can already call
>>> event cb's when these actions succeed or fail. we have done this with
>>> preload for years already. if you do another file_set it does cancel the
>>> previous one by definition (the only q is if that means you have to call a
>>> load fail callback of some sort).
>>>
>>> this is what i mean by "let's not use promises 

Re: [E-devel] promises...

[The Rasterman]

On Sat, 25 Jun 2016 11:38:46 -0300 Felipe Magno de Almeida
 said:

> On Sat, Jun 25, 2016 at 11:12 AM, Carsten Haitzler 
> wrote:
> > On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
> >  said:
> >
> >> Hello,
> >>
> >> I still don't get it why promises should be an all-or-nothing thing. It
> >> must be usable for all scenarios possible or we should drop it and
> >> live with events which are impossible to translate to the real semantics
> >> of asynchronous operations (I'm calling an asynchronous operation
> >> one that returns a value asynchronously) to bindings that already have
> >> a concept of asynchronous operations.
> >
> > i don't know if anyone said it should be all or nothing. i have said that
> > given the newness and disagreements on promises that we need to use them
> > very carefully and avoid usage "all over the place" for now until we can
> > settle them down. if we were all happy with them and agreed on them then
> > things may be different, but that is not the case.
> >
> > i think a big difference is our view of promises. to me a promise is an
> > OBJECT that REPRESENTS the async action (and then is responsible for
> > calling the correct callbacks and for storing the value until all such
> > callbacks are called etc. etc.). you (and cedric) keep referring to
> > promises as async values. at least in every language binding they are
> > OBJECTS. they have methods on them (p.then(), and to cancel p.cancel() for
> > starters).
> 
> Well, the object nomenclature is a little misleading IMO. For C++ at least
> everything is an object, even ints. So I agree a promise is an object. But
> its sole purpose, IMO, is to hold a value that will be available in the
> future. So both are right. IMO, the only problem with Eolizing Promise is 1.
> paying for things we don't need; 2. The intricacies of other Eolian features,
> such as inheritance for example.

the was we have promises, they go beyond just holding a value for the
future.they hold a series of callbacks to call on success or failure AND they
also hold progress events AND they have cancel methods on them. they can be
reference counted too. to my mind, that makes them pretty much full featured
objects in the efl/c sense. yes in c++ everything is an object. :) but in the c
world wse have a dividing line from objects to data structures and then another
to basic types. basic types (int, double, char, int[], void * etc.) are clearly
defined by the language. data structures are what we define in eina. objects
are everything else above.

at least to me, promises are being used to replace existing objects we have
(timeouts, jobs) and so should be eo objects. :) yes - i know there is a cost.
giving it some thought, that cost is, in the big picture, not that high
(think about how often promises will be created/destroyed and methods called on
them and then figure out the delta between eo and the eina_proimise... and then
consider how often we call other things... and the real work behind it all)

> I'm not completely against it being an Eo object however, though IMO
> it is not a good tradeoff. But I can live with it and would be really happy
> to build the JavaScript binding on top of that if I can deliver the same
> semantics (on steroids) that normal JavaScript promises have.

i definitely think you can do that. i have a different view on the cost, and we
can reduce the cost at least of creation and destruction to something
equivalent to eina_promise

> The intrincacies of Eo properties, however, are not very easy to foresee
> IMO. So, how inheritance should work? This is not a rhetorical question,
> because right now we have a built-in called promise in Eolian
> that says that a promise is being returned, because we don't have
> parameterized classes in Eolian, so how should bindings know that
> a derived class with more events are being used? If we use the
> class name of the subclassed promise then we need new syntax
> to allow parameterizing that in Eolian. Should we?

our promise should be ours imho with whatever extensions (like cancel) that
we have. if we allow inheritance then well.. we need new types like
promise.progress or something. or should we dump progress in the base
promise class?

> >> One example is making promises open to add new events through
> >> inheritance. However, let's say that it is really desirable, so we can
> >> all compromise on a middle term, we need to have a way to support
> >> that in bindings in a way that is natural in the binding languages, and
> >> IMO that is the _most_important_part_ and I have been repeating
> >> myself about this since I introduced the promise idea in january, but
> >> let me repeat again:
> >
> > yes, and since promises are objects in every language and binding we
> > support... this isn't much of an issue. we can extend progress events as eo
> > events since they wont be a minimal base requirement. 

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sun, Jun 26, 2016 at 3:49 PM, Michal Suchanek  wrote:
>

Hello Michal,

> On 25 June 2016 at 16:38, Felipe Magno de Almeida
>  wrote:


>> Well, the object nomenclature is a little misleading IMO. For C++ at least
>> everything is an object, even ints. ...
>
> no, not ints :)

Yes.. It is. Look at the last draft (this is true since C++98, but the
last draft is obviously easier to reference) at 1.8 paragraph 1.

[snip]

>> I actually like the idea of using events for progress, because it is an 
>> event,
>> it has all the properties of events. However, it just has one single problem,
>> which is the race condition of progress being available and when the event
>> is registered. This problem also existed with Eina_Promise however, and
>> we fixed by adding strict_promise concept which would only send progress
>> when a progress callback was registered. This could be case for Eo as well,
>> but we need to be able to differentiate, because a strict_promise can lead
>> to deadlock if the user never registers any progress callback.
>
> What's the strict progress good for?
>
> Just cache one progress event until a progress callback is registered
> or the promise is deleted. If new progress event is sent it is cached
> and the old one deleted. That way when the progress callback is
> registered it has latest progress information.

I have considered that option. However, this creates overhead even
for asynchronous operations which progress is not really that
relevant. And we start requiring a free function for progress data,
etc. The way it is right now, the caller is responsible for freeing
and promises don't have to know how to do that, if we cache,
this no longer is true and we have to deal with moveability,
copyability etc.

> Thanks
>
> Michal

Regards,
-- 
Felipe Magno de Almeida

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Michal Suchanek]

On 25 June 2016 at 16:38, Felipe Magno de Almeida
 wrote:
> On Sat, Jun 25, 2016 at 11:12 AM, Carsten Haitzler  
> wrote:
>> On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
>>  said:
>>
>>> Hello,
>>>
>>> I still don't get it why promises should be an all-or-nothing thing. It must
>>> be usable for all scenarios possible or we should drop it and
>>> live with events which are impossible to translate to the real semantics
>>> of asynchronous operations (I'm calling an asynchronous operation
>>> one that returns a value asynchronously) to bindings that already have
>>> a concept of asynchronous operations.
>>
>> i don't know if anyone said it should be all or nothing. i have said that 
>> given
>> the newness and disagreements on promises that we need to use them very
>> carefully and avoid usage "all over the place" for now until we can settle 
>> them
>> down. if we were all happy with them and agreed on them then things may be
>> different, but that is not the case.
>>
>> i think a big difference is our view of promises. to me a promise is an 
>> OBJECT
>> that REPRESENTS the async action (and then is responsible for calling the
>> correct callbacks and for storing the value until all such callbacks are 
>> called
>> etc. etc.). you (and cedric) keep referring to promises as async values. at
>> least in every language binding they are OBJECTS. they have methods on them
>> (p.then(), and to cancel p.cancel() for starters).
>
> Well, the object nomenclature is a little misleading IMO. For C++ at least
> everything is an object, even ints. ...

no, not ints :)

>>> One example is making promises open to add new events through
>>> inheritance. However, let's say that it is really desirable, so we can
>>> all compromise on a middle term, we need to have a way to support
>>> that in bindings in a way that is natural in the binding languages, and
>>> IMO that is the _most_important_part_ and I have been repeating
>>> myself about this since I introduced the promise idea in january, but
>>> let me repeat again:
>>
>> yes, and since promises are objects in every language and binding we 
>> support...
>> this isn't much of an issue. we can extend progress events as eo events since
>> they wont be a minimal base requirement. will these events be really common?
>
> I actually like the idea of using events for progress, because it is an event,
> it has all the properties of events. However, it just has one single problem,
> which is the race condition of progress being available and when the event
> is registered. This problem also existed with Eina_Promise however, and
> we fixed by adding strict_promise concept which would only send progress
> when a progress callback was registered. This could be case for Eo as well,
> but we need to be able to differentiate, because a strict_promise can lead
> to deadlock if the user never registers any progress callback.

What's the strict progress good for?

Just cache one progress event until a progress callback is registered
or the promise is deleted. If new progress event is sent it is cached
and the old one deleted. That way when the progress callback is
registered it has latest progress information.

Thanks

Michal

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sat, Jun 25, 2016 at 11:12 AM, Carsten Haitzler  wrote:
> On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
>  said:
>
>> Hello,
>>
>> I still don't get it why promises should be an all-or-nothing thing. It must
>> be usable for all scenarios possible or we should drop it and
>> live with events which are impossible to translate to the real semantics
>> of asynchronous operations (I'm calling an asynchronous operation
>> one that returns a value asynchronously) to bindings that already have
>> a concept of asynchronous operations.
>
> i don't know if anyone said it should be all or nothing. i have said that 
> given
> the newness and disagreements on promises that we need to use them very
> carefully and avoid usage "all over the place" for now until we can settle 
> them
> down. if we were all happy with them and agreed on them then things may be
> different, but that is not the case.
>
> i think a big difference is our view of promises. to me a promise is an OBJECT
> that REPRESENTS the async action (and then is responsible for calling the
> correct callbacks and for storing the value until all such callbacks are 
> called
> etc. etc.). you (and cedric) keep referring to promises as async values. at
> least in every language binding they are OBJECTS. they have methods on them
> (p.then(), and to cancel p.cancel() for starters).

Well, the object nomenclature is a little misleading IMO. For C++ at least
everything is an object, even ints. So I agree a promise is an object. But
its sole purpose, IMO, is to hold a value that will be available in the future.
So both are right. IMO, the only problem with Eolizing Promise is 1. paying
for things we don't need; 2. The intricacies of other Eolian features, such
as inheritance for example.

I'm not completely against it being an Eo object however, though IMO
it is not a good tradeoff. But I can live with it and would be really happy
to build the JavaScript binding on top of that if I can deliver the same
semantics (on steroids) that normal JavaScript promises have.

The intrincacies of Eo properties, however, are not very easy to foresee
IMO. So, how inheritance should work? This is not a rhetorical question,
because right now we have a built-in called promise in Eolian
that says that a promise is being returned, because we don't have
parameterized classes in Eolian, so how should bindings know that
a derived class with more events are being used? If we use the
class name of the subclassed promise then we need new syntax
to allow parameterizing that in Eolian. Should we?

>> One example is making promises open to add new events through
>> inheritance. However, let's say that it is really desirable, so we can
>> all compromise on a middle term, we need to have a way to support
>> that in bindings in a way that is natural in the binding languages, and
>> IMO that is the _most_important_part_ and I have been repeating
>> myself about this since I introduced the promise idea in january, but
>> let me repeat again:
>
> yes, and since promises are objects in every language and binding we 
> support...
> this isn't much of an issue. we can extend progress events as eo events since
> they wont be a minimal base requirement. will these events be really common?

I actually like the idea of using events for progress, because it is an event,
it has all the properties of events. However, it just has one single problem,
which is the race condition of progress being available and when the event
is registered. This problem also existed with Eina_Promise however, and
we fixed by adding strict_promise concept which would only send progress
when a progress callback was registered. This could be case for Eo as well,
but we need to be able to differentiate, because a strict_promise can lead
to deadlock if the user never registers any progress callback.

> good question. at least in our current usage progress is not used, so... why
> not extend that via eo events? this would work in every language we bind to as
> long as we return the promise objects from our api's (they will be of the 
> right
> type then with these extensions).

OK.

> the natural bindings in c++ (libstdc++) have no progress, so when we add this 
> -
> our promises are not 1005 natural. this is something we have to accept, OR we
> will require efl to be the lowest common denominator of all languages and that
> would be far worse then even just using events on objects for async work.

We will accept it can be more than what the language offers. This is
common-place
even for STL implementations. They have extensions in numerous ways.

[snip]

>> Regards,
>> --
>> Felipe Magno de Almeida

Regards,
-- 
Felipe Magno de Almeida

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their 

Re: [E-devel] promises...

[The Rasterman]

On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida
 said:

> Hello,
> 
> I still don't get it why promises should be an all-or-nothing thing. It must
> be usable for all scenarios possible or we should drop it and
> live with events which are impossible to translate to the real semantics
> of asynchronous operations (I'm calling an asynchronous operation
> one that returns a value asynchronously) to bindings that already have
> a concept of asynchronous operations.

i don't know if anyone said it should be all or nothing. i have said that given
the newness and disagreements on promises that we need to use them very
carefully and avoid usage "all over the place" for now until we can settle them
down. if we were all happy with them and agreed on them then things may be
different, but that is not the case.

i think a big difference is our view of promises. to me a promise is an OBJECT
that REPRESENTS the async action (and then is responsible for calling the
correct callbacks and for storing the value until all such callbacks are called
etc. etc.). you (and cedric) keep referring to promises as async values. at
least in every language binding they are OBJECTS. they have methods on them
(p.then(), and to cancel p.cancel() for starters).

> One example is making promises open to add new events through
> inheritance. However, let's say that it is really desirable, so we can
> all compromise on a middle term, we need to have a way to support
> that in bindings in a way that is natural in the binding languages, and
> IMO that is the _most_important_part_ and I have been repeating
> myself about this since I introduced the promise idea in january, but
> let me repeat again:

yes, and since promises are objects in every language and binding we support...
this isn't much of an issue. we can extend progress events as eo events since
they wont be a minimal base requirement. will these events be really common?
good question. at least in our current usage progress is not used, so... why
not extend that via eo events? this would work in every language we bind to as
long as we return the promise objects from our api's (they will be of the right
type then with these extensions).

the natural bindings in c++ (libstdc++) have no progress, so when we add this -
our promises are not 1005 natural. this is something we have to accept, OR we
will require efl to be the lowest common denominator of all languages and that
would be far worse then even just using events on objects for async work.

> Promises must be a way to have well-defined-semantics for bindings
> to be able to translate that to what is natural and native in the binding
> languages. The whole efl interfaces effort, afaik, is not about C API,
> because we already have a stable C API! We need to think about
> bindings too, because the efl interfaces effort is, afaik, about having
> usable efl interface api for bindings, which we don't have yet. We
> can't create bad C APIs in the process ofc, but, afaik, this is not
> about creating new C APIs.

actually... efl interfaces started to improve/clean our c interfaces. bindings
came later. but i agree with you that things like promises need to map to
bindings nicely. they ALSO have to be nice in c. if the bindings are done
manually for other langs then we need to focus on making the c api nice. as
long as this does not PRECLUDE manual bindings from making promises work in the
language native way.

that's why i don't see that e HAVE to split promises in c into owner/future.
that can be done manually in the bindings *IF* the language does a split. js
does not. c++ does. java does. lua has no promise so it's whatever we decide
(likely the js way). but in C there is no real point in splitting between
promise owner and future.

> I work on most bindings for EFL, so yeah, I'll be very annoying about
> it, because I don't want to create bad bindings. I don't think anybody
> wants to work to do bad things, I'm not different. I want to be
> proud of what I deliver. And that means writing bindings that people
> will want to use, and not that people will curse me because they
> _have_ to use it. Also, I think it will help EFL a lot if we get it
> to be used by more languages.

see above. i agree. but we cant go fucking up our c api as a result.

> So, bindings already know the special relationship between derived
> classes of Future (I'm using cedric's nomenclature here) and
> translate new events directly. So I think this is doable. With the
> lifetime thing, well, for bindings I don't care if we drop it any
> automagical things because bindings will deal it correctly. So
> that makes things easier. Implementing data models in C
> might be a little less sexy, but still way easier than using events
> and caching all things and etc.

if the model objects do NOT cache data like properties... they are going to be
so horrible in performance... it's not funny. any re-fetch of a property by the
ui for 

Re: [E-devel] promises...

[Felipe Magno de Almeida]

Hello,

I still don't get it why promises should be an all-or-nothing thing. It must
be usable for all scenarios possible or we should drop it and
live with events which are impossible to translate to the real semantics
of asynchronous operations (I'm calling an asynchronous operation
one that returns a value asynchronously) to bindings that already have
a concept of asynchronous operations.

One example is making promises open to add new events through
inheritance. However, let's say that it is really desirable, so we can
all compromise on a middle term, we need to have a way to support
that in bindings in a way that is natural in the binding languages, and
IMO that is the _most_important_part_ and I have been repeating
myself about this since I introduced the promise idea in january, but
let me repeat again:

Promises must be a way to have well-defined-semantics for bindings
to be able to translate that to what is natural and native in the binding
languages. The whole efl interfaces effort, afaik, is not about C API,
because we already have a stable C API! We need to think about
bindings too, because the efl interfaces effort is, afaik, about having
usable efl interface api for bindings, which we don't have yet. We
can't create bad C APIs in the process ofc, but, afaik, this is not
about creating new C APIs.

I work on most bindings for EFL, so yeah, I'll be very annoying about
it, because I don't want to create bad bindings. I don't think anybody
wants to work to do bad things, I'm not different. I want to be
proud of what I deliver. And that means writing bindings that people
will want to use, and not that people will curse me because they
_have_ to use it. Also, I think it will help EFL a lot if we get it
to be used by more languages.

So, bindings already know the special relationship between derived
classes of Future (I'm using cedric's nomenclature here) and
translate new events directly. So I think this is doable. With the
lifetime thing, well, for bindings I don't care if we drop it any
automagical things because bindings will deal it correctly. So
that makes things easier. Implementing data models in C
might be a little less sexy, but still way easier than using events
and caching all things and etc.

The separation between Future and Promise, IMO, is good.
About the runtime-checking, I think there's a misconception here.
Eo is about runtime-checking indeed. But Eolian is about
generating interfaces that are not necessarily runtime-checked.
C++ is _not_ runtime-checked. So, if things belong to multiple
interfaces, then it should be in two different interfaces IMO.
Otherwise C++ programmers will assume they can value_set
a future/promise they received from another function. And
sometimes they will be right, it is not prohibited to return
promise_owners and it was an idea that almost worked for
genlists to get style from through events, it just didn't work
because genlist must get the style synchronously and not
asynchronously. So, separating the side that value_set
from the side that listens to value_set makes things
way clearer of the API intent.

However, as long as it uses different nomenclatures in
Eolian, I can separate them in C++ in generation.

Regards,
-- 
Felipe Magno de Almeida

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Fri, 24 Jun 2016 10:39:39 -0700 Cedric BAIL  said:

> On Thu, Jun 23, 2016 at 7:15 PM, Carsten Haitzler 
> wrote:
> > On Thu, 23 Jun 2016 15:04:22 -0700 Cedric BAIL  said:
> >> On Wed, Jun 22, 2016 at 6:42 PM, Carsten Haitzler 
> >> wrote:
> >> > On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL 
> >> > said:
> >> >> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
> >> >>  wrote:
> >> >> > On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
> >> >> >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
> >> >> >>  wrote:
> 
> 
> 
> >> > 3. we already have the ability to optimize with del intercepts. we could
> >> > actually make a del intercept at the class level (which makes much more
> >> > sense for the following)... we can cache objects. since caching will
> >> > only be effective on objects that don't change a lot from their
> >> > constructed state to their destructed one (promises for example do not
> >> > change much). so when destruction is about to begin... cache the object
> >> > somewhere, and now we need to also extend construction to allow there to
> >> > be a lookup for a cached object. my point here is that we can add
> >> > caching class by class easily enough and all we need is maybe 10-20
> >> > cached promise objects floating about at most and pick them from the
> >> > cache each time we need one. chances are this will address pretty much
> >> > all the performance issues. the only other is calling methods on a
> >> > promise via eo is slower but really... how much will that really matetr
> >> > given that 100's of other eo calls will happen as well at the same time
> >> > to handle the result of a promise etc. etc. - it's a rounding error of
> >> > difference at best in the overall performance of efl
> >>
> >> With all the complexity added in going with an eo object, let's just
> >> say, that maybe we will find a way to get performance kinda ok and
> >> maybe find some useful case where eo api does help in some way. So
> >> here is my current proposal on how we can do a promise with eo with
> >> the constraint as outlined by tom (no overriding of the reference
> >> count infrastructure). First example of the api for user :
> >>
> >> Example 1:
> >>
> >> eo_future_use(, efl_file_set(obj, file, key));
> >> eo_future_then(destination, _then, _cancel, _progress, NULL);
> >> eo_future_cancel(destination); // No barking on NULL
> >>
> >> Example 2:
> >>
> >> eo_future_use(, efl_file_set(obj, file, key));
> >> eo_ref(destination);
> >> eo_future_then(destination, _then1, _cancel1, _progress1, NULL);
> >> eo_future_then(destination, _then2, _cancel2, _progress2, NULL);
> >> eo_future_use(, eo_future_chain_then(destination, _then_chain,
> >> _cancel_chain, NULL, NULL));
> >> eo_future_use(, eo_future_all(destination, destination1,
> >> destination2, chain));
> >> eo_future_then(all, _then_all, _cancel_all, _progress_all, NULL);
> >> eo_future_link(obj, all); // We need to register a proper then/cancel
> >> callback to handle linking eo object with promise
> >> eo_unref(destination);
> >> eo_future_cancel(destination);
> >>
> >> Example 3:
> >>
> >> eo_future_then(efl_file_set(obj, file, key), _then, _cancel, NULL, NULL);
> >>
> >> Example 4:
> >>
> >> eo_future_use(, efl_file_set(obj, file, key));
> >> some->where = eo_ref(destination);
> >> f = eo_future_value_get(some->where);
> >> eo_unref(some->where);
> >
> > is there a reason you called it a future? you want to break it up into
> > promise vs future objects? can i just suggest not bothering? js doesn't
> > bother. it's a promise. just have 1 interface class for the owner to use
> > and another for the "user". if someone uses the wrong api on the obj - well
> > too bad for them. at least it is clear which you should use. this should
> > reduce complexity.
> 
> JS has not type checking at all. It makes no sense to indeed bother
> for them. We can provide type checking as I said one of them will be
> an opaque type and the more I think about it, the more I think I got
> the wrong one opaque.

no. you can't provide type checking with eo as it all gets typedefed to Eo in
the end so eo_ref, eo_* stuff work. i don't see any great value of typing here.
don't use owner funcs if you are a user of the promise. nice and simple.

> > so let us then just assume file_set returns a promise like above... why not
> > just do:
> >
> > Example 5:
> >
> > p = efl_file_async_set(obj, file, key);
> > eo_promise_then(p, cb_ok, cb_err, data);
> >
> > that's it? it's almost like example 3 but with a single data ptr to both
> > then and err cb's. so the short version like in example 3:
> 
> The first NULL pointer is obviously as shown in example 1 and 2 the
> progress callback and indeed you have copied the example 3, just for
> no reason droping the progress callback. 

Re: [E-devel] promises...

[Cedric BAIL]

On Thu, Jun 23, 2016 at 7:15 PM, Carsten Haitzler  wrote:
> On Thu, 23 Jun 2016 15:04:22 -0700 Cedric BAIL  said:
>> On Wed, Jun 22, 2016 at 6:42 PM, Carsten Haitzler 
>> wrote:
>> > On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL  said:
>> >> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
>> >>  wrote:
>> >> > On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
>> >> >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
>> >> >>  wrote:



>> > 3. we already have the ability to optimize with del intercepts. we could
>> > actually make a del intercept at the class level (which makes much more
>> > sense for the following)... we can cache objects. since caching will only 
>> > be
>> > effective on objects that don't change a lot from their constructed state 
>> > to
>> > their destructed one (promises for example do not change much). so when
>> > destruction is about to begin... cache the object somewhere, and now we
>> > need to also extend construction to allow there to be a lookup for a cached
>> > object. my point here is that we can add caching class by class easily
>> > enough and all we need is maybe 10-20 cached promise objects floating about
>> > at most and pick them from the cache each time we need one. chances are
>> > this will address pretty much all the performance issues. the only other is
>> > calling methods on a promise via eo is slower but really... how much will
>> > that really matetr given that 100's of other eo calls will happen as well
>> > at the same time to handle the result of a promise etc. etc. - it's a
>> > rounding error of difference at best in the overall performance of efl
>>
>> With all the complexity added in going with an eo object, let's just
>> say, that maybe we will find a way to get performance kinda ok and
>> maybe find some useful case where eo api does help in some way. So
>> here is my current proposal on how we can do a promise with eo with
>> the constraint as outlined by tom (no overriding of the reference
>> count infrastructure). First example of the api for user :
>>
>> Example 1:
>>
>> eo_future_use(, efl_file_set(obj, file, key));
>> eo_future_then(destination, _then, _cancel, _progress, NULL);
>> eo_future_cancel(destination); // No barking on NULL
>>
>> Example 2:
>>
>> eo_future_use(, efl_file_set(obj, file, key));
>> eo_ref(destination);
>> eo_future_then(destination, _then1, _cancel1, _progress1, NULL);
>> eo_future_then(destination, _then2, _cancel2, _progress2, NULL);
>> eo_future_use(, eo_future_chain_then(destination, _then_chain,
>> _cancel_chain, NULL, NULL));
>> eo_future_use(, eo_future_all(destination, destination1,
>> destination2, chain));
>> eo_future_then(all, _then_all, _cancel_all, _progress_all, NULL);
>> eo_future_link(obj, all); // We need to register a proper then/cancel
>> callback to handle linking eo object with promise
>> eo_unref(destination);
>> eo_future_cancel(destination);
>>
>> Example 3:
>>
>> eo_future_then(efl_file_set(obj, file, key), _then, _cancel, NULL, NULL);
>>
>> Example 4:
>>
>> eo_future_use(, efl_file_set(obj, file, key));
>> some->where = eo_ref(destination);
>> f = eo_future_value_get(some->where);
>> eo_unref(some->where);
>
> is there a reason you called it a future? you want to break it up into promise
> vs future objects? can i just suggest not bothering? js doesn't bother. it's a
> promise. just have 1 interface class for the owner to use and another for the
> "user". if someone uses the wrong api on the obj - well too bad for them. at
> least it is clear which you should use. this should reduce complexity.

JS has not type checking at all. It makes no sense to indeed bother
for them. We can provide type checking as I said one of them will be
an opaque type and the more I think about it, the more I think I got
the wrong one opaque.

> so let us then just assume file_set returns a promise like above... why not
> just do:
>
> Example 5:
>
> p = efl_file_async_set(obj, file, key);
> eo_promise_then(p, cb_ok, cb_err, data);
>
> that's it? it's almost like example 3 but with a single data ptr to both then
> and err cb's. so the short version like in example 3:

The first NULL pointer is obviously as shown in example 1 and 2 the
progress callback and indeed you have copied the example 3, just for
no reason droping the progress callback. This follow Ecmascript 6
calling convention into a way that I think is quite better (We usually
have the same data pointer for the same tripplet of
success/failure/progress).

> eo_promise_then(efl_file_async_set(obj, file, key), cb_ok, cb_err, NULL);
>
> if i do this i can no longer cancel the action as i lost the promise object
> handle.

Your example 5 will suffer from the same issue as you have now to
manually track the lifecycle of p to not call cancel or whatever you
want on a dead pointer.

> 

Re: [E-devel] promises...

[The Rasterman]

On Thu, 23 Jun 2016 15:04:22 -0700 Cedric BAIL  said:

> On Wed, Jun 22, 2016 at 6:42 PM, Carsten Haitzler 
> wrote:
> > On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL  said:
> >> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
> >>  wrote:
> >> > On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
> >> >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
> >> >>  wrote:
> >> >> > it is the _perfect_ match IMO. Probably we should ask someone
> >> >> > that actually uses Lua about it, instead of guessing.
> >> >>
> >> >> I'm inclined to agree with raster here. I honestly don't see
> >> >> coroutines being a good match here - the API is one thing, and there
> >> >> is one other thing to consider that wasn't brought up and that is
> >> >> performance - coroutines cannot be JITed and for async stuff we'll be
> >> >> jumping across C-Lua border all the time over classic C API rather
> >> >> than fast FFI stuff (it will also add a significant amount of new
> >> >> runtime on C side, which I would rather avoid) which will abort traces
> >> >> and hurt perf.
> >> >
> >> > Not using coroutines because of performance in lua doesn't seem like a
> >> > good reason at all IMO.
> >>
> >> 
> >>
> >> Just focusing here on the performance issue. If you think that
> >> coroutine are going to be a performance issue for promise, I think
> >> this raise two points to discuss. First how good is the JIT on short
> >> function, because if we go with events/callbacks, we will endup with
> >> very short snippet of code. I don't know for lua jit, but most JIT I
> >> know about are bad with short code anyway (It will literray come from
> >> C, execute a small amount of code and go back to C). So I don't really
> >> see why coroutine will be any worse than events/callbacks in that
> >> case.
> >>
> >> Second point, if you are concerned by performance, then why is it a
> >> good idea to switch to an eo object at all. We are now going to pay a
> >> way higher price for an API that will be wrapped in C to be convenient
> >> and manually binded in all bindings. So where do people still see any
> >> win at all into moving to an eo object ?
> >
> > just speaking of the eo promise performance thing - here is a summary of
> > discussions i've had with both jpeg and tasn:
> >
> > 1. for the vast majority of usage promises are not common and thus not an
> > issue
> 
> I am not to sure of this assesment. As we are going for more
> asynchronous behavior, we will use it a lot more. I am specifically
> worried about our use in the new list view which will likely be a big
> user of it. We may be able to reduce pressure by doing groupped
> binding, still not sure at all how that can be done with model
> intereception (Will require some time before such an optimization can
> land).



> > 2. performance issues in creating and destroying eo objects are not unique
> > to promises, so omptimizing to make them faster will help ALL eo objects.
> 
> How many object will have a life time and a cycle as short as a
> promise ? Not many in my opinion. We do try hard to recycle object
> everywhere for that reason. Sure, it is nice to optimize and bet that
> we can optimize it later if necessary, but still why pay the cost in
> the first place ?

jobs, timers have such short lifetimes. they always have. in fact part proxy
objects will have an ever shorter lifetime and will be more common than
promises.

so here is my view. let's take the worst case we have. model. with a genlist.
how many promise api calls will we make vs other eo api calls - eg move obj,
resize, set text, set color, etc. etc. etc. - what percentage are a method call
on a promise vs others. let us for now ignore the content of a call and let's
just talk about call overhead. let's for now ignore creation/destruction. just
calls. ignore cpu time to render and everything else. just the call overhead of
an eo call on a promise vs what eina had. what percentage of calls are promise
ones during any given second of scrolling around? i argue maybe 1 in 100 is a
call on a promise. maybe. on a bad day. more likely 1 in 500. but let's just
talk of the worst side - 1% of calls. 1% of calls are slower now because they
are eo calls. now lets' throw in all the other cpu time in ACTUALLY doing the
work. that has to dwarf the call cost by at least 100 times. the code spent
sorting lists, walking through objects to render, doing i/o etc.

so my back-of-a-napkin numbers say that 0.01% of our cpu time will be slower...
what by maybe 3x? 5x? let's say 10x slower so on a bad day 0.1% overhead.
that's within error margins. you can't measure it really. and that's imho worst
case scenario. in general it'll be far less so like 0.001% or so. maybe.

> > 3. we already have the ability to optimize with del intercepts. we could
> > actually make a del intercept at the 

Re: [E-devel] promises...

[The Rasterman]

On Wed, 22 Jun 2016 20:11:31 -0700 Cedric BAIL  said:

> On Jun 22, 2016 18:28, "Carsten Haitzler"  wrote:
> > On Wed, 22 Jun 2016 10:31:54 -0700 Cedric BAIL  said:
> > > On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler  >
> > > wrote:
> > > > On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL 
> said:
> > > >> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler <
> ras...@rasterman.com>
> > > >> wrote:
> > > >> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
> > > >> >  said:
> > > >> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler
> > > >> >>  wrote:
> > > >> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> > > >> >> >  said:
> > > >> >> >
> > > >> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler
> > > >> >> >>  wrote:
> > > >> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> > > >> >> >> >  said:
> > > >> >>
> > > >> >> [snip]
> > > >> >>
> > > >> >> >> There will be wait. I'll implement it. It will throw an
> exception if
> > > >> >> >> it is called from the mainloop thread. And people will miss
> cancel
> > > >> >> >> if they don't look for it. They will miss it too if they use
> > > >> >> >> Eo_Promise too and don't look for it.
> > > >> >> >
> > > >> >> > there';s a difference. if it's a std promise then they expect
> it to
> > > >> >> > work a certain way. if its an efl one they need to learn its
> api and
> > > >> >> > behaviour. they will find the features.
> > > >> >>
> > > >> >> We can't be arguing C++ API because users won't read a header
> file.
> > > >> >> This is not reasonable. Do we expect C developers to read
> > > >> >> documentation, or at least doxygen docs?
> > > >> >
> > > >> > we do expect them to read. though in my experience few actually
> read a
> > > >> > header file. docs is an expectation.
> > > >> >
> > > >> > but the issue here is of masquerading with a feature that will
> never work
> > > >> > (wait). it'll always cause an exception. it'd just be best to look
> > > >> > similar to a future/promise and just be a different class.
> > > >>
> > > >> I don't understand why you think we can't implement wait. The C++
> > > >> standard doesn't expect it to work with a mainloop, but from another
> > > >> thread. So it is very simple to implement it. When you instanciate a
> > > >> promise, you do also create a mutex, a cond and add a first
> > > >> then/cancel couple that will just take that mutex, set the value and
> > > >> broadcast on the cond. The future itself when instanciated will ref
> > > >> count the promise and on the wait will take the mutex and wait on the
> > > >> cond if the value is not there already. The only difference is that
> > > >> use of wait in C++ will lead to dead lock if you use it in the same
> > > >> thread, we will have a warning and throw an excepion in that case.
> > > >> This is the only difference and I fail to see where you see a
> problem.
> > > >
> > > > we have no wait in efl for promises. that's my point. it doesn't
> exist. and
> > > > yes
> > > > - if it were to be used within the same thread where the work is done
> - it'd
> > > > deadlock.
> > >
> > > Yes, we don't have one and it would only make sense to have one, when
> > > we push for having more thread around, for now it can wait. And if it
> > > is possible to implement it in the C++ binding, it should be possible
> > > in C when the need come. I still don't get why you are making that
> > > point. The C++ binding as any binding on promise is manually done for
> > > reason discussed in other email here, so the fact that we do not have
> > > a 1:1 matching doesn't matter as long as we can provide what the user
> > > of that language expect, which we can.
> >
> > my point is that if you want to have promises mapped natively to each
> language
> > by hand, then c++ has a wait() and nothing maps to that at all and so you
> have
> > a wait() that does nothing.
> 
> Ah, ok, so as you have likely guessed now, there will be an implementation
> of wait done by the c++ binding that will do exactly what is expected by
> c++ developers (and implemented in the way I described above). This is one
> of the reason to do things manually is to match the language needs and
> adapt.
> 
> > C++ devs used to promises/futures in c++ will be
> > confused when a feature they expect to work does not. the point of
> mapping to
> > the native language type for this is to re-use existing knowledge. the
> existing
> > knowledge doesnt map. it fails e.g. with wait()
> 
> Ok, so if that was your concern,I hope that it is now clear that it will
> work and their is no issue at all with it.

work how? if efl's promise doesn't do it - then wait in c++ can only just fail
and generate exceptions - so the api is there but it always 

Re: [E-devel] promises...

[Cedric BAIL]

On Wed, Jun 22, 2016 at 6:42 PM, Carsten Haitzler  wrote:
> On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL  said:
>> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
>>  wrote:
>> > On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
>> >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
>> >>  wrote:
>> >> > it is the _perfect_ match IMO. Probably we should ask someone
>> >> > that actually uses Lua about it, instead of guessing.
>> >>
>> >> I'm inclined to agree with raster here. I honestly don't see
>> >> coroutines being a good match here - the API is one thing, and there
>> >> is one other thing to consider that wasn't brought up and that is
>> >> performance - coroutines cannot be JITed and for async stuff we'll be
>> >> jumping across C-Lua border all the time over classic C API rather
>> >> than fast FFI stuff (it will also add a significant amount of new
>> >> runtime on C side, which I would rather avoid) which will abort traces
>> >> and hurt perf.
>> >
>> > Not using coroutines because of performance in lua doesn't seem like a good
>> > reason at all IMO.
>>
>> 
>>
>> Just focusing here on the performance issue. If you think that
>> coroutine are going to be a performance issue for promise, I think
>> this raise two points to discuss. First how good is the JIT on short
>> function, because if we go with events/callbacks, we will endup with
>> very short snippet of code. I don't know for lua jit, but most JIT I
>> know about are bad with short code anyway (It will literray come from
>> C, execute a small amount of code and go back to C). So I don't really
>> see why coroutine will be any worse than events/callbacks in that
>> case.
>>
>> Second point, if you are concerned by performance, then why is it a
>> good idea to switch to an eo object at all. We are now going to pay a
>> way higher price for an API that will be wrapped in C to be convenient
>> and manually binded in all bindings. So where do people still see any
>> win at all into moving to an eo object ?
>
> just speaking of the eo promise performance thing - here is a summary of
> discussions i've had with both jpeg and tasn:
>
> 1. for the vast majority of usage promises are not common and thus not an 
> issue

I am not to sure of this assesment. As we are going for more
asynchronous behavior, we will use it a lot more. I am specifically
worried about our use in the new list view which will likely be a big
user of it. We may be able to reduce pressure by doing groupped
binding, still not sure at all how that can be done with model
intereception (Will require some time before such an optimization can
land).

> 2. performance issues in creating and destroying eo objects are not unique to
> promises, so omptimizing to make them faster will help ALL eo objects.

How many object will have a life time and a cycle as short as a
promise ? Not many in my opinion. We do try hard to recycle object
everywhere for that reason. Sure, it is nice to optimize and bet that
we can optimize it later if necessary, but still why pay the cost in
the first place ?

> 3. we already have the ability to optimize with del intercepts. we could
> actually make a del intercept at the class level (which makes much more sense
> for the following)... we can cache objects. since caching will only be
> effective on objects that don't change a lot from their constructed state to
> their destructed one (promises for example do not change much). so when
> destruction is about to begin... cache the object somewhere, and now we need 
> to
> also extend construction to allow there to be a lookup for a cached object. my
> point here is that we can add caching class by class easily enough and all we
> need is maybe 10-20 cached promise objects floating about at most and pick 
> them
> from the cache each time we need one. chances are this will address pretty 
> much
> all the performance issues. the only other is calling methods on a promise via
> eo is slower but really... how much will that really matetr given that 100's 
> of
> other eo calls will happen as well at the same time to handle the result of a
> promise etc. etc. - it's a rounding error of difference at best in the overall
> performance of efl

With all the complexity added in going with an eo object, let's just
say, that maybe we will find a way to get performance kinda ok and
maybe find some useful case where eo api does help in some way. So
here is my current proposal on how we can do a promise with eo with
the constraint as outlined by tom (no overriding of the reference
count infrastructure). First example of the api for user :

Example 1:

eo_future_use(, efl_file_set(obj, file, key));
eo_future_then(destination, _then, _cancel, _progress, NULL);
eo_future_cancel(destination); // No barking on NULL

Example 2:

eo_future_use(, efl_file_set(obj, file, key));

Re: [E-devel] promises...

[Cedric BAIL]

On Jun 22, 2016 18:28, "Carsten Haitzler"  wrote:
> On Wed, 22 Jun 2016 10:31:54 -0700 Cedric BAIL  said:
> > On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler 
> > wrote:
> > > On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL 
said:
> > >> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler <
ras...@rasterman.com>
> > >> wrote:
> > >> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
> > >> >  said:
> > >> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler
> > >> >>  wrote:
> > >> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> > >> >> >  said:
> > >> >> >
> > >> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler
> > >> >> >>  wrote:
> > >> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> > >> >> >> >  said:
> > >> >>
> > >> >> [snip]
> > >> >>
> > >> >> >> There will be wait. I'll implement it. It will throw an
exception if
> > >> >> >> it is called from the mainloop thread. And people will miss
cancel
> > >> >> >> if they don't look for it. They will miss it too if they use
> > >> >> >> Eo_Promise too and don't look for it.
> > >> >> >
> > >> >> > there';s a difference. if it's a std promise then they expect
it to
> > >> >> > work a certain way. if its an efl one they need to learn its
api and
> > >> >> > behaviour. they will find the features.
> > >> >>
> > >> >> We can't be arguing C++ API because users won't read a header
file.
> > >> >> This is not reasonable. Do we expect C developers to read
> > >> >> documentation, or at least doxygen docs?
> > >> >
> > >> > we do expect them to read. though in my experience few actually
read a
> > >> > header file. docs is an expectation.
> > >> >
> > >> > but the issue here is of masquerading with a feature that will
never work
> > >> > (wait). it'll always cause an exception. it'd just be best to look
> > >> > similar to a future/promise and just be a different class.
> > >>
> > >> I don't understand why you think we can't implement wait. The C++
> > >> standard doesn't expect it to work with a mainloop, but from another
> > >> thread. So it is very simple to implement it. When you instanciate a
> > >> promise, you do also create a mutex, a cond and add a first
> > >> then/cancel couple that will just take that mutex, set the value and
> > >> broadcast on the cond. The future itself when instanciated will ref
> > >> count the promise and on the wait will take the mutex and wait on the
> > >> cond if the value is not there already. The only difference is that
> > >> use of wait in C++ will lead to dead lock if you use it in the same
> > >> thread, we will have a warning and throw an excepion in that case.
> > >> This is the only difference and I fail to see where you see a
problem.
> > >
> > > we have no wait in efl for promises. that's my point. it doesn't
exist. and
> > > yes
> > > - if it were to be used within the same thread where the work is done
- it'd
> > > deadlock.
> >
> > Yes, we don't have one and it would only make sense to have one, when
> > we push for having more thread around, for now it can wait. And if it
> > is possible to implement it in the C++ binding, it should be possible
> > in C when the need come. I still don't get why you are making that
> > point. The C++ binding as any binding on promise is manually done for
> > reason discussed in other email here, so the fact that we do not have
> > a 1:1 matching doesn't matter as long as we can provide what the user
> > of that language expect, which we can.
>
> my point is that if you want to have promises mapped natively to each
language
> by hand, then c++ has a wait() and nothing maps to that at all and so you
have
> a wait() that does nothing.

Ah, ok, so as you have likely guessed now, there will be an implementation
of wait done by the c++ binding that will do exactly what is expected by
c++ developers (and implemented in the way I described above). This is one
of the reason to do things manually is to match the language needs and
adapt.

> C++ devs used to promises/futures in c++ will be
> confused when a feature they expect to work does not. the point of
mapping to
> the native language type for this is to re-use existing knowledge. the
existing
> knowledge doesnt map. it fails e.g. with wait()

Ok, so if that was your concern,I hope that it is now clear that it will
work and their is no issue at all with it.

Cedric

> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This 

Re: [E-devel] promises...

[The Rasterman]

On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL  said:

> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
>  wrote:
> > On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
> >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
> >>  wrote:
> >> > it is the _perfect_ match IMO. Probably we should ask someone
> >> > that actually uses Lua about it, instead of guessing.
> >>
> >> I'm inclined to agree with raster here. I honestly don't see
> >> coroutines being a good match here - the API is one thing, and there
> >> is one other thing to consider that wasn't brought up and that is
> >> performance - coroutines cannot be JITed and for async stuff we'll be
> >> jumping across C-Lua border all the time over classic C API rather
> >> than fast FFI stuff (it will also add a significant amount of new
> >> runtime on C side, which I would rather avoid) which will abort traces
> >> and hurt perf.
> >
> > Not using coroutines because of performance in lua doesn't seem like a good
> > reason at all IMO.
> 
> 
> 
> Just focusing here on the performance issue. If you think that
> coroutine are going to be a performance issue for promise, I think
> this raise two points to discuss. First how good is the JIT on short
> function, because if we go with events/callbacks, we will endup with
> very short snippet of code. I don't know for lua jit, but most JIT I
> know about are bad with short code anyway (It will literray come from
> C, execute a small amount of code and go back to C). So I don't really
> see why coroutine will be any worse than events/callbacks in that
> case.
> 
> Second point, if you are concerned by performance, then why is it a
> good idea to switch to an eo object at all. We are now going to pay a
> way higher price for an API that will be wrapped in C to be convenient
> and manually binded in all bindings. So where do people still see any
> win at all into moving to an eo object ?

just speaking of the eo promise performance thing - here is a summary of
discussions i've had with both jpeg and tasn:

1. for the vast majority of usage promises are not common and thus not an issue
2. performance issues in creating and destroying eo objects are not unique to
promises, so omptimizing to make them faster will help ALL eo objects.
3. we already have the ability to optimize with del intercepts. we could
actually make a del intercept at the class level (which makes much more sense
for the following)... we can cache objects. since caching will only be
effective on objects that don't change a lot from their constructed state to
their destructed one (promises for example do not change much). so when
destruction is about to begin... cache the object somewhere, and now we need to
also extend construction to allow there to be a lookup for a cached object. my
point here is that we can add caching class by class easily enough and all we
need is maybe 10-20 cached promise objects floating about at most and pick them
from the cache each time we need one. chances are this will address pretty much
all the performance issues. the only other is calling methods on a promise via
eo is slower but really... how much will that really matetr given that 100's of
other eo calls will happen as well at the same time to handle the result of a
promise etc. etc. - it's a rounding error of difference at best in the overall
performance of efl



-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Wed, 22 Jun 2016 10:31:54 -0700 Cedric BAIL  said:

> On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler 
> wrote:
> > On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL  said:
> >> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler 
> >> wrote:
> >> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
> >> >  said:
> >> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler
> >> >>  wrote:
> >> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> >> >> >  said:
> >> >> >
> >> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler
> >> >> >>  wrote:
> >> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> >> >> >> >  said:
> >> >>
> >> >> [snip]
> >> >>
> >> >> >> There will be wait. I'll implement it. It will throw an exception if
> >> >> >> it is called from the mainloop thread. And people will miss cancel
> >> >> >> if they don't look for it. They will miss it too if they use
> >> >> >> Eo_Promise too and don't look for it.
> >> >> >
> >> >> > there';s a difference. if it's a std promise then they expect it to
> >> >> > work a certain way. if its an efl one they need to learn its api and
> >> >> > behaviour. they will find the features.
> >> >>
> >> >> We can't be arguing C++ API because users won't read a header file.
> >> >> This is not reasonable. Do we expect C developers to read
> >> >> documentation, or at least doxygen docs?
> >> >
> >> > we do expect them to read. though in my experience few actually read a
> >> > header file. docs is an expectation.
> >> >
> >> > but the issue here is of masquerading with a feature that will never work
> >> > (wait). it'll always cause an exception. it'd just be best to look
> >> > similar to a future/promise and just be a different class.
> >>
> >> I don't understand why you think we can't implement wait. The C++
> >> standard doesn't expect it to work with a mainloop, but from another
> >> thread. So it is very simple to implement it. When you instanciate a
> >> promise, you do also create a mutex, a cond and add a first
> >> then/cancel couple that will just take that mutex, set the value and
> >> broadcast on the cond. The future itself when instanciated will ref
> >> count the promise and on the wait will take the mutex and wait on the
> >> cond if the value is not there already. The only difference is that
> >> use of wait in C++ will lead to dead lock if you use it in the same
> >> thread, we will have a warning and throw an excepion in that case.
> >> This is the only difference and I fail to see where you see a problem.
> >
> > we have no wait in efl for promises. that's my point. it doesn't exist. and
> > yes
> > - if it were to be used within the same thread where the work is done - it'd
> > deadlock.
> 
> Yes, we don't have one and it would only make sense to have one, when
> we push for having more thread around, for now it can wait. And if it
> is possible to implement it in the C++ binding, it should be possible
> in C when the need come. I still don't get why you are making that
> point. The C++ binding as any binding on promise is manually done for
> reason discussed in other email here, so the fact that we do not have
> a 1:1 matching doesn't matter as long as we can provide what the user
> of that language expect, which we can.

my point is that if you want to have promises mapped natively to each language
by hand, then c++ has a wait() and nothing maps to that at all and so you have
a wait() that does nothing. c++ devs used to promises/futures in c++ will be
confused when a feature they expect to work does not. the point of mapping to
the native language type for this is to re-use existing knowledge. the existing
knowledge doesnt map. it fails e.g. with wait()

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Cedric BAIL]

On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida
 wrote:
> On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
>> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
>>  wrote:
>> > it is the _perfect_ match IMO. Probably we should ask someone
>> > that actually uses Lua about it, instead of guessing.
>>
>> I'm inclined to agree with raster here. I honestly don't see
>> coroutines being a good match here - the API is one thing, and there
>> is one other thing to consider that wasn't brought up and that is
>> performance - coroutines cannot be JITed and for async stuff we'll be
>> jumping across C-Lua border all the time over classic C API rather
>> than fast FFI stuff (it will also add a significant amount of new
>> runtime on C side, which I would rather avoid) which will abort traces
>> and hurt perf.
>
> Not using coroutines because of performance in lua doesn't seem like a good
> reason at all IMO.



Just focusing here on the performance issue. If you think that
coroutine are going to be a performance issue for promise, I think
this raise two points to discuss. First how good is the JIT on short
function, because if we go with events/callbacks, we will endup with
very short snippet of code. I don't know for lua jit, but most JIT I
know about are bad with short code anyway (It will literray come from
C, execute a small amount of code and go back to C). So I don't really
see why coroutine will be any worse than events/callbacks in that
case.

Second point, if you are concerned by performance, then why is it a
good idea to switch to an eo object at all. We are now going to pay a
way higher price for an API that will be wrapped in C to be convenient
and manually binded in all bindings. So where do people still see any
win at all into moving to an eo object ?
-- 
Cedric BAIL

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Cedric BAIL]

On Tue, Jun 21, 2016 at 10:35 PM, Carsten Haitzler  wrote:
> On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL  said:
>> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler 
>> wrote:
>> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
>> >  said:
>> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler 
>> >> wrote:
>> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
>> >> >  said:
>> >> >
>> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler 
>> >> >> 
>> >> >> wrote:
>> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
>> >> >> >  said:
>> >>
>> >> [snip]
>> >>
>> >> >> There will be wait. I'll implement it. It will throw an exception if it
>> >> >> is called from the mainloop thread. And people will miss cancel if they
>> >> >> don't look for it. They will miss it too if they use Eo_Promise too and
>> >> >> don't look for it.
>> >> >
>> >> > there';s a difference. if it's a std promise then they expect it to work
>> >> > a certain way. if its an efl one they need to learn its api and
>> >> > behaviour. they will find the features.
>> >>
>> >> We can't be arguing C++ API because users won't read a header file.
>> >> This is not reasonable. Do we expect C developers to read
>> >> documentation, or at least doxygen docs?
>> >
>> > we do expect them to read. though in my experience few actually read a
>> > header file. docs is an expectation.
>> >
>> > but the issue here is of masquerading with a feature that will never work
>> > (wait). it'll always cause an exception. it'd just be best to look similar
>> > to a future/promise and just be a different class.
>>
>> I don't understand why you think we can't implement wait. The C++
>> standard doesn't expect it to work with a mainloop, but from another
>> thread. So it is very simple to implement it. When you instanciate a
>> promise, you do also create a mutex, a cond and add a first
>> then/cancel couple that will just take that mutex, set the value and
>> broadcast on the cond. The future itself when instanciated will ref
>> count the promise and on the wait will take the mutex and wait on the
>> cond if the value is not there already. The only difference is that
>> use of wait in C++ will lead to dead lock if you use it in the same
>> thread, we will have a warning and throw an excepion in that case.
>> This is the only difference and I fail to see where you see a problem.
>
> we have no wait in efl for promises. that's my point. it doesn't exist. and 
> yes
> - if it were to be used within the same thread where the work is done - it'd
> deadlock.

Yes, we don't have one and it would only make sense to have one, when
we push for having more thread around, for now it can wait. And if it
is possible to implement it in the C++ binding, it should be possible
in C when the need come. I still don't get why you are making that
point. The C++ binding as any binding on promise is manually done for
reason discussed in other email here, so the fact that we do not have
a 1:1 matching doesn't matter as long as we can provide what the user
of that language expect, which we can.
-- 
Cedric BAIL

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Jun 22, 2016 9:22 AM, "Daniel Kolesa"  wrote:
>
> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
>  wrote:
> >
> > it is the _perfect_ match IMO. Probably we should ask someone
> > that actually uses Lua about it, instead of guessing.
> >
>
> I'm inclined to agree with raster here. I honestly don't see
> coroutines being a good match here - the API is one thing, and there
> is one other thing to consider that wasn't brought up and that is
> performance - coroutines cannot be JITed and for async stuff we'll be
> jumping across C-Lua border all the time over classic C API rather
> than fast FFI stuff (it will also add a significant amount of new
> runtime on C side, which I would rather avoid) which will abort traces
> and hurt perf.

Not using coroutines because of performance in lua doesn't seem like a good
reason at all IMO. And I don't see where the api doesn't match. That
coroutine is not cancellable is not because coroutines are intrinsically
not cancellable, it is just because we need cancellation points,  which we
have with promises. Anyway I don't think this discussion is getting us
anywhere IMO. So I'll just leave the discussing in Lua bindings. However
the C++ and Javascript bindings should work the same as you propose for Lua.

> If we have promises at all (I'm still against them, and I think this
> "hurr async everything, promises everywhere" approach creates more
> problems than it solves) then the separate promise object is probably
> the sanest approach. Obviously this object would be bound manually,
> having an eo file defining it is stupid (honestly, I'm against having
> Eo.Base in an eo file as well, I'd rather make it a builtin, it's not
> like bindings are going to use it - Lua already skips it and binds it
> on its own).

This is not about async everywhere and not even about using promises for
ago async behavior. But I don't see any other proposal for real async
operations,which we already have in several places, except in creating
horrible API with events for getting results and dealing with private data
manually on more events, bending events to the point of almost breaking it
so they behave the same even with drastically different behavior. So being
against promises is like being against malloc.

> D5
>

--
Felipe Magno de Almeida
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Daniel Kolesa]

On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida
 wrote:
>
> it is the _perfect_ match IMO. Probably we should ask someone
> that actually uses Lua about it, instead of guessing.
>

I'm inclined to agree with raster here. I honestly don't see
coroutines being a good match here - the API is one thing, and there
is one other thing to consider that wasn't brought up and that is
performance - coroutines cannot be JITed and for async stuff we'll be
jumping across C-Lua border all the time over classic C API rather
than fast FFI stuff (it will also add a significant amount of new
runtime on C side, which I would rather avoid) which will abort traces
and hurt perf.

If we have promises at all (I'm still against them, and I think this
"hurr async everything, promises everywhere" approach creates more
problems than it solves) then the separate promise object is probably
the sanest approach. Obviously this object would be bound manually,
having an eo file defining it is stupid (honestly, I'm against having
Eo.Base in an eo file as well, I'd rather make it a builtin, it's not
like bindings are going to use it - Lua already skips it and binds it
on its own).

D5

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Mon, 20 Jun 2016 13:03:01 -0700 Cedric BAIL  said:

> On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler 
> wrote:
> > On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
> >  said:
> >> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler 
> >> wrote:
> >> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> >> >  said:
> >> >
> >> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler 
> >> >> wrote:
> >> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> >> >> >  said:
> >>
> >> [snip]
> >>
> >> >> There will be wait. I'll implement it. It will throw an exception if it
> >> >> is called from the mainloop thread. And people will miss cancel if they
> >> >> don't look for it. They will miss it too if they use Eo_Promise too and
> >> >> don't look for it.
> >> >
> >> > there';s a difference. if it's a std promise then they expect it to work
> >> > a certain way. if its an efl one they need to learn its api and
> >> > behaviour. they will find the features.
> >>
> >> We can't be arguing C++ API because users won't read a header file.
> >> This is not reasonable. Do we expect C developers to read
> >> documentation, or at least doxygen docs?
> >
> > we do expect them to read. though in my experience few actually read a
> > header file. docs is an expectation.
> >
> > but the issue here is of masquerading with a feature that will never work
> > (wait). it'll always cause an exception. it'd just be best to look similar
> > to a future/promise and just be a different class.
> 
> I don't understand why you think we can't implement wait. The C++
> standard doesn't expect it to work with a mainloop, but from another
> thread. So it is very simple to implement it. When you instanciate a
> promise, you do also create a mutex, a cond and add a first
> then/cancel couple that will just take that mutex, set the value and
> broadcast on the cond. The future itself when instanciated will ref
> count the promise and on the wait will take the mutex and wait on the
> cond if the value is not there already. The only difference is that
> use of wait in C++ will lead to dead lock if you use it in the same
> thread, we will have a warning and throw an excepion in that case.
> This is the only difference and I fail to see where you see a problem.

we have no wait in efl for promises. that's my point. it doesn't exist. and yes
- if it were to be used within the same thread where the work is done - it'd
deadlock.

> -- 
> Cedric BAIL
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Mon, 20 Jun 2016 18:07:46 +0100 Tom Hacohen  said:

> On 19/06/16 02:27, Carsten Haitzler wrote:
> > On Fri, 17 Jun 2016 09:41:39 +0100 Tom Hacohen  said:
> >
> >> On 17/06/16 03:28, Carsten Haitzler wrote:
> >>> On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen  
> >>> said:
> >>>
>  On 03/06/16 20:17, Cedric BAIL wrote:
>  
> >>> also promises should become eo objects with event cb's
> >>> so they work just like everything else. i can ref, unref, delete and
> >>> whatever them like everything else.
> >
> > As said above, this does work. Example with event :
> > eo_promise = efl_file_set(image, "toto.jpg", NULL);
> > eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
> > eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
> >
> > In this 3 lines, there is already 2 case in which that fail. First if,
> > the object is done before the callback is set, data are lost and there
> > is no way to get any event. Ofcourse, we can override the behavior of
> > events on this eo_promise completely. Now let's imagine, that we
> > actually do always store the events, so that everytime someone
> > register a callback we can send the event. Still you can't auto del
> > the object at any point in time, you have to force the user to
> > implement the eo_del and to always provide both a then and cancel
> > callback.
> >
> > Other possibility, it is an event on the object itself.
> > eo_event_callback_array_add(image, promise_callbacks1(), NULL);
> > efl_file_set(image, "toto.jpg", NULL);
> > eo_event_callback_array_add(image, promise_callbacks2(), NULL);
> >
> > Same again, this can not work. The first group of event handler,
> > promise_callbacks1(), may actually be triggered by a previously
> > running promise on the object, so you have to first forcefully stop
> > the previous operation. This would add complexity. And still the
> > second callback has the same issue as the previous case, if it is a
> > normal eo event, it could have been triggered before any callback get
> > registered and the event be lost... Same story short, doesn't work.
> >
> 
>  I'm currently reading through the thread, and I didn't see anything
>  mentioned about this other than a casual remark you made, so just wanted
>  to make it crystal clear regarding implementing it as an Eo object.
>  The whole point/magic of inheritance is that you can and are supposed to
>  override functions if needed. Overriding callback add to call the
>  callback immediately upon addition (if already done) is how I would
>  implement promise callbacks. It's clean, easy and as intended. This is
>  definitely not a problem.
> >>>
> >>> just for convenience i think having a special eo_promise_then(obj, cb1,
> >>> cb2, data); may be best as its the simplest and is not pretending to ADD
> >>> a cb in the name. it sets it explicitly. this needs special treatment
> >>> like the eo event callbacks of course.
> >>>
> >>> but using an eo event is possible by override indeed, but here is the
> >>> issue. you have to wait until either "then" or "else" or both are set.
> >>> since you set one then set another... you will have to always add one of
> >>> them as a NULL or dummy cb just to do this. having a single method/func
> >>> set both makes more sense. in fact this likely needs manual
> >>> binding/.handling per language anyway. i'm really only thinking of eo
> >>> events for EXTRA features like progress events on a promise that happen
> >>> before the success/fail cb's above.
> >>>
> >>>
> >>
> >> This is explained better in my reply to the initial post of this thread,
> >> but essentially you don't. What you are missing, and why life-cycle can
> >> be pretty broken, and why this doesn't matter is that you can register a
> >> few "then" and a few "cancel" in promises. That is actually the power of
> >> promises, that you can chain them and use them for a few things. This is
> >> dealt with nicely. See the post I mentioned.
> >
> > register a few then/else cb's on the same promise? at least that should not
> > be possible (it should not work). on;y one else/then cb (zero or one of
> > each).
> >
> >
> 
> Why not? Anyhow, as I said, that is very common in js land and how race 
> and all are probably implemented.

eh? well eina_promise allowed only a single then... which i think is the sanest
way here. limit it to one. the reason is that otherwise you never know when the
promise is finished its setup. you need a special done() call on the promise
then to tell it you're done attaching callbacks. e.g. for the case it's an
async load but the load finds the target in an in-memory cache already and
wants to immediately call the then func - when does it call it? if you can add
any number of then funcs... ?

-- 

Re: [E-devel] promises...

[The Rasterman]

On Mon, 20 Jun 2016 18:04:30 +0100 Tom Hacohen  said:

> On 19/06/16 02:24, Carsten Haitzler wrote:
> > On Fri, 17 Jun 2016 09:21:13 +0100 Tom Hacohen  said:
> >
> >> On 17/06/16 03:21, Carsten Haitzler wrote:
> >>> On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen  
> >>> said:
> >>>
>  On 16/06/16 10:47, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André
> >  said:
> >
> >
>  The ON_HOLD flag, now called efl_event_processed_get/set() is a
>  better approach to stop processing events.
> >>>
> >>> That is off topic, but seriously something we should consider asap if
> >>> we want to drop the return type of event. I have not any case in mind
> >>> where returning EINA_FALSE make sense. Should we drop it ?
> >>>
> >>
> >> I am also thinking we should drop it.
> >> Pretty sure the few places that return EINA_FALSE right now are
> >> actually mistakes and sources of bugs.
> >
> > i think so too. drop the return.
> >
> 
>  The return is mega useful, though I'm open to implementing it
>  differently. The return is there so you can filter events. We currently
>  have things like "on_hold" in input events to mark an event has been
>  processed and should stop propagating, but the return lets you stop the
>  callback. I guess we can change it to be "eo_event_callback_stop(obj)".
> >>>
> >>> but the thing is.. we don't want to stop the callback. well not where hold
> >>> is used. you want to still get the cb but put on hold any actions.like
> >>> calling the clicked callback. you still need the event to get the matching
> >>> mouse up fro the mouse down for example, but since you started a drag,
> >>> after n move events the mouse up (and future moves) should not be acted
> >>> on.
> >>>
>  Btw, it shouldn't be a bool, there are defines for the return values. I
>  should have typedeffed the type. I'm open to changing to
>  eo_event_callback_stop though, just let me know.
> 
>  Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
>  write. :)
> >>>
> >>> see above. the only use case we have to date is the above and a return
> >>> just doesn't do it. you need to have a modified event go through
> >>> afterwards.
> >>>
> >>> i did the return true/false for ecore events for pass through. over the
> >>> years i have recognized this as a mistake. it's more pain than gain.
> >>
> >> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels
> >> better for making event propagation to stop, but I do like being able to
> >> stop it. It is used in the EFL, I just got the name wrong,
> >> EO_CALLBACK_STOP. :)
> >> It's useful for text filtering iirc, to make it stop processing the
> >> filter if one has already failed. It is used and useful.
> >
> > considering the rarity of this need... i think eo_event_callback_stop()
> > seems fine to me. it means the 99% case of passing it on is less likely to
> > have an error in it by returning the wrong value (or someone not returning
> > at all and they either dont have warnings for that in their compiler or...
> > they have so many they miss this warning) :)
> >
> 
> 
> I need to take a bath after this change, but anyhow: done. :)

just do your hacking in the bath! never have a need to take a bath again... as
that's your normal state! :)


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Cedric BAIL]

On Sun, Jun 19, 2016 at 9:38 PM, Carsten Haitzler  wrote:
> On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida
>  said:
>> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler 
>> wrote:
>> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
>> >  said:
>> >
>> >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler 
>> >> wrote:
>> >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
>> >> >  said:
>>
>> [snip]
>>
>> >> There will be wait. I'll implement it. It will throw an exception if it is
>> >> called from the mainloop thread. And people will miss cancel if they
>> >> don't look for it. They will miss it too if they use Eo_Promise too and
>> >> don't look for it.
>> >
>> > there';s a difference. if it's a std promise then they expect it to work a
>> > certain way. if its an efl one they need to learn its api and behaviour.
>> > they will find the features.
>>
>> We can't be arguing C++ API because users won't read a header file.
>> This is not reasonable. Do we expect C developers to read
>> documentation, or at least doxygen docs?
>
> we do expect them to read. though in my experience few actually read a header
> file. docs is an expectation.
>
> but the issue here is of masquerading with a feature that will never work
> (wait). it'll always cause an exception. it'd just be best to look similar to 
> a
> future/promise and just be a different class.

I don't understand why you think we can't implement wait. The C++
standard doesn't expect it to work with a mainloop, but from another
thread. So it is very simple to implement it. When you instanciate a
promise, you do also create a mutex, a cond and add a first
then/cancel couple that will just take that mutex, set the value and
broadcast on the cond. The future itself when instanciated will ref
count the promise and on the wait will take the mutex and wait on the
cond if the value is not there already. The only difference is that
use of wait in C++ will lead to dead lock if you use it in the same
thread, we will have a warning and throw an excepion in that case.
This is the only difference and I fail to see where you see a problem.
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 19/06/16 02:27, Carsten Haitzler wrote:
> On Fri, 17 Jun 2016 09:41:39 +0100 Tom Hacohen  said:
>
>> On 17/06/16 03:28, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen  said:
>>>
 On 03/06/16 20:17, Cedric BAIL wrote:
 
>>> also promises should become eo objects with event cb's
>>> so they work just like everything else. i can ref, unref, delete and
>>> whatever them like everything else.
>
> As said above, this does work. Example with event :
> eo_promise = efl_file_set(image, "toto.jpg", NULL);
> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>
> In this 3 lines, there is already 2 case in which that fail. First if,
> the object is done before the callback is set, data are lost and there
> is no way to get any event. Ofcourse, we can override the behavior of
> events on this eo_promise completely. Now let's imagine, that we
> actually do always store the events, so that everytime someone
> register a callback we can send the event. Still you can't auto del
> the object at any point in time, you have to force the user to
> implement the eo_del and to always provide both a then and cancel
> callback.
>
> Other possibility, it is an event on the object itself.
> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
> efl_file_set(image, "toto.jpg", NULL);
> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>
> Same again, this can not work. The first group of event handler,
> promise_callbacks1(), may actually be triggered by a previously
> running promise on the object, so you have to first forcefully stop
> the previous operation. This would add complexity. And still the
> second callback has the same issue as the previous case, if it is a
> normal eo event, it could have been triggered before any callback get
> registered and the event be lost... Same story short, doesn't work.
>

 I'm currently reading through the thread, and I didn't see anything
 mentioned about this other than a casual remark you made, so just wanted
 to make it crystal clear regarding implementing it as an Eo object.
 The whole point/magic of inheritance is that you can and are supposed to
 override functions if needed. Overriding callback add to call the
 callback immediately upon addition (if already done) is how I would
 implement promise callbacks. It's clean, easy and as intended. This is
 definitely not a problem.
>>>
>>> just for convenience i think having a special eo_promise_then(obj, cb1, cb2,
>>> data); may be best as its the simplest and is not pretending to ADD a cb in
>>> the name. it sets it explicitly. this needs special treatment like the eo
>>> event callbacks of course.
>>>
>>> but using an eo event is possible by override indeed, but here is the issue.
>>> you have to wait until either "then" or "else" or both are set. since you
>>> set one then set another... you will have to always add one of them as a
>>> NULL or dummy cb just to do this. having a single method/func set both
>>> makes more sense. in fact this likely needs manual binding/.handling per
>>> language anyway. i'm really only thinking of eo events for EXTRA features
>>> like progress events on a promise that happen before the success/fail cb's
>>> above.
>>>
>>>
>>
>> This is explained better in my reply to the initial post of this thread,
>> but essentially you don't. What you are missing, and why life-cycle can
>> be pretty broken, and why this doesn't matter is that you can register a
>> few "then" and a few "cancel" in promises. That is actually the power of
>> promises, that you can chain them and use them for a few things. This is
>> dealt with nicely. See the post I mentioned.
>
> register a few then/else cb's on the same promise? at least that should not be
> possible (it should not work). on;y one else/then cb (zero or one of each).
>
>

Why not? Anyhow, as I said, that is very common in js land and how race 
and all are probably implemented.

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 19/06/16 02:24, Carsten Haitzler wrote:
> On Fri, 17 Jun 2016 09:21:13 +0100 Tom Hacohen  said:
>
>> On 17/06/16 03:21, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen  said:
>>>
 On 16/06/16 10:47, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André 
> said:
>
>
 The ON_HOLD flag, now called efl_event_processed_get/set() is a better
 approach to stop processing events.
>>>
>>> That is off topic, but seriously something we should consider asap if
>>> we want to drop the return type of event. I have not any case in mind
>>> where returning EINA_FALSE make sense. Should we drop it ?
>>>
>>
>> I am also thinking we should drop it.
>> Pretty sure the few places that return EINA_FALSE right now are actually
>> mistakes and sources of bugs.
>
> i think so too. drop the return.
>

 The return is mega useful, though I'm open to implementing it
 differently. The return is there so you can filter events. We currently
 have things like "on_hold" in input events to mark an event has been
 processed and should stop propagating, but the return lets you stop the
 callback. I guess we can change it to be "eo_event_callback_stop(obj)".
>>>
>>> but the thing is.. we don't want to stop the callback. well not where hold
>>> is used. you want to still get the cb but put on hold any actions.like
>>> calling the clicked callback. you still need the event to get the matching
>>> mouse up fro the mouse down for example, but since you started a drag,
>>> after n move events the mouse up (and future moves) should not be acted on.
>>>
 Btw, it shouldn't be a bool, there are defines for the return values. I
 should have typedeffed the type. I'm open to changing to
 eo_event_callback_stop though, just let me know.

 Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
 write. :)
>>>
>>> see above. the only use case we have to date is the above and a return just
>>> doesn't do it. you need to have a modified event go through afterwards.
>>>
>>> i did the return true/false for ecore events for pass through. over the
>>> years i have recognized this as a mistake. it's more pain than gain.
>>
>> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels
>> better for making event propagation to stop, but I do like being able to
>> stop it. It is used in the EFL, I just got the name wrong,
>> EO_CALLBACK_STOP. :)
>> It's useful for text filtering iirc, to make it stop processing the
>> filter if one has already failed. It is used and useful.
>
> considering the rarity of this need... i think eo_event_callback_stop() seems
> fine to me. it means the 99% case of passing it on is less likely to have an
> error in it by returning the wrong value (or someone not returning at all and
> they either dont have warnings for that in their compiler or... they have so
> many they miss this warning) :)
>


I need to take a bath after this change, but anyhow: done. :)

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

On Sun, 19 Jun 2016 21:21:57 -0300 Felipe Magno de Almeida
 wrote:

> On Sun, Jun 19, 2016 at 9:19 PM, David Seikel 
> wrote:
> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> >  wrote:
> >
> >> > coroutines are a wrong match. just because they run code later
> >> > doesn't mean they match a promise.
> >>
> >> it is the _perfect_ match IMO. Probably we should ask someone
> >> that actually uses Lua about it, instead of guessing.
> >
> > I use Lua, but I've not been using anything that looks like
> > promises, so I can't comment.
> 
> Have you used coroutines?

I'm trying to stay out of this bun fight.  ;-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler  wrote:
> On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
>  said:
>
>> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler 
>> wrote:
>> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
>> >  said:

[snip]

>> There will be wait. I'll implement it. It will throw an exception if it is
>> called from the mainloop thread. And people will miss cancel if they
>> don't look for it. They will miss it too if they use Eo_Promise too and
>> don't look for it.
>
> there';s a difference. if it's a std promise then they expect it to work a
> certain way. if its an efl one they need to learn its api and behaviour. they
> will find the features.

We can't be arguing C++ API because users won't read a header file.
This is not reasonable. Do we expect C developers to read
documentation, or at least doxygen docs?

> and when they get the exceptions thrown they'll complain that it's broken.
> there is an api exposed that is meant to work, but does not.

They will be glad their application didn't deadlock. std::future
can deadlock too on wait. At least ours will warn then. Also,
std::future might throw the same exception if the same
thread tries to lock the same non-recursive mutex. Exceptions
exist to interrupt a function to finish which can't guarantee
its post-conditions, which would be exactly the case.

> lua has no syntax at all for promises. coroutines are nothing of the sort.

I have implemented coroutines for Lua already, you can check it at
https://github.com/expertisesolutions/ghtv-ncl-player/blob/master/src/ncl/lua/
It is a partial implementation I wrote of the interactivity system of the
Brazilian Digital TV system I did back in 2012.
I'm not unfamiliar with co-routines. I know how they work and I know
how to implement them and how to extend/sandbox it.

The Lua manual shows that a coroutine object is returned, that
object can have a cancel function in it.
https://www.lua.org/manual/5.3/manual.html#2.6

And to my knowledge, I don't see any problems with using promises
and adding a cancel function to the coroutine object.

>> Why don't we just generate all eina containers too? We could be
>> arguing exactly the same thing.
>
> because promises are objects with ref counting, callbacks, lifespan etc. they
> are being USEd to replace objects like job and timers (as a timeout). making
> lists objects would be a huge memory footprint jump. not so with eina_promise
> vs an eo version of it. they also are not used and stored 1's of times in
> an app unlike let's say eina lists.

IMO, we aren't because each language uses containers in a very different
way. And if performance wasn't an issue, I'd still argue the same thing for
manually binding containers as well. They _have_ to be manually bound
because they are used in very different ways and _should not_ be blindly
OO-based.

>> Who cares? It is dynamic typing. How do you even _tell_ it is not a
>> Promise? It will work the same, quack the same and even smell the
>> same.
>
> it depends if you return it or have to create it and pass it in. if its create
> and pass in like is used in efl_model and now fileselector then you have to
> CREATE the correct type in your js code to pass in.

Then the binding just calls then on the promise and use that for the
Eina/Eo Promise Owner. Though, IMO, we could just prohibit passing
@in promises in EFL API and that's it. They would be an @out/return
only. But we can just as well create an Promise_Owner from a normal
promise as well.

[snip]

>> I don't get why promises should have a concept of yield? Yield is a concept
>> of coroutines. It means it is not ready to make progress and something
>
> you are talking of using coroutines as promises. if you want a cancel on a
> coroutine .. that is exactly what you are talking about. the coroutine
> represnets the promise. same thing.

If they are the same thing, how are they so different that you think they
can't even be translated to that?

>> else should run in its place. Promises can't have yield because promises
>> make no promise (pun intended) of that. However a co-routine _using_
>> promises know when progress can be made when the promise tells them.
>>
>> > coroutines have no concept of fail, cancel, progress.
>>
>> It does for fail, as I've explained in the last email. For cancel it is just
>
> where? the lua docs on coroutines show no failure. just run until completion 
> or
> a yield, then pick up where the yield left of if run again. there is no
> separation of success or failure segments of code in coroutines. promises
> explicitly want a difference.

Any Lua function can "throw" an error. A cancelation would be just an
error while calling a function that returns a promise.

>> a failure as well and asking for cancelation can be just a meta-method
>> on the couroutine. And progress can be just a function 

Re: [E-devel] promises...

[The Rasterman]

On Mon, 20 Jun 2016 08:10:43 +0930 Simon Lees  said:

> 
> 
> On 06/20/2016 07:52 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> >  said:
> > 
> >> On Sun, Jun 19, 2016 at 9:32 AM, Carsten Haitzler 
> >> wrote:
> >>> On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida
> >>>  said:
> >>
> >> [snip]
> >>
>  I have explained in the email exactly how they would be translated to C+
>  +, JS and Lua by _not_ being a object used directly by the user
>  translated automatically by Eolian. So I don't know what you mean. JS
>  will be used
> >>>
> >>> that is the ONLY way for them to work right. to be translated. have you
> >>> looked at c+ promises/futures in stdc++? there is no cancel for starters.
> >>> there are wait methods that we just don't support. you CAN'T map an
> >>> eina_promise or an eo_promise to c++ promises/futures. they are disjoint
> >>> sets.
> >>
> >> I don't know why you think that's the only way. First of all, if
> >> Eolian can generate,
> >> why then bindings writing manual code couldn't?
> >>
> >> I think you're confusing by thinking I have to instantiate a
> >> std::future/std::promise
> >> for this to be useful and/or used by C++ developers. future/promises are
> >> part of the STL, which means Standard _Template_ Library, so the concrete
> >> type doesn't have to one from the std:: namespace, I can create one myself
> >> and that will be used just the same. This is exactly how all of eina is
> >> bound to C++ right now, I do not return a std::list, but a
> >> efl::eina::list, which
> >> _is_ a list container, i.e. it models the Container concept from the STL,
> >> however it has more push_back/insert/etc overloads that also accept
> >> a naked-pointer or std::unique_ptr for transferring ownership, and treat
> >> value_type as T and not T* (it is like the boost.ptr_container library).
> > 
> > and having an efl::promise and efl::future will miss features from the std
> > one's like wait. someone used to the std ones will be confused. as to their
> > usage.. someone used to th std ones will not know they can cancel.
> > 
> 
> the std library isn't the be all and end all of C++, there is really 3
> library’s and they all implement this type of thing in there own way,
> one being the std lib, the second being boost and the third being Qt. A

we standardized on std. eina types are mapped to that. we had this discussion
long ago. the lstd futures/promises don't map to efl's promises. they are a
disjoint set. so either way our promises need to be a different class.

> reasonable proportion of C++ programmers don't use the standard library
> in there code because it doesn't provide as good implementations as
> either Qt or boost. When I was writing C++ we would never use the std
> libs we used QStrings and QLists because both provided a significantly
> better api then the standard library (I have written command line
> applications that depend on the Qt equivalent of eina because its 100x
> quicker and easier then using the standard libs. So from this point of
> view efl having its own promise class rather then using the standard
> libraries with a different api is no big issue. For data types like

we have to do it anyway because it doesn't map to std promise/futures. that was
my point. if we have to create classes anyway for most languages we may as well
just have an efl promise class and make them an object that we completely
control the api of across multiple bindings. it then has all the features of
the core efl promise and maps 1:1.

> lists etc its nice if you can convert from eina ones to std ones but for
> something like a promise or a thread concept or anything like that I
> don't think its necessary and if you can swap a standard promise for a
> efl one at the moment thats a nice bonus but I wouldn't even call it
> essential.

that's why i said... we just have an efl promise class. then the argument of
having to manually bind/map them per language begins to fall apart. just auto
bind them like the rest of efl.

> -- 
> 
> Simon Lees (Simotek)http://simotek.net
> 
> Emergency Update Team   keybase.io/simotek
> SUSE LinuxAdeliade Australia, UTC+9:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 

Re: [E-devel] promises...

[The Rasterman]

On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
 said:

> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler 
> wrote:
> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
> >  said:
> 
> [snip]
> 
> >> I think you're confusing by thinking I have to instantiate a
> >> std::future/std::promise
> >> for this to be useful and/or used by C++ developers. future/promises are
> >> part of the STL, which means Standard _Template_ Library, so the concrete
> >> type doesn't have to one from the std:: namespace, I can create one myself
> >> and that will be used just the same. This is exactly how all of eina is
> >> bound to C++ right now, I do not return a std::list, but a
> >> efl::eina::list, which
> >> _is_ a list container, i.e. it models the Container concept from the STL,
> >> however it has more push_back/insert/etc overloads that also accept
> >> a naked-pointer or std::unique_ptr for transferring ownership, and treat
> >> value_type as T and not T* (it is like the boost.ptr_container library).
> >
> > and having an efl::promise and efl::future will miss features from the std
> > one's like wait. someone used to the std ones will be confused. as to their
> > usage.. someone used to th std ones will not know they can cancel.
> 
> There will be wait. I'll implement it. It will throw an exception if it is
> called from the mainloop thread. And people will miss cancel if they
> don't look for it. They will miss it too if they use Eo_Promise too and
> don't look for it.

there';s a difference. if it's a std promise then they expect it to work a
certain way. if its an efl one they need to learn its api and behaviour. they
will find the features.

> > you have created your own promise type effectively. it may be similar to the
> > std ones, but it is a new object in its own right. that is exactly what i
> > said. and that is why i was saying that efl promises in all languages will
> > be special efl promises as efl promises are a disjoint set from just about
> > every other promise/future thing i looked up.
> 
> It doesn't matter it is a disjoint set as long as we have a powerful
> primitive, because we can translate that to every other language.

we can't to lua - it has nothing even close. we have to build it specifically.

> If, however, we impose a broken concept for that language, nobody
> is going to use it. That means events for asynchronous operations
> and ad-hoc implementation of it for every asynchronous operation.
> 
> >> Spite of it being a different type and having some differences, it works
> >> exactly as the user expects and can be used with all STL algorithms.
> >
> > wait doesn't work.
> 
> It will.

and when they get the exceptions thrown they'll complain that it's broken.
there is an api exposed that is meant to work, but does not.

> >> That's exactly how efl::eina::future/promise will work. We will have
> >> a efl::eina::future and efl::eina::promise class templates that will
> >> wrap the Eina/Eo_Future* handle/object. They will not, and cannot,
> >> be exposed directly, specially for C++ where it will be a template and
> >> not a C++ class, otherwise we will have void* all over the place and
> >> that would _really_ _really_ suck in C++ to use void*.
> >
> > that is probably something eolian_gen needs to know - iv you accept or
> > return void *'s it needs to generate a template for that class.
> 
> That is _exactly_ the same as manually binding. I don't see how that
> is any different. Besides, there are difference of syntax from C++, JS
> and Lua, so makiing it a single class automatically generated is not
> better at all in this case.

lua has no syntax at all for promises. coroutines are nothing of the sort.

> Why don't we just generate all eina containers too? We could be
> arguing exactly the same thing.

because promises are objects with ref counting, callbacks, lifespan etc. they
are being USEd to replace objects like job and timers (as a timeout). making
lists objects would be a huge memory footprint jump. not so with eina_promise
vs an eo version of it. they also are not used and stored 1's of times in
an app unlike let's say eina lists.

> >> For JS it will be exactlly the same, it will not return a new Promise(),
> >> but one that will be manually bound to have the same API + things
> >> we extended it with. The class will be a 'thenable'
> >
> > that is exactly what i said. and so it's now some Efl.Promise class, not a
> > Promise.
> 
> Who cares? It is dynamic typing. How do you even _tell_ it is not a
> Promise? It will work the same, quack the same and even smell the
> same.

it depends if you return it or have to create it and pass it in. if its create
and pass in like is used in efl_model and now fileselector then you have to
CREATE the correct type in your js code to pass in.

> >> 

Re: [E-devel] promises...

[Felipe Magno de Almeida]

Small correction:

On Jun 19, 2016 9:04 PM, "Felipe Magno de Almeida"
 wrote:
>

[snip]

> That's not the job of promises, the job of promises is being a primitive
> that bindings can abstract it. If you make it a uber_super_solution_for_async,
> then obviously it *can*(correction: can't) be used as primitive. The way it 
> is right now it is
> the perfect well-defined solution for being a primitive for all the bindings
> we just discussed.

* can't

[snip]
--
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sun, Jun 19, 2016 at 9:19 PM, David Seikel  wrote:
> On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
>  wrote:
>
>> > coroutines are a wrong match. just because they run code later
>> > doesn't mean they match a promise.
>>
>> it is the _perfect_ match IMO. Probably we should ask someone
>> that actually uses Lua about it, instead of guessing.
>
> I use Lua, but I've not been using anything that looks like promises,
> so I can't comment.

Have you used coroutines?

> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
 wrote:

> > coroutines are a wrong match. just because they run code later
> > doesn't mean they match a promise.  
> 
> it is the _perfect_ match IMO. Probably we should ask someone
> that actually uses Lua about it, instead of guessing.

I use Lua, but I've not been using anything that looks like promises,
so I can't comment.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler  wrote:
> On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
>  said:

[snip]

>> I think you're confusing by thinking I have to instantiate a
>> std::future/std::promise
>> for this to be useful and/or used by C++ developers. future/promises are
>> part of the STL, which means Standard _Template_ Library, so the concrete
>> type doesn't have to one from the std:: namespace, I can create one myself
>> and that will be used just the same. This is exactly how all of eina is
>> bound to C++ right now, I do not return a std::list, but a
>> efl::eina::list, which
>> _is_ a list container, i.e. it models the Container concept from the STL,
>> however it has more push_back/insert/etc overloads that also accept
>> a naked-pointer or std::unique_ptr for transferring ownership, and treat
>> value_type as T and not T* (it is like the boost.ptr_container library).
>
> and having an efl::promise and efl::future will miss features from the std
> one's like wait. someone used to the std ones will be confused. as to their
> usage.. someone used to th std ones will not know they can cancel.

There will be wait. I'll implement it. It will throw an exception if it is
called from the mainloop thread. And people will miss cancel if they
don't look for it. They will miss it too if they use Eo_Promise too and
don't look for it.

> you have created your own promise type effectively. it may be similar to the
> std ones, but it is a new object in its own right. that is exactly what i 
> said.
> and that is why i was saying that efl promises in all languages will be 
> special
> efl promises as efl promises are a disjoint set from just about every other
> promise/future thing i looked up.

It doesn't matter it is a disjoint set as long as we have a powerful
primitive, because we can translate that to every other language.
If, however, we impose a broken concept for that language, nobody
is going to use it. That means events for asynchronous operations
and ad-hoc implementation of it for every asynchronous operation.

>> Spite of it being a different type and having some differences, it works
>> exactly as the user expects and can be used with all STL algorithms.
>
> wait doesn't work.

It will.

>> That's exactly how efl::eina::future/promise will work. We will have
>> a efl::eina::future and efl::eina::promise class templates that will
>> wrap the Eina/Eo_Future* handle/object. They will not, and cannot,
>> be exposed directly, specially for C++ where it will be a template and
>> not a C++ class, otherwise we will have void* all over the place and
>> that would _really_ _really_ suck in C++ to use void*.
>
> that is probably something eolian_gen needs to know - iv you accept or return
> void *'s it needs to generate a template for that class.

That is _exactly_ the same as manually binding. I don't see how that
is any different. Besides, there are difference of syntax from C++, JS
and Lua, so makiing it a single class automatically generated is not
better at all in this case.

Why don't we just generate all eina containers too? We could be
arguing exactly the same thing.

>> For JS it will be exactlly the same, it will not return a new Promise(),
>> but one that will be manually bound to have the same API + things
>> we extended it with. The class will be a 'thenable'
>
> that is exactly what i said. and so it's now some Efl.Promise class, not a
> Promise.

Who cares? It is dynamic typing. How do you even _tell_ it is not a
Promise? It will work the same, quack the same and even smell the
same.

>> (https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve#Resolving_thenables_and_throwing_Errors)
>> and will
>> interoperate with normal JavaScript code that expects ECMAScript
>> Promises. So whoever uses our code will be able to cancel _and_
>> do the things they are used to with a Promise.
>>
>> It is true they are all different, however, over a solid, well-defined,
>> asynchronous primitive we can build all the translations.
>>
>> Lua is quite different, and IMO, that's what will make it even more
>> awesome. For this to work, the binding will just generate differently
>> when it sees a promise in the method, the generated method
>> will call a eina/eo_promise_then on the promise that the C function
>> will return with a callback notifying the current coroutine can be
>> scheduled to resume and it will do an immediately yield. We should
>> probably have a cancel function on couroutines as well in this case
>> so we can cancel the whole co-routine which will cancel the currently
>> pending promise. The cancel could resume the coroutine with a
>> lua_error, so the coroutine can clean itself if it needs.
>
> coroutines are BARELY a match for promises. they simply execute code later. 
> our
> promises have no concept of yield.

I don't get why promises should have a concept of yield? Yield is 

Re: [E-devel] promises...

[The Rasterman]

On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida
 said:

> On Sun, Jun 19, 2016 at 9:32 AM, Carsten Haitzler 
> wrote:
> > On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida
> >  said:
> 
> [snip]
> 
> >> I have explained in the email exactly how they would be translated to C++,
> >> JS and Lua by _not_ being a object used directly by the user translated
> >> automatically by Eolian. So I don't know what you mean. JS will be used
> >
> > that is the ONLY way for them to work right. to be translated. have you
> > looked at c+ promises/futures in stdc++? there is no cancel for starters.
> > there are wait methods that we just don't support. you CAN'T map an
> > eina_promise or an eo_promise to c++ promises/futures. they are disjoint
> > sets.
> 
> I don't know why you think that's the only way. First of all, if
> Eolian can generate,
> why then bindings writing manual code couldn't?
> 
> I think you're confusing by thinking I have to instantiate a
> std::future/std::promise
> for this to be useful and/or used by C++ developers. future/promises are
> part of the STL, which means Standard _Template_ Library, so the concrete
> type doesn't have to one from the std:: namespace, I can create one myself
> and that will be used just the same. This is exactly how all of eina is
> bound to C++ right now, I do not return a std::list, but a
> efl::eina::list, which
> _is_ a list container, i.e. it models the Container concept from the STL,
> however it has more push_back/insert/etc overloads that also accept
> a naked-pointer or std::unique_ptr for transferring ownership, and treat
> value_type as T and not T* (it is like the boost.ptr_container library).

and having an efl::promise and efl::future will miss features from the std
one's like wait. someone used to the std ones will be confused. as to their
usage.. someone used to th std ones will not know they can cancel.

you have created your own promise type effectively. it may be similar to the
std ones, but it is a new object in its own right. that is exactly what i said.
and that is why i was saying that efl promises in all languages will be special
efl promises as efl promises are a disjoint set from just about every other
promise/future thing i looked up.

> Spite of it being a different type and having some differences, it works
> exactly as the user expects and can be used with all STL algorithms.

wait doesn't work.

> That's exactly how efl::eina::future/promise will work. We will have
> a efl::eina::future and efl::eina::promise class templates that will
> wrap the Eina/Eo_Future* handle/object. They will not, and cannot,
> be exposed directly, specially for C++ where it will be a template and
> not a C++ class, otherwise we will have void* all over the place and
> that would _really_ _really_ suck in C++ to use void*.

that is probably something eolian_gen needs to know - iv you accept or return
void *'s it needs to generate a template for that class.

> For JS it will be exactlly the same, it will not return a new Promise(),
> but one that will be manually bound to have the same API + things
> we extended it with. The class will be a 'thenable'

that is exactly what i said. and so it's now some Efl.Promise class, not a
Promise.

> (https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve#Resolving_thenables_and_throwing_Errors)
> and will
> interoperate with normal JavaScript code that expects ECMAScript
> Promises. So whoever uses our code will be able to cancel _and_
> do the things they are used to with a Promise.
> 
> It is true they are all different, however, over a solid, well-defined,
> asynchronous primitive we can build all the translations.
> 
> Lua is quite different, and IMO, that's what will make it even more
> awesome. For this to work, the binding will just generate differently
> when it sees a promise in the method, the generated method
> will call a eina/eo_promise_then on the promise that the C function
> will return with a callback notifying the current coroutine can be
> scheduled to resume and it will do an immediately yield. We should
> probably have a cancel function on couroutines as well in this case
> so we can cancel the whole co-routine which will cancel the currently
> pending promise. The cancel could resume the coroutine with a
> lua_error, so the coroutine can clean itself if it needs.

coroutines are BARELY a match for promises. they simply execute code later. our
promises have no concept of yield. coroutines have no concept of fail, cancel,
progress. coroutines are a wrong match. just because they run code later
doesn't mean they match a promise. what eina_promise is is a far far far more
extensive blob of code that does not let you yield and pick up where you left
off. we would want to create fill promise objects in lua that actually match
what efl promises are.

> So, if you think some of 

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sun, Jun 19, 2016 at 9:32 AM, Carsten Haitzler  wrote:
> On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida
>  said:

[snip]

>> I have explained in the email exactly how they would be translated to C++,
>> JS and Lua by _not_ being a object used directly by the user translated
>> automatically by Eolian. So I don't know what you mean. JS will be used
>
> that is the ONLY way for them to work right. to be translated. have you looked
> at c+ promises/futures in stdc++? there is no cancel for starters. there are
> wait methods that we just don't support. you CAN'T map an eina_promise or an
> eo_promise to c++ promises/futures. they are disjoint sets.

I don't know why you think that's the only way. First of all, if
Eolian can generate,
why then bindings writing manual code couldn't?

I think you're confusing by thinking I have to instantiate a
std::future/std::promise
for this to be useful and/or used by C++ developers. future/promises are
part of the STL, which means Standard _Template_ Library, so the concrete
type doesn't have to one from the std:: namespace, I can create one myself
and that will be used just the same. This is exactly how all of eina is
bound to C++ right now, I do not return a std::list, but a
efl::eina::list, which
_is_ a list container, i.e. it models the Container concept from the STL,
however it has more push_back/insert/etc overloads that also accept
a naked-pointer or std::unique_ptr for transferring ownership, and treat
value_type as T and not T* (it is like the boost.ptr_container library).

Spite of it being a different type and having some differences, it works
exactly as the user expects and can be used with all STL algorithms.
That's exactly how efl::eina::future/promise will work. We will have
a efl::eina::future and efl::eina::promise class templates that will
wrap the Eina/Eo_Future* handle/object. They will not, and cannot,
be exposed directly, specially for C++ where it will be a template and
not a C++ class, otherwise we will have void* all over the place and
that would _really_ _really_ suck in C++ to use void*.

For JS it will be exactlly the same, it will not return a new Promise(),
but one that will be manually bound to have the same API + things
we extended it with. The class will be a 'thenable'
(https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve#Resolving_thenables_and_throwing_Errors)
and will
interoperate with normal JavaScript code that expects ECMAScript
Promises. So whoever uses our code will be able to cancel _and_
do the things they are used to with a Promise.

It is true they are all different, however, over a solid, well-defined,
asynchronous primitive we can build all the translations.

Lua is quite different, and IMO, that's what will make it even more
awesome. For this to work, the binding will just generate differently
when it sees a promise in the method, the generated method
will call a eina/eo_promise_then on the promise that the C function
will return with a callback notifying the current coroutine can be
scheduled to resume and it will do an immediately yield. We should
probably have a cancel function on couroutines as well in this case
so we can cancel the whole co-routine which will cancel the currently
pending promise. The cancel could resume the coroutine with a
lua_error, so the coroutine can clean itself if it needs.

So, if you think some of these methods will not work, you will have
to be more specific on why. Because to me, right now, that's the only
sensible solution if we really want people to use our bindings with
asynchronous operations.

[snip]

Kind regards,
-- 
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida
 said:

> On Sat, Jun 18, 2016 at 10:56 PM, Carsten Haitzler 
> wrote:
> > On Fri, 17 Jun 2016 11:12:51 -0300 Felipe Magno de Almeida
> >  said:
> >
> > felipe - look at eina promises then loo at stdc++ promise and futures. they
> > dont even match. js promises cant be canceled. lua doesn't even have the
> > idea of a promise. what we have in eina_promise doesn't translate to any
> > language native future/promise thing. it's very specifically an efl thing
> > and if we do it we need to embrace it as such and that's how it goes. it
> > LOOKs like many language native promise things but it's extended and efl
> > specific. that's the on;y way to use promises we have, otherwise we should
> > drop them entirely and do things only by obj + event cb's because this
> > problem space is just too fragmented with the lowest common denominator not
> > being even good enough for us (no cancel) but not even being enough for
> > other langs (c++ has wait - we don't)
> 
> I have explained in the email exactly how they would be translated to C++,
> JS and Lua by _not_ being a object used directly by the user translated
> automatically by Eolian. So I don't know what you mean. JS will be used

that is the ONLY way for them to work right. to be translated. have you looked
at c+ promises/futures in stdc++? there is no cancel for starters. there are
wait methods that we just don't support. you CAN'T map an eina_promise or an
eo_promise to c++ promises/futures. they are disjoint sets.

> exactly as JavaScript developers are used to, but they will have the option
> to cancel as well, and C++ will be able to wait on it or register a callback

how? where? without the promise being an object... how? because in js they are
promises. in c++ a promise and future are... objects.

> function. And for Lua exactly how I explained in the email below. Maybe you
> missed my answer to your reply in the bottom of the email,after my answer
> to Tom?

i saw you spoke about coroutines. but that is not what a promise is in efl.
there is a definite handle you have to have to be able to address it. lua have
NO promises themselves of any sort. nothing. there is nothing to even have a
cancel method on for example.

> > so as you said - then make promises full efl supported objects and they
> > appear so in every language and work the same way, as the only other option
> > is to drop them entirely.
> 
> I neveer said that. And for the reasons I explained below.

>> So, in the end, if we make Promises an Eo/Eolian
>> object with very well defined semantics, we get
>> a "normal class"* that works the same as an

yes - you said in c only - but we have to map what we have in c to other
languages. show me how a libstdc++ promise/future is able to be canceled? show
me. show me how a js promise does progress events 9without extending the class
to a special promise class of our own). show me the promises in lua, or futures
or anything even equivalent than can be canceled, listened to for success or
failure, even events.

> >> So, JP asked my opinion privately and he thought it would
> >> be better for me to paste what I replied here. I  didn't want
> >> to make this discussion longer, however I have to make
> >> these points explicit so we can move on. Sorry in advance
> >> for the huge email. So I'll paste my answer here and then
> >> make some considerations of other points afterwards:
> >>
> >> ""
> >> Hello JP,
> >>
> >> Now I see I should've voiced myself more in the discussion. But it has been
> >> too lengthy and too much things to do before and during the feature freeze,
> >> so I kinda absteined myself from it. Which was probably an error because
> >> now nobody knows my opinion on the matter.
> >>
> >> My personal stance on promises being Eo objects is that we're hammering
> >> things to be OOP more than it should. IMO, Promises are nothing more
> >> than a one-element-containers that warns when the value is available.
> >>
> >> It is not too much different from Eina_List/Eina_Array, etc. Could we
> >> make Eina containers Eo objects? We can, would it have benefits?
> >> It would. However, it is always a trade-off and the problems it brings
> >> would bigger than the benefits. Java does it and it works, but it slow
> >> and invites people to inherit classes in ways they can't possibly do
> >> because they, inadvertadly, break the class invariants by changing
> >> how the user interacts with the class (by overriding methods).
> >>
> >> I'm sure in C++, JavaScript and Lua they won't be used as an Eolian
> >> class at all, that's even why Kolesa has suggested that it should
> >> not even be an Eolian class (but be a Eo class implemented directly),
> >> that way people can't inherit from it and bindings don't have to
> >> special case the class, like we have to do for Eo.Base.
> >>
> >> Now, why classes shouldn't 

Re: [E-devel] promises...

[Felipe Magno de Almeida]

On Sat, Jun 18, 2016 at 10:56 PM, Carsten Haitzler  wrote:
> On Fri, 17 Jun 2016 11:12:51 -0300 Felipe Magno de Almeida
>  said:
>
> felipe - look at eina promises then loo at stdc++ promise and futures. they
> dont even match. js promises cant be canceled. lua doesn't even have the idea
> of a promise. what we have in eina_promise doesn't translate to any language
> native future/promise thing. it's very specifically an efl thing and if we do
> it we need to embrace it as such and that's how it goes. it LOOKs like many
> language native promise things but it's extended and efl specific. that's the
> on;y way to use promises we have, otherwise we should drop them entirely and 
> do
> things only by obj + event cb's because this problem space is just too
> fragmented with the lowest common denominator not being even good enough for 
> us
> (no cancel) but not even being enough for other langs (c++ has wait - we 
> don't)

I have explained in the email exactly how they would be translated to C++,
JS and Lua by _not_ being a object used directly by the user translated
automatically by Eolian. So I don't know what you mean. JS will be used
exactly as JavaScript developers are used to, but they will have the option
to cancel as well, and C++ will be able to wait on it or register a callback
function. And for Lua exactly how I explained in the email below. Maybe you
missed my answer to your reply in the bottom of the email,after my answer
to Tom?

> so as you said - then make promises full efl supported objects and they appear
> so in every language and work the same way, as the only other option is to
> drop them entirely.

I neveer said that. And for the reasons I explained below.

>> So, JP asked my opinion privately and he thought it would
>> be better for me to paste what I replied here. I  didn't want
>> to make this discussion longer, however I have to make
>> these points explicit so we can move on. Sorry in advance
>> for the huge email. So I'll paste my answer here and then
>> make some considerations of other points afterwards:
>>
>> ""
>> Hello JP,
>>
>> Now I see I should've voiced myself more in the discussion. But it has been
>> too lengthy and too much things to do before and during the feature freeze,
>> so I kinda absteined myself from it. Which was probably an error because
>> now nobody knows my opinion on the matter.
>>
>> My personal stance on promises being Eo objects is that we're hammering
>> things to be OOP more than it should. IMO, Promises are nothing more
>> than a one-element-containers that warns when the value is available.
>>
>> It is not too much different from Eina_List/Eina_Array, etc. Could we
>> make Eina containers Eo objects? We can, would it have benefits?
>> It would. However, it is always a trade-off and the problems it brings
>> would bigger than the benefits. Java does it and it works, but it slow
>> and invites people to inherit classes in ways they can't possibly do
>> because they, inadvertadly, break the class invariants by changing
>> how the user interacts with the class (by overriding methods).
>>
>> I'm sure in C++, JavaScript and Lua they won't be used as an Eolian
>> class at all, that's even why Kolesa has suggested that it should
>> not even be an Eolian class (but be a Eo class implemented directly),
>> that way people can't inherit from it and bindings don't have to
>> special case the class, like we have to do for Eo.Base.
>>
>> Now, why classes shouldn't generate Promise as an Eolian class?
>> Because it makes no sense and it is _not_ convenient to users.
>> Registering events? What does event have to do with anything?
>> And how do you chain promises like in JavaScript with events?
>> Well, you don't. And how about Lua? Why should Lua even
>> generate a Promise object? In Lua I'd expect the Promise
>> to be used to connect the Lua event loop with co-routines,
>> so the current execution would just get scheduled-out and
>> return execution when the Promise is now fulfilled.
>>
>> The idea that we're going to create the _uber_super_ Promise
>> class for all languages is, IMO, completely impossible. Each
>> language will have its own asynchronous-way to deal with
>> how values are going to be available in the future and which
>> syntax better conveys that concept. Promises in our API,
>> OTH, allow us to _talk_ about asynchronous operations
>> in a way that is well-defined and which bindings can rely
>> enough to do proper code generation without knowing
>> specific semantics of each asynchronous operations. That
>> is not possible with events per se, because bindings
>> don't know anything about them.
>>
>> However, making promises an Eo object is not a problem
>> per se, as long as we have _very_well_defined_
>> semantics for everything, it works exactly the same,
>> but, at the same time, to have very well defined
>> semantics we need to limit on how extensible everything
>> is, otherwise we just get 

Re: [E-devel] promises...

[The Rasterman]

On Fri, 17 Jun 2016 13:38:16 +0100 Tom Hacohen  said:

> On 16/06/16 22:55, Cedric BAIL wrote:
> > On Thu, Jun 16, 2016 at 12:11 PM, Tom Hacohen  wrote:
> >> On 03/06/16 07:42, Carsten Haitzler wrote:
> >>> ok. interacting with promises...
> >>>
> >>> these are just a mess.
> >>>
> >>> 1. the value thing is just odd.
> >>> 2. they are complex to set up inside our api (setting them up setting
> >>> cancel cb's and more)
> >>> 3. they totally screw with what eo and interfaces was all about - making
> >>> the api EASIER to use. promises make it harder.
> >>>
> >>> why harder? longer lines of code with more parameters and more special
> >>> casing... but the WORST...
> >>>
> >>>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
> >>>
> >>> that's a promise cb
> >>>
> >>>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
> >>>
> >>> and that's an event cb. they are different. eo events were meant to
> >>> simplify and unify our callback handling. to have a single cb signature.
> >>> now promises break that. this is just bad.
> >>>
> >>> i wasn't sold on promises. i was skeptical, but whatever... but now i am
> >>> seeing they are visibly making things worse. code is harder to write,
> >>> harder to read, harder to maintain, harder to get right. now we have
> >>> timeouts that cannot repeat. no - creating a new timer in the cb is not
> >>> repeating. it has to repeat with the "zero time" being the time when the
> >>> timer was ticked off, not "now".
> >>>
> >>> please - everyone. take a look at promises and how they are used. forget
> >>> all of the "but node.js has them" and all the "i can chain promises" and
> >>> so on. the BASIC usage of them is harder now in efl.
> >>>
> >>> what to do? well... minimize their use for one. do not use them unless you
> >>> ABSOLUTELY HAVE TO. also promises should become eo objects with event
> >>> cb's so they work just like everything else. i can ref, unref, delete and
> >>> whatever them like everything else.
> >>>
> >>> right now i think promises are just not in a shape to use or ship. they
> >>> need a lot more work. i think we need to drop them for efl 1.18 and defer
> >>> for efl 2.0
> >>
> >> Guys, you bored me to death with this thread. I replied to what looked
> >> like it needed attention, but please let me know if there's anything
> >> specific I missed that warrants my reply.
> >>
> >> I would like to add my take on promises too. As you may remember, I've
> >> objected to promises from the start. I just didn't see a sensible way of
> >> implementing them back then, and unfortunately, even after they've been
> >> implemented, I still don't think they are done nicely.
> >
> > Being against promise, is only advocating for no asynchrone behavior
> > in Efl. This is a position we can't take. So either you have a better
> > pattern to handle asynchronous behavior and synchronisation or we have
> > to provide promise. Objecting to promise is clearly not helping
> > anything here.
> >
> 
> This is FUD and raster called you out on it a few times already, please 
> stop stating it as fact all over the place, because it's anything but. 
> You can say "in my opinion it's better to use promises", but that's as 
> far as I'll go.
> 
> > 
> >
> >> Lets start with life-cycle: Eo is great, and I think using Eo is the
> >> right way to go, but unfortunately that doesn't solve our life-cycle
> >> issue. When do promises die?
> >>
> >> p = efl_file_set()...
> >> // Delete here if file has been set?
> >> promise_then_add(p, cb)
> >> // Delete here if file has been set?
> >> promise_then_add(p, cb2);
> >> // Delete here if file has been set?
> >> ... // a million years into the future
> >> // Delete here if file has been set?
> >>
> >> There is just no sensible way to do it automatically. You will *always*
> >> have to unref, so following the above example:
> >>
> >> p = efl_file_set()
> >> ... // All of the code before
> >> eo_del(p); // It'll only die here
> >>
> >> Which won't work because then ignoring efl_file_set's output won't be
> >> allowed.
> >>
> >> The only sensible way of doing it, I guess, is to force a wrapper of
> >> some sort, so the code above becomes:
> >> p = eo_ref(efl_file_set());
> >> ... // Code from before
> >> eo_del(p);
> >
> > Amazing, we are more or less back to my point. Except that eo_del is
> > now to be used. The problem is that this break things, first you loose
> > the parent relationship on promise. So if that was used to actually do
> > something useful on its lifecycle, you can't anymore. Second problem,
> > you have to do eo_del only once you have actually sure you will never
> > cancel that said promise. Otherwise how could you still have a handler
> > on it somewhere ? If user don't get confused by the fact that they can
> > stil do an eo_promise_cancel on a promise that has been eo_del...
> >
> > So if you have to delay eo_del by the time you actually have
> > cancel/then, hum, 

Re: [E-devel] promises...

[The Rasterman]

On Fri, 17 Jun 2016 09:41:39 +0100 Tom Hacohen  said:

> On 17/06/16 03:28, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen  said:
> >
> >> On 03/06/16 20:17, Cedric BAIL wrote:
> >> 
> > also promises should become eo objects with event cb's
> > so they work just like everything else. i can ref, unref, delete and
> > whatever them like everything else.
> >>>
> >>> As said above, this does work. Example with event :
> >>> eo_promise = efl_file_set(image, "toto.jpg", NULL);
> >>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
> >>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
> >>>
> >>> In this 3 lines, there is already 2 case in which that fail. First if,
> >>> the object is done before the callback is set, data are lost and there
> >>> is no way to get any event. Ofcourse, we can override the behavior of
> >>> events on this eo_promise completely. Now let's imagine, that we
> >>> actually do always store the events, so that everytime someone
> >>> register a callback we can send the event. Still you can't auto del
> >>> the object at any point in time, you have to force the user to
> >>> implement the eo_del and to always provide both a then and cancel
> >>> callback.
> >>>
> >>> Other possibility, it is an event on the object itself.
> >>> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
> >>> efl_file_set(image, "toto.jpg", NULL);
> >>> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
> >>>
> >>> Same again, this can not work. The first group of event handler,
> >>> promise_callbacks1(), may actually be triggered by a previously
> >>> running promise on the object, so you have to first forcefully stop
> >>> the previous operation. This would add complexity. And still the
> >>> second callback has the same issue as the previous case, if it is a
> >>> normal eo event, it could have been triggered before any callback get
> >>> registered and the event be lost... Same story short, doesn't work.
> >>>
> >>
> >> I'm currently reading through the thread, and I didn't see anything
> >> mentioned about this other than a casual remark you made, so just wanted
> >> to make it crystal clear regarding implementing it as an Eo object.
> >> The whole point/magic of inheritance is that you can and are supposed to
> >> override functions if needed. Overriding callback add to call the
> >> callback immediately upon addition (if already done) is how I would
> >> implement promise callbacks. It's clean, easy and as intended. This is
> >> definitely not a problem.
> >
> > just for convenience i think having a special eo_promise_then(obj, cb1, cb2,
> > data); may be best as its the simplest and is not pretending to ADD a cb in
> > the name. it sets it explicitly. this needs special treatment like the eo
> > event callbacks of course.
> >
> > but using an eo event is possible by override indeed, but here is the issue.
> > you have to wait until either "then" or "else" or both are set. since you
> > set one then set another... you will have to always add one of them as a
> > NULL or dummy cb just to do this. having a single method/func set both
> > makes more sense. in fact this likely needs manual binding/.handling per
> > language anyway. i'm really only thinking of eo events for EXTRA features
> > like progress events on a promise that happen before the success/fail cb's
> > above.
> >
> >
> 
> This is explained better in my reply to the initial post of this thread, 
> but essentially you don't. What you are missing, and why life-cycle can 
> be pretty broken, and why this doesn't matter is that you can register a 
> few "then" and a few "cancel" in promises. That is actually the power of 
> promises, that you can chain them and use them for a few things. This is 
> dealt with nicely. See the post I mentioned.

register a few then/else cb's on the same promise? at least that should not be
possible (it should not work). on;y one else/then cb (zero or one of each).


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen  said:

> On 17/06/16 03:53, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  said:
> >
> >> Lets start with life-cycle: Eo is great, and I think using Eo is the
> >> right way to go, but unfortunately that doesn't solve our life-cycle
> >> issue. When do promises die?
> >>
> >> p = efl_file_set()...
> >> // Delete here if file has been set?
> >> promise_then_add(p, cb)
> >> // Delete here if file has been set?
> >> promise_then_add(p, cb2);
> >> // Delete here if file has been set?
> >> ... // a million years into the future
> >> // Delete here if file has been set?
> >
> > the way i see it is you need to set both then and else at the same time so
> >
> >   p = efl_file_set()
> >   eo_promise_then(p, sucess_cb, fail_cb, NULL);
> >   // p may be deleted at this point since on success or failure it is
> > deleted // do not depend on p after you have set then/else cb's. ensure if
> > you need to // access the cb that you add a DEL event cb to the promise to
> > track it OR if // you HAVE to have it then add an eo_ref(p) before
> > eo_promise_then()
> 
> Unfortunately, I don't think that works well in real life. It'll be a 
> source of many bugs. The problem is that:
> p = ...
> eo_promise_then(...)
> eo_promise_then(...)

we have eoid to help here... but who would ad 2 then's. we should have the 2n'd
then be an error so it'll ERR() saying then is set twice. then the programmer
gets that message every time their code runs and they know to not do it and
sometimes if the promise is deleted eoid will ten barf on the id, but you'll
keep working.

make the then only be ae to set cb's once at all. problem solved.

> Will work in many case, until it doesn't sometime when we change 
> something internally, or when the stars align just right and the promise 
> evaluates immediately. This is very dangerous. This is more common than 
> you think, and will become even more common. In JS, the usage often 
> looks like:
> p.then(...).then(efl_provided_helper_cb).then(other_efl_cb).
> 
> >
> >> There is just no sensible way to do it automatically. You will *always*
> >> have to unref, so following the above example:
> >>
> >> p = efl_file_set()
> >> ... // All of the code before
> >> eo_del(p); // It'll only die here
> >>
> >> Which won't work because then ignoring efl_file_set's output won't be
> >> allowed.
> >
> > well that's kind of the problem. with no then/else the promise has to stay
> > around forever holding the return value. you can't ignore it if its a
> > return. if it's
> >
> >   p = eo_add(NULL, PROMISE);
> >   // do aother promise setup here like
> >   eo_promise_then(p, done_cb, NULL, NULL);
> >   elf_file_set(obj, file, key, );
> >
> > then it can set up the promise in efl_file_set. if you do
> >
> >   efl_file_set(obj, file, key, NULL);
> >
> > then we say "we don't care about the async result". perhaps it can now be
> > sync by default if you do this?
> 
> Look at my suggestion below, I already solved this problem.
> 
> >
> >> The only sensible way of doing it, I guess, is to force a wrapper of
> >> some sort, so the code above becomes:
> >> p = eo_ref(efl_file_set());
> >> ... // Code from before
> >> eo_del(p);
> >>
> >> Or probably for extra safety (like marking the promise was actually
> >> used, and not just implicitly with a ref, this will allow us to block
> >> then/cancel registration and be more safe).
> >>
> >> p = efl_promise_use(efl_file_set());
> >> ... // Code from before
> >> eo_del(p);
> >>
> >> efl_promise_use will set a flag in the promise so that
> >> p = efl_file_set();
> >> promise_then_add(p); // This will fail because the flag wasn't set.
> >>
> >> So that's safe and probably the way to go. This will let us manage
> >> life-cycle correctly.
> >
> > i think that's more complex than the above i suggest. the problem is if you
> > pass in a promise... this now affects all of our file_set or any api that
> > can or should be async.
> >
> > as i said... i don't think we need a promise on these objects. we already
> > have an object to store the value/state of the load. it can already call
> > event cb's when these actions succeed or fail. we have done this with
> > preload for years already. if you do another file_set it does cancel the
> > previous one by definition (the only q is if that means you have to call a
> > load fail callback of some sort).
> >
> > this is what i mean by "let's not use promises here because at this stage
> > they do not help, just cause more work, complexity etc.".
> 
> I 100% agree on this, we don't need to use promise for file_set! Using 
> file set was just an example though for the life-cycle issue. The 
> life-cycle is the problem I was addressing here, and I don't think it's 
> solved in any way but my last example.

i dislike making people have to del their promises when they can be taken care
of by themselves. look at timeouts and jobs. 

Re: [E-devel] promises...

[The Rasterman]

On Fri, 17 Jun 2016 11:12:51 -0300 Felipe Magno de Almeida
 said:

felipe - look at eina promises then loo at stdc++ promise and futures. they
dont even match. js promises cant be canceled. lua doesn't even have the idea
of a promise. what we have in eina_promise doesn't translate to any language
native future/promise thing. it's very specifically an efl thing and if we do
it we need to embrace it as such and that's how it goes. it LOOKs like many
language native promise things but it's extended and efl specific. that's the
on;y way to use promises we have, otherwise we should drop them entirely and do
things only by obj + event cb's because this problem space is just too
fragmented with the lowest common denominator not being even good enough for us
(no cancel) but not even being enough for other langs (c++ has wait - we don't)

so as you said - then make promises full efl supported objects and they appear
so in every language and work the same way, as the only other option is to
drop them entirely.

> So, JP asked my opinion privately and he thought it would
> be better for me to paste what I replied here. I  didn't want
> to make this discussion longer, however I have to make
> these points explicit so we can move on. Sorry in advance
> for the huge email. So I'll paste my answer here and then
> make some considerations of other points afterwards:
> 
> ""
> Hello JP,
> 
> Now I see I should've voiced myself more in the discussion. But it has been
> too lengthy and too much things to do before and during the feature freeze,
> so I kinda absteined myself from it. Which was probably an error because
> now nobody knows my opinion on the matter.
> 
> My personal stance on promises being Eo objects is that we're hammering
> things to be OOP more than it should. IMO, Promises are nothing more
> than a one-element-containers that warns when the value is available.
> 
> It is not too much different from Eina_List/Eina_Array, etc. Could we
> make Eina containers Eo objects? We can, would it have benefits?
> It would. However, it is always a trade-off and the problems it brings
> would bigger than the benefits. Java does it and it works, but it slow
> and invites people to inherit classes in ways they can't possibly do
> because they, inadvertadly, break the class invariants by changing
> how the user interacts with the class (by overriding methods).
> 
> I'm sure in C++, JavaScript and Lua they won't be used as an Eolian
> class at all, that's even why Kolesa has suggested that it should
> not even be an Eolian class (but be a Eo class implemented directly),
> that way people can't inherit from it and bindings don't have to
> special case the class, like we have to do for Eo.Base.
> 
> Now, why classes shouldn't generate Promise as an Eolian class?
> Because it makes no sense and it is _not_ convenient to users.
> Registering events? What does event have to do with anything?
> And how do you chain promises like in JavaScript with events?
> Well, you don't. And how about Lua? Why should Lua even
> generate a Promise object? In Lua I'd expect the Promise
> to be used to connect the Lua event loop with co-routines,
> so the current execution would just get scheduled-out and
> return execution when the Promise is now fulfilled.
> 
> The idea that we're going to create the _uber_super_ Promise
> class for all languages is, IMO, completely impossible. Each
> language will have its own asynchronous-way to deal with
> how values are going to be available in the future and which
> syntax better conveys that concept. Promises in our API,
> OTH, allow us to _talk_ about asynchronous operations
> in a way that is well-defined and which bindings can rely
> enough to do proper code generation without knowing
> specific semantics of each asynchronous operations. That
> is not possible with events per se, because bindings
> don't know anything about them.
> 
> However, making promises an Eo object is not a problem
> per se, as long as we have _very_well_defined_
> semantics for everything, it works exactly the same,
> but, at the same time, to have very well defined
> semantics we need to limit on how extensible everything
> is, otherwise we just get normal events again and
> that is not well-defined enough to be translatable
> properly to every language.
> 
> So, in the end, if we make Promises an Eo/Eolian
> object with very well defined semantics, we get
> a "normal class"* that works the same as an
> Eina_Promise, but uses the Eo syntax
> for things on C (only on C!), and with that we
> start paying for things that doesn't seem
> to make sense IMO, such as the cost of
> late binding in Eo; the cost of allocating
> and instantiating a Eo object; etc. Without
> reaping any benefits. And, IMO, if asynchronous
> operations are to be _really_ used in EFL, we
> need promises to be _fast_. Asynchronous
> operations already have a inherent cost of
> having to use heap memory where synchronous
> 

Re: [E-devel] promises...

[The Rasterman]

On Fri, 17 Jun 2016 09:21:13 +0100 Tom Hacohen  said:

> On 17/06/16 03:21, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen  said:
> >
> >> On 16/06/16 10:47, Carsten Haitzler wrote:
> >>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André 
> >>> said:
> >>>
> >>>
> >> The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> >> approach to stop processing events.
> >
> > That is off topic, but seriously something we should consider asap if
> > we want to drop the return type of event. I have not any case in mind
> > where returning EINA_FALSE make sense. Should we drop it ?
> >
> 
>  I am also thinking we should drop it.
>  Pretty sure the few places that return EINA_FALSE right now are actually
>  mistakes and sources of bugs.
> >>>
> >>> i think so too. drop the return.
> >>>
> >>
> >> The return is mega useful, though I'm open to implementing it
> >> differently. The return is there so you can filter events. We currently
> >> have things like "on_hold" in input events to mark an event has been
> >> processed and should stop propagating, but the return lets you stop the
> >> callback. I guess we can change it to be "eo_event_callback_stop(obj)".
> >
> > but the thing is.. we don't want to stop the callback. well not where hold
> > is used. you want to still get the cb but put on hold any actions.like
> > calling the clicked callback. you still need the event to get the matching
> > mouse up fro the mouse down for example, but since you started a drag,
> > after n move events the mouse up (and future moves) should not be acted on.
> >
> >> Btw, it shouldn't be a bool, there are defines for the return values. I
> >> should have typedeffed the type. I'm open to changing to
> >> eo_event_callback_stop though, just let me know.
> >>
> >> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
> >> write. :)
> >
> > see above. the only use case we have to date is the above and a return just
> > doesn't do it. you need to have a modified event go through afterwards.
> >
> > i did the return true/false for ecore events for pass through. over the
> > years i have recognized this as a mistake. it's more pain than gain.
> 
> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels 
> better for making event propagation to stop, but I do like being able to 
> stop it. It is used in the EFL, I just got the name wrong, 
> EO_CALLBACK_STOP. :)
> It's useful for text filtering iirc, to make it stop processing the 
> filter if one has already failed. It is used and useful.

considering the rarity of this need... i think eo_event_callback_stop() seems
fine to me. it means the 99% case of passing it on is less likely to have an
error in it by returning the wrong value (or someone not returning at all and
they either dont have warnings for that in their compiler or... they have so
many they miss this warning) :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

So, JP asked my opinion privately and he thought it would
be better for me to paste what I replied here. I  didn't want
to make this discussion longer, however I have to make
these points explicit so we can move on. Sorry in advance
for the huge email. So I'll paste my answer here and then
make some considerations of other points afterwards:

""
Hello JP,

Now I see I should've voiced myself more in the discussion. But it has been
too lengthy and too much things to do before and during the feature freeze,
so I kinda absteined myself from it. Which was probably an error because
now nobody knows my opinion on the matter.

My personal stance on promises being Eo objects is that we're hammering
things to be OOP more than it should. IMO, Promises are nothing more
than a one-element-containers that warns when the value is available.

It is not too much different from Eina_List/Eina_Array, etc. Could we
make Eina containers Eo objects? We can, would it have benefits?
It would. However, it is always a trade-off and the problems it brings
would bigger than the benefits. Java does it and it works, but it slow
and invites people to inherit classes in ways they can't possibly do
because they, inadvertadly, break the class invariants by changing
how the user interacts with the class (by overriding methods).

I'm sure in C++, JavaScript and Lua they won't be used as an Eolian
class at all, that's even why Kolesa has suggested that it should
not even be an Eolian class (but be a Eo class implemented directly),
that way people can't inherit from it and bindings don't have to
special case the class, like we have to do for Eo.Base.

Now, why classes shouldn't generate Promise as an Eolian class?
Because it makes no sense and it is _not_ convenient to users.
Registering events? What does event have to do with anything?
And how do you chain promises like in JavaScript with events?
Well, you don't. And how about Lua? Why should Lua even
generate a Promise object? In Lua I'd expect the Promise
to be used to connect the Lua event loop with co-routines,
so the current execution would just get scheduled-out and
return execution when the Promise is now fulfilled.

The idea that we're going to create the _uber_super_ Promise
class for all languages is, IMO, completely impossible. Each
language will have its own asynchronous-way to deal with
how values are going to be available in the future and which
syntax better conveys that concept. Promises in our API,
OTH, allow us to _talk_ about asynchronous operations
in a way that is well-defined and which bindings can rely
enough to do proper code generation without knowing
specific semantics of each asynchronous operations. That
is not possible with events per se, because bindings
don't know anything about them.

However, making promises an Eo object is not a problem
per se, as long as we have _very_well_defined_
semantics for everything, it works exactly the same,
but, at the same time, to have very well defined
semantics we need to limit on how extensible everything
is, otherwise we just get normal events again and
that is not well-defined enough to be translatable
properly to every language.

So, in the end, if we make Promises an Eo/Eolian
object with very well defined semantics, we get
a "normal class"* that works the same as an
Eina_Promise, but uses the Eo syntax
for things on C (only on C!), and with that we
start paying for things that doesn't seem
to make sense IMO, such as the cost of
late binding in Eo; the cost of allocating
and instantiating a Eo object; etc. Without
reaping any benefits. And, IMO, if asynchronous
operations are to be _really_ used in EFL, we
need promises to be _fast_. Asynchronous
operations already have a inherent cost of
having to use heap memory where synchronous
operations can just use stack allocation, if
we make the cost considerably bigger, then
asynchronous operations becomes way too
costly to be useful for more and more
scenarios, and then it just won't be as useful.
Or maybe worse, each sub-component
start creating its own way of doing asynchronous,
because promises now are too expensive.

We can optimize things other ways ofc, like
caching and etc. But I fear this becomes
another eo_do, where we want to be
faster than C++ and end up creating a
huge infrastructure to make it faster,
and end up being even slower.

* not so normal, because we need to be able
to mark the type information statically when
used, as we do for containers, but that is only
on usage, so not a huge problem.

So, tl;dr; I think we need to have fast
promises so we can use it in more places,
have a proper C API that is convenient
to use and remove any frivelous features
that aren't extremely necessary for
normal asynchronous operations. And
let bindings deal with asynchronous their
own way by being users to EFL Promises,
and not necessarily expose EFL Promises
directly.
""

On Fri, Jun 17, 2016 at 9:38 AM, Tom Hacohen  wrote:
> On 16/06/16 22:55, Cedric 

Re: [E-devel] promises...

[Tom Hacohen]

On 17/06/16 03:53, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  said:
>
>> Lets start with life-cycle: Eo is great, and I think using Eo is the
>> right way to go, but unfortunately that doesn't solve our life-cycle
>> issue. When do promises die?
>>
>> p = efl_file_set()...
>> // Delete here if file has been set?
>> promise_then_add(p, cb)
>> // Delete here if file has been set?
>> promise_then_add(p, cb2);
>> // Delete here if file has been set?
>> ... // a million years into the future
>> // Delete here if file has been set?
>
> the way i see it is you need to set both then and else at the same time so
>
>   p = efl_file_set()
>   eo_promise_then(p, sucess_cb, fail_cb, NULL);
>   // p may be deleted at this point since on success or failure it is deleted
>   // do not depend on p after you have set then/else cb's. ensure if you need 
> to
>   // access the cb that you add a DEL event cb to the promise to track it OR 
> if
>   // you HAVE to have it then add an eo_ref(p) before eo_promise_then()

Unfortunately, I don't think that works well in real life. It'll be a 
source of many bugs. The problem is that:
p = ...
eo_promise_then(...)
eo_promise_then(...)

Will work in many case, until it doesn't sometime when we change 
something internally, or when the stars align just right and the promise 
evaluates immediately. This is very dangerous. This is more common than 
you think, and will become even more common. In JS, the usage often 
looks like:
p.then(...).then(efl_provided_helper_cb).then(other_efl_cb).

>
>> There is just no sensible way to do it automatically. You will *always*
>> have to unref, so following the above example:
>>
>> p = efl_file_set()
>> ... // All of the code before
>> eo_del(p); // It'll only die here
>>
>> Which won't work because then ignoring efl_file_set's output won't be
>> allowed.
>
> well that's kind of the problem. with no then/else the promise has to stay
> around forever holding the return value. you can't ignore it if its a return.
> if it's
>
>   p = eo_add(NULL, PROMISE);
>   // do aother promise setup here like
>   eo_promise_then(p, done_cb, NULL, NULL);
>   elf_file_set(obj, file, key, );
>
> then it can set up the promise in efl_file_set. if you do
>
>   efl_file_set(obj, file, key, NULL);
>
> then we say "we don't care about the async result". perhaps it can now be sync
> by default if you do this?

Look at my suggestion below, I already solved this problem.

>
>> The only sensible way of doing it, I guess, is to force a wrapper of
>> some sort, so the code above becomes:
>> p = eo_ref(efl_file_set());
>> ... // Code from before
>> eo_del(p);
>>
>> Or probably for extra safety (like marking the promise was actually
>> used, and not just implicitly with a ref, this will allow us to block
>> then/cancel registration and be more safe).
>>
>> p = efl_promise_use(efl_file_set());
>> ... // Code from before
>> eo_del(p);
>>
>> efl_promise_use will set a flag in the promise so that
>> p = efl_file_set();
>> promise_then_add(p); // This will fail because the flag wasn't set.
>>
>> So that's safe and probably the way to go. This will let us manage
>> life-cycle correctly.
>
> i think that's more complex than the above i suggest. the problem is if you
> pass in a promise... this now affects all of our file_set or any api that can
> or should be async.
>
> as i said... i don't think we need a promise on these objects. we already have
> an object to store the value/state of the load. it can already call event cb's
> when these actions succeed or fail. we have done this with preload for years
> already. if you do another file_set it does cancel the previous one by
> definition (the only q is if that means you have to call a load fail callback
> of some sort).
>
> this is what i mean by "let's not use promises here because at this stage they
> do not help, just cause more work, complexity etc.".

I 100% agree on this, we don't need to use promise for file_set! Using 
file set was just an example though for the life-cycle issue. The 
life-cycle is the problem I was addressing here, and I don't think it's 
solved in any way but my last example.

>
>> Usage of event callbacks: I mentioned it somewhere else in the thread,
>> but not as bluntly. I think Marcel is wrong, and I think you guys are
>> focusing too much on non-existent semantics. Saying promises are
>> callbacks that are only called once so they are inherently different
>> from event callbacks is absolutely wrong. Think of EO_EVENT_DEL, called
>
> i totally agree with you on this.
>
>> when object is deleted, only called once. You are too fixated with how
>> events happen to be implemented in eo.base, don't.
>
> i agree.
>
>> As I also said, overriding callback_add and adding there code to call
>> the callback immediately if the promise has already finished is
>> *exactly* the way to go. Also, you don't need to remove callbacks once
>> they have been executed, they 

Re: [E-devel] promises...

[Tom Hacohen]

On 17/06/16 03:28, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen  said:
>
>> On 03/06/16 20:17, Cedric BAIL wrote:
>> 
> also promises should become eo objects with event cb's
> so they work just like everything else. i can ref, unref, delete and
> whatever them like everything else.
>>>
>>> As said above, this does work. Example with event :
>>> eo_promise = efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>>>
>>> In this 3 lines, there is already 2 case in which that fail. First if,
>>> the object is done before the callback is set, data are lost and there
>>> is no way to get any event. Ofcourse, we can override the behavior of
>>> events on this eo_promise completely. Now let's imagine, that we
>>> actually do always store the events, so that everytime someone
>>> register a callback we can send the event. Still you can't auto del
>>> the object at any point in time, you have to force the user to
>>> implement the eo_del and to always provide both a then and cancel
>>> callback.
>>>
>>> Other possibility, it is an event on the object itself.
>>> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
>>> efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>>>
>>> Same again, this can not work. The first group of event handler,
>>> promise_callbacks1(), may actually be triggered by a previously
>>> running promise on the object, so you have to first forcefully stop
>>> the previous operation. This would add complexity. And still the
>>> second callback has the same issue as the previous case, if it is a
>>> normal eo event, it could have been triggered before any callback get
>>> registered and the event be lost... Same story short, doesn't work.
>>>
>>
>> I'm currently reading through the thread, and I didn't see anything
>> mentioned about this other than a casual remark you made, so just wanted
>> to make it crystal clear regarding implementing it as an Eo object.
>> The whole point/magic of inheritance is that you can and are supposed to
>> override functions if needed. Overriding callback add to call the
>> callback immediately upon addition (if already done) is how I would
>> implement promise callbacks. It's clean, easy and as intended. This is
>> definitely not a problem.
>
> just for convenience i think having a special eo_promise_then(obj, cb1, cb2,
> data); may be best as its the simplest and is not pretending to ADD a cb in 
> the
> name. it sets it explicitly. this needs special treatment like the eo event
> callbacks of course.
>
> but using an eo event is possible by override indeed, but here is the issue.
> you have to wait until either "then" or "else" or both are set. since you set
> one then set another... you will have to always add one of them as a NULL or
> dummy cb just to do this. having a single method/func set both makes more
> sense. in fact this likely needs manual binding/.handling per language anyway.
> i'm really only thinking of eo events for EXTRA features like progress events
> on a promise that happen before the success/fail cb's above.
>
>

This is explained better in my reply to the initial post of this thread, 
but essentially you don't. What you are missing, and why life-cycle can 
be pretty broken, and why this doesn't matter is that you can register a 
few "then" and a few "cancel" in promises. That is actually the power of 
promises, that you can chain them and use them for a few things. This is 
dealt with nicely. See the post I mentioned.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 16/06/16 19:51, Cedric BAIL wrote:
> On Thu, Jun 16, 2016 at 11:13 AM, Tom Hacohen  wrote:
>> On 03/06/16 20:17, Cedric BAIL wrote:
>> 
> also promises should become eo objects with event cb's
> so they work just like everything else. i can ref, unref, delete and 
> whatever
> them like everything else.
>>>
>>> As said above, this does work. Example with event :
>>> eo_promise = efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
>>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>>>
>>> In this 3 lines, there is already 2 case in which that fail. First if,
>>> the object is done before the callback is set, data are lost and there
>>> is no way to get any event. Ofcourse, we can override the behavior of
>>> events on this eo_promise completely. Now let's imagine, that we
>>> actually do always store the events, so that everytime someone
>>> register a callback we can send the event. Still you can't auto del
>>> the object at any point in time, you have to force the user to
>>> implement the eo_del and to always provide both a then and cancel
>>> callback.
>>>
>>> Other possibility, it is an event on the object itself.
>>> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
>>> efl_file_set(image, "toto.jpg", NULL);
>>> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>>>
>>> Same again, this can not work. The first group of event handler,
>>> promise_callbacks1(), may actually be triggered by a previously
>>> running promise on the object, so you have to first forcefully stop
>>> the previous operation. This would add complexity. And still the
>>> second callback has the same issue as the previous case, if it is a
>>> normal eo event, it could have been triggered before any callback get
>>> registered and the event be lost... Same story short, doesn't work.
>>>
>>
>> I'm currently reading through the thread, and I didn't see anything
>> mentioned about this other than a casual remark you made, so just wanted
>> to make it crystal clear regarding implementing it as an Eo object.
>> The whole point/magic of inheritance is that you can and are supposed to
>> override functions if needed. Overriding callback add to call the
>> callback immediately upon addition (if already done) is how I would
>> implement promise callbacks. It's clean, easy and as intended. This is
>> definitely not a problem.
>
> I hope that by the end of this thread you do understand why this
> doesn't work. Basically the point is that you don't have to eo_del a
> promise ever. Once you set the callback on it and when all the
> expected callback are called, the promise vanish. Inheritance on
> callback, that is a given, thanks. Now, how do you make sure you have
> all the callback registered and that you have delivered the value to
> everyone that expect it before the promise commit succide ?
>

See my reply with all the promise comments. I explained everything there.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 17/06/16 09:33, Jean-Philippe André wrote:
> On 17 June 2016 at 17:21, Tom Hacohen  wrote:
>
>> On 17/06/16 03:21, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen 
>> said:
>>>
 On 16/06/16 10:47, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André <
>> j...@videolan.org>
> said:
>
>
 The ON_HOLD flag, now called efl_event_processed_get/set() is a
>> better
 approach to stop processing events.
>>>
>>> That is off topic, but seriously something we should consider asap if
>>> we want to drop the return type of event. I have not any case in mind
>>> where returning EINA_FALSE make sense. Should we drop it ?
>>>
>>
>> I am also thinking we should drop it.
>> Pretty sure the few places that return EINA_FALSE right now are
>> actually
>> mistakes and sources of bugs.
>
> i think so too. drop the return.
>

 The return is mega useful, though I'm open to implementing it
 differently. The return is there so you can filter events. We currently
 have things like "on_hold" in input events to mark an event has been
 processed and should stop propagating, but the return lets you stop the
 callback. I guess we can change it to be "eo_event_callback_stop(obj)".
>>>
>>> but the thing is.. we don't want to stop the callback. well not where
>> hold is
>>> used. you want to still get the cb but put on hold any actions.like
>> calling the
>>> clicked callback. you still need the event to get the matching mouse up
>> fro the
>>> mouse down for example, but since you started a drag, after n move
>> events the
>>> mouse up (and future moves) should not be acted on.
>>
 Btw, it shouldn't be a bool, there are defines for the return values. I
 should have typedeffed the type. I'm open to changing to
 eo_event_callback_stop though, just let me know.

 Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
 write. :)
>>>
>>> see above. the only use case we have to date is the above and a return
>> just
>>> doesn't do it. you need to have a modified event go through afterwards.
>>>
>>> i did the return true/false for ecore events for pass through. over the
>> years i
>>> have recognized this as a mistake. it's more pain than gain.
>>
>> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels
>> better for making event propagation to stop, but I do like being able to
>> stop it. It is used in the EFL, I just got the name wrong,
>> EO_CALLBACK_STOP. :)
>> It's useful for text filtering iirc, to make it stop processing the
>> filter if one has already failed. It is used and useful.
>>
>>
> obj here would then be the Eo_Event's object?
> As Cedric noted, this is not like ON_HOLD (actually called "processed"),
> because we call that on the event->info.
>
> I agree stop can be useful sometimes, but only quite rarely (in practice,
> in our code).
>

That's why I suggested maybe making it an external call. The only 
problem with that is that it'll have to be the absolute last call in the 
callback, otherwise it could confuse Eo and generate bugs. I could make 
it more safe by making people adding the event type to the stop 
function, but that's still not airtight.

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Jean-Philippe André]

On 17 June 2016 at 17:21, Tom Hacohen  wrote:

> On 17/06/16 03:21, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen 
> said:
> >
> >> On 16/06/16 10:47, Carsten Haitzler wrote:
> >>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André <
> j...@videolan.org>
> >>> said:
> >>>
> >>>
> >> The ON_HOLD flag, now called efl_event_processed_get/set() is a
> better
> >> approach to stop processing events.
> >
> > That is off topic, but seriously something we should consider asap if
> > we want to drop the return type of event. I have not any case in mind
> > where returning EINA_FALSE make sense. Should we drop it ?
> >
> 
>  I am also thinking we should drop it.
>  Pretty sure the few places that return EINA_FALSE right now are
> actually
>  mistakes and sources of bugs.
> >>>
> >>> i think so too. drop the return.
> >>>
> >>
> >> The return is mega useful, though I'm open to implementing it
> >> differently. The return is there so you can filter events. We currently
> >> have things like "on_hold" in input events to mark an event has been
> >> processed and should stop propagating, but the return lets you stop the
> >> callback. I guess we can change it to be "eo_event_callback_stop(obj)".
> >
> > but the thing is.. we don't want to stop the callback. well not where
> hold is
> > used. you want to still get the cb but put on hold any actions.like
> calling the
> > clicked callback. you still need the event to get the matching mouse up
> fro the
> > mouse down for example, but since you started a drag, after n move
> events the
> > mouse up (and future moves) should not be acted on.
> >
> >> Btw, it shouldn't be a bool, there are defines for the return values. I
> >> should have typedeffed the type. I'm open to changing to
> >> eo_event_callback_stop though, just let me know.
> >>
> >> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
> >> write. :)
> >
> > see above. the only use case we have to date is the above and a return
> just
> > doesn't do it. you need to have a modified event go through afterwards.
> >
> > i did the return true/false for ecore events for pass through. over the
> years i
> > have recognized this as a mistake. it's more pain than gain.
>
> Again, I don't mind changing it to eo_event_callback_stop(obj). Feels
> better for making event propagation to stop, but I do like being able to
> stop it. It is used in the EFL, I just got the name wrong,
> EO_CALLBACK_STOP. :)
> It's useful for text filtering iirc, to make it stop processing the
> filter if one has already failed. It is used and useful.
>
>
obj here would then be the Eo_Event's object?
As Cedric noted, this is not like ON_HOLD (actually called "processed"),
because we call that on the event->info.

I agree stop can be useful sometimes, but only quite rarely (in practice,
in our code).

-- 
Jean-Philippe André
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 17/06/16 03:21, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen  said:
>
>> On 16/06/16 10:47, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André 
>>> said:
>>>
>>>
>> The ON_HOLD flag, now called efl_event_processed_get/set() is a better
>> approach to stop processing events.
>
> That is off topic, but seriously something we should consider asap if
> we want to drop the return type of event. I have not any case in mind
> where returning EINA_FALSE make sense. Should we drop it ?
>

 I am also thinking we should drop it.
 Pretty sure the few places that return EINA_FALSE right now are actually
 mistakes and sources of bugs.
>>>
>>> i think so too. drop the return.
>>>
>>
>> The return is mega useful, though I'm open to implementing it
>> differently. The return is there so you can filter events. We currently
>> have things like "on_hold" in input events to mark an event has been
>> processed and should stop propagating, but the return lets you stop the
>> callback. I guess we can change it to be "eo_event_callback_stop(obj)".
>
> but the thing is.. we don't want to stop the callback. well not where hold is
> used. you want to still get the cb but put on hold any actions.like calling 
> the
> clicked callback. you still need the event to get the matching mouse up fro 
> the
> mouse down for example, but since you started a drag, after n move events the
> mouse up (and future moves) should not be acted on.
>
>> Btw, it shouldn't be a bool, there are defines for the return values. I
>> should have typedeffed the type. I'm open to changing to
>> eo_event_callback_stop though, just let me know.
>>
>> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
>> write. :)
>
> see above. the only use case we have to date is the above and a return just
> doesn't do it. you need to have a modified event go through afterwards.
>
> i did the return true/false for ecore events for pass through. over the years 
> i
> have recognized this as a mistake. it's more pain than gain.

Again, I don't mind changing it to eo_event_callback_stop(obj). Feels 
better for making event propagation to stop, but I do like being able to 
stop it. It is used in the EFL, I just got the name wrong, 
EO_CALLBACK_STOP. :)
It's useful for text filtering iirc, to make it stop processing the 
filter if one has already failed. It is used and useful.

--
Tom.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 16/06/16 19:53, Cedric BAIL wrote:
> On Thu, Jun 16, 2016 at 11:29 AM, Tom Hacohen  wrote:
>> On 16/06/16 10:47, Carsten Haitzler wrote:
>>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André  
>>> said:
>> The ON_HOLD flag, now called efl_event_processed_get/set() is a better
>> approach to stop processing events.
>
> That is off topic, but seriously something we should consider asap if
> we want to drop the return type of event. I have not any case in mind
> where returning EINA_FALSE make sense. Should we drop it ?

 I am also thinking we should drop it.
 Pretty sure the few places that return EINA_FALSE right now are actually
 mistakes and sources of bugs.
>>>
>>> i think so too. drop the return.
>>
>> The return is mega useful, though I'm open to implementing it
>> differently. The return is there so you can filter events. We currently
>> have things like "on_hold" in input events to mark an event has been
>> processed and should stop propagating, but the return lets you stop the
>> callback. I guess we can change it to be "eo_event_callback_stop(obj)".
>> Btw, it shouldn't be a bool, there are defines for the return values. I
>> should have typedeffed the type. I'm open to changing to
>> eo_event_callback_stop though, just let me know.
>
> on_hold boolean is gone from efl input event. JP did some magic here
> as this would have never worked with bindings, basically using an Eo
> object to set the flag.
>
>> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
>> write. :)
>
> git grep return nothing on efl tree for me.
>

It's because I was tired! "git grep EO_CALLBACK_STOP"...

bin/elementary/test_code.c:   return EO_CALLBACK_STOP;
lib/ecore_con/ecore_con_url.c:   if (!e) return EO_CALLBACK_STOP;
lib/ecore_con/ecore_con_url.c:   return EO_CALLBACK_STOP;
lib/elementary/efl_ui_text.c:   eina_strbuf_append_printf(buf, 
"validation,%s,%s", vc.signal, res == EO_CALLBACK_STOP ? "fail" : "pass");
lib/elementary/elm_entry.c:   eina_strbuf_append_printf(buf, 
"validation,%s,%s", vc.signal, res == EO_CALLBACK_STOP ? "fail" : "pass");
lib/elementary/elm_helper.c:   return validator->status ? 
EO_CALLBACK_STOP : EO_CALLBACK_CONTINUE;
lib/elementary/elm_panel.c:   return EO_CALLBACK_STOP;

--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 11:53:56 -0700 Cedric BAIL  said:

> On Thu, Jun 16, 2016 at 11:29 AM, Tom Hacohen  wrote:
> > On 16/06/16 10:47, Carsten Haitzler wrote:
> >> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André 
> >> said:
> > The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> > approach to stop processing events.
> 
>  That is off topic, but seriously something we should consider asap if
>  we want to drop the return type of event. I have not any case in mind
>  where returning EINA_FALSE make sense. Should we drop it ?
> >>>
> >>> I am also thinking we should drop it.
> >>> Pretty sure the few places that return EINA_FALSE right now are actually
> >>> mistakes and sources of bugs.
> >>
> >> i think so too. drop the return.
> >
> > The return is mega useful, though I'm open to implementing it
> > differently. The return is there so you can filter events. We currently
> > have things like "on_hold" in input events to mark an event has been
> > processed and should stop propagating, but the return lets you stop the
> > callback. I guess we can change it to be "eo_event_callback_stop(obj)".
> > Btw, it shouldn't be a bool, there are defines for the return values. I
> > should have typedeffed the type. I'm open to changing to
> > eo_event_callback_stop though, just let me know.
> 
> on_hold boolean is gone from efl input event. JP did some magic here
> as this would have never worked with bindings, basically using an Eo
> object to set the flag.

actually the event information *IS* an eo object. yo just get properties from
it... this means to set hold ... you just set the property and the same obj is
passed into future cb's for that event. :)

> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
> > write. :)
> 
> git grep return nothing on efl tree for me.
> -- 
> Cedric BAIL
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Wed, 15 Jun 2016 17:28:07 -0700 Cedric BAIL  said:

> On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler 
> wrote:
> > On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL  said:
> >> Ok, I am giving up on this. We will make it an eo object, but not an
> >> eolian one as it should be a native type for any binding (It is sure
> >> that C++, Lua and JS will have to do a manual binding for it) as there
> >> is very little case were inheritance make sense on promise and
> >> wouldn't at the same time break binding. eina_promise_owner will
> >> become eo_promise and eina_promise will become eo_future (to follow
> >> C++ naming convention). Not to sure how to limit the interface exposed
> >> by a return type as we don't want the user of the API to access the
> >> promise API, just the future one. Double object would be annoying, but
> >> is likely the only solution. So if we want to be safe, we will need to
> >> use 2 objects per promise. One facing the user of the API and one used
> >> by the producer of the API. If we don't want to be safe, we can merge
> >> both API and just use inheritance. So returning an eo_future interface
> >> in the API, while in fact eo_promise function would work on it.
> >
> > what api should not be used? a lot of not most will need to be bound and
> > exposed so you can CREATE a promise - e.g. if you create a new class in js
> > and want to return promises or set them up etc. etc.
> 
> There is two part to a promise. C++ is clearer on this. It define one
> side to be the promise and the other to be the future. The future is
> what deliver the value. You can cancel it and it is what you actually
> get from any API that provide something using promise. Promise is what
> the owner, the creator of the promise use internally to set value on
> or trigger cancel. The user of the future is not supposed to ever call
> value set on the future. This is for type safety obviously.

well the functions have to exist either way so you can set them up. as tom said
- divide into a owner/future interfaces on a promise object for example, or use
@protected for those funcs we only use on the c side etc.

> > and why not eolian. eo base uses eolian. you can make methods @protected for
> > example... and why not inheritance? adding progress events to me at least is
> > taking the basic promise without them and extending by adding. it's even
> > then typesafe in c++ - you cant listen for progress on a promise that does
> > not provide it. we don't do it right now but for events we could also type
> > check in c too to see what events that class supports and runtime
> > error/reject.
> 
> As said, you can not automatically bind a promise. It is a native type
> for every possible binding. It also make little sense to actually

as toms said - still use .eo files and eolian_gen ... :) and yoou can partially
bind it with eolian just like eo base class is.

> inherit in that case as that inherited type would be unavailable to
> any binding obviously. Following C++ naming, future are defined by
> having 3 events (then, cancel and progress) with a guaranty that
> either then or cancel will happen. As for promise, they allow the
> delivery of a value that may be associated with some progress and can
> also fail. The scope of promise is well defined and has been used like
> this for years in other language (It even managed to land in C++  and
> JS standard).
> 
> Also this is part of the language of eolian. You define a promise that
> return a future value, like promise. Promise is a future
> container to that type. As stated above, binding will have no clue
> what to do with a a new container that they have never heard off.
> Especially if there is a new behavior needed to be implemented to
> finish the task. If a promise is not defined by then/cancel/progress,
> it is likely to break its integration with _all/_race and any module
> that use promise in any bindings. Basically if you add undefined
> event, that promise is unusable in any binding.
> 
> > if you now need not just progress but some other event along the way to
> > completion, just inherit class and extend.
> 
> It is most likely that you are trying to squeeze 2 promise into one or
> something that is not a promise to a value, but something else.

eh? i'm just speaking of the progress thing in eina_promise. that can be done
with a progress promise class that inherits from a basic promise class. it adds
progress events (and that's about it) in normal eo fashion. :) you could make
it part of the basic promise class too, but it's an example of how to extend
the promise class to do more.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an 

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 14:55:05 -0700 Cedric BAIL  said:

> On Thu, Jun 16, 2016 at 12:11 PM, Tom Hacohen  wrote:
> > On 03/06/16 07:42, Carsten Haitzler wrote:
> >> ok. interacting with promises...
> >>
> >> these are just a mess.
> >>
> >> 1. the value thing is just odd.
> >> 2. they are complex to set up inside our api (setting them up setting
> >> cancel cb's and more)
> >> 3. they totally screw with what eo and interfaces was all about - making
> >> the api EASIER to use. promises make it harder.
> >>
> >> why harder? longer lines of code with more parameters and more special
> >> casing... but the WORST...
> >>
> >>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
> >>
> >> that's a promise cb
> >>
> >>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
> >>
> >> and that's an event cb. they are different. eo events were meant to
> >> simplify and unify our callback handling. to have a single cb signature.
> >> now promises break that. this is just bad.
> >>
> >> i wasn't sold on promises. i was skeptical, but whatever... but now i am
> >> seeing they are visibly making things worse. code is harder to write,
> >> harder to read, harder to maintain, harder to get right. now we have
> >> timeouts that cannot repeat. no - creating a new timer in the cb is not
> >> repeating. it has to repeat with the "zero time" being the time when the
> >> timer was ticked off, not "now".
> >>
> >> please - everyone. take a look at promises and how they are used. forget
> >> all of the "but node.js has them" and all the "i can chain promises" and
> >> so on. the BASIC usage of them is harder now in efl.
> >>
> >> what to do? well... minimize their use for one. do not use them unless you
> >> ABSOLUTELY HAVE TO. also promises should become eo objects with event cb's
> >> so they work just like everything else. i can ref, unref, delete and
> >> whatever them like everything else.
> >>
> >> right now i think promises are just not in a shape to use or ship. they
> >> need a lot more work. i think we need to drop them for efl 1.18 and defer
> >> for efl 2.0
> >
> > Guys, you bored me to death with this thread. I replied to what looked
> > like it needed attention, but please let me know if there's anything
> > specific I missed that warrants my reply.
> >
> > I would like to add my take on promises too. As you may remember, I've
> > objected to promises from the start. I just didn't see a sensible way of
> > implementing them back then, and unfortunately, even after they've been
> > implemented, I still don't think they are done nicely.
> 
> Being against promise, is only advocating for no asynchrone behavior
> in Efl. This is a position we can't take. So either you have a better
> pattern to handle asynchronous behavior and synchronisation or we have
> to provide promise. Objecting to promise is clearly not helping
> anything here.

that's completely false. we've had no promises for a decade, yet we have lots
of async behaviour. we have async rendering in evas, async image loading in
evas, async network tcp/ip/udb etc. handling, async http, async unix socket/ipc
handling, async dbus handling

i think you've somehow gotten it into your head that there is only one way in
the universe to be async and that is a promise. and whatever that thing is in
your head... it's wrong by a massive margin. there are many ways to slice and
dice async behaviour. our whole eo event callbacks are FOR async behavior and
much more.

you need to think very carefully. is a promise BETTER than just a callback on
an object. if it is not BETTER and EASIER to use, then don't usse it. and
easier means to the people using the api.

> 
> 
> > Lets start with life-cycle: Eo is great, and I think using Eo is the
> > right way to go, but unfortunately that doesn't solve our life-cycle
> > issue. When do promises die?
> >
> > p = efl_file_set()...
> > // Delete here if file has been set?
> > promise_then_add(p, cb)
> > // Delete here if file has been set?
> > promise_then_add(p, cb2);
> > // Delete here if file has been set?
> > ... // a million years into the future
> > // Delete here if file has been set?
> >
> > There is just no sensible way to do it automatically. You will *always*
> > have to unref, so following the above example:
> >
> > p = efl_file_set()
> > ... // All of the code before
> > eo_del(p); // It'll only die here
> >
> > Which won't work because then ignoring efl_file_set's output won't be
> > allowed.
> >
> > The only sensible way of doing it, I guess, is to force a wrapper of
> > some sort, so the code above becomes:
> > p = eo_ref(efl_file_set());
> > ... // Code from before
> > eo_del(p);
> 
> Amazing, we are more or less back to my point. Except that eo_del is
> now to be used. The problem is that this break things, first you loose
> the parent relationship on promise. So if that was used to actually do
> something useful on its lifecycle, you can't anymore. Second 

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen  said:

> Lets start with life-cycle: Eo is great, and I think using Eo is the 
> right way to go, but unfortunately that doesn't solve our life-cycle 
> issue. When do promises die?
> 
> p = efl_file_set()...
> // Delete here if file has been set?
> promise_then_add(p, cb)
> // Delete here if file has been set?
> promise_then_add(p, cb2);
> // Delete here if file has been set?
> ... // a million years into the future
> // Delete here if file has been set?

the way i see it is you need to set both then and else at the same time so

  p = efl_file_set()
  eo_promise_then(p, sucess_cb, fail_cb, NULL);
  // p may be deleted at this point since on success or failure it is deleted
  // do not depend on p after you have set then/else cb's. ensure if you need to
  // access the cb that you add a DEL event cb to the promise to track it OR if
  // you HAVE to have it then add an eo_ref(p) before eo_promise_then()

> There is just no sensible way to do it automatically. You will *always* 
> have to unref, so following the above example:
> 
> p = efl_file_set()
> ... // All of the code before
> eo_del(p); // It'll only die here
> 
> Which won't work because then ignoring efl_file_set's output won't be 
> allowed.

well that's kind of the problem. with no then/else the promise has to stay
around forever holding the return value. you can't ignore it if its a return.
if it's

  p = eo_add(NULL, PROMISE);
  // do aother promise setup here like
  eo_promise_then(p, done_cb, NULL, NULL);
  elf_file_set(obj, file, key, );

then it can set up the promise in efl_file_set. if you do

  efl_file_set(obj, file, key, NULL);

then we say "we don't care about the async result". perhaps it can now be sync
by default if you do this?

> The only sensible way of doing it, I guess, is to force a wrapper of 
> some sort, so the code above becomes:
> p = eo_ref(efl_file_set());
> ... // Code from before
> eo_del(p);
> 
> Or probably for extra safety (like marking the promise was actually 
> used, and not just implicitly with a ref, this will allow us to block 
> then/cancel registration and be more safe).
> 
> p = efl_promise_use(efl_file_set());
> ... // Code from before
> eo_del(p);
> 
> efl_promise_use will set a flag in the promise so that
> p = efl_file_set();
> promise_then_add(p); // This will fail because the flag wasn't set.
> 
> So that's safe and probably the way to go. This will let us manage 
> life-cycle correctly.

i think that's more complex than the above i suggest. the problem is if you
pass in a promise... this now affects all of our file_set or any api that can
or should be async.

as i said... i don't think we need a promise on these objects. we already have
an object to store the value/state of the load. it can already call event cb's
when these actions succeed or fail. we have done this with preload for years
already. if you do another file_set it does cancel the previous one by
definition (the only q is if that means you have to call a load fail callback
of some sort).

this is what i mean by "let's not use promises here because at this stage they
do not help, just cause more work, complexity etc.".

> Usage of event callbacks: I mentioned it somewhere else in the thread, 
> but not as bluntly. I think Marcel is wrong, and I think you guys are 
> focusing too much on non-existent semantics. Saying promises are 
> callbacks that are only called once so they are inherently different 
> from event callbacks is absolutely wrong. Think of EO_EVENT_DEL, called 

i totally agree with you on this.

> when object is deleted, only called once. You are too fixated with how 
> events happen to be implemented in eo.base, don't.

i agree.

> As I also said, overriding callback_add and adding there code to call 
> the callback immediately if the promise has already finished is 
> *exactly* the way to go. Also, you don't need to remove callbacks once 
> they have been executed, they just happen to never be called again 
> because the callback is never triggered again.

agree - but i think the then/else would do well to be special for eo promises
(for the reasons already given). progress should be an eo event etc.

> Splitting of promise to two objects, owner and future: unnecessary. 
> There are a few mechanisms in Eo to let you have different "access" to 
> an object.

i agree. single object, but 2 interfaces. a future and an owner interface on a
promise obj.

> 1. Make all of the owner methods "protected", so assume whoever is 
> implementing "owner" is more responsible and let him have access to both 
> the "future" functions and his "own".

this sounds good.

> 2. Same assumption as #1, but just make Owner inherit from Future, and 
> create Owner internally, but return Future in the API. Won't have a 
> different in C, but for bindings it'll only expose the correct type.

well futures and promises for at least several languages need to be manually
bound. but 

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 19:29:52 +0100 Tom Hacohen  said:

> On 16/06/16 10:47, Carsten Haitzler wrote:
> > On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André 
> > said:
> >
> >
>  The ON_HOLD flag, now called efl_event_processed_get/set() is a better
>  approach to stop processing events.
> >>>
> >>> That is off topic, but seriously something we should consider asap if
> >>> we want to drop the return type of event. I have not any case in mind
> >>> where returning EINA_FALSE make sense. Should we drop it ?
> >>>
> >>
> >> I am also thinking we should drop it.
> >> Pretty sure the few places that return EINA_FALSE right now are actually
> >> mistakes and sources of bugs.
> >
> > i think so too. drop the return.
> >
> 
> The return is mega useful, though I'm open to implementing it 
> differently. The return is there so you can filter events. We currently 
> have things like "on_hold" in input events to mark an event has been 
> processed and should stop propagating, but the return lets you stop the 
> callback. I guess we can change it to be "eo_event_callback_stop(obj)". 

but the thing is.. we don't want to stop the callback. well not where hold is
used. you want to still get the cb but put on hold any actions.like calling the
clicked callback. you still need the event to get the matching mouse up fro the
mouse down for example, but since you started a drag, after n move events the
mouse up (and future moves) should not be acted on.

> Btw, it shouldn't be a bool, there are defines for the return values. I 
> should have typedeffed the type. I'm open to changing to 
> eo_event_callback_stop though, just let me know.
> 
> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't 
> write. :)

see above. the only use case we have to date is the above and a return just
doesn't do it. you need to have a modified event go through afterwards.

i did the return true/false for ecore events for pass through. over the years i
have recognized this as a mistake. it's more pain than gain.

> --
> Tom.
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 11:51:45 -0700 Cedric BAIL  said:

> On Thu, Jun 16, 2016 at 11:13 AM, Tom Hacohen  wrote:
> > On 03/06/16 20:17, Cedric BAIL wrote:
> > 
>  also promises should become eo objects with event cb's
>  so they work just like everything else. i can ref, unref, delete and
>  whatever them like everything else.
> >>
> >> As said above, this does work. Example with event :
> >> eo_promise = efl_file_set(image, "toto.jpg", NULL);
> >> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
> >> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
> >>
> >> In this 3 lines, there is already 2 case in which that fail. First if,
> >> the object is done before the callback is set, data are lost and there
> >> is no way to get any event. Ofcourse, we can override the behavior of
> >> events on this eo_promise completely. Now let's imagine, that we
> >> actually do always store the events, so that everytime someone
> >> register a callback we can send the event. Still you can't auto del
> >> the object at any point in time, you have to force the user to
> >> implement the eo_del and to always provide both a then and cancel
> >> callback.
> >>
> >> Other possibility, it is an event on the object itself.
> >> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
> >> efl_file_set(image, "toto.jpg", NULL);
> >> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
> >>
> >> Same again, this can not work. The first group of event handler,
> >> promise_callbacks1(), may actually be triggered by a previously
> >> running promise on the object, so you have to first forcefully stop
> >> the previous operation. This would add complexity. And still the
> >> second callback has the same issue as the previous case, if it is a
> >> normal eo event, it could have been triggered before any callback get
> >> registered and the event be lost... Same story short, doesn't work.
> >>
> >
> > I'm currently reading through the thread, and I didn't see anything
> > mentioned about this other than a casual remark you made, so just wanted
> > to make it crystal clear regarding implementing it as an Eo object.
> > The whole point/magic of inheritance is that you can and are supposed to
> > override functions if needed. Overriding callback add to call the
> > callback immediately upon addition (if already done) is how I would
> > implement promise callbacks. It's clean, easy and as intended. This is
> > definitely not a problem.
> 
> I hope that by the end of this thread you do understand why this
> doesn't work. Basically the point is that you don't have to eo_del a
> promise ever. Once you set the callback on it and when all the
> expected callback are called, the promise vanish. Inheritance on

yup. totally get that. the promise deletes itself after having called either
success or fail cb. no need to delete it yourself. like eo part proxy objects.

> callback, that is a given, thanks. Now, how do you make sure you have
> all the callback registered and that you have delivered the value to
> everyone that expect it before the promise commit succide ?

as i suggested a special eo_promise_then() method that takes 2 cb's just like
eina_promise_then(). do progress as a different eo event callback. always add
the eo event cb for progress before the then/else. that's the rule.

> -- 
> Cedric BAIL
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 19:38:55 +0100 Tom Hacohen  said:

> God, walls of text. :)
> 
> I think you are confusing a few things which is where your disagreement 
> with raster comes from. More on that below.
> 
> 
> On 16/06/16 01:28, Cedric BAIL wrote:
> > On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler 
> > wrote:
> >> On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL  said:
> >>> Ok, I am giving up on this. We will make it an eo object, but not an
> >>> eolian one as it should be a native type for any binding (It is sure
> >>> that C++, Lua and JS will have to do a manual binding for it) as there
> >>> is very little case were inheritance make sense on promise and
> >>> wouldn't at the same time break binding. eina_promise_owner will
> >>> become eo_promise and eina_promise will become eo_future (to follow
> >>> C++ naming convention). Not to sure how to limit the interface exposed
> >>> by a return type as we don't want the user of the API to access the
> >>> promise API, just the future one. Double object would be annoying, but
> >>> is likely the only solution. So if we want to be safe, we will need to
> >>> use 2 objects per promise. One facing the user of the API and one used
> >>> by the producer of the API. If we don't want to be safe, we can merge
> >>> both API and just use inheritance. So returning an eo_future interface
> >>> in the API, while in fact eo_promise function would work on it.
> >>
> >> what api should not be used? a lot of not most will need to be bound and
> >> exposed so you can CREATE a promise - e.g. if you create a new class in js
> >> and want to return promises or set them up etc. etc.
> >
> > There is two part to a promise. C++ is clearer on this. It define one
> > side to be the promise and the other to be the future. The future is
> > what deliver the value. You can cancel it and it is what you actually
> > get from any API that provide something using promise. Promise is what
> > the owner, the creator of the promise use internally to set value on
> > or trigger cancel. The user of the future is not supposed to ever call
> > value set on the future. This is for type safety obviously.
> 
> As raster said, you can use @protected for that. This is a very good 
> example to why protected exists in languages like C++ and in Eo. 
> Protected means: do not call this function if you are not the one 
> implementing this class, inheriting from it, or in eolian we also added: 
> managing the object, because C is different. This is a prime example of 
> where protected should be used, and with only one object.
> 
> If you want, another thing you can do, which is a pattern I've used 
> before is something like this:
> Efl.Promise.Future
> Efl.Promise.Owner - inherits from Future and extends it to add the 
> aforementioned management functions.
> 
> You create an Efl.Promise.Owner internally, but return it as 
> Efl.Promise.Future. It won't really matter in C, but in bindings they'll 
> see the type as Future, so they won't have access to the functions.
> 
> I like the protected approach better in this case.

i agree too. though maytbe splitting it in eolian/eo files makes sense so the
future is what you see as a recipient of a promise but in c it's just the same
object and we have promise methods and future methods that work on it. c will
be happy. for c++ if you get a future, the promise methods should be protected.
creating the promise still needs another set of api's. the same object just has
2 views. a view as a promise (to the creator) and a view as a future (the
consumer). but either way the methods will have to exist in bindings so you can
set up promises etc. :)

> >
> >> and why not eolian. eo base uses eolian. you can make methods @protected
> >> for example... and why not inheritance? adding progress events to me at
> >> least is taking the basic promise without them and extending by adding.
> >> it's even then typesafe in c++ - you cant listen for progress on a promise
> >> that does not provide it. we don't do it right now but for events we could
> >> also type check in c too to see what events that class supports and
> >> runtime error/reject.
> >
> > As said, you can not automatically bind a promise. It is a native type
> > for every possible binding. It also make little sense to actually
> > inherit in that case as that inherited type would be unavailable to
> > any binding obviously. Following C++ naming, future are defined by
> > having 3 events (then, cancel and progress) with a guaranty that
> > either then or cancel will happen. As for promise, they allow the
> > delivery of a value that may be associated with some progress and can
> > also fail. The scope of promise is well defined and has been used like
> > this for years in other language (It even managed to land in C++  and
> > JS standard).
> >
> > Also this is part of the language of eolian. You define a promise that
> > return a future value, 

Re: [E-devel] promises...

[Cedric BAIL]

On Thu, Jun 16, 2016 at 12:11 PM, Tom Hacohen  wrote:
> On 03/06/16 07:42, Carsten Haitzler wrote:
>> ok. interacting with promises...
>>
>> these are just a mess.
>>
>> 1. the value thing is just odd.
>> 2. they are complex to set up inside our api (setting them up setting cancel
>> cb's and more)
>> 3. they totally screw with what eo and interfaces was all about - making the
>> api EASIER to use. promises make it harder.
>>
>> why harder? longer lines of code with more parameters and more special
>> casing... but the WORST...
>>
>>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
>>
>> that's a promise cb
>>
>>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
>>
>> and that's an event cb. they are different. eo events were meant to simplify
>> and unify our callback handling. to have a single cb signature. now promises
>> break that. this is just bad.
>>
>> i wasn't sold on promises. i was skeptical, but whatever... but now i am 
>> seeing
>> they are visibly making things worse. code is harder to write, harder to 
>> read,
>> harder to maintain, harder to get right. now we have timeouts that cannot
>> repeat. no - creating a new timer in the cb is not repeating. it has to 
>> repeat
>> with the "zero time" being the time when the timer was ticked off, not "now".
>>
>> please - everyone. take a look at promises and how they are used. forget all 
>> of
>> the "but node.js has them" and all the "i can chain promises" and so on. the
>> BASIC usage of them is harder now in efl.
>>
>> what to do? well... minimize their use for one. do not use them unless you
>> ABSOLUTELY HAVE TO. also promises should become eo objects with event cb's so
>> they work just like everything else. i can ref, unref, delete and whatever 
>> them
>> like everything else.
>>
>> right now i think promises are just not in a shape to use or ship. they need 
>> a
>> lot more work. i think we need to drop them for efl 1.18 and defer for efl 
>> 2.0
>
> Guys, you bored me to death with this thread. I replied to what looked
> like it needed attention, but please let me know if there's anything
> specific I missed that warrants my reply.
>
> I would like to add my take on promises too. As you may remember, I've
> objected to promises from the start. I just didn't see a sensible way of
> implementing them back then, and unfortunately, even after they've been
> implemented, I still don't think they are done nicely.

Being against promise, is only advocating for no asynchrone behavior
in Efl. This is a position we can't take. So either you have a better
pattern to handle asynchronous behavior and synchronisation or we have
to provide promise. Objecting to promise is clearly not helping
anything here.



> Lets start with life-cycle: Eo is great, and I think using Eo is the
> right way to go, but unfortunately that doesn't solve our life-cycle
> issue. When do promises die?
>
> p = efl_file_set()...
> // Delete here if file has been set?
> promise_then_add(p, cb)
> // Delete here if file has been set?
> promise_then_add(p, cb2);
> // Delete here if file has been set?
> ... // a million years into the future
> // Delete here if file has been set?
>
> There is just no sensible way to do it automatically. You will *always*
> have to unref, so following the above example:
>
> p = efl_file_set()
> ... // All of the code before
> eo_del(p); // It'll only die here
>
> Which won't work because then ignoring efl_file_set's output won't be
> allowed.
>
> The only sensible way of doing it, I guess, is to force a wrapper of
> some sort, so the code above becomes:
> p = eo_ref(efl_file_set());
> ... // Code from before
> eo_del(p);

Amazing, we are more or less back to my point. Except that eo_del is
now to be used. The problem is that this break things, first you loose
the parent relationship on promise. So if that was used to actually do
something useful on its lifecycle, you can't anymore. Second problem,
you have to do eo_del only once you have actually sure you will never
cancel that said promise. Otherwise how could you still have a handler
on it somewhere ? If user don't get confused by the fact that they can
stil do an eo_promise_cancel on a promise that has been eo_del...

So if you have to delay eo_del by the time you actually have
cancel/then, hum, you kind of ruined the point of having promise as
you now need to track actively its live cycle and do a del when the
cancel/then you care about happened. Of course this start to be messy
as you don't really know how many callbacks are registered on it and
things kind of fall apart.

If you are willing to accept the confusion that you can call
eo_promise_cancel on an eo_del promise, then your proposition is
doable. I think this is pretty bad.

> Or probably for extra safety (like marking the promise was actually
> used, and not just implicitly with a ref, this will allow us to block
> then/cancel registration and be more safe).
>
> p = 

Re: [E-devel] promises...

[Tom Hacohen]

On 03/06/16 07:42, Carsten Haitzler wrote:
> ok. interacting with promises...
>
> these are just a mess.
>
> 1. the value thing is just odd.
> 2. they are complex to set up inside our api (setting them up setting cancel
> cb's and more)
> 3. they totally screw with what eo and interfaces was all about - making the
> api EASIER to use. promises make it harder.
>
> why harder? longer lines of code with more parameters and more special
> casing... but the WORST...
>
>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
>
> that's a promise cb
>
>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
>
> and that's an event cb. they are different. eo events were meant to simplify
> and unify our callback handling. to have a single cb signature. now promises
> break that. this is just bad.
>
> i wasn't sold on promises. i was skeptical, but whatever... but now i am 
> seeing
> they are visibly making things worse. code is harder to write, harder to read,
> harder to maintain, harder to get right. now we have timeouts that cannot
> repeat. no - creating a new timer in the cb is not repeating. it has to repeat
> with the "zero time" being the time when the timer was ticked off, not "now".
>
> please - everyone. take a look at promises and how they are used. forget all 
> of
> the "but node.js has them" and all the "i can chain promises" and so on. the
> BASIC usage of them is harder now in efl.
>
> what to do? well... minimize their use for one. do not use them unless you
> ABSOLUTELY HAVE TO. also promises should become eo objects with event cb's so
> they work just like everything else. i can ref, unref, delete and whatever 
> them
> like everything else.
>
> right now i think promises are just not in a shape to use or ship. they need a
> lot more work. i think we need to drop them for efl 1.18 and defer for efl 2.0
>

Guys, you bored me to death with this thread. I replied to what looked 
like it needed attention, but please let me know if there's anything 
specific I missed that warrants my reply.

I would like to add my take on promises too. As you may remember, I've 
objected to promises from the start. I just didn't see a sensible way of 
implementing them back then, and unfortunately, even after they've been 
implemented, I still don't think they are done nicely.
Here are a few of my comments on what I think needs to change. It is all 
based on things people talked to me about in the past and asked me, I 
haven't actually played with promises, sorry, no time. I don't know what 
is done with "value" that raster and jp mentioned, and I don't know 
about the type safety there (though it looked abysmal).

Lets start with life-cycle: Eo is great, and I think using Eo is the 
right way to go, but unfortunately that doesn't solve our life-cycle 
issue. When do promises die?

p = efl_file_set()...
// Delete here if file has been set?
promise_then_add(p, cb)
// Delete here if file has been set?
promise_then_add(p, cb2);
// Delete here if file has been set?
... // a million years into the future
// Delete here if file has been set?

There is just no sensible way to do it automatically. You will *always* 
have to unref, so following the above example:

p = efl_file_set()
... // All of the code before
eo_del(p); // It'll only die here

Which won't work because then ignoring efl_file_set's output won't be 
allowed.

The only sensible way of doing it, I guess, is to force a wrapper of 
some sort, so the code above becomes:
p = eo_ref(efl_file_set());
... // Code from before
eo_del(p);

Or probably for extra safety (like marking the promise was actually 
used, and not just implicitly with a ref, this will allow us to block 
then/cancel registration and be more safe).

p = efl_promise_use(efl_file_set());
... // Code from before
eo_del(p);

efl_promise_use will set a flag in the promise so that
p = efl_file_set();
promise_then_add(p); // This will fail because the flag wasn't set.

So that's safe and probably the way to go. This will let us manage 
life-cycle correctly.



Usage of event callbacks: I mentioned it somewhere else in the thread, 
but not as bluntly. I think Marcel is wrong, and I think you guys are 
focusing too much on non-existent semantics. Saying promises are 
callbacks that are only called once so they are inherently different 
from event callbacks is absolutely wrong. Think of EO_EVENT_DEL, called 
when object is deleted, only called once. You are too fixated with how 
events happen to be implemented in eo.base, don't.
As I also said, overriding callback_add and adding there code to call 
the callback immediately if the promise has already finished is 
*exactly* the way to go. Also, you don't need to remove callbacks once 
they have been executed, they just happen to never be called again 
because the callback is never triggered again.



Splitting of promise to two objects, owner and future: unnecessary. 
There are a few mechanisms in Eo to let you have different "access" to 
an 

Re: [E-devel] promises...

[Cedric BAIL]

On Thu, Jun 16, 2016 at 11:29 AM, Tom Hacohen  wrote:
> On 16/06/16 10:47, Carsten Haitzler wrote:
>> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André  
>> said:
> The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> approach to stop processing events.

 That is off topic, but seriously something we should consider asap if
 we want to drop the return type of event. I have not any case in mind
 where returning EINA_FALSE make sense. Should we drop it ?
>>>
>>> I am also thinking we should drop it.
>>> Pretty sure the few places that return EINA_FALSE right now are actually
>>> mistakes and sources of bugs.
>>
>> i think so too. drop the return.
>
> The return is mega useful, though I'm open to implementing it
> differently. The return is there so you can filter events. We currently
> have things like "on_hold" in input events to mark an event has been
> processed and should stop propagating, but the return lets you stop the
> callback. I guess we can change it to be "eo_event_callback_stop(obj)".
> Btw, it shouldn't be a bool, there are defines for the return values. I
> should have typedeffed the type. I'm open to changing to
> eo_event_callback_stop though, just let me know.

on_hold boolean is gone from efl input event. JP did some magic here
as this would have never worked with bindings, basically using an Eo
object to set the flag.

> Grep for EO_EVENT_STOP, it is already used by code, even code I didn't
> write. :)

git grep return nothing on efl tree for me.
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Cedric BAIL]

On Thu, Jun 16, 2016 at 11:13 AM, Tom Hacohen  wrote:
> On 03/06/16 20:17, Cedric BAIL wrote:
> 
 also promises should become eo objects with event cb's
 so they work just like everything else. i can ref, unref, delete and 
 whatever
 them like everything else.
>>
>> As said above, this does work. Example with event :
>> eo_promise = efl_file_set(image, "toto.jpg", NULL);
>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>>
>> In this 3 lines, there is already 2 case in which that fail. First if,
>> the object is done before the callback is set, data are lost and there
>> is no way to get any event. Ofcourse, we can override the behavior of
>> events on this eo_promise completely. Now let's imagine, that we
>> actually do always store the events, so that everytime someone
>> register a callback we can send the event. Still you can't auto del
>> the object at any point in time, you have to force the user to
>> implement the eo_del and to always provide both a then and cancel
>> callback.
>>
>> Other possibility, it is an event on the object itself.
>> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
>> efl_file_set(image, "toto.jpg", NULL);
>> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>>
>> Same again, this can not work. The first group of event handler,
>> promise_callbacks1(), may actually be triggered by a previously
>> running promise on the object, so you have to first forcefully stop
>> the previous operation. This would add complexity. And still the
>> second callback has the same issue as the previous case, if it is a
>> normal eo event, it could have been triggered before any callback get
>> registered and the event be lost... Same story short, doesn't work.
>>
>
> I'm currently reading through the thread, and I didn't see anything
> mentioned about this other than a casual remark you made, so just wanted
> to make it crystal clear regarding implementing it as an Eo object.
> The whole point/magic of inheritance is that you can and are supposed to
> override functions if needed. Overriding callback add to call the
> callback immediately upon addition (if already done) is how I would
> implement promise callbacks. It's clean, easy and as intended. This is
> definitely not a problem.

I hope that by the end of this thread you do understand why this
doesn't work. Basically the point is that you don't have to eo_del a
promise ever. Once you set the callback on it and when all the
expected callback are called, the promise vanish. Inheritance on
callback, that is a given, thanks. Now, how do you make sure you have
all the callback registered and that you have delivered the value to
everyone that expect it before the promise commit succide ?
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

God, walls of text. :)

I think you are confusing a few things which is where your disagreement 
with raster comes from. More on that below.


On 16/06/16 01:28, Cedric BAIL wrote:
> On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler  
> wrote:
>> On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL  said:
>>> Ok, I am giving up on this. We will make it an eo object, but not an
>>> eolian one as it should be a native type for any binding (It is sure
>>> that C++, Lua and JS will have to do a manual binding for it) as there
>>> is very little case were inheritance make sense on promise and
>>> wouldn't at the same time break binding. eina_promise_owner will
>>> become eo_promise and eina_promise will become eo_future (to follow
>>> C++ naming convention). Not to sure how to limit the interface exposed
>>> by a return type as we don't want the user of the API to access the
>>> promise API, just the future one. Double object would be annoying, but
>>> is likely the only solution. So if we want to be safe, we will need to
>>> use 2 objects per promise. One facing the user of the API and one used
>>> by the producer of the API. If we don't want to be safe, we can merge
>>> both API and just use inheritance. So returning an eo_future interface
>>> in the API, while in fact eo_promise function would work on it.
>>
>> what api should not be used? a lot of not most will need to be bound and
>> exposed so you can CREATE a promise - e.g. if you create a new class in js 
>> and
>> want to return promises or set them up etc. etc.
>
> There is two part to a promise. C++ is clearer on this. It define one
> side to be the promise and the other to be the future. The future is
> what deliver the value. You can cancel it and it is what you actually
> get from any API that provide something using promise. Promise is what
> the owner, the creator of the promise use internally to set value on
> or trigger cancel. The user of the future is not supposed to ever call
> value set on the future. This is for type safety obviously.

As raster said, you can use @protected for that. This is a very good 
example to why protected exists in languages like C++ and in Eo. 
Protected means: do not call this function if you are not the one 
implementing this class, inheriting from it, or in eolian we also added: 
managing the object, because C is different. This is a prime example of 
where protected should be used, and with only one object.

If you want, another thing you can do, which is a pattern I've used 
before is something like this:
Efl.Promise.Future
Efl.Promise.Owner - inherits from Future and extends it to add the 
aforementioned management functions.

You create an Efl.Promise.Owner internally, but return it as 
Efl.Promise.Future. It won't really matter in C, but in bindings they'll 
see the type as Future, so they won't have access to the functions.

I like the protected approach better in this case.

>
>> and why not eolian. eo base uses eolian. you can make methods @protected for
>> example... and why not inheritance? adding progress events to me at least is
>> taking the basic promise without them and extending by adding. it's even then
>> typesafe in c++ - you cant listen for progress on a promise that does not
>> provide it. we don't do it right now but for events we could also type check 
>> in
>> c too to see what events that class supports and runtime error/reject.
>
> As said, you can not automatically bind a promise. It is a native type
> for every possible binding. It also make little sense to actually
> inherit in that case as that inherited type would be unavailable to
> any binding obviously. Following C++ naming, future are defined by
> having 3 events (then, cancel and progress) with a guaranty that
> either then or cancel will happen. As for promise, they allow the
> delivery of a value that may be associated with some progress and can
> also fail. The scope of promise is well defined and has been used like
> this for years in other language (It even managed to land in C++  and
> JS standard).
>
> Also this is part of the language of eolian. You define a promise that
> return a future value, like promise. Promise is a future
> container to that type. As stated above, binding will have no clue
> what to do with a a new container that they have never heard off.
> Especially if there is a new behavior needed to be implemented to
> finish the task. If a promise is not defined by then/cancel/progress,
> it is likely to break its integration with _all/_race and any module
> that use promise in any bindings. Basically if you add undefined
> event, that promise is unusable in any binding.

This is the confusion I was referring to earlier. Eo.Base was also not 
always automatically bound, but using eolian to create the class and 
expose the functions is still useful. Eolian is great, we use it for 
docs generation, simplification of code and etc. Use it, just add 
special treatment in 

Re: [E-devel] promises...

[Tom Hacohen]

On 03/06/16 20:17, Cedric BAIL wrote:

>>> also promises should become eo objects with event cb's
>>> so they work just like everything else. i can ref, unref, delete and 
>>> whatever
>>> them like everything else.
>
> As said above, this does work. Example with event :
> eo_promise = efl_file_set(image, "toto.jpg", NULL);
> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL);
> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL);
>
> In this 3 lines, there is already 2 case in which that fail. First if,
> the object is done before the callback is set, data are lost and there
> is no way to get any event. Ofcourse, we can override the behavior of
> events on this eo_promise completely. Now let's imagine, that we
> actually do always store the events, so that everytime someone
> register a callback we can send the event. Still you can't auto del
> the object at any point in time, you have to force the user to
> implement the eo_del and to always provide both a then and cancel
> callback.
>
> Other possibility, it is an event on the object itself.
> eo_event_callback_array_add(image, promise_callbacks1(), NULL);
> efl_file_set(image, "toto.jpg", NULL);
> eo_event_callback_array_add(image, promise_callbacks2(), NULL);
>
> Same again, this can not work. The first group of event handler,
> promise_callbacks1(), may actually be triggered by a previously
> running promise on the object, so you have to first forcefully stop
> the previous operation. This would add complexity. And still the
> second callback has the same issue as the previous case, if it is a
> normal eo event, it could have been triggered before any callback get
> registered and the event be lost... Same story short, doesn't work.
>

I'm currently reading through the thread, and I didn't see anything 
mentioned about this other than a casual remark you made, so just wanted 
to make it crystal clear regarding implementing it as an Eo object.
The whole point/magic of inheritance is that you can and are supposed to 
override functions if needed. Overriding callback add to call the 
callback immediately upon addition (if already done) is how I would 
implement promise callbacks. It's clean, easy and as intended. This is 
definitely not a problem.



--
Tom.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Tom Hacohen]

On 16/06/16 10:47, Carsten Haitzler wrote:
> On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André  
> said:
>
>
 The ON_HOLD flag, now called efl_event_processed_get/set() is a better
 approach to stop processing events.
>>>
>>> That is off topic, but seriously something we should consider asap if
>>> we want to drop the return type of event. I have not any case in mind
>>> where returning EINA_FALSE make sense. Should we drop it ?
>>>
>>
>> I am also thinking we should drop it.
>> Pretty sure the few places that return EINA_FALSE right now are actually
>> mistakes and sources of bugs.
>
> i think so too. drop the return.
>

The return is mega useful, though I'm open to implementing it 
differently. The return is there so you can filter events. We currently 
have things like "on_hold" in input events to mark an event has been 
processed and should stop propagating, but the return lets you stop the 
callback. I guess we can change it to be "eo_event_callback_stop(obj)". 
Btw, it shouldn't be a bool, there are defines for the return values. I 
should have typedeffed the type. I'm open to changing to 
eo_event_callback_stop though, just let me know.

Grep for EO_EVENT_STOP, it is already used by code, even code I didn't 
write. :)

--
Tom.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Thu, 16 Jun 2016 14:28:22 +0900 Jean-Philippe André  said:


> > > The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> > > approach to stop processing events.
> >
> > That is off topic, but seriously something we should consider asap if
> > we want to drop the return type of event. I have not any case in mind
> > where returning EINA_FALSE make sense. Should we drop it ?
> >
> 
> I am also thinking we should drop it.
> Pretty sure the few places that return EINA_FALSE right now are actually
> mistakes and sources of bugs.

i think so too. drop the return.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Jean-Philippe André]

Hi,

On 16 June 2016 at 05:41, Cedric BAIL  wrote:

> Hello,
>
> Ok, I am giving up on this. We will make it an eo object, but not an
> eolian one as it should be a native type for any binding (It is sure
> that C++, Lua and JS will have to do a manual binding for it) as there
> is very little case were inheritance make sense on promise and
> wouldn't at the same time break binding. eina_promise_owner will
> become eo_promise and eina_promise will become eo_future (to follow
> C++ naming convention). Not to sure how to limit the interface exposed
> by a return type as we don't want the user of the API to access the
> promise API, just the future one. Double object would be annoying, but
> is likely the only solution. So if we want to be safe, we will need to
> use 2 objects per promise. One facing the user of the API and one used
> by the producer of the API. If we don't want to be safe, we can merge
> both API and just use inheritance. So returning an eo_future interface
> in the API, while in fact eo_promise function would work on it.
>
> On Mon, Jun 13, 2016 at 7:23 PM, Jean-Philippe André 
> wrote:
> > On 14 June 2016 at 02:28, Felipe Magno de Almeida <
> > felipe.m.alme...@gmail.com> wrote:
> >> Sorry for top-posting. But let me summarize the Promise lifetime:
>


> >>
> >> Eina_Promise* p = ...;
> >> eina_promise_all(p, ...);
> >> // promise will be deleted
> >> // when callback for the then is called
> >
> > So my understanding here is that this can work because a promise can not
> > ever be synchronous.
> > In other words, eina_promise_then can never trigger the success/error
> > callback to be called synchronously, otherwise the above reference count
> > system falls apart.
> >
> > While this approach is convenient, it means that we can use an object
> > (promise) we don't hold any reference on (after first _then).
> > This is weird :)
>
> Agreed.
>

Ok




>
> > The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> > approach to stop processing events.
>
> That is off topic, but seriously something we should consider asap if
> we want to drop the return type of event. I have not any case in mind
> where returning EINA_FALSE make sense. Should we drop it ?
>

I am also thinking we should drop it.
Pretty sure the few places that return EINA_FALSE right now are actually
mistakes and sources of bugs.



>
> >> >> Anyway it seems the only difference here is that a promise starts the
> >> >> action as soon as possible, while an eo object would have to
> >> explicitely be
> >> >> marked as ready (which is very similar to starting the action during
> >> >> eina_promise_then).
> >> >
> >> > No, the main difference is that the life cycle is linked to the
> >> > callbacks and that their should not be any way to bypass it. eo_del
> >> > should also be forbidden for example on a promise as only a cancel
> >> > make sense. Of course we could alias it, and make sure that cancel
> >> > don't destroy the parent. We can also override all eo event API and
> >> > make sure they do what we want, but we can't at the moment override
> >> > eo_ref and eo_unref. The alternative would be to create an Eo_Promise
> >> > which doesn't inherit from Eo_Base (Or make an Eo_Light that both
> >> > would inherit from) and would kind of make clear that it is not an Eo
> >> > object, but a promise object (Given that eo_ref and eo_unref become
> >> > virtual function).
> >> >
> >> > Also at which point do you think user are going to be confused by an
> >> > Eo object where every single function call on it has its own
> >> > documentation and doesn't behave like a normal eo object ?
> >
> > That's where we still disagree :)
> >
> > I still have trouble understanding how fundamentally different those two
> > objects are.
> > In fact I see a lot of similarities between a (conceptual) promise and
> > Efl.Part.
> >
> > From my understanding, the main difference is that a promise callback
> WILL
> > be called, be it the error or success, one of them will be, for each
> _then,
> > _race and _all that was setup. Which can be enforced with a commit
> approach:
> >
> > // same syntax as eina_promise:
> > p = promise_function(obj)
> > eo_promise_then(p, _success, _error, data) // this is a HELPER based on
> eo
> > events, implemented in Eo.Promise, steals the ref
> >
> >
> > // it would be equivalent to:
> > p = promise_function(obj)
> > eo_event_callback_add(p, PROMISE_EVENT_FAILURE, _error, data)
> > eo_event_callback_add(p, PROMISE_EVENT_SUCCESS, _success, data)
> > eo_promise_commit(p) // steals the ref
> >
> >
> > // or:
> > p = promise_function(obj)
> > eo_event_callback_add(p, PROGRESS_EVENT, _progress, data)
> > eo_event_callback_add(p, PROMISE_EVENT_SUCCESS, _success, data)
> > eo_event_callback_add(p, PROMISE_EVENT_SUCCESS, _success_watcher, data)
> > eo_event_callback_add(p, PROMISE_CANCEL_SUCCESS, _canceled, data)
> > eo_wref_add(p, )
> > eo_data_key_set(p, "my data", 

Re: [E-devel] promises...

[Cedric BAIL]

On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler  wrote:
> On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL  said:
>> Ok, I am giving up on this. We will make it an eo object, but not an
>> eolian one as it should be a native type for any binding (It is sure
>> that C++, Lua and JS will have to do a manual binding for it) as there
>> is very little case were inheritance make sense on promise and
>> wouldn't at the same time break binding. eina_promise_owner will
>> become eo_promise and eina_promise will become eo_future (to follow
>> C++ naming convention). Not to sure how to limit the interface exposed
>> by a return type as we don't want the user of the API to access the
>> promise API, just the future one. Double object would be annoying, but
>> is likely the only solution. So if we want to be safe, we will need to
>> use 2 objects per promise. One facing the user of the API and one used
>> by the producer of the API. If we don't want to be safe, we can merge
>> both API and just use inheritance. So returning an eo_future interface
>> in the API, while in fact eo_promise function would work on it.
>
> what api should not be used? a lot of not most will need to be bound and
> exposed so you can CREATE a promise - e.g. if you create a new class in js and
> want to return promises or set them up etc. etc.

There is two part to a promise. C++ is clearer on this. It define one
side to be the promise and the other to be the future. The future is
what deliver the value. You can cancel it and it is what you actually
get from any API that provide something using promise. Promise is what
the owner, the creator of the promise use internally to set value on
or trigger cancel. The user of the future is not supposed to ever call
value set on the future. This is for type safety obviously.

> and why not eolian. eo base uses eolian. you can make methods @protected for
> example... and why not inheritance? adding progress events to me at least is
> taking the basic promise without them and extending by adding. it's even then
> typesafe in c++ - you cant listen for progress on a promise that does not
> provide it. we don't do it right now but for events we could also type check 
> in
> c too to see what events that class supports and runtime error/reject.

As said, you can not automatically bind a promise. It is a native type
for every possible binding. It also make little sense to actually
inherit in that case as that inherited type would be unavailable to
any binding obviously. Following C++ naming, future are defined by
having 3 events (then, cancel and progress) with a guaranty that
either then or cancel will happen. As for promise, they allow the
delivery of a value that may be associated with some progress and can
also fail. The scope of promise is well defined and has been used like
this for years in other language (It even managed to land in C++  and
JS standard).

Also this is part of the language of eolian. You define a promise that
return a future value, like promise. Promise is a future
container to that type. As stated above, binding will have no clue
what to do with a a new container that they have never heard off.
Especially if there is a new behavior needed to be implemented to
finish the task. If a promise is not defined by then/cancel/progress,
it is likely to break its integration with _all/_race and any module
that use promise in any bindings. Basically if you add undefined
event, that promise is unusable in any binding.

> if you now need not just progress but some other event along the way to
> completion, just inherit class and extend.

It is most likely that you are trying to squeeze 2 promise into one or
something that is not a promise to a value, but something else.
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL  said:

> Hello,
> 
> Ok, I am giving up on this. We will make it an eo object, but not an
> eolian one as it should be a native type for any binding (It is sure
> that C++, Lua and JS will have to do a manual binding for it) as there
> is very little case were inheritance make sense on promise and
> wouldn't at the same time break binding. eina_promise_owner will
> become eo_promise and eina_promise will become eo_future (to follow
> C++ naming convention). Not to sure how to limit the interface exposed
> by a return type as we don't want the user of the API to access the
> promise API, just the future one. Double object would be annoying, but
> is likely the only solution. So if we want to be safe, we will need to
> use 2 objects per promise. One facing the user of the API and one used
> by the producer of the API. If we don't want to be safe, we can merge
> both API and just use inheritance. So returning an eo_future interface
> in the API, while in fact eo_promise function would work on it.

what api should not be used? a lot of not most will need to be bound and
exposed so you can CREATE a promise - e.g. if you create a new class in js and
want to return promises or set them up etc. etc.

and why not eolian. eo base uses eolian. you can make methods @protected for
example... and why not inheritance? adding progress events to me at least is
taking the basic promise without them and extending by adding. it's even then
typesafe in c++ - you cant listen for progress on a promise that does not
provide it. we don't do it right now but for events we could also type check in
c too to see what events that class supports and runtime error/reject.

if you now need not just progress but some other event along the way to
completion, just inherit class and extend.

> On Mon, Jun 13, 2016 at 7:23 PM, Jean-Philippe André 
> wrote:
> > On 14 June 2016 at 02:28, Felipe Magno de Almeida <
> > felipe.m.alme...@gmail.com> wrote:
> >> Sorry for top-posting. But let me summarize the Promise lifetime:
> >>
> >> A Promise when created starts with a ref-count of 1.
> >> If the promise is not needed anymore, it should be
> >> unref'ed (if no eina_promise_then is made, either
> >> directly or by eina_promise_all/eina_promise_race).
> >>
> >> The first eina_promise_then _steals_ the first
> >> reference, the others eina_promise_then
> >> increments the reference count.
> >>
> >> When the promise is fulfilled (by value_set or error_set),
> >> then each call to a eina_promise_then decrements
> >> the reference count by 1.
> >>
> >> When the reference count reaches 0 _and_ the
> >> promise is fulfilled the promise is deleted (both
> >> conditions must be true, if just one is true it
> >> continues to exist).
> >>
> >> So, valid cases:
> >>
> >> Eina_Promise* p = ..;
> >> eina_promise_then(p, ...);
> >> // promise will be deleted
> >> // when callback for the then is called
> >>
> >> Eina_Promise* p = ...;
> >> eina_promise_unref(p);
> >> // Promise will be freed when promise is fulfilled
> >> // by error_set or value_set
> >>
> >> Eina_Promise* p = ...;
> >> eina_promise_then(p, ...);
> >> eina_promise_then(p, ...);
> >> // promise will be deleted
> >> // when callback for the then is called
> >>
> >> Eina_Promise* p = ...;
> >> eina_promise_all(p, ...);
> >> eina_promise_then(p, ...);
> >> // promise will be deleted
> >> // when callback for the then is called
> >>
> >> Eina_Promise* p = ...;
> >> eina_promise_all(p, ...);
> >> // promise will be deleted
> >> // when callback for the then is called
> >
> > So my understanding here is that this can work because a promise can not
> > ever be synchronous.
> > In other words, eina_promise_then can never trigger the success/error
> > callback to be called synchronously, otherwise the above reference count
> > system falls apart.
> >
> > While this approach is convenient, it means that we can use an object
> > (promise) we don't hold any reference on (after first _then).
> > This is weird :)
> 
> Agreed.
> 
> >> Etc..
> >>
> >> On Mon, Jun 13, 2016 at 2:17 PM, Cedric BAIL  wrote:
> >> > Hello,
> >> >
> >> > On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André 
> >> wrote:
> >> >> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
> >> >>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  >> >
> >> >>> wrote:
> >> >>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
> >> >>> said:
> 
> 
> 
> >>> Events are the same: they call a callback function with a user data and
> >> an
> >> >> event info (promise value).
> >> >
> >> > No. Event in promise will keep their value until all the reference to
> >> > the promise exist and each time that a callback is triggered that
> >> > reference count goes down by one. There is also an absolute guaranty
> >> > that you can not destroy a promise without having all the 

Re: [E-devel] promises...

[Cedric BAIL]

Hello,

Ok, I am giving up on this. We will make it an eo object, but not an
eolian one as it should be a native type for any binding (It is sure
that C++, Lua and JS will have to do a manual binding for it) as there
is very little case were inheritance make sense on promise and
wouldn't at the same time break binding. eina_promise_owner will
become eo_promise and eina_promise will become eo_future (to follow
C++ naming convention). Not to sure how to limit the interface exposed
by a return type as we don't want the user of the API to access the
promise API, just the future one. Double object would be annoying, but
is likely the only solution. So if we want to be safe, we will need to
use 2 objects per promise. One facing the user of the API and one used
by the producer of the API. If we don't want to be safe, we can merge
both API and just use inheritance. So returning an eo_future interface
in the API, while in fact eo_promise function would work on it.

On Mon, Jun 13, 2016 at 7:23 PM, Jean-Philippe André  wrote:
> On 14 June 2016 at 02:28, Felipe Magno de Almeida <
> felipe.m.alme...@gmail.com> wrote:
>> Sorry for top-posting. But let me summarize the Promise lifetime:
>>
>> A Promise when created starts with a ref-count of 1.
>> If the promise is not needed anymore, it should be
>> unref'ed (if no eina_promise_then is made, either
>> directly or by eina_promise_all/eina_promise_race).
>>
>> The first eina_promise_then _steals_ the first
>> reference, the others eina_promise_then
>> increments the reference count.
>>
>> When the promise is fulfilled (by value_set or error_set),
>> then each call to a eina_promise_then decrements
>> the reference count by 1.
>>
>> When the reference count reaches 0 _and_ the
>> promise is fulfilled the promise is deleted (both
>> conditions must be true, if just one is true it
>> continues to exist).
>>
>> So, valid cases:
>>
>> Eina_Promise* p = ..;
>> eina_promise_then(p, ...);
>> // promise will be deleted
>> // when callback for the then is called
>>
>> Eina_Promise* p = ...;
>> eina_promise_unref(p);
>> // Promise will be freed when promise is fulfilled
>> // by error_set or value_set
>>
>> Eina_Promise* p = ...;
>> eina_promise_then(p, ...);
>> eina_promise_then(p, ...);
>> // promise will be deleted
>> // when callback for the then is called
>>
>> Eina_Promise* p = ...;
>> eina_promise_all(p, ...);
>> eina_promise_then(p, ...);
>> // promise will be deleted
>> // when callback for the then is called
>>
>> Eina_Promise* p = ...;
>> eina_promise_all(p, ...);
>> // promise will be deleted
>> // when callback for the then is called
>
> So my understanding here is that this can work because a promise can not
> ever be synchronous.
> In other words, eina_promise_then can never trigger the success/error
> callback to be called synchronously, otherwise the above reference count
> system falls apart.
>
> While this approach is convenient, it means that we can use an object
> (promise) we don't hold any reference on (after first _then).
> This is weird :)

Agreed.

>> Etc..
>>
>> On Mon, Jun 13, 2016 at 2:17 PM, Cedric BAIL  wrote:
>> > Hello,
>> >
>> > On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André 
>> wrote:
>> >> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
>> >>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler > >
>> >>> wrote:
>> >>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
>> >>> said:



>>> Events are the same: they call a callback function with a user data and
>> an
>> >> event info (promise value).
>> >
>> > No. Event in promise will keep their value until all the reference to
>> > the promise exist and each time that a callback is triggered that
>> > reference count goes down by one. There is also an absolute guaranty
>> > that you can not destroy a promise without having all the reference
>> > receiving either a succeed or a fail. Also the returned value of an
>> > event handler for then or cancel should be ignored as you can not stop
>> > notifying anyone in the chain and the state should stay either success
>> > or failure once it has been decided.
>>
>
> It is actually a good question whether the return bool is a good idea or
> not.
> If you return false in evas callbacks, you're gonna be in trouble.
>
> The ON_HOLD flag, now called efl_event_processed_get/set() is a better
> approach to stop processing events.

That is off topic, but seriously something we should consider asap if
we want to drop the return type of event. I have not any case in mind
where returning EINA_FALSE make sense. Should we drop it ?



>> >> Anyway it seems the only difference here is that a promise starts the
>> >> action as soon as possible, while an eo object would have to
>> explicitely be
>> >> marked as ready (which is very similar to starting the action during
>> >> eina_promise_then).
>> >
>> > No, the main difference is that the life 

Re: [E-devel] promises...

[The Rasterman]

On Wed, 8 Jun 2016 10:07:33 -0700 Cedric BAIL  said:

> On Wed, Jun 8, 2016 at 8:10 AM,   wrote:
> > On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
> >>
> >  [...]
> >> they should be eo objects.
> >
> > I wondered in the beginning why promises are not a eo object, comparing the
> > two models shows that it can be dangerous moving promises to a Eo.Base
> > class.
> >
> > Take a look at the events, when in a promise the then callback is
> > called the callback is unsubscribed, and never called again. When a then
> > callback is attached after the value is set the then callback is called
> > while beeing added. So this is a completly different sematic compared to
> > Eo.Base. Of course a implementation can be treated to do smth. like
> > that, but i think its confusing to users of a api, if objects behave
> > differently under the same base api.
> >
> > Also when attaching a then_cb you will get a ref of the promise, so as
> > long as your then_cb is not called the promise will not be freed. This
> > is also something which does not play with the ref/unref system of
> > Eo.Base.
> >
> > Basically you can say, after the then_cb you just have to nuke your
> > reference to your promise, at the best dont keep a reference to it.
> >
> > So all in all the concept of A Promise inheriting from Eo.Base doesnt
> > sound sane to me, and looks like a huge confusion you can get in. So I
> > would prefer to keep the promises as they are, exept the idea of using
> > Eo_Id to make the pointer more secure.
> 
> Good point. It should have been a generic infrastructure anyway. Will
> work on that.

Don't do this.. because it shouldn't! promises should be eo objects! don't go
duplicating this in eina just because you can't see that eina promises are
objects.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Wed, 8 Jun 2016 22:37:55 +1000 David Seikel  said:

> I'm just gonna pipe in here a little bit.
> 
> On Wed, 8 Jun 2016 20:16:20 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > > If history tell us, our existing solution is not usable, but prove
> > > me wrong and show me how amazing our current limited set of
> > > asynchronous API is used by so many people. Now just think that we
> > > are expanding  
> > 
> > as above. ecore_con. ecore_con_url, preload, timer, job,
> > animator,  all used.
> 
> I use ecore_con, timer, job, and animator in a couple of my projects.
> The first two I use a lot in my huge project.  ecore_con_url and
> preload I just haven't bothered to try out yet.  I also use EFL
> threads and ecore fd handler for some async stuff.
> 
> There was one thing I was thinking that I might try promises on, once
> the API and arguments are settled, replacing timer and job for
> sequencing some async startup stuff.  That would still leave ecore_con,
> timer, and threads heavily used in that project, but I think that's the
> only place I use job.  Promises as initially described to me seems like
> a slightly better fit than timers and jobs for this startup stuff.
> 
> I've not actually looked at promises yet though, but I agree in
> principle with Raster when he says that things should be consistent and
> use the same infrastructure.  Having said that, now I'm wondering why we
> can't just extend jobs?

actually jobs in current efl are promises, so it's kind of inverted. but
promises are objects. a job is now a promise. you want to track it and
cancel/unref/whatever it hwne you no longer need it. this is why i keep saying
they are objects thus should be eo.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Wed, 8 Jun 2016 17:10:07 +0200 marcel-hollerb...@t-online.de said:

> Hello,
> 
> On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
> >
>  [...]
> > they should be eo objects.
> 
> I wondered in the beginning why promises are not a eo object, comparing the 
> two models shows that it can be dangerous moving promises to a Eo.Base class.

how so?

> Take a look at the events, when in a promise the then callback is
> called the callback is unsubscribed, and never called again. When a then
> callback is attached after the value is set the then callback is called
> while beeing added. So this is a completly different sematic compared to
> Eo.Base. Of course a implementation can be treated to do smth. like
> that, but i think its confusing to users of a api, if objects behave
> differently under the same base api.

i disagree. having eina_promise_ref in addition to eo_ref, having yet another
copy of the oi id indirection to make promise i'ds safe etc. is worse than
making a promise live within eo api. as i keep saying - the solution is worse
than the disease.

we dont HAVE to use eo event callbacks though. we could special case then/else
in eo promises and of course require those to be hand bound specifically. eo
objects that delete after their task is done can be tagged in eo as such
specific objects, just like proxy objects delete themselves after use. it isnt
confusing when its tagged. it's just a PAIN to have eina_promise vs eo_* in c.
in c++, js, lua promises are normal objects with all normal object operations
of referencing, gc'ing, deletion etc. just like eo is for c. in other langs they
use the SAME object api as all other objects, why are they so special in c
where they should not? all they do is cause pain in c. in other langs they are
full blown normal objects as i am saying they should be in c.

we can do:

eo_promise_then(promise, done_cb, err_cb, data);

it's a special manually bound method that has the 2 cb's. all the eina_promise
progress stuff can be dropped and done as eo event extensions. any events until
the done/err can be extended as much as desired via eo callbaks. it nukes a
huge amount of the eina promise api. no need for the progress_cb stuff and only
extend where needed and use normal inheritance/classes for this. have a promise
progress class for anything needing to extend promises to do progress that
inherits from the promise class. and so on...

> Also when attaching a then_cb you will get a ref of the promise, so as
> long as your then_cb is not called the promise will not be freed. This
> is also something which does not play with the ref/unref system of
> Eo.Base.

see above. and we already define proxy objects to specially delete themselves
after their furst use. is this no different to the promise deleting itself
after the then/error cb? it's aproprty of the object. it's specific to
promises. you have to learn this behaviour with eina_promise objects anyway and
in c++, js and lua you have normal "regular objects" that are hiding the
eina_promises that behave exactly this way... so the argument that promises are
somehow special and cant be eo objects falls apart the moment you are in c++,
js or lua where they ARE such objects. so i call the argument "bogus" on the
best of days.

> Basically you can say, after the then_cb you just have to nuke your
> reference to your promise, at the best dont keep a reference to it.

we don't need to tell people to nuke their reference. the obj class just does
an eo_del on itself after calling the then/error cb. you don't need to. if
someone as an extra eo_ref on the obj then it stays alive until that ref is
released - this is exactly how eina promises work now. there is nothing weird
or wrong with eo objects working this way too. they already do - proxy objects
for parts.

> So all in all the concept of A Promise inheriting from Eo.Base doesnt
> sound sane to me, and looks like a huge confusion you can get in. So I
> would prefer to keep the promises as they are, exept the idea of using
> Eo_Id to make the pointer more secure.

i disagree. think of operator overloading in c++. a + may not mean a
mathematical +. i can ave a string lass that makes + append the strings. this
is common. it makes a common tool work appropriately for the task. people seem
to be able to deal with this.

same with eo promise objects. they are objects with a specific behaviour. they
delete after their then/error cb is called. they only allow a single then/error
cb. you CAN add event cb's to listen for their deletion with del events, or you
can extend them with progress cb's etc.

there is no reason the then/else cb's have to be a different cb prototype to eo
event callbacks. the return value can go unused as there are no more cb's to
skip after this so its just a dummy return value. it saves a lot of mental
effort to remember the different callback types. the return doesn't hurt as it
has no effect. the value stuff can be passed in the event info 

Re: [E-devel] promises...

[The Rasterman]

On Sun, 12 Jun 2016 11:02:37 -0700 Cedric BAIL  said:

> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  wrote:
> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL  said:
> 
> 
> 
> >> >> You just can't do with eo event what promise do. Eo event are a
> >> >
> >> > it's not NECESSARY to do anything new. timeout can be an eo obj that
> >> > deletes itself after the one-shot callback. it doesn't need a promise.
> >> > same as job. i can't add promises as children to an obj and make sure
> >> > they get autodeleted when parent is. i have to do this all by hand now.
> >>
> >> It is a terrible mistake to override eo object lifecycle. This is an
> >> absolute no go as a solution. Anything that bypass the refcounting and
> >> ownership of an eo object lead to massive issue and trouble. We can
> >> not implement auto deletion of eo object outside of the reference
> >> count system.
> >
> > this doesn't bypass it. it USES it. the object unrefs/del's itself. when
> > done. when an evas canvas is deleted it deletes all child objects. no code
> > is explicitly in the app deleting the objects. it's done internally.
> 
> That's exactly what I mean by bypass. Evas canvas delete object
> because the parent die. Now, in the case of a promise eo object, there
> is no parent that will disapear to do the unref/del, it is when all
> the listener have received the value, that the promise disapear. If
> you want to use normal eo lifecycle for that, it means that the object
> has to delete itself. And this is bad. This is exactly what
> ecore_timer where historically doing. They were not linked to any
> parent and would just vanish under your feet. This is what tricked you
> into thinking the bug was in the timeout promise while it was in the
> handling of the lifecycle of the timer itself.

and for promises its the "parent action" the download, the async property
fetch, the file load etc. that is the parent conceptually and it deletes the
promise representing it in the wild.

> Reading what you say, you are advocating for using the normal eo
> lifecycle and not letting itself commit succide, which is the proper
> way to handle eo object. Now how can that work with promise ? No idea.

YES I AM. as jp already said. we have proxy objects that self-delete on first
use in another function. promises self-delete when the action is done - same
idea. of course it can work. it works just fine. we do it already. there is no
"proper way" to handle eo deletion other than objects ARE deleted. the
convention is parents del children. del otherwise can happen anywhere by
anything. there is no magical rule otherwise.



> Promise are a promise to deliver something in the future. In themself
> they have no propery and no function. They aren't object, they are

of course they are an object. they old a success/error callback. they HOLD the
value content until suhc a cb can be set to get the value. they can be ref'd
and unref'd and kept around for along as desired. in js, c++ and lua they are
actual objects because these languages ONLY have an object, or a basic
variable. so they are objects there. you keep the object around so you can
cancel it. they are objects. they are as much objects as eo objects are.

> delivering object. Their lifecycle is that they either deliver or
> fail, they never "die" before that. It is a guaranty that they deliver
> a callback whatever happen to everyone that registered to listen them.
> This doesn't match at all eo object lifecycle.

proxy objects. need i say more. they die after first use in another func. and
either way this is a lifecycle SPECIFIED by the promise object. it is HOW they
are meant to work. they are MEANT to delete themselves when done (after calling
success/err callbacks). self deletion isn't something eo forbids at all.

> > you are totally inconsistent thinking promises are some kind of magically
> > special thing that is not an object... yet in all ways it works *IS* an
> > object.
> 
> If you stretch the definition of an object outside of what Eo is, yes,
> but by that standard everything could be an object. If you limit your
> definition to what Eo is and I mean by that Eo lifecycle and events,
> it doesn't. Oh, and there is plenty of stuff in an Eo object that are
> useless for promise.

eo doesn't define an object cannot self delete. so it matches. eo events are
not useless for callbacks - its how you can extend progress etc. it makes far
more sense than what eina_promise has now. it allows inheritance and extension.
eina_promise is totally fixed in stone. and so what if key/value data is not
useful. it doesnt cost anything except a ptr to have as a feature and all eo
objects have it and its not useful on every single object BUT... it's useful
ENOUGH to be in the base class. so what then? a promise uses a bit more ram.
this isnt about ram or efficiency but of usability and eina _promises are FAr
LESS USABLE than if they were eo 

Re: [E-devel] promises...

[Jean-Philippe André]

Hi Felipe & Cedric,


Thanks for explaining the lifecycle in detail, ... but I'm still not
convinced :)


On 14 June 2016 at 02:28, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> wrote:

> Sorry for top-posting. But let me summarize the Promise lifetime:
>
> A Promise when created starts with a ref-count of 1.
> If the promise is not needed anymore, it should be
> unref'ed (if no eina_promise_then is made, either
> directly or by eina_promise_all/eina_promise_race).
>
> The first eina_promise_then _steals_ the first
> reference, the others eina_promise_then
> increments the reference count.
>
> When the promise is fulfilled (by value_set or error_set),
> then each call to a eina_promise_then decrements
> the reference count by 1.
>
> When the reference count reaches 0 _and_ the
> promise is fulfilled the promise is deleted (both
> conditions must be true, if just one is true it
> continues to exist).
>
> So, valid cases:
>
> Eina_Promise* p = ..;
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_unref(p);
> // Promise will be freed when promise is fulfilled
> // by error_set or value_set
>
> Eina_Promise* p = ...;
> eina_promise_then(p, ...);
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_all(p, ...);
> eina_promise_then(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
> Eina_Promise* p = ...;
> eina_promise_all(p, ...);
> // promise will be deleted
> // when callback for the then is called
>
>
So my understanding here is that this can work because a promise can not
ever be synchronous.
In other words, eina_promise_then can never trigger the success/error
callback to be called synchronously, otherwise the above reference count
system falls apart.

While this approach is convenient, it means that we can use an object
(promise) we don't hold any reference on (after first _then).
This is weird :)



> Etc..
>
> Regards,
> --
> Felipe Magno de Almeida
>
>
> On Mon, Jun 13, 2016 at 2:17 PM, Cedric BAIL  wrote:
> > Hello,
> >
> > On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André 
> wrote:
> >> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
> >>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  >
> >>> wrote:
> >>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
> >>> said:
> >>> > and you can do the same with eo - you can store the result until cb's
> >>> added or
> >>> > until a go/done/whatever api is called. but that on;y matters if you
> >>> want a
> >>> > specific cb for that specific action. in general if you want that hen
> >>> you want
> >>> > a real object to be returned so you can manage it like other objects.
> >>>
> >>> As said before, basically what you want is an Eo object which doesn't
> >>> behave like a normal eo object. Having its own meaning for ref/unref,
> >>> for events and life cycle. At this point, I don't see how it will be
> >>> easier for people and not more confusing ?
> >>
> >> Efl.Part are EO objects that die after a single function call.
> >> So, we already have objects with a different lifecycle.
> >
> > Yes, but you are not supposed to interact with that said object more
> > than with just one function. What happen if someone do an
> > eo_ref/eo_unref on it ?
>

You can eo_ref() before calling a function, this gives you a "strong" ref
that you then need to eo_unref() manually as well.
This means you can do:

func(efl_part(obj, "a"))

and:

part = eo_ref(efl_part(obj, "a"))
func1(part)
func2(part)
func3(part)
eo_unref(part)

Only func1() will unref the part object implicitely. An internal flag
insures that func2 and func3 don't also trigger an unref.

The same model could be used for promises that we want to stuff into more
than one _then, _race or _all.


>> Events are the same: they call a callback function with a user data and
> an
> >> event info (promise value).
> >
> > No. Event in promise will keep their value until all the reference to
> > the promise exist and each time that a callback is triggered that
> > reference count goes down by one. There is also an absolute guaranty
> > that you can not destroy a promise without having all the reference
> > receiving either a succeed or a fail. Also the returned value of an
> > event handler for then or cancel should be ignored as you can not stop
> > notifying anyone in the chain and the state should stay either success
> > or failure once it has been decided.
>

It is actually a good question whether the return bool is a good idea or
not.
If you return false in evas callbacks, you're gonna be in trouble.

The ON_HOLD flag, now called efl_event_processed_get/set() is a better
approach to stop processing events.



> >> For how long is a promise handle valid?
> >> Is it valid up until 

Re: [E-devel] promises...

[Cedric BAIL]

On Mon, Jun 13, 2016 at 10:17 AM, Cedric BAIL  wrote:
> On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André  
> wrote:
>> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
>>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler 
>>> wrote:
>>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
>>> said:
>>> > and you can do the same with eo - you can store the result until cb's
>>> added or
>>> > until a go/done/whatever api is called. but that on;y matters if you
>>> want a
>>> > specific cb for that specific action. in general if you want that hen
>>> you want
>>> > a real object to be returned so you can manage it like other objects.
>>>
>>> As said before, basically what you want is an Eo object which doesn't
>>> behave like a normal eo object. Having its own meaning for ref/unref,
>>> for events and life cycle. At this point, I don't see how it will be
>>> easier for people and not more confusing ?
>>
>> Efl.Part are EO objects that die after a single function call.
>> So, we already have objects with a different lifecycle.
>
> Yes, but you are not supposed to interact with that said object more
> than with just one function. What happen if someone do an
> eo_ref/eo_unref on it ?
>
>> Events are the same: they call a callback function with a user data and an
>> event info (promise value).
>
> No. Event in promise will keep their value until all the reference to
> the promise exist and each time that a callback is triggered that
> reference count goes down by one. There is also an absolute guaranty
> that you can not destroy a promise without having all the reference
> receiving either a succeed or a fail. Also the returned value of an
> event handler for then or cancel should be ignored as you can not stop
> notifying anyone in the chain and the state should stay either success
> or failure once it has been decided.
>
>> For how long is a promise handle valid?
>> Is it valid up until eina_promise_then? What if you just stuff the promise
>> in a _race or _all?
>
> A promise is expecting one couple of cancel/then to be registered.
> Once it is, that promise can still be cancelled by the user if it has
> not triggered any of the callback it registered for, any other use
> will be illegal. If it give it to a _race or _all, he obviously loose
> his chance to register callbacks, so if he want to register them, he
> need to increase the ref count.
>
>> Can you ignore a promise handle altogether? (I guess it would leak)
>
> Will leak inded and make no sense as it is delivering something at the
> end of the pipe. If you do not want it, well, why did you ask for it ?
> :-)
>
>> Anyway it seems the only difference here is that a promise starts the
>> action as soon as possible, while an eo object would have to explicitely be
>> marked as ready (which is very similar to starting the action during
>> eina_promise_then).
>
> No, the main difference is that the life cycle is linked to the
> callbacks and that their should not be any way to bypass it. eo_del
> should also be forbidden for example on a promise as only a cancel
> make sense. Of course we could alias it, and make sure that cancel
> don't destroy the parent. We can also override all eo event API and
> make sure they do what we want, but we can't at the moment override
> eo_ref and eo_unref. The alternative would be to create an Eo_Promise
> which doesn't inherit from Eo_Base (Or make an Eo_Light that both
> would inherit from) and would kind of make clear that it is not an Eo
> object, but a promise object (Given that eo_ref and eo_unref become
> virtual function).

After talking with Felipe, we do not need to override ref/unref. It
will just be slightly more verbose to use than current implementation.
Still below question apply.

> Also at which point do you think user are going to be confused by an
> Eo object where every single function call on it has its own
> documentation and doesn't behave like a normal eo object ?
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Felipe Magno de Almeida]

Sorry for top-posting. But let me summarize the Promise lifetime:

A Promise when created starts with a ref-count of 1.
If the promise is not needed anymore, it should be
unref'ed (if no eina_promise_then is made, either
directly or by eina_promise_all/eina_promise_race).

The first eina_promise_then _steals_ the first
reference, the others eina_promise_then
increments the reference count.

When the promise is fulfilled (by value_set or error_set),
then each call to a eina_promise_then decrements
the reference count by 1.

When the reference count reaches 0 _and_ the
promise is fulfilled the promise is deleted (both
conditions must be true, if just one is true it
continues to exist).

So, valid cases:

Eina_Promise* p = ..;
eina_promise_then(p, ...);
// promise will be deleted
// when callback for the then is called

Eina_Promise* p = ...;
eina_promise_unref(p);
// Promise will be freed when promise is fulfilled
// by error_set or value_set

Eina_Promise* p = ...;
eina_promise_then(p, ...);
eina_promise_then(p, ...);
// promise will be deleted
// when callback for the then is called

Eina_Promise* p = ...;
eina_promise_all(p, ...);
eina_promise_then(p, ...);
// promise will be deleted
// when callback for the then is called

Eina_Promise* p = ...;
eina_promise_all(p, ...);
// promise will be deleted
// when callback for the then is called

Etc..

Regards,
--
Felipe Magno de Almeida


On Mon, Jun 13, 2016 at 2:17 PM, Cedric BAIL  wrote:
> Hello,
>
> On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André  
> wrote:
>> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
>>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler 
>>> wrote:
>>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
>>> said:
>>> > and you can do the same with eo - you can store the result until cb's
>>> added or
>>> > until a go/done/whatever api is called. but that on;y matters if you
>>> want a
>>> > specific cb for that specific action. in general if you want that hen
>>> you want
>>> > a real object to be returned so you can manage it like other objects.
>>>
>>> As said before, basically what you want is an Eo object which doesn't
>>> behave like a normal eo object. Having its own meaning for ref/unref,
>>> for events and life cycle. At this point, I don't see how it will be
>>> easier for people and not more confusing ?
>>
>> Efl.Part are EO objects that die after a single function call.
>> So, we already have objects with a different lifecycle.
>
> Yes, but you are not supposed to interact with that said object more
> than with just one function. What happen if someone do an
> eo_ref/eo_unref on it ?
>
>> Events are the same: they call a callback function with a user data and an
>> event info (promise value).
>
> No. Event in promise will keep their value until all the reference to
> the promise exist and each time that a callback is triggered that
> reference count goes down by one. There is also an absolute guaranty
> that you can not destroy a promise without having all the reference
> receiving either a succeed or a fail. Also the returned value of an
> event handler for then or cancel should be ignored as you can not stop
> notifying anyone in the chain and the state should stay either success
> or failure once it has been decided.
>
>> For how long is a promise handle valid?
>> Is it valid up until eina_promise_then? What if you just stuff the promise
>> in a _race or _all?
>
> A promise is expecting one couple of cancel/then to be registered.
> Once it is, that promise can still be cancelled by the user if it has
> not triggered any of the callback it registered for, any other use
> will be illegal. If it give it to a _race or _all, he obviously loose
> his chance to register callbacks, so if he want to register them, he
> need to increase the ref count.
>
>> Can you ignore a promise handle altogether? (I guess it would leak)
>
> Will leak inded and make no sense as it is delivering something at the
> end of the pipe. If you do not want it, well, why did you ask for it ?
> :-)
>
>> Anyway it seems the only difference here is that a promise starts the
>> action as soon as possible, while an eo object would have to explicitely be
>> marked as ready (which is very similar to starting the action during
>> eina_promise_then).
>
> No, the main difference is that the life cycle is linked to the
> callbacks and that their should not be any way to bypass it. eo_del
> should also be forbidden for example on a promise as only a cancel
> make sense. Of course we could alias it, and make sure that cancel
> don't destroy the parent. We can also override all eo event API and
> make sure they do what we want, but we can't at the moment override
> eo_ref and eo_unref. The alternative would be to create an Eo_Promise
> which doesn't inherit from Eo_Base (Or make an Eo_Light that both
> would inherit from) and would kind of make clear that it is 

Re: [E-devel] promises...

[Cedric BAIL]

Hello,

On Sun, Jun 12, 2016 at 10:13 PM, Jean-Philippe André  wrote:
> On 13 June 2016 at 03:02, Cedric BAIL  wrote:
>> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler 
>> wrote:
>> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
>> said:
>> > and you can do the same with eo - you can store the result until cb's
>> added or
>> > until a go/done/whatever api is called. but that on;y matters if you
>> want a
>> > specific cb for that specific action. in general if you want that hen
>> you want
>> > a real object to be returned so you can manage it like other objects.
>>
>> As said before, basically what you want is an Eo object which doesn't
>> behave like a normal eo object. Having its own meaning for ref/unref,
>> for events and life cycle. At this point, I don't see how it will be
>> easier for people and not more confusing ?
>
> Efl.Part are EO objects that die after a single function call.
> So, we already have objects with a different lifecycle.

Yes, but you are not supposed to interact with that said object more
than with just one function. What happen if someone do an
eo_ref/eo_unref on it ?

> Events are the same: they call a callback function with a user data and an
> event info (promise value).

No. Event in promise will keep their value until all the reference to
the promise exist and each time that a callback is triggered that
reference count goes down by one. There is also an absolute guaranty
that you can not destroy a promise without having all the reference
receiving either a succeed or a fail. Also the returned value of an
event handler for then or cancel should be ignored as you can not stop
notifying anyone in the chain and the state should stay either success
or failure once it has been decided.

> For how long is a promise handle valid?
> Is it valid up until eina_promise_then? What if you just stuff the promise
> in a _race or _all?

A promise is expecting one couple of cancel/then to be registered.
Once it is, that promise can still be cancelled by the user if it has
not triggered any of the callback it registered for, any other use
will be illegal. If it give it to a _race or _all, he obviously loose
his chance to register callbacks, so if he want to register them, he
need to increase the ref count.

> Can you ignore a promise handle altogether? (I guess it would leak)

Will leak inded and make no sense as it is delivering something at the
end of the pipe. If you do not want it, well, why did you ask for it ?
:-)

> Anyway it seems the only difference here is that a promise starts the
> action as soon as possible, while an eo object would have to explicitely be
> marked as ready (which is very similar to starting the action during
> eina_promise_then).

No, the main difference is that the life cycle is linked to the
callbacks and that their should not be any way to bypass it. eo_del
should also be forbidden for example on a promise as only a cancel
make sense. Of course we could alias it, and make sure that cancel
don't destroy the parent. We can also override all eo event API and
make sure they do what we want, but we can't at the moment override
eo_ref and eo_unref. The alternative would be to create an Eo_Promise
which doesn't inherit from Eo_Base (Or make an Eo_Light that both
would inherit from) and would kind of make clear that it is not an Eo
object, but a promise object (Given that eo_ref and eo_unref become
virtual function).

Also at which point do you think user are going to be confused by an
Eo object where every single function call on it has its own
documentation and doesn't behave like a normal eo object ?
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[Jean-Philippe André]

Hi Cedric,

On 13 June 2016 at 03:02, Cedric BAIL  wrote:

> On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler 
> wrote:
> > On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL 
> said:
>
> 
>
> >> >> You just can't do with eo event what promise do. Eo event are a
> >> >
> >> > it's not NECESSARY to do anything new. timeout can be an eo obj that
> deletes
> >> > itself after the one-shot callback. it doesn't need a promise. same
> as job.
> >> > i can't add promises as children to an obj and make sure they get
> >> > autodeleted when parent is. i have to do this all by hand now.
> >>
> >> It is a terrible mistake to override eo object lifecycle. This is an
> >> absolute no go as a solution. Anything that bypass the refcounting and
> >> ownership of an eo object lead to massive issue and trouble. We can
> >> not implement auto deletion of eo object outside of the reference
> >> count system.
> >
> > this doesn't bypass it. it USES it. the object unrefs/del's itself. when
> done.
> > when an evas canvas is deleted it deletes all child objects. no code is
> > explicitly in the app deleting the objects. it's done internally.
>
> That's exactly what I mean by bypass. Evas canvas delete object
> because the parent die. Now, in the case of a promise eo object, there
> is no parent that will disapear to do the unref/del, it is when all
> the listener have received the value, that the promise disapear. If
> you want to use normal eo lifecycle for that, it means that the object
> has to delete itself. And this is bad. This is exactly what
> ecore_timer where historically doing. They were not linked to any
> parent and would just vanish under your feet. This is what tricked you
> into thinking the bug was in the timeout promise while it was in the
> handling of the lifecycle of the timer itself.
>
> Reading what you say, you are advocating for using the normal eo
> lifecycle and not letting itself commit succide, which is the proper
> way to handle eo object. Now how can that work with promise ? No idea.
>
> >> > efl model needs to drop promises. ask sanghyeon and sub - they are
> hating to
> >> > work with the promises in efl model - it's massive overkill and
> unneeded.
> >>
> >> If you read the ongoing discussion regarding MVC and the view list
> >> code, you will see that the problem is not the promise, but the fact
> >> that the model is fully asynchronous and that they have to handle it.
> >> Dropping promise out of the model, and they will not only hate, they
> >> will want to jump by the window.
> >
> > it's both. async made it more complex than sync AND promises require a
> unique
> > promise per property on a model object when a simple "property loaded"
> event on
> > the model object would do just fine. the one cb can refresh the item
> mapped to
> > the model object in whole and a property get can just return null etc.
> if the
> > property is not loaded yet. property content has to in the end be cached
> in the
> > model object anyway so this ends up simpler and you don't need a promise
> nor
> > the value - the value is already living in the object under the property.
>
> Returning NULL change absolutely nothing to there problem. It just
> means they have to keep fetching and fetching until they have all the
> property resolved. Even worse, they have now no synchronisation
> primitive to do that for them at all. You know with promise they have
> promise_all to know when everything is finally settle down, because
> there problem was how to find the final size of an item if you don't
> have all it's data. So you need to keep fetching all the property you
> need to display it until they are all there. Then you can stop, learn
> the size and move on. Your solution doesn't simplify that at all and
> you have no synchronisation helper anymore ! It add complexity as this
> is what we had before. As I said, that's what we had before, and it
> was way more complex.
>
> Now in the case where we do force all data to be available before we
> notify them, so that they avoid there problem (which was to wait until
> everything is there), it obviously create delay problem as the time
> needed to finish fetching all  property can be quite long. Expecting
> only to have all data available in one request make absolutely no
> sense. Let's take two examples :
>
> - An avahi model will be able to give you an ip right away, but it
> won't be able to give you the name right away. That part is
> asynchronous. So what do you do ? Wait for the network to be done
> fully filling that entry before you can actually access any of it ?
> This is likely going to be the case with a lot of network model,
> multiple request to build the model delaying the availability of the
> data to until all of it are fetched.
>
> - Io model. If you are listing the content of a directory, you get to
> know right away if it is a file or a directory and you also get the
> filename directly. You 

Re: [E-devel] promises...

[Cedric BAIL]

On Wed, Jun 8, 2016 at 4:16 AM, Carsten Haitzler  wrote:
> On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL  said:



>> >> You just can't do with eo event what promise do. Eo event are a
>> >
>> > it's not NECESSARY to do anything new. timeout can be an eo obj that 
>> > deletes
>> > itself after the one-shot callback. it doesn't need a promise. same as job.
>> > i can't add promises as children to an obj and make sure they get
>> > autodeleted when parent is. i have to do this all by hand now.
>>
>> It is a terrible mistake to override eo object lifecycle. This is an
>> absolute no go as a solution. Anything that bypass the refcounting and
>> ownership of an eo object lead to massive issue and trouble. We can
>> not implement auto deletion of eo object outside of the reference
>> count system.
>
> this doesn't bypass it. it USES it. the object unrefs/del's itself. when done.
> when an evas canvas is deleted it deletes all child objects. no code is
> explicitly in the app deleting the objects. it's done internally.

That's exactly what I mean by bypass. Evas canvas delete object
because the parent die. Now, in the case of a promise eo object, there
is no parent that will disapear to do the unref/del, it is when all
the listener have received the value, that the promise disapear. If
you want to use normal eo lifecycle for that, it means that the object
has to delete itself. And this is bad. This is exactly what
ecore_timer where historically doing. They were not linked to any
parent and would just vanish under your feet. This is what tricked you
into thinking the bug was in the timeout promise while it was in the
handling of the lifecycle of the timer itself.

Reading what you say, you are advocating for using the normal eo
lifecycle and not letting itself commit succide, which is the proper
way to handle eo object. Now how can that work with promise ? No idea.

>> > efl model needs to drop promises. ask sanghyeon and sub - they are hating 
>> > to
>> > work with the promises in efl model - it's massive overkill and unneeded.
>>
>> If you read the ongoing discussion regarding MVC and the view list
>> code, you will see that the problem is not the promise, but the fact
>> that the model is fully asynchronous and that they have to handle it.
>> Dropping promise out of the model, and they will not only hate, they
>> will want to jump by the window.
>
> it's both. async made it more complex than sync AND promises require a unique
> promise per property on a model object when a simple "property loaded" event 
> on
> the model object would do just fine. the one cb can refresh the item mapped to
> the model object in whole and a property get can just return null etc. if the
> property is not loaded yet. property content has to in the end be cached in 
> the
> model object anyway so this ends up simpler and you don't need a promise nor
> the value - the value is already living in the object under the property.

Returning NULL change absolutely nothing to there problem. It just
means they have to keep fetching and fetching until they have all the
property resolved. Even worse, they have now no synchronisation
primitive to do that for them at all. You know with promise they have
promise_all to know when everything is finally settle down, because
there problem was how to find the final size of an item if you don't
have all it's data. So you need to keep fetching all the property you
need to display it until they are all there. Then you can stop, learn
the size and move on. Your solution doesn't simplify that at all and
you have no synchronisation helper anymore ! It add complexity as this
is what we had before. As I said, that's what we had before, and it
was way more complex.

Now in the case where we do force all data to be available before we
notify them, so that they avoid there problem (which was to wait until
everything is there), it obviously create delay problem as the time
needed to finish fetching all  property can be quite long. Expecting
only to have all data available in one request make absolutely no
sense. Let's take two examples :

- An avahi model will be able to give you an ip right away, but it
won't be able to give you the name right away. That part is
asynchronous. So what do you do ? Wait for the network to be done
fully filling that entry before you can actually access any of it ?
This is likely going to be the case with a lot of network model,
multiple request to build the model delaying the availability of the
data to until all of it are fetched.

- Io model. If you are listing the content of a directory, you get to
know right away if it is a file or a directory and you also get the
filename directly. You need another system call to get size and access
right which will take longer. Also at some point we should integrate
with efreet to allow easy linking of the type of the file to an icon
name that could be connected to efl.ui.icon. Obviously the time

Re: [E-devel] promises...

[Cedric BAIL]

On Wed, Jun 8, 2016 at 8:10 AM,   wrote:
> On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
>>
>  [...]
>> they should be eo objects.
>
> I wondered in the beginning why promises are not a eo object, comparing the
> two models shows that it can be dangerous moving promises to a Eo.Base class.
>
> Take a look at the events, when in a promise the then callback is
> called the callback is unsubscribed, and never called again. When a then
> callback is attached after the value is set the then callback is called
> while beeing added. So this is a completly different sematic compared to
> Eo.Base. Of course a implementation can be treated to do smth. like
> that, but i think its confusing to users of a api, if objects behave
> differently under the same base api.
>
> Also when attaching a then_cb you will get a ref of the promise, so as
> long as your then_cb is not called the promise will not be freed. This
> is also something which does not play with the ref/unref system of
> Eo.Base.
>
> Basically you can say, after the then_cb you just have to nuke your
> reference to your promise, at the best dont keep a reference to it.
>
> So all in all the concept of A Promise inheriting from Eo.Base doesnt
> sound sane to me, and looks like a huge confusion you can get in. So I
> would prefer to keep the promises as they are, exept the idea of using
> Eo_Id to make the pointer more secure.

Good point. It should have been a generic infrastructure anyway. Will
work on that.
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[marcel-hollerbach]

Hello,

On Wed, Jun 08, 2016 at 08:16:20PM +0900, Carsten Haitzler wrote:
>
 [...]
> they should be eo objects.

I wondered in the beginning why promises are not a eo object, comparing the 
two models shows that it can be dangerous moving promises to a Eo.Base class.

Take a look at the events, when in a promise the then callback is
called the callback is unsubscribed, and never called again. When a then
callback is attached after the value is set the then callback is called
while beeing added. So this is a completly different sematic compared to
Eo.Base. Of course a implementation can be treated to do smth. like
that, but i think its confusing to users of a api, if objects behave
differently under the same base api.

Also when attaching a then_cb you will get a ref of the promise, so as
long as your then_cb is not called the promise will not be freed. This
is also something which does not play with the ref/unref system of
Eo.Base.

Basically you can say, after the then_cb you just have to nuke your
reference to your promise, at the best dont keep a reference to it.

So all in all the concept of A Promise inheriting from Eo.Base doesnt
sound sane to me, and looks like a huge confusion you can get in. So I
would prefer to keep the promises as they are, exept the idea of using
Eo_Id to make the pointer more secure.

Greetings
   bu5hm4n

> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

I'm just gonna pipe in here a little bit.

On Wed, 8 Jun 2016 20:16:20 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> > If history tell us, our existing solution is not usable, but prove
> > me wrong and show me how amazing our current limited set of
> > asynchronous API is used by so many people. Now just think that we
> > are expanding  
> 
> as above. ecore_con. ecore_con_url, preload, timer, job,
> animator,  all used.

I use ecore_con, timer, job, and animator in a couple of my projects.
The first two I use a lot in my huge project.  ecore_con_url and
preload I just haven't bothered to try out yet.  I also use EFL
threads and ecore fd handler for some async stuff.

There was one thing I was thinking that I might try promises on, once
the API and arguments are settled, replacing timer and job for
sequencing some async startup stuff.  That would still leave ecore_con,
timer, and threads heavily used in that project, but I think that's the
only place I use job.  Promises as initially described to me seems like
a slightly better fit than timers and jobs for this startup stuff.

I've not actually looked at promises yet though, but I agree in
principle with Raster when he says that things should be consistent and
use the same infrastructure.  Having said that, now I'm wondering why we
can't just extend jobs?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[The Rasterman]

On Mon, 6 Jun 2016 06:01:13 +0200 Cedric BAIL  said:

> >> >> 2. they are complex to set up inside our api (setting them up setting
> >> >> cancel cb's and more)
> >>
> >> What do you mean by that ?
> >
> > look at Efl_Internal_Promise and then needing Eina_Promise_Owner in there
> > and then the wonder of the cancel callback deleting the obj which then also
> > cancels and double-frees and segfaults. promises are totally unsafe.
> 
> Yes, there is some security to add to promise, not a big deal. We need
> to prevent double cancel and prevent reiteration. Added with the magic
> check, should be already pretty much fixed for everything you just did
> describe.

there should be much more. it should be in the eo obj id table or you should
implement a whole new one just for promises. or make them eo objects and one
way or another have promise callbacks work.


> >> You just can't do with eo event what promise do. Eo event are a
> >
> > it's not NECESSARY to do anything new. timeout can be an eo obj that deletes
> > itself after the one-shot callback. it doesn't need a promise. same as job.
> > i can't add promises as children to an obj and make sure they get
> > autodeleted when parent is. i have to do this all by hand now.
> 
> It is a terrible mistake to override eo object lifecycle. This is an
> absolute no go as a solution. Anything that bypass the refcounting and
> ownership of an eo object lead to massive issue and trouble. We can
> not implement auto deletion of eo object outside of the reference
> count system.

this doesn't bypass it. it USES it. the object unrefs/del's itself. when done.
when an evas canvas is deleted it deletes all child objects. no code is
explicitly in the app deleting the objects. it's done internally.


> > efl model needs to drop promises. ask sanghyeon and sub - they are hating to
> > work with the promises in efl model - it's massive overkill and unneeded.
> 
> If you read the ongoing discussion regarding MVC and the view list
> code, you will see that the problem is not the promise, but the fact
> that the model is fully asynchronous and that they have to handle it.
> Dropping promise out of the model, and they will not only hate, they
> will want to jump by the window.

it's both. async made it more complex than sync AND promises require a unique
promise per property on a model object when a simple "property loaded" event on
the model object would do just fine. the one cb can refresh the item mapped to
the model object in whole and a property get can just return null etc. if the
property is not loaded yet. property content has to in the end be cached in the
model object anyway so this ends up simpler and you don't need a promise nor
the value - the value is already living in the object under the property.

> > efl model would be far simpler with just the model objects having an api to
> > queue a fetch for a property and a property "fetched" event callback. they
> > don't NEED promises. a get of a property returns NULL until the property has
> > been fetched and stored. it's far SIMPLER to design and use WITHOUT
> > promises.
> 
> NO IT WILL NOT. As I have said, it was what we had before promise. The
> code was 30% bigger everywhere in the MVC stack. It was more buggy,
> more difficult to fix and more difficult to extend. We already have
> the experience of that change, and it was really awful.

having to have a new promise per property and per new range get isn't needed.
you can have a simple "new child range" event on the parent obj. as above for
properties.

> > please talk with the people USING promises. no one likes them at all right
> > now except for you and felipe.
> 
> Well, I have put Subhransu in copy, I like to hear his version.

see above.

> >> repeated event which doesn't allow any easy synchronisation and lead
> >
> > wrong. you can in the callback just do the next action and delete yourself.
> > it is possible to do this easily enough. but this isn't the common case.
> 
> Yeah, this is going to make life easier by writing more code that is
> likely to be the source of more problem.

and eina_promise isn't more code? it's new/different to the rest of events and
objects? eina_promise objects have no safety and ate causing crashes now where
none were before and will continue to cause more and more and more. it will
cause much more time spent debugging and complaining that efl is "horrible" and
"hard".

> >> to race condition. Promise do allow easy synchronisation and avoid any
> >> race condition. They make life easier on that side. The price to pay
> >
> > and they are a pain in the butt to work with in their current incarnation.
> > the medicine is WORSE than the disease.
> >
> > please speak with the people using promises. they are worse than what they
> > are trying to cure.
> 
> There are 3 pieces of code that have fully asynchronous behavior in
> EFL. elm_store, that you did write. MVC that Felipe did write and evas
> async preload 

Re: [E-devel] promises...

[Cedric BAIL]

On Sun, Jun 5, 2016 at 3:08 AM, Carsten Haitzler  wrote:
> On Fri, 3 Jun 2016 12:17:18 -0700 Cedric BAIL  said:
>> On Fri, Jun 3, 2016 at 12:20 AM, Jean-Philippe André 
>> wrote:
>> > On 3 June 2016 at 15:42, Carsten Haitzler  wrote:



>> >> 2. they are complex to set up inside our api (setting them up setting
>> >> cancel cb's and more)
>>
>> What do you mean by that ?
>
> look at Efl_Internal_Promise and then needing Eina_Promise_Owner in there and
> then the wonder of the cancel callback deleting the obj which then also 
> cancels
> and double-frees and segfaults. promises are totally unsafe.

Yes, there is some security to add to promise, not a big deal. We need
to prevent double cancel and prevent reiteration. Added with the magic
check, should be already pretty much fixed for everything you just did
describe.

>> >> 3. they totally screw with what eo and interfaces was all about - making
>> >> the api EASIER to use. promises make it harder.
>> >>
>> >> why harder? longer lines of code with more parameters and more special
>> >> casing... but the WORST...
>> >>
>> >>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
>> >>
>> >> that's a promise cb
>> >>
>> >>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
>> >>
>> >> and that's an event cb. they are different. eo events were meant to
>> >> simplify and unify our callback handling. to have a single cb signature.
>> >> now promises break that. this is just bad.
>> >
>> > That's bad. Doesn't look good.
>>
>> You just can't do with eo event what promise do. Eo event are a
>
> it's not NECESSARY to do anything new. timeout can be an eo obj that deletes
> itself after the one-shot callback. it doesn't need a promise. same as job. i
> can't add promises as children to an obj and make sure they get autodeleted
> when parent is. i have to do this all by hand now.

It is a terrible mistake to override eo object lifecycle. This is an
absolute no go as a solution. Anything that bypass the refcounting and
ownership of an eo object lead to massive issue and trouble. We can
not implement auto deletion of eo object outside of the reference
count system.

> efl model needs to drop promises. ask sanghyeon and sub - they are hating to
> work with the promises in efl model - it's massive overkill and unneeded.

If you read the ongoing discussion regarding MVC and the view list
code, you will see that the problem is not the promise, but the fact
that the model is fully asynchronous and that they have to handle it.
Dropping promise out of the model, and they will not only hate, they
will want to jump by the window.

> efl model would be far simpler with just the model objects having an api to
> queue a fetch for a property and a property "fetched" event callback. they
> don't NEED promises. a get of a property returns NULL until the property has
> been fetched and stored. it's far SIMPLER to design and use WITHOUT promises.

NO IT WILL NOT. As I have said, it was what we had before promise. The
code was 30% bigger everywhere in the MVC stack. It was more buggy,
more difficult to fix and more difficult to extend. We already have
the experience of that change, and it was really awful.

> please talk with the people USING promises. no one likes them at all right now
> except for you and felipe.

Well, I have put Subhransu in copy, I like to hear his version.

>> repeated event which doesn't allow any easy synchronisation and lead
>
> wrong. you can in the callback just do the next action and delete yourself. it
> is possible to do this easily enough. but this isn't the common case.

Yeah, this is going to make life easier by writing more code that is
likely to be the source of more problem.

>> to race condition. Promise do allow easy synchronisation and avoid any
>> race condition. They make life easier on that side. The price to pay
>
> and they are a pain in the butt to work with in their current incarnation. the
> medicine is WORSE than the disease.
>
> please speak with the people using promises. they are worse than what they are
> trying to cure.

There are 3 pieces of code that have fully asynchronous behavior in
EFL. elm_store, that you did write. MVC that Felipe did write and evas
async preload of image that I did write. I have not seen any
application using elm_store as a fully asynchronous MVC in the past as
it was to difficult. Felipe had a huge pain to implement the
asynchronous behavior in the MVC using eo event. Finaly myself I
remember how long it took to finally fix it (it was properly fixed
this year). The fact that we don't have any proper infrastructure to
handle asynchronous behavior correctly over the last decade should
have told you better than just it was fine.

Basically nobody use image preload or elm_store, because it is a pain
to implement the asynchronous behavior. Writing a new data model for
MVC has also been a huge pain until we 

Re: [E-devel] promises...

[The Rasterman]

On Fri, 3 Jun 2016 12:17:18 -0700 Cedric BAIL  said:

> On Fri, Jun 3, 2016 at 12:20 AM, Jean-Philippe André 
> wrote:
> > On 3 June 2016 at 15:42, Carsten Haitzler  wrote:
> >> ok. interacting with promises...
> >>
> >> these are just a mess.
> >>
> >> 1. the value thing is just odd.
> 
> That is a known issue that should be fixed today as Felipe is working on it.

the whole value thing still makes the callback signatures different.

> >> 2. they are complex to set up inside our api (setting them up setting
> >> cancel cb's and more)
> 
> What do you mean by that ?

look at Efl_Internal_Promise and then needing Eina_Promise_Owner in there and
then the wonder of the cancel callback deleting the obj which then also cancels
and double-frees and segfaults. promises are totally unsafe.

> >> 3. they totally screw with what eo and interfaces was all about - making
> >> the api EASIER to use. promises make it harder.
> >>
> >> why harder? longer lines of code with more parameters and more special
> >> casing... but the WORST...
> >>
> >>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
> >>
> >> that's a promise cb
> >>
> >>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
> >>
> >> and that's an event cb. they are different. eo events were meant to
> >> simplify and unify our callback handling. to have a single cb signature.
> >> now promises break that. this is just bad.
> >
> > That's bad. Doesn't look good.
> 
> You just can't do with eo event what promise do. Eo event are a

it's not NECESSARY to do anything new. timeout can be an eo obj that deletes
itself after the one-shot callback. it doesn't need a promise. same as job. i
can't add promises as children to an obj and make sure they get autodeleted
when parent is. i have to do this all by hand now.

efl model needs to drop promises. ask sanghyeon and sub - they are hating to
work with the promises in efl model - it's massive overkill and unneeded.

efl model would be far simpler with just the model objects having an api to
queue a fetch for a property and a property "fetched" event callback. they
don't NEED promises. a get of a property returns NULL until the property has
been fetched and stored. it's far SIMPLER to design and use WITHOUT promises.

please talk with the people USING promises. no one likes them at all right now
except for you and felipe.

> repeated event which doesn't allow any easy synchronisation and lead

wrong. you can in the callback just do the next action and delete yourself. it
is possible to do this easily enough. but this isn't the common case.

> to race condition. Promise do allow easy synchronisation and avoid any
> race condition. They make life easier on that side. The price to pay

and they are a pain in the butt to work with in their current incarnation. the
medicine is WORSE than the disease.

please speak with the people using promises. they are worse than what they are
trying to cure.

> is that we can't use the same prototype. I see no problem with this as
> they are apple and orange and can't be used for the same purpose (see
> below with timeout and timer). The only change still coming is the
> removal of the Eina_Promise parameter from the function as we have not
> found any use case for it.
> 
> Having a single signature and loosing the benefit of avoiding race
> condition. Is like avoiding to type a few characteres to avoid
> debugging for hours. This is just not where the problem is. You can't
> implement promise on top of Eo event. Not just because of the overhead
> of Eo object, but because the event are in nature different from the
> asynchronous operation provided by promise. Switching efl model to use
> promise instead of event has massively simplified the code (Still
> quite complex, but way better).

and it's massively COMPLICATED the use.

promises are not eo objects. they cannot be managed in the lifecycle of object.
jobs and timeouts now need special handling. the promises for models are not eo
objects so you have to specially handle them if you want to cancel and there
actually just is little point in doing so actually.

you can't make promises weak refs. you can't add them and children to a parent
for auto-deletion. they can't be easily extended (adding more events to a
promise) like eo objects can.

> Also last point, I think having the same signature, would actually be
> more confusing to people. Like why does that event not accept to be in
> a promise_all or promise_race ? If it has the same signature, people
> would expect to be able to use random event in promise_all/race and
> that is just not doable.

the number of times people actually NEED these is insanely rare. no one is using
them. these "features" cause more pain than it's worth. speak to the people
using promises now.

> >> i wasn't sold on promises. i was skeptical, but whatever... but now i am
> >> seeing they are visibly making things worse. code 

Re: [E-devel] promises...

[Cedric BAIL]

On Fri, Jun 3, 2016 at 12:20 AM, Jean-Philippe André  wrote:
> On 3 June 2016 at 15:42, Carsten Haitzler  wrote:
>> ok. interacting with promises...
>>
>> these are just a mess.
>>
>> 1. the value thing is just odd.

That is a known issue that should be fixed today as Felipe is working on it.

>> 2. they are complex to set up inside our api (setting them up setting
>> cancel cb's and more)

What do you mean by that ?

>> 3. they totally screw with what eo and interfaces was all about - making
>> the api EASIER to use. promises make it harder.
>>
>> why harder? longer lines of code with more parameters and more special
>> casing... but the WORST...
>>
>>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
>>
>> that's a promise cb
>>
>>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
>>
>> and that's an event cb. they are different. eo events were meant to
>> simplify and unify our callback handling. to have a single cb signature. now
>> promises break that. this is just bad.
>
> That's bad. Doesn't look good.

You just can't do with eo event what promise do. Eo event are a
repeated event which doesn't allow any easy synchronisation and lead
to race condition. Promise do allow easy synchronisation and avoid any
race condition. They make life easier on that side. The price to pay
is that we can't use the same prototype. I see no problem with this as
they are apple and orange and can't be used for the same purpose (see
below with timeout and timer). The only change still coming is the
removal of the Eina_Promise parameter from the function as we have not
found any use case for it.

Having a single signature and loosing the benefit of avoiding race
condition. Is like avoiding to type a few characteres to avoid
debugging for hours. This is just not where the problem is. You can't
implement promise on top of Eo event. Not just because of the overhead
of Eo object, but because the event are in nature different from the
asynchronous operation provided by promise. Switching efl model to use
promise instead of event has massively simplified the code (Still
quite complex, but way better).

Also last point, I think having the same signature, would actually be
more confusing to people. Like why does that event not accept to be in
a promise_all or promise_race ? If it has the same signature, people
would expect to be able to use random event in promise_all/race and
that is just not doable.

>> i wasn't sold on promises. i was skeptical, but whatever... but now i am
>> seeing they are visibly making things worse. code is harder to write, harder 
>> to
>> read, harder to maintain, harder to get right. now we have timeouts that 
>> cannot
>> repeat. no - creating a new timer in the cb is not repeating. it has to
>> repeat with the "zero time" being the time when the timer was ticked off, not
>> "now".

So, the point of timeout is to provide a timeout, not a timer. If you
want a timer, efl.timer is there for that purpose. It is an Eo object
and it does exactly what you expect from it. Repeating itself over and
over until it is destroyed or freezed. The main difference, as you
have noted, is that a timeout doesn't repeat and is a one off. It
makes it super easy to implement timeout behavior with network for
example. You would have a promise to a connection object, you create a
timeout and you link them in a promise_race.  Not a single callback to
write to get the timeout to cancel the connect.

As for maintenance and readability, I disagree. Moving eio_model to
use eina_promise instead of eo events lead to a net removal of 1/3 of
the code and I think that there is more to win now that we have an
eoified Eio, but that's for later. The point of promise is to allow
easy synchronisation without race condition. If you try to use them to
do something else, like your attempt to implement a timer with
timeout, it doesn't work. There is no synchronisation expected in that
case.

>> please - everyone. take a look at promises and how they are used. forget
>> all of the "but node.js has them" and all the "i can chain promises" and so 
>> on.
>> the BASIC usage of them is harder now in efl.

It is to be understood that they are only useful for synchronisation
purpose. If you do not need to synchronise, then promise is not the
answer. If there are place where a promise is returned and that there
is no use of it for any synchronisation purpose then it is obviously a
bad place to have a promise. Otherwise it is.

>> what to do? well... minimize their use for one. do not use them unless you
>> ABSOLUTELY HAVE TO.

As I just said above, promise is to be used only for synchronisation
purpose. It is not a matter of minimizing their use, it is a matter of
using them at the right place. Using a timeout for a timer, make no
sense from the beginning. Also most of our API that should be
asynchronous is not there yet, so it is hard to synchronise anything,
when nothing is asynchronous 

Re: [E-devel] promises...

[Jean-Philippe André]

On 3 June 2016 at 15:42, Carsten Haitzler  wrote:

> ok. interacting with promises...
>
> these are just a mess.
>
> 1. the value thing is just odd.
> 2. they are complex to set up inside our api (setting them up setting
> cancel
> cb's and more)
> 3. they totally screw with what eo and interfaces was all about - making
> the
> api EASIER to use. promises make it harder.
>
> why harder? longer lines of code with more parameters and more special
> casing... but the WORST...
>
>   void _cb_promise(void *data, void *vaue, Eina_Promise *promise)
>
> that's a promise cb
>
>   Eina_Bool _cb_event(void *data, const Eo_Event *event)
>
> and that's an event cb. they are different. eo events were meant to
> simplify
> and unify our callback handling. to have a single cb signature. now
> promises
> break that. this is just bad.
>

That's bad. Doesn't look good.



> i wasn't sold on promises. i was skeptical, but whatever... but now i am
> seeing
> they are visibly making things worse. code is harder to write, harder to
> read,
> harder to maintain, harder to get right. now we have timeouts that cannot
> repeat. no - creating a new timer in the cb is not repeating. it has to
> repeat
> with the "zero time" being the time when the timer was ticked off, not
> "now".
>
> please - everyone. take a look at promises and how they are used. forget
> all of
> the "but node.js has them" and all the "i can chain promises" and so on.
> the
> BASIC usage of them is harder now in efl.
>
> what to do? well... minimize their use for one. do not use them unless you
> ABSOLUTELY HAVE TO. also promises should become eo objects with event cb's
> so
> they work just like everything else. i can ref, unref, delete and whatever
> them
> like everything else.
>
> right now i think promises are just not in a shape to use or ship. they
> need a
> lot more work. i think we need to drop them for efl 1.18 and defer for efl
> 2.0
>


I also haven't understood the data stuff. value vs data, and which to pass
where.
My problem right now is I basically can not use efl_loop_timeout.

p = efl_loop_timeout(evas_obj);
--> p is NULL

p = efl_loop_timeout(eo_provider_find(evas_obj, EFL_LOOP_CLASS));
--> p is NULL because evas_obj is not able to find the loop (not a
Loop.User)

p = efl_loop_timeout(ecore_main_loop_get());
--> p is valid. But I just called a non EO API. oops

Now I want to cancel my previous timeout to renew it from "now":
eina_promise_cancel(p);
--> crash if p is NULL (2 most convenient cases above)
--> crashes later if p is valid... but the timeout cb is still triggered
(bug)

Basically promises as they are right now are incredibly unsafe. Any misstep
will crash.


Last point is: ecore_timeout takes one line only to create the timeout,
efl_loop_timeout takes two lines (create promise + use it). Less convenient.

Best regards,

-- 
Jean-Philippe André
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel