fema-team team mailing list archive

[Themiya Jayasinghe <themiya.jayasinghe@xxxxxxxxx>]

>
>
> There's two ways DefaultOptions could decorate Options…
>
> 1) Storing the Options class as a (protected) member variable of
> DefaultOptions and accessing the required option e.g. Options.getType(name,
> default) on demand e.g. DefaultOptions.getMaxIterationCount()
>
> OR
>
> 2) In the DefaultOptions constructor pulling the options out of the Options
> class and setting local member variables e.g.
> DefaultOptions._maxIterationCount - this way is probably better for the
> performance of our algorithms if DefaultOptions.getMaxIterationCount() is
> going to be frequently throughout the algorithm
>

I think we should go with 2). If we also add the protected Options member
then you can have multiple decorators to support the heirarchies as needed.
(See the WindowDecorator example on
wikipedia<http://en.wikipedia.org/wiki/Decorator_pattern#First_Example_.28window.2Fscrolling_scenario.29>
).


> We need to get a list of things we have left to do and priorities so we can
> divvy the project up and get people working on stuff now. Since the Client
> is effectively working and you know the Server side of things better than
> anyone else can you start working on it ASAP (getting options sent to the
> algorithm to use multiple LS strategies etc isn't so important as getting
> the work generator creating islands and work units at this moment!). I'd
> like to do any further changes on the Client so you can focus on starting
> the Server. Is that OK? I'm happy to take on board whatever constness, RAII
> or other refactorings you were hoping to get done.
>
>
I'm just going to finish off adding interfaces for the NeighbourhoodFunction
and LocalSearchStrategy for the client side and then add some documentation
to the QAP/WuJI related stuff. Tomorrow, I'll start writing a prototype work
generator and an assmilator for the island model. Then we can refactor it to
create the fema-server.

I've already written a basic BOINC client app (see
source/apps/soo/qap/main.cpp) with support for BOINC VFS, etc. If you could
extract the boinc related stuff from that and put it in to a
fema::BoincApplication class or a header then everyone else will be able to
reuse that code for creating the BOINC client. (I'm not too sure about
 linking the boinc stuff to the fema static library though. Maybe we should
get bjam to build that class seperately)

Also. if you chance upon a class without a virtual destructors consider
adding one. (Valgrind is still complaining about memory leaks).

Thanks.

Regards,
-jt