Re: Loading GHC into GHCi (and ghcid)

[Michael Sloan]

Here is the diff adding ghci scripts and some related code changes:
https://phabricator.haskell.org/D4904

This has made development iterations drastically quicker for me, which
for me really lowers the friction to contribution.  All of my diffs in
the past week were developed by using ghc-in-ghci.

-Michael
On Wed, Jun 27, 2018 at 10:48 PM Michael Sloan  wrote:
>
> Wow!  This is an absolute game changer for me with regards to ghc
> development.  My usual workflow on large haskell projects is to use
> GHCI as much as possible for quick iterations.  I'm really glad
> Csongor figured this out and that you sent an email about it.
>
> I've been messing with this for a bit today, and after a few code
> changes, I can to load GHCI into GHCI!!  For example, I can modify
> "ghciWelcomeMessage", reload, and enter into the nested ghci:
>
> λ :r
> [491 of 492] Compiling GHCi.UI  ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o )
> Ok, 492 modules loaded.
> λ :main -ignore-dot-ghci --interactive
> GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/  :? for help
> Prelude> unwords ["it", "works!"]
> "it works!"
> Prelude> :q
> Leaving GHCi.
> λ Prelude.unwords ["now,", "in", "outer", "GHCi"]
> "now, in outer GHCi"
>
> I will be opening up a PR soon that makes this convenient, once I've
> polished it up.
>
> -Michael
> On Wed, May 30, 2018 at 1:43 PM Matthew Pickering
>  wrote:
> >
> > Hi all,
> >
> > Csongor has informed me that he has worked out how to load GHC into
> > GHCi which can then be used with ghcid for a more interactive
> > development experience.
> >
> > 1. Put this .ghci file in compiler/
> >
> > https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
> >
> > 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> > from inside compiler/
> >
> > It may take a while and require a little bit of memory but in the end
> > all 500 or so modules will be loaded.
> >
> > It can also be used with ghcid.
> >
> > ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> >
> > Hopefully someone who has more RAM than I.
> >
> > Can anyone suggest the suitable place on the wiki for this information?
> >
> > Cheers,
> >
> > Matt
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Michael Sloan]

Wow!  This is an absolute game changer for me with regards to ghc
development.  My usual workflow on large haskell projects is to use
GHCI as much as possible for quick iterations.  I'm really glad
Csongor figured this out and that you sent an email about it.

I've been messing with this for a bit today, and after a few code
changes, I can to load GHCI into GHCI!!  For example, I can modify
"ghciWelcomeMessage", reload, and enter into the nested ghci:

λ :r
[491 of 492] Compiling GHCi.UI  ( ../ghc/GHCi/UI.hs, tmp/GHCi/UI.o )
Ok, 492 modules loaded.
λ :main -ignore-dot-ghci --interactive
GHCi inception, version 8.7.20180627: http://www.haskell.org/ghc/  :? for help
Prelude> unwords ["it", "works!"]
"it works!"
Prelude> :q
Leaving GHCi.
λ Prelude.unwords ["now,", "in", "outer", "GHCi"]
"now, in outer GHCi"

I will be opening up a PR soon that makes this convenient, once I've
polished it up.

-Michael
On Wed, May 30, 2018 at 1:43 PM Matthew Pickering
 wrote:
>
> Hi all,
>
> Csongor has informed me that he has worked out how to load GHC into
> GHCi which can then be used with ghcid for a more interactive
> development experience.
>
> 1. Put this .ghci file in compiler/
>
> https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
>
> 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> from inside compiler/
>
> It may take a while and require a little bit of memory but in the end
> all 500 or so modules will be loaded.
>
> It can also be used with ghcid.
>
> ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
>
> Hopefully someone who has more RAM than I.
>
> Can anyone suggest the suitable place on the wiki for this information?
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Ben Gamari]

Matthew Pickering  writes:

