linearizeAll function will take an expression and an optional
n keyword argument and return an iterator to the n-variant
linearizations of the expression.
The examples directory contains two modules for using Python bindings in GF.
The gf_utils module provides various Python functions to perform parsing
and linearization using the C runtime. Additionally, the translation_pipeline
module is an replica of the current pipeline used in the Wide-coverage
Web translation pipeline.
The length limit test previously used the URL-encoded UTF-8 representation
of the source sentense. This was needed because of a fixed size buffer in C.
Now that the server is in Haskell, the only reason the length is limited
is to avoid excessive time and space use in the parser, so it is better to
count source characters. This also avoids being too restrictive with
non-European languages.
For further separation of pretty printing concerns from conversion concerns,
the Haskell AST and pretty printer has been moved to its own module,
GF.Haskell, also allowing it to be reused in other places where Haskell
code is generated.
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).
Too see inflection tables, click on a translated sentense, then click on a
blue function name in the textual representation of the abstract syntax tree.
You can now click on a tree to toggle between the abstract syntax tree and
the parse tree.
Also, the implementation now uses the new C run-time requests, e.g.
App14.pgf?command=c-abstrtree&tree=...
so no need to install AppEng.pgf on the server any more.
The trees are drawn by using the Haskell run-time request
AppEng.pgf?command=abstrtree&tree=...
Thus AppEng.pgf has to be installed on the server and in sync with App14.pgf.
This is to avoid loading the huge App14.pgf in the Haskell run-time system, and
is enough since we only need the abstract syntax.
