This reverts the previous change. Not preprocessing opers turns out to make a
difference in what needs to be mentioned in restricted inheritance/imports.
This also allows the parameter rec to be removed from function computeTermOpt.
(The change is made in GF.Compile.Compute.ConcreteLazy, but not in
GF.Compile.Compute.ConcreteStrict.)
This patch adds GF.Compile.Compute.ConcreteLazy, which replaces the Err monad
with the Identity monad. While the Err monad makes the interpreter
(hyper)strict, the Identity monad let's the interpreter inherit Haskell's
laziness. This can give big speedups: from 50s to 1s in one example,
from ~4 minutes to ~2 minutes for the RGL.
This is still experimental and might be buggy, so it is off by default.
You can turn it on by configuring with the -fcclazy flag, e.g.
cabal configure -fcclazy
Let me know if anything breaks.
It is needed by greatestResource (and similar functions, presumably).
So keep both the list and the finite map of modules. This slows down some
things, but the compilation of PhrasebookFin.pgf benefits from it.
To be continued...
This speeds up the compilation of PhrasebookFin.pgf by 12%, mosly by speeding
up calls to lookupModule in calls from lookupParamValues, in calls
from allParamValues.
The invariant "modules are stored in dependency order" is no longer respected!
But the type MGrammar is now abstract, making it easier to maintain this or
other invariants in the future.
+ Avoids some code duplication by combinging lookupModule and lookupIdentInfo.
+ Also removed lookupIdentInfo from export list, since it is not used anywhere
else.
This quick fix should make Ctrl-C in the GF shell behave more like it does in
other shells: even if no command is running, Ctrl-C now just gives you a new
prompt instead of terminating the shell.
The command "gf -server" now starts a simple HTTP server on port 41295,
providing a simple web API to the GF compiler. It currently support the
follwing operations:
* creating new temporary directories for grammar uploads,
* uploading grammars files for use in the GF shell,
* executing GF shell commands, and
* accessing static files.
This means that GF now depends on some additional networking related packages,
but they should be available and easy to install on all platforms. There is
also a new configuration flag "server" in gf.cabal, so GF will be compiled
without support for server mode if the extra packages are unavailable.
Note that running gf -server while connected to the internet can be a security
risk. To prevent unauthorized access to the rest of the system, it is
advisable to run the server in GF_RESTRICTED mode and as a user with suitably
restricted file permissions.
The GF shell welcome message will now include something like
This is GF version 3.2.1-darcs.
Built on darwin/i386 with ghc-7.0, flags: interrupt
where a list of enabled configuration flags are included on the last line.
This is implemented in GF.Infra.BuildInfo by consulting the CPP macros
defined by the respective option in gf.cabal. For this to work,
GF.Infra.BuildInfo obviously has to be updated when new flags are added to
gf.cabal or if the CPP macros are renamed.
(Also, I suspect that if you reconfigure with different flags and rebuild GF
without cleaning first, the BuildInfo module will not be recompiled,
resulting in a misleading welcome message...)
By setting the environment variable GF_RESTRICTED before starting GF, the shell
will be run in restricted mode. This will prevent the GF shell from starting
arbitrary system commands (most uses of System.Cmd.system are blocked) and
writing arbitrary files (most commands that use writeFile et al are blocked).
Restricted mode is intended minimize the potential security risks involved
in allowing public access to the GF shell over the internet. It should be used
in conjuction with system level protection mechanisms (e.g. file permissions)
to make sure that a publicly acessible GF shell does not give access to parts
of the system that should not be publicly accessible.
