> On Nov. 10, 2014, 7:50 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp, lines 27-29 > > <https://reviews.apache.org/r/27605/diff/1/?file=750087#file750087line27> > > > > What's the distinction between these three tests? Seems more like a > > test of implicit string conversion...?
Yes, and that it works in different argument positions. The behavior and how it happens changes with the switch to a variadic template, it is relatively simple to make the mixing case no longer work (or one of the pure cases). > On Nov. 10, 2014, 7:50 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp, line 30 > > <https://reviews.apache.org/r/27605/diff/1/?file=750087#file750087line30> > > > > Is there a configure check for initializer lists? Not yet. I can add one. (The GCC docs say they exist in GCC 4.4). Review request attached. Practically our whitelisting isn't sustainable because there are so many features in c++11/14. I'm aiming to get a bot per distribution/compiler Mesosphere and it's clients want supported. Then so long as you have a bot which checks your compilers. If we say "Bots must not break" and do a basic level of sanity check in the c++11 bits, life should be happy / people's workflows will work. > On Nov. 10, 2014, 7:50 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp, line 32 > > <https://reviews.apache.org/r/27605/diff/1/?file=750087#file750087line32> > > > > Does this make sense? If not, let's call that out here with a TODO! > > > > Interestingly, we differ from python's os.path.join here. To me no, but I believe this is the case that broke browse last time because the behavior changed. The files test extension: https://reviews.apache.org/r/27606/ points out more of the resulting weirdness from how we currently handle paths (And lack of normalization). > On Nov. 10, 2014, 7:50 p.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp, line 36 > > <https://reviews.apache.org/r/27605/diff/1/?file=750087#file750087line36> > > > > Interestingly: > > > > >>> os.path.join("/a", "/b", "/c") > > '/c' I think our behavior is more reasonable / what programmers and end users will expect with data passing through the function. The path dropping seems like odd behavior to me on the python side (Although it does seem to be consistent for them) - Cody ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27605/#review60651 ----------------------------------------------------------- On Nov. 13, 2014, 12:39 a.m., Cody Maloney wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27605/ > ----------------------------------------------------------- > > (Updated Nov. 13, 2014, 12:39 a.m.) > > > Review request for mesos and Ben Mahler. > > > Bugs: MESOS-1733 and mesos-1877 > https://issues.apache.org/jira/browse/MESOS-1733 > https://issues.apache.org/jira/browse/mesos-1877 > > > Repository: mesos-git > > > Description > ------- > > Add a unit test to stout path to increase confidence when changing the code. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/Makefile.am > 7aac3fdb864e838cdd4e0d817ed4dff14923c69d > 3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp > bc6920a24d920c809e36a2a3da1810e52d0db101 > 3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/27605/diff/ > > > Testing > ------- > > make distcheck on Ubuntu 14.04 > > NOTE: ReviewBot is going to be unhappy about this "crossing" stout and > libprocess... I'm not sure what the correct fix for reviewbot is in this > case, since the Makefile does really cross the project bounds... > > > Thanks, > > Cody Maloney > >
