> On June 15, 2015, 11:48 p.m., Niklas Nielsen wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp, lines > > 484-490 > > <https://reviews.apache.org/r/34943/diff/4/?file=984516#file984516line484> > > > > I am a bit torn whether we should copy this block so many places (taken > > the number of times it needs to get updates/kept in sync). > > > > Should we reference the first block from the other places?
I referenced the other ones, thanks for the suggestion. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34943/#review87996 ----------------------------------------------------------- On June 15, 2015, 5:52 p.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34943/ > ----------------------------------------------------------- > > (Updated June 15, 2015, 5:52 p.m.) > > > Review request for mesos and Niklas Nielsen. > > > Repository: mesos > > > Description > ------- > > Also refactored existing 'lambda::bind' arguments to use C++11 lambdas, > enabling us to get rid of our "loader" and "stringifier" functors. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/Makefile.am > 6ac2f04a6a1d8db1725972a3b4b46a0dd734566f > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flag.hpp > 87606d860dea3235ec70d127d3379065d42dc90b > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp > ee855da6128c2d671eb2fc7eaa2c0aab2341aebb > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/loader.hpp > 51d3ab020bd2bae1f12b66cac0da5383c813d5d7 > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/stringifier.hpp > fda5ae1328a23a4371475652f921341dce7448d5 > 3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp > 80450185f60c5b273face490e0bb9e695b0cb984 > > Diff: https://reviews.apache.org/r/34943/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
