Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sun, 23 Aug 2009 04:48:56 +0200 Arfrever Frehtes Taifersar Arahesis wrote: > > There was a change in wording to better convey the original intent. > > There was no change in behaviour. > > There was a change in behavior of 'nonfatal > eclass_function_which_sometimes_calls_die'. No there wasn't. The behaviour specified by PMS both before and after the patch remains exactly the same. The only thing the patch did was make the wording much clearer, so people can no longer make the (perfectly understandble) misinterpretation of the intent that you have made. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
2009-08-22 01:43:54 Ciaran McCreesh napisał(a): > On Sat, 22 Aug 2009 01:39:41 +0200 > Arfrever Frehtes Taifersar Arahesis wrote: > > > > > There was a clarification of the wording after it became clear > > > > > that there was room to misinterpret the intent of the original > > > > > wording, and it went through the usual Council-mandated process > > > > > for such a change. > > > > > > > > This sentence contradicts your first sentence. > > > > > > No, it doesn't. > > > > "it went through the usual Council-mandated process for such a > > change" clearly contradicts "There was no change". > > There was a change in wording to better convey the original intent. > There was no change in behaviour. There was a change in behavior of 'nonfatal eclass_function_which_sometimes_calls_die'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sat, 22 Aug 2009 01:39:41 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> > > There was a change regardless of what you think.
> >
> > No, you were misreading the original wording
>
> The original wording didn't disallow affecting die(). Not disallowed
> things are always allowed.
Er, no. The wording describes the extent of what die and nonfatal do.
There's nothing in the die description about it being affected by
nonfatal, and nothing in the nonfatal description about affecting die,
so neither affect each other.
PMS doesn't say "nonfatal must not chmod +s ${D}/bin/sh", so do you
believe that nonfatal would be allowed to do that too?
> > > > There was a clarification of the wording after it became clear
> > > > that there was room to misinterpret the intent of the original
> > > > wording, and it went through the usual Council-mandated process
> > > > for such a change.
> > >
> > > This sentence contradicts your first sentence.
> >
> > No, it doesn't.
>
> "it went through the usual Council-mandated process for such a
> change" clearly contradicts "There was no change".
There was a change in wording to better convey the original intent.
There was no change in behaviour.
> > The original wording used the phrase "abort the build process due
> > to a failure". The intent was that this would cover commands that
> > had language like "Failure behaviour is EAPI dependent as per
> > section~\ref{sec:failure-behaviour}.".
> >
> > The language for 'die' does not say "due to a failure", and so was
> > not supposed to be affected by 'nonfatal'.
> >
> > However, that wasn't explicit, so your misreading of the intent of
> > the document is entirely understandable. That is why we fixed it.
>
> You broke it.
I made the wording more clearly present the original intent. That is
all.
> > > Additionally you had deceived Christian Faulhammer by not
> > > presenting negative consequences of your patch and your
> > > interpretation of original wording of definition of nonfatal().
> >
> > The only consequence of the patch was to clarify what was already
> > stated.
>
> It wasn't stated as I said above in my 2 first sentences in this
> e-mail.
It was. The extent of the behaviour of nonfatal is described in PMS.
You can't go around inventing magic new behaviour for it that isn't
specified.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
2009-08-22 01:28:17 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 01:15:18 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
> > > There was no change to the definition of nonfatal.
> >
> > There was a change regardless of what you think.
>
> No, you were misreading the original wording
The original wording didn't disallow affecting die(). Not disallowed things
are always allowed.
> > > There was a clarification of the wording after it became clear that
> > > there was room to misinterpret the intent of the original wording,
> > > and it went through the usual Council-mandated process for such a
> > > change.
> >
> > This sentence contradicts your first sentence.
>
> No, it doesn't.
"it went through the usual Council-mandated process for such a change" clearly
contradicts "There was no change".
> The original wording used the phrase "abort the build process due to a
> failure". The intent was that this would cover commands that had
> language like "Failure behaviour is EAPI dependent as per
> section~\ref{sec:failure-behaviour}.".
>
> The language for 'die' does not say "due to a failure", and so was not
> supposed to be affected by 'nonfatal'.
>
> However, that wasn't explicit, so your misreading of the intent of the
> document is entirely understandable. That is why we fixed it.
You broke it.
> > Additionally you had deceived Christian Faulhammer by not presenting
> > negative consequences of your patch and your interpretation of
> > original wording of definition of nonfatal().
>
> The only consequence of the patch was to clarify what was already
> stated.
It wasn't stated as I said above in my 2 first sentences in this e-mail.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sat, 22 Aug 2009 01:15:18 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> > There was no change to the definition of nonfatal.
>
> There was a change regardless of what you think.
No, you were misreading the original wording (which I quite happy
admit was wide open for misreading), hence the need for the
clarification.
> > There was a clarification of the wording after it became clear that
> > there was room to misinterpret the intent of the original wording,
> > and it went through the usual Council-mandated process for such a
> > change.
>
> This sentence contradicts your first sentence.
No, it doesn't.
The original wording used the phrase "abort the build process due to a
failure". The intent was that this would cover commands that had
language like "Failure behaviour is EAPI dependent as per
section~\ref{sec:failure-behaviour}.".
The language for 'die' does not say "due to a failure", and so was not
supposed to be affected by 'nonfatal'.
However, that wasn't explicit, so your misreading of the intent of the
document is entirely understandable. That is why we fixed it.
> Additionally you had deceived Christian Faulhammer by not presenting
> negative consequences of your patch and your interpretation of
> original wording of definition of nonfatal().
The only consequence of the patch was to clarify what was already
stated.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sat, 22 Aug 2009 01:20:36 +0200
Maciej Mrozowski wrote:
> > > That being said I don't like refraining from "return value
> > > approach" towards "exception handling approach"
> >
> > nonfatal's not an exception handling approach. Think of it as a
> > utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.
>
> Le sigh..
> Replacing return value with die ("throw") *and* providing 'nonfatal'
> as mechanism to catch and ignore what's been thrown is obviously
> "exception handling approach" (not literally that is, I don't have to
> recall the semantics of \" character) - every respected software
> engineer will see that.
That isn't what nonfatal does. It does not in any way catch and ignore
what's been thrown. It prevents the fatal notification from being sent
in the first place.
die is not a throw operation, never has been a throw operation (see the
whole "die in subshells" mess) and isn't going to be a throw operation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Saturday 22 of August 2009 01:06:30 Ciaran McCreesh wrote:
> On Sat, 22 Aug 2009 01:01:48 +0200
>
> Maciej Mrozowski wrote:
> > That being said I don't like refraining from "return value approach"
> > towards "exception handling approach"
>
> nonfatal's not an exception handling approach. Think of it as a utility
> like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.
Le sigh..
Replacing return value with die ("throw") *and* providing 'nonfatal' as
mechanism to catch and ignore what's been thrown is obviously "exception
handling approach" (not literally that is, I don't have to recall the
semantics of \" character) - every respected software engineer will see that.
But on topic, if you want to participate in discussion, please refer to
suggestions given by David, please.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
2009-08-22 00:51:14 Ciaran McCreesh napisał(a): > On Sat, 22 Aug 2009 00:40:04 +0200 > Arfrever Frehtes Taifersar Arahesis wrote: > > I would like to also notice that (not yet approved by Council) > > definition of nonfatal() in PMS was recently drastically changed > > without proper discussion with developers of other package managers. > > [1] was sent about 20 minutes after discussion about nonfatal() > > started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm > > attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think > > that such drastic changes should be first discussed on gentoo-dev > > mailing list. > > There was no change to the definition of nonfatal. There was a change regardless of what you think. > There was a clarification of the wording after it became clear that there > was room to misinterpret the intent of the original wording, and it went > through the usual Council-mandated process for such a change. This sentence contradicts your first sentence. Additionally you had deceived Christian Faulhammer by not presenting negative consequences of your patch and your interpretation of original wording of definition of nonfatal(). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sat, 22 Aug 2009 01:01:48 +0200 Maciej Mrozowski wrote: > That being said I don't like refraining from "return value approach" > towards "exception handling approach" nonfatal's not an exception handling approach. Think of it as a utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote: > On Fri, 21 Aug 2009 23:09:33 +0200 > Maciej Mrozowski wrote: > > I suggest #5 - drop the idea of 'nonfatal'. > Then how do you plan to handle all the standard utilities that die on > failure in EAPI 3? >>> #1 make die respect nonfatal The most obvious. About consequences - when you override behaviour of "die-on- failure" function (that has been marked as fatal for reason) you're supposed to know what you're doing, so all codepaths should be checked in that case, otherwise one should be really ready to grab the pieces in such case. >>> #2 make die always die In such case nonfatal is useless as it's supposed to surpass "die-on-failure" EAPI3 functions, am I right? Correct me if I'm wrong, bug there are just two ways to mark function invocation as 'failed': - return nonzero value - soft way - abort further execution of script, so call die function - hard way In such case nonfatal works against its purpose (it cannot interfere in arbitrary function's flow control, and return value only affects this, so the only mean for it is to interfere in general-purpose-die-function). This could be fixed by introducing 'even-more-fatal' way of aborting script execution, like function 'really-die-seriously-this-time' that ignores 'nonfatal' :P (which leads us to #3 and #4). >>> #3 add a new die variant that respects nonfatal Seems the most reasonable to me, but should be introduced with caution (if at all). It's very old question how to approach flow control: whether to: - maintain in using 'do_it_now_think_later' approach (exceptions' handling, nonfatal) - 'do_it_now_think_now' (checking return values) Ideally would be to have just one. And if the goal is to implement exception-handling-like (actually catching and ignoring) approach in flow control for EAPI3 instead of relying on return value (|| die) with runtime errors throwing (current 'die'), one would need not just one or two "die functions", but maybe whole family, with different fatality levels (for example controlled by environment variable, so that one could ignore those with level > 0 or could be more strict and only ignore those with level > 2, when 0 would be the most fatal, 1 less-lethal and so on). >>> #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? All existing 'die' invocations now are supposed to be fatal (according to definition in devmanual), so making them maybe-fatal in EAPI3 is wrong imho. General problem is defining what's really fatal and what's not - and I can assure that someone in a future will find some use case for preventing aborting of execution of some fatal function that failed. That being said I don't like refraining from "return value approach" towards "exception handling approach" (and I'm ebuild/eclass developer and I don't see adding || die very disturbing) that has been proposed for EAPI3 in die-on- failure utility functions, and thus I don't like nonfatal (which is of course needed for them). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Sat, 22 Aug 2009 00:40:04 +0200 Arfrever Frehtes Taifersar Arahesis wrote: > I would like to also notice that (not yet approved by Council) > definition of nonfatal() in PMS was recently drastically changed > without proper discussion with developers of other package managers. > [1] was sent about 20 minutes after discussion about nonfatal() > started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm > attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think > that such drastic changes should be first discussed on gentoo-dev > mailing list. There was no change to the definition of nonfatal. There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
2009-08-21 22:56:41 David Leverton napisał(a):
> In EAPI 3, most commands and functions provided by the package
> manager automatically call die if they fail. There's also a
> new "nonfatal" function that can be used to suppress this
> behaviour: by prefixing a function/command call with nonfatal,
> the automatic die behaviour is suppressed during the executation
> of that function/command.
>
> The difficulty here is that it's not clear what nonfatal should
> do to explicit die and assert calls. On the one hand, if
> nonfatal does suppress these functions, then nonfatal can be
> usefully used with eclass functions - silly hypothetical example:
>
> # eclass
> escons() {
> scons "$...@}" || die "scons failed"
> }
>
> # ebuild
> nonfatal escons || do_something_else
>
> On the other hand, it could be risky to change the behaviour of
> existing functions like that:
>
> do_foo() {
> cd foo || die "cd failed"
> # something that would be dangerous if run in some other directory
> }
>
> If called as "nonfatal do_foo" and the cd failed, do_foo
> /wouldn't/ return a failure code - it would proceed with the rest
> of its body and wreak all manner of havoc.
>
> One way around this would be to add either an option to die to
> explicitly tell it to respect nonfatal, or an alternative die
> function. This would allow eclasses to choose to respect
> nonfatal when it's safe to do so, but without changing existing
> behaviour. The disadvantage of this is that it would require
> changes to all eclass functions that could potentially use it,
> plus the slight ugliness of making them handle older EAPIs as
> well.
>
> Another option would be to make die respect nonfatal by default,
> and add an option that doesn't. This wouldn't require changes to
> eclasses that want the nonfatal behaviour, but it would require
> some care to make sure that it was used when necessary. A
> potential advantage of this over the previous solution is that if
> the "force" option is implemented with an environment variable,
> it can be used regardless of EAPI - the previous example could be
> changed to something like
>
> do_foo() {
> cd foo || DIE_FORCE=1 die "cd failed"
> # something that would be dangerous if run in some other directory
> }
>
> Does anyone have any opinions on which of the four options (#1
> make die respect nonfatal, #2 make die always die, #3 add a new
> die variant that respects nonfatal, #4 make regular die respect
> nonfatal, and add a new variant that doesn't) we should go with?
I think that 'DIE_FORCE=1 die "${die_message}"' (which was invented by me)
would be the
best option. It will allow to use nonfatal() with eclass functions with the
smallest
number of required changes in eclasses.
I would like to also notice that (not yet approved by Council) definition of
nonfatal()
in PMS was recently drastically changed without proper discussion with
developers of
other package managers. [1] was sent about 20 minutes after discussion about
nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev
mailing list.
[1]
http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml
--
Arfrever Frehtes Taifersar Arahesis
### Log session started at 2009-08-06T13:57:20 ###
[13:57:20] Arfrever [n=arfre...@gentoo/developer/arfrever] has joined #gentoo-portage
[13:57:20] Channel topic is: This is not a help/support channel || Ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || Portage resources: http://www.gentoo.org/proj/en/portage/index.xml#doc_chap6
[13:57:20] Topic was set by zmedico on 2009-06-07T06:54:17
[13:57:20] pratchett.freenode.net [...@*] has set channel mode +tnc
[13:57:20] Channel was created at 2006-11-26T07:42:44
[14:07:37] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: "No Ping reply in 90 seconds."
[14:11:27] scarabeus [n=sca...@net-2-2.jaw.cz] has joined #gentoo-portage
[14:37:51] sping_ [n=sp...@e179008226.adsl.alicedsl.de] has joined #gentoo-portage
[14:54:07] reavertm [n=reave...@gentoo/contributor/reavertm] has quit IRC: Remote closed the connection
[15:05:30] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:05:34] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Remote closed the connection
[15:05:50] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:06:05] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Client Quit
[15:08:02] slonopotamus [n=slono...@83.149.10.164] has quit IRC: Read error: 110 (Connection timed out)
[15:08:10] FuzzyRay [n=pvar...@gentoo/developer/FuzzyRay] has joined #gentoo-portage
[15:21:01] noisebleed [n=noise...@piggy.inescn.pt] has quit IRC: Remote closed the connection
[15:41:22] sping_ [n=sp...@gentoo/user/sping] is now known as sping
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Fri, 21 Aug 2009 23:09:33 +0200 Maciej Mrozowski wrote: > I suggest #5 - drop the idea of 'nonfatal'. Then how do you plan to handle all the standard utilities that die on failure in EAPI 3? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Friday 21 of August 2009 22:56:41 David Leverton wrote:
> Does anyone have any opinions on which of the four options (#1
> make die respect nonfatal, #2 make die always die, #3 add a new
> die variant that respects nonfatal, #4 make regular die respect
> nonfatal, and add a new variant that doesn't) we should go with?
> We should definitely get this resolved and agreed on before EAPI
> 3 is finalised.
I suggest #5 - drop the idea of 'nonfatal'.
Quoting devmanual:
"The die function should be used to indicate a fatal error and abort the
build. Its parameters should be the message to display."
Period.
In such case, following code:
nonfatal some_function
when:
some_function() {
so_sth || die "sth failed"
}
only means, that "some_function" shouldn't have been equipped with 'die'
mechanism, as use case appeared that demands it being non-fatal.
And in this case "some_function" should be fixed to be nonfatal instead (and
all existing invocations suffixed by "|| die".
Simple as this.
Please refrain from adding silly workarounds like this - only thing they add
is unnecessary complexity and thus maintenance/debugging burden.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
