July 27, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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).
|
July 27, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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
|
July 31, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | 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.
|
July 31, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to ponce | 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
|
July 31, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | 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. |
July 31, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to ponce | 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?
|
July 31, 2014 Re: Coloring terminal output. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | 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 |
Copyright © 1999-2021 by the D Language Foundation