| Age | Commit message (Collapse) | Author |
|
|
|
linearized
|
|
|
|
one for the output trees. This means that the memory for parsing can be released as soon as the needed abstract trees are retrieved, while the trees themselves are retained in the separate output pool
|
|
|
|
partial trees
|
|
|
|
using readline with word completion
|
|
|
|
|
|
per sentence
|
|
|
|
|
|
The API computes PARSEVAL and Exact Match for a given tree. As a side effect the abstract trees in Python are now compared for equality by value and not by reference
|
|
|
|
|
|
working with bracketed strings. This also fixes some errors in the old implementation
|
|
order. this ensures probability order search in the C runtime
|
|
Also in Commands.hs: be explicit about things imported from the PGF library
that are not in the public API.
Also a couple of haddock documentation fixes.
|
|
|
|
sentences
|
|
|
|
|
|
|
|
properly. It should be fixed but for now I just disabled the optimization
|
|
in the C runtime
|
|
much memory and even makes it impossible to load the Finnish and the German parsing grammars.
|
|
|
|
|
|
|
|
Fixes the following build failure:
src/runtime/haskell/Data/Binary/IEEE754.lhs:256:17:
Could not deduce (Num a) arising from a use of `mask'
from the context (Bits a)
bound by the type signature for
clamp :: Bits a => BitCount -> a -> a
|
|
|
|
defined
|
|
|
|
|
|
GF produced slightly different PGF files on 64-bit systems and 32-bit systems.
This could cause problems when a PGF was produced on a 32-bit system and used
on a 64-bit system.
To fix this, the GF compiler and the Haskell PGF run-time library now reads
and writes PGF files like the 32-bit version even when compiled on a 64-bit
system.
Note: the Haskell type Int is still used internally in GF, which could be
32 bits or 64 bits...
|
|
flag beam_size in the top-level concrete module
|
|
|
|
returns the name of the concrete syntax
|
|
|
|
declarations for generic programming from data.c are removed as well
|
|
use the generic programming API
|
|
and adds another implementation which builds on the existing API for lexers in the C runtime. Now it is possible to write incremental Lexers in Python
|
|
|
|
|
|
|
|
|
|
|
|
instead of pgf_ExprIterType
|
|
Is allows to define a tokenizer in python (or use an existing one, from nltk for instance.)
|