| Age | Commit message (Collapse) | Author |
|
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
|
|
In Data.Operations, the function topoTest2 assumed too much about the form of
the input, compared to the older function topoTest.
|
|
|
|
The sequence operator (x+y) was implemented by splitting the string to be
matched at all positions and trying to match the parts against the two
subpatterns. To reduce the number of splits, we now estimate the minimum and
maximum length of the string that the subpatterns could match. For common
cases, where one of the subpatterns is a string of known length, like
in (x+"y") or (x + ("a"|"o"|"u"|"e")+"y"), only one split will be tried.
|
|
Allow line breaks in more places to make large terms more readable.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
It shows available documents and a Cancel button on top of the current
document.
|
|
returns the name of the concrete syntax
|
|
|
|
declarations for generic programming from data.c are removed as well
|
|
use the generic programming API
|
|
lexicon, as required by Xerox lexc
|
|
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 "Internal error in ...", you now get a proper error message with
a source location and a function name.
|
|
Add a conversion rule for ({ l1 = e } ** x).l2 in PMCFG generation. (A rule
for the symmetric case (x ** { l1 = e }).l2 was added some time ago.)
|
|
|
|
|
|
|
|
|
|
instead of pgf_ExprIterType
|
|
files correctly.
The parser works on raw byte sequences read from source files. If parsing
succeeds the raw byte sequences are converted to proper Unicode characters
in a later phase. But the parser calls the function buildAnyTree, which can
fail and generate error messages containing source code fragments, which might
then containing raw byte sequences. To render these error messages correctly,
they need to be converted in accordance with the coding flag in the source
file. This is now done for UTF-8-encoded source files, but should ideally also
be done for other character encodings. (Latin-1-encoded files never suffered
from this problem, since raw bytes are proper Unicode characters in this case.)
|
|
+ Instead of "Internal error in ...", you now get a proper error message with
a source location and a function name.
+ Also added some missing error value propagation in the partial evaluator.
+ Also some other minor cleanup and error handling fixes.
|
|
same as one of the expected ones: it shows full records rather than just lock fields.
|
|
Is allows to define a tokenizer in python (or use an existing one, from nltk for instance.)
|
|
This is accessible vis the `browse` command, by adding the flag `printnames`
e.g.: .../Letter.pgf?command=browse&id=Recipient&format=json&printnames=1
|
|
|
|
|
|
unhandled errors
|
|
Also a bug fix when switching to editor, although this still messes up
when using the letters grammar.
Also updated readme with options, and some style improvements.
|
|
|
|
|
|
"a"+("b"++"c") was simplified to "bb"++"c" instead of "ab"++c.
|
|
Tested it in Firefox 18 (which has the new Ionmonkey JavaScript engine).
Still get stack overflows.
|
|
This makes it possible to download PGF files from servers where the PGF service
is installed.
I am also considering making commmand=download the default instead of
command=grammar.
|
|
|
|
|
|
|
|
|
|
which is composed of Python objects. The new representation is not integrated with the core runtime yet
|
|
decideable for propositional logic. dependent types and high-order types are not supported yet. The generation is still in decreasing probability order
|