Hi everyone,

This might be me being a little bit picky, but I noticed the new colouring scheme for words like "Warning" and "Error" in the output logs.  Is there any particular reason why "Warning" is in magenta?  Normally the convention is that it's yellow (and "Error" in red).  Granted, it's purely cosmetic.

Gareth aka. Kit

What version of the trunk is this in and what's the flag to enable it? My trunk is maybe 30 days old and I don't see any way to get the colors.

Regards,
Ryan Joseph

I'm using the latest trunk on arm-linux.  I'm pretty sure it's in the FPC source and not some quirk with the Raspian OS's terminal because the escape sequences appear in the "Console In/Output" debug window in Lazarus.

Gareth aka. Kit

The feature request was here: https://bugs.freepascal.org/view.php?id=37331

It's magenta because GCC etc use magenta for warnings too. Actually, for those of us with white terminal backgrounds, yellow text would be hard to see, while green, red, and magenta appear quite well against both a black and a white background.

I hope a new FPC release happens sooner rather than later; colored output is really nice to have.

~Kirinn

Ryan Joseph wrote

What version of the trunk is this in and what's the flag to enable it? My trunk is maybe 30 days old and I don't see any way to get the colors.

It's only enabled on Linux and Windows currently.

Jonas

Jonas Maebe wrote

On 22/11/2020 16:03, Ryan Joseph via fpc-devel wrote: > What version of the trunk is this in and what's the flag to enable it? My trunk is maybe 30 days old and I don't see any way to get the colors. It's only enabled on Linux and Windows currently.

Is there a switch to disable it ?
The lazarus parser doesn't need color, it supplies it's own in the messages dialog.

I looked in the help but could not see one, maybe it was forgotten.

Michael.

Michael Van Canneyt via fpc-devel schrieb
am So., 22. Nov. 2020, 17:03:

It's only enabled if the output is to a TTY and not a pipe (analogous on Windows).

Regards,
Sven

Both GCC and Clang use magenta for warnings as well. So considering that FPC follows the convention. ;)

Regards,
Sven

The next major release is a year or two away. Don't know if we'll merge that back to fixes...

Regards,
Sven

Fair enough then!  I always thought yellow was for warnings, red was for errors and white was for notes, but if GCC says otherwise, I can't argue!

Gareth aka. Kit

I believe that to enable colour on a Windows console, you need to use an API function, which can get a bit clumsy because there isn't an equivalent to \e[0m to reset to default, so you have to retrieve the current console colour beforehand.  Windows 10 /might/ accept the ANSI escape sequences, but I'm not sure.

Gareth aka. Kit

On Nov 22, 2020, at 8:57 AM, Jonas Maebe via fpc-devel wrote: It's only enabled on Linux and Windows currently.

Why is that? Mac has colors in the terminal also.

Regards,
Ryan Joseph

Because I have no Mac so I couldn't test it.

Most modern Macs are Unix-based, so the escape sequences should work, right? Granted, I think we need someone with a Mac or a Mac virtual machine to test it for sure.

Gareth aka. Kit

On Windows the code checks whether the VT100 compatibility is available that was introduced with some Windows 10 update and only uses the VT100 codes in that case.

Regards,
Sven

J. Gareth Moreton wrote

Most modern Macs are Unix-based, so the escape sequences should work, right? Granted, I think we need someone with a Mac or a Mac virtual machine to test it for sure.

Considering that Jonas doesn't support the textmode IDE on macOS because of - if I remember correctly - problems with the terminal I wouldn't be too sure that it's fully compatible. Though granted, for colored output it should be enough...

Regards,
Sven

No, the terminal works fine with it (apart from mouse support, which only works if you use Xterm). I don't support it because the IDE is not really maintained by anyone, and I don't want to maintain or debug it either (so if someone would report a bug on macOS with it, it would just sit there forever).

Jonas

That's a fair point. Good call.

Gareth aka. Kit

On Nov 22, 2020, at 9:29 AM, Florian Klämpfl via fpc-devel wrote: Because I have no Mac so I couldn't test it.

I see. It's this easy.

const
  ANSI_FORE_BLACK           = 30;
  ANSI_FORE_RED             = 31;
  ANSI_FORE_GREEN           = 32;
  ANSI_FORE_YELLOW          = 33;
  ANSI_FORE_BLUE            = 34;
  ANSI_FORE_MAGENTA         = 35;
  ANSI_FORE_CYAN            = 36;
  ANSI_FORE_WHITE           = 37;
  ANSI_FORE_RESET           = 39;
  ANSI_BACK_BLACK           = 40;
  ANSI_BACK_RED             = 41;
  ANSI_BACK_GREEN           = 42;
  ANSI_BACK_YELLOW          = 43;
  ANSI_BACK_BLUE            = 44;
  ANSI_BACK_MAGENTA         = 45;
  ANSI_BACK_CYAN            = 46;
  ANSI_BACK_WHITE           = 47;
  ANSI_BACK_RESET           = 49;
  ANSI_STYLE_BOLD           = 1;
  ANSI_STYLE_ITALIC         = 3;
  ANSI_STYLE_UNDERLINE      = 4;
  ANSI_STYLE_BLINK          = 5;
procedure PrintColor(codes: array of byte; str: ansistring);
var
  attrs: string;
  code: byte;
begin
  attrs := '';
  for code in codes do
    begin
      if attrs  '' then
        attrs += ';';
      attrs += IntToStr(code);
    end;
  writeln(#&033,'[',attrs,'m',str,#&033,'[',0,'m');
end;
// prints a blinking, bold red text on a white background
PrintColor([ANSI_BACK_WHITE, ANSI_FORE_RED, ANSI_STYLE_BLINK, ANSI_STYLE_BOLD], 'Hello World');

Regards,
Ryan Joseph

Personally I'd write the function as something like "function GenerateColorCode(codes: array of Byte): ansistring;", mostly in anticipation of pure functions, because then the compiler can just replace the call with the relevant string at compile time, but that's a long way off!

Gareth aka. Kit

But to go back to the point I originally raised, Kirinn raised a good point about those who have white rather than black backgrounds, or any colour so long as it's /not/ black! Yellow is very hard to see against a bright white backdrop, while red, medium/dark green and magenta can be seen on most backgrounds.  Plus GCC uses the same colours for warnings.

So, my complaint is dropped!

Gareth aka. Kit

On Nov 22, 2020, at 10:09 AM, J. Gareth Moreton via fpc-devel wrote: Personally I'd write the function as something like "function GenerateColorCode(codes: array of Byte): ansistring;", mostly in anticipation of pure functions, because then the compiler can just replace the call with the relevant string at compile time, but that's a long way off!

That would great. Hopefully this gets finished some day.

Regards,
Ryan Joseph

I'm getting there.  I keep getting distracted or lost though! Hardware failures don't help!

I'm trying a different approach this time and writing a whitepaper like I've done with my more major changes for Free Pascal, so I can describe its uses and how it works etc.  It can be updated of course, but it means I have something to refer to if I lose my way, and others can better add to the concept.

In the case of that PrintColor example, I don't think it could be inlined, for example, due to the call to IntToStr, among other things (like if you call PrintColor with a non-constant actual parameter), but if IntToStr were a pure function as well (and there's no reason why it can't), then logically GenerateColorCode could easily be pure.

I'm glad there's still interest in pure functions.  It may be a while though, and I'm being tempted with a bounty and Patreon pledges to implement "static single assignment" into the Free Pascal Compiler.  That will take some research to see if it's even possible and not prone to completely breaking things!

First things first though, I've got a bug to fix in AArch64, and on the same platform, I'm almost finshed implementing the optimisation that turns division by a constant into a multiplication and shift.

Gareth aka. Kit

I would probably do something like this:

const
ansi_colors: array[0..7] of char = ('0', '4', '2', '6', '1', '5', '3', '7');
procedure PrintColor(fg, bg: byte; s: string);
var
tmp: string;
begin
tmp:=#27+'[0;3'+ansi_colors[fg]+';4'+ansi_colors[bg]+'m'+s+#27+'[0m';
writeln(tmp);
end;
begin
PrintColor(2, 0, 'derp');
end.

Easy enough to remember pascal style color numbers.

Florian had already worked on SSA in the past. So maybe best ask him what he had done, what worked, what didn't and what is missing. (In a separate thread though)

Regards,
Sven

I ran the compiler on linux through a ssh session:

The colors display just fine, so I see no reason to disable on darwin except that the termio unit is not found...

Michael.

If Florian wants to provide some explanation as to where the colors were added I'll enable them on mac and test them myself.

Regards,
Ryan Joseph

I'd say thie first port of call is "compiler/comphook.pas", line 258:

procedure WriteColoredOutput(var t: Text;color: TOutputColor;const s :
AnsiString);

It looks like a simple "$if defined".

Gareth aka. Kit

Yes, and the more platforms are added, the more messy this unit gets. :-( I tried to clean it up a bit by moving the platform-specific parts to a new unit - see the attachment containing a diff for comphook.pas and the new unit. I didn't commit yet because I couldn't test it on the other platforms (my new implementation for OS/2 works OK ;-) ). If somebody tests is under Linux and WinXX, I'll committ it tomorrow.

Tomas

I'm doing some optimisation development for x86_64 currently, so I can give it a test run if you like - got the Raspberry Pi for arm-linux and aarch64-linux too, but it might take more then a day.  I'll let you know.

Gareth aka. Kit

Sorry for being a bit slow - I've been doing my own work on x86. I gave your patch (and new file) a test run on x86_64-win64, and that seems to work fine.  At least the warning messages in the packages appear magenta.  I'll give arm-linux a test next.

Gareth aka. Kit

J. Gareth Moreton wrote

Sorry for being a bit slow - I've been doing my own work on x86. I gave your patch (and new file) a test run on x86_64-win64, and that seems to work fine.  At least the warning messages in the packages appear magenta.  I'll give arm-linux a test next.

No problem, thanks for testing. Unfortunately, it doesn't work for me under Windows (Win 10 Pro 64-bit) either with the original version or with my modifications (i.e. hopefully unrelated to my changes). It could be some configuration of the used Windows installation, whatever, no idea. I'll probably commit my changes now hoping that I didn't break anything for anybody for whom it worked correctly previously. The GO32v2 version was not compilable in the sent version, fixed now and tested to work properly (apparently, coloured output using ANSI escape codes works more reliably with 16-bit MS-DOS/PC DOS/... than with 64-bit MS Windows 10 Pro ;-) ). And BTW, no, it doesn't work under DOSBox, because DOSBox supports ANSI escape codes out of the box without signalizing that such support is available in a way compatible to the real DOS. I could add a specific check for running under DOSBox if somebody wants it (it's just a few more lines of code, no difficulties).

Tomas

Hi!

25.11.2020 1:52, Tomas Hajny via fpc-devel:

Have you also checked with this registry trick for win10:

[HKEY_CURRENT_USER\Console]
"VirtualTerminalLevel"=dword:00000001

(As per https://superuser.com/a/1300251/109090)

HTH,

Regards,
Nikolai

Nikolai Zhubr wrote

25.11.2020 1:52, Tomas Hajny via fpc-devel:

Hi Nikolai,

.
.

If I read the article correctly, it says that an application may enable this processing explicitly using SetConsoleMode, or that it may be enabled for all applications / consoles using the mentioned registry key. The code added to the compiler contains the mentioned SetConsoleMode setting, thus it should be sufficient according to the article. However, the call fails (here) with error 87 (invalid parameter). And btw, changing the registry key doesn't help (i.e. I still get the same error). The same call (SetConsoleMode) performed without setting the respective flag (ENABLE_VIRTUAL_TERMINAL_PROCESSING) succeeds. I'm willing to have a look at additional hints, but I won't perform additional research myself for this.

For anybody interested, the following test program reproduces the functionality in the compiler (and provides debug information):

-----------------------------
{$MODE OBJFPC}
uses
  Windows;
const
   ENABLE_VIRTUAL_TERMINAL_PROCESSING = $0004;
   CachedIsATTY : Boolean = false;
   IsATTYValue : Boolean = false;
function IsATTY(var t : text) : Boolean;
   const dwMode: dword = 0;
   begin
     if not(CachedIsATTY) then
       begin
         IsATTYValue := false;
         if GetConsoleMode(TextRec(t).handle, dwMode) then
         begin
           WriteLn ('dwMode = ', dwMode);
           if not (SetConsoleMode(TextRec(t).handle, dwMode)) then
            WriteLn ('SCM0: ', GetLastError);
           dwMode := dwMode or ENABLE_VIRTUAL_TERMINAL_PROCESSING;
           if SetConsoleMode(TextRec(t).handle, dwMode) then
             IsATTYValue := true
           else
            WriteLn ('SCM: ', GetLastError);
         end
          else
           WriteLn ('GCM: ', GetLastError);
         CachedIsATTY:=true;
       end;
     Result:=IsATTYValue;
   end;
begin
  WriteLn (IsATTY (Output));
end.
======================================

I get the following result (regardless from the registry setting):

dwMode = 3
SCM: 87
FALSE

Tomas

Tomas Hajny via fpc-devel schrieb am Mi.,
25. Nov. 2020, 13:31:

How current is your Windows 10? VT100 support was added only two years ago or so.

Regards,
Sven

.
.

How current is your Windows 10? VT100 support was added only two years ago or so.

I have the machine since May and it gets regular fixes (it's managed by my employer). The most recent binaries in Windows\System32 are from September the 18th and the File Version and Product Version properties show 10.0.18362.1049 (and some other .1082). Maybe it's too recent? ;-) (Sorry, I couldn't resist, making jokes about MS approach to compatibility is way too easy. ;-) ) I don't care too much, I just wanted to make sure that the compiler colouring still works on Windows after my changes.

Tomas

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test dwMode = 3
TRUE

Microsoft Windows [Version 10.0.19041.630]

I just tested with a current revision and it still works correctly on Windows 10.

Regards,
Sven