On 26 May 2015 at 00:13, Gabriela Gibson <gabriela.gib...@gmail.com> wrote:
> On Mon, May 18, 2015 at 9:14 AM, jan i <j...@apache.org> wrote: > > > On 18 May 2015 at 01:48, Gabriela Gibson <gabriela.gib...@gmail.com> > > wrote: > > > > > > > > > > 1) Does anyone else other than me find this kind of thing useful? > > > > > I had not thought of it, but it is not a bad idea....just wonder where we > > have output that benefit from coloring. > > > > I find it useful for debugging when: > > 1) there is a lot of output. Looking for something blue is quicker than > reading it all. > > 2) If there is something that does not always occur and that may go under > in other output. > > > > > > > > > 2) Is it portable? > > > > > I dont think so, for a number of reasons...I would not know how to do > color > > on a vt100 terminal in Linux or a dos prompt in windows. > > > > Hmm, but I guess it would work on a cygwin xterm in windows or on a mac? > As in, partially portable? ;-) > -1 for using cygwin, or even suggesting it. You might have a look at the dos command prompt, in earlier days ANSI was supported, but it no longer is, however there is a utility that enables that. I have NO problem that we suggest developers to install that utility. http://stackoverflow.com/questions/16755142/how-to-make-win32-console-recognize-ansi-vt100-escape-sequences > > > > > > > 3) If 1 & 2, would you enjoy this dev debugging feature being > > > added? > > > > > Yes an no. > > > > We should never use printf or similar in DocFormats, those are bound to > > give problems in a number of cases. > > > > I discussed earlier with Peter, the idea that we make some DEBUG_PRINT > > macros. The macro should contain > > an #ifdef DEBUG (or similar), but most importantly it should NOT do > printf. > > > > Instead it should print via a global function pointer (parameters like > > printf). That way the main program can decide to use > > printf or other functions (when we define the API, we will have a setup() > > call, that could then included the function ptr. > > > > Going down that road, would open up for LOG_PRINT, WARNING_PRINT, > > INFO_PRINT as well. > > > > That would be handy. It's also nice to be able to leave in debugging > statements sometimes and being able to turn just that suite on or off. > > > > I am very much for the MACROS, and against a direct printf. Colors is > more > > a portability concern. > > > > I did some thinking today how to keep colour out of Corinthias' hair but > still be able to use it locally and had the idea that I should try and make > a dynamic library for the colors, so that I can easily use it everything I > do in C. I'm sure someone already wrote a RollsRoyce doing just the same > thing, but, it was fun nevertheless and a good reason to learn about the > topic. I am now proud owner of my very own /usr/local/lib/libcolor.so and > have started to use it -- profit! :> > I am -1 to add an extra library, this should be internal functions. > > This together with Jan's debug print macros idea makes me think that maybe > there is already such a library of a good debug system out there we could > use, or, if there isn't, perhaps separating this kind of service out would > not be the worst thing to do -- having a great debug mechanism that I know > and that just works everywhere for me would be brill. > +1 but integrated please. rgds jan i > > G > > Ps.: Btw, it appears (if one is inclined to believe a Reddit meme!) that > the literal translation of the Chinese name for 'owl' is 'cat head eagle'. > > > > rgds > > jan i. > > > > > > > > > G > > > > > > -- > > > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ > > > > > > > > > -- > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ >
