| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
still ok.
|
|
|
|
|
|
Ravishankar
|
|
|
|
|
|
longer a parameter to the callbacks.
|
|
copied since otherwise the Python string may be discarded the garbage collector
|
|
|
|
|
|
|
|
|
|
|
|
temporary pool is used on every iteration to keep memory allocation to constant
|
|
|
|
|
|
|
|
|
|
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 API in the C runtime as well as in the Haskell, Python and Java binding
is changed. Now instead of adding the literal callbacks to the concrete syntax
you need to supply them every time when you need to parse. The main reason is:
- referentially transparent API for Haskell
- when we start using memory mapped files we will not be allowed to change
anything in the grammar data structures. At that point the old API would
be impossible to use.
|
|
|
|
|
|
|
|
|
|
|
|
except those that require def rules. The design is consistent with the STG virtual machine
|
|
the embedded grammars especially pleasing
|
|
|
|
|
|
There are also some changes in src/runtime/python/setyp.py to support this.
|
|
|
|
|
|
|
|
|
