Elliot,

One slight concern I've been running into recently is the memory usage of ghc-modi. I've been on a rampage over the last few days trying to keep the Chart library from OOMing on my laptop, and this generally involves killing one or more ghc-modi instances with 1GB+ of resident memory. If anyone else can confirm this is an issue (and it isn't already a known issue/necessary evil), I'd be happy to file an issue on Github and do some preliminary work as to why this is happening.

Please record this space leak to a github issue. You are the second person who are taking about this. Though I have not experienced such a space leak, it must exit in some cases. Let's try to fix it. --Kazu

Please see https://github.com/kazu-yamamoto/ghc-mod/issues/243 for the current status of this issue. --- Elliot Robinson Phone: (321) 252-9660 Site: www.argiopetech.com Email: elliot.robinson@argiopetech.com PGP Fingerprint: 0xD1E72E6A9D0610FFBBF838A6FFB5205A9FEDE59A On Tue, May 20, 2014 at 9:19 PM, Andreas Abel wrote:

Oh, yes, tried M-x ghc-check-syntax on a 3 line program, and ghc-modi took 700m of resident memory.

On 02.05.2014 14:17, Kazu Yamamoto (山本和彦) wrote:

...

Elliot,

One slight concern I've been running into recently is the memory usage of

...

ghc-modi. I've been on a rampage over the last few days trying to keep the Chart library from OOMing on my laptop, and this generally involves killing one or more ghc-modi instances with 1GB+ of resident memory. If anyone else can confirm this is an issue (and it isn't already a known issue/necessary evil), I'd be happy to file an issue on Github and do some preliminary work as to why this is happening.

Please record this space leak to a github issue. You are the second person who are taking about this. Though I have not experienced such a space leak, it must exit in some cases. Let's try to fix it.

--Kazu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Bardur, in such situations I use a shared sandbox instead of the "add-source". execute `cabal sandbox init --sandbox=../.shared-cabal-sandbox in each project and build A, B, C, D. Does it help with ghc-mod? Michal On Sat, May 17, 2014 at 2:18 PM, Bardur Arantsson wrote:

On 2014-05-01 04:58, Kazu Yamamoto (山本和彦) wrote:

...

Hello guys,

I have released ghc-mod version 4.1.0. In this version, ghc-modi provides "info" and "type" commands. This means that you can display types and information of expressions very quickly on Emacs.

http://hackage.haskell.org/package/ghc-mod

Thanks to GHC's -fdefer-type-errors, "type" and "info" can work even if the file contains type errors. Yay! Of course, you can make use of GHC's hole. For more information, please read the "Types" subsection of the following page:

http://mew.org/~kazu/proj/ghc-mod/en/emacs.html

Enjoy!

Hi,

I've been trying this thing out (including the Emacs integration) and it's working pretty well so far, but I've run into a limitation that's a bit frustrating.

I have a multi-project setup sort of like the following:

project/ A/ B/ (depends on A) C/ (depends on A) D/ (depends on B + C)

(where D is an executable "example" project)

To compile everything I've created a sandbox for the D project in project/D/ and run all my cabal commands from there. I've added A, B, and C via the "add-source" sandbox feature.

If I edit a file in the D project, ghc-mod works beautifully, but if I edit anything in A, B, or C ghc-mod (understandably) cannot find the sandbox and complains about various packages (that A, B or C depend on) not being installed.

It there some way to make this work?

Would it help to actually create the sandbox in the project's main directory (A, B, C, D are subdirectories) and then add them all as source?

Any help/guidance in getting this to work would be appreciated.

Regards,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 17/05/14 20:18, Bardur Arantsson wrote:

I've been trying this thing out (including the Emacs integration) and it's working pretty well so far, but I've run into a limitation that's a bit frustrating.

I have a multi-project setup sort of like the following:

project/ A/ B/ (depends on A) C/ (depends on A) D/ (depends on B + C)

(where D is an executable "example" project)

To compile everything I've created a sandbox for the D project in project/D/ and run all my cabal commands from there. I've added A, B, and C via the "add-source" sandbox feature.

Does it work if you create a sandbox in each of the directories A, B, C, and D? My thinking is that if you are adding the directories A, B, and C using "cabal sandbox add-source" then they should be able to be built independently. And of course you'd have to run cabal sandbox add-source /path/to/project/A # in directory B cabal sandbox add-source /path/to/project/A # in directory C cabal sandbox add-source /path/to/project/B # in directory D cabal sandbox add-source /path/to/project/C # in directory D to get the dependencies. I've tried this out with a test project and it seems to work ok. Also "cabal repl" works in each of the subdirectories. -- Carlo Hamalainen http://carlo-hamalainen.net