Thanks for comments!

...

1) daemon some time allow -F/--foreground options to disallow fork() , how to achieve that in boostapp ?

We have no way to do this, in server application type, but you can have, both types, and choose what execute, e.g.: http://www.dokfile.com/appbeta3/docs/libs/application/example/multi_applicat ion.cpp

...

2) is setup() guaranteed to be called? I think installed win32 service will not have any chance to run setup()

If you define setup handler on functor class, setup() always will be called.

...

3) even setup() return 1, the main functor is called anyway, under Linux. is that intentional or just a bug?

It's a bug, thank you for find it, I'll fix Thanks

Hi all,

The docs and lib are updated!

Please, send your comments.

http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.h tml

looks good. used that for a while. just some comments: 1) daemon some time allow -F/--foreground options to disallow fork() , how to achieve that in boostapp ? 2) is setup() guaranteed to be called? I think installed win32 service will not have any chance to run setup() 3) even setup() return 1, the main functor is called anyway, under Linux. is that intentional or just a bug?

PS: I want to take and ask for help, if any native english speaker can help me with the documentation! Please, contact: re.tf <at> acm.org

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

That looks very interesting, but I have a couple of questions: Why did you not make the app framework a base class that is extended by the application? It seems to me that would allow you to enforce the API (by making the application entry point pure virtual), make passing in the parameters and control easier (make them members of the base class), and potentially handle main() (base class has a list of applications to run, application ctor registers in list, application is a static instance). Also, it would be nice to have a getops style arg parser function, so that you could help automate getting args and generating help messages for command line apps.

Like other things, I let this as user option, but, thinking better of this! I can provide some engine that handle threads for client, as separated class that user can plug on operator functor, I don’t know! I need think more about this! I think that this feature need be separated of application, (like sahred_library plugin class). I can’t assume what type of parallelism the user want! For sample I use Boost.MPI with Boost.Application to do distributed memory parallel processing! Thanks for idea! -----Mensagem original----- De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de Arpan Sen Enviada em: sábado, 21 de setembro de 2013 02:36 Para: boost@lists.boost.org Assunto: Re: [boost] Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a_release_2 This certainly looks good to me, what I think is needed is some additional work on configurable thread support as part of the application/threadpool. On Sat, Sep 21, 2013 at 12:49 AM, Renato Forti wrote:

Hi all,

The docs and lib are updated!

Please, send your comments.

http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.h tml

PS: I want to take and ask for help, if any native english speaker can help me with the documentation! Please, contact: re.tf <at> acm.org

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Regards, Arpan ---------------------------------------------------------------------------- ------------------------------------- Reality is merely an illusion, albeit a very persistent one. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Dib, Thanks for your comments! I am very happy that you think that this library can be useful! About your comments:

...

- let the user set callbacks for more signals (eg. SIGHUP is often used). Maybe you can use asio's signals here for better portability?

I agree, and I will take a look in how to extend handlers types of application class! All other mentioned features, I think that are very important, but, I think that can be done, in future releases! The problem is that now I don't have time to do this now.

...

I would probably have started something like this in the near future, but not with "boost-compliant quality", so I'm quite happy about your effort :)

Well, I will ask to you! Do you have any free time to contribute with some of those mentioned features? :)

...

Do you have a development-code repository somewhere or just the archives you linked to?

I don't have any repository, because, this lib is only one idea that I sent to boost group to see interest! And for my surprise, several people are interested! :)

...

What is your roadmap for further development and/or acceptance into boost?

Well, I have no idea! Depends on what the community request! My development time is limited, so at some point I have to close the scope and try to submit! The documentation need a lot of work too! I am not a Native English Speaker! I do not know exactly, I never submitted anything to boost before. I do not know how it will be! Do you have some experience in this submission process? Thanks a lot -----Mensagem original----- De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de dib Enviada em: segunda-feira, 23 de setembro de 2013 05:04 Para: boost-devel-archive@googlegroups.com Cc: boost@lists.boost.org Assunto: Re: [boost] Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a_release_2 Hi, I think this is very useful and am looking forward to seeing this as an official boost lib. There are a couple of features that come to mind when I think about using this, which are: - let the user set callbacks for more signals (eg. SIGHUP is often used). Maybe you can use asio's signals here for better portability? - integrate boost.programoptions a little more. I think about reading a config file and maintaining some "config-state" inside application.ctrl? Then, if I change some config values they get written back to the config file.. - for the above feature it might be useful to introduce an "initalisation-handler", so the user can separate the code for eg. setting up program options and the actual program logic - option to turn on some "general exception handling" - _optional_ incorporation of boost.log - offering a threadpool or sth (or even asio?) I think this was already mentioned I would probably have started something like this in the near future, but not with "boost-compliant quality", so I'm quite happy about your effort :) Do you have a development-code repository somewhere or just the archives you linked to? What is your roadmap for further development and/or acceptance into boost? -- regards dib _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost