> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, line 187
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line187>
> >
> >     1) Let's sync with BenH if we want to factor out logging like this. 
> > There are arguments on both sides, so let's follow up with a discussion, 
> > and maybe add it to the style guide!
> >     2) *If* we *do* decide to factor out the logging like this, let's 
> > change the name to be more meaninful, or even move this function into 
> > `updateFrameworkInfo` as a lambda. This message is clearly specific to that 
> > function, and is not usable by other functions in `Framework`.
> >     3) Since we're in the implementation file, we can do `using 
> > std::string` and remove the namespacing of `std::string` here.

I actually wasn't quite sure myself (and the more I think about this, the less 
I like my own choice): this is just a helper function, to avoid violating the 
DRY Principle.
I would like to move it out of the Framework class, and just leave it the cpp 
file as a local (static) helper method.
Again, to me, it scratches the itch of copy & pasted code, which I positively 
dislike.

If I change it to a local helper method, would that address your concerns?


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 185-186
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line185>
> >
> >     Can you find other places in the code where the TODOs are aligned like 
> > this?
> >     It's definitely neat, but it seems to be different from other places.

I actually did ask Nik - and he suggested this.
I'll check out other TODO's in the code base


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 101-102
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line101>
> >
> >     The style is either:
> >     Follow the alignment if you stay on the 1st line:
> >     ```
> >     bool Framework::hasExecutor(const SlaveID& slaveId,
> >                                 const ExecutorID& executorId)
> >     ```
> >     or
> >     Indent by 4 if you start the parameter list on a new line:
> >     ```
> >     bool Framework::hasExecutor(
> >         const SlaveID& slaveId,
> >         const ExecutorID& executorId)
> >     ```
> >     
> >     Here and the others below please!

ummm...
// 2: Don't use.
allocator->resourcesRecovered(frameworkId, slaveId,
                              resources, filters);

but I agree I had misread (4):

// 4: OK.
allocator->resourcesRecovered(
    frameworkId,
    slaveId,
    resources,
    filters);

will change


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, line 60
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line60>
> >
> >     This is not your fault:
> >     there was a patch that got committed that changes `memory::shared_ptr` 
> > to `std::shared_ptr`. Can you make sure that when this gets rebased that we 
> > get rid of any reference to `memory:shared_ptr`? Thanks!

absolutely, will do.


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 40-43
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line40>
> >
> >     I think having this comment here (together with the implementation) is 
> > good. Can we remove it from the header so we don't have it duplicated?

yep - sorry.
I'm usually careful about that...


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33376/#review82004
-----------------------------------------------------------


On April 22, 2015, 8:35 p.m., Marco Massenzio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33376/
> -----------------------------------------------------------
> 
> (Updated April 22, 2015, 8:35 p.m.)
> 
> 
> Review request for mesos and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-2633
>     https://issues.apache.org/jira/browse/MESOS-2633
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Created new file framework.cpp containing all the methods' implementations 
> for the `Framework` class (declared in master/master.hpp)
> 
> Declared `operator ==` for Task in type_utils.hpp 
> (it was implemented before, but not declared in the header file);
> 
> Refactored all the LOG(WARNING) to a single utility method.
> 
> 
> Diffs
> -----
> 
>   include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
>   src/Makefile.am 93c7c8a807a33ab639be6289535bbd32022aa85b 
>   src/master/framework.cpp PRE-CREATION 
>   src/master/master.hpp 550d2c50cd01aa5830a7e7e03ab4a0240c221b15 
> 
> Diff: https://reviews.apache.org/r/33376/diff/
> 
> 
> Testing
> -------
> 
> All tests (make check) pass.
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>

Reply via email to