similar to: [LLVMdev] Old DOUT

On Friday 11 December 2009 11:35, Chris Lattner wrote: = > > I'm not sure what you mean here. It's not ok to convert code under > > DEBUG() or #ifndef NDEBUG to use dbgs()? > > Right. > > > Then what's the point of providing it? > > I don't know what dbgs does, so I don't know! dbgs() will be a circular-buffering raw_ostream, meaning it saves

On Thursday 10 December 2009 16:30, Anton Korobeynikov wrote: > Hello, David > > > What replaced the old DOUT? > > DEBUG(errs() << foo); > > The reason is quite simple - DOUT in release mode was just /dev/null, > but the functions sending data to it were still called. errs() is no good. I would want to keep errs() printing things out immediately. I need

On Thursday 10 December 2009 17:53, Chris Lattner wrote: > > So I would write the above as: > > > > DEBUG(dbgs() << foo); > > > > Does that sound reasonable? > > If you're asking if a new dbgs() might be useful, "yes if specified well". > If you're asking if you can convert everything to using it, "no". I'm not sure

On Dec 11, 2009, at 9:03 AM, David Greene wrote: >> >> If you're asking if a new dbgs() might be useful, "yes if specified well". >> If you're asking if you can convert everything to using it, "no". > > I'm not sure what you mean here. It's not ok to convert code under DEBUG() or > #ifndef NDEBUG to use dbgs()? Right. > Then

On Dec 11, 2009, at 9:44 AM, David Greene wrote: > On Friday 11 December 2009 11:35, Chris Lattner wrote: > = >>> I'm not sure what you mean here. It's not ok to convert code under >>> DEBUG() or #ifndef NDEBUG to use dbgs()? >> >> Right. >> >>> Then what's the point of providing it? >> >> I don't know what dbgs

On Dec 10, 2009, at 1:46 PM, David Greene wrote: > On Thursday 10 December 2009 16:30, Anton Korobeynikov wrote: >> Hello, David >> >>> What replaced the old DOUT? >> >> DEBUG(errs() << foo); >> >> The reason is quite simple - DOUT in release mode was just /dev/null, >> but the functions sending data to it were still called. >

Hello, David > What replaced the old DOUT? DEBUG(errs() << foo); The reason is quite simple - DOUT in release mode was just /dev/null, but the functions sending data to it were still called. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Dec 11, 2009, at 9:44 AM, David Greene wrote: > On Friday 11 December 2009 11:35, Chris Lattner wrote: > = >>> I'm not sure what you mean here. It's not ok to convert code under >>> DEBUG() or #ifndef NDEBUG to use dbgs()? >> >> Right. >> >>> Then what's the point of providing it? >> >> I don't know what dbgs

On Friday 18 December 2009 12:28, Chris Lattner wrote: > This is looking a lot better, here are some more comments: > > + /// current_pos - Return the current position within the stream, > > + /// not counting the bytes currently in the buffer. > > + virtual uint64_t current_pos() { > > I didn't notice this earlier, but is there any reason for current_pos

On Friday 18 December 2009 19:47, Chris Lattner wrote: > On Dec 18, 2009, at 3:46 PM, David Greene wrote: > > + /// circular_raw_ostream - A raw_ostream that saves its output in a > > + /// circular buffer. > > A better description would be "which *can* save its data to a circular > buffer, or can pass it through directly to an underlying stream if > specified

On Tuesday 04 August 2009 18:24, Chris Lattner wrote: > The big issue is things like this: > > DOUT << foo.getName() << "\n"; > > When -debug is disable and even when assertions are turned off, > foo.getName() is still called. When you use: Yep, that's a problem. > DEBUG(errs() << foo.getName() << "\n"); > > When

On Dec 18, 2009, at 3:46 PM, David Greene wrote: > > + /// circular_raw_ostream - A raw_ostream that saves its output in a > + /// circular buffer. A better description would be "which *can* save its data to a circular buffer, or can pass it through directly to an underlying stream if specified with a buffer of zero." When it is buffering, what causes it to flush? Your

On Friday 18 December 2009 20:20, David Greene wrote: > I wanted something to signify in the output where the debug dump starts. > That's for that case where some stuff might still get output through > errs(). I anticipate that while I'll change most uses of errs() to dbgs(), > we probably don't want to change all of them. > > I agree the naming here is poor.

On Dec 17, 2009, at 3:41 PM, David Greene wrote: > On Wednesday 16 December 2009 13:35, David Greene wrote: > >>> Please make BufferSize an 'unsigned' and default it to 8192. Please use >>> PRESERVE_STREAM instead of 'false'. > > Here's an updated version of the circular buffer. Ok to check in? This is looking a lot better, here are some more

On Wednesday 16 December 2009 13:35, David Greene wrote: > > Please make BufferSize an 'unsigned' and default it to 8192. Please use > > PRESERVE_STREAM instead of 'false'. Here's an updated version of the circular buffer. Ok to check in? -Dave Index: include/llvm/Support/circular_raw_ostream.h

On Friday 18 December 2009 17:27, David Greene wrote: > > Here's the updated patch. > > Well, that didn't go through right. Here it is again. Argh! Stupid bug fixed. :) Index: include/llvm/Support/circular_raw_ostream.h =================================================================== --- include/llvm/Support/circular_raw_ostream.h (revision 0) +++

Here's the patch to provide dbgs(). By default it works just like errs(). When -debug-buffer-size=N (N > 0) is set, it buffers output sent to it and dumps it at program termination via a signal handler. Please review. Thanks! -Dave Index: include/llvm/Support/Debug.h =================================================================== ---

On Dec 21, 2009, at 8:05 AM, David Greene wrote: > On Friday 18 December 2009 20:20, David Greene wrote: > >> I wanted something to signify in the output where the debug dump starts. >> That's for that case where some stuff might still get output through >> errs(). I anticipate that while I'll change most uses of errs() to dbgs(), >> we probably don't

On Dec 17, 2009, at 4:02 PM, David Greene wrote: > Here's the patch to provide dbgs(). By default it works just like > errs(). > When -debug-buffer-size=N (N > 0) is set, it buffers output sent to > it and > dumps it at program termination via a signal handler. > > Please review. Thanks! > > -Dave > > Index:

On Tuesday 04 August 2009 10:46, Chris Lattner wrote: > On Aug 4, 2009, at 8:29 AM, Aaron Gray wrote: > > How do output hex in DOUT's ? > > Please don't use DOUT, please use: > > DEBUG(errs() << stuff); > > instead. I've got some more DOUT-involving patches in the queue. Is this a general design choice that's been made? If so I can change the