On Thu, 22 Mar 2018 09:56:37 +0100 Jérémy Zurcher <jer...@asynk.ch> said:
> 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'
actually then is on success. if the promise rejects (as a failure) it won't be
a "then" chain that continues. that's key to promises. then here is then IF the
promise succeeds without failure. see eio efl_io_managr.c - if stat fails on a
file it rejects the promise with an error. it's doing that and that is
apparently correct, but an exit error code is not correct doing the same thing.
> 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.
see efl_io_manager.c - if a stat() of a file fails (e.g. file doesn't exist),
the promise rejects with a error. i simply did precisely the same thing with an
exit code of non-zero. it's an error/failure (that was my point in indicating
it is in shell examples). thus it should behave the same way. not doing so is
inconsistent.
> 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
--
------------- 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
