----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11331/#review21540 -----------------------------------------------------------
third_party/libprocess/third_party/stout/include/stout/duration.hpp <https://reviews.apache.org/r/11331/#comment44582> This is where the boot tuple is used. I can change the ValueUnit tuple to a struct. I can add more documentation to the logic: basically set up a bunch of buckets of Duration values and see where the parameter duration falls into. We do this because we try to see whether using a lower unit helps readability of the output. So Days(10) won't be output as "1.42857142857143weeks" but "10days" Alternatively I could write the buckets as "if" branches and use modulo to determine whether we get a whole number but then I have to have a code branch per unit for all the units from NANOSECONDS to WEEKS, which doesn't look very elegant to me. Thoughts? - Jiang Yan Xu On May 22, 2013, 7:08 p.m., Jiang Yan Xu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11331/ > ----------------------------------------------------------- > > (Updated May 22, 2013, 7:08 p.m.) > > > Review request for mesos, Benjamin Hindman and Vinod Kone. > > > Description > ------- > > - Currently when the result isn't a whole number, we go one-level down in > terms of the unit of time and see if we can get a whole number there. If so, > use the lower unit; if not, use the higher unit. > > > This addresses bug MESOS-477. > https://issues.apache.org/jira/browse/MESOS-477 > > > Diffs > ----- > > third_party/libprocess/third_party/stout/include/stout/duration.hpp > c943ab196871cf4c55f2a2dce5ef85ffe3a22577 > third_party/libprocess/third_party/stout/tests/duration_tests.cpp > 421615aa510f540ccfc0413d3252bbdedd70f7da > > Diff: https://reviews.apache.org/r/11331/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Jiang Yan Xu > >
