On Wed, 21 Mar 2018 14:18:39 -0400 Cedric Bail <ced...@ddlm.me> said:
> On March 20, 2018 6:14 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > > 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. > > Great example. This is not a chain of error/success, but a logical and > operator, the same way you would do in C : > > if (f1() && f2() && f3()) which is a chain of success only. fo f1, if that is true then f2, if that is true then f3. if the promises don't fail when the error code is non-zero then you can't chain like the above. > A chain of future is not designed to just implement the above line, but you > should be able to do also : > > do || fallback and that is a different kind of chain which actually does both things irrespective, but logically or's the result. so if do AND fallback both errors your result will be "false" (promises just extend this logic over time async rather than in-line in a blocking kind of way like if's etc.) > or even : > > [$? -ne 5] > > In all of this case, it is using $? value explicitely or implicitely. It in this case you are checking the error code to see what kind of error. an exit code of 5 never should imply success. not in the world of the command line shell. i didn't make those rules. i'm just following the pattern. > would be the same in C, a value. So during a future resolution is when you > take a decision on what to do with the value, should it be a &&, ||, -ne, -eq > or whatever. future/promise are a generic construct, they are not supposed to > just handle the shell && command. see eio. this does exactly the stuff that eio does. it decides when it's a fail or success. with eio for example with stat the eina error value is the syscalls errno value. in this case since its a system error ECANCEL will be distinctly "not reported" because stat won't say that. there is no conflict. with exe exit codes there is a conflict as it can report ANYTHING (actually exit codes are basically masked with 0xff so they only report 0->255 even thought it's a full int in the C ABI). > > 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. > > Some language implementation of future and asynchronous primitive, like for > example Javascript, do not have a failure case. To generate a failure, you > throw an execption and you catch it at the end of the future pipeline. That's > how it work. So yes, in some language, you have to deal with exception. And > the interface should document the expected exception at some point. so if the language means you must handle exceptions then that's how it works. you must handle them. > > 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. > > If you actually return a value, you can actually make series of commands with > all the behavior you want more easily. How about doing something when the > exit code is 5 ? future are a generic construct, not their to do only the > equivalent of &&. you get an eina error with a value of 1000005. i just used the +100000 to push the exit code value well outside any normal range of error codes so its distinguishable fro ECANCEL. you get the information. it's there. an exit code of 5 is an error. by definition. i didn't make he definition. that was done long ago. just like when stat fails in eio and the promise is rejected with the errno. the stat failing is an error. even if all i want to do is check if the file exists (a very common use of stat - i don't want the data. i just want to know if it's there or not). if i need exceptions to deal with "it's not there" result... then i have to do that. > > 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. > > Yes, your code in the future or as Gustavo proposed, we can have helper that > check for this value and provide operator logic that you can insert in the > pipeline. I hope that help you understand why a process exit code is a value. it's not a "success value". it's an "error value". i've been saying that clearly and pointing to how the shell determines it is an error too (a && b && c, /bin/sh -e, state nonexistentfile etc.). the convention is that anything non-ero is an error and it's just reporting the kind of error value. that is reporting as an eina error in a promise reject, just like eio does. if simplecerrors like "file not found" for stat is a promise reject + eina error, then execing stat nonexistent file MUST produce the same kind of result - an error if the file does not exist (which the stat command will do), otherwise it's not consistent. same with any other command. Makefiles are another great example. any non-zero exit code from a compile command results in the entire compile breaking at that point. any shell commands using non-zero exit codes as success of any sort are just simply broken commands as they would fail in the above sh -e, makefile, a && b && c, etc. etc. cases as they do not follow the shell convention. the default "out of the box' must absolutely be anything non-zero is a failure because that is the default "out of the box" convention on the cmdline. a failure is a promise reject. you clearly did just that in eio. if you want tov have some mapping capability to turn some errors into success, then that is out of scope for the code in question right now as it is implementing a sane default that follows conventions laid down decades ago. if by default it succeeded with non-zero exit codes then it'd be broken code as it would not be following any conventions within efl (see my comparisons to eio), nor from the outside world (command line + exit codes). if you want to argue that a non-zero exit code is not an error on the command-line (exit codes of processes), then point me to a shell/cmdline convention that follows this. for example: ccache returns 0 if the cached file is not found or valid and it has to run gcc to do a full compile, or it returns 5 if the cache is a hit and can avoid the compile. just an example. point me to a NON-BROKEN real usage of non-zero exit codes for success. then point me to how they are the majority of cases so that the convention in efl should interpret non-zero exit codes as success. then you will convince me that non-zero exit codes are successes. i know of no such examples (of non-broken cmds that won't break all of the above conventions on the cmdline/shell scrips/Makefiles or basically anything that is EXECUTING things and needing to base decisions on what to do next by exit codes), thus i'm not even trying to find a solution to this at this point because it's not worth doing unless there is a good reason to. -- ------------- 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
