corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Colo(u)rs?
Date Tue, 26 May 2015 01:31:53 GMT
Oh, and on the main topic (of colours) - I suggest making it either a command-line option or
an environment variable. Colours are great when viewing output on the terminal (and piping
through less, you can pass it the -R command line option to have it preserve the colours),
but sometimes if you want to redirect output to a file and then open it in an editor you might
not want those control characters there.

As others have mentioned, I believe there may be compatibility problems with windows as well
- hence using macros which can easily be placed inside #ifndef WINDOWS (with an empty alternative
for windows) would be a good solution here.

The other day I happened to watch part of the famous “BBS documentary” which talked about
the fascinating ANSI art scene in the 80s & early 90s, and how part of the reason that
ended up dying out was that it became harder to view ANSI files under windows - https://www.youtube.com/watch?v=2ReS4Bp4IPY

I actually started using colour in this manner recently in a Python program I’m writing.
Rather than have macros to turn it on or off, I defined functions to set a particular colour,
add the string, then have the ANSI code to reset the colour:

def magenta2(s):
    return '\033[1;95m'+str(s)+'\033[m’

In a C macro, this would probably be something like (not tested):

#define magenta(s) "\033[1;95m” s "\033[m”

and with the windows conditional definition:

#ifdef WINDOWS
#define magenta(s) s
#else
#define magenta(s) "\033[1;95m” s "\033[m”
#endif

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

> On 26 May 2015, at 5:13 am, 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? ;-)
> 
> 
>>> 
>>> 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! :>
> 
> 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.
> 
> 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