Hi,
just trying to follow here and maybe clarify a bit.
Of course everybody here knows about the conventions :
- 0 is the success return code
- anything else is an (hopefully documented) error
we all know about logical shell chaining :
cmd1 && cmd2 && cmd3 || cmd4
but what I think I understood here is that promises chaining should be a
different construction where the chaining is not dependent on the return code
(success/failure) of any of the actions.
{ action 1 } then { action 2 } then { action 3 }
it's a 'then' meaning 'after that', not an '&&' that means 'on action success'
so with v beeing the value of the promise, you do
{ action 1 } then { if (v!=0) return action21 else return action22 } then {
if (v==0) action 3 }
and with handy helpers (operator logic) like
bypassOnFailure(if (v!=0) return v)
bypassOnSuccess(if (v==0) return v)
you can do
{ action1 } then { bypassOnFailure(); action2 } then { bypassOnSuccess();
action3 } then { byPassOnFailure; action4 }
the chaining fails on "System errors" -> Exception on some languages
the logic is implemented in the futur
hope I'm not in outer space.
On Thursday 22 March 2018 09:36, Carsten Haitzler wrote :
> 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
--- Hell'O from Yverdoom
Jérémy (jeyzu)
------------------------------------------------------------------------------
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
