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'
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
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.
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
T
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
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', 'en
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. Thi
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 wi
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'.
--
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 nonfata
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 ab
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,
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
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 does
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 e
15 matches
Mail list logo
