corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Colo(u)rs?
Date Tue, 26 May 2015 11:47:55 GMT
On 26 May 2015 at 00:13, Gabriela Gibson <gabriela.gibson@gmail.com> wrote:

> On Mon, May 18, 2015 at 9:14 AM, jan i <jani@apache.org> wrote:
>
> > On 18 May 2015 at 01:48, Gabriela Gibson <gabriela.gibson@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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message