On Fri, Mar 28, 2014 at 2:21 AM, Jason H <scorp...@yahoo.com> wrote:
> While existing maintenance is probably done best as you described, I'm still > looking for an easier way to iteratively develop "pages" (for lack of a > better term). My idea is currently that upon saving a C/Cpp file, the binary > should rebuild the object file and unload/insert itself into the server. I > don't know if it is possible to have each object file do that automatically. > But with a fast enough system I should be able to hit "save" and by the time > I hit reload in the browser the new code (object or whole new binary) should > be up and running. However, in my tests with my core i5, when also debugging > I sometimes beat it. > > So I think that would be cool. Integrate a file system watcher with make. IMHO you don't really need to integrate an fs watcher with make, you can do that by yourself in your app by using a plugin-like structure: 1. Implement your actual application as a shared library 2. Implement a dummy application which loads that shared library 3. Now enhance the dummy application: - Store the of the timestamp of the shared library and dlopen it - Next time you spawn a session (F5 in your browser), you check the timestamp of the file on disk and the timestamp on memory. If disk is more recent, dlclose. Main problem with that approach (which I have not tested) is dlclose may not unload the library if the existing sessions cause the reference count to stay at > 0. But you can solve that by using Wim's approach of different prefixes: automatically change the prefix for either the old sessions, or the new sessions. You may end up with a lot of different prefixes if you use that in production in a busy site, though. One problem I don't know how to solve would be doing all of the above, while moving to a newer version of Wt. The fact that every new version of Wt breaks ABI doesn't exactly help. You'd need to use some kind of IPC mechanism then. But that's probably way too complex for our usual use case. -- Pau Garcia i Quiles http://www.elpauer.orgu could (Due to my workload, I may need 10 days to answer)
------------------------------------------------------------------------------
_______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
