Unnamed repository; edit this file 'description' to name the repository. https://git.adelon.net/gf-core.git/atom?h=master 2020-08-05T16:48:24+00:00 2020-08-05T16:48:24+00:00 Andreas Källberg anka.213@gmail.com 2020-08-05T14:20:35+00:00 urn:sha1:251845f83ea52965b5205fd231ffa2c87bb34de6 2018-07-22T07:04:07+00:00 meng wong mengwong@pobox.com 2017-08-19T11:27:07+00:00 urn:sha1:8a14912ee3b692bc578465b6920575f5d7b11b4c 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 2015-08-13T10:49:50+00:00 hallgren hallgren@chalmers.se 2015-08-13T10:49:50+00:00 urn:sha1:87e64a804cbe5848d20f0555dedae42e1516cbbc + Generalize the CommandInfo type by parameterizing it on the monad instead of just the environment. + Generalize the commands defined in GF.Command.{Commands,Commands2,CommonCommands,SourceCommands,HelpCommand} to work in any monad that supports the needed operations. + Liberate GF.Command.Interpreter from the IO monad. Also, move the current PGF from CommandEnv to GFEnv in GF.Interactive, making the command interpreter even more generic. + Use a state monad to maintain the state of the interpreter in GF.{Interactive,Interactive2}. 2014-11-10T16:20:01+00:00 hallgren hallgren@chalmers.se 2014-11-10T16:20:01+00:00 urn:sha1:c707575bd7751ac3b03371edba478e37d3488448 Renamed appIOE to tryIOE (it is analogous to 'try' in the standard libraries). Removed unused IOE operations & documented the remaining ones. Removed/simplified superfluous uses of IOE operations. 2014-11-10T15:23:02+00:00 hallgren hallgren@chalmers.se 2014-11-10T15:23:02+00:00 urn:sha1:33571ba44f2a42502722a3b025b448efe1f0ab88 2014-10-22T15:45:52+00:00 hallgren hallgren@chalmers.se 2014-10-22T15:45:52+00:00 urn:sha1:6ee67cd04ffbce375d7f10e74a5d9eb742d6428d 2014-10-20T19:32:46+00:00 hallgren hallgren@chalmers.se 2014-10-20T19:32:46+00:00 urn:sha1:8337a19b40301bfda5dd74c6d975072f168538de IOE used to be a monad with extra error handling built on top of the IO monad, But the IO monad already supports error handling, so this construction was a superfluous. The new 'instance ErrorMonad IOE' is defined to preserve the previous error handling behaviour, i.e. the function 'handle' only catches errors thrown with 'raise' (or 'fail') and not other errors in the IO monad. 2014-10-16T15:00:49+00:00 hallgren hallgren@chalmers.se 2014-10-16T15:00:49+00:00 urn:sha1:2e2e7acf12c1b84eb1d4f0ac28d120a4d0c4a1c4 The module src/compiler/GF.hs now serves as a prelimiary compiler API. It just exports a selection of functions and types from the compiler. Haddock documentation can be generated with cabal haddock --hyperlink-source Also bumbed the version number to 3.6.10. 2014-10-16T14:03:57+00:00 hallgren hallgren@chalmers.se 2014-10-16T14:03:57+00:00 urn:sha1:c924491289259fa8a5a259ed97f2d9e817e3338c 2014-08-25T09:56:00+00:00 hallgren hallgren@chalmers.se 2014-08-25T09:56:00+00:00 urn:sha1:d84c5ef1715c3e4aed4098ee9c847e2dcc86cba4 On my laptop these changes speed up the full build of the RGL and example grammars with 'cabal build' from ~95s to ~43s and the zero build from ~18s to ~5s. The main change is the introduction of the module GF.CompileInParallel that replaces GF.Compile and the function GF.Compile.ReadFiles.getAllFiles. At present, it is activated with the new -j flag, and it is only used when combined with --make or --batch. In addition, to get parallel computations, you need to add GHC run-time flags, e.g., +RTS -N -A20M -RTS, to the command line. The Setup.hs script has been modified to pass the appropriate flags to GF for parallel compilation when compiling the RGL and example grammars, but you need a recent version of Cabal for this to work (probably >=1.20). Some additonal refactoring were made during this work. A new monad is used to avoid warnings/error messages from different modules to be intertwined when compiling in parallel, so some functios that were hardiwred to the IO or IOE monads have been lifted to work in arbitrary monads that are instances in the appropriate classes.