Page 1 of 1

[Solved] Newlines and logging output with printf ...

Posted: Thu Oct 13, 2016 12:44 am
by kolban
In an attempt to debug some code, I was getting the strangest results in my console output after switching on some debug in a 3rd party library. I couldn't for the life of me figure out what was going on. About an hour later I had a theory and said "No ... that can't be right!" ... so I ran a test. I compiled a C program that contained:

Code: Select all

printf("This is line1\nThis is line2\n");
when run, what would you expect the result to be. What I was expecting was:

Code: Select all

... stuff before ...
This is line1
This is line2
... stuff after ...
what I found was:

Code: Select all

... stuff before ...
This is line 1
... stuff after ...
oh my!!! ... it seems we are loosing the content (silently) after the first newline in output.

Is this expected behavior?

Re: Newlines and logging output with printf ...

Posted: Thu Oct 13, 2016 1:27 am
by ESP_Sprite
it's a known bug for which we pushed a fix yesterday. Can you update your esp-idf and try again?

Re: Newlines and logging output with printf ...

Posted: Thu Oct 13, 2016 1:39 am
by kolban
Thank you sir, I refreshed ESP-IDF and now the problem has gone away and results are as desired. A follow on question if I may. I try and watch the espressif/idf repository looking for new commits as my signal to refresh my ESP-IDF download. If I look at the list of commits, I don't see any earlier than a week ago ... see:

https://github.com/espressif/esp-idf/commits/master

This seems to tell me that the git clone I am performing is pulling in things from elsewhere. I have very poor skills in git, do you know where I should have looked to determine that there had been changes in ESP-IDF that may have prompted me to refresh?

Re: Newlines and logging output with printf ...

Posted: Thu Oct 13, 2016 1:54 am
by ESP_Angus
The catch is that the timestamps shown there are when the git commit was done locally, rather than when it got pushed to github.

So, in this case the fix was commit aae3e8 which I made locally (on my development computer) on October 6. So that's the timestamp on the commit. Then I pushed that commit to our internal git server, the change went through code review to be merged to "master" (which happened in commit 12caaed), then through our integration tests and then got pushed out to github.

But the timestamp remains the time I made the original change. It normally doesn't take a week for this kind of bugfix to deploy, we're still ironing out some of the kinks in our automatic integration test & deployment process. But it will usually take at least a few days between "developer creates commit" and "commit pushed to github".

So, from your point of view, I'm not sure what the easiest way to find out "are there new commits?" is apart from running "git pull" in your local directory and seeing what happens. If you "Watch" the esp-idf repository on github then you might see "@igrr pushed X commits to esp-idf"[*] in your personal activity feed at https://github.com/ (although I just looked and I don't see this, so maybe not...)

Possibly someone else with more deep github knowledge will know another way to watch for "pushes" of this kind.

[*] The deployment process runs with a special deployment key that github associates with Ivan's account, so the "deploy" pushes show as being done by his username.

EDIT: clarified deployment process.

Re: [Solved] Newlines and logging output with printf ...

Posted: Thu Oct 13, 2016 4:06 pm
by kolban
Reviewing the commits made to the latest Github I found an issue raised by Mr jmattsson that was a direct report of the issues listed in this forum post. Had I spent the time studying the Github known issues I would not have needed to spend my own time recreating this problem. The mistake was completely mine and the Github report is exceptionally good and well written.

https://github.com/espressif/esp-idf/issues/44

I post this as a note to self and a consideration for our community that when we find things that are not working as we would like, it does no harm to become conversant with the known issues in the software. Thanks to mr jmattsson and mr projectgus for their write ups in the Github issue.