On Mon, 20 Jun 2016 00:35:35 -0300 Felipe Magno de Almeida <[email protected]> said:
> On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler <[email protected]> > wrote: > > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida > > <[email protected]> said: > > > >> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler <[email protected]> > >> wrote: > >> > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida > >> > <[email protected]> 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. > > 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<T> > can deadlock too on wait. At least ours will warn then. Also, > std::future<T> 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. then they will have to not use std promises but efl ones that add the extended features. as i said - with model and fileselector they already require passing in promises created elsewhere by the caller code (property_set for example). > > 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 a normal coroutine can't. it would need to be extended or overridden. but even then... what on earth has yield() got to do with a promise and how does a coroutine handle success vs an error? it has a single function only. > And to my knowledge, I don't see any problems with using promises > and adding a cancel function to the coroutine object. ^^^ where is the handling of success vs failure? there is a single function - a single code path only. there isnt even anything to handle progress unless you go add more functions to the coroutine object. then you still have no error vs success handling separated and you still have a yield that is pointless. <snip> > >> 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. that would solve the problem if we only return them. for c++ typechecking could make it clear. ja/lua - > no checking so it's not clear. > [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? no i'm saying you are MAKING them the same thing. then you have a coroutine now with just a single execution path (not both success and failure) and no progress handling path. yes it's an object that can be extended to have a cancel (as long as it's always returned not created+passed in) > >> 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. so how? like c = coroutine.create(function () if pcall(coroutine.success()) then ... else ... end) ? > >> a failure as well and asking for cancelation can be just a meta-method > >> on the couroutine. And progress can be just a function that the > >> asynchronous call will get it. > > > > not if created as a normal coruotine. and why shove a square peg in a round > > hole? coruotines are not related to promises. they are different beasts. > > just create full promises in lua with a then+fail function with closures > > like in js etc. etc. > > Is sockets related to coroutines? Why do they handle it that way? Because > it is the _Lua-way_. Why are we so special? because with socket there are not different callbacks called from libc based on an error. it's an explicit read() or recvmsg() that returns an error value thus doing this is normal: while 1 do coroutine.yield() local data = read(socket) if (data == nil) return -- error handle here process(data) end where a promise just calls code a or code b when done. at least from our end. we want 2 separate pieces of code to call. > >> 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 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. > > > > it's not. wait. cancel. .... i've listed them. we end up extending language > > promises and/or futures but then eg missing features like wait. if passed in > > like they are as above then we have issues... etc. etc. etc. > > We will not miss wait, cancel or progress. Anyway, we can have an Eolian > promise object and just manually bind it to other languages when the > time comes. At least with Eolian, we can change our minds later > one way or another. well the time comes now. we can't use promises in our api and then later figure out bindings for them as our api is partly non-functional without them being bound. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