> I added the wiki page now: 
> https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci
>
> Do you mean just adding the .ghci file? It seems that this might be
> something that would be good to add to hadrian so that it can control
> the locations of the object files rather than splurging them over the
> build tree.
>
Just adding the .ghci file is a start. However, ideally it would be
something that will be more resistant to bitrotting that we might even
be able to test. For instance, a shell script or build system rule that
can generate the .ghci file from GHC's cabal file and launch ghc
--interactive.

We could then test this during CI as I think there is enough interest in
this workflow that we should really try to support it.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Matthew Pickering]

I added the wiki page now: https://ghc.haskell.org/trac/ghc/wiki/Building/InGhci

Do you mean just adding the .ghci file? It seems that this might be
something that would be good to add to hadrian so that it can control
the locations of the object files rather than splurging them over the
build tree.

Cheers,

Matt

On Fri, Jun 8, 2018 at 4:37 PM, Joachim Breitner
 wrote:
> Hi,
>
> Am Donnerstag, den 07.06.2018, 17:05 -0400 schrieb Ben Gamari:
>> How about on a new page (e.g. Building/InGhci) linked to from,
>>
>>  * https://ghc.haskell.org/trac/ghc/wiki/Building
>>  * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions (in the Tips
>>& Tricks section)
>>
>> It might also be a good idea to add a script to the tree capturing this
>> pattern.
>
> yes pretty please!
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   m...@joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Manuel M T Chakravarty]

> Am 09.06.2018 um 02:30 schrieb Evan Laforge :
> Currently -fdefer-type-errors is broken:
> https://ghc.haskell.org/trac/ghc/ticket/14963  This is not related to
> loading .o files, but ghci in general.

Which is a good indication that out CI story is still crap.

Cheers,
Manuel



signature.asc
Description: Message signed with OpenPGP
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Evan Laforge]

On Fri, Jun 8, 2018 at 11:46 AM, Simon Marlow  wrote:
> I'm slightly surprised that it keeps breaking for you, given that this is a
> core feature of GHCi and we have multiple tests for it.  You'll need to
> remind me - what were the bugs specifically? Maybe we need more tests.

Most recently, 8.2 had this problem:
https://ghc.haskell.org/trac/ghc/ticket/13604

I seem to recall an older version also had the same problem, in that
it was too sensitive about hash changes, but I think it was a plain
bug, unlike the ticket above which is arguable correct though
inconvenient.  I also remember requesting the "why did it reload"
message (e.g. flags changed, etc.), probably due to some earlier
change that made compiled modules not load.  It's been so long I
forget the details, sorry!

Currently -fdefer-type-errors is broken:
https://ghc.haskell.org/trac/ghc/ticket/14963  This is not related to
loading .o files, but ghci in general.

Also currently there's an issue where ghc uses modtime and then the
elaborate recompilation check to determine whether to recompile to
binary, but it seems ghci uses just the modtime check.  I think this
has always been there, but I'm only just noticing it recently because
of switching to git.  I don't completely understand what's going on
here yet so I may be misrepresenting the situation.

More tests would be welcome!  I guess we could compile some modules,
and ensure the binary continues to load after various kinds of poking
and prodding.  I'd be willing to contribute tests that represent my
workflow.

> There really are fundamental differences in how the compiler treats these
> two methods though, and I don't see an easy way to reconcile them. Loading
> object files happens as part of the compilation manager that manages the
> compilations for all the modules in the current package, whereas packages
> are assumed to be pre-compiled and are linked on-demand after all the
> compilation is done.

Ah, too bad.  But just out of curiosity, is there anything about the
OS level linking that's fundamentally different than ghci loading
individual .o files, or is this more a result of how ghc and ghci have
evolved?  I know you did some work to unload object files, could the
same thing be used to unload and reload packages dynamically?  Even if
it were manual, it could be a big improvement over having to shut down
and restart the whole system because a package changed.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Simon Marlow]

On 8 June 2018 at 19:18, Evan Laforge  wrote:

> On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow  wrote:
> > heap profiler for a while. However, I imagine at some point loading
> > everything into GHCi will become unsustainable and we'll have to explore
> > other strategies. There are a couple of options here:
> > - pre-compile modules so that GHCi is loading the .o instead of
> interpreted
> > code
>
> This is what I do, which is why I was complaining about GHC tending to
> break it.  But when it's working, it works well, I load 500+ modules
> in under a second.
>
> > - move some of the code into pre-compiled packages, as you mentioned
>
> I was wondering about the tradeoffs between these two approaches,
> compiled modules vs. packages. Compiled modules have the advantage
> that you can reload without restarting ghci and relinking a large
> library, but no one seems to notice when they break.  Whereas if ghc
> broke package loading it would get noticed right away.  Could they be
> unified so that, say, -package xyz is equivalent to adding the package
> root (with all the .hi and .o files) to the -i list?  I guess the low
> level loading mechanism of loading a .so vs. a bunch of individual .o
> files is different.
>

I'm slightly surprised that it keeps breaking for you, given that this is a
core feature of GHCi and we have multiple tests for it.  You'll need to
remind me - what were the bugs specifically? Maybe we need more tests.

There really are fundamental differences in how the compiler treats these
two methods though, and I don't see an easy way to reconcile them. Loading
object files happens as part of the compilation manager that manages the
compilations for all the modules in the current package, whereas packages
are assumed to be pre-compiled and are linked on-demand after all the
compilation is done.

Cheers
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Evan Laforge]

On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow  wrote:
> heap profiler for a while. However, I imagine at some point loading
> everything into GHCi will become unsustainable and we'll have to explore
> other strategies. There are a couple of options here:
> - pre-compile modules so that GHCi is loading the .o instead of interpreted
> code

This is what I do, which is why I was complaining about GHC tending to
break it.  But when it's working, it works well, I load 500+ modules
in under a second.

> - move some of the code into pre-compiled packages, as you mentioned

I was wondering about the tradeoffs between these two approaches,
compiled modules vs. packages. Compiled modules have the advantage
that you can reload without restarting ghci and relinking a large
library, but no one seems to notice when they break.  Whereas if ghc
broke package loading it would get noticed right away.  Could they be
unified so that, say, -package xyz is equivalent to adding the package
root (with all the .hi and .o files) to the -i list?  I guess the low
level loading mechanism of loading a .so vs. a bunch of individual .o
files is different.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Joachim Breitner]

Hi,

Am Donnerstag, den 07.06.2018, 17:05 -0400 schrieb Ben Gamari:
> How about on a new page (e.g. Building/InGhci) linked to from,
> 
>  * https://ghc.haskell.org/trac/ghc/wiki/Building
>  * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions (in the Tips
>& Tricks section)
> 
> It might also be a good idea to add a script to the tree capturing this
> pattern.

yes pretty please!

Cheers,
Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Simon Marlow]

On 7 June 2018 at 22:25, Evan Laforge  wrote:

