lazycat,
You may find the following link useful, as it talks about much the same
approach.
http://nathanwiegand.com/wp/2010/02/hot-swapping-binaries/
Sadly, any hot-swap mechanism is going to suffer from the potential loss of
state where that state is not controlled by your code.
When that loss of state isn't acceptable you have a few mechanisms
available.
By far the easiest, I think, in the gtk2hs scenario you mention is that you
could refactor all of the code that interoperated with gtk2hs into another
process and spawn it, communicating with it over a pipe or other
communication mechanism. That way hot-swapping the current process would
leave your GUI (and the pipe/IPC mechanism) intact.
You may then need to pass along whatever changes affect the gui over the
pipe in a fairly manual fashion.
-Edward Kmett
On Thu, Jul 15, 2010 at 11:05 PM, Andy Stewart
Hi all,
I'm research to build a hot-swap Haskell program to developing itself in Runtime, like Emacs.
Essentially, Yi/Xmonad/dyre solution is "replace currently executing" technology:
re-compile new code with new binary entry
when re-compile success $ do save state before re-launch new entry replace current entry with new binary entry (executeFile) store state after re-launch new entry
There are some problems with re-compile solution:
1) You can't save *all* state with some FFI code, such as gtk2hs, you can't save state of GTK+ widget. You will lost some state after re-launch new entry.
2) Sometimes re-execute is un-acceptable, example, you running some command in temrinal before you re-compile, you need re-execute command to restore state after re-launch, in this situation re-execute command is un-acceptable.
I wonder have a better way that hot-swapping new code without re-compile/reboot.
Thanks,
-- Andy
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe