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).
2 modules: Name clashes caused by Applicative-Monad change in Prelude
2 modules: Ambiguities caused by Foldable/Traversable in Prelude
2 modules: Backwards incompatible changes in time-1.5 for defaultTimeLocale
9 modules: {-# LANGUAGE FlexibleContexts #-} (because GHC checks inferred types
now, in addition to explicitly given type signatures)
Also silenced warnings about tab characters in source files.
* httpd-shed-0.4 does not specify an upper bound on network, but it fails
to build against network>=2.6. This is fixed in httpd-shed-0.4.0.2.
* With network-2.6, the Network.URI modules is moved to a separate package,
so for the time being GF requires network>=2.3 && <2.6. This is compatible
with the four most recent versions of the Haskell Platform.
* Introducing the module CGI, re-exporting a subset of the cgi package. It
might complete replace the cgi package in the future.
* Introducing the module CGIUtils, containing functions from FastCGIUtils that
have nothing to do with fastcgi.
Some low level hackery with unsafePerformIO and global variables was left
in FastCGIUtils, but it is actually not used, neither for gf -server nor
exec/pgf-fcgi.hs.
When using full=yes in the web service 'complete' command,
you now get an additional field 'seq' with the longest possible completion.
So, given:
lin
f1 = ss "the" ;
f2 = ss ("the red house" | "the real deal") ;
and trying to complete on input "th", you get:
[
{
"from": "TestCnc",
"brackets": {
"cat": "_",
"fid": 0,
"index": 0,
"fun": "_",
"children": []
},
"text": "th",
"completions": [
{
"token": "the",
"funs": [
{
"fun": "f1",
"hyps": [],
"cat": "C",
"seq": "the"
},
{
"fun": "f2",
"hyps": [],
"cat": "C",
"seq": "the red house"
},
{
"fun": "f2",
"hyps": [],
"cat": "C",
"seq": "the real deal"
}
]
}
]
}
]
Caching parse results uses a lot of memory, even if they expire after
2 minutes, so it won't scale up to many simultaneous users.
But some excessive memory use seems to be caused by space leaks in
(the Haskell binding to) the C run-time system, and these should be fixed.
For example, flushing the PGF cache does not release the memory allocated
by the C run-time system when loading a PGF file.
Most PGF web API commands that produce linearizations now accept an
unlexer parameter. Possible values are "text", "code" and "mixed".
The web service now include Date and Last-Modified headers in the HTTP,
responses. This means that browsers can treat responses as static content and
cache them, so it becomes less critical to cache parse results in the server.
Also did some cleanup in PGFService.hs, e.g. removed a couple of functions
that can now be imported from PGF.Lexing instead.
Only change the first word to lowercase if the original input is not found in
the grammar's morphology. This allows parsing of sentenses starting with "I" in
English, nouns in German and proper names in other languages, but it can make
the wrong choice for multi-words.
The PGF web API commands parse, translate, translategroup, c-parse and
c-translate now support a lexer parameter. Possible values are "text",
"code" and "mixed".
This is used in the Wide Coverage Demo App to save one server roundtrip.
+ PGFService.hs: add command c-grammar, include probability in parse results
+ js/gftranslation.js: add start position and limit parameters, return more
info to applications
+ Simple Translator: show two wide coverage translations
+ Wide coverage demo: show parse tree and probability (intended as grammar
debugging aids)
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.
