On Tue, 20 Mar 2018 12:06:08 -0400 Cedric Bail <ced...@ddlm.me> said:
> 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 waaait. if it creates exceptions, then promises are a horrible thing in that languages. how do you do the else part of a promise then? you can't. it's an exception. (well unless it's an exception if you DON'T catch it with an else). if you catch it then fine - no exception. that is what you should be doing with a potentially failing child process. it may have failed because it doesn't exist, user hit process limit, it crashed on startup or just couldn't do its work. how it fails is transmitted via a non=0 exit code. so if a non-handled else is an exception in that language then that's absolutely the right thing to do. it's /bin/sh -e which is a policy of "if you don't catch the error - then the system exception handler will catch it which is to exit with the error code". that's totally the same thing. if it's ONLY via exceptions then that's a stupid promise implementation in that language and promises are a horrible idea if they cause exceptions on failures. imagine your stat in eio... joy joy. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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
