This is a simple change in GF.Grammar.Lookup.allOpers, which is used only in
the implementation of the show_operations command in the shell.
This is useful when importing a concrete syntax (like LexiconEng) as a resource.
However, the types don't always look as nice as I hoped...
+ The restrictions on arbitrary IO when GF is running in restricted mode is now
enforced in the types.
+ This hopefully also solves an intermittent problem when accessing the GF
shell through the web API provided by gf -server. This was visible in the
Simple Translation Tool and probably caused by some low-level bug in the
GHC IO libraries.
The SIO monad is a restriction of the IO monad with two purposes:
+ Access to arbitrary IO operations can be turned off by setting the environment
variable GF_RESTRICTED. There is a limited set of IO operations that are
considered safe and always allowed.
+ It allows output to stdout to be captured. This can be used in gf -server
mode, where output of GF shell commands is made part of HTTP responses
returned to clients.
The dependency on PGFEnv has been moved from the list to the exec function of
the commands in the list. This means that the help command no longer needs
to generate a new list of commands and that the state of the shell
(type GF.Command.Interpreter.CommandEnv) no longer needs to contain the list
of commands.
+ More restrictive limits on which file paths can be downloaded and removed.
+ Add more extensions to the list of file types that may be removed. In
particular, allow documents created by simple translation tool to be removed.
+ The instructions have been modernized and simplified slightly and should now
work again. (I have not verified it on Windows.)
Using 'cabal' instead of 'runghc Setup.hs' avoids some problems.
+ Also, download/index.html has simpler installation instructions sufficient
for many users, so mention it in the main README file.
+ Also adjusted the main Makefile.
+ show a cloud icon next to the document name if it is stored in the cloud
+ in addition to the name of the current document, remember if it is stored in
the cloud, so that the right document is loaded next time you open the
translator.
Introduced the function
parallelCheck :: [Check a] -> Check [a]
that runs independent checks in parallel, potentially allowing faster grammar
compilation on multi-core computers, if you run gf with +RTS -N.
However, on my dual core laptop, this seems to slow down compilation somewhat
even though CPU utilization goes up as high as 170% at times.
(This is with GF compiled with GHC 7.0.4.)
In GF.Compile.CheckGrammar, use a new topological sorting function that
groups independent judgements, allowing them all to be checked before
continuing or reporting errors.
Reimplemented it with the new function accumulateError.
Also keeping the formatting of errors and warnings unchanged for now, to avoid
potentially causing problems in the GF Eclipse Plugin.
Using accumulated errors in the Check monad.
TODO: some errors are still not accumulated, but thanks to checkMapRecover
at least one error per judgement is reported.
In addition to warnings, the Check monad in GF.Infra.CheckM can now accumulate
errors. There are two new functions
checkAccumError: Message -> Check ()
accumulateError :: (a -> Check a) -> a -> Check a
The former (with the same type as checkWarn) is used to report an accumulated
(nonfatal) error. The latter converts fatal errors into accumulated errors.
Accumulated errors are reported as regular errors by runCheck.
Also, the Check monad type has been made abstract.
This turns error messages like
gf: too few bytes. Failed reading at byte position 1
gf: /some/path/somefile.gfo: too few bytes. Failed reading at byte position 1
but a better fix would be to ignore bad .gfo files and compile from source.
The problem is the way this decision is made in
GF.Compile.ReadFiles.selectFormat...
Also added feedback to source & target language menus to indicate which
languages are supported by the selected translation method. For Apertium, the
source language menu shows all possible source languages, and the target menu
shows the possible target languages for the chosen source language.
The Setup.hs script now queries darcs to create more detailed version info
to include in the startup message.
Note thought that with distributed version control systems like darcs,
the only way to uniquely identify a version is by the set of patches included.
Since the patches are not totally ordered, just looking at the last patch is
not enough.
For official releases, we tag the current set of patches so we can refer to
it by name (e.g. RELEASE-3.3.3).
Note though that the unlexer does the wrong thing with initial words that are
supposed to be capitalized, e.g. "I am ready.", "Spanish wine is good.", so
these sentenses are not translated at the moment.
* Update Setup.hs to build Japanese by default.
* News item about Japanese on the home page.
* Add Japanese to the supported RGL imports in the grammar editor (gfse).
As a temporary workaround, alex is no longer invoked automatically when
building with cabal. Developers who want to modify the lexer need to run
alex on Lexer.x manually and record the modified Lexer.hs.
src/compiler/GF/Grammar/lexer/Lexer.x -- hidden from cabal
src/compiler/GF/Grammar/Lexer.hs -- update it manually
Instead of showing the name of a function in the abstract syntax, linearize it
and show the result. For functions with argument, e.g. That : Kind -> Item,
the function is applied to the right number of placeholder arguments: 'That ?'.
If the linearization fails, the name of the function is shown anyway.
The grammar extension is now done with a regular HTML form, so you can use the
TAB key to move between the fields and press ENTER to submit the extension when
you are done.
TODO: more immediate error feedback
The Haskell Platform page for Mac states that Xcode 3.2 or later is ok, but
there seems to be a problem with Xcode 3.2.2.
Also added some other small clarifications.
The current intput is now represented as an array of words instead of as a
string.
(This is the kind of change is scary to do in a dynamically type language
like JavaScript. In a statically typed language like Haskell you can do it
with confidence, since you know the compiler can help you catch all mistakes...)
hallgren