[Haskell-cafe] Hot-Swap with Haskell
ekmett at gmail.com
Fri Jul 16 22:46:01 EDT 2010
You may find the following link useful, as it talks about much the same
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
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.
On Thu, Jul 15, 2010 at 11:05 PM, Andy Stewart <lazycat.manatee at 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"
> 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
> I wonder have a better way that hot-swapping new code without
> -- Andy
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe