The interface to the wide coverage translation is in js/gftranslate.js
and it assumes that the grammar is installed on the cloud server
as /robust/Translate8.pgf.
The list of supported languages is hardwired in gftranslate.js, since
there is no support for obtaining this info from the C run-time system
at the moment.
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.
* The haskell-bind.cabal file makes it easy to build the haskell binding and
use it in ghci.
* pgf-shell.hs is a simple example of how to use the haskell binding.
Change the type of getConcr from
getConcr :: PGF -> Language -> Concr
to
getConcr :: PGF -> Language -> Maybe Concr
This is to prevent programs from crashing later if you try to select a
concrete syntax that is not present in a grammar.
The parse grammar Parse8.pgf for 8 languages can now be built in parallel with
make -j. Finnish requires a lot of RAM. French requires a lot of time.
Other related make targets available for convenience:
make Parse: create Parse???.pgf for the 8 individual languages
make Parse8: create Parse8.pgf assuming all Parse???.pgf already exist
Note: these make targets (and some others) use the gf executable and RGL
library that are installed on the system (found via $PATH and $GF_LIB_PATH,
respectively).
When running a command like
gf -make L_1.gf ... L_n.gf
gf now avoids recreating the target PGF file if it already exists and is
up-to-date.
gf still reads all required .gfo files, so significant additional speed
improvements are still possible. This could be done by reading .gfo files
more lazily...
When running a command like
gf -make -name=T L_1.pgf ... L_n.pgf
gf now checks if T.pgf exists and is up-to-date before reading and computing
the union of the L_i.pgf files.
The name (T) of the target PGF file has to be given explicitly for this to work,
since otherwise the name is not known until the union has been computed.
If the functions for reading PGF files and computing the union were lazier,
this would not be necessary...
