Loading GHC into GHCi (and ghcid)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading GHC into GHCi (and ghcid)

Matthew Pickering
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Simon Marlow-7
For loading large amounts of code into GHCi, you want to add -j<n> +RTS -A128m where <n> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

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

Best,
Csongor

On 7 Jun 2018, at 16:47, Simon Marlow <[hidden email]> wrote:

For loading large amounts of code into GHCi, you want to add -j<n> +RTS -A128m where <n> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Ben Gamari-2
In reply to this post by Matthew Pickering
Matthew Pickering <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Evan Laforge
In reply to this post by Simon Marlow-7
On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow <[hidden email]> wrote:
> For loading large amounts of code into GHCi, you want to add -j<n> +RTS
> -A128m where <n> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> napisał(a):

>
> On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow <[hidden email]> wrote:
> > For loading large amounts of code into GHCi, you want to add -j<n> +RTS
> > -A128m where <n> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Evan Laforge
On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Simon Marlow-7
On 8 June 2018 at 00:33, Evan Laforge <[hidden email]> wrote:
On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka <[hidden email]> 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?

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Simon Marlow-7
In reply to this post by Evan Laforge
On 7 June 2018 at 22:25, Evan Laforge <[hidden email]> wrote:
On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow <[hidden email]> wrote:
> For loading large amounts of code into GHCi, you want to add -j<n> +RTS
> -A128m where <n> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Joachim Breitner-2
In reply to this post by Ben Gamari-2
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
  [hidden email]
  http://www.joachim-breitner.de/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Evan Laforge
In reply to this post by Simon Marlow-7
On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Simon Marlow-7
On 8 June 2018 at 19:18, Evan Laforge <[hidden email]> wrote:
On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Evan Laforge
On Fri, Jun 8, 2018 at 11:46 AM, Simon Marlow <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Manuel M T Chakravarty-4
> Am 09.06.2018 um 02:30 schrieb Evan Laforge <[hidden email]>:
> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Matthew Pickering
In reply to this post by Joachim Breitner-2
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
<[hidden email]> 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
>   [hidden email]
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Ben Gamari-2
Matthew Pickering <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Loading GHC into GHCi (and ghcid)

Michael Sloan
In reply to this post by Matthew Pickering
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
<[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
> <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs