Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 21 of 21

Thread: My one great desire...

  1. #1

    My one great desire...

    This isn't actually such a world-shaking suggestion .... however

    What I would really like to see is the "errors" in the Teensyduino verbose output compile window being shown in a different color from the "warnings". IE, every one of my programs shows dozens if not 100s of the following totally useless warnings, and any actual errors are buried in the pile, and it takes endless amounts of wasted time to find them, starting with blowing the IDE up to fill the entire screen so you can even read the lines. Foo.
    Code:
    warning: deprecated conversion from string constant to 'char*'

  2. #2
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,250
    The better way is to fix the warnings...
    In general, warnings are not printed "just for fun".
    Last edited by Frank B; 02-10-2017 at 02:55 PM.

  3. #3
    Senior Member
    Join Date
    Nov 2012
    Posts
    830
    When faced with that, I copy the entire IDE output, paste it into a text editor and then search for the word "error".

    Pete

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,455
    Quote Originally Posted by oric_dan View Post
    What I would really like to see is the "errors" in the Teensyduino verbose output compile window being shown in a different color from the "warnings".
    The warnings are supposed to show as white text and the errors as red. Like this:

    Click image for larger version. 

Name:	sc2.png 
Views:	25 
Size:	32.3 KB 
ID:	9659

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,455
    Can you give me a screenshot of how the errors are warnings are actually appearing on your screen?

    Hopefully you could do this with a relatively small program you can post here, and tell me which operating system and software version, so I can try to reproduce the problem here.

    The really are supposed to print in different colors, exactly as you have wished. I would like to know why they're not.

  6. #6
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,990
    Quote Originally Posted by oric_dan View Post
    Code:
    warning: deprecated conversion from string constant to 'char*'
    You often get this type of message if your code has something like:
    Code:
    void myfunc(char *string_pointer) {
    ...
    }
    ...
       myfunc("ABCD");
    You can often get rid of the error if you change myfunc like:
    Code:
    void myfunc(const char *string_pointer) {
    ...
    }
    ...
       myfunc("ABCD");
    Which tells the system you are not going to try to change the string...

  7. #7
    Oh darn, this is kind of one of those "never mind" sort of things. I've been using the older Teensyduino install (v1.24 on IDE v1.0.6, left side of attachment) so much with my T3.1 modules that I hadn't noticed things had changed on the newer installs (v1.32a on IDE 1.6.13, right side of attachment). However, there are still some weird things.

    The attachment shows the same sketch compiled in each version of Teensyduino. I added some obvious warnings and errors. In the new version, the errors are indeed shown in a different color from the warnings, although the formatting uses a large amount of blank space. And now the warnings are the same color as the compile statements. Strange. I don't know if that's better or not.

    Also,
    You can often get rid of the error if you change myfunc like:
    Code:
    void myfunc(const char *string_pointer) {
    ...
    }
    ...
    myfunc("ABCD");
    Kurt was right about this. Cf lines 2 and 3 in the sketch, the deprecated char* warnings disappear on adding "const". Now to add this to 10,000 places in my programs :-).

    When faced with that, I copy the entire IDE output, paste it into a text editor and then search for the word "error".

    Pete
    Yeah, that's what I have been doing for ... many ... years.

    EDIT: using Win10 here.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	test1.jpg 
Views:	30 
Size:	113.9 KB 
ID:	9660  
    Last edited by oric_dan; 02-10-2017 at 07:18 PM.

  8. #8
    As Frank says the correct thing to do its correct the warnings... in code.
    I've been programming since 13 years old in assembler, C, C++, Pascal, Perl, Java, ASP, PHP, bash and so many languages I don't even remember (and I will like to be a 1/100 Paul).
    I have done alone projects of more than 40000 lines of code and didn't see 100 warnings more than a few times. And most of the times when you have that high warnings count usually involves a single mistake.
    Given the limited rom and ram space of Teensy compared with a regular PC, having that amount of non corrected warnings in a such small platform speaks really bad about your coding habits and standards.
    Do you have 10000 functions definitions in a sketch for a 256K MCU?.
    Are you sure you are not being a little bit hyperbolic speaking?

    Luis M.

  9. #9
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,250
    Yup, professional developers treat warnings as errors, and there's a compiler-switch to do this:

    -Werror

    That's a good practice.
    Warnings may lead to unexpected behavior.

  10. #10
    Frank and Stendall, you guys are both right. I normally go through and ultimately clean up my programs until all of the warnings have been taken care of, except for that deprecated char* warning, of which there may be 100s in my larger programs. But if I implement Kurt's fix, then that should go away too.

    But I'm not sure, if a usage has been deprecated, it seems to me that's a matter of "style", and a not possible compile error. But I'm probably wrong.

  11. #11
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    2,990
    In this case, I think it is a bit more than just style.

    It may be more also depending on how the compiler handles the string constants.

    That is in my case above:
    Code:
    void myfunc(char *string_pointer) {
    ...
    }
    ...
       myfunc("ABCD");
    if inside of myFunc I did something like:
    *string_pointer = 0;

    If the string constant is held in RAM than this will function, if it is held in Program space it will fault the processor... I think now it is kept in program space.

    The reason I knew about that warning was I was lazy for awhile and took my time fixing them.

    Now as a "Retired" professional programmer I can be lazy again

    Also sometimes I get lazy on how to remove warnings. Ones like, variable may be used before it is set (paraphrased), even though you know by the logic it can not happen.
    I get lazy and do something like uint8_t myvar=0;
    Which generates fatter code.

    I hate having to look for all of those ... Pragma or attribute statements. Like if you wish to pop something off of SPI stack, if you ignore the results compiler complain, likewise if you assign it to a variable that is not used it complains... So you look it up to find something like:
    uint32_t tmp __attribute__((unused)) = SPI0_DL;
    ...

  12. #12
    Seems to me there has always been a problem between declaring something as char *x and char x[] with the C language, so sometimes the programmer has to think about what he's doing, ha. Eg, in the following sketch, the compiler has caught the error at line 13, but it compiles fine if line 13 is commented out. OTOH, it seems to me that lines 19,21,23,25 will crash at run time. Deprecation, or no.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	test1a.jpg 
Views:	26 
Size:	129.5 KB 
ID:	9661  

  13. #13
    Programers always have to think about what they are doing xD

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,455
    Quote Originally Posted by oric_dan View Post
    The attachment shows the same sketch compiled in each version of Teensyduino. I added some obvious warnings and errors. In the new version, the errors are indeed shown in a different color from the warnings, although the formatting uses a large amount of blank space. And now the warnings are the same color as the compile statements. Strange. I don't know if that's better or not.
    The newer compiler versions print the actual line of source code after the error, then a line with a "^" which is meant to point to the exact location on the line where the error occurs, and then a blank line which is probably meant to help you visually see the "^". Maybe?

    I'm also not sure if it's better or not.

    In an ideal world (with a *lot* more hours in every day) I've considered trying to add GUI elements to Arduino's lower panel. Ideally this ascii art text from the compiler could be replaced with something much better with real graphics. All the extra info could be hidden under a little more/less button that expands the info and highlights the source line in Arduino's editor. Links to "help with this error" could open up (ideally) well written help for the most common causes and suggestions for troubleshooting errors and warnings, and in a really ideal situation such help could get some context cues from the source code to prioritize which help to show first.

    But for now, I'm working on EHCI USB, and then a long list of minor issues, and then probably some improvements to Wire, and Ethernet, and improving the website..... seems unlikely such work on the Arduino IDE will happen anytime soon, at least by my hand...


    Kurt was right about this. Cf lines 2 and 3 in the sketch, the deprecated char* warnings disappear on adding "const". Now to add this to 10,000 places in my programs :-).
    For this particular warning, you likely have 10,000 places that pass string constants to just a few functions defined with (non-const) char * inputs. Of course this is a guess without seeing your code, but there's a good chance adding const to a relatively small number of function inputs will make a huge number of "deprecated conversion from string constant" warnings disappear.
    Last edited by PaulStoffregen; 02-11-2017 at 01:11 AM.

  15. #15
    For this particular warning, you likely have 10,000 places that pass string constants to just a few functions defined with (non-const) char * inputs.
    Paul, you and Kurt may be right. Since Rduino IDE doesn't have a nice printf() type of function like normal C, I have been using 12-15 of my own specially-defined utility fcns in various forms that look as follows:
    Code:
    /* trivial printf for string/integer/string/integer display. 
    *  - usage:  print_sisi("...", -123, "...", 456);
    ************************************************************/
    void print_sisi( const char* s1, int num1, const char* s2, int num2 )
    {
       dbg.print(s1);  dbg.print(num1);
       dbg.print(s2);  dbg.print(num2); 
    }
    
    - earlier on, I have:
    #define dbg   Serial1
    So, I just changed all of the char* to const char* as shown above in this set of fcns, and it reduced the number of
    Code:
    rem.ino:582: warning: deprecated conversion from string constant to 'char*'
    warning statements in my most-used program from 271 down to 145. There are only 5 other warnings in the current program. So, if I keep hacking away it should reduce these a lot more.

    For reference, that program has 22 .ino and .h source files, and probably 150 pages of source code. The compile window dump has 418 lines, so reading through it looking for errors has been a PITN.

    For edification, when I mentioned 10,000 places, I was originally referring to my dozens and dozens and dozens of sketches. So, not quite pure hyperbole, :-).

  16. #16
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,250
    Quote Originally Posted by oric_dan View Post
    Since Rduino IDE doesn't have a nice printf() type of function like normal C
    Teensyduino has it

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,455
    Yup, with Teensy you can use Serial.printf("number = %d\n", num);

    The printf support is in the Print class inherited by almost all displays and other things that use print, so you can use it with those too.

  18. #18
    Quote Originally Posted by PaulStoffregen View Post
    Yup, with Teensy you can use Serial.printf("number = %d\n", num);

    The printf support is in the Print class inherited by almost all displays and other things that use print, so you can use it with those too.
    Aha, very nice. News to me. As long as you are updating pages, Paul, would be nice to add description of this feature. Eg,
    https://www.pjrc.com/teensy/td_serial.html
    https://www.pjrc.com/teensy/td_uart.html

  19. #19
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,250
    In fact, Teensyduino uses the NEWLIB (math functions)

  20. #20
    Wow. And some of us have long dreamed of having an atan(), LOL. I notice there is both
    - double atan(double x);
    - float atanf(float x);
    and I assume the 2nd makes use of the T3.6 FPU, maybe?

    Would be nice to have a summary page on pjrc.com that lists all of the really cool advanced features that Teensyduino has, and not found in the usual Arduino distos.

  21. #21
    Senior Member Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    4,250
    If the FPU supports atanf somehow yes, then it makes use of it. I don't know! - maybe run a benchmark or take a look at the assembler-output ?
    But i guess, the answer is "yes"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •