This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "snap".
The branch, master has been updated
via d100331c73dd9a9346e10f7e00d274262fa61ea8 (commit)
from 5dbb52de15bf086fb00200e1ec7da71bb70309a1 (commit)
Summary of changes:
project_template/hint/src/Main.hs | 31 +++++++++++++++++++++++++++++++
src/Snap/Loader/Hint.hs | 14 ++++++++++++++
2 files changed, 45 insertions(+), 0 deletions(-)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit d100331c73dd9a9346e10f7e00d274262fa61ea8
Author: Carl Howells <[email protected]>
Date: Thu Jul 1 16:08:58 2010 -0700
More documentation about the tradeoffs between development and production
mode
diff --git a/project_template/hint/src/Main.hs
b/project_template/hint/src/Main.hs
index a891683..d0af9d8 100644
--- a/project_template/hint/src/Main.hs
+++ b/project_template/hint/src/Main.hs
@@ -23,6 +23,37 @@ import Snap.Loader.Hint (loadSnapTH)
-- of the project tree. It locates its templates, static content, and
-- source files in development mode, relative to the current working
-- directory when it is run.
+--
+-- When compiled without the production flag only changes to the
+-- libraries, your cabal file, or this file should require a recompile
+-- to be picked up. Everything else is interpreted at runtime. There
+-- are a few consequences of this.
+--
+-- First, this is much slower. Running the interpreter seems to take
+-- about 300ms on my system, regardless of the simplicity of the
+-- loaded code. The results of the interpreter process are cached for
+-- a few seconds, to hopefully ensure that the the interpreter is only
+-- invoked once for each load of a page and the resources it depends
+-- on.
+--
+-- Second, the generated server binary is MUCH larger, since it links
+-- in the GHC API (via the hint library).
+--
+-- Third, it results in loadAppState/cleanupAppState being called for
+-- each request. This is to ensure that the current state is
+-- compatible with the running action. If your application state
+-- takes a long time to load or clean up, the penalty will be visible.
+--
+-- Fourth, and the reason you would ever want to actually compile
+-- without production mode, is that it enables a *much* faster
+-- development cycle. You can simply edit a file, save your changes,
+-- and hit reload to see your changes reflected immediately.
+--
+-- When this is compiled with the production flag, all the actions are
+-- statically compiled in. This results in much faster execution, a
+-- smaller binary size, only running load and cleanup once per
+-- application run, and having to recompile the server for any code
+-- change.
main :: IO ()
main = do
-- override the some of the defaults from Snap.Http.Server.Config
diff --git a/src/Snap/Loader/Hint.hs b/src/Snap/Loader/Hint.hs
index dc03947..e32a1bb 100644
--- a/src/Snap/Loader/Hint.hs
+++ b/src/Snap/Loader/Hint.hs
@@ -43,6 +43,16 @@ import qualified Snap.Loader.Static as Static
-- This could be considered a TH wrapper around a function
-- > loadSnap :: IO a -> (a -> IO ()) -> (a -> Snap ()) -> IO (IO (), Snap ())
-- with a magical implementation.
+--
+-- The returned IO action does nothing. The returned Snap action does
+-- initialization, runs the action, and does the cleanup. This means
+-- that the whole application state will be loaded and unloaded for
+-- each request. To make this worthwhile, those steps should be made
+-- quite fast.
+--
+-- The upshot is that you shouldn't need to recompile your server
+-- during development unless your .cabal file changes, or the code
+-- that uses this splice changes.
loadSnapTH :: Name -> Name -> Name -> Q Exp
loadSnapTH initialize cleanup action = do
args <- runIO getArgs
@@ -101,6 +111,10 @@ getHintOpts args = -- These hide-packages will go away
with a new
-- This constructs an expression of type Snap (), that is essentially
-- > bracketSnap initialization cleanup handler
-- for the values of initialization, cleanup, and handler passed in.
+--
+-- Generally, this won't be called manually. Instead, loadSnapTH will
+-- generate a call to it at compile-time, calculating all the
+-- arguments from its environment.
hintSnap :: [String] -- ^ A list of command-line options for the interpreter
-> [String] -- ^ A list of modules that need to be
-- interpreted. This should contain only the
-----------------------------------------------------------------------
hooks/post-receive
--
snap
_______________________________________________
Snap mailing list
[email protected]
http://mailman-mail5.webfaction.com/listinfo/snap