> On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow  wrote:
> > For loading large amounts of code into GHCi, you want to add -j +RTS
> > -A128m where  is the number of cores on your machine. We've found that
> > parallel compilation works really well in GHCi provided you use a nice
> large
> > allocation area for the GC. This dramatically speeds up working with
> large
> > numbers of modules in GHCi. (500 is small!)
>
> This is a bit of a thread hijack (feel free to change the subject),
> but I also have a workflow that involves loading a lot of modules in
> ghci (500-700).  As long as I can coax ghci to load them, things are
> fast and work well, but my impression is that this isn't a common
> workflow, and specifically ghc developers don't do this, because just
> about every ghc release will break it in one way or another (e.g. by
> putting more flags in the recompile check hash), and no one seems to
> understand what I'm talking about when I suggest features to improve
> it (e.g. the recent msg about modtime and recompilation avoidance).
>
> Given the uphill battle, I've been thinking that linking most of those
> modules into a package and loading much fewer will be a better
> supported workflow.  It's actually less convenient, because now it's
> divided between package level (which require a restart and relink if
> they change) and ghci level (which don't), but is maybe less likely to
> be broken by ghc changes.  Also, all those loaded module consume a
> huge amount of memory, which I haven't tracked down yet, but maybe
> packages will load more efficiently.
>
> But ideally I would prefer to continue to not use packages, and in
> fact do per-module more aggressively for larger codebases, because the
> need to restart ghci (or the ghc API-using program) and do a lengthy
> relink every time a module in the "wrong place" changed seems like it
> could get annoying (in fact it already is, for a cabal-oriented
> workflow).
>
> Does the workflow at Facebook involve loading tons of individual
> modules as I do?


Yes, our workflow involves loading a large number of modules into GHCi.
However, we have run into memory issues, which was the reason for the
recent work on fixing this space leak: https://phabricator.haskell.org/D4659

As it is, this workflow is OK thanks to Bartosz' work on speedups for large
numbers of modules, tweaking the RTS flags as I mentioned and some other
fixes we've made in GHCi to avoid performance issues. (all of this is
upstream, incidentally).  There is probably low-hanging fruit to be had in
reducing the memory usage of GHCi, nobody has really attacked this with the
heap profiler for a while. However, I imagine at some point loading
everything into GHCi will become unsustainable and we'll have to explore
other strategies. There are a couple of options here:
- pre-compile modules so that GHCi is loading the .o instead of interpreted
code
- move some of the code into pre-compiled packages, as you mentioned

Cheers
Simon


>
> Or do they get packed into packages?  If it's the
> many modules, do you have recommendations making that work well and
> keeping it working?  If packages are the way you're "supposed" to do
> things, then is there any idea about how hard it would be to reload
> packages at runtime?  If both modules and packages can be reloaded, is
> there an intended conceptual difference between a package and an
> unpackaged collection of modules?  To illustrate, I would put packages
> purely as a way to organize builds and distribution, and have no
> meaning at the compiler level, which is how I gather C compilers
> traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o
> b.o c.o; cc abc.a').  But that's clearly not how ghc sees it!
>
>
> thanks!
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Simon Marlow]

On 8 June 2018 at 00:33, Evan Laforge  wrote:

> On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka  wrote:
> > What version of GHC are you using?
> > There have been some significant improvements like
> > https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b
> 8d5ab35afb828f,
> > that only just made it into GHC 8.4.
>
> I did in fact notice a very nice speedup in 8.4, this explains it.
> Finally I know who to thank for it!  Thank you very much for that fix,
> it really makes a difference.
>
> Are there more goodies in the 8.0.2 facebook branch, or have they all
> made it into 8.4?
>
> As loaded modules seem to consume a lot of memory, I've considered
> trying GHC.Compact on them, but haven't looked into what that would
> entail.  Have you considered something like that?
>

I think I looked into this and found that it wasn't going to be easy, but I
forget exactly why. Off the top of my head:
- you can't compact mutable things: perhaps the FastString table would give
us problems here
- there is lots of deliberate laziness to support demand-loading of
interface files, compaction would force all of it
- you can't compact functions, so if there are any functions in ModIface or
ModDetails we would have to avoid compacting those parts of the structure
somehow
- there are cycles and sharing in these structures so we would need to use
the more expensive compaction method that keeps a hash table, which is 10x
slower than cheap compaction

Probably worth looking into to find out exactly what the problems are
though.

Cheers
Simon





> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Evan Laforge]

On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka  wrote:
> What version of GHC are you using?
> There have been some significant improvements like
> https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b8d5ab35afb828f,
> that only just made it into GHC 8.4.

I did in fact notice a very nice speedup in 8.4, this explains it.
Finally I know who to thank for it!  Thank you very much for that fix,
it really makes a difference.

Are there more goodies in the 8.0.2 facebook branch, or have they all
made it into 8.4?

As loaded modules seem to consume a lot of memory, I've considered
trying GHC.Compact on them, but haven't looked into what that would
entail.  Have you considered something like that?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Bartosz Nitka]

