Assuming I'm starting a brand-new project, it starts by creating a file in my code directory. initing darcs there, creating the .cabal file, and creating a basic module hierarchy. After that, I `touch` a couple of files. add the standard license/description/other header info... When I'm working on the code proper, I have a screen session split to a ghci session and a vim session editing the file. The ghci sits in the base directory of the projects (where the _darcs folder is) and has the files I'm working on loaded. I edit, ^a-tab to ghci, reload, flip back, fix errors, repeat till it loads. After that, I run a few tests to make sure the program does what I think it does, if not, I fix it, then back to adding new functionality. I hope this is what you wanted to know. Towards the point where I'm going to release a version, I substitute the ghci-business to a proper test harness/cabal build to make sure it compiles all correctly. /Joe On Sep 21, 2009, at 5:35 PM, Tom Doris wrote:
Hi I'd like to know what the typical edit-compile-test loop looks like with the Haskell platform; that is, in C++ this would be edit, run make to compile everything in the project into libraries and executables, then run an executable test suite. I'm confused as to how people work on larger projects in Haskell - do you work on a single module and load it into ghci to test as you develop, then compile the entire package and run a test suite? Or do you generally only use ghci for prototyping and not when in the middle of proper development? Or do you compile the package and load that into ghci? I'd like to know as I'm starting to work on patches for some hackage packages which have proper cabal builds etc., and want to follow the correct (and efficient!) convention. Thanks Tom
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners