Print::println() line-ending is inconsistent with Arduino core (a documented change)

[brucemack]

Thanks for an awesome library!

I'm noticing that the end-of-line convention in the Print class has been changed recently. The documentation in the release notes is clear and I realize that this is an expected change. However, it does break unit tests. I think the change could also break programs that parse the serial output of an Arduino program.

Isn't it desirable for the EpoxyDuino Print class be as similar to the "real" Print class as possible? Can you provide a bit of background on what the issue was that prompted change?

I'm trying to figure out how best to clean up breaking unit tests and knowing the full context of the change would be most helpful.

Thanks in advance!

[bxparks]

It's because I write a lot of EpoxyDuino programs that print to Serial, which is sent out to the stdout, which I redirect to a file, which is then processed by other scripts on Linux. The DOS encoding (\r\n) of Serial.println() does not mix well with the Unix convention using just using (\n), especially when combined with the Serial.printf() function. I end up with files containing mixed line encodings, which causes Linux to think that the file is a binary file, and things become ugly.

However, you make a good point that Serial.println() should emulate the real Print class. What I will do is to add a flag to my StdioSerial class in EpoxyDuino, which I can use to tell the Serial object to use Unix conventions for my programs.

I'm surprised that you were affected by this change. This project has only ~35 stars, hardly anyone uses it. :-)

[brucemack]

That's great, thanks for the info and thanks for suggesting a flag. That flag will save people a lot of hassle I suspect, particularly for those who are testing the output precisely. BTW, I'll bet there are a lot of people using your library since it speeds up the dev/test cycle considerably. People may not have upgraded to V1.1.0 just yet so the issue may not be widely noticed yet.

I'll keep an eye out for the update. Thanks again for your help. Bruce.

[bxparks]

Fixed by v1.2.0

[brucemack]

Looks great, many thanks for the quick fix. My tests are passing again. 👍

[philj404]

Brian,

FYI more people use EpoxyDuino than may actually realize it. For example I added a single automated unit testing example to contrem/arduino-timer, and the library owner took my example and ran with it. So -- indirectly -- they started taking advantage of your library.
In addition, anyone contributing to their library will get hints if their changes cause a regression... and then learn about unit tests.

[bxparks]

Interesting reference to contrem/arduino-timer. I find it interesting that the maintainer pinned EpoxyDuino and AUnit to specific commits:
https://github.com/contrem/arduino-timer/blob/master/extras/tests/Makefile#L5

I guess I understand that this give stability. On the other hand, that version is really old, before UnixHostDuino got renamed to EpoxyDuino. So I wouldn't want other people to copy that.