| Age | Commit message (Collapse) | Author |
|
|
|
longer needed
|
|
Please add things you think are imporant to mention to the release notes!
|
|
This makes it explicit that we no longer support compiling GF with GHC 6.12
(which is 4 years old and comes with base-4.2).
|
|
|
|
+ Programs compiled with ghc<7.8 have a default built-in 8M stack size limit.
With ghc>7.0 this built-in default can be changed, so it is now 64M, allowing
GF to work with larger grammars without manually increasing the stack size.
(But if GF is compiled with ghc 6.12, the built-in default is still 8M.)
+ Enable ghc>=7.8 support for compiling modules in parallel, to speed up the
compilation of GF.
|
|
|
|
|
|
|
|
|
|
For example, you can now reorder paragraphs by cut & paste, without causing
anything to be sent to the server for re-translation.
Also some color & layout tweaks.
|
|
|
|
|
|
It has the same parameters and result format as c-translate, but it does
the translation word for word. (To be used as a last resort).
|
|
fix to French and Italian elision in the App
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also,
+ Get up to 10 (instead of 5) alternative robust translations.
+ Remove duplicates from list of alternative robust translations
+ Add GF Cloud logo to the simple translator page
|
|
|
|
|
|
|
|
|
|
Caching parse results uses a lot of memory, even if they expire after
2 minutes, so it won't scale up to many simultaneous users.
But some excessive memory use seems to be caused by space leaks in
(the Haskell binding to) the C run-time system, and these should be fixed.
For example, flushing the PGF cache does not release the memory allocated
by the C run-time system when loading a PGF file.
|
|
|
|
|
|
|
|
|
|
from the API but for now I just hacked the C runtime
|
|
Translate
|
|
If you stored "false" and tried to retrieve it with a default value, you got
the default value instead of "false".
|
|
It is now enough to make one server call per translation, and the results can
cached by the browser.
|
|
Most PGF web API commands that produce linearizations now accept an
unlexer parameter. Possible values are "text", "code" and "mixed".
The web service now include Date and Last-Modified headers in the HTTP,
responses. This means that browsers can treat responses as static content and
cache them, so it becomes less critical to cache parse results in the server.
Also did some cleanup in PGFService.hs, e.g. removed a couple of functions
that can now be imported from PGF.Lexing instead.
|
|
The old type was [String] -> String. This function was only used
in GF.Text.Lexing.stringOp, which now uses (unwords . bindTok) instead,
with no change in behaviour.
|
|
The capitalization of the first word was done in GF.Text.Lexing.stringOp,
but is now done in the functions unlexText and unlexMixed in PGF.Lexing.
These functions are only used in stringOp and in PGFService (where the change
is needed), so the subtle change in behaviour should not cause any bugs.
|
|
Only change the first word to lowercase if the original input is not found in
the grammar's morphology. This allows parsing of sentenses starting with "I" in
English, nouns in German and proper names in other languages, but it can make
the wrong choice for multi-words.
|
|
+ Add Clear button.
+ Use localstorage to remember entered text between visits.
+ Add a link to it on the GF cloud service start page.
|
|
copies the exclude list from App.gf to the concrete syntax files.
|
|
This minimizes the duplication of code between Translate and App. Also added some functions, which make App 15% slower but increase the coverage and quality. This trade-off has to be studied further.
|
|
|
|
The PGF web API commands parse, translate, translategroup, c-parse and
c-translate now support a lexer parameter. Possible values are "text",
"code" and "mixed".
This is used in the Wide Coverage Demo App to save one server roundtrip.
|
|
|
|
They are thus part of the PGF Run-Time Library, making it possible to add
lexing functionality in PGF service in a natural way.
|
|
Otherwise the first word won't be capitalized.
|