If the C run-time library is compiled and installed on your system, you can now
do 'cabal configure -fc-runtime' to get the following extras:
+ The haskell binding to the C run-time library will be included in the
PGF library (so you can import it in Haskell applications).
Documentation on the new modules will be included when you run
'cabal haddock'.
+ The new command 'pgf-shell', implemented on top of haskell binding to
the C run-time system.
+ Three new commands in the web API: c-parse, c-linearize and
c-translate. Their interfaces are similar to the corresponding commands
without the "c-" prefix, but they should be considered preliminary.
GF.Compile.Compute.ConcreteNew + two new modules contain a new
partial evaluator intended to solve some performance problems with the old
partial evalutator in GF.Compile.Compute.ConcreteLazy. It has been around for
a while, but is now complete enough to compile the RGL and the Phrasebook.
The old partial evaluator is still used by default. The new one can be activated
in two ways:
- by using the command line option -new-comp when invoking GF.
- by using cabal configure -fnew-comp to make -new-comp the default. In this
case you can also use the command line option -old-comp to revert to the old
partial evaluator.
In the GF shell, the cc command uses the old evaluator regardless of -new-comp
for now, but you can use "cc -new ..." to invoke the new evaluator.
With -new-comp, computations happen in GF.Compile.GeneratePMCFG instead of
GF.Compile.Optimize. This is implemented by testing the flag optNewComp in
both modules, to omit calls to the old partial evaluator from GF.Compile.Optimize
and add calls to the new partial evaluator in GF.Compile.GeneratePMCFG.
This also means that -new-comp effectively implies -noexpand.
In GF.Compile.CheckGrammar, there is a check that restricted inheritance is used
correctly. However, when -noexpand is used, this check causes unexpected errors,
so it has been converted to generate warnings, for now.
-new-comp no longer enables the new type checker in
GF.Compile.Typeckeck.ConcreteNew.
The GF version number has been bumped to 3.3.10-darcs
The Setup.hs script now queries darcs to create more detailed version info
to include in the startup message.
Note thought that with distributed version control systems like darcs,
the only way to uniquely identify a version is by the set of patches included.
Since the patches are not totally ordered, just looking at the last patch is
not enough.
For official releases, we tag the current set of patches so we can refer to
it by name (e.g. RELEASE-3.3.3).
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...)
