Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-25 Thread Ciaran McCreesh
On Tue, 25 Aug 2009 12:21:46 +0200
"Marijn Schouten (hkBst)"  wrote:
> What is the reason that we are trying to generalize non-fatal from a
> simple switch to a full-blown primitive that should handle whatever
> it's thrown?

We aren't. nonfatal is done as a prefix rather than a --switch for the
same reason that 'nice' is.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-25 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Faulhammer wrote:
> Hi,
> 
> Ryan Hill :
> 
>> On Fri, 21 Aug 2009 21:56:41 +0100
>> 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'd like die to respect nonfatal.  People using nonfatal should check
>> beforehand that the functions they're calling won't do anything
>> stupid if die's are ignored.  If there's something that absolutely
>> has to die, nonfatal or not, then use a variable.  I guess that's #4?
> 
>  I agree here (yes, I know, a "ME TOO" posting, but I say this as PMS
> team member).

I thought the whole idea was that functions that don't currently die by default
because sometimes this is unwanted will now die by default but provide an opt
out --non-fatal switch to get back the old behavior. In the non-fatal case such
functions should then again (as in the current situation) not call die.

Some functions will not have a --non-fatal switch.
Some functions should not have a --non-fatal switch.
Some functions will call die unconditionally.

What is the reason that we are trying to generalize non-fatal from a simple
switch to a full-blown primitive that should handle whatever it's thrown?

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqTuzoACgkQp/VmCx0OL2xh1ACgjvtPz+3uke5p2p+iVuSmGw1u
JKwAn2O2l1h8gRDkGnfZ2aIwaIHvlr/L
=ybPQ
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-24 Thread Ciaran McCreesh
On Mon, 24 Aug 2009 15:09:52 -0700
Zac Medico  wrote:
> > I'd like die to respect nonfatal.  People using nonfatal should
> > check beforehand that the functions they're calling won't do
> > anything stupid if die's are ignored.
> 
> If you're doing that then it might be wise to add an 'assert' helper
> that is guaranteed to generate an exception regardless of 'nonfatal'
> status.

Probably not the best choice of name... 'assert' is already in use for
checking PIPESTATUS.

The other problem with doing things that way is that people have to
start writing code that does an EAPI check just to be able to force a
die. An IGNORE_NONFATAL environment variable, whilst slightly ickier,
avoids that issue if we do change the definitions of die and nonfatal.

*shrug* I still think the way it was originally worded is the best
option. Otherwise we'll just replace the "some helpers die, some don't,
and no-one knows which" situation with "some eclass functions are
nonfatal aware, some aren't, and no-one knows which", with an added
side helping of "people need to find out whether any of the callers in
any overlay anywhere expect this function to work with nonfatal before
changing it".

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-24 Thread Zac Medico
Ryan Hill wrote:
> On Fri, 21 Aug 2009 21:56:41 +0100
> 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'd like die to respect nonfatal.  People using nonfatal should check
> beforehand that the functions they're calling won't do anything stupid if
> die's are ignored.

If you're doing that then it might be wise to add an 'assert' helper
that is guaranteed to generate an exception regardless of 'nonfatal'
status.
-- 
Thanks,
Zac



Re: [gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-24 Thread Thomas Anderson
On Mon, Aug 24, 2009 at 08:20:44PM +0200, Christian Faulhammer wrote:
> Hi,
> 
> Ryan Hill :
> 
> > On Fri, 21 Aug 2009 21:56:41 +0100
> > 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'd like die to respect nonfatal.  People using nonfatal should check
> > beforehand that the functions they're calling won't do anything
> > stupid if die's are ignored.  If there's something that absolutely
> > has to die, nonfatal or not, then use a variable.  I guess that's #4?
> 
>  I agree here (yes, I know, a "ME TOO" posting, but I say this as PMS
> team member).

I must agree here too as a PMS team member. so 'me too' :P

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgp1DcsVBwPus.pgp
Description: PGP signature


[gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-24 Thread Christian Faulhammer
Hi,

Ryan Hill :

> On Fri, 21 Aug 2009 21:56:41 +0100
> 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'd like die to respect nonfatal.  People using nonfatal should check
> beforehand that the functions they're calling won't do anything
> stupid if die's are ignored.  If there's something that absolutely
> has to die, nonfatal or not, then use a variable.  I guess that's #4?

 I agree here (yes, I know, a "ME TOO" posting, but I say this as PMS
team member).

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://gentoo.faulhammer.org/>


signature.asc
Description: PGP signature


[gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-21 Thread Ryan Hill
On Fri, 21 Aug 2009 21:56:41 +0100
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'd like die to respect nonfatal.  People using nonfatal should check
beforehand that the functions they're calling won't do anything stupid if
die's are ignored.  If there's something that absolutely has to die, nonfatal
or not, then use a variable.  I guess that's #4?


-- 
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


[gentoo-dev] Re: EAPI 3 and "nonfatal die"

2009-08-21 Thread David Leverton
On Friday 21 August 2009 21:56:41 David Leverton wrote:
> 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

...except that the previous solution could use an environment variable too, of 
course.