Author Topic: possible to show color message from compiler log message(ansi escape code)  (Read 5633 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5377
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Hi, I see a post:

Scintilla / Bugs / #2161 Ansi color codes support

I see that scintilla is already support such feature in year 2016, so maybe we can enable this feature(by parsing the ANSI escape code) in our C::B's compiler log message?

Any ideas?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2313
Wow! What a great idea. I've always wished for colors in the log.
Especially in the DebugLog() function. Green for ok; yellow for info; red for errors.

But for now, I'm swamped supporting TokenTree for LSP responses.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Avan

  • Multiple posting newcomer
  • *
  • Posts: 24
It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...

Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5377
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
It would be a way better if someone spends some time to find out why builds with many warnings are so massively slower than a builds without warnings...

Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.

If the slow down is from the C::B side, how can we check it. Disable or Enable the reg expressing parser inside the compiler plugin?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Avan

  • Multiple posting newcomer
  • *
  • Posts: 24
Can't the process be run from the command line, without CB in memory?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Wouldn't solving these warnings not do that? Compilers need time to figure these things out, just like us. In my experience dangling warnings are some day going to bite you and they obscure new and really important ones.
The speed C::B displays warnings shouldn't be a motivator to solve them.
C::B should not be slow displaying warnings. This has nothing to do with the compiler getting slower if there are many warnings, it is just C::B getting slower processing them.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Avan

  • Multiple posting newcomer
  • *
  • Posts: 24
Would it then not help if C::B was slowed down even more? ;o)

I still think that suppressing and/or ignoring boatloads of warnings is not the way to develop software. If done wright the bottom line should/could read 0 error and 0 warnings.