[mlpack-git] [mlpack] moving cliDeleter instance to log.cpp (#524)

[Joseph Mariadassou]

Let me paraphrase what I understood:
----------------------------------------------------
In singleton.cpp you are going to declare
Log Log::info
CLI CLI::singleton
ProgramDoc ProgramDoc::singleton

Then the PROGRAM_INFO macro would  refer to ProgramDoc::singleton directly
or indirectly.
-------------------------------------------------

There is no guarantee that ProgramDoc::singleton would have been created
before the macro which must represent an object is created. Why can't we
just move PROGRAM_INFO et al. inside main. Then we can make sure that
CLI::singleton is created after Log::Info and ilk. I am not sure of the
ramifications though.

I came into CLI_Deleter because I wanted to build a mlpack.lib-free
executable. I removed `#include "cli.hpp"` from core.hpp and managed to run
a simple CNN trainer (basically the mnist test)  on Raspberry Pi without
compiling the mlpack library. I just added log and prefixedoutstream cpp
files.

My suggestion is to move CLI away from core and include it explicitly in
all the applications. This will help better adoption of mlpack.






On Fri, Feb 26, 2016 at 12:40 PM, Ryan Curtin <notifications at github.com>
wrote:

> There is... one other possibility. This could be appealing if the idea of
> getting all of the classes associated with CLI or mlpack inside of
> libmlpack.so, and it's also appealing from a code size reduction
> standpoint. (I think this also means that if you just #include
> <mlpack/core.hpp> without using anything in it, you don't need to link
> against -lmlpack.)
>
> The idea is to make ProgramDoc a singleton of its own, then make the
> PROGRAM_INFO() macro a call to access the ProgramDoc singleton and set its
> parameters. The ProgramDoc singleton can then be put into some file like
> src/mlpack/core/util/singletons.cpp which can also contain the CLI and
> Log objects (technically the Log objects aren't singletons, they're global
> variables, but hey, I couldn't think of a better name for it...). Then we
> can control the order of construction (and thus destruction) and can
> eliminate the need for CLIDeleter entirely.
>
> What do you think? Maybe there is something I have overlooked?
>
> Thanks for looking into this, by the way. The CLI module hasn't gotten
> much attention since it was written in 2011. :)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/mlpack/mlpack/pull/524#issuecomment-189073562>.
>



-- 
Joseph Chakravarti Mariadassou
http://thesundayprogrammer.com


---
Reply to this email directly or view it on GitHub:
https://github.com/mlpack/mlpack/pull/524#issuecomment-189141898
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/mlpack-git/attachments/20160225/594be90c/attachment.html>