On Fri, 28 Oct 2016 09:05:37 -0700 Cedric BAIL <[email protected]> said:
> On Thu, Oct 27, 2016 at 4:53 PM, Carsten Haitzler <[email protected]> > wrote: > > On Thu, 27 Oct 2016 09:05:37 -0700 Cedric BAIL <[email protected]> said: > >> On Oct 26, 2016 6:19 PM, "Gustavo Sverzut Barbieri" <[email protected]> > >> wrote: > >> > barbieri pushed a commit to branch master. > >> > > >> http://git.enlightenment.org/core/efl.git/commit/?id=574e4b8ad56b0cced409417f76e90205fb28fe22 > >> > > >> > commit 574e4b8ad56b0cced409417f76e90205fb28fe22 > >> > Author: Gustavo Sverzut Barbieri <[email protected]> > >> > Date: Wed Oct 26 23:17:10 2016 -0200 > >> > > >> > efl_io_copier: work around efl_future weirdness. > >> > > >> > The pointer given to efl_future_use() should be NULL-ified before > >> > calling my function, since that pointer has no meaning anymore. > >> > > >> > The copier relied on pd->job being NULL to avoid useless > >> > rescheduling, it was being reached with non-null, but that pointer is no > >> > longer useful. > >> > > >> > Moreover, I'm not sure if the second pointer, with the new future > >> > won't be modified to NULL when the efl_future continues :-( > >> > >> Yes, this is a problem I am well aware off.due to the use of eo for future, > >> weak ref are nulled only after the future is destroyed. But the real > >> correct behavior is to have it nulled as soon as it is fulfilled before > >> even calling any callback, because weak ref are to be used by cancel only. > >> They shouldn't exist when cancel can't be called anymore. I intend to fix > >> this when I move future away from eo. > > > > futures should not be moved away from eo. futures are what you cancel and > > this discussion is going to go in a circle. because to cancel them you need > > a handle to keep around... they MUST be eo. for safety. for reffing. etc. > > You may have missed a few information. Reffing is uneeded as we rely > on returning to the main loop to actually trigger a future. We have if i want to keep the value around BY reffing the future in order to store it... we've been over this. and then the eo ptr safety and type/call safety. call a promise method on a future? invalid. caught at runtime. try and cancel an already deleted future? safe. caught at runtime. keep it with eo. this conversation is going around in circles and we've been over this many times. > several problem with eo. First one is weak reference don't behave as > they should with future. You want all weak reference to disapear as > soon as a promise resolve, not after the future are done. Otherwise a weak reference TO a future goes away when the FUTURE is done. not the promise. promise is input to the future. it's irrelevant there. a weak ref to promises should go away when the promise does. different things. > you end up with the line of code above. Second problem, if you can > efl_future_then on NULL future, you should trigger the fail callback > right away. This is not doable in eo without wrapping that call. Other let's stand back. no. i dont think the fail call should be called here. what happens in js when i do: var x = 10 x.then(function ...).else(function ...); ? it certainly will NOT call the else callback function. it'll cause a runtime error that the js runtime may just complain about and return (ver likely). so why are you trying to do things other languages which use promises heavily do not do? it's a nop to do a then on an invalid future object. no callback will be called. this should basically NEVER happen anyway. you will set up the then right after creation and return of the future, so if futures may be invalid (its possible they cant be created) then future = efl_whatever_do(obj); if (!future) { error - no futrue) } else efl_future_then(future, ...); if future != NULL it must by definition be valid, and if it is not then not calling anything is as good a response as any. > than that, future are using no other feature of eo except for safe incorrect. use future to store value for longer. as above. ALSO call safety. ALSO i can attach data to a future of my own and use it later on: efl_key_data_set(future, "somedata", data); ... data = efl_key_data_get(future, "somedata"); e.g. in the future then/else cbs or progress cb. as an eo object i can have MULTIPLE progress event listeners. i can "glue" a progress widget DIRECTLY to futures - have multiple widgets watching and displaying status of that future. i can name my futures and look them up by name. (efl_name_set()). i can add comments for debugging. i can listen to the del event of a future to know when it's done from MULTIPLE sources and not just the then/else cb's. e.g. the download dialog could LISTEN to the future of a file download and auto delete itself when the future is deleted. just have to listen and "on delete" nuke the dialog too. in fact i can make the dialog a CHILD OBJECT of the future even... you dismiss all of this as "not useful at all and thus i'll remove it all because i want to call the else func if future is invalid" which others don't do... > pointer. This part of the code in Eo as grown organically to a point > where maintenance of it is non trivial already. Moving it to eina with > a clean API will solve both problem. Allow a proper testing and no! not again! future and promise should be eo objects and should stay that way. they SHOULD have used eolian and eo files. > benchmarking of that infrastructure along with the reusability for > other piece of code who do not need a full scale Eo object. It can > even be used for legacy only handler, like Ecore_Animator without NO! see the bug filed already about ecore animators going BACK to legacy code. being eo objects eo was safe. NOW there are segv's in e with junk ecore animators and the REMOVAL of them as eo objects has now turned a complaint and safe function of e into a crash... which we can't find because its rare and i think only on openbsd where valgrind doesnt even work. you want to make efl LESS safe and LESS useful. this is bad. > confusing people on having legacy Eo object and modern object. So no, > there is more problem into keeping future an eo object than moving > away from it. just dont INSTALL the eo files for the legacy animator. > Note, we are not talking about promise object here, just future. this whole thing is going in circles. removing eo here is not a good thing. it's a bad thing. animators are proof of this as above. i've listed all sorts of useful things eo brings to the table. of COURSE a future weak ref is NOT nillified until the then or else is called. thinking it WOULD be is insane. the object is not complete. it's still calling functions. trying to make this work is just broken by design. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
