Re: Coloring terminal output.
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.
Re: Coloring terminal output.
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\dappcolor.exe ←[34mThis is blue←[0m
Re: Coloring terminal output.
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\dappcolor.exe ←[34mThis is blue←[0m You have to use cwrite/cwritef/cwriteln/cwritefln, and it's not yet in the examples.
Re: Coloring terminal output.
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\dappcolor.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?
Re: Coloring terminal output.
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\dappcolor.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
Re: Coloring terminal output.
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
Re: Coloring terminal output.
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).
Re: Coloring terminal output.
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
Re: Coloring terminal output.
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.
Re: Coloring terminal output.
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. :)
Re: Coloring terminal output.
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?
Re: Coloring terminal output.
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);
}
Re: Coloring terminal output.
On Mon, Jul 14, 2014 at 20:09:04 +, 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
Re: Coloring terminal output.
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.
Re: Coloring terminal output.
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*.
Re: Coloring terminal output.
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.