What version of GHC are you using?
There have been some significant improvements like
https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b8d5ab35afb828f,
that only just made it into GHC 8.4.
Some of them maybe haven't made it into a release yet.
You could try building
https://github.com/niteria/ghc/commits/ghc-8.0.2-facebook and see how
well it works for you.

Cheers,
Bartosz
czw., 7 cze 2018 o 23:26 Evan Laforge  napisał(a):
>
> On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow  wrote:
> > For loading large amounts of code into GHCi, you want to add -j +RTS
> > -A128m where  is the number of cores on your machine. We've found that
> > parallel compilation works really well in GHCi provided you use a nice large
> > allocation area for the GC. This dramatically speeds up working with large
> > numbers of modules in GHCi. (500 is small!)
>
> This is a bit of a thread hijack (feel free to change the subject),
> but I also have a workflow that involves loading a lot of modules in
> ghci (500-700).  As long as I can coax ghci to load them, things are
> fast and work well, but my impression is that this isn't a common
> workflow, and specifically ghc developers don't do this, because just
> about every ghc release will break it in one way or another (e.g. by
> putting more flags in the recompile check hash), and no one seems to
> understand what I'm talking about when I suggest features to improve
> it (e.g. the recent msg about modtime and recompilation avoidance).
>
> Given the uphill battle, I've been thinking that linking most of those
> modules into a package and loading much fewer will be a better
> supported workflow.  It's actually less convenient, because now it's
> divided between package level (which require a restart and relink if
> they change) and ghci level (which don't), but is maybe less likely to
> be broken by ghc changes.  Also, all those loaded module consume a
> huge amount of memory, which I haven't tracked down yet, but maybe
> packages will load more efficiently.
>
> But ideally I would prefer to continue to not use packages, and in
> fact do per-module more aggressively for larger codebases, because the
> need to restart ghci (or the ghc API-using program) and do a lengthy
> relink every time a module in the "wrong place" changed seems like it
> could get annoying (in fact it already is, for a cabal-oriented
> workflow).
>
> Does the workflow at Facebook involve loading tons of individual
> modules as I do?  Or do they get packed into packages?  If it's the
> many modules, do you have recommendations making that work well and
> keeping it working?  If packages are the way you're "supposed" to do
> things, then is there any idea about how hard it would be to reload
> packages at runtime?  If both modules and packages can be reloaded, is
> there an intended conceptual difference between a package and an
> unpackaged collection of modules?  To illustrate, I would put packages
> purely as a way to organize builds and distribution, and have no
> meaning at the compiler level, which is how I gather C compilers
> traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o
> b.o c.o; cc abc.a').  But that's clearly not how ghc sees it!
>
>
> thanks!
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Evan Laforge]

On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow  wrote:
> For loading large amounts of code into GHCi, you want to add -j +RTS
> -A128m where  is the number of cores on your machine. We've found that
> parallel compilation works really well in GHCi provided you use a nice large
> allocation area for the GC. This dramatically speeds up working with large
> numbers of modules in GHCi. (500 is small!)

This is a bit of a thread hijack (feel free to change the subject),
but I also have a workflow that involves loading a lot of modules in
ghci (500-700).  As long as I can coax ghci to load them, things are
fast and work well, but my impression is that this isn't a common
workflow, and specifically ghc developers don't do this, because just
about every ghc release will break it in one way or another (e.g. by
putting more flags in the recompile check hash), and no one seems to
understand what I'm talking about when I suggest features to improve
it (e.g. the recent msg about modtime and recompilation avoidance).

