For brevity, I'd prefer to simply use "internal error:" for both (which I was tempted to do anyway, but didn't due to my five minutes elapsing), and would be happy to have someone else own this. I agree that calling these "errors" rather than "failures" is more consistent.
-Brad On Thu, 20 Mar 2014, Vassily Litvinov wrote: > My suggestion is to retain "error:" in the message that gets printed upon an > internal failure. That's to simplify human search for issues in a long job > output. In other words, an internal failure will result in: > > # developer mode > internal failure error: <message intended for developers> > > # user mode > internal failure error: CAL0123 > > Brad - I can give you a hand adjusting your patch for that. > > Vass > > On 03/19/14 17:39, Brad Chamberlain wrote: >> >> Chapel Devs -- >> >> This is a patch that logically falls into Vass's court though everyone >> should read the description to raise objections, if any. >> >> >> In breaking one of Vass's futures this week, it looked like (and was) a >> candidate for a 5-minute fix (TM). The issue raised was that internal >> failures, when compiled in developer mode, don't do anything to mark >> themselves as internal failures -- they just say something like: >> >> 'error: <message intended for developers>' >> >> whereas for users they say something like: >> >> 'error: internal failure CAL123' >> >> Vass suggested that something should indicate that the case was an >> internal failure in developer mode as well and this didn't seem >> objectionable to me (though I'd never actually noticed before). >> >> >> The approach I took was to make developer mode print out: >> >> 'internal failure: <message intended for developers>' >> >> but this unwittingly caused the user message to say: >> >> 'internal failure: internal failure CAL123' >> >> So I then shortened the second case to simply: >> >> 'internal failure: CAL123' >> >> If there are no objections to these formatting issues, the change itself >> is pretty straightforward (though also hard to test since our tests run >> in --no-devel mode). The tax on the 5-minute fix was getting other >> .futures, particularly with .prediffs and .bad files, to match properly >> against the new format. >> >> -Brad >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> >> >> >> _______________________________________________ >> Chapel-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-developers >> > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
