The userLangauge is the name of the concrete syntax that has a languageCode
that matches the user's preferred language, as reported by the web browser.
If no matching language code is found, the PGF service now sets userLanguage
to the concrete syntax for English (e.g. FoodsEng) if present, and defaults
to the first concrete syntax (e.g. FoodsAfr) only if English is not present
in the grammar.
It was only needed for compatibility with directory<1.2, but
directory>=1.2 has been shipped with ghc since ghc-7.6.
Note: time-compat-1.9.* (the current version) is a completely different
package, that does not provide the needed function toUTCTime, which
was provided in time-compat-0.1.*.
CncLabels are read from a file in the same directory as the PGF file and
with the same name as the concrete syntax + extension .labels,
e.g. ResourceDemo.pgf would use labels from
ResouceDemo.labels (abslabels)
ResouceDemoEng.labels (clclabels)
The function listCaches returns an empty list instead of the contents
of the cached C run-time system PGFs when compiled without C-run-time support
This gave rise to an ambiguity in GF.Server.
+ The PGF service now reads and caches dependency label configuration files.
+ The grammar info returned by command=grammar has a new boolean field
'hasDependencyLabels' to indicate if dependency labels were found for
the grammar. Also, command=deptree will now fail if no labels are present.
+ The minibar only shows word dependency trees if labels are present.
+ Also changed the type of getDepLabels from [String] -> Labels to
String -> Labels, since all uses were in the form "getDepLabels . lines".
This is the web interface to PGF.graphvizDependencyTree.
Accepted parameters: format=<output_format>, to=<lang>, tree=<tree>.
Accepted output formats: latex, conll, malt_tab, malt_input, png, gif, svg, gv
Also, label information is taken from <path>.labels if present, where
<path>.pgf is the path to the PGF file.
By adding unlexer=none (or unlexer=id) in requests that output linearizations
(e.g. command=linearize, command=translate), you can leave &+ uninterpreted
instead of gluing the adjacent tokens. This means that the output is left in
a format that can be parsed in a subsequent request.
To implement this consistently, the function linearizeAndBind was replaced
with the function linearizedAndUnlex (but there are a couple of requests
that do not call this function...)
Note that this applies to the Haskell run-time requests only. The C run-time
request (c-linearize, c-translate) always applies the &+ token and the
c-parse request can parse input containing glued tokens.
The parse/translate/c-parse/c-translate commands now recognize the option
jsontree=true to augment the returned JSON structure with a field called
"jsontree" next to the field "tree", or "jsontrees" next to "trees",
containing the the returned syntax tree in JSON format (the same format
returned by the abstrjson command, similar to the format returned in the
"brackets" field).
