Re: Hadrian questions
`make 2` should be somewhat equivalent to `./hadrian/build.sh _build/stage1/bin/ghc` I think. The problem is with the devel2 flavour itself. Tracked by https://ghc.haskell.org/trac/ghc/ticket/16210 The `hadrian/build.sh` script uses `cabal new-build` so the dependencies should be shared already when possible. Cheers, Matt On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg wrote: > > In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do > this with devel2, and I'd prefer Hadrian didn't, too. > > Maybe I'm not really on the devel2 flavor? > > > On Jan 24, 2019, at 11:02 PM, Richard Eisenberg > > wrote: > > > > As suggested, I'm trying out Hadrian. I have a few questions. > > > > - After building GHC the first time, I often go into the /ghc directory and > > then do `make 2` to build just the stage-2 compiler. Is that now the same > > as `build --freeze1`? It would seem not (I haven't tested), because running > > `make 2` builds only the compiler, not the libraries. Can this workflow be > > replicated in Hadrian? > > > > - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs > > file. But I see build artifacts during compilation of stage-2 that have > > dyn_o and p_o extensions. I don't want these. Have I done something wrong? > > Or are these artifacts now necessary? > > > > - I have quite a few ghc directories. What are the dependencies of Hadrian > > so that I can install these into my global package database and avoiding > > rebuilding them for each ghc tree? (Please don't tell me that the global > > package database is bad for my health. I know that, and I know why, but > > it's still terribly convenient, and I'm happy to pay the occasional price > > for that convenience.) > > > > I'm sure I'll have more questions. > > > > Thanks! > > Richard > > ___ > > 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Hadrian questions
Worth noting that Hadrian additionally defines a set of so-called phony targets for packages and executables, so `./hadrian/build.sh --freeze1 build/stage1/bin/ghc` can also be expressed independently from your build root as `./hadrian/build.sh --freeze1 stage2:exe:ghc-bin`. Alec > On Jan 25, 2019, at 12:22 AM, Matthew Pickering > wrote: > > `make 2` should be somewhat equivalent to `./hadrian/build.sh > _build/stage1/bin/ghc` I think. > > The problem is with the devel2 flavour itself. Tracked by > https://ghc.haskell.org/trac/ghc/ticket/16210 > > The `hadrian/build.sh` script uses `cabal new-build` so the > dependencies should be shared already when possible. > > Cheers, > > Matt > > On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg > wrote: >> >> In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do >> this with devel2, and I'd prefer Hadrian didn't, too. >> >> Maybe I'm not really on the devel2 flavor? >> >>> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg >>> wrote: >>> >>> As suggested, I'm trying out Hadrian. I have a few questions. >>> >>> - After building GHC the first time, I often go into the /ghc directory and >>> then do `make 2` to build just the stage-2 compiler. Is that now the same >>> as `build --freeze1`? It would seem not (I haven't tested), because running >>> `make 2` builds only the compiler, not the libraries. Can this workflow be >>> replicated in Hadrian? >>> >>> - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs >>> file. But I see build artifacts during compilation of stage-2 that have >>> dyn_o and p_o extensions. I don't want these. Have I done something wrong? >>> Or are these artifacts now necessary? >>> >>> - I have quite a few ghc directories. What are the dependencies of Hadrian >>> so that I can install these into my global package database and avoiding >>> rebuilding them for each ghc tree? (Please don't tell me that the global >>> package database is bad for my health. I know that, and I know why, but >>> it's still terribly convenient, and I'm happy to pay the occasional price >>> for that convenience.) >>> >>> I'm sure I'll have more questions. >>> >>> Thanks! >>> Richard >>> ___ >>> 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 > ___ > 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: Why are nested brackets disallowed?
I don't think that cross stage persistence will work as it is currently implemented which is probably why the check exists. 1. The normal case foo x = [| x |] ===> foo x = [| $(lift x) |] 2. x is defined at stage 0, and used at stage 2. One option is: foo x = [| [| x |] |] ===> foo x = [| [| $($(lift (lift x))) |] |] or foo x = [| [| x |] |] ===> foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |] We need to think a bit how to `lift` something of type `Q Exp` because of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT (I tested and this works after deriving 40 instances). You can define `lift2` which lifts an expression twice as follows. ``` lift2 :: Lift a => a -> Q Exp lift2 a = lift a >>= \e -> [| return $ $(lift e) |] ``` 3. x is defined at stage 1 and used in stage 2 foo = [| \x -> [| x |] |] ===> foo = [| \x -> [| $(lift x) |] |] Desugared with a single call to `lift` like normal. 4. x is defined in stage 2 and used in stage 1 foo = [| [| \x -> $(x) |] |] Rejected just like usual. `x` won't be bound when the splice is run. It seems that with some suitable care that things will work out when lifting across multiple levels but that is the point where care needs to be taken. Matt On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg wrote: > > I think Geoff was primarily concerned with typed Template Haskell, not the > untyped variety. > > I, too, have wondered if there was a technical reason behind this > restriction, or if merely it was assumed that nested brackets were not > worthwhile. > > One question: how would staging work between nesting levels of brackets? > > Richard > > > On Jan 24, 2019, at 12:42 PM, Ben Gamari wrote: > > > > Matthew Pickering writes: > > > >> There is a check in `RnSplice` which errors on the following program > >> with nested brackets. > >> > > It might be good to explicitly include Geoff Mainland in this thread. > > I'm not sure he'll see it otherwise. > > > > Cheers, > > > > - Ben > > > > ___ > > 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: Why are nested brackets disallowed?
Interesting. I don’t recall a specific reason why nested brackets were outlawed. I think it was just that we didn't think we needed them, so it seemed simplest not to have them. TH does not do runtime codegen, so there are really only two stages: compile time and run time. Do you have a compelling use-case? Simon | -Original Message- | From: ghc-devs On Behalf Of Matthew | Pickering | Sent: 25 January 2019 11:57 | To: Richard Eisenberg | Cc: GHC developers | Subject: Re: Why are nested brackets disallowed? | | I don't think that cross stage persistence will work as it is currently | implemented which is probably why the check exists. | | 1. The normal case | | foo x = [| x |] ===> |foo x = [| $(lift x) |] | | 2. x is defined at stage 0, and used at stage 2. | | One option is: | foo x = [| [| x |] |] ===> |foo x = [| [| $($(lift (lift x))) |] |] or foo x = [| [| x |] |] ===> |foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |] | | We need to think a bit how to `lift` something of type `Q Exp` because of | the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT (I | tested and this works after deriving 40 instances). | | You can define `lift2` which lifts an expression twice as follows. | | ``` | lift2 :: Lift a => a -> Q Exp | lift2 a = lift a >>= \e -> [| return $ $(lift e) |] ``` | | 3. x is defined at stage 1 and used in stage 2 | | foo = [| \x -> [| x |] |] ===> |foo = [| \x -> [| $(lift x) |] |] | | Desugared with a single call to `lift` like normal. | | 4. x is defined in stage 2 and used in stage 1 | | foo = [| [| \x -> $(x) |] |] | | Rejected just like usual. `x` won't be bound when the splice is run. | | It seems that with some suitable care that things will work out when | lifting across multiple levels but that is the point where care needs to | be taken. | | Matt | | | | On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg | wrote: | > | > I think Geoff was primarily concerned with typed Template Haskell, not | the untyped variety. | > | > I, too, have wondered if there was a technical reason behind this | restriction, or if merely it was assumed that nested brackets were not | worthwhile. | > | > One question: how would staging work between nesting levels of | brackets? | > | > Richard | > | > > On Jan 24, 2019, at 12:42 PM, Ben Gamari | wrote: | > > | > > Matthew Pickering writes: | > > | > >> There is a check in `RnSplice` which errors on the following | > >> program with nested brackets. | > >> | > > It might be good to explicitly include Geoff Mainland in this thread. | > > I'm not sure he'll see it otherwise. | > > | > > Cheers, | > > | > > - Ben | > > | > > ___ | > > ghc-devs mailing list | > > ghc-devs@haskell.org | > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai | > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02% | > > 7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d682bc3d4b%7C | > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830&sd | > > ata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&reserved=0 | > | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d | 682bc3d4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830 | &sdata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&reserved= | 0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why are nested brackets disallowed?
This typechecks: instance Lift a => Lift (Q a) where lift :: Q a -> Q Exp lift x = join (fmap lift x) And it looks correct. Do you agree? In general, it sounds like you've thought this through. To me, this doesn't rise to the need of a ghc-proposal; I would say to go for it. Richard > On Jan 25, 2019, at 6:56 AM, Matthew Pickering > wrote: > > I don't think that cross stage persistence will work as it is > currently implemented which is probably why the check exists. > > 1. The normal case > > foo x = [| x |] ===> > foo x = [| $(lift x) |] > > 2. x is defined at stage 0, and used at stage 2. > > One option is: > foo x = [| [| x |] |] ===> > foo x = [| [| $($(lift (lift x))) |] |] > or > foo x = [| [| x |] |] ===> > foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |] > > We need to think a bit how to `lift` something of type `Q Exp` because > of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT > (I tested and this works after deriving 40 instances). > > You can define `lift2` which lifts an expression twice as follows. > > ``` > lift2 :: Lift a => a -> Q Exp > lift2 a = lift a >>= \e -> [| return $ $(lift e) |] > ``` > > 3. x is defined at stage 1 and used in stage 2 > > foo = [| \x -> [| x |] |] ===> > foo = [| \x -> [| $(lift x) |] |] > > Desugared with a single call to `lift` like normal. > > 4. x is defined in stage 2 and used in stage 1 > > foo = [| [| \x -> $(x) |] |] > > Rejected just like usual. `x` won't be bound when the splice is run. > > It seems that with some suitable care that things will work out when > lifting across multiple levels but that is the point where care needs > to be taken. > > Matt > > > > On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg > wrote: >> >> I think Geoff was primarily concerned with typed Template Haskell, not the >> untyped variety. >> >> I, too, have wondered if there was a technical reason behind this >> restriction, or if merely it was assumed that nested brackets were not >> worthwhile. >> >> One question: how would staging work between nesting levels of brackets? >> >> Richard >> >>> On Jan 24, 2019, at 12:42 PM, Ben Gamari wrote: >>> >>> Matthew Pickering writes: >>> There is a check in `RnSplice` which errors on the following program with nested brackets. >>> It might be good to explicitly include Geoff Mainland in this thread. >>> I'm not sure he'll see it otherwise. >>> >>> Cheers, >>> >>> - Ben >>> >>> ___ >>> 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
Marge: "CI is taking too long"
Marge has complained that https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long. And indeed it seems stuck. Help? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why are nested brackets disallowed?
It's possible to have multiple compile time phases (as evidenced by the possibility of multiple splices). Metaocaml supports k phases so we should as well! Fwiw, It is also possible to implement run-time code generation, see https://github.com/mainland/th-new http://johnlato.blogspot.com/2012/10/runtime-meta-programming-in-haskell.html On Fri, Jan 25, 2019 at 12:49 PM Simon Peyton Jones wrote: > > Interesting. I don’t recall a specific reason why nested brackets were > outlawed. I think it was just that we didn't think we needed them, so it > seemed simplest not to have them. TH does not do runtime codegen, so there > are really only two stages: compile time and run time. > > Do you have a compelling use-case? > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Matthew > | Pickering > | Sent: 25 January 2019 11:57 > | To: Richard Eisenberg > | Cc: GHC developers > | Subject: Re: Why are nested brackets disallowed? > | > | I don't think that cross stage persistence will work as it is currently > | implemented which is probably why the check exists. > | > | 1. The normal case > | > | foo x = [| x |] ===> > |foo x = [| $(lift x) |] > | > | 2. x is defined at stage 0, and used at stage 2. > | > | One option is: > | foo x = [| [| x |] |] ===> > |foo x = [| [| $($(lift (lift x))) |] |] or foo x = [| [| x |] |] ===> > |foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |] > | > | We need to think a bit how to `lift` something of type `Q Exp` because of > | the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT (I > | tested and this works after deriving 40 instances). > | > | You can define `lift2` which lifts an expression twice as follows. > | > | ``` > | lift2 :: Lift a => a -> Q Exp > | lift2 a = lift a >>= \e -> [| return $ $(lift e) |] ``` > | > | 3. x is defined at stage 1 and used in stage 2 > | > | foo = [| \x -> [| x |] |] ===> > |foo = [| \x -> [| $(lift x) |] |] > | > | Desugared with a single call to `lift` like normal. > | > | 4. x is defined in stage 2 and used in stage 1 > | > | foo = [| [| \x -> $(x) |] |] > | > | Rejected just like usual. `x` won't be bound when the splice is run. > | > | It seems that with some suitable care that things will work out when > | lifting across multiple levels but that is the point where care needs to > | be taken. > | > | Matt > | > | > | > | On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg > | wrote: > | > > | > I think Geoff was primarily concerned with typed Template Haskell, not > | the untyped variety. > | > > | > I, too, have wondered if there was a technical reason behind this > | restriction, or if merely it was assumed that nested brackets were not > | worthwhile. > | > > | > One question: how would staging work between nesting levels of > | brackets? > | > > | > Richard > | > > | > > On Jan 24, 2019, at 12:42 PM, Ben Gamari > | wrote: > | > > > | > > Matthew Pickering writes: > | > > > | > >> There is a check in `RnSplice` which errors on the following > | > >> program with nested brackets. > | > >> > | > > It might be good to explicitly include Geoff Mainland in this thread. > | > > I'm not sure he'll see it otherwise. > | > > > | > > Cheers, > | > > > | > > - Ben > | > > > | > > ___ > | > > ghc-devs mailing list > | > > ghc-devs@haskell.org > | > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai > | > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02% > | > > 7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d682bc3d4b%7C > | > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830&sd > | > > ata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&reserved=0 > | > > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cdf0aa539bb1041dca42308d > | 682bc3d4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636840142327169830 > | &sdata=oIiA768uqGGGBJh7ogpymmPvuKBDLj%2BiqJCZpig6SPg%3D&reserved= > | 0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why are nested brackets disallowed?
That definition typechecks but doesn't do what you intend I think. If you `lift (lift Bool)` then result of splicing this is of type `Exp` and not `Q Exp` as you intended so you can't splice it again. That is why my definition is more complicated and involves `return`. Cheers, Matt On Fri, Jan 25, 2019 at 12:50 PM Richard Eisenberg wrote: > > This typechecks: > > instance Lift a => Lift (Q a) where > lift :: Q a -> Q Exp > lift x = join (fmap lift x) > > And it looks correct. Do you agree? > > In general, it sounds like you've thought this through. To me, this doesn't > rise to the need of a ghc-proposal; I would say to go for it. > > Richard > > > On Jan 25, 2019, at 6:56 AM, Matthew Pickering > > wrote: > > > > I don't think that cross stage persistence will work as it is > > currently implemented which is probably why the check exists. > > > > 1. The normal case > > > > foo x = [| x |] ===> > > foo x = [| $(lift x) |] > > > > 2. x is defined at stage 0, and used at stage 2. > > > > One option is: > > foo x = [| [| x |] |] ===> > > foo x = [| [| $($(lift (lift x))) |] |] > > or > > foo x = [| [| x |] |] ===> > > foo x = [| let x' = $(lift x) in [| $(lift [| x' |]) |] > > > > We need to think a bit how to `lift` something of type `Q Exp` because > > of the `Q` monad. Lifting an `Exp` seems trivial as it's a normal ADT > > (I tested and this works after deriving 40 instances). > > > > You can define `lift2` which lifts an expression twice as follows. > > > > ``` > > lift2 :: Lift a => a -> Q Exp > > lift2 a = lift a >>= \e -> [| return $ $(lift e) |] > > ``` > > > > 3. x is defined at stage 1 and used in stage 2 > > > > foo = [| \x -> [| x |] |] ===> > > foo = [| \x -> [| $(lift x) |] |] > > > > Desugared with a single call to `lift` like normal. > > > > 4. x is defined in stage 2 and used in stage 1 > > > > foo = [| [| \x -> $(x) |] |] > > > > Rejected just like usual. `x` won't be bound when the splice is run. > > > > It seems that with some suitable care that things will work out when > > lifting across multiple levels but that is the point where care needs > > to be taken. > > > > Matt > > > > > > > > On Thu, Jan 24, 2019 at 5:46 PM Richard Eisenberg > > wrote: > >> > >> I think Geoff was primarily concerned with typed Template Haskell, not the > >> untyped variety. > >> > >> I, too, have wondered if there was a technical reason behind this > >> restriction, or if merely it was assumed that nested brackets were not > >> worthwhile. > >> > >> One question: how would staging work between nesting levels of brackets? > >> > >> Richard > >> > >>> On Jan 24, 2019, at 12:42 PM, Ben Gamari wrote: > >>> > >>> Matthew Pickering writes: > >>> > There is a check in `RnSplice` which errors on the following program > with nested brackets. > > >>> It might be good to explicitly include Geoff Mainland in this thread. > >>> I'm not sure he'll see it otherwise. > >>> > >>> Cheers, > >>> > >>> - Ben > >>> > >>> ___ > >>> 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: Marge: "CI is taking too long"
Richard Eisenberg writes: > Marge has complained that > https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long. > And indeed it seems stuck. > Indeed currently CI is a bit backed up. There are a few reasons for this: * I am currently in the middle of a (now two-day-long) internet outage meaning a non-trivial fraction (roughly half) of our builder capacity is off-line. I have been reassured that service will be restored by 7 PM today. * there has been a significant number of patches recently, especially since I have recently migrated a number of patches from Phabricator. Consequently it doesn't surprise me that CI is taking a while. 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: Hadrian questions
Maybe I'm just lazy, but would it be possible to shorten these? Specifically, could there be a root-level file `build` that triggers Hadrian? That way, I could just say ./build instead of hadrian/build.sh. Actually, even that isn't quite right. It is common, for example, for me to be deep in the testsuite, trying to fix a test. I twiddle something (say, the output file), and then I want to rerun the test. But now I have to go back out to the root of my tree to run the test, no? So: I think it would be very convenient to make a script we can all install (in our PATH) that will search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only one who would enjoy it. Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, and I don't see a way to run just one directory of the testsuite. I use that ability currently quite often (because I know that I've mucked with the typechecker, so I just run the typecheck tests before doing full CI). Is this possible? Thanks for all the work on this! Richard > On Jan 25, 2019, at 3:22 AM, Matthew Pickering > wrote: > > `make 2` should be somewhat equivalent to `./hadrian/build.sh > _build/stage1/bin/ghc` I think. > > The problem is with the devel2 flavour itself. Tracked by > https://ghc.haskell.org/trac/ghc/ticket/16210 > > The `hadrian/build.sh` script uses `cabal new-build` so the > dependencies should be shared already when possible. > > Cheers, > > Matt > > On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg > wrote: >> >> In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do >> this with devel2, and I'd prefer Hadrian didn't, too. >> >> Maybe I'm not really on the devel2 flavor? >> >>> On Jan 24, 2019, at 11:02 PM, Richard Eisenberg >>> wrote: >>> >>> As suggested, I'm trying out Hadrian. I have a few questions. >>> >>> - After building GHC the first time, I often go into the /ghc directory and >>> then do `make 2` to build just the stage-2 compiler. Is that now the same >>> as `build --freeze1`? It would seem not (I haven't tested), because running >>> `make 2` builds only the compiler, not the libraries. Can this workflow be >>> replicated in Hadrian? >>> >>> - I have `userDefaultFlavour = "devel2"` in my hadrian/UserSettings.hs >>> file. But I see build artifacts during compilation of stage-2 that have >>> dyn_o and p_o extensions. I don't want these. Have I done something wrong? >>> Or are these artifacts now necessary? >>> >>> - I have quite a few ghc directories. What are the dependencies of Hadrian >>> so that I can install these into my global package database and avoiding >>> rebuilding them for each ghc tree? (Please don't tell me that the global >>> package database is bad for my health. I know that, and I know why, but >>> it's still terribly convenient, and I'm happy to pay the occasional price >>> for that convenience.) >>> >>> I'm sure I'll have more questions. >>> >>> Thanks! >>> Richard >>> ___ >>> 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Getting a profiled GHC with hadrian.
Hello Devs, What's the proper way to get a profiled GHC in hadrian? I tried hadrian/build.cabal.sh -j8 --flavour=Prof but that didn't work out: $ _build/stage1/bin/ghc.exe +RTS -p ghc.exe: the flag -p requires the program to be built with -prof ghc.exe: ... What am I doing wrong here? Cheers Andreas ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Getting a profiled GHC with hadrian.
Hello, This is supposed to work, and worked for a while until some refactoring of mine which mistakenly dropped some logic. Matthew fixed it as soon as he noticed it though, so I suspect your branch doesn't have https://gitlab.haskell.org/ghc/ghc/commit/cfe64019a70acc1bae76f2fa580d6654f8eb5bc4 ? Cherry-picking this commit or rebasing against a quite recent master should fix the issue. Sorry for the inconvenience. On 25/01/2019 14:28, Andreas Klebinger wrote: Hello Devs, What's the proper way to get a profiled GHC in hadrian? I tried hadrian/build.cabal.sh -j8 --flavour=Prof but that didn't work out: $ _build/stage1/bin/ghc.exe +RTS -p ghc.exe: the flag -p requires the program to be built with -prof ghc.exe: ... What am I doing wrong here? Cheers Andreas ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
