Robotics Service Bus

Ok, now that it is clear that the parsing in RSC is not the cause for this, we need to find a different reason.

Robert, where exactly did you place the config file, how did you launch the programs and what was the error message you received?

I placed rsb.conf in my user directory as C:/Dokumente und Einstellungen/rabel/.config/rsb.conf (This should be %HOMEDRIVE%/%HOMEPATH%/.config/rsb.conf IIRC; had to look in the RSC source code for that one, too).

The spaces did not seem to cause any problems, as I saw that my program actually read the file completely (i.e. all bytes of it, whereas it aborted the read when the file was not present) using ProcessMonitor.

I launched rsb_informer and rsb_listener from the command line, there were no errors whatsoever. Do your questions suggest you cannot reproduce or you cannot find where the line ends are treated OS-specific? Because I'm pretty sure the problem is

277      boost::filesystem::ifstream stream(path);

in ParticipantConfig.hpp. Supposedly, this will use the default openmode, which is text-mode, which will use OS-specific line endings. However, this begs the question why RSB doesn't choke on one big line of text it cannot parse...

Further suggestion: Please to run RSC's unit tests and check whether the ConfigFileSourceEncodingTest succeeds (see description in previous comment).

Also: which Windows version and compiler did you use?

Does converting the newline encoding in the rsb.conf to windows-eols fix the problem or does it occur for any eol-style?

I think there are two errors in the LastTest_Macintosh.log file:

First:

CMake Error: The source directory "c:/Users/languitar/workspace/RSC/build/Doxyfile" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.

Second:

[ RUN      ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/0
1325784828812 rsc.config.ConfigFileSource [TRACE]: Option #(global) -> <int>5
string = string
[section1]
option = <double>1.5
unknown file: error: C++ exception with description "bad lexical cast: source type value could not be interpreted as target" thrown in the test body.
[  FAILED  ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/0, where GetParam() = "smoke-unix.conf" (0 ms)

Jan Moringen wrote:

I think there are two errors in the LastTest_Macintosh.log file:

First:
[...]
Not sure where this comes from.

This shouldn't be a problem.

Second:
[...]
This could be related to line endings.

That is probably the problem. However, I strongly vote against support the old mac line endings. No current system uses them anymore and treating them is cumbersome because there seems to be no library for this purpose and we would have to implement this manually.

Would it be ok to ignore this case?

Johannes Wienke wrote:

That is probably the problem. However, I strongly vote against support the old mac line endings. No current system uses them anymore and treating them is cumbersome because there seems to be no library for this purpose and we would have to implement this manually.

Would it be ok to ignore this case?

If I may add my 2￠ to this:

• This EOL limitation should be mentioned explicitly in the configuration documentation.
  • I had originally thought that config files from two supported platforms were not interchangeable, which is why I raised the bug in the first place
• I still do not understand how the parser can actually not raise an error once it encounters this very long line of text of virtually no impact to it. This might actually be another bug, or maybe parsing errors are ignored. I would expect an error message to the user if the configuration file a) did exist, but b) could not be parsed. This doesn't seem to happen.

[----------] 2 tests from ValidFiles/ConfigFileSourceEncodingTest
[ RUN      ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/0
unknown file: error: C++ exception with description "Old Mac EOL style '\r' is not supported." thrown in the test body.
[  FAILED  ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/0, where GetParam() = "smoke-unix.conf" (0 ms)
[ RUN      ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/1
1326821745343 rsc.config.ConfigFileSource [TRACE]: Option #(global) -> <int>5
1326821745343 rsc.config.ConfigFileSource [TRACE]: Option #(string) -> string
1326821745343 rsc.config.ConfigFileSource [TRACE]: Option #(section1, option) -> <double>1.5
[       OK ] ValidFiles/ConfigFileSourceEncodingTest.testSmoke/1 (0 ms)
[----------] 2 tests from ValidFiles/ConfigFileSourceEncodingTest (0 ms total)

Seems to be expected. However, the whole test suite is now marked as failing, which would mean RSC behaves incorrectly. I think it should actually behave like DebugToolsTest.testExceptionInfo, i. e. only pass when the exception occurs and not pass if it doesn't and not the other way around. So the test suite should pass when the exception is thrown and fail if it isn't, like so:

[----------] 3 tests from DebugToolsTest
[ RUN      ] DebugToolsTest.testNewInstance
[       OK ] DebugToolsTest.testNewInstance (0 ms)
[ RUN      ] DebugToolsTest.testCreateBacktrace
[       OK ] DebugToolsTest.testCreateBacktrace (0 ms)
[ RUN      ] DebugToolsTest.testExceptionInfo
Exception of type: class std::invalid_argument
Backtrace:
[       OK ] DebugToolsTest.testExceptionInfo (47 ms)
[----------] 3 tests from DebugToolsTest (47 ms total)

This is weird. Did you really update to latest trunk?

Because on our CI server no job shows this behavior:
https://ci.cor-lab.de/view/RSC/job/rsc-trunk/
https://ci.cor-lab.de/view/RSC/job/rsc-trunk-windows/

Also, the respective test code in trunk is:

TEST(ConfigFileSourceTest, testEolError) {
    CollectingHandler handler;
    ifstream stream(str(format("%1%/smoke-mac.conf") % TEST_ROOT).c_str());
    ConfigFileSource source(stream);
    EXPECT_THROW(source.provideOptions(handler), invalid_argument);
}

Johannes Wienke wrote:

This is weird. Did you really update to latest trunk?

I'm quite positive on that one... I just redownloaded trunk and svn says I'm at revision 463. It works now. But I'm sure it said the same thing when I tested it... So anyway, it seems to work now :?

Also, the doxygen issue with your profile path is still in there...

[----------] 1 test from WindowsSubprocessTest
[ RUN      ] WindowsSubprocessTest.testSubprocess
CMake Error: The source directory "c:/Users/languitar/workspace/RSC/build/Doxyfile" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
[       OK ] WindowsSubprocessTest.testSubprocess (5219 ms)
[----------] 1 test from WindowsSubprocessTest (5219 ms total)

For doxygen please open a new bug in RSC. However, it's only a minor warning. so low priority should be ok.

Can we close this one now?

Yep, this one is resolved for me. Thanks.