lazycat,
You may find the following link useful, as it talks about much the same approach.
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
<lazycat.manatee@gmail.com> wrote:
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