* "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.
This reduces the amount of duplicated code from 2400 to 490. No code from
data-binary-ieee754 is duplicated.
The module is called PGF.Data.Binary instead of Data.Binary. It is not
in use yet.
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.
While the abstract Numeral inherits only Cat[Numeral,Digits], some of the
concrete NumeralNNN of Numeral inherited everything from CatNNN.
Normally the compiler outputs a warning message when a concrete syntax
contains superflous lincats, but apparently not when they get included
through inheritance...
This does not seem to cause problems in the Haskell run-time system, but the
C run-time system fails to load PGFs with superflous lincats.
This problems shows up when creating application grammars that inherit Numeral.
The Phrasebook is an example of such a grammar.
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...
pg supports only the -funs, -cats and -langs output modes.
ai IDENTIFIER shows info about a category or a function. ai can not type check
and refine metavariables in expressions.
showType :: Type -> String
categories :: PGF -> [Cat]
But both are implemented as quick hacks: categories is implemented by listing
all functions and taking the target categories from their types. showType uses
ppType copied & modified from PGF.Type, and needs a ppExpr, which is currently
implemented by wrapping showExpr...
TODO: need something correpsonding to PGF.categoryContext.
hallgren