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 removes all superfluous files from the directory, especially the
binary files in the doc folder. They are still available in the git
repository http://github.com/daherb/GF-latin which is still the main
repository for the development of the latin grammar.
The GF files are updated to a state close to the one at the end of the GF
Summer School 2015 where they were extended to support the MUSTE grammar.
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.
