search for: dumpable

...that the code would never allow, and getting 100% test coverage (of lines AND branches), only to realize that a test engineer could break my new feature in many different ways by misusing it on a command-line level. I personally think we'd have a much better use of time by making the MI layer dumpable and re-readable, so we could create lots of very specific low-level tests, than having yet-another unit-test infrastructure. The only place I think that unit-tests are worthy is on base libraries (APFLoat, APInt, containers, basic algorithms), and for that, you need nothing special. > Furthe...

Good morning, Now that hdt is capable of dumping system information it would be nice if there was some sort of filtering system which filters out unwanted information prior to dumping output. For example one could add the command: append nomenu auto=dump mac_address serial_number bios_version; And ultimately dumping output to a plain text file like: mac_address : 00:11:22:33:44 serial_number :

...different from the ''filter'' table, in that only the first packet of a new connection will traverse the table. The result of this traversal is then applied to all future packets of the same connection." I imagine that the result of this traversal is stored in a kernel table, dumpable through "/proc/net/ip_conntrack". There is no information about the destination device of the route... When is the route decision made? After setting all the information gathered from ip_conntrack, or _before_ that? It isn''t clear to me, if the "applying of the result of the...

...C_CHECK_FUNCS might not find prctl() due to the autoconf-generated test program not #including <sys/prctl.h>. Assuming I got that right, I have two comments on it: (1) A false negative in this case would not be a huge problem; we'd miss out on prctl(), i.e. the test program would remain dumpable on Linux. The test would still function as needed, just litter the user's machine with a coredump during "make check". Not ideal, but also not tragic. (2) I believe I disagree with the idea that AC_CHECK_FUNCS might not find an otherwise existent prctl() *due to* AC_CHECK_FUNCS not g...

...er allow, and getting 100% test coverage (of lines AND > branches), only to realize that a test engineer could break my new feature > in many different ways by misusing it on a command-line level. > > I personally think we'd have a much better use of time by making the MI > layer dumpable and re-readable, so we could create lots of very specific > low-level tests, than having yet-another unit-test infrastructure. > > The only place I think that unit-tests are worthy is on base libraries > (APFLoat, APInt, containers, basic algorithms), and for that, you need > nothing...

On Nov 14, 2013, at 12:52 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 14, 2013 at 10:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> wrote: >> However, when we are adding interfaces or generic utilities to LLVM (admittedly, not the common case) I don't think we do

...gram not #including <sys/prctl.h>. Bingo - you caught my poorly stated conclusion. > > Assuming I got that right, I have two comments on it: > > (1) A false negative in this case would not be a huge problem; we'd miss > out on prctl(), i.e. the test program would remain dumpable on Linux. > The test would still function as needed, just litter the user's machine > with a coredump during "make check". Not ideal, but also not tragic. I'm not sure if it remains a core dump, or if it becomes dumpabale to ABRT (or whatever else was consuming the pipeline...

> -----Original Message----- > From: owner-vorbis-dev@xiph.org [mailto:owner-vorbis-dev@xiph.org]On > Behalf Of Steve Underwood > Sent: Tuesday, January 23, 2001 10:58 AM > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] Fixed vs. Floating Point primer. was: > Implementing Vorbis in hardware > > > "Borgerding, Mark A." wrote: > > [...] > >

On Thu, Nov 14, 2013 at 10:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 14, 2013, at 3:16 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > However, when we are adding interfaces or generic utilities to LLVM > (admittedly, not the common case) I don't think we do ourselves any favors > by using only half of the available tools to write

http://bugs.freedesktop.org/show_bug.cgi?id=14859 Summary: External analog monitor does not show part of the output (Randr12) Product: xorg Version: unspecified Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau