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.
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.
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...
