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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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/
>
>
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
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
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
18 matches
Mail list logo
