summaryrefslogtreecommitdiff
path: root/src/compiler/GF/CompileOne.hs
AgeCommit message (Collapse)Author
2014-09-08(1) Refactor concurrency, (2) write to .gfo.tmp then rename to .gfohallgren
(1) introduces the module GF.Infra.Concurreny with lifted concurrency operators (to reduce uses of liftIO) and some additional concurrency utilities, e.g. a function for sequential logging that is used in both GF.CompileInParallel and GFServer. (2) avoids leaving broken .gfo files behind if compilation is aborted.
2014-08-25Experimental: parallel batch compilation of grammarshallgren
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.
2014-08-22Command line flag -s/-q now silences all warningshallgren
These flags now do what the say.
2014-08-20Add lifted directory operations in GF.System.Directory to eliminate the need ↵hallgren
for liftIO in various places
2014-08-20GF.CompileOne: refactoring to reduce code duplication and improve readabilityhallgren
I prefer small functions with descriptive names over large monilithic chunks of code, so I grouped the compiler passes called from compileSourceModule into funcitons named frontend, middle and backend. This also makes decisions about which passes to run clearly visible up front. Also made some small changes in GF.Compile.
2014-08-13Refactoring in GF.Compile and GF.ReadFiles with an eye to parallel compilationhallgren
In particular, the function compileOne has been moved to the new module GF.CompileOne and its type has been changed from compileOne :: ... -> CompileEnv -> FilePath -> IOE CompileEnv to compileOne :: ... -> SourceGrammar -> FilePath -> IOE OneCompiledModule making it more suitable for use in a parallel compiler.