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 > 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. i'm not the one coming up with raising exceptions or not, BUT i mentioned this before. shell: cmd1 && cmd2 && cmd3 is a chain of promises. they are the same thing. if cmd1 succeedsm then run cmd2, if that succeeds run cmd3. if the "it doesnt succeed" is done via an exception - then promises are going to SUCK. if a file download failed to fully complete - exception. if a file_set failed because file doesn't exist - exception. you do know that there is tonnes of code in e and efl that does a file_set to just determine if the file exists AND is an image or not? (well file_set then size_get for non 0 size). if exceptions are the way to do this then there are going to be a LOT of them and people have to handle them in that language. if exe's can never fail - they always succeed unless there is a total catastrophic failure (fork or something before fork fails - highly unlikely) then you can never use promise chains to run a series of commands one after the other. something has to make a decision on failure and promises make that decision when it's rejected, and the point of rejection is exit code. the shell already decided on this. cmd1 && cmd2. > <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. any exit code that is not 0 is an error. i didn't decide that. that's how process exit codes work in a shell. > Error are system failure. Think when you want an exception in bindings. then how do you chain promises sensibly? like download file x and then if that works, file_st it on an object, and if that works then show the object? look at eio. *YOU* wrote that code. it rejects promises on simple things like a stat filed on a file. that's not a "system failure" . that's a simple part of regular operation. you should review your own code then. what i am doing with exit codes is directly following in line with eio. if a file stat fails and causes a promise to reject with an error, then an exe exit code of non-0 does the same. a shell sees a "stat nonexistent file" as a non-zero exit code. that is an error. try this one in a shell: stat nonexistentfile && echo hi hi will not echo. stat failed. it's precisely what eio code that you wrote does. > > 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. the result of executing an executable is JUST an exit code. 0 is success. anything else is failure. see above. unix shell semantics already decided on this long ago. > <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 then stop using it in eio for stat fails and ls fails and so on. good luck chaining promises nicely then. the whole premise of the utility of promises goes out the window if they basically never fail unless it's a major SYSTEM error like "can't allocate memory". > 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 because you do in eio. > 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. threads can return 0 if no error happened and use other side-band data (inout data ptr, the io streams, or sync/async call on the parent) to return something other than an exit code. exe's can do the same (no inout data though as ptrs don't translate between processes generally speaking). a process that succeeded and had no error will return 0. #!/bin/sh -e most good shell scripts do that. any un-caught error return of a child process in the script will cause the script to exit. scripts either totally ignore errors UNLESS in a chain like cmd1 && cmd2 or if command; then xxx; fi or cmd1 && cmd2. try it: if stat nonexistentfile; then echo hi; fi why do you think a process exit code of non-zero is not a fail/error/false? that is what a promise reject is too. you yourself do just that in eio. > 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