Given the uphill battle, I've been thinking that linking most of those
modules into a package and loading much fewer will be a better
supported workflow.  It's actually less convenient, because now it's
divided between package level (which require a restart and relink if
they change) and ghci level (which don't), but is maybe less likely to
be broken by ghc changes.  Also, all those loaded module consume a
huge amount of memory, which I haven't tracked down yet, but maybe
packages will load more efficiently.

But ideally I would prefer to continue to not use packages, and in
fact do per-module more aggressively for larger codebases, because the
need to restart ghci (or the ghc API-using program) and do a lengthy
relink every time a module in the "wrong place" changed seems like it
could get annoying (in fact it already is, for a cabal-oriented
workflow).

Does the workflow at Facebook involve loading tons of individual
modules as I do?  Or do they get packed into packages?  If it's the
many modules, do you have recommendations making that work well and
keeping it working?  If packages are the way you're "supposed" to do
things, then is there any idea about how hard it would be to reload
packages at runtime?  If both modules and packages can be reloaded, is
there an intended conceptual difference between a package and an
unpackaged collection of modules?  To illustrate, I would put packages
purely as a way to organize builds and distribution, and have no
meaning at the compiler level, which is how I gather C compilers
traditionally work (e.g. 'cc a.o b.o c.o' is the same as 'ar abc.a a.o
b.o c.o; cc abc.a').  But that's clearly not how ghc sees it!


thanks!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Ben Gamari]

Matthew Pickering  writes:

> Hi all,
>
> Csongor has informed me that he has worked out how to load GHC into
> GHCi which can then be used with ghcid for a more interactive
> development experience.
>
> 1. Put this .ghci file in compiler/
>
> https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
>
> 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> from inside compiler/
>
> It may take a while and require a little bit of memory but in the end
> all 500 or so modules will be loaded.
>
> It can also be used with ghcid.
>
> ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
>
> Hopefully someone who has more RAM than I.
>
> Can anyone suggest the suitable place on the wiki for this information?
>
How about on a new page (e.g. Building/InGhci) linked to from,

 * https://ghc.haskell.org/trac/ghc/wiki/Building
 * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions (in the Tips
   & Tricks section)

It might also be a good idea to add a script to the tree capturing this
pattern.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Csongor Kiss]

Indeed, it's a lot faster with these flags, thanks for the tip!

Best,
Csongor

> On 7 Jun 2018, at 16:47, Simon Marlow  wrote:
> 
> For loading large amounts of code into GHCi, you want to add -j +RTS 
> -A128m where  is the number of cores on your machine. We've found that 
> parallel compilation works really well in GHCi provided you use a nice large 
> allocation area for the GC. This dramatically speeds up working with large 
> numbers of modules in GHCi. (500 is small!)
> 
> Cheers
> Simon
> 
> On 30 May 2018 at 21:43, Matthew Pickering  > wrote:
> Hi all,
> 
> Csongor has informed me that he has worked out how to load GHC into
> GHCi which can then be used with ghcid for a more interactive
> development experience.
> 
> 1. Put this .ghci file in compiler/
> 
> https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c 
> 
> 
> 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> from inside compiler/
> 
> It may take a while and require a little bit of memory but in the end
> all 500 or so modules will be loaded.
> 
> It can also be used with ghcid.
> 
> ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> 
> Hopefully someone who has more RAM than I.
> 
> Can anyone suggest the suitable place on the wiki for this information?
> 
> Cheers,
> 
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading GHC into GHCi (and ghcid)

[Simon Marlow]

For loading large amounts of code into GHCi, you want to add -j +RTS
-A128m where  is the number of cores on your machine. We've found that
parallel compilation works really well in GHCi provided you use a nice
large allocation area for the GC. This dramatically speeds up working with
large numbers of modules in GHCi. (500 is small!)

Cheers
Simon

On 30 May 2018 at 21:43, Matthew Pickering 
wrote:

> Hi all,
>
> Csongor has informed me that he has worked out how to load GHC into
> GHCi which can then be used with ghcid for a more interactive
> development experience.
>
> 1. Put this .ghci file in compiler/
>
> https://gist.github.com/mpickering/73749e7783f40cc762fec171b879704c
>
> 2. Run "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
> from inside compiler/
>
> It may take a while and require a little bit of memory but in the end
> all 500 or so modules will be loaded.
>
> It can also be used with ghcid.
>
> ghcid -c "../inplace/bin/ghc-stage2 --interactive -odir tmp -hidir tmp"
>
> Hopefully someone who has more RAM than I.
>
> Can anyone suggest the suitable place on the wiki for this information?
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs