CncLabels are read from a file in the same directory as the PGF file and
with the same name as the concrete syntax + extension .labels,
e.g. ResourceDemo.pgf would use labels from
ResouceDemo.labels (abslabels)
ResouceDemoEng.labels (clclabels)
* Just skip the Java binding if there were errors compiling it.
* Install the Python binding in the expected place on Mac OS X when creating
an OS X installer package. (i.e. under /Library/Python/2.7/site-packages)
Also updated the 3.8 download page and release notes to reflect the above.
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.
Remove ghc-7.4 from the list of tested/recommended versions of GHC
(because of Hackage dependency problems).
Recommend version 7.10.3 of the Haskell Platform. (GHC 8.0.1 works too,
but I haven't tested the corresponding Haskell Platform packages.)
+ 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 was done by introducing an intermediate representation for the LaTeX
pictures produced by the LaTeX renderer and providing a new backend that
outputs SVG instead of LaTeX.
This was done to obtain speech synthesis for more languages in the Numerals
grammar, which uses neither language flags nor the standard naming for
concrete syntax.
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.
They seemed very difficult to use without the documentation, since their
types are not particularly self documenting.
Also documented what the (Bool,Bool) argument to PGF.graphvizAbstractTree
is for.
* Automatically update the translations when the set of selected
application grammars is changed.
* Skip application grammars that do not support the currently selected
source & target languages.
Add missing initalization after a new application grammar has been selected.
Add an "X" close button in the upper left corner of the grammar selection popup.
When selecting which application grammars to use for translation, after
pressing the "Grammars..." button, it is now possible to change the order
of the selected grammars by dragging them up and down in the list.
gfse/editor.js had its own list with 34 languages, while js/langcode.js
only had 30 languages. The missing languages have been added to
js/langcode.js and all apps now use that list.
There is now a new button "Grammars..." which show a list where users can
select which application grammars to use for translation, in addition to
the wide coverage grammar. Application grammars can give higher quality
translations in the domain they cover.
TODO: make it possible control the order of the selected application grammars.
This was fixed by adding "&nodep=true" in the minibar when it requests a
parse tree from the server. The reason dependency information got included
in the first place was that all rendering options are on by default in
command=parsetree requests in PGF service API.
This means that you now need to have a Java SDK installed to build
a Debian package.
The bin/build-binary-dist.sh (which builds bintar packages and OS X installer
packages) now skips the Python binding if python is not installed. Likewise
it skips the Java binding if a Java SDK is not installed.
dh_shlibdeps has a problem finding which package some of the Haskell
libraries come from, even though dpkg-query -S has no problem finding them.
But the gf executable is statically linked against the Haskell libraries, so
it will work even if these shared libraries aren't installed. But there will
be a problem if other shared libraries are missing (.e.g. libtinfo, libgmp),
so we need a better solution than simply ignoring all dependency problems...
See also http://stackoverflow.com/questions/11238134/dpkg-shlibdeps-error-no-dependency-information-found-for
This patch fixes a problem introduced last year when the GF shell was
refactored to allow more commands to be treated uniformly and be part
of pipes. The cc command was one of those commands, but unfortunately this
introduced a parsing problem, e.g.
> cc "last"
constant not found: last
> cc "last"++"year"
command not parsed: cc "last"++"year"
This happened because the generic command line parser in
GF.Command.{Abstract,Parse} assumes that all commands have an argument of
type PGF.Expr. Commands that expect other types of arguments have to
use PGF.showExpr combined with other conversion to the argument type they
expect. The cc command excpets a GF.Grammar.Term, and unfortunately not
all terms survice the roundtrip through PGF.Expr, in part because of
an additional hack to allow strings to be roundtripped through PGF.Expr
without adding superfluous double quotes.
To solve the problem, this patch
+ makes room for arguments of type Term in the Argument type in
GF.Command.Abstract.
+ makes a special case for the cc command in GF.Command.Parse, by
calling the partial parser 'runPartial pTerm' recently added in
GF.Grammar.Lexer and GF.Grammar.Parser. Care was taken so that
that "|" and ";" can be used both inside terms and as separators between
commands in the shell, e.g. things like the following now work:
> cc ("a"|"b") | ps -lexcode
variants { "a" ; "b" }
+ introduces a type CommandArgument that replaces [Expr] as the
type of values passed between commands in pipes. It has room for
values of type [Expr], [String] and Term, thus eliminating the need
to roundtrip through the Expr type all the time.
The hack to avoid adding superfluous quotes when strings are
roundtripped through Expr has been left in place for now,
but can probably be removed.
Lexer.x: Change the parser monad type P to allow the remaining input to
be returned after a partial parse. Add function
runPartial :: P t -> String -> Either (Posn, String) (String, t)
Parser.y: Add a partial parser pTerm for nonterminal Exp1.
Re-export runPartial.
The automake package contains aclocal, which is needed when running
autoreconf -i.
I never needed to install automake explicitly on Linux, presumably because it
got installed anyway because of some other dependency, but apparently you
can't take this for granted.
Because of the "heurisitc factor", the results returned by the parser might
not be in strict probability order. To compensate, a sorting pass has been
added to find and show the translation with the highest probability among the
10 first translations.
However, this means that the translation demo now immediately has to ask for
10 translations of every segment. Before, it initially asked for only one
translation of every segment, and then 9 more translations for a segment
when/if the user clicked on it. This change can slow down translation
noticeably (e.g. from 15s 30s to load an example with fiction in English).
"File/Open In Wide Coverage Translation Demo" stopped working when support
for using different grammars in the Wide Coverage Translation Demo was added
On September 2.
This is implemented as a simple post-processing step after partial evaluation
to try compute pre{...} tokens in token sequences. Nothing is done to deal
with intervening free variants.
This was done in response to a query from René T on the gf-dev mailing list.
The matchPrefix function is used in str2strings and the partial evaluator to
compute pre{...} tokens. But unlike the description in the GF book and
the implementation in the run-time system, matchPrefix looked at
the concatenation(!) of all following tokens and not just the next token
when deciding how to compute a pre{...} token.
This is a backwards incompatible change, but it is subtle and probably won't
cause any problems. In particular, the example grammars are unaffected.
Updated version number in gf.cabal and update debian/changelog
News item on home page (index.html)
Some last minute edits on the download page
Move the new release notes and download page in place.
This makes the output from PGF.showExpr (and other Haskell code that uses
the Prelude.show function to show strings) parsable as GF source code in
more cases.
This is a workaround for the problem that GHC's implementation of the show
function uses numeric escapes for printable non-ASCII characters, e.g.
show "dålig" = "d\229lig"...
This should work nicely now that GF itself can detect the number of processors
in the system.
Previously there was some code in WebSetup.hs that relied on Cabal to do this,
but it was commented out because it requires Cabal>=1.20, which is fairly new
and it would complicate the installation instructions if it was required to
compile GF...
* "gf -make -j=n" uses n parallel threads.
* "gf -make -j" adapts to the number of processors in the system.
This mimics how "cabal build -j" and "ghc --make -j" works.
Support for this is implemented in the new module GF.System.Concurrency and
it depends on the function Control.Concurrent.setNumCapabilities, which is
only available in GHC>=7.6 (base>=4.6). GF can still be compiled with
GHC<7.6, but then you have to use +RTS -N -RTS to take advantage of
multicore processors.
To detect the number of processors in the system, the code depends on a
foreign import of a C function in the GHC run-time system.
Apparently Foreign.unsafePerformIO is not just a re-export of
System.IO.Unsafe.unsafePerformIO (or vise versa), it is a different function,
so you get an ambiguity if you import both.
These changes are inspired by the gf -cshell implementation of these commands.
The output of the linearize command has been changed to remove superfluous
blank lines and commas, and deliver the result as a list of strings instead of
a single multi-line string. This makes it possible to use -all and pipe the
results to the parse command. This also means that with -treebank -all,
the language tag will be repeated for each result from the same language.
The parse command, when trying to parse with more than one language, would
"forget" other results after a failed parse, and thus not send all
successful parses through the pipe. For example, if English is not the first
language in the grammar,
p "hello" | l
would output nothing, instead of translations of "hello" to all languages,
forcing the user to write
p -lang=Eng "hello" | l
instead, to get the expected result. The cause of this behaviour was in the
function fromParse, which was rather messy, so I assume it is not intentional,
but the result of a programming mistake at some point.
The fromParse function has now been refactored from a big recursive function
into
fromParse opts = foldr (joinPiped . fromParse1 opts) void
where the helper functions fromParse1 deals with a single parse result and
joinPiped combines multiple parse results.
Even though the -lang flag was handled in the implementation, it was not
documented, and GF.Command.Interpreter rejects undocumented flags:
option not interpreted: lang
This must be a fairly old bug, so it suggests that the vp command isn't used
much...
Thomas Hallgren