hub.darcs.net :: stepcut -> happstack -> changes happstack-plugins/Happstack

When two source files are modified almost simultaneously (as a result of a cp or a darcs pull command, for instance) the previous behavior was to compile the plugin twice, that is once for each file modification event.

This patch delays recompilation a few milliseconds after a file modification event is received. Thus, if several files are modified close enough in time, recompilation is delayed until the modifications have settled for a given timeout period.

When recompilation is in progress and modification events arrive, recompilation is attempted once more after the current recompilation finishes.

This translates with a change in the signature of funcTH' from funcTH :: PluginHandle -> Name -> IO (Either Errors a) to funcTH' :: PluginHandle -> Name -> [String] -> IO (Errors,Maybe a)

where the value a is always returned even in the presence of errors. The only case in which Nothing is returned is when the module has not been loaded yet.

Now the modules Happstack.Plugins.Plugins and Happstack.Server.Plugins/Dynamic export apostrophe-suffixed versions of their functions which take an additional [String] parameter with arguments for ghc.

This may be useful for people interested in implementing the file system event functionality somehow different than using inotify.

The following code

> do addSymbol ph fp sym > rebuild ph fp True

was problematic when an exception were thrown during the evaluation of the second line. The internal state would reference a symbol which would be never loaded.

For this reason, the code was modified to:

> bracketOnError > (addSymbol ph fp sym) > (const$ deleteSymbol ph fp sym) > (const$ rebuild ph fp True)

which after executed, it either leaves a loaded symbol in the internal state, or does not leave the symbol if the attempt to load it was interrupted by an exception.

The path for a hierarchical module A/B/C.hs was given to inotify as A.B.C.hs This patch has inotify receive the path A/B/C.hs

Also, on some kernels inotify would reject observing the empty path "", so this patch makes sure to pass inotify the path "." whenever "" is found.

A previous patch whose description is copied below had a fatal mistake in inotify event handling. When attempting to register handlers for two files in the same folder, two event handlers were registered on the same folder.

Due to System.INotify.addWatch semantics, the first registered handler would be discarded and only the later handler would be called.

The new fix creates a layer on top of inotify, so files are watched by observing the folder which contains them. But this time, we register at most one handler for each folder, and that handler is in charge of dispatching the events of all observed files in the folder.

> Mon Jul 18 14:57:35 UYT 2011 facundominguez@gmail.com > > * Has inotify observe the folder containing a file, rather than the file > itself. Otherwise inotify would stop listening at the file when editing it > with vim. >
> Vim deletes the file and moves a separate copy of the file onto the original > location. This caused inotify to stop looking at the file. >
> This patch also has happstack-plugins follow a sourcefile with compile errors > on the first try to compile it. Previously, if the file had compiling errors > the first time it was loaded by the application, happstack-plugins would not > reload it when the file is fixed. This second fix required switching from > using IORef to using MVars in order to allow IO operations (registering the > broken source file) while updating the mapping of the observed files.

Vim deletes the file and moves a separate copy of the file onto the original location. This caused inotify to stop looking at the file.

This patch also has happstack-plugins follow a sourcefile with compile errors on the first try to compile it. Previously, if the file had compiling errors the first time it was loaded by the application, happstack-plugins would not reload it when the file is fixed. This second fix required switching from using IORef to using MVars in order to allow IO operations (registering the broken source file) while updating the mapping of the observed files.