On March 20, 2018 7:38 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 20 Mar 2018 10:06:43 -0300 Gustavo Sverzut Barbieri > barbi...@gmail.com said:
<snip> > > I said I'd give up... but seeing this makes me sad. > > > > in two lines you: misused the Eina_Error AND missed the purpose of resolve. > > > > I hoped when you looked at it, written as code, you'd realize the > > mistake... but seems not... so I'm pointing here. > > > > eina_error conversion to string (which will be helpful to high level > > languages) is missed, "+ 1000000" is an error that is not > > registered... > > > > OTOH success is always ZERO, so there is no value... IF that would be > > right, then it should be a void promise (carries no value). > > > > but my hope is that you'll simply move this to > > eina_promise_resolve(pd->promise, eina_value_int_init(exit_code)) > > > > and listen to my advice that is to move the "!= 0" OUTSIDE of this > > function, you're mixing roles :-/ > > eh? we only have 1 value to know of success or failure. an int. 0 == success. > anything else is failure. that's precisely what i did right there. No. Think about what Eina_Error mean for binding. It will trigger an exception in some language. Now the user as to catch exception and instead of doing a switch on expected real error, it has to work around this hack to get the real exit status. Additionnaly, there is no requirement/guarantee in Eina_Error that this error code will never be used for something else. <snip> > yes. in this case on success the value is the struct data for the state. for > an > exe i don't have anything. it's a 0. that's it. that's all i have. I don't even see how this is even closely related to what you are doing. In your case you are making up error from something that is not necessarily one while the example you picked generate the error from the system error. Error are system failure. Think when you want an exception in bindings. > that is one reason why i kept saying that an object is the right thing to pass > here, not an value... but well. i'm obviously so incredibly wrong there so i > did exactly what you said to do and passed and int. The result of executing a process is an exit code, not an int that == 0. You don't need an object to get an int. <snip> > > I know we don't have the eina\_future\_cb_compare(), but adding that > > will be usable everywhere and make your efl_task interface more > > powerful. > > you didn't listen. then how do you determine the kind of error from an > executable that returns != 0 for the kind of error vs ECANCELED. ECANCELED on > linux at least is 125. that is a perfectly possible error exit code from an > executable. i shifted the error codes up by 1000000 IF the error code != 0. > if it's zero no error type is passed. the int type is passed instead with is > always 0. there is no other thing to return except always 0 because you > absolutely insist that promises are values not objects and they absolutely > must > be a value, so there is the return code. voila. it's an int and it's always 0. > that's how it's defined for executables. Eina_Error is for system error. Think exception. A binary that exit with a code != 0 should not be a source of exception. Why do you go to that extend to make things more complex ? I can't even understand how you come up with this conclusion, they make no sense. The return code is the value, why would it be more complex than that !?! And it work exactly the same with thread, they can just directly return an Eina_Value from the thread, which allow for returning anything directly. Cedric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
