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).

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

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.

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

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.

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?

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