On 02/16/2012 10:42 PM, Ian Pilcher wrote:
> I'm willing to bet that I wouldn't be getting a "NameError: global name
> 'BRFSError' is not defined" traceback if it were. (BTRFSError anyone?)
Apparently it's not BTRFSError either.
https://bugzilla.redhat.com/show_bug.cgi?id=796013
--
=
On Mon, 20 Feb 2012 17:33:11 -0500
Jon Stanley wrote:
> No packages need to be installed, everything is right there in the
> install environment. In the window with the traceback, there's a
> 'debug' option that will drop you into PDB (I haven't looked at the
> code, but it probably calls pdb.pos
On 16 February 2012 21:42, Ian Pilcher wrote:
> Just kidding ... sort of.
>
> I'm willing to bet that I wouldn't be getting a "NameError: global name
> 'BRFSError' is not defined" traceback if it were. (BTRFSError anyone?)
>
Would writing it in pypy count :)?
--
Stephen J Smoogen.
"The core sk
> No packages need to be installed, everything is right there in the
> install environment. In the window with the traceback, there's a
> 'debug' option that will drop you into PDB (I haven't looked at the
> code, but it probably calls pdb.post_mortem() with the exception
> object). See http://docs
On Mon, Feb 20, 2012 at 5:21 PM, stan wrote:
> Can you expand on entering the debugger when a traceback occurs? What
> packages need to be installed? How is it invoked immediately after the
> traceback in order to pick up the failed job?
No packages need to be installed, everything is right th
On Sun, 19 Feb 2012 22:56:25 -0500
Jon Stanley wrote:
> No, you'd instead get much less useful errors instead. Obviously this
> particular typo would never compile, but logic errors, instead of
> giving you a nice traceback (and the ability to enter a debugger
> straight from where the installer
On Thu, Feb 16, 2012 at 11:42 PM, Ian Pilcher wrote:
> I'm willing to bet that I wouldn't be getting a "NameError: global name
> 'BRFSError' is not defined" traceback if it were. (BTRFSError anyone?)
No, you'd instead get much less useful errors instead. Obviously this
particular typo would nev
On Sun, Feb 19, 2012 at 23:43, Bryn M. Reeves wrote:
> Human decisions are removed from system installation. Anaconda begins to
> learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern
> time, May 8th, 2012. ;-)
This is why we really need to move to a language where this kind of
th
On 02/18/2012 12:02 AM, Rick Stevens wrote:
> On 02/17/2012 02:27 PM, FRank Murphy wrote:
>> On 17/02/12 20:52, John Dulaney wrote:
>>>
>>> I say, write it in Fortran!
>>>
>>>
>>
>> Cobol.
>
> I'd vote for PL/1, APL, Ada, or BCPL. But let's get really odd...
> how about Lisp? After all, we want
On 02/17/2012 02:27 PM, FRank Murphy wrote:
On 17/02/12 20:52, John Dulaney wrote:
I say, write it in Fortran!
Cobol.
I'd vote for PL/1, APL, Ada, or BCPL. But let's get really odd...
how about Lisp? After all, we want Anaconda to self-extend to handle
all possible conditions, don't we?
On 17/02/12 20:52, John Dulaney wrote:
I say, write it in Fortran!
Cobol.
--
Regards
Frank "Jack of all Fubars"
Learning "Till the day I die"
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
> Date: Fri, 17 Feb 2012 09:29:01 -0500
> From: clum...@redhat.com
> To: test@lists.fedoraproject.org
> Subject: Re: Anaconda should be rewritten in a compiled language!
>
> > Just kidding ... sort of.
> >
> > I'm willing to bet that I wouldn&
> Just kidding ... sort of.
>
> I'm willing to bet that I wouldn't be getting a "NameError: global name
> 'BRFSError' is not defined" traceback if it were. (BTRFSError anyone?)
>
> Bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=794504.
You know, redoing it in Haskell really would solve
On Thu, 2012-02-16 at 22:42 -0600, Ian Pilcher wrote:
> Just kidding ... sort of.
I take it you're volunteering? ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraprojec
14 matches
Mail list logo
