| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/GrammaticalFramework/pgf-binary
|
|
|
|
The functions cExpr and hsExpr in GF.Command.Commands2 need to
handle string literals.
|
|
|
|
|
|
|
|
|
|
|
|
and pgf-service executable optional
This allows you to build the content-service without installing the problematic fastcgi library.
|
|
|
|
Traditionally, GF_LIB_PATH points to something like
`.../share/ghc-8.0.2-x86_64/gf-3.9/lib`
and if you want prelude and alltenses and present, you add a
`--# -path=.:present`
compiler pragma to the top of your .gf file
But if you are developing some kind of application grammar
library or contrib of your own, you might find yourself
repeating your library path at the top of all your .gf files.
After painstakingly maintaining the same library path at the
top of all your .gf files, you might say, let's factor this
out into GF_LIB_PATH.
Then you might then find to your surprise that GF_LIB_PATH
doesn't accept the usual colon:separated:path notation
familiar from, say, unix PATH and MANPATH.
This patch allows you to define
`GF_LIB_PATH=gf-3.9.lib:$HOME/gf-contrib/whatever/lib`
in a more natural way.
If you are an RGL hacker and have your own version of the
RGL tree sitting somewhere, you should be able to have both
paths in the GF_LIB_PATH, for added convenience. This minor
convenience will probably lead to obscure bugs and great
frustration when you find that your changes are mysteriously
not being picked up by GF; so keep this in mind and use it
cautiously.
This caution should probably sit in the documentation
somewhere. A subsequent commit will do that.
If you use zsh, you can do this to quickly build up a big
GF_LIB_PATH:
% gf_lib_path=( $HOME/src/GF/lib/src/{api,abstract,common,english,api/libraryBrowser,prelude,..} )
% typeset -xT GF_LIB_PATH gf_lib_path
|
|
|
|
One could also add stricter version constraints in gf.cabal, e.g.
base>=4.8 (implies GHC>=7.10) if we want to only support building with
GHC>=7.10.
|
|
|
|
|
|
function should still be reported"
This reverts commit 18204bdd25bd460904ac475f3ea340daa96589df.
|
|
This reverts commit 5919dfa3366dfd2f2af8c3ce7749d066a2033f0d.
|
|
|
|
should still be reported
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- moved to new repo at
https://github.com/GrammaticalFramework/gf-emacs-mode
- main changes:
- use utf-8 encoding for inferior gf process
- add display of operation types
- update links
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* In GHC 8.4.1, the operator <> has become a method of the Semigroup class
and is exported from the Prelude. This is unfortunate, since <> is also
exported from the standard library module Text.PrettyPrint, so in any
module that defines a pretty printer, there is likely to be an ambiguity.
This affects ~18 modules in GF. Solution:
import Prelude hiding (<>)
This works also in older versions of GHC, since GHC does't complain if
you hide something that doesn't exists.
* In GHC 8.4.1, Semigroup has become a superclass of Monoid. This means
that anywhere you define an instance of the Monoid class you also have to
define an instance in the Semigroup class.
This affects Data.Binary.Builder in GF. Solution: conditionally define
a Semigroup instance if compiling with base>=4.11 (ghc>=8.4.1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gf -server now includes the comment field from the grammar in the
response to /cloud requests with command=ls-t and ext=.json
|
|
The editor doesn't show delete buttons on grammars published by other
users, but it was too picky when deciding which grammars you own. Now
it should be possible to delete grammars from the device/browser
you published it from, even if you don't have a private copy of it any more.
On a related note, there seems to be problem with the way unique grammars
names are created and maintained, causing published grammars to be duplicated
in some cases. This needs to be overhauled.
|
|
This was a problem in Safari (an other similar browsers I presume), but
not in Firefox: hovering over the grammar comment (shown below the grammar
name when you edit a grammar) didn't reveal the button to edit it, thus
preventing you from adding a comment. It was till possible by selecting the
"Enable editing on touch devices." at the bottom of the screen, but most
people probably didn't notice that it is possible to add a comment.
|
