www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Coloring terminal output.

reply "yamadapc" <tacla.yamada gmail.com> writes:
Hello all :)

I've made a simple port of ruby's colorize library for D.
I'd greatly appreciate any feedback. Windows isn't supported,
yet.

Links:
http://code.dlang.org/packages/colorize
https://github.com/yamadapc/d-colorize
https://github.com/fazibear/colorize
Jul 13 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 13 July 2014 at 20:11:19 UTC, yamadapc wrote:
 Hello all :)

 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.

 Links:
 http://code.dlang.org/packages/colorize
 https://github.com/yamadapc/d-colorize
 https://github.com/fazibear/colorize
It looks good. This stuff is always a pain to handle so i appreciate you wrapping this up into a library. :)
Jul 14 2014
prev sibling next sibling parent reply "Suliman" <evermind live.ru> writes:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.
Cool! Would it be hard to add windows support?
Jul 14 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 Cool! Would it be hard to add windows support?
I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d works on both platforms. import terminal; void main() { // get the terminal object for linear output auto terminal = Terminal(ConsoleOutputType.linear); // set foreground and background colors terminal.color(Color.green | Bright, Color.black); // to use default btw: // terminal.color(Color.DEFAULT, Color.DEFAULT); // write with this instead of regular stdout terminal.write("hello\n"); }
Jul 14 2014
next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Jul 14, 2014 at 20:09:04 +0000, Adam D. Ruppe via
Digitalmars-d-announce wrote:
 My terminal.d offers color output through special function calls: 
 https://github.com/adamdruppe/arsd/blob/master/terminal.d
Scanning this, I see missing termcap for screen and screen-256color which are fairly common. Also rxvt-unicode-256color (if it supports 256 colors which a quick scan didn't seem to indicate). --Ben
Jul 14 2014
prev sibling parent reply "yamadapc" <tacla.yamada gmail.com> writes:
On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 Cool! Would it be hard to add windows support?
I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d
Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution.
Jul 14 2014
parent reply "Alexandre L." <alex.cs00 yahoo.ca> writes:
On Monday, 14 July 2014 at 22:51:17 UTC, yamadapc wrote:
 On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 Cool! Would it be hard to add windows support?
I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d
Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution.
If you wish, I have some small examples on my github. github.com/mrtryhard/dlang Directory 'console'. It provides minimalistic console support for Windows only. However I was pissed that some headers / functions weren't available so I kind of lacked the updates on it.
Jul 14 2014
parent "Alexandre L." <alex.cs00 yahoo.ca> writes:
On Tuesday, 15 July 2014 at 00:21:09 UTC, Alexandre L. wrote:
 On Monday, 14 July 2014 at 22:51:17 UTC, yamadapc wrote:
 On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 Cool! Would it be hard to add windows support?
I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d
Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution.
If you wish, I have some small examples on my github. github.com/mrtryhard/dlang Directory 'console'. It provides minimalistic console support for Windows only. However I was pissed that some headers / functions weren't available so I kind of lacked the updates on it.
Sorry, I meant example for Windows support*.
Jul 14 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
Jul 31 2014
parent reply "Suliman" <evermind live.ru> writes:
On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
I tried to build on Windows example and get on console next: D:\code\d>appcolor.exe ←[34mThis is blue←[0m
Jul 31 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
 On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
I tried to build on Windows example and get on console next: D:\code\d>appcolor.exe ←[34mThis is blue←[0m
You have to use cwrite/cwritef/cwriteln/cwritefln, and it's not yet in the examples.
Jul 31 2014
parent reply "Suliman" <evermind live.ru> writes:
On Thursday, 31 July 2014 at 13:45:45 UTC, ponce wrote:
 On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
 On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't 
 supported,
 yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
I tried to build on Windows example and get on console next: D:\code\d>appcolor.exe ←[34mThis is blue←[0m
You have to use cwrite/cwritef/cwriteln/cwritefln, and it's not yet in the examples.
Now, I had used examples from github. Would it's possible to add support of color to classical writeln?
Jul 31 2014
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 31 July 2014 at 17:01:22 UTC, Suliman wrote:
 On Thursday, 31 July 2014 at 13:45:45 UTC, ponce wrote:
 On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote:
 On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote:
 On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't 
 supported,
 yet.
Cool! Would it be hard to add windows support?
Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
I tried to build on Windows example and get on console next: D:\code\d>appcolor.exe ←[34mThis is blue←[0m
You have to use cwrite/cwritef/cwriteln/cwritefln, and it's not yet in the examples.
Now, I had used examples from github. Would it's possible to add support of color to classical writeln?
Not for writing to a classic windows cmd.exe as it doesn't support ANSI/VT100 escape sequences. Either use a better terminal or perhaps try this: https://github.com/adoxa/ansicon
Jul 31 2014
prev sibling next sibling parent Lionello Lunesu <lionello lunesu.remove.com> writes:
On 13/07/14 22:11, yamadapc wrote:
 Hello all :)

 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.

 Links:
 http://code.dlang.org/packages/colorize
 https://github.com/yamadapc/d-colorize
 https://github.com/fazibear/colorize
Good timing. I just added coloring support to DMD: https://github.com/D-Programming-Language/dmd/blob/master/src/color.c You can clearly see the difference between Windows and *nix. L.
Jul 16 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/13/14, 5:11 PM, yamadapc wrote:
 Hello all :)

 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.

 Links:
 http://code.dlang.org/packages/colorize
 https://github.com/yamadapc/d-colorize
 https://github.com/fazibear/colorize
It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts "hello".colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr
Jul 27 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/27/14, 11:16 AM, Ary Borenszweig wrote:
 On 7/13/14, 5:11 PM, yamadapc wrote:
 Hello all :)

 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.

 Links:
 http://code.dlang.org/packages/colorize
 https://github.com/yamadapc/d-colorize
 https://github.com/fazibear/colorize
It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts "hello".colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr
Also, usually the color is known by the user and not something that is put in a variable and later read. So having convenience methods that don't do a big case over the color or an enum value is again more performant. Something like: "hello".colorize.red instead of: "hello".colorize(fg.red) which is shorter, more readable *and* more efficient. You could generate those methods at compile time based on all the colors (which is something we do in Crystal too).
Jul 27 2014
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 7/27/14, 11:31 AM, Ary Borenszweig wrote:
 On 7/27/14, 11:16 AM, Ary Borenszweig wrote:
 On 7/13/14, 5:11 PM, yamadapc wrote:
 Hello all :)

 I've made a simple port of ruby's colorize library for D.
 I'd greatly appreciate any feedback. Windows isn't supported,
 yet.

 Links:
 http://code.dlang.org/packages/colorize
 https://github.com/yamadapc/d-colorize
 https://github.com/fazibear/colorize
It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts "hello".colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr
Also, usually the color is known by the user and not something that is put in a variable and later read. So having convenience methods that don't do a big case over the color or an enum value is again more performant. Something like: "hello".colorize.red instead of: "hello".colorize(fg.red) which is shorter, more readable *and* more efficient. You could generate those methods at compile time based on all the colors (which is something we do in Crystal too).
Finally, don't restrict "colorize" to a string. You could colorize any object: # works, without converting [1, 2, 3] to a string puts [1, 2, 3].colorize.red
Jul 27 2014