From omeragacan at gmail.com Mon Apr 1 05:35:20 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 1 Apr 2019 08:35:20 +0300 Subject: Can't build HEAD with the old build system In-Reply-To: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> References: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> Message-ID: Yeah I can reproduce it reliably. I tried a few `git clean -xfd`s, and tried with no build.mk and with a debug build.mk, it happened with all configurations, when building the same file (the hsc2hs executable). The repro is simple: clone the GHC repo, build at 6f7115dfd4. If this doesn't reproduce the bug then I don't know what else to try. > so perhaps you also have a corrupt ELF file somewhere How do I check this? Maybe gold.ld produces a corrupt ELF file during the build, and then tries to read it to link an executable. Ömer Niklas Hambüchen , 31 Mar 2019 Paz, 23:11 tarihinde şunu yazdı: > > Can you reproduce this reliably? > > Googling the error message "internal error in find_view" yields: > > https://www.mail-archive.com/bug-binutils at gnu.org/msg28716.html > > where somebody encountered it, but only in proprietary code. > It would probably be very useful if we could provide a repro of it in an open-source code base like GHC. > > By the way, the attachment there is called "Corrupt elf file which causes linker to crash", so perhaps you also have a corrupt ELF file somewhere? > > Niklas From simonpj at microsoft.com Mon Apr 1 08:22:38 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Apr 2019 08:22:38 +0000 Subject: Newtypes in STG In-Reply-To: References: Message-ID: I printed out the full [StgTopBinding] list and got: let { sat_s27NC [Occ=Once] :: IO Timeout [LclId] = [] \u [] fmap $fFunctorIO Timeout newUnique; } in >>= $fMonadIO sat_s27NC sat_s27NT; That does look odd. Can you explain how to reproduce this with HEAD? That is, are we getting a newtype constructor in the argument position of an StgApp in HEAD too? Newtype “data constructors” are always inlined, which is why I don’t understand what’s happening. Simon From: ghc-devs On Behalf Of Christopher Done Sent: 30 March 2019 14:05 To: GHC developers Subject: Newtypes in STG Hi all, Could you offer some insight into newtypes at the STG level? Here’s the context: 1. I’m working on this interpreter for STG (https://github.com/chrisdone/prana) and I’m trying to generate a pristine AST where all names in it are resolved to something known to me. 2. I’ve compiled ghc-prim and integer-gmp without issue, and I’m compiling base and there remains one last frontier which is newtypes. These are the culprits pointed out if I compile base: chris at precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch Preprocessing library for base-4.11.1.0.. Building library for base-4.11.1.0.. [1 of 244] Compiling GHC.Base [2 of 244] Compiling GHC.IO [3 of 244] Compiling GHC.Real [4 of 244] Compiling Data.Semigroup.Internal ... [snip] ... [242 of 244] Compiling Data.Functor.Compose [243 of 244] Compiling Data.Fixed [244 of 244] Compiling Data.Complex Errors in Data.Foldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in Foreign.Marshal.Pool: Variable name not found: base:Foreign.Marshal.Pool.Pool Errors in GHC.ExecutionStack.Internal: Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace Errors in Data.Bifoldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in System.Timeout: Variable name not found: base:System.Timeout.Timeout Errors in Data.Data: Variable name not found: base:Foreign.Ptr.WordPtr Variable name not found: base:Foreign.Ptr.IntPtr Variable name not found: base:Data.Semigroup.Internal.Any Variable name not found: base:Data.Semigroup.Internal.All I looked these up, and they all appear to be uses of a newtype. For example, in the Timeout function: http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.html#timeout I printed out the full [StgTopBinding] list and got: let { sat_s27NC [Occ=Once] :: IO Timeout [LclId] = [] \u [] fmap $fFunctorIO Timeout newUnique; } in >>= $fMonadIO sat_s27NC sat_s27NT; Oddly (or not?), they’re used as values, not constructors. This error comes from this part of my code: StgSyn.StgApp occ arguments -> AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments If it was used as a constructor, it’d appear in this position, where looking up the ID would produce a “Data constructor name not found” error: StgSyn.StgConApp dataCon arguments types -> ConAppExpr <$> lookupDataConId dataCon <> traverse fromStgGenArg arguments <> pure (map (const Type) types) My understanding of newtypes at this stage is hazy. It seems like: · They ought to be erased and replaced with coercions by now. If they’re not replaced, it’s because they’re in a not-quite-id position like fmap Timeout .... (Arguably these could be fixed in base with a Data.Coerce.coerce?) · However, the CoreTidy/PrepPgm processing modules don’t seem to have removed or replaced these, or introduced a binding that would do something. At this stage what would you recommend? At this point type-checking is done, and I only care about interpreting the code. So I suppose they could be id for all it matters to the interpreter? I imagine they aren’t actually supposed to allocate something here. And I’m certain that any pattern matching on a newtype is also erased away by this point. Cheers! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Apr 1 08:49:21 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 1 Apr 2019 11:49:21 +0300 Subject: Newtypes in STG In-Reply-To: References: Message-ID: Hi, I'm a bit confused about your findings because I'm unable to reproduce them. I wasn't aware that we're generating terms for newtype constructors, and when I try I can see that this is really the case. For example, when I compile a module with just this line: newtype MyInt = MyInt Int in the Core or STG dumps I don't see any terms for the `MyInt` constructor. I also checked the Core for System.Timeout.timeout module, and I don't see any `Timeout` constructor applications anywhere. I compiled with -O0 -ddump-simpl. Here's what I get for the `fmap Timeout` application in that module: (fmap @ IO GHC.Base.$fFunctorIO @ Unique @ Timeout ((\ (v_B1 :: Unique) -> v_B1) `cast` (_R ->_R Sym (System.Timeout.N:Timeout[0]) :: (Unique -> Unique) ~R# (Unique -> Timeout))) newUnique) No `Timeout` constructors here. For reference, I'm attaching the full Core and STG dumps of System.Timeout module. It'd be helpful if you could share the build.mk you used when buildling GHC. Ömer Christopher Done , 30 Mar 2019 Cmt, 17:07 tarihinde şunu yazdı: > > Oh, also my complete pipeline is here: https://github.com/chrisdone/prana/blob/0cbb7b4b96bbfdb4f0d6a60e08f4b1f53abdfb15/prana-ghc/src/Prana/Ghc.hs#L106-L154 > > Parse/typecheck/desugar, tidy, prep, core-to-stg (ripped from HscMain) and then I try to resolve all names in the AST and that leads me to this. > > On Sat, 30 Mar 2019 at 14:05, Christopher Done wrote: >> >> Hi all, >> >> Could you offer some insight into newtypes at the STG level? Here’s the >> context: >> >> I’m working on this interpreter for STG >> (https://github.com/chrisdone/prana) and I’m trying to generate a >> pristine AST where all names in it are resolved to something known to >> me. >> >> I’ve compiled ghc-prim and integer-gmp without issue, and I’m >> compiling base and there remains one last frontier which is newtypes. >> >> These are the culprits pointed out if I compile base: >> >> chris at precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch >> Preprocessing library for base-4.11.1.0.. >> Building library for base-4.11.1.0.. >> [1 of 244] Compiling GHC.Base >> [2 of 244] Compiling GHC.IO >> [3 of 244] Compiling GHC.Real >> [4 of 244] Compiling Data.Semigroup.Internal >> ... [snip] ... >> [242 of 244] Compiling Data.Functor.Compose >> [243 of 244] Compiling Data.Fixed >> [244 of 244] Compiling Data.Complex >> >> Errors in Data.Foldable: >> Variable name not found: base:Data.Semigroup.Internal.All >> Variable name not found: base:Data.Semigroup.Internal.Any >> >> Errors in Foreign.Marshal.Pool: >> Variable name not found: base:Foreign.Marshal.Pool.Pool >> >> Errors in GHC.ExecutionStack.Internal: >> Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace >> >> Errors in Data.Bifoldable: >> Variable name not found: base:Data.Semigroup.Internal.All >> Variable name not found: base:Data.Semigroup.Internal.Any >> >> Errors in System.Timeout: >> Variable name not found: base:System.Timeout.Timeout >> >> Errors in Data.Data: >> Variable name not found: base:Foreign.Ptr.WordPtr >> Variable name not found: base:Foreign.Ptr.IntPtr >> Variable name not found: base:Data.Semigroup.Internal.Any >> Variable name not found: base:Data.Semigroup.Internal.All >> >> I looked these up, and they all appear to be uses of a >> newtype. >> >> For example, in the Timeout function: >> >> http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.html#timeout >> >> I printed out the full [StgTopBinding] list and got: >> >> let { >> sat_s27NC [Occ=Once] :: IO Timeout >> [LclId] = >> [] \u [] fmap $fFunctorIO Timeout newUnique; >> } in >>= $fMonadIO sat_s27NC sat_s27NT; >> >> Oddly (or not?), they’re used as values, not constructors. This error >> comes from this part of my code: >> >> StgSyn.StgApp occ arguments -> >> AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments >> >> If it was used as a constructor, it’d appear in this position, where >> looking up the ID would produce a “Data constructor name not found” >> error: >> >> StgSyn.StgConApp dataCon arguments types -> >> ConAppExpr <$> lookupDataConId dataCon <> traverse fromStgGenArg arguments <> >> pure (map (const Type) types) >> >> My understanding of newtypes at this stage is hazy. It seems like: >> >> They ought to be erased and replaced with coercions by now. If >> they’re not replaced, it’s because they’re in a not-quite-id position >> like fmap Timeout .... (Arguably these could be fixed in base with a >> Data.Coerce.coerce?) >> >> However, the CoreTidy/PrepPgm processing modules >> don’t seem to have removed or replaced these, or introduced a binding >> that would do something. >> >> At this stage what would you recommend? At this point type-checking is >> done, and I only care about interpreting the code. So I suppose they >> could be id for all it matters to the interpreter? >> >> I imagine they aren’t actually supposed to allocate something here. And >> I’m certain that any pattern matching on a newtype is also erased away >> by this point. >> >> Cheers! >> >> Chris > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: Timeout.dump-simpl Type: application/octet-stream Size: 23462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Timeout.dump-stg Type: application/octet-stream Size: 264886 bytes Desc: not available URL: From chrisdone at gmail.com Mon Apr 1 09:08:47 2019 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 1 Apr 2019 10:08:47 +0100 Subject: Newtypes in STG In-Reply-To: References: Message-ID: On Mon, 1 Apr 2019 at 09:22, Simon Peyton Jones simonpj at microsoft.com wrote: That does look odd. Can you explain how to reproduce this with HEAD? That is, are we getting a newtype constructor in the argument position of an StgApp in HEAD too? Newtype “data constructors” are always inlined, which is why I don’t understand what’s happening. OK, that’s good to know. I must be missing a Core-to-Core ot Core-to-STG transform step. I’ll try to make a single-file repro case against HEAD and see what happens. Maybe in doing so I’ll uncover what caused this output for me. On Mon, 1 Apr 2019 at 09:49, Ömer Sinan Ağacan omeragacan at gmail.com wrote: I’m a bit confused about your findings because I’m unable to reproduce them. I wasn’t aware that we’re generating terms for newtype constructors, and when I try I can see that this is really the case. For example, when I compile a module with just this line: newtype MyInt = MyInt Int in the Core or STG dumps I don’t see any terms for the MyInt constructor. I also checked the Core for System.Timeout.timeout module, and I don’t see any Timeout constructor applications anywhere. I compiled with -O0 -ddump-simpl. Here’s what I get for the fmap Timeout application in that module: Right, I see in yours that the newtype is properly removed and mine isn’t (via -ddump-simpl): -- RHS size: {terms: 201, types: 218, coercions: 11, joins: 0/1}timeout :: forall a. Int -> IO a -> IO (Maybe a) [GblId, Arity=2]timeout = \ (@ a_a27I4) (n_a27GX :: Int) (f_a27GY :: IO a_a27I4) -> case < @ Int GHC.Classes.$fOrdInt n_a27GX (GHC.Types.I# 0#) of { False -> case == @ Int GHC.Classes.$fEqInt n_a27GX (GHC.Types.I# 0#) of { False -> case rtsSupportsBoundThreads of { False -> >>= @ IO GHC.Base.$fMonadIO @ ThreadId @ (Maybe a_a27I4) myThreadId (\ (pid_a27Hb :: ThreadId) -> >>= @ IO GHC.Base.$fMonadIO @ Timeout @ (Maybe a_a27I4) (fmap @ IO GHC.Base.$fFunctorIO @ Unique @ Timeout System.Timeout.Timeout <- *NEWTYPE HERE* newUnique) So I must be missing a pass somewhere. I’ll try to reproduce on HEAD and get back to you. Cheers! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 1 11:34:06 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Apr 2019 11:34:06 +0000 Subject: GHC label conventions In-Reply-To: <87d0m9imt4.fsf@smart-cactus.org> References: <87d0m9imt4.fsf@smart-cactus.org> Message-ID: Good! Colours are a bit mixed up. Blue seems to be for "Scope". Could "Issue flags" be another colour, and "Types of bugs" be another. The mixture under those headings is hard to grok. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 29 March 2019 18:00 | To: GHC developers | Subject: GHC label conventions | | | Hello everyone, | | I have documented our current conventions regarding GitLab label usage | on the Wiki [1]. Please do keep this up-to-date if you create, remove, | or rename a label. | | As always, feedback is welcome | | Cheers, | | - Ben | | | [1] | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab | .haskell.org%2Fghc%2Fghc%2Fwikis%2FGitLab- | Labels%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0bcbca77f214dc5a | 9a408d6b4705bb1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63689479200 | 3872381&sdata=DeNxaFFKnkyYOXhIoUoiIeqq19ceOK37BHP5wwfmAg0%3D&res | erved=0 From takenobu.hs at gmail.com Mon Apr 1 12:27:20 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 1 Apr 2019 21:27:20 +0900 Subject: GHC HEAD documentation once again available In-Reply-To: <87tvfjgc84.fsf@smart-cactus.org> References: <87zhpbhnfh.fsf@smart-cactus.org> <87tvfjgc84.fsf@smart-cactus.org> Message-ID: Thanks for the explanation. I was able to access the URL. Thank you, Takenobu On Mon, Apr 1, 2019 at 2:55 AM Ben Gamari wrote: > Takenobu Tani writes: > > > Thank you for the useful link. > > > > It may not be related to this, but the following URL is not displayed > > correctly. > > > Thanks for pointing this out. This was due to a configuration mistake > which I had fixed, but apparently the CDN hadn't caught up. I have > purged the affected URL from the CDN so things should be fine now. > > Unfortunately there is no easy way to do a more comprehensive purge so > if there are any other affected URLs we will simply need to purge them > as we find them. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Apr 1 13:30:32 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 1 Apr 2019 15:30:32 +0200 Subject: Can't build HEAD with the old build system In-Reply-To: References: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> Message-ID: <3ece2ba4-52bb-c40c-cf2b-a695e3a0a28e@nh2.me> That sounds good. A few more questions: What's the exact version of your OS, and of gold? After getting to the error, can you run the failing ghc invocation directly, and see if the error remains? The one starting with "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs ... If yes, can you add a `-v` to it, so we can see the invocations to the programs it calls? Then, it should show a gcc invocation (which eventually calls gold). Can you then manually run and add a `-v` to to the gcc invocation as well, so we can see the linker command it runs (see also https://stackoverflow.com/questions/1170809/how-to-get-gcc-linker-command)? You may have to run ghc with `-keep-tmp-files` if it invokes the gcc on temporary files. Finally, can you run the printed ld.gold invocation manually, and add a `-v` to that, so we get more detail about what gold is doing? If you are on Linux (and also in some other cases), you can also run ghc under `strace -fy -e execve` to see all programs started recursively by any subprogram; this may also easily provide the linker invocation. Thank you! On 01/04/2019 7:35 AM, Ömer Sinan Ağacan wrote: > Yeah I can reproduce it reliably. I tried a few `git clean -xfd`s, and tried > with no build.mk and with a debug build.mk, it happened with all configurations, > when building the same file (the hsc2hs executable). > > The repro is simple: clone the GHC repo, build at 6f7115dfd4. If this doesn't > reproduce the bug then I don't know what else to try. > >> so perhaps you also have a corrupt ELF file somewhere > > How do I check this? Maybe gold.ld produces a corrupt ELF file during the build, > and then tries to read it to link an executable. From ben at well-typed.com Mon Apr 1 13:46:43 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Apr 2019 09:46:43 -0400 Subject: GHC label conventions In-Reply-To: References: <87d0m9imt4.fsf@smart-cactus.org> Message-ID: <87a7h9hm81.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Good! > > Colours are a bit mixed up. Blue seems to be for "Scope". Could "Issue > flags" be another colour, and "Types of bugs" be another. The mixture > under those headings is hard to grok. > Yes they were; I ran out of time before I had a chance to look too deeply at the colors. Matthew and I discussed the matter of colors and he argued that most labels should remain a single color (currently blue) to prevent things from becoming too visually busy. Given how cluttered GitLab's UI already is, I'm sympathetic to this argument. I just had a quick look over the colors with this in mind and changed a couple to improve consistency. Things are could likely still be improved but the general idea is: * purple: types of issues (e.g. bug, feature request, task) * green: performance issues * red: correctness issues * yellow/brown: stages of the issue lifecycle * blue: bug scope (operating system, architecture, compiler subsystem, language featuresetc.) Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at nh2.me Mon Apr 1 14:01:32 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 1 Apr 2019 16:01:32 +0200 Subject: Can't build HEAD with the old build system In-Reply-To: <3ece2ba4-52bb-c40c-cf2b-a695e3a0a28e@nh2.me> References: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> <3ece2ba4-52bb-c40c-cf2b-a695e3a0a28e@nh2.me> Message-ID: <4685453e-0146-1e0b-d4a3-0189ab2537dc@nh2.me> At least on my Ubuntu 16.04, it builds: % git clone --recursive git at gitlab.haskell.org:ghc/ghc.git ghc-gold-error-6f7115dfd4 % cd ghc-gold-error-6f7115dfd4 % ./boot && ./configure --prefix=$HOME/opt/ghc-gold-error-6f7115dfd4 GHC=$HOME/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc % make -j4 # Ctrl-C after a while when it's building stage-1 code % rm -f utils/hsc2hs/dist/build/tmp/hsc2hs % make utils/hsc2hs/dist/build/tmp/hsc2hs ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds "/home/niklas/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.3.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -outputdir utils/hsc2hs/dist/build -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.3.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o /usr/bin/install -c -m 755 utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin/hsc2hs ... make[1]: 'utils/hsc2hs/dist/build/tmp/hsc2hs' is up to date. make utils/hsc2hs/dist/build/tmp/hsc2hs 49.26s user 15.66s system 91% cpu 1:10.58 total Adding `-fforce-recomp -v -keep-tmp-files` to the above ghc invocation reveals a `gcc` invocation; running that one under `strace` shows: % strace -s 30000 -fy -e execve gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' -Wl,--no-as-needed -o utils/hsc2hs/dist/build/tmp/hsc2hs -lm -no-pie -Wl,--gc-sections utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/process-1.6.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/directory-1.3.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/unix-2.7.2.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/bytestring-0.10.8.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/time-1.8.0.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/filepath-1.4.2.1 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/containers-0.6.0.1 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/deepseq-1.4.4.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/array-0.5.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/integer-gmp-1.0.2.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/ghc-prim-0.5.3 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/rts /tmp/ghc2447_0/ghc_2.o /tmp/ghc2447_0/ghc_5.o -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,ghczmprim_GHCziTuple_Z0T_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure -Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure -Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure -Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runMainIO_closure -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziInt_I8zh_con_info -Wl,-u,base_GHCziInt_I16zh_con_info -Wl,-u,base_GHCziInt_I32zh_con_info -Wl,-u,base_GHCziInt_I64zh_con_info -Wl,-u,base_GHCziWord_W8zh_con_info -Wl,-u,base_GHCziWord_W16zh_con_info -Wl,-u,base_GHCziWord_W32zh_con_info -Wl,-u,base_GHCziWord_W64zh_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,hs_atomic_add8 -Wl,-u,hs_atomic_add16 -Wl,-u,hs_atomic_add32 -Wl,-u,hs_atomic_add64 -Wl,-u,hs_atomic_sub8 -Wl,-u,hs_atomic_sub16 -Wl,-u,hs_atomic_sub32 -Wl,-u,hs_atomic_sub64 -Wl,-u,hs_atomic_and8 -Wl,-u,hs_atomic_and16 -Wl,-u,hs_atomic_and32 -Wl,-u,hs_atomic_and64 -Wl,-u,hs_atomic_nand8 -Wl,-u,hs_atomic_nand16 -Wl,-u,hs_atomic_nand32 -Wl,-u,hs_atomic_nand64 -Wl,-u,hs_atomic_or8 -Wl,-u,hs_atomic_or16 -Wl,-u,hs_atomic_or32 -Wl,-u,hs_atomic_or64 -Wl,-u,hs_atomic_xor8 -Wl,-u,hs_atomic_xor16 -Wl,-u,hs_atomic_xor32 -Wl,-u,hs_atomic_xor64 -Wl,-u,hs_cmpxchg8 -Wl,-u,hs_cmpxchg16 -Wl,-u,hs_cmpxchg32 -Wl,-u,hs_cmpxchg64 -Wl,-u,hs_atomicread8 -Wl,-u,hs_atomicread16 -Wl,-u,hs_atomicread32 -Wl,-u,hs_atomicread64 -Wl,-u,hs_atomicwrite8 -Wl,-u,hs_atomicwrite16 -Wl,-u,hs_atomicwrite32 -Wl,-u,hs_atomicwrite64 -lHSprocess-1.6.3.0 -lHSdirectory-1.3.3.0 -lHSunix-2.7.2.2 -lHSbytestring-0.10.8.2 -lHStime-1.8.0.2 -lHSfilepath-1.4.2.1 -lHScontainers-0.6.0.1 -lHSdeepseq-1.4.4.0 -lHSarray-0.5.3.0 -lHSbase-4.12.0.0 -lHSinteger-gmp-1.0.2.0 -lHSghc-prim-0.5.3 -lHSrts -lCffi -lrt -lutil -ldl -lpthread -lgmp -lm -lrt -ldl -lpthread -v ... [pid 2998] execve("/usr/bin/ld.gold", ["/usr/bin/ld.gold", "-plugin", "/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so", "-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccix2beF.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "--sysroot=/", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=gnu", "--as-needed", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-z", "relro", "-o", "utils/hsc2hs/dist/build/tmp/hsc2hs", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o", "/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/process-1.6.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/directory-1.3.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/unix-2.7.2.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/bytestring-0.10.8.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/time-1.8.0.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/filepath-1.4.2.1", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/containers-0.6.0.1", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/deepseq-1.4.4.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/array-0.5.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/integer-gmp-1.0.2.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/ghc-prim-0.5.3", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/rts", "-L/usr/lib/gcc/x86_64-linux-gnu/5", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib", "-L/lib/x86_64-linux-gnu", "-L/lib/../lib", "-L/usr/lib/x86_64-linux-gnu", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..", "--no-as-needed", "-lm", "--gc-sections", "utils/hsc2hs/dist/build/Main.o", "utils/hsc2hs/dist/build/C.o", "utils/hsc2hs/dist/build/Common.o", "utils/hsc2hs/dist/build/CrossCodegen.o", "utils/hsc2hs/dist/build/DirectCodegen.o", "utils/hsc2hs/dist/build/Flags.o", "utils/hsc2hs/dist/build/HSCParser.o", "utils/hsc2hs/dist/build/ATTParser.o", "utils/hsc2hs/dist/build/UtilsCodegen.o", "utils/hsc2hs/dist/build/Compat/ResponseFile.o", "utils/hsc2hs/dist/build/Paths_hsc2hs.o", "/tmp/ghc2447_0/ghc_2.o", "/tmp/ghc2447_0/ghc_5.o", "-u", "base_GHCziTopHandler_runIO_closure", "-u", "base_GHCziTopHandler_runNonIO_closure", "-u", "ghczmprim_GHCziTuple_Z0T_closure", "-u", "ghczmprim_GHCziTypes_True_closure", "-u", "ghczmprim_GHCziTypes_False_closure", "-u", "base_GHCziPack_unpackCString_closure", "-u", "base_GHCziWeak_runFinalizzerBatch_closure", "-u", "base_GHCziIOziException_stackOverflow_closure", "-u", "base_GHCziIOziException_heapOverflow_closure", "-u", "base_GHCziIOziException_allocationLimitExceeded_closure", "-u", "base_GHCziIOziException_blockedIndefinitelyOnMVar_closure", "-u", "base_GHCziIOziException_blockedIndefinitelyOnSTM_closure", "-u", "base_GHCziIOziException_cannotCompactFunction_closure", "-u", "base_GHCziIOziException_cannotCompactPinned_closure", "-u", "base_GHCziIOziException_cannotCompactMutable_closure", "-u", "base_ControlziExceptionziBase_absentSumFieldError_closure", "-u", "base_ControlziExceptionziBase_nonTermination_closure", "-u", "base_ControlziExceptionziBase_nestedAtomically_closure", "-u", "base_GHCziEventziThread_blockedOnBadFD_closure", "-u", "base_GHCziConcziSync_runSparks_closure", "-u", "base_GHCziConcziIO_ensureIOManagerIsRunning_closure", "-u", "base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure", "-u", "base_GHCziConcziSignal_runHandlersPtr_closure", "-u", "base_GHCziTopHandler_flushStdHandles_closure", "-u", "base_GHCziTopHandler_runMainIO_closure", "-u", "ghczmprim_GHCziTypes_Czh_con_info", "-u", "ghczmprim_GHCziTypes_Izh_con_info", "-u", "ghczmprim_GHCziTypes_Fzh_con_info", "-u", "ghczmprim_GHCziTypes_Dzh_con_info", "-u", "ghczmprim_GHCziTypes_Wzh_con_info", "-u", "base_GHCziPtr_Ptr_con_info", "-u", "base_GHCziPtr_FunPtr_con_info", "-u", "base_GHCziInt_I8zh_con_info", "-u", "base_GHCziInt_I16zh_con_info", "-u", "base_GHCziInt_I32zh_con_info", "-u", "base_GHCziInt_I64zh_con_info", "-u", "base_GHCziWord_W8zh_con_info", "-u", "base_GHCziWord_W16zh_con_info", "-u", "base_GHCziWord_W32zh_con_info", "-u", "base_GHCziWord_W64zh_con_info", "-u", "base_GHCziStable_StablePtr_con_info", "-u", "hs_atomic_add8", "-u", "hs_atomic_add16", "-u", "hs_atomic_add32", "-u", "hs_atomic_add64", "-u", "hs_atomic_sub8", "-u", "hs_atomic_sub16", "-u", "hs_atomic_sub32", "-u", "hs_atomic_sub64", "-u", "hs_atomic_and8", "-u", "hs_atomic_and16", "-u", "hs_atomic_and32", "-u", "hs_atomic_and64", "-u", "hs_atomic_nand8", "-u", "hs_atomic_nand16", "-u", "hs_atomic_nand32", "-u", "hs_atomic_nand64", "-u", "hs_atomic_or8", "-u", "hs_atomic_or16", "-u", "hs_atomic_or32", "-u", "hs_atomic_or64", "-u", "hs_atomic_xor8", "-u", "hs_atomic_xor16", "-u", "hs_atomic_xor32", "-u", "hs_atomic_xor64", "-u", "hs_cmpxchg8", "-u", "hs_cmpxchg16", "-u", "hs_cmpxchg32", "-u", "hs_cmpxchg64", "-u", "hs_atomicread8", "-u", "hs_atomicread16", "-u", "hs_atomicread32", "-u", "hs_atomicread64", "-u", "hs_atomicwrite8", "-u", "hs_atomicwrite16", "-u", "hs_atomicwrite32", "-u", "hs_atomicwrite64", "-lHSprocess-1.6.3.0", "-lHSdirectory-1.3.3.0", "-lHSunix-2.7.2.2", "-lHSbytestring-0.10.8.2", "-lHStime-1.8.0.2", "-lHSfilepath-1.4.2.1", "-lHScontainers-0.6.0.1", "-lHSdeepseq-1.4.4.0", "-lHSarray-0.5.3.0", "-lHSbase-4.12.0.0", "-lHSinteger-gmp-1.0.2.0", "-lHSghc-prim-0.5.3", "-lHSrts", "-lCffi", "-lrt", "-lutil", "-ldl", "-lpthread", "-lgmp", "-lm", "-lrt", "-ldl", "-lpthread", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_64-linux-gnu/5/crtend.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o"], [/* 89 vars */]) = 0 [pid 2998] +++ exited with 0 +++ So no error for me. We'll want to do the same for you and compare. On 01/04/2019 3:30 PM, Niklas Hambüchen wrote: > That sounds good. A few more questions: > > What's the exact version of your OS, and of gold? > > After getting to the error, can you run the failing ghc invocation directly, and see if the error remains? The one starting with > > "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o > utils/hsc2hs/dist/build/tmp/hsc2hs ... > > If yes, can you add a `-v` to it, so we can see the invocations to the programs it calls? > > Then, it should show a gcc invocation (which eventually calls gold). > Can you then manually run and add a `-v` to to the gcc invocation as well, so we can see the linker command it runs (see also https://stackoverflow.com/questions/1170809/how-to-get-gcc-linker-command)? > You may have to run ghc with `-keep-tmp-files` if it invokes the gcc on temporary files. > > Finally, can you run the printed ld.gold invocation manually, and add a `-v` to that, so we get more detail about what gold is doing? > > If you are on Linux (and also in some other cases), you can also run ghc under `strace -fy -e execve` to see all programs started recursively by any subprogram; this may also easily provide the linker invocation. > > Thank you! > > On 01/04/2019 7:35 AM, Ömer Sinan Ağacan wrote: >> Yeah I can reproduce it reliably. I tried a few `git clean -xfd`s, and tried >> with no build.mk and with a debug build.mk, it happened with all configurations, >> when building the same file (the hsc2hs executable). >> >> The repro is simple: clone the GHC repo, build at 6f7115dfd4. If this doesn't >> reproduce the bug then I don't know what else to try. >> >>> so perhaps you also have a corrupt ELF file somewhere >> >> How do I check this? Maybe gold.ld produces a corrupt ELF file during the build, >> and then tries to read it to link an executable. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Apr 1 14:11:35 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Apr 2019 14:11:35 +0000 Subject: GHC label conventions In-Reply-To: <87d0m9imt4.fsf@smart-cactus.org> References: <87d0m9imt4.fsf@smart-cactus.org> Message-ID: Are you sure you got all the labels. Eg I don't see "type error messages https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages Maybe that's because there is only one such ticket, #16439. Can we have a list of all such orphaned labels, so we can get rid of them? Eg by relabelling Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 29 March 2019 18:00 | To: GHC developers | Subject: GHC label conventions | | | Hello everyone, | | I have documented our current conventions regarding GitLab label usage | on the Wiki [1]. Please do keep this up-to-date if you create, remove, | or rename a label. | | As always, feedback is welcome | | Cheers, | | - Ben | | | [1] | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab | .haskell.org%2Fghc%2Fghc%2Fwikis%2FGitLab- | Labels%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0bcbca77f214dc5a | 9a408d6b4705bb1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63689479200 | 3872381&sdata=DeNxaFFKnkyYOXhIoUoiIeqq19ceOK37BHP5wwfmAg0%3D&res | erved=0 From ben at well-typed.com Mon Apr 1 18:55:07 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Apr 2019 14:55:07 -0400 Subject: GHC label conventions In-Reply-To: References: <87d0m9imt4.fsf@smart-cactus.org> Message-ID: <8736n1h7xz.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Are you sure you got all the labels. Eg I don't see "type error messages > https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages > > Maybe that's because there is only one such ticket, #16439. > Indeed, that is reason. I had intended to fold that particular label into ~"error messages" but it appears that I missed it. > Can we have a list of all such orphaned labels, so we can get rid of them? Eg by relabelling > Sure, I can produce such a list. Give me just a minute. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From omeragacan at gmail.com Mon Apr 1 19:57:38 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 1 Apr 2019 22:57:38 +0300 Subject: Can't build HEAD with the old build system In-Reply-To: <4685453e-0146-1e0b-d4a3-0189ab2537dc@nh2.me> References: <07a4b551-0d4f-ef8b-0e0d-fbf9ead79aaa@nh2.me> <3ece2ba4-52bb-c40c-cf2b-a695e3a0a28e@nh2.me> <4685453e-0146-1e0b-d4a3-0189ab2537dc@nh2.me> Message-ID: Hmm this is really weird, I tried to again but it's building fine now. Nothing changed -- I'm using the same tree, trying after `git clean -xfd`, and without a build.mk. I guess the bug does not happen deterministically? Was that also the case with the bug report you mentioned? In case anyone's interested: I'm on Ubuntu 18.04, booting with GHC 8.6.4 (bindist from haskell.org, with debug info). Ömer Niklas Hambüchen , 1 Nis 2019 Pzt, 17:01 tarihinde şunu yazdı: > > At least on my Ubuntu 16.04, it builds: > > % git clone --recursive git at gitlab.haskell.org:ghc/ghc.git ghc-gold-error-6f7115dfd4 > % cd ghc-gold-error-6f7115dfd4 > % ./boot && ./configure --prefix=$HOME/opt/ghc-gold-error-6f7115dfd4 GHC=$HOME/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc > % make -j4 > > # Ctrl-C after a while when it's building stage-1 code > > % rm -f utils/hsc2hs/dist/build/tmp/hsc2hs > % make utils/hsc2hs/dist/build/tmp/hsc2hs > ===--- building phase 0 > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > make[1]: Nothing to be done for 'phase_0_builds'. > ===--- building phase 1 > make --no-print-directory -f ghc.mk phase=1 phase_1_builds > "/home/niklas/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.3.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -outputdir utils/hsc2hs/dist/build -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.3.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o > /usr/bin/install -c -m 755 utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin/hsc2hs > ... > make[1]: 'utils/hsc2hs/dist/build/tmp/hsc2hs' is up to date. > make utils/hsc2hs/dist/build/tmp/hsc2hs 49.26s user 15.66s system 91% cpu 1:10.58 total > > Adding `-fforce-recomp -v -keep-tmp-files` to the above ghc invocation reveals a `gcc` invocation; running that one under `strace` shows: > > % strace -s 30000 -fy -e execve gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' -Wl,--no-as-needed -o utils/hsc2hs/dist/build/tmp/hsc2hs -lm -no-pie -Wl,--gc-sections utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/process-1.6.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/directory-1.3.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/unix-2.7.2.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/bytestring-0.10.8.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/time-1.8.0.2 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/filepath-1.4.2.1 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/containers-0.6.0.1 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/deepseq-1.4.4.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/array-0.5.3.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/integer-gmp-1.0.2.0 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/ghc-prim-0.5.3 -L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/rts /tmp/ghc2447_0/ghc_2.o /tmp/ghc2447_0/ghc_5.o -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,ghczmprim_GHCziTuple_Z0T_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure -Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure -Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure -Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runMainIO_closure -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziInt_I8zh_con_info -Wl,-u,base_GHCziInt_I16zh_con_info -Wl,-u,base_GHCziInt_I32zh_con_info -Wl,-u,base_GHCziInt_I64zh_con_info -Wl,-u,base_GHCziWord_W8zh_con_info -Wl,-u,base_GHCziWord_W16zh_con_info -Wl,-u,base_GHCziWord_W32zh_con_info -Wl,-u,base_GHCziWord_W64zh_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,hs_atomic_add8 -Wl,-u,hs_atomic_add16 -Wl,-u,hs_atomic_add32 -Wl,-u,hs_atomic_add64 -Wl,-u,hs_atomic_sub8 -Wl,-u,hs_atomic_sub16 -Wl,-u,hs_atomic_sub32 -Wl,-u,hs_atomic_sub64 -Wl,-u,hs_atomic_and8 -Wl,-u,hs_atomic_and16 -Wl,-u,hs_atomic_and32 -Wl,-u,hs_atomic_and64 -Wl,-u,hs_atomic_nand8 -Wl,-u,hs_atomic_nand16 -Wl,-u,hs_atomic_nand32 -Wl,-u,hs_atomic_nand64 -Wl,-u,hs_atomic_or8 -Wl,-u,hs_atomic_or16 -Wl,-u,hs_atomic_or32 -Wl,-u,hs_atomic_or64 -Wl,-u,hs_atomic_xor8 -Wl,-u,hs_atomic_xor16 -Wl,-u,hs_atomic_xor32 -Wl,-u,hs_atomic_xor64 -Wl,-u,hs_cmpxchg8 -Wl,-u,hs_cmpxchg16 -Wl,-u,hs_cmpxchg32 -Wl,-u,hs_cmpxchg64 -Wl,-u,hs_atomicread8 -Wl,-u,hs_atomicread16 -Wl,-u,hs_atomicread32 -Wl,-u,hs_atomicread64 -Wl,-u,hs_atomicwrite8 -Wl,-u,hs_atomicwrite16 -Wl,-u,hs_atomicwrite32 -Wl,-u,hs_atomicwrite64 -lHSprocess-1.6.3.0 -lHSdirectory-1.3.3.0 -lHSunix-2.7.2.2 -lHSbytestring-0.10.8.2 -lHStime-1.8.0.2 -lHSfilepath-1.4.2.1 -lHScontainers-0.6.0.1 -lHSdeepseq-1.4.4.0 -lHSarray-0.5.3.0 -lHSbase-4.12.0.0 -lHSinteger-gmp-1.0.2.0 -lHSghc-prim-0.5.3 -lHSrts -lCffi -lrt -lutil -ldl -lpthread -lgmp -lm -lrt -ldl -lpthread -v > ... > [pid 2998] execve("/usr/bin/ld.gold", ["/usr/bin/ld.gold", "-plugin", "/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so", "-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccix2beF.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "--sysroot=/", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=gnu", "--as-needed", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-z", "relro", "-o", "utils/hsc2hs/dist/build/tmp/hsc2hs", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o", "/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/process-1.6.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/directory-1.3.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/unix-2.7.2.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/bytestring-0.10.8.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/time-1.8.0.2", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/filepath-1.4.2.1", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/containers-0.6.0.1", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/deepseq-1.4.4.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/array-0.5.3.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/integer-gmp-1.0.2.0", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/ghc-prim-0.5.3", "-L/raid/stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/rts", "-L/usr/lib/gcc/x86_64-linux-gnu/5", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib", "-L/lib/x86_64-linux-gnu", "-L/lib/../lib", "-L/usr/lib/x86_64-linux-gnu", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..", "--no-as-needed", "-lm", "--gc-sections", "utils/hsc2hs/dist/build/Main.o", "utils/hsc2hs/dist/build/C.o", "utils/hsc2hs/dist/build/Common.o", "utils/hsc2hs/dist/build/CrossCodegen.o", "utils/hsc2hs/dist/build/DirectCodegen.o", "utils/hsc2hs/dist/build/Flags.o", "utils/hsc2hs/dist/build/HSCParser.o", "utils/hsc2hs/dist/build/ATTParser.o", "utils/hsc2hs/dist/build/UtilsCodegen.o", "utils/hsc2hs/dist/build/Compat/ResponseFile.o", "utils/hsc2hs/dist/build/Paths_hsc2hs.o", "/tmp/ghc2447_0/ghc_2.o", "/tmp/ghc2447_0/ghc_5.o", "-u", "base_GHCziTopHandler_runIO_closure", "-u", "base_GHCziTopHandler_runNonIO_closure", "-u", "ghczmprim_GHCziTuple_Z0T_closure", "-u", "ghczmprim_GHCziTypes_True_closure", "-u", "ghczmprim_GHCziTypes_False_closure", "-u", "base_GHCziPack_unpackCString_closure", "-u", "base_GHCziWeak_runFinalizzerBatch_closure", "-u", "base_GHCziIOziException_stackOverflow_closure", "-u", "base_GHCziIOziException_heapOverflow_closure", "-u", "base_GHCziIOziException_allocationLimitExceeded_closure", "-u", "base_GHCziIOziException_blockedIndefinitelyOnMVar_closure", "-u", "base_GHCziIOziException_blockedIndefinitelyOnSTM_closure", "-u", "base_GHCziIOziException_cannotCompactFunction_closure", "-u", "base_GHCziIOziException_cannotCompactPinned_closure", "-u", "base_GHCziIOziException_cannotCompactMutable_closure", "-u", "base_ControlziExceptionziBase_absentSumFieldError_closure", "-u", "base_ControlziExceptionziBase_nonTermination_closure", "-u", "base_ControlziExceptionziBase_nestedAtomically_closure", "-u", "base_GHCziEventziThread_blockedOnBadFD_closure", "-u", "base_GHCziConcziSync_runSparks_closure", "-u", "base_GHCziConcziIO_ensureIOManagerIsRunning_closure", "-u", "base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure", "-u", "base_GHCziConcziSignal_runHandlersPtr_closure", "-u", "base_GHCziTopHandler_flushStdHandles_closure", "-u", "base_GHCziTopHandler_runMainIO_closure", "-u", "ghczmprim_GHCziTypes_Czh_con_info", "-u", "ghczmprim_GHCziTypes_Izh_con_info", "-u", "ghczmprim_GHCziTypes_Fzh_con_info", "-u", "ghczmprim_GHCziTypes_Dzh_con_info", "-u", "ghczmprim_GHCziTypes_Wzh_con_info", "-u", "base_GHCziPtr_Ptr_con_info", "-u", "base_GHCziPtr_FunPtr_con_info", "-u", "base_GHCziInt_I8zh_con_info", "-u", "base_GHCziInt_I16zh_con_info", "-u", "base_GHCziInt_I32zh_con_info", "-u", "base_GHCziInt_I64zh_con_info", "-u", "base_GHCziWord_W8zh_con_info", "-u", "base_GHCziWord_W16zh_con_info", "-u", "base_GHCziWord_W32zh_con_info", "-u", "base_GHCziWord_W64zh_con_info", "-u", "base_GHCziStable_StablePtr_con_info", "-u", "hs_atomic_add8", "-u", "hs_atomic_add16", "-u", "hs_atomic_add32", "-u", "hs_atomic_add64", "-u", "hs_atomic_sub8", "-u", "hs_atomic_sub16", "-u", "hs_atomic_sub32", "-u", "hs_atomic_sub64", "-u", "hs_atomic_and8", "-u", "hs_atomic_and16", "-u", "hs_atomic_and32", "-u", "hs_atomic_and64", "-u", "hs_atomic_nand8", "-u", "hs_atomic_nand16", "-u", "hs_atomic_nand32", "-u", "hs_atomic_nand64", "-u", "hs_atomic_or8", "-u", "hs_atomic_or16", "-u", "hs_atomic_or32", "-u", "hs_atomic_or64", "-u", "hs_atomic_xor8", "-u", "hs_atomic_xor16", "-u", "hs_atomic_xor32", "-u", "hs_atomic_xor64", "-u", "hs_cmpxchg8", "-u", "hs_cmpxchg16", "-u", "hs_cmpxchg32", "-u", "hs_cmpxchg64", "-u", "hs_atomicread8", "-u", "hs_atomicread16", "-u", "hs_atomicread32", "-u", "hs_atomicread64", "-u", "hs_atomicwrite8", "-u", "hs_atomicwrite16", "-u", "hs_atomicwrite32", "-u", "hs_atomicwrite64", "-lHSprocess-1.6.3.0", "-lHSdirectory-1.3.3.0", "-lHSunix-2.7.2.2", "-lHSbytestring-0.10.8.2", "-lHStime-1.8.0.2", "-lHSfilepath-1.4.2.1", "-lHScontainers-0.6.0.1", "-lHSdeepseq-1.4.4.0", "-lHSarray-0.5.3.0", "-lHSbase-4.12.0.0", "-lHSinteger-gmp-1.0.2.0", "-lHSghc-prim-0.5.3", "-lHSrts", "-lCffi", "-lrt", "-lutil", "-ldl", "-lpthread", "-lgmp", "-lm", "-lrt", "-ldl", "-lpthread", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_64-linux-gnu/5/crtend.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o"], [/* 89 vars */]) = 0 > [pid 2998] +++ exited with 0 +++ > > So no error for me. > We'll want to do the same for you and compare. > > > On 01/04/2019 3:30 PM, Niklas Hambüchen wrote: > > That sounds good. A few more questions: > > > > What's the exact version of your OS, and of gold? > > > > After getting to the error, can you run the failing ghc invocation directly, and see if the error remains? The one starting with > > > > "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o > > utils/hsc2hs/dist/build/tmp/hsc2hs ... > > > > If yes, can you add a `-v` to it, so we can see the invocations to the programs it calls? > > > > Then, it should show a gcc invocation (which eventually calls gold). > > Can you then manually run and add a `-v` to to the gcc invocation as well, so we can see the linker command it runs (see also https://stackoverflow.com/questions/1170809/how-to-get-gcc-linker-command)? > > You may have to run ghc with `-keep-tmp-files` if it invokes the gcc on temporary files. > > > > Finally, can you run the printed ld.gold invocation manually, and add a `-v` to that, so we get more detail about what gold is doing? > > > > If you are on Linux (and also in some other cases), you can also run ghc under `strace -fy -e execve` to see all programs started recursively by any subprogram; this may also easily provide the linker invocation. > > > > Thank you! > > > > On 01/04/2019 7:35 AM, Ömer Sinan Ağacan wrote: > >> Yeah I can reproduce it reliably. I tried a few `git clean -xfd`s, and tried > >> with no build.mk and with a debug build.mk, it happened with all configurations, > >> when building the same file (the hsc2hs executable). > >> > >> The repro is simple: clone the GHC repo, build at 6f7115dfd4. If this doesn't > >> reproduce the bug then I don't know what else to try. > >> > >>> so perhaps you also have a corrupt ELF file somewhere > >> > >> How do I check this? Maybe gold.ld produces a corrupt ELF file during the build, > >> and then tries to read it to link an executable. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From ben at well-typed.com Mon Apr 1 20:34:45 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Apr 2019 16:34:45 -0400 Subject: GHC label conventions In-Reply-To: References: <87d0m9imt4.fsf@smart-cactus.org> Message-ID: <87zhp9forl.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Are you sure you got all the labels. Eg I don't see "type error messages > https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages > > Maybe that's because there is only one such ticket, #16439. > > Can we have a list of all such orphaned labels, so we can get rid of them? Eg by relabelling > The set of orphan keywords is attached (orphan-keywords.json). For reference, the orphan set was computed from the set of all keywords (all-keywords.csv, from Trac report #25) and the keyword mapping used by the import script (keyword-label-mapping.json, mapping Trac keywords to a set of GitLab labels) as follows in Python: import csv import json all_keywords = set(e[0].lower() for e in csv.reader(open('all-keywords.csv'))) mapping = json.load(open('./keyword-label-mappping.json')) mapped_keywords = set(map(str.lower, mapping.keys())) orphans = set(all_keywords).difference(mapped_keywords) json.dump(list(orphans), open('orphan-keywords.json','w')) Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: all-keywords.csv Type: application/octet-stream Size: 23572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: orphan-keywords.json Type: application/octet-stream Size: 3469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keyword-label-mappping.json Type: application/octet-stream Size: 7738 bytes Desc: not available URL: From lonetiger at gmail.com Mon Apr 1 20:44:29 2019 From: lonetiger at gmail.com (Phyx) Date: Mon, 1 Apr 2019 21:44:29 +0100 Subject: GHC label conventions In-Reply-To: <87zhp9forl.fsf@smart-cactus.org> References: <87d0m9imt4.fsf@smart-cactus.org> <87zhp9forl.fsf@smart-cactus.org> Message-ID: Hi Ben, That's awesome! I'm glad to have something to refer to as on Trac I was sometimes hesitant as to where something fell. Two questions, well three. 1. Curious, is there no Linux label? Similarly no x86 and x64_86 labels? 2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm architectures? (I see no AArch64) either. Is this because we didn't have a label for them in trac? 3. Slightly unrelated, on Phabricator I used to have a customized side bar with helpful links such as this one. Can I do the same on GitLab? Thanks, Tamar Sent from my Mobile On Mon, Apr 1, 2019, 21:35 Ben Gamari wrote: > Simon Peyton Jones via ghc-devs writes: > > > Are you sure you got all the labels. Eg I don't see "type error messages > > > https://gitlab.haskell.org/ghc/ghc/issues?label_name%5B%5D=type+error+messages > > > > Maybe that's because there is only one such ticket, #16439. > > > > Can we have a list of all such orphaned labels, so we can get rid of > them? Eg by relabelling > > > The set of orphan keywords is attached (orphan-keywords.json). > > For reference, the orphan set was computed from the set of all keywords > (all-keywords.csv, from Trac report #25) and the keyword mapping used by > the import script (keyword-label-mapping.json, mapping Trac keywords to > a set of GitLab labels) as follows in Python: > > import csv > import json > > all_keywords = set(e[0].lower() for e in > csv.reader(open('all-keywords.csv'))) > mapping = json.load(open('./keyword-label-mappping.json')) > mapped_keywords = set(map(str.lower, mapping.keys())) > orphans = set(all_keywords).difference(mapped_keywords) > json.dump(list(orphans), open('orphan-keywords.json','w')) > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Apr 1 21:16:59 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Apr 2019 17:16:59 -0400 Subject: GHC label conventions In-Reply-To: References: <87d0m9imt4.fsf@smart-cactus.org> <87zhp9forl.fsf@smart-cactus.org> Message-ID: <87k1gdfmt5.fsf@smart-cactus.org> Phyx writes: > Hi Ben, > > That's awesome! I'm glad to have something to refer to as on Trac I was > sometimes hesitant as to where something fell. > Indeed; you certainly weren't the only one. As you can tell from the import mappings I posted earlier, Trac keyword usage wasn't particularly consistent. > Two questions, well three. > > 1. Curious, is there no Linux label? Similarly no x86 and x64_86 labels? I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't labelled with one of the operating system labels then it should be assumed that either the issue is OS-independent or it's Linux. This is a compromise but given that we need to assign labels manually, it didn't seem like manually labelling all Linux tickets was worth the effort. Also, once !653 lands issue authors will be prompted for their operating system in the issue description. > 2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm > architectures? (I see no AArch64) either. ARM refers to all ARM architectures. I'll update the description to be more clear on this. > Is this because we didn't have a label for them in trac? > Pretty much. > 3. Slightly unrelated, on Phabricator I used to have a customized side bar > with helpful links such as this one. Can I do the same on GitLab? > I'm afraid the answer may be "no". I have this page in my browser's bookmarks list. I suppose we could add it to _sidebar [1], which is displayed in the sidebar on the right side of the screen when viewing the wiki; however this seems like a bit of a slippery slope as it isn't really a top-level page. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/_sidebar -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Apr 1 22:49:19 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Apr 2019 18:49:19 -0400 Subject: GitLab conventions Message-ID: <87h8bhfija.fsf@smart-cactus.org> Hi everyone, Today I have been working on better documenting our conventions under GitLab. This has resulted in a handful of documents: * A gitlab/issues wiki page [1], describing our triage and issue resolution workflow * A gitlab/merge-requests wiki page [2], describing our patch backport workflow * issue and merge request templates (e.g. [3] and [4]), which will be used by authors of issues and MR, respectively. If you frequent GHC's issue tracker it may be a good idea to look over the triage guide [1] to make sure you understand the implications of our many labels. Also, on the behest of Simon I propose that we start using a comment convention to note the addition of tests on issues (replacing Trac's "Test Case" field). Specifically, I suggest that a comment containing a line beginning with the token "Testsuite-tests:" followed by a series of comma-separated strings denote a set of test-cases for the issue. I have documented this here [5] If there is consensus that this is a sensible and worthwhile convention I will add these comments for the issues imported from Trac next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues [2] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests [3] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/issue_templates/bug.md [4] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/merge_request_templates/merge-request.md [5] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#marking-an-issue-as-resolved -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue Apr 2 09:22:32 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 Apr 2019 09:22:32 +0000 Subject: Gitlab email Message-ID: Ben I get a lot of email from GitLab. But I miss some that I expect. In particular I've just posted a Discussion comment on https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that comment come to me by email. But it didn't! It's as if Gitlab sends you everyone else's comments, but not your own. Is that right? Is it a setting one can change? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Tue Apr 2 09:36:02 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Tue, 2 Apr 2019 11:36:02 +0200 Subject: Gitlab email In-Reply-To: References: Message-ID: <6cb913c0-abb2-b81b-6af0-3aee0aee7178@nh2.me> Hey Simon, try the checkbox setting "Receive notifications about your own activity" at https://gitlab.haskell.org/profile/notifications In Gitlab thread https://gitlab.com/gitlab-org/gitlab-ce/issues/26395 somebody requested "Send email notifications to yourself for your own comments", and this checkbox is what people claimed there implements it. Niklas From ryan.gl.scott at gmail.com Tue Apr 2 13:09:48 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 2 Apr 2019 09:09:48 -0400 Subject: GitLab conventions Message-ID: Thanks for writing these up! These will be handy references that I'm sure I'll come back to many times. Question: once I've marked my MR as "backport-needed" (and it is merged into master), whose responsibility is it to ensure that it gets merged into the latest release branch (e.g., ghc-8.8)? It it the responsibility of the person who made the MR originally, or is there a process in place for collecting these backport-needed patches into batches and merging them? Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Apr 2 14:05:23 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Apr 2019 10:05:23 -0400 Subject: GitLab conventions In-Reply-To: References: Message-ID: <87y34sec4h.fsf@smart-cactus.org> Ryan Scott writes: > Thanks for writing these up! These will be handy references that I'm sure > I'll come back to many times. > > Question: once I've marked my MR as "backport-needed" (and it is merged > into master), whose responsibility is it to ensure that it gets merged into > the latest release branch (e.g., ghc-8.8)? It it the responsibility of the > person who made the MR originally, or is there a process in place for > collecting these backport-needed patches into batches and merging them? > It is of course appreciated if people backport their own patches. However, I do intend on doing a sweep of the backport list and take care of anything I find while preparing the stable branch. I'll see to it that this is better documented. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Tue Apr 2 16:14:06 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Apr 2019 12:14:06 -0400 Subject: Gitlab email In-Reply-To: References: Message-ID: <87k1gce65x.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Ben > I get a lot of email from GitLab. But I miss some that I expect. > In particular I've just posted a Discussion comment on https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that comment come to me by email. But it didn't! > It's as if Gitlab sends you everyone else's comments, but not your own. Is that right? Is it a setting one can change? Indeed, Niklas hit the nail on the head. Let me know if you would like further guidance or to chat one-on-one. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Tue Apr 2 18:16:33 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 2 Apr 2019 14:16:33 -0400 Subject: GitLab conventions In-Reply-To: <87y34sec4h.fsf@smart-cactus.org> References: <87y34sec4h.fsf@smart-cactus.org> Message-ID: Thanks! The updated information is now on https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those who are curious: > While the release manager can perform the backport on your behalf, it is appreciated if you open a merge request with the backported patches yourself. One further question: if a patch (that is intended to be backported) first lands on master, is it considered good practice to leave the corresponding issue open until the backport happens, similar to Trac's "merge" status? Or is this practice obsolete in the new label-based workflow? Ryan S. On Tue, Apr 2, 2019 at 10:05 AM Ben Gamari wrote: > Ryan Scott writes: > > > Thanks for writing these up! These will be handy references that I'm sure > > I'll come back to many times. > > > > Question: once I've marked my MR as "backport-needed" (and it is merged > > into master), whose responsibility is it to ensure that it gets merged > into > > the latest release branch (e.g., ghc-8.8)? It it the responsibility of > the > > person who made the MR originally, or is there a process in place for > > collecting these backport-needed patches into batches and merging them? > > > It is of course appreciated if people backport their own patches. > However, I do intend on doing a sweep of the backport list and take care > of anything I find while preparing the stable branch. > > I'll see to it that this is better documented. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Apr 2 18:23:24 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 2 Apr 2019 19:23:24 +0100 Subject: GHC label conventions In-Reply-To: <87k1gdfmt5.fsf@smart-cactus.org> References: <87d0m9imt4.fsf@smart-cactus.org> <87zhp9forl.fsf@smart-cactus.org> <87k1gdfmt5.fsf@smart-cactus.org> Message-ID: Hi Ben, > I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't > labelled with one of the operating system labels then it should be > assumed that either the issue is OS-independent or it's Linux. This is a > compromise but given that we need to assign labels manually, it didn't > seem like manually labelling all Linux tickets was worth the effort. > Also, once !653 lands issue authors will be prompted for their operating > system in the issue description. > That's fair, I had thought this might be the case, but have you considered that you also lose the ability to filter using an inclusion filter then? To get list of x86 only Linux you would have exclude all competing tags then (if possible). But this also introduce an ambiguity, there's no way to say for instance that an issue effects Linux and Windows for instance as you would just have the Windows tag. > > 2. The ARM one is that Arm (e.g. pre AArch32) or just all Arm > > architectures? (I see no AArch64) either. > > ARM refers to all ARM architectures. I'll update the description to be > more clear on this. > > > Is this because we didn't have a label for them in trac? > > > Pretty much. > > > 3. Slightly unrelated, on Phabricator I used to have a customized side > bar > > with helpful links such as this one. Can I do the same on GitLab? > > > I'm afraid the answer may be "no". I have this page in my browser's > bookmarks list. I suppose we could add it to _sidebar [1], which is > displayed in the sidebar on the right side of the screen when viewing > the wiki; however this seems like a bit of a slippery slope as it isn't > really a top-level page. > Ah ok, was just checking, I can do a local plugin instead. Thanks, Tamar > Cheers, > > - Ben > > [1] https://gitlab.haskell.org/ghc/ghc/wikis/_sidebar > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Apr 2 18:24:55 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Apr 2019 14:24:55 -0400 Subject: GitLab conventions In-Reply-To: References: <87y34sec4h.fsf@smart-cactus.org> Message-ID: <874l7ge03u.fsf@smart-cactus.org> Ryan Scott writes: > Thanks! The updated information is now on > https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those > who are curious: > >> While the release manager can perform the backport on your behalf, it is > appreciated if you open a merge request with the backported patches > yourself. > > One further question: if a patch (that is intended to be backported) first > lands on master, is it considered good practice to leave the corresponding > issue open until the backport happens, similar to Trac's "merge" status? Or > is this practice obsolete in the new label-based workflow? > Indeed this should be documented (which I have done): the ticket should remain open. To identify backports I look at open tickets bearing the "backport needed" label. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Tue Apr 2 18:30:25 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 2 Apr 2019 14:30:25 -0400 Subject: GitLab conventions In-Reply-To: <874l7ge03u.fsf@smart-cactus.org> References: <87y34sec4h.fsf@smart-cactus.org> <874l7ge03u.fsf@smart-cactus.org> Message-ID: > To identify backports I look at open tickets bearing the > "backport needed" label. That's good to know, thanks. What should become of small MRs that are made directly against `master` (without a corresponding issue) that are intended to be backported as well? Does it suffice to label those with "backport needed", or should we also open "backport needed"–labeled issues as well to ensure that they're caught? (I have [1] and [2] in mind when asking this question.) I ask since if the former suffices, that would imply that the set of places that one would need to look to find all things that need to be backported would be: 1. The set of all open tickets labeled with "backport needed", unioned with 2. The set of all resolved MRs labeled with "backport needed". Unfortunately, GitLab doesn't appear to give you a way to view both simultaneously (unless I'm missing something), which is why I thought it worthwhile to ask you if this state of affairs would be inconvenient. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/650 [2] https://gitlab.haskell.org/ghc/ghc/merge_requests/639 On Tue, Apr 2, 2019 at 2:24 PM Ben Gamari wrote: > Ryan Scott writes: > > > Thanks! The updated information is now on > > https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for > those > > who are curious: > > > >> While the release manager can perform the backport on your behalf, it is > > appreciated if you open a merge request with the backported patches > > yourself. > > > > One further question: if a patch (that is intended to be backported) > first > > lands on master, is it considered good practice to leave the > corresponding > > issue open until the backport happens, similar to Trac's "merge" status? > Or > > is this practice obsolete in the new label-based workflow? > > > Indeed this should be documented (which I have done): the ticket should > remain open. To identify backports I look at open tickets bearing the > "backport needed" label. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Apr 2 18:58:52 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 02 Apr 2019 14:58:52 -0400 Subject: GitLab conventions In-Reply-To: References: <87y34sec4h.fsf@smart-cactus.org> <874l7ge03u.fsf@smart-cactus.org> Message-ID: <871s2kdyjc.fsf@smart-cactus.org> Ryan Scott writes: >> To identify backports I look at open tickets bearing the >> "backport needed" label. > > That's good to know, thanks. > > What should become of small MRs that are made directly against `master` > (without a corresponding issue) that are intended to be backported as well? > Does it suffice to label those with "backport needed", or should we also > open "backport needed"–labeled issues as well to ensure that they're > caught? (I have [1] and [2] in mind when asking this question.) > Indeed this is something I have wondered about. This is all a fair bit trickier recently because we currently are maintaining two "stable" branches (ghc-8.6 and ghc-8.8). This means that a MR could be in one of five states: a. ~"backport needed" applied and open: not present in master or any stable branch. b. ~"backport needed" applied and closed: present only in maser c. ~"backport needed" applied and closed: present in master and ghc-8.8 d. ~"backport needed" applied and closed: present in master and ghc-8.6 e. closed: present in master, ghc-8.8, and ghc-8.6 Unfortunately keeping track of which of (b), (c), or (d) an MR is in entirely manual. For this reason I have wondered whether it would be worth opening an issue for every backport request (e.g. for each backport MR that should be created). This sounds like it may be a lot of work but it would significantly reduce the probability that something is dropped on the floor (and address your quite valid concern of there being no way to view both issues and merge requests together). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Apr 2 19:15:49 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 02 Apr 2019 15:15:49 -0400 Subject: GHC label conventions In-Reply-To: References: <87d0m9imt4.fsf@smart-cactus.org> <87zhp9forl.fsf@smart-cactus.org> <87k1gdfmt5.fsf@smart-cactus.org> Message-ID: <87y34scj6q.fsf@smart-cactus.org> Phyx writes: > Hi Ben, > > >> I consider Linux/x86-64 to be the default; e.g. if there a ticket isn't >> labelled with one of the operating system labels then it should be >> assumed that either the issue is OS-independent or it's Linux. This is a >> compromise but given that we need to assign labels manually, it didn't >> seem like manually labelling all Linux tickets was worth the effort. >> Also, once !653 lands issue authors will be prompted for their operating >> system in the issue description. >> > > That's fair, I had thought this might be the case, but have you considered > that you also > lose the ability to filter using an inclusion filter then? To get list of > x86 only Linux you would have > exclude all competing tags then (if possible). > Indeed. Apparently at some point GitLab will be gaining the ability to do full boolean expression queries. However, until then I'm not sure that I see an alternative that isn't labor-intensive. > But this also introduce an ambiguity, there's no way to say for instance > that an issue effects Linux and > Windows for instance as you would just have the Windows tag. > Yes, this a known (and unfortunate) consequence of the choice. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jan at vanbruegge.de Wed Apr 3 11:06:11 2019 From: jan at vanbruegge.de (=?UTF-8?Q?Jan_van_Br=c3=bcgge?=) Date: Wed, 3 Apr 2019 13:06:11 +0200 Subject: Defining a wired-in type of a different kind Message-ID: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Hi, when trying to get familiar with the GHC code base for my Bachelor's thesis. I followed the GHC Wiki, especially the case study about the bool type. Now I wanted to add a new kind and a new type inhabiting this kind (without having to expose a data constructor, so without datatype promotion). So in TysWiredIn.hs I added the new TyCons and added them to the list of wired-in types: -- data Row a b rowKindCon :: TyCon rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] rowKind :: Kind rowKind = mkTyConTy rowKindCon -- data RNil :: Row a b rnilTyCon :: TyCon rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] (mkDataTyConRhs []) (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) False rnilTy :: Type rnilTy = mkTyConTy rnilTyCon I also added two new empty data decls to ghc-prim, but if I inspect the kind of RNil it is not Row, but Type. So I think I am either understanding res_kind wrong or I have to do something completely different. I am also not sure how to verify that the code in TysWiredIn.hs is working at all, from all what I can tell it could just be the declarations in ghc-prim that result in what I see in ghci. Thank you and sorry for my beginner question Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Apr 3 11:11:49 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 03 Apr 2019 07:11:49 -0400 Subject: Defining a wired-in type of a different kind In-Reply-To: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: On April 3, 2019 7:06:11 AM EDT, "Jan van Brügge" wrote: >Hi, > >when trying to get familiar with the GHC code base for my Bachelor's >thesis. I followed the GHC Wiki, especially the case study about the >bool type. >Now I wanted to add a new kind and a new type inhabiting this kind >(without having to expose a data constructor, so without datatype >promotion). > >So in TysWiredIn.hs I added the new TyCons and added them to the list >of >wired-in types: > >-- data Row a b >rowKindCon :: TyCon >rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] > >rowKind :: Kind >rowKind = mkTyConTy rowKindCon > >-- data RNil :: Row a b >rnilTyCon :: TyCon >rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] > (mkDataTyConRhs []) > (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) > False > >rnilTy :: Type >rnilTy = mkTyConTy rnilTyCon > > >I also added two new empty data decls to ghc-prim, but if I inspect the >kind of RNil it is not Row, but Type. So I think I am either >understanding res_kind wrong or I have to do something completely >different. >I am also not sure how to verify that the code in TysWiredIn.hs is >working at all, from all what I can tell it could just be the >declarations in ghc-prim that result in what I see in ghci. > >Thank you and sorry for my beginner question >Jan Can you post a full branch? Nothing in particular looks wrong with what you posted here but the PrelNames code is also relevant. Cheers, - Ben From jan at vanbruegge.de Wed Apr 3 11:33:02 2019 From: jan at vanbruegge.de (=?UTF-8?Q?Jan_van_Br=c3=bcgge?=) Date: Wed, 3 Apr 2019 13:33:02 +0200 Subject: Defining a wired-in type of a different kind In-Reply-To: References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: Yeah, sorry, it is here: https://gitlab.haskell.org/jvanbruegge/ghc/commit/73b383275f3d497338ca50a3a7934445c3858450 Am 03.04.19 um 13:11 schrieb Ben Gamari: > On April 3, 2019 7:06:11 AM EDT, "Jan van Brügge" wrote: >> Hi, >> >> when trying to get familiar with the GHC code base for my Bachelor's >> thesis. I followed the GHC Wiki, especially the case study about the >> bool type. >> Now I wanted to add a new kind and a new type inhabiting this kind >> (without having to expose a data constructor, so without datatype >> promotion). >> >> So in TysWiredIn.hs I added the new TyCons and added them to the list >> of >> wired-in types: >> >> -- data Row a b >> rowKindCon :: TyCon >> rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] >> >> rowKind :: Kind >> rowKind = mkTyConTy rowKindCon >> >> -- data RNil :: Row a b >> rnilTyCon :: TyCon >> rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] >> (mkDataTyConRhs []) >> (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) >> False >> >> rnilTy :: Type >> rnilTy = mkTyConTy rnilTyCon >> >> >> I also added two new empty data decls to ghc-prim, but if I inspect the >> kind of RNil it is not Row, but Type. So I think I am either >> understanding res_kind wrong or I have to do something completely >> different. >> I am also not sure how to verify that the code in TysWiredIn.hs is >> working at all, from all what I can tell it could just be the >> declarations in ghc-prim that result in what I see in ghci. >> >> Thank you and sorry for my beginner question >> Jan > Can you post a full branch? Nothing in particular looks wrong with what you posted here but the PrelNames code is also relevant. > > Cheers, > > - Ben From simonpj at microsoft.com Wed Apr 3 14:28:53 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Apr 2019 14:28:53 +0000 Subject: Defining a wired-in type of a different kind In-Reply-To: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: Make sure you add the new wired in this to `TysWiredIn.wiredInTyCons` From: ghc-devs On Behalf Of Jan van Brügge Sent: 03 April 2019 12:06 To: ghc-devs at haskell.org Subject: Defining a wired-in type of a different kind Hi, when trying to get familiar with the GHC code base for my Bachelor's thesis. I followed the GHC Wiki, especially the case study about the bool type. Now I wanted to add a new kind and a new type inhabiting this kind (without having to expose a data constructor, so without datatype promotion). So in TysWiredIn.hs I added the new TyCons and added them to the list of wired-in types: -- data Row a b rowKindCon :: TyCon rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] rowKind :: Kind rowKind = mkTyConTy rowKindCon -- data RNil :: Row a b rnilTyCon :: TyCon rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] (mkDataTyConRhs []) (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) False rnilTy :: Type rnilTy = mkTyConTy rnilTyCon I also added two new empty data decls to ghc-prim, but if I inspect the kind of RNil it is not Row, but Type. So I think I am either understanding res_kind wrong or I have to do something completely different. I am also not sure how to verify that the code in TysWiredIn.hs is working at all, from all what I can tell it could just be the declarations in ghc-prim that result in what I see in ghci. Thank you and sorry for my beginner question Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at vanbruegge.de Wed Apr 3 14:33:47 2019 From: jan at vanbruegge.de (=?UTF-8?Q?Jan_van_Br=c3=bcgge?=) Date: Wed, 3 Apr 2019 16:33:47 +0200 Subject: Defining a wired-in type of a different kind In-Reply-To: References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: <72816b0b-f530-0049-0ca1-1d1ff50ad4e3@vanbruegge.de> I did, see here: https://gitlab.haskell.org/jvanbruegge/ghc/blob/73b383275f3d497338ca50a3a7934445c3858450/compiler/prelude/TysWiredIn.hs#L235 Am 03.04.19 um 16:28 schrieb Simon Peyton Jones: > > Make sure you add the new wired in this to `TysWiredIn.wiredInTyCons` > >   > > *From:*ghc-devs *On Behalf Of *Jan van > Brügge > *Sent:* 03 April 2019 12:06 > *To:* ghc-devs at haskell.org > *Subject:* Defining a wired-in type of a different kind > >   > > Hi, >   > when trying to get familiar with the GHC code base for my Bachelor's > thesis. I followed the GHC Wiki, especially the case study about the > bool type. > Now I wanted to add a new kind and a new type inhabiting this kind > (without having to expose a data constructor, so without datatype > promotion). >   > So in TysWiredIn.hs I added the new TyCons and added them to the list of > wired-in types: >   > -- data Row a b > rowKindCon :: TyCon > rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] >   > rowKind :: Kind > rowKind = mkTyConTy rowKindCon >   > -- data RNil :: Row a b > rnilTyCon :: TyCon > rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] >     (mkDataTyConRhs []) >     (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) >     False >   > rnilTy :: Type > rnilTy = mkTyConTy rnilTyCon >   >   > I also added two new empty data decls to ghc-prim, but if I inspect the > kind of RNil it is not Row, but Type. So I think I am either > understanding res_kind wrong or I have to do something completely different. > I am also not sure how to verify that the code in TysWiredIn.hs is > working at all, from all what I can tell it could just be the > declarations in ghc-prim that result in what I see in ghci. >   > Thank you and sorry for my beginner question > Jan >   -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Wed Apr 3 14:35:52 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 3 Apr 2019 15:35:52 +0100 Subject: Defining a wired-in type of a different kind In-Reply-To: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: I would suggest that it's easier to define a normal type constructor and data cons and then promote them. This is how the runtime rep polymorphism stuff works for instance so you can look there for inspiration (it's where I look to work out how to implement multiplicity polymorphism). Matt On Wed, Apr 3, 2019 at 12:06 PM Jan van Brügge wrote: > > Hi, > > when trying to get familiar with the GHC code base for my Bachelor's > thesis. I followed the GHC Wiki, especially the case study about the > bool type. > Now I wanted to add a new kind and a new type inhabiting this kind > (without having to expose a data constructor, so without datatype > promotion). > > So in TysWiredIn.hs I added the new TyCons and added them to the list of > wired-in types: > > -- data Row a b > rowKindCon :: TyCon > rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] > > rowKind :: Kind > rowKind = mkTyConTy rowKindCon > > -- data RNil :: Row a b > rnilTyCon :: TyCon > rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] > (mkDataTyConRhs []) > (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) > False > > rnilTy :: Type > rnilTy = mkTyConTy rnilTyCon > > > I also added two new empty data decls to ghc-prim, but if I inspect the > kind of RNil it is not Row, but Type. So I think I am either > understanding res_kind wrong or I have to do something completely different. > I am also not sure how to verify that the code in TysWiredIn.hs is > working at all, from all what I can tell it could just be the > declarations in ghc-prim that result in what I see in ghci. > > Thank you and sorry for my beginner question > Jan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From autotaker at gmail.com Wed Apr 3 23:23:13 2019 From: autotaker at gmail.com (autotaker) Date: Thu, 4 Apr 2019 08:23:13 +0900 Subject: Cannot fetch array @ 58a7ea Message-ID: Hi devs, I pulled ghc gitlab repository by ``` git pull --recurse-submodules ``` But it failed with the following error. ``` error: Server does not allow request for unadvertised object 58a7ea0336363b29513164487190f6570b8ea834 Fetched in submodule path 'libraries/array', but it did not contain 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit failed. ``` It seems the latest commit `58a7ea` of `array` library is not found on the server. Are there any help on this? Best, Taku Terao -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Apr 4 08:20:59 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 4 Apr 2019 11:20:59 +0300 Subject: Introducing bugs that are caught by slow validate? Message-ID: Hi all, I just run slow validate and it actually catches bugs (#16529) and some configuration problems in the test definitions (#!700). These are not caught by the CI jobs because they run normal validate instead of slow. (Actually they don't even run the validate script, but they run "test" instead of "slowtest", which I think is the main difference between normal validate and slow validate) As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do slow validate, but I'm not sure if those are used? Would it be possible to switch over to slow validate in CI jobs? If slow validate takes too long on the CI servers, could we maybe configure CI tasks so that if the MR submitter is Marge, we run slow validate, otherwise we run fast validate? The problem with nightly jobs (assuming they're used) is that it's too late by the time they catch a test failure because the commits are already in the tree, and because nothing's blocked the bugs are more likely to stay unfixed. Ömer From simonpj at microsoft.com Thu Apr 4 09:51:39 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 09:51:39 +0000 Subject: Help with cabal Message-ID: I'm setting up my GHC builds on a new machine, and this time I'm using WSL (windows subsystem for Linux). Small problem. I've installed cabal-3.0, and say "cabal update". But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json And indeed, that's what a web browser says for that same URL. What do to? Oddly, on another also-new Windows machine, I do exactly the same thing, and with 'cabal update -v' I can see that it gets the same error, but then moves on to try hackages.fpcomplete.com, which works. Why does the behaviour differ? And, at least for now, how can I get the first machine to look at hackage.fpcomplete.com? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Thu Apr 4 09:56:10 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 4 Apr 2019 11:56:10 +0200 Subject: Help with cabal In-Reply-To: References: Message-ID: Hi Simon, Hackage on haskell.org is down: https://www.reddit.com/r/haskell/comments/b99cef/hackage_downtime/ Sylvain On 04/04/2019 11:51, Simon Peyton Jones via ghc-devs wrote: > > I’m setting up my GHC builds on a new machine, and this time I’m using > WSL (windows subsystem for Linux). > > Small problem.  I’ve installed cabal-3.0, and say “cabal update”.  But > I get > > Unexpected response 502for http://hackage.haskell.org/timestamp.json > > > And indeed, that’s what a web browser says for that same URL. > > What do to? > > Oddly, on another also-new Windows machine, I do exactly the same > thing, and with ‘cabal update –v’ I can see that it gets the same > error, but then moves on to try hackages.fpcomplete.com, which works. > > Why does the behaviour differ?  And, at least for now, how can I get > the first machine to look at hackage.fpcomplete.com? > > Thanks > > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 4 09:59:50 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 09:59:50 +0000 Subject: Help with cabal In-Reply-To: References: Message-ID: ok thanks. But still, how can I tell it to look at fpcomplete instead? And why does it do so automatically on one machine but not on another? From: ghc-devs On Behalf Of Sylvain Henry Sent: 04 April 2019 10:56 To: ghc-devs at haskell.org Subject: Re: Help with cabal Hi Simon, Hackage on haskell.org is down: https://www.reddit.com/r/haskell/comments/b99cef/hackage_downtime/ Sylvain On 04/04/2019 11:51, Simon Peyton Jones via ghc-devs wrote: I'm setting up my GHC builds on a new machine, and this time I'm using WSL (windows subsystem for Linux). Small problem. I've installed cabal-3.0, and say "cabal update". But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json And indeed, that's what a web browser says for that same URL. What do to? Oddly, on another also-new Windows machine, I do exactly the same thing, and with 'cabal update -v' I can see that it gets the same error, but then moves on to try hackages.fpcomplete.com, which works. Why does the behaviour differ? And, at least for now, how can I get the first machine to look at hackage.fpcomplete.com? Thanks Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 4 11:21:36 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 11:21:36 +0000 Subject: In-tree invocation of GHC built with Hadrian Message-ID: How can I run the inplace binary built by Hadrian. I tried this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs but I got this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190403", got "8064") | 1 | module Foo where | ^^^ simonpj at MSRC-3645512:~/tmp$ Somehow the inplace binary built by Hadrian is looking for library files in completely the wrong place. What should I do? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Apr 4 11:46:21 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 4 Apr 2019 12:46:21 +0100 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: Do you have any .ghc-environment files in your working directory? Matt On Thu, Apr 4, 2019 at 12:21 PM Simon Peyton Jones via ghc-devs wrote: > > How can I run the inplace binary built by Hadrian. I tried this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > but I got this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > > > Foo.hs:1:8: error: > > Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi > > mismatched interface file versions (wanted "80920190403", got "8064") > > | > > 1 | module Foo where > > | ^^^ > > simonpj at MSRC-3645512:~/tmp$ > > Somehow the inplace binary built by Hadrian is looking for library files in completely the wrong place. > > What should I do? > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Apr 4 12:27:24 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 12:27:24 +0000 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: No, definitely not in the current directory. There is only one file in the directory, Foo.hs Simon | -----Original Message----- | From: Matthew Pickering | Sent: 04 April 2019 12:46 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: In-tree invocation of GHC built with Hadrian | | Do you have any .ghc-environment files in your working directory? | | Matt | | | On Thu, Apr 4, 2019 at 12:21 PM Simon Peyton Jones via ghc-devs wrote: | > | > How can I run the inplace binary built by Hadrian. I tried this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > but I got this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > | > | > Foo.hs:1:8: error: | > | > Bad interface file: | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > mismatched interface file versions (wanted "80920190403", got | > "8064") | > | > | | > | > 1 | module Foo where | > | > | ^^^ | > | > simonpj at MSRC-3645512:~/tmp$ | > | > Somehow the inplace binary built by Hadrian is looking for library files | in completely the wrong place. | > | > What should I do? | > | > Simon | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01 | > %7Csimonpj%40microsoft.com%7Cf54dbe96df5f405e689c08d6b8f33015%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899752031269186&sdata=Llg1 | > 19jpY9JjiYxgWoca3b7Z%2BvZXruKbQVHIW1okxo4%3D&reserved=0 From simonpj at microsoft.com Thu Apr 4 12:29:31 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 12:29:31 +0000 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: No, setting GHC_ENVIRONMNT to "-" doesn't change anything tmp$ GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190404", got "8064") | 1 | module Foo where | ^^^ | -----Original Message----- | From: Moritz Angermann | Sent: 04 April 2019 12:47 | To: Simon Peyton Jones | Subject: Re: In-tree invocation of GHC built with Hadrian | | Yes, that looks wrong indeed. It shouldn't pick up the ghc-8.6.4 library. | | After the recent env files discussion, maybe it's picking up some env | files? | It's just a wild guess though, I've never had ghc do that to me yet(!). | Does | | GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | | yield any better results? | | Cheers, | Moritz | > On Apr 4, 2019, at 7:21 PM, Simon Peyton Jones via ghc-devs wrote: | > | > How can I run the inplace binary built by Hadrian. I tried this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > but I got this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > Foo.hs:1:8: error: | > Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base- | 4.12.0.0/Prelude.hi | > mismatched interface file versions (wanted "80920190403", got | "8064") | > | | > 1 | module Foo where | > | ^^^ | > simonpj at MSRC-3645512:~/tmp$ | > | > Somehow the inplace binary built by Hadrian is looking for library files | in completely the wrong place. | > | > What should I do? | > | > Simon | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C350a796ae8db4e3f8fc708d6 | b8f34549%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899752311716865&a | mp;sdata=FCMavvoIcAGUQVO0ggOxNJwIKZw2EC%2BSbmhZFSacywg%3D&reserved=0 From simonpj at microsoft.com Thu Apr 4 12:44:01 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 12:44:01 +0000 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: simonpj at MSRC-9870733:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags","") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","ranlib") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.9.20190404") ,("Project Git commit id","51fd357119b357c52e990ccce9059c423cc49406") ,("Booter version","8.6.4") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","v thr") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/simonpj/code/HEAD/_build/stage0/lib") ,("Global Package DB","/home/simonpj/code/HEAD/_build/stage0/lib/package.conf.d") ] simonpj at MSRC-9870733:~/tmp$ From: Herbert Valerio Riedel Sent: 04 April 2019 13:41 To: Simon Peyton Jones Subject: Re: In-tree invocation of GHC built with Hadrian Hi, I haven't tried this with Hadrian yet, but maybe the output from ~/code/HEAD/_build/stage0/bin/ghc --info might provide a hint. As for the ghc-environment theory: if there was a ghc-env file, GHC would tell you it has picked one up... On Thu, Apr 4, 2019 at 1:21 PM Simon Peyton Jones via ghc-devs > wrote: How can I run the inplace binary built by Hadrian. I tried this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs but I got this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190403", got "8064") | 1 | module Foo where | ^^^ simonpj at MSRC-3645512:~/tmp$ Somehow the inplace binary built by Hadrian is looking for library files in completely the wrong place. What should I do? Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Thu Apr 4 12:53:46 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 4 Apr 2019 21:53:46 +0900 Subject: Cannot fetch array @ 58a7ea In-Reply-To: References: Message-ID: Hi, Did you clone from gitlab.haskell.org ? Both github.com and git.haskell.org are already old domains. There may be a better way, but I'm cloning like this: -- clone from gitlab $ git clone git at gitlab.haskell.org:YOUR_NAME/ghc.git -- fix submodules $ mv .gitmodules .gitmodules.org $ sed -e 's/\.\./https:\/\/gitlab.haskell.org\/ghc/' .gitmodules.org > .gitmodules $ git submodule update --init $ git checkout .gitmodules Regards, Takenobu On Thu, Apr 4, 2019 at 8:23 AM autotaker wrote: > Hi devs, > > I pulled ghc gitlab repository by > ``` > git pull --recurse-submodules > ``` > > But it failed with the following error. > ``` > error: Server does not allow request for unadvertised object > 58a7ea0336363b29513164487190f6570b8ea834 > Fetched in submodule path 'libraries/array', but it did not contain > 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit > failed. > ``` > It seems the latest commit `58a7ea` of `array` library is not found on the > server. > Are there any help on this? > > Best, > Taku Terao > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 4 12:56:26 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 12:56:26 +0000 Subject: Help with cabal In-Reply-To: References: Message-ID: Ah, so you installed the `cabal-install-3.0` package? Yes I attached your repo and then said apt install cabal-install and lo! cabal 3.0 appeared in /opt/cabal/bin I did this because the vanilla Ubuntu distro only had cabal 1.24. And I could not update by saying “cabal install cabal-install” because cabal 1.24 fell over with that “futex error”. In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL? No, no noticeable startup latency. I’ll do the reinstall thing in a few hrs, after you’d done your update. Thanks! SImon From: Herbert Valerio Riedel Sent: 04 April 2019 13:45 To: Simon Peyton Jones Subject: Re: Help with cabal On Thu, Apr 4, 2019 at 2:25 PM Simon Peyton Jones > wrote: But how do I "recompile your cabal 3.0 executable with the new GHC"? The cabal-3.0 I have is (I believe) installed by apt install cabal-install and so I suppose if I "upgrade", the new 'cabal' binary will WSL'd, no? Ah, so you installed the `cabal-install-3.0` package? If so, yes, it *will* be updated to the WSL version.... in about one hour... because it turns out I forgot to push the 3.0 packages to the WSL ppa... and I've just triggered a new build of cabal 3.0 packages which will take about one hour to show up there... :-) In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL? -------------- next part -------------- An HTML attachment was scrubbed... URL: From autotaker at gmail.com Thu Apr 4 13:20:35 2019 From: autotaker at gmail.com (autotaker) Date: Thu, 4 Apr 2019 22:20:35 +0900 Subject: Cannot fetch array @ 58a7ea In-Reply-To: References: Message-ID: Hi, Takenobu, It worked! Thank you. This was the case mentioned in https://gitlab.haskell.org/ghc/ghc/issues/16513. URL of GHC in `README.md` has been fixed today. So there will be no problem. Best, Taku 2019年4月4日(木) 21:53 Takenobu Tani : > Hi, > > Did you clone from gitlab.haskell.org ? > Both github.com and git.haskell.org are already old domains. > > There may be a better way, but I'm cloning like this: > > -- clone from gitlab > $ git clone git at gitlab.haskell.org:YOUR_NAME/ghc.git > > -- fix submodules > $ mv .gitmodules .gitmodules.org > $ sed -e 's/\.\./https:\/\/gitlab.haskell.org\/ghc/' .gitmodules.org > > .gitmodules > $ git submodule update --init > $ git checkout .gitmodules > > Regards, > Takenobu > > > > > On Thu, Apr 4, 2019 at 8:23 AM autotaker wrote: > >> Hi devs, >> >> I pulled ghc gitlab repository by >> ``` >> git pull --recurse-submodules >> ``` >> >> But it failed with the following error. >> ``` >> error: Server does not allow request for unadvertised object >> 58a7ea0336363b29513164487190f6570b8ea834 >> Fetched in submodule path 'libraries/array', but it did not contain >> 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit >> failed. >> ``` >> It seems the latest commit `58a7ea` of `array` library is not found on >> the server. >> Are there any help on this? >> >> Best, >> Taku Terao >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Apr 4 13:26:18 2019 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 4 Apr 2019 15:26:18 +0200 Subject: Help with cabal In-Reply-To: References: Message-ID: On Thu, Apr 4, 2019 at 2:56 PM Simon Peyton Jones wrote: > Ah, so you installed the `cabal-install-3.0` package? > > > > Yes I attached your repo and then said > > apt install cabal-install > > and lo! cabal 3.0 appeared in /opt/cabal/bin > Ok, so here's the weird thing... I don't have any "cabal-install" package in my PPA; I do however have a "cabal-install-3.0" package (i.e. the 3.0 is part of the version number, because I supply one package per major version of cabal). So I'd expect you'd find something like ii cabal-install-3.0 3.0+git20190317.1.b3d6d0b-6~16.04 amd64 Command-line interface for Cabal and Hackage if you executed `dpkg -l | grep cabal-install`... (i.e. the "version" is that monstrous "3.0+git20190317.1.b3d6d0b-6~16.04" thing) > > > In the meantime you can just keep using your current cabal 3.0 exe; does > `cabal --version` currently have any noticeable startup latency for you on > WSL? > > > No, no noticeable startup latency. > Interesting. I'll investigate... maybe I'll be able to discontinue the WSL ppa at last... :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Apr 4 14:38:53 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Apr 2019 10:38:53 -0400 Subject: Debug printing inside the typechecker knot Message-ID: I've recently found myself wanting to add some pprTrace statements in typechecker-related code but unable to do so, as the code would pull on knot-tied TyCons (leading to an infinite loop if actually ran). In particular, I want to print some code [1] in TcTyClsDecls.tcConDecl: ; (ze, tkvs) <- zonkTyBndrs tkvs ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs ; arg_tys <- zonkTcTypesToTypesX ze arg_tys ; ctxt <- zonkTcTypesToTypesX ze ctxt ; res_ty <- zonkTcTypeToTypeX ze res_ty ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst) = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty In [2], goldfire claimed that there is a way to work around this problem now: > But you can do this. It just has to be before the final zonk. I see that rejigConRes is used after the final zonk. But there's nothing about that function that requires things be in their final state. The arguments need to be zonked, but they can be zonked by zonkTcType and friends, not zonkTcTypeToType and friends. So, for debugging: zonk everything with the functions in TcMType (not those in TcHsSyn). Then rejigConRes. Then print all the output you like. Then do the final zonk. This double-zonk is redundant, so it's not good to keep going forward, but it shouldn't cause other trouble. Unfortunately, this advice doesn't seem to pan out in practice. I started off by looking for a TcMType equivalent of this function: zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type However, I am utterly unable to find anything defined in TcMType with a similar type signature. Actually, it's worse than that: there isn't a single mention of ZonkEnv anywhere in TcMType! So as far as I can tell, this advice is completely unimplementable, unless I'm missing something obvious. Any tips? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc49406/compiler/typecheck/TcTyClsDecls.hs#L2312-2318 [2] https://phabricator.haskell.org/D4974#137224 From alp at well-typed.com Thu Apr 4 15:25:03 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Thu, 4 Apr 2019 17:25:03 +0200 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: I can reproduce this problem. This doesn't come up when building stage2 with that executable (stage1) because the commands that Hadrian emits all do something along the lines of `-no-user-package-db -package-db _build/stage0/lib/package.conf.d`, which masks the problem. I'm looking into this, I will open a ticket soon with the information that I can gather. On 04/04/2019 13:21, Simon Peyton Jones via ghc-devs wrote: > > How can I run the inplace binary built by Hadrian.  I tried this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > but I got this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > Foo.hs:1:8: error: > >     Bad interface file: > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi > >         mismatched interface file versions (wanted "80920190403", got > "8064") > >   | > > 1 | module Foo where > >   |        ^^^ > > simonpj at MSRC-3645512:~/tmp$ > > Somehow the inplace binary built by Hadrian is looking for library > files in completely the wrong place. > > What should I do? > > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 4 15:40:24 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 4 Apr 2019 15:40:24 +0000 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: OK, that's great - it's not just me. I'll await further guidance, and revert to "sh validate" meanwhile. Thanks Simon From: ghc-devs On Behalf Of Alp Mestanogullari Sent: 04 April 2019 16:25 To: ghc-devs at haskell.org Subject: Re: In-tree invocation of GHC built with Hadrian I can reproduce this problem. This doesn't come up when building stage2 with that executable (stage1) because the commands that Hadrian emits all do something along the lines of `-no-user-package-db -package-db _build/stage0/lib/package.conf.d`, which masks the problem. I'm looking into this, I will open a ticket soon with the information that I can gather. On 04/04/2019 13:21, Simon Peyton Jones via ghc-devs wrote: How can I run the inplace binary built by Hadrian. I tried this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs but I got this ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "80920190403", got "8064") | 1 | module Foo where | ^^^ simonpj at MSRC-3645512:~/tmp$ Somehow the inplace binary built by Hadrian is looking for library files in completely the wrong place. What should I do? Simon _______________________________________________ ghc-devs mailing list ghc-devs at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alp at well-typed.com Thu Apr 4 15:45:03 2019 From: alp at well-typed.com (Alp Mestanogullari) Date: Thu, 4 Apr 2019 17:45:03 +0200 Subject: In-tree invocation of GHC built with Hadrian In-Reply-To: References: Message-ID: <2fd49ba4-6878-5197-9345-1941695e28fc@well-typed.com> Issue tracked at https://gitlab.haskell.org/ghc/ghc/issues/16534 Somehow the stage 2 GHCs (_build/stage1/bin/ghc) that we build _don't_ have this problem. I will post an update here when I have a comprehensive explanation and a fix. On 04/04/2019 17:40, Simon Peyton Jones wrote: > > OK, that’s great – it’s not just me.   I’ll await further guidance, > and revert to “sh validate” meanwhile. > > Thanks > > Simon > > *From:*ghc-devs *On Behalf Of *Alp > Mestanogullari > *Sent:* 04 April 2019 16:25 > *To:* ghc-devs at haskell.org > *Subject:* Re: In-tree invocation of GHC built with Hadrian > > I can reproduce this problem. This doesn't come up when building > stage2 with that executable (stage1) because the commands that Hadrian > emits all do something along the lines of `-no-user-package-db > -package-db _build/stage0/lib/package.conf.d`, which masks the > problem. I'm looking into this, I will open a ticket soon with the > information that I can gather. > > On 04/04/2019 13:21, Simon Peyton Jones via ghc-devs wrote: > > How can I run the inplace binary built by Hadrian.  I tried this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > but I got this > > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs > > Foo.hs:1:8: error: > >     Bad interface file: > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi > >         mismatched interface file versions (wanted "80920190403", > got "8064") > >   | > > 1 | module Foo where > >   |        ^^^ > > simonpj at MSRC-3645512:~/tmp$ > > Somehow the inplace binary built by Hadrian is looking for library > files in completely the wrong place. > > What should I do? > > Simon > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at 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 -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Thu Apr 4 16:15:43 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 04 Apr 2019 12:15:43 -0400 Subject: Introducing bugs that are caught by slow validate? In-Reply-To: References: Message-ID: <87bm1ld9w6.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > Hi all, > > I just run slow validate and it actually catches bugs (#16529) and some > configuration problems in the test definitions (#!700). These are not caught by > the CI jobs because they run normal validate instead of slow. > > (Actually they don't even run the validate script, but they run "test" instead > of "slowtest", which I think is the main difference between normal validate and > slow validate) > > As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do > slow validate, but I'm not sure if those are used? > > Would it be possible to switch over to slow validate in CI jobs? If slow > validate takes too long on the CI servers, could we maybe configure CI tasks so > that if the MR submitter is Marge, we run slow validate, otherwise we run fast > validate? > See !710. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rae at richarde.dev Thu Apr 4 18:38:09 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 4 Apr 2019 14:38:09 -0400 Subject: Debug printing inside the typechecker knot In-Reply-To: References: Message-ID: <8F90CADA-93DA-4ACA-A068-C8E571857E14@richarde.dev> Though a ZonkEnv does some important work when zonking *terms*, it's just an optimization when zonking *types*. You want TcMType.zonkTcType. I hope this helps! Richard > On Apr 4, 2019, at 10:38 AM, Ryan Scott wrote: > > I've recently found myself wanting to add some pprTrace statements in > typechecker-related code but unable to do so, as the code would pull > on knot-tied TyCons (leading to an infinite loop if actually ran). In > particular, I want to print some code [1] in TcTyClsDecls.tcConDecl: > > ; (ze, tkvs) <- zonkTyBndrs tkvs > ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs > ; arg_tys <- zonkTcTypesToTypesX ze arg_tys > ; ctxt <- zonkTcTypesToTypesX ze ctxt > ; res_ty <- zonkTcTypeToTypeX ze res_ty > > ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst) > = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty > > In [2], goldfire claimed that there is a way to work around this problem now: > >> But you can do this. It just has to be before the final zonk. I > see that rejigConRes is used after the final zonk. But there's nothing > about that function that requires things be in their final state. The > arguments need to be zonked, but they can be zonked by zonkTcType and > friends, not zonkTcTypeToType and friends. So, for debugging: zonk > everything with the functions in TcMType (not those in TcHsSyn). Then > rejigConRes. Then print all the output you like. Then do the final > zonk. This double-zonk is redundant, so it's not good to keep going > forward, but it shouldn't cause other trouble. > > Unfortunately, this advice doesn't seem to pan out in practice. I > started off by looking for a TcMType equivalent of this function: > > zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type > > However, I am utterly unable to find anything defined in TcMType with > a similar type signature. Actually, it's worse than that: there isn't > a single mention of ZonkEnv anywhere in TcMType! So as far as I can > tell, this advice is completely unimplementable, unless I'm missing > something obvious. Any tips? > > Ryan S. > ----- > [1] https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc49406/compiler/typecheck/TcTyClsDecls.hs#L2312-2318 > [2] https://phabricator.haskell.org/D4974#137224 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Thu Apr 4 18:55:47 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Apr 2019 14:55:47 -0400 Subject: Debug printing inside the typechecker knot Message-ID: Good to know, thanks. I assume that TcMType.zonkTcTypes is to TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to TcHsType.zonkTyBndrs? Also, what exactly is the optimization that ZonkEnv performs in types? And why don't the functions in TcMType make use of this optimization? Ryan S. From rae at richarde.dev Thu Apr 4 19:05:19 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 4 Apr 2019 15:05:19 -0400 Subject: Debug printing inside the typechecker knot In-Reply-To: References: Message-ID: <5290D1BC-3002-4A9D-98E2-33AA0F181820@richarde.dev> > On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote: > > Good to know, thanks. I assume that TcMType.zonkTcTypes is to > TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to > TcHsType.zonkTyBndrs? No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind. Clearly, it would behoove use to rename these functions to be more systematic. > > Also, what exactly is the optimization that ZonkEnv performs in types? > And why don't the functions in TcMType make use of this optimization? Suppose we have forall (a :: kappa). ... a ... We laboriously discover that kappa should be (Type -> Type). The ZonkEnv stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in the body of the forall, we don't have to repeat the zonk -- we just do a lookup. But, of course, zonking the occurrence of `a` would also work. Why don't we do this in TcMType? There's likely no good reason -- it would be effective there, too. But it would be less effective. The code in TcHsSyn generally starts with *closed* types/terms, meaning that all type variables will be brought into scope somewhere. In contrast, TcMType functions can work over *open* terms, so we have less opportunity to extend the ZonkEnv. Richard > > Ryan S. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Thu Apr 4 19:13:51 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Apr 2019 15:13:51 -0400 Subject: Debug printing inside the typechecker knot In-Reply-To: <5290D1BC-3002-4A9D-98E2-33AA0F181820@richarde.dev> References: <5290D1BC-3002-4A9D-98E2-33AA0F181820@richarde.dev> Message-ID: > No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind. Ah. I was led astray because there is a TcMType.zonkTyCoVarKind function, but not a TcMType.zonkTyCoVarKinds function (with an -s at the end). Similarly strange is that there is a TcHsType.zonkTyBndrs function, but not a TcHsType.zonkTyBndr function (without an -s at the end). Out of curiosity, is a TcHsType counterpart to TcMType.zonkTcTyVar(s)? > Clearly, it would behoove use to rename these functions to be more systematic. Indeed. What would be better names for these? It looks like we've identified at least a couple things that could be cleaned up in TcMType and TcHsType, so if you suggest a more consistent naming scheme, I would be willing to implement it. My eventual goal is to write up this wisdom in a GHC wiki page simply because I keep getting frustrated any time I have to debug code in the typechecker knot, and I'd like to codify this solution somewhere where I can look it up in the future if (when) I eventually forget it. Ryan S. On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg wrote: > > > > > On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote: > > > > Good to know, thanks. I assume that TcMType.zonkTcTypes is to > > TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to > > TcHsType.zonkTyBndrs? > > No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind. > > Clearly, it would behoove use to rename these functions to be more systematic. > > > > > Also, what exactly is the optimization that ZonkEnv performs in types? > > And why don't the functions in TcMType make use of this optimization? > > Suppose we have > > forall (a :: kappa). ... a ... > > We laboriously discover that kappa should be (Type -> Type). The ZonkEnv stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in the body of the forall, we don't have to repeat the zonk -- we just do a lookup. But, of course, zonking the occurrence of `a` would also work. > > Why don't we do this in TcMType? There's likely no good reason -- it would be effective there, too. But it would be less effective. The code in TcHsSyn generally starts with *closed* types/terms, meaning that all type variables will be brought into scope somewhere. In contrast, TcMType functions can work over *open* terms, so we have less opportunity to extend the ZonkEnv. > > Richard > > > > > Ryan S. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From rae at richarde.dev Thu Apr 4 19:33:02 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 4 Apr 2019 15:33:02 -0400 Subject: Debug printing inside the typechecker knot In-Reply-To: References: <5290D1BC-3002-4A9D-98E2-33AA0F181820@richarde.dev> Message-ID: > On Apr 4, 2019, at 3:13 PM, Ryan Scott wrote: > >> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind. > > Ah. I was led astray because there is a TcMType.zonkTyCoVarKind > function, but not a TcMType.zonkTyCoVarKinds function (with an -s at > the end). Similarly strange is that there is a TcHsType.zonkTyBndrs > function, but not a TcHsType.zonkTyBndr function (without an -s at the > end). > > Out of curiosity, is a TcHsType counterpart to TcMType.zonkTcTyVar(s)? Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"? TcHsSyn.zonkTyVarOcc, naturally. :) > >> Clearly, it would behoove use to rename these functions to be more systematic. > > Indeed. What would be better names for these? It looks like we've > identified at least a couple things that could be cleaned up in > TcMType and TcHsType, so if you suggest a more consistent naming > scheme, I would be willing to implement it. No particular wisdom here. We really should just bite the bullet and do this, though. > > My eventual goal is to write up this wisdom in a GHC wiki page simply > because I keep getting frustrated any time I have to debug code in the > typechecker knot, and I'd like to codify this solution somewhere where > I can look it up in the future if (when) I eventually forget it. I will point out that this knot is *much* *much* smaller than it once was. But it's never a bad idea to document more. Richard > > Ryan S. > > On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg wrote: >> >> >> >>> On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote: >>> >>> Good to know, thanks. I assume that TcMType.zonkTcTypes is to >>> TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to >>> TcHsType.zonkTyBndrs? >> >> No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] -- this won't end well. If you look further in zonkTyBndrs, you'll see that it calls `zonkTcTypeToType (tyVarKind tv)` (roughly), making the equivalent to be TcMType.zonkTyCoVarKind. >> >> Clearly, it would behoove use to rename these functions to be more systematic. >> >>> >>> Also, what exactly is the optimization that ZonkEnv performs in types? >>> And why don't the functions in TcMType make use of this optimization? >> >> Suppose we have >> >> forall (a :: kappa). ... a ... >> >> We laboriously discover that kappa should be (Type -> Type). The ZonkEnv stores a mapping (a |-> (a :: Type -> Type)) so that when we spot the `a` in the body of the forall, we don't have to repeat the zonk -- we just do a lookup. But, of course, zonking the occurrence of `a` would also work. >> >> Why don't we do this in TcMType? There's likely no good reason -- it would be effective there, too. But it would be less effective. The code in TcHsSyn generally starts with *closed* types/terms, meaning that all type variables will be brought into scope somewhere. In contrast, TcMType functions can work over *open* terms, so we have less opportunity to extend the ZonkEnv. >> >> Richard >> >>> >>> Ryan S. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From qdunkan at gmail.com Thu Apr 4 21:35:27 2019 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 4 Apr 2019 14:35:27 -0700 Subject: Introducing bugs that are caught by slow validate? In-Reply-To: References: Message-ID: Where I work we use marge, and I wound up adding a patch to run an especially expensive "on merge only" CI run. The two pieces are: - patch marge to add a --require-ci-run-by-me flag, which makes marge want to see a CI completion by margebot and start one otherwise - modify the .gitlab-ci.yml to put the expensive CI under 'only: variables: [$GITLAB_USER_LOGIN == "marge-bot"]' It has the side-effect that marge-bot insists on running an extra CI on each merge (since she no longer wants to reuse your CI run), but since we have caching, we only pay for extra tests implied by the heavy version of the CI run. You could probably get the same thing by making the test outputs shake targets, at which point it should only run tests affected by your changes, and reuse test outputs if there hasn't been a change. I'm not sure if ghc tests do that... but last I recall it was a monolithic "test everything" script that always ran all the tests. On Thu, Apr 4, 2019 at 1:21 AM Ömer Sinan Ağacan wrote: > > Hi all, > > I just run slow validate and it actually catches bugs (#16529) and some > configuration problems in the test definitions (#!700). These are not caught by > the CI jobs because they run normal validate instead of slow. > > (Actually they don't even run the validate script, but they run "test" instead > of "slowtest", which I think is the main difference between normal validate and > slow validate) > > As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do > slow validate, but I'm not sure if those are used? > > Would it be possible to switch over to slow validate in CI jobs? If slow > validate takes too long on the CI servers, could we maybe configure CI tasks so > that if the MR submitter is Marge, we run slow validate, otherwise we run fast > validate? > > The problem with nightly jobs (assuming they're used) is that it's too late by > the time they catch a test failure because the commits are already in the tree, > and because nothing's blocked the bugs are more likely to stay unfixed. > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From rae at richarde.dev Fri Apr 5 02:22:33 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 4 Apr 2019 22:22:33 -0400 Subject: Defining a wired-in type of a different kind In-Reply-To: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> References: <928be264-c648-8a2f-b881-c58217cbccb7@vanbruegge.de> Message-ID: Hi Jan, mkAlgTyCon is good for making an algebraic datatype -- like Maybe or Bool or Either. It's not what you want for RNil, which is really a data constructor. Instead, rowKindCon should be the algebraic datatype, and RNil should be one of its constructors. Then you get the RNil TyCon via promotion, as Matt suggested. I hope this helps! Richard > On Apr 3, 2019, at 7:06 AM, Jan van Brügge wrote: > > > Hi, > > when trying to get familiar with the GHC code base for my Bachelor's > thesis. I followed the GHC Wiki, especially the case study about the > bool type. > Now I wanted to add a new kind and a new type inhabiting this kind > (without having to expose a data constructor, so without datatype > promotion). > > So in TysWiredIn.hs I added the new TyCons and added them to the list of > wired-in types: > > -- data Row a b > rowKindCon :: TyCon > rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] > > rowKind :: Kind > rowKind = mkTyConTy rowKindCon > > -- data RNil :: Row a b > rnilTyCon :: TyCon > rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] > (mkDataTyConRhs []) > (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) > False > > rnilTy :: Type > rnilTy = mkTyConTy rnilTyCon > > > I also added two new empty data decls to ghc-prim, but if I inspect the > kind of RNil it is not Row, but Type. So I think I am either > understanding res_kind wrong or I have to do something completely different. > I am also not sure how to verify that the code in TysWiredIn.hs is > working at all, from all what I can tell it could just be the > declarations in ghc-prim that result in what I see in ghci. > > Thank you and sorry for my beginner question > Jan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Fri Apr 5 05:13:26 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 5 Apr 2019 08:13:26 +0300 Subject: Can Gitlab's "issue was closed by ..." mails be improved? Message-ID: Hi, Currently Gitlab doesn't give any details of why an issue was closed, it just says "Issue was closed by ...". You have to go to the issue page to see that it was closed because of a closing merge request was merged. I'm wondering if this could be improved so that in the email it says "issue was closed by ... via commit ..." or something like that. Anyone know if there's already a ticket for this in Gitlab issue tracker? Ömer From matthewtpickering at gmail.com Fri Apr 5 11:09:21 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 5 Apr 2019 12:09:21 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: Thanks everyone for the lively discussion last week. I think we all understand better now about environment files. GHC reading environment files by default doesn't seem to be a problem as it is just like having more packages installed in the global package DB. This could be convenient. The largest issue with the files is that cabal places relative paths into the environment files which can easily become stale. For example, by deleting the dist-newstyle directory. The absolute paths can also become stale (as Richard discovered). Therefore, it seems the correct course of action is to stop cabal generating the environment files by default. If user's still want to use them then they are easy to enable globally via a configuration setting. This can be achieved by adding the following to your "~/.cabal/config" file: write-ghc-environment-files: always The patch which changes the default behavior is here: https://github.com/haskell/cabal/pull/5985 Cheers, Matt On Fri, Mar 29, 2019 at 4:53 PM Brandon Allbery wrote: > > Nix instead of system, but roughly yes. > > On Fri, Mar 29, 2019 at 5:46 AM Oleg Grenrus wrote: >> >> To clarify: You mean different installations of same-version GHC? E.g. >> /opt/ghc/8.4.4/bin/ghc (HVR's) and /usr/bin/ghc (System default) which >> both happen to be 8.4.4 (so some other version)? >> >> - Oleg >> >> On 29.3.2019 5.44, Brandon Allbery wrote: >> > FWIW I've run into this one myself, and use (clones, if necessary, of) >> > v1 sandboxes for it currently. >> > >> > I've also been both bitten by, and helped by, environment files. The >> > former is somewhat nastier, especially if you have multiple versions >> > of ghc around and a given environment file was generated by a >> > different ghc. >> > >> > I also have a somewhat weird setup, because of how I ended up cobbling >> > this machine together: the global and user package dbs for my default >> > ghc are more or less "owned" by xmonad development, anything else is >> > in v2, a sandbox, or otherwise a different ghc version. Including nix, >> > also operating as a sandbox (that is, I use an alias to set up nix >> > within specific shells, rather than unconditionally loading its >> > config). Plus that "default ghc" is via wrappers around hvr's ghc >> > repos for Ubuntu. Which means I have lots of different ghcs around, >> > depending on which shell window I'm in. Not that I'm expecting anyone >> > to directly support this mess, but environment files seem to play >> > especially badly with multiple ghc versions with different packages >> > installed. >> > >> > On Thu, Mar 28, 2019 at 11:33 PM > > > wrote: >> > >> > >> > > El 28 mar 2019, a las 3:26 PM, Richard Eisenberg >> > escribió: >> > > >> > >> > [...] >> > >> > > 2. I get pilloried every time I say it, but I vastly prefer >> > global package databases to local ones. >> > >> > I'll second this in one specific context. v2-build has been >> > amazing at work and in general for project-based development, but >> > – and maybe simply because I don't know the right incantations – a >> > step backwards for impromptu coding where I don't want to set up a >> > whole project to start messing with an idea. >> > >> > I've actually fallen back to v1-install for this specific usecase: >> > I have a set of ~15 packages, all installed from local git repos, >> > some of which depend on others, that I *always* want when I'm in >> > GHCi. It's basically my base. I may simply be doing it wrong but >> > I've been unable to use the "global ghc.env file" trick successfully. >> > >> > Tom >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > >> > >> > -- >> > brandon s allbery kf8nh >> > allbery.b at gmail.com >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Fri Apr 5 12:34:31 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 5 Apr 2019 08:34:31 -0400 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab Message-ID: Almost every day now I receive an e-mail from GitLab titled "Remote mirror update failed", which contains something like: To ! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot lock ref 'refs/heads/wip/dmd-arity': is at e1cc1254b81a7adadd8db77c7be625497264ab2b but expected f07b61d047967129a3ae0c56f8894d41c5a9b036) error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc' Is there a way to make these stop? Ryan S. From mikhail.glushenkov at gmail.com Fri Apr 5 12:54:57 2019 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Fri, 5 Apr 2019 13:54:57 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <1553797332.22450.39.camel@well-typed.com> <87tvfmizoe.fsf@gmail.com> Message-ID: Hi *, On Fri, 5 Apr 2019 at 12:09, Matthew Pickering wrote: > > [...] > > Therefore, it seems the correct course of action is to stop cabal > generating the environment files by default. If user's still want to > use them then they are easy to enable globally via a configuration > setting. > > This can be achieved by adding the following to your "~/.cabal/config" file: > > write-ghc-environment-files: always Please also note that this can be set per-project in the 'cabal.project' file. This is what we (Scrive AB) use to make ghcid work out of the box for everyone in the team. From ryan.gl.scott at gmail.com Fri Apr 5 13:21:00 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 5 Apr 2019 09:21:00 -0400 Subject: Debug printing inside the typechecker knot Message-ID: > Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"? D'oh. Yes, I did. > But it's never a bad idea to document more. I've documented all the wisdom from here in this wiki page [1]! Feel free to edit it if there are any corrections to be made. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/tying-the-knot/printing From ben at well-typed.com Sat Apr 6 18:28:09 2019 From: ben at well-typed.com (Ben Gamari) Date: Sat, 06 Apr 2019 14:28:09 -0400 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab In-Reply-To: References: Message-ID: <871s2fc7kb.fsf@smart-cactus.org> Ryan Scott writes: > Almost every day now I receive an e-mail from GitLab titled "Remote > mirror update failed", which contains something like: > > To > > ! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot > lock ref 'refs/heads/wip/dmd-arity': is at > e1cc1254b81a7adadd8db77c7be625497264ab2b but expected > f07b61d047967129a3ae0c56f8894d41c5a9b036) > > error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc' > Hmm, how annoying. Strangely, the `wip/dmd-arity` branch currently appears to be sitting at the same commit on GitLab and GitHub so I'm not really sure what to do here. sgraf, did you ever push a branch manually to the github.com/ghc/ghc mirror? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Sat Apr 6 20:02:38 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 6 Apr 2019 16:02:38 -0400 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab In-Reply-To: <871s2fc7kb.fsf@smart-cactus.org> References: <871s2fc7kb.fsf@smart-cactus.org> Message-ID: To be clear, the wip/dmd-arity is not the only branch I've received e-mails about. I've also received "Remove mirror update failed" e-mails of a similar caliber that warn about the wip/slowtest, ghc-8.6, ghc-8.8-merges, wip/marge_bot_batch_merge_job, and master branches. Are you not received these as well? They almost seem to happen any time any commit is landed. Ryan S. On Sat, Apr 6, 2019 at 2:28 PM Ben Gamari wrote: > Ryan Scott writes: > > > Almost every day now I receive an e-mail from GitLab titled "Remote > > mirror update failed", which contains something like: > > > > To > > > > ! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot > > lock ref 'refs/heads/wip/dmd-arity': is at > > e1cc1254b81a7adadd8db77c7be625497264ab2b but expected > > f07b61d047967129a3ae0c56f8894d41c5a9b036) > > > > error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc' > > > Hmm, how annoying. Strangely, the `wip/dmd-arity` branch currently > appears to be sitting at the same commit on GitLab and GitHub so I'm not > really sure what to do here. > > sgraf, did you ever push a branch manually to the github.com/ghc/ghc > mirror? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Sun Apr 7 14:21:51 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 7 Apr 2019 15:21:51 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: <878swzjiew.fsf@gmail.com> References: <878swzjiew.fsf@gmail.com> Message-ID: I've also been surprised (not in a good way) by environment files. But I haven't followed all the discussion so I still have some questions. As I understand it, the aim is to support workflows like "cabal install $pkg; ghci" (amongst other things). This currently works with 'cabal install' because it installs into the global package DB, but it doesn't work with 'cabal new-install' which installs into `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a .ghc-environment file in the current directory, even outside of a cabal package/project? I would find that *very* surprising as a user. Indeed it almost works to say 'ghci -package-db ~/.cabal/store/ghc-8.4.3/package.db` after 'cabal new-install $pkg', but this might fail if there are conflicts in the package DB preventing the use of $pkg. GHC does some not-very-clever constraint solving to end up with a consistent set of packages, and you can guide it by adding '-package $pkg' flags. But it's still not very clever, and might fail. Instead what if we had something like 'cabal ghci -package $pkg' to indicate that you want to start GHCi with $pkg available? It would be Cabal's job to ensure that $pkg was built and made available to GHCi. For more complex cases, you can create a package or a project, but simple ad-hoc invocations would be well supported by this. I suppose I somewhat agree with those who are calling for environment files to require a command-line flag. We've gone to all this trouble to make a nice stateless model for the package DB, but then we've lobbed a stateful UI on top of it, which seems odd and is clearly surprising a lot of people. Cheers Simon On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel wrote: > Matthew, > > I realize this to be a controversial issue, but what you're suggesting > is effectively an attempt at cutting this cabal V2 feature off at the knees > ("If Cabal won't change its default let's cripple this feature on GHC's > side by rendering it pointless to use in cabal"). > > If ghc environment aren't read anymore by default they fail to have > the purpose they were invented for in the first place! > > At the risk of repeating things I've tried to explain already in the > GitHub issue let me motivate (again) why we have these env files: We > want to be able to provide a stateful interface providing the common > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` > already provided in the past; e.g. > > > ,---- > | $ cabal v1-install lens lens-aeson > | > | $ ghc --make MyProgUsingLens.hs > | [1 of 1] ... > | ... > | > | $ ghci > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > | Prelude> import Control.Lens > | Prelude Control.Lens> > `---- > > or similarly, when you had just `cabal v1-build` something, you'd get > access to your projects dependencies which were installed into ghc's > user pkg-db. > > This is also a workflow which has been well documented for over a decade > in Haskell's literature and instructions *and* this is the same idiom as > used by many popular package managers out there ("${pkgmgr} install > somelibrary") > > So `cabal v1-build` made use of the user package-db facility to achieve > this; but now with `cabal v2-build` the goal was to improve this > workflow, but the user pkg-db facility wasn't a good fit anymore for the > nix-style pkg store cache which can easily have dozens instances for the > same lens-4.17 pkg-id cached (I just checked, I currently have 9 > instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). > > So ghc environment files were born as a clever means to provide a > thinned slice/view into the nix-style pkg store. > > And with these we can provide those workflows *without* the needed to pass > extra flags or having to prefix each `ghc` invocation with `cabal > repl`/`cabal exec`: > > ,---- > | $ cabal v2-install --lib lens lens-aeson > | > | $ ghc --make MyProgUsingLens.hs > | Loaded package environment from > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > | [1 of 1] ... > | ... > | > | $ ghci > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > | Loaded package environment from > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > | Prelude> import Control.Lens > | Prelude Control.Lens> > `---- > > (and respectively for the `cabal v2-build` workflow) > > However, if we now had to explicitly pass a flag to ghc in order to have > it pick up ghc env files, this would severly break this workflow > everytime you forget about it, and it would certainly cause a lot of > confusion (of e.g. users following instructions such as `cabal install > lens` and then being confused that GHCi doesn't pick it up) and > therefore a worse user experience for cabal users. > > Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and GHC 8.6 > have been picking up ghc env files by default (and finally we've reached > the point where the pkg-env-file-agnostic GHC versions are old enough to > have moved outside the traditional 3-5 major ghc release > support-windows!), and now you'd have to remember which GHC versions > don't do this anymore and instead require passing an additional > flag. This would IMO translate to a terrible user experience. > > And also tooling would still need to have the logic to "isolate > themselves" for those versions of GHC that picked up env files by > default unless they dropped support for older versions. Also, how much > tooling is there even that needs to be aware of this and how did it cope > with GHC's user pkg db which can easily screw up things as well by > providing a weird enough pkg-db env! And why is it considered such a big > burden for tooling to invoke GHC in a robust enough way to not be > confused by the user's configuration? IMO, shifting the cost of passing > an extra flag to a tool which doesn't feel any pain is the better > tradeoff than to inconvience all cabal users to have rememeber to pass > an additional flag for what is designed to be the default UI/workflow > idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, the Nix > environment which already controls environment vars can easily override > GHC's or cabal's defaults to tailor them more towards Nix's specific > assumptions/requirements. > > > Long story short, I'm -1 on changing GHC's default as the resulting > downsides clearly outweight IMO. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Sun Apr 7 15:57:07 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 7 Apr 2019 18:57:07 +0300 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <878swzjiew.fsf@gmail.com> Message-ID: On 7.4.2019 17.21, Simon Marlow wrote: > I've also been surprised (not in a good way) by environment files. But > I haven't followed all the discussion so I still have some questions. > > As I understand it, the aim is to support workflows like "cabal > install $pkg; ghci" (amongst other things). This currently works with > 'cabal install' because it installs into the global package DB, but it > doesn't work with 'cabal new-install' which installs into > `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a > .ghc-environment file in the current directory, even outside of a > cabal package/project? I would find that *very* surprising as a user. This is not correct. Cabal doesn't write (local) .ghc.environment files when you `cabal v2-install` __outside__ the project (actually it doesn't, even when you `v2-install` the local project either, as you don't build the local project then). - When you install an executable, say `cabal v2-install alex` it do nothing related to environment files (there is inference in reading them atm though) - When you install a library, say `cabal v2-install distributive --lib`, then `cabal` (tries to) update `~/.ghc/-/environments/default` (or specified environment), so following `ghci` or `(ghci -package-env=somename) could pickup that library. For playing with libraries, you can manage multiple environments, and starting over (as you will eventually run into incompatible package versions) isn't as expensive, as packages are still cached in store. This is however a goal, and not yet a reality, due to bugs in cabal: see e.g https://github.com/haskell/cabal/issues/5888 and https://github.com/haskell/cabal/issues/5559 issues. > > Indeed it almost works to say 'ghci -package-db > ~/.cabal/store/ghc-8.4.3/package.db` after 'cabal new-install $pkg', > but this might fail if there are conflicts in the package DB > preventing the use of $pkg. GHC does some not-very-clever constraint > solving to end up with a consistent set of packages, and you can guide > it by adding '-package $pkg' flags. But it's still not very clever, > and might fail. > > Instead what if we had something like 'cabal ghci -package $pkg' to > indicate that you want to start GHCi with $pkg available? It would be > Cabal's job to ensure that $pkg was built and made available to GHCi. > For more complex cases, you can create a package or a project, but > simple ad-hoc invocations would be well supported by this. > Instead of cabal ghci -package $pkg you can do     cabal v2-install $pkg1 --lib --package-env=foo     cabal v2-install $pkg2 --lib --package-env=foo     ...     ghci -package-env=foo Or alternatively     cabal v2-repl -b $pkg Unfortunately neither way is (known) bug free at the moment. I mostly use the former, with the `default` package-env (then I can omit --package-env flags) for all kind of experiments, e.g. to try out things when answering people on `#haskell` or Stack Overflow; but I have my own way to create environment file (i.e. I don't use v2-install --lib), as cabal is atm not perfect, see Cabal's issue 5888. It's however important to note, that `cabal` makes `ghc` ignore these global environments (especially the default one) in builds etc, so `cabal v2-build` works. > I suppose I somewhat agree with those who are calling for environment > files to require a command-line flag. We've gone to all this trouble > to make a nice stateless model for the package DB, but then we've > lobbed a stateful UI on top of it, which seems odd and is clearly > surprising a lot of people. I disagree. I created `~/.ghci` and `~/.../environments/default` because I want some defaults. Note: with v1-install people managed user-package-db, with v2-install you are supposed to manage environment(s). Yet, you can also only use `cabal v2-repl` or `cabal v2-run` (See "new-run also supports running script files that ..." in https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run). Most of the above works (sans known bugs), and if you run Ubuntu, I invite you to try it out, as it's easy to install from Herbert's PPA: https://launchpad.net/~hvr/+archive/ubuntu/ghc > > Cheers > Simon > > On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel > > wrote: > > Matthew, > > I realize this to be a controversial issue, but what you're suggesting > is effectively an attempt at cutting this cabal V2 feature off at > the knees > ("If Cabal won't change its default let's cripple this feature on > GHC's > side by rendering it pointless to use in cabal"). > > If ghc environment aren't read anymore by default they fail to have > the purpose they were invented for in the first place! > > At the risk of repeating things I've tried to explain already in the > GitHub issue let me motivate (again) why we have these env files: We > want to be able to provide a stateful interface providing the common > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` > already provided in the past; e.g. > > > ,---- > | $ cabal v1-install lens lens-aeson > | > | $ ghc --make MyProgUsingLens.hs > | [1 of 1] ... > | ... > | > | $ ghci > | GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help > | Prelude> import Control.Lens > | Prelude Control.Lens> > `---- > > or similarly, when you had just `cabal v1-build` something, you'd get > access to your projects dependencies which were installed into ghc's > user pkg-db. > > This is also a workflow which has been well documented for over a > decade > in Haskell's literature and instructions *and* this is the same > idiom as > used by many popular package managers out there ("${pkgmgr} install > somelibrary") > > So `cabal v1-build` made use of the user package-db facility to > achieve > this; but now with `cabal v2-build` the goal was to improve this > workflow, but the user pkg-db facility wasn't a good fit anymore > for the > nix-style pkg store cache which can easily have dozens instances > for the > same lens-4.17 pkg-id cached (I just checked, I currently have 9 > instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). > > So ghc environment files were born as a clever means to provide a > thinned slice/view into the nix-style pkg store. > > And with these we can provide those workflows *without* the needed > to pass > extra flags or having to prefix each `ghc` invocation with `cabal > repl`/`cabal exec`: > > ,---- > | $ cabal v2-install --lib lens lens-aeson > | > | $ ghc --make MyProgUsingLens.hs > | Loaded package environment from > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > | [1 of 1] ... > | ... > | > | $ ghci > | GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help > | Loaded package environment from > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > | Prelude> import Control.Lens > | Prelude Control.Lens> > `---- > > (and respectively for the `cabal v2-build` workflow) > > However, if we now had to explicitly pass a flag to ghc in order > to have > it pick up ghc env files, this would severly break this workflow > everytime you forget about it, and it would certainly cause a lot of > confusion (of e.g. users following instructions such as `cabal install > lens` and then being confused that GHCi doesn't pick it up) and > therefore a worse user experience for cabal users. > > Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and > GHC 8.6 > have been picking up ghc env files by default (and finally we've > reached > the point where the pkg-env-file-agnostic GHC versions are old > enough to > have moved outside the traditional 3-5 major ghc release > support-windows!), and now you'd have to remember which GHC versions > don't do this anymore and instead require passing an additional > flag. This would IMO translate to a terrible user experience. > > And also tooling would still need to have the logic to "isolate > themselves" for those versions of GHC that picked up env files by > default unless they dropped support for older versions. Also, how much > tooling is there even that needs to be aware of this and how did > it cope > with GHC's user pkg db which can easily screw up things as well by > providing a weird enough pkg-db env! And why is it considered such > a big > burden for tooling to invoke GHC in a robust enough way to not be > confused by the user's configuration? IMO, shifting the cost of > passing > an extra flag to a tool which doesn't feel any pain is the better > tradeoff than to inconvience all cabal users to have rememeber to pass > an additional flag for what is designed to be the default UI/workflow > idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, > the Nix > environment which already controls environment vars can easily > override > GHC's or cabal's defaults to tailor them more towards Nix's specific > assumptions/requirements. > > > Long story short, I'm -1 on changing GHC's default as the resulting > downsides clearly outweight IMO. > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From chessai1996 at gmail.com Sun Apr 7 16:41:49 2019 From: chessai1996 at gmail.com (chessai .) Date: Sun, 7 Apr 2019 12:41:49 -0400 Subject: Recover role of a type variable in source Haskell Message-ID: Hi devs, Is it possible to programmatically recover the role of a type variable? Or, possibly, a list of the roles of the type variables from left to right? For example, if i have: data Foo a = Foo (1) newtype Bar a b = Bar (a -> b) (1) Getting the role list of (1) would give me [Phantom], and (2) would give me [Representational, Representational]. I know in compiler/types/TyCon.hs that TyCon has a list of Roles in it, but there doesn't seem to be any machinery available to do this in source haskell. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiss.csongor.kiss at gmail.com Sun Apr 7 16:45:07 2019 From: kiss.csongor.kiss at gmail.com (Csongor Kiss) Date: Sun, 7 Apr 2019 17:45:07 +0100 Subject: Recover role of a type variable in source Haskell In-Reply-To: References: Message-ID: <7521B054-9071-4F41-B9EC-B8CF8360E340@gmail.com> Hi chessai, It is indeed not possible in source Haskell at the moment. Cheers, Csongor > On 7 Apr 2019, at 17:41, chessai . wrote: > > Hi devs, > > Is it possible to programmatically recover the role of a type variable? > > Or, possibly, a list of the roles of the type variables from left to right? > > For example, if i have: > > data Foo a = Foo (1) > newtype Bar a b = Bar (a -> b) (1) > > Getting the role list of (1) would give me [Phantom], and (2) would give me [Representational, Representational]. > > I know in compiler/types/TyCon.hs that TyCon has a list of Roles in it, but there doesn't seem to be any machinery available to do this in source haskell. > > Thanks > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Sun Apr 7 19:30:26 2019 From: ben at well-typed.com (Ben Gamari) Date: Sun, 07 Apr 2019 15:30:26 -0400 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab In-Reply-To: References: <871s2fc7kb.fsf@smart-cactus.org> Message-ID: <87y34lboky.fsf@smart-cactus.org> Ryan Scott writes: > To be clear, the wip/dmd-arity is not the only branch I've received e-mails > about. I've also received "Remove mirror update failed" e-mails of a > similar caliber that warn about the wip/slowtest, ghc-8.6, ghc-8.8-merges, > wip/marge_bot_batch_merge_job, and master branches. > > Are you not received these as well? They almost seem to happen any time any > commit is landed. > Strangely I'm not. I did receive a number of similar emails for other repositories in March but I have not received any recently and never any concerning ghc/ghc. This is extremely strange given that I created the project and we both have maintainer role. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Sun Apr 7 21:06:15 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 7 Apr 2019 17:06:15 -0400 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab In-Reply-To: <87y34lboky.fsf@smart-cactus.org> References: <871s2fc7kb.fsf@smart-cactus.org> <87y34lboky.fsf@smart-cactus.org> Message-ID: This GitLab CE issue seems relevant: [1] (I'm writing this just as I receive another "Remote mirror update failed" e-mail, this time about the wip/lint-check-version-number branch.) Ryan S. ----- [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/56222 On Sun, Apr 7, 2019 at 3:30 PM Ben Gamari wrote: > Ryan Scott writes: > > > To be clear, the wip/dmd-arity is not the only branch I've received > e-mails > > about. I've also received "Remove mirror update failed" e-mails of a > > similar caliber that warn about the wip/slowtest, ghc-8.6, > ghc-8.8-merges, > > wip/marge_bot_batch_merge_job, and master branches. > > > > Are you not received these as well? They almost seem to happen any time > any > > commit is landed. > > > Strangely I'm not. I did receive a number of similar emails for other > repositories in March but I have not received any recently and never any > concerning ghc/ghc. This is extremely strange given that I created the > project and we both have maintainer role. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Sun Apr 7 21:10:46 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 7 Apr 2019 17:10:46 -0400 Subject: Recover role of a type variable in source Haskell Message-ID: It depends on what you mean by "source Haskell". If you're willing to consider including Template Haskell in your definition of "source", then the answer is yes, since there is a reifyRoles function [1] which gives you this information. I'm not aware of another way to accomplish this (without resorting to something like the GHC API). Ryan S. ----- [1] https://hackage.haskell.org/package/template-haskell-2.14.0.0/docs/Language-Haskell-TH.html#v:reifyRoles -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Apr 8 07:19:58 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 8 Apr 2019 08:19:58 +0100 Subject: Proposal: Don't read environment files by default In-Reply-To: References: <878swzjiew.fsf@gmail.com> Message-ID: On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus wrote: > > On 7.4.2019 17.21, Simon Marlow wrote: > > As I understand it, the aim is to support workflows like "cabal > > install $pkg; ghci" (amongst other things). This currently works with > > 'cabal install' because it installs into the global package DB, but it > > doesn't work with 'cabal new-install' which installs into > > `~/.cabal/store`. Is the plan that 'cabal new-install' will drop a > > .ghc-environment file in the current directory, even outside of a > > cabal package/project? I would find that *very* surprising as a user. > > This is not correct. Well, it was a question :) > Cabal doesn't write (local) .ghc.environment files > when you `cabal v2-install` __outside__ the project (actually it > doesn't, even when you `v2-install` the local project either, as you > don't build the local project then). > - When you install an executable, say `cabal v2-install alex` it do > nothing related to environment files (there is inference in reading them > atm though) > - When you install a library, say `cabal v2-install distributive --lib`, > then `cabal` (tries to) update > `~/.ghc/-/environments/default` (or specified > environment), so following > `ghci` or `(ghci -package-env=somename) could pickup that library. > Thanks, I wasn't aware of the default environment file. Seems perfectly reasonable to me. > Instead of cabal ghci -package $pkg you can do > > cabal v2-install $pkg1 --lib --package-env=foo > cabal v2-install $pkg2 --lib --package-env=foo > ... > ghci -package-env=foo > > Or alternatively > > cabal v2-repl -b $pkg > > Unfortunately neither way is (known) bug free at the moment. I mostly > use the former, with the `default` package-env (then I can omit > --package-env flags) for all kind of experiments, e.g. to try out things > when answering people on `#haskell` or Stack Overflow; but I have my own > way to create environment file (i.e. I don't use v2-install --lib), as > cabal is atm not perfect, see Cabal's issue 5888. It's however important > to note, that `cabal` makes `ghc` ignore these global environments > (especially the default one) in builds etc, so `cabal v2-build` works. > This all sounds good to me. I hope you can work out the bugs! Cheers Simon > I suppose I somewhat agree with those who are calling for environment > > files to require a command-line flag. We've gone to all this trouble > > to make a nice stateless model for the package DB, but then we've > > lobbed a stateful UI on top of it, which seems odd and is clearly > > surprising a lot of people. > > I disagree. I created `~/.ghci` and `~/.../environments/default` because > I want some defaults. Note: with v1-install people managed > user-package-db, with v2-install you are supposed to manage > environment(s). Yet, you can also only use `cabal v2-repl` or `cabal > v2-run` (See "new-run also supports running script files that ..." in > https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-new-run > ). > > Most of the above works (sans known bugs), and if you run Ubuntu, I > invite you to try it out, as it's easy to install from Herbert's PPA: > https://launchpad.net/~hvr/+archive/ubuntu/ghc > > > > > Cheers > > Simon > > > > On Thu, 28 Mar 2019 at 12:25, Herbert Valerio Riedel > > > wrote: > > > > Matthew, > > > > I realize this to be a controversial issue, but what you're > suggesting > > is effectively an attempt at cutting this cabal V2 feature off at > > the knees > > ("If Cabal won't change its default let's cripple this feature on > > GHC's > > side by rendering it pointless to use in cabal"). > > > > If ghc environment aren't read anymore by default they fail to have > > the purpose they were invented for in the first place! > > > > At the risk of repeating things I've tried to explain already in the > > GitHub issue let me motivate (again) why we have these env files: We > > want to be able to provide a stateful interface providing the common > > idiom users from non-Nix UIs are used to, and which `cabal` and `ghc` > > already provided in the past; e.g. > > > > > > ,---- > > | $ cabal v1-install lens lens-aeson > > | > > | $ ghc --make MyProgUsingLens.hs > > | [1 of 1] ... > > | ... > > | > > | $ ghci > > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > > | Prelude> import Control.Lens > > | Prelude Control.Lens> > > `---- > > > > or similarly, when you had just `cabal v1-build` something, you'd get > > access to your projects dependencies which were installed into ghc's > > user pkg-db. > > > > This is also a workflow which has been well documented for over a > > decade > > in Haskell's literature and instructions *and* this is the same > > idiom as > > used by many popular package managers out there ("${pkgmgr} install > > somelibrary") > > > > So `cabal v1-build` made use of the user package-db facility to > > achieve > > this; but now with `cabal v2-build` the goal was to improve this > > workflow, but the user pkg-db facility wasn't a good fit anymore > > for the > > nix-style pkg store cache which can easily have dozens instances > > for the > > same lens-4.17 pkg-id cached (I just checked, I currently have 9 > > instances of `lens-4.17` cached in my GHC 8.4.4 pkg store). > > > > So ghc environment files were born as a clever means to provide a > > thinned slice/view into the nix-style pkg store. > > > > And with these we can provide those workflows *without* the needed > > to pass > > extra flags or having to prefix each `ghc` invocation with `cabal > > repl`/`cabal exec`: > > > > ,---- > > | $ cabal v2-install --lib lens lens-aeson > > | > > | $ ghc --make MyProgUsingLens.hs > > | Loaded package environment from > > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > > | [1 of 1] ... > > | ... > > | > > | $ ghci > > | GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > > | Loaded package environment from > > /home/hvr/.ghc/x86_64-linux-8.4.4/environments/default > > | Prelude> import Control.Lens > > | Prelude Control.Lens> > > `---- > > > > (and respectively for the `cabal v2-build` workflow) > > > > However, if we now had to explicitly pass a flag to ghc in order > > to have > > it pick up ghc env files, this would severly break this workflow > > everytime you forget about it, and it would certainly cause a lot of > > confusion (of e.g. users following instructions such as `cabal > install > > lens` and then being confused that GHCi doesn't pick it up) and > > therefore a worse user experience for cabal users. > > > > Even more confusing is that GHCs GHC 8.0, GHC 8.2, GHC 8.4, and > > GHC 8.6 > > have been picking up ghc env files by default (and finally we've > > reached > > the point where the pkg-env-file-agnostic GHC versions are old > > enough to > > have moved outside the traditional 3-5 major ghc release > > support-windows!), and now you'd have to remember which GHC versions > > don't do this anymore and instead require passing an additional > > flag. This would IMO translate to a terrible user experience. > > > > And also tooling would still need to have the logic to "isolate > > themselves" for those versions of GHC that picked up env files by > > default unless they dropped support for older versions. Also, how > much > > tooling is there even that needs to be aware of this and how did > > it cope > > with GHC's user pkg db which can easily screw up things as well by > > providing a weird enough pkg-db env! And why is it considered such > > a big > > burden for tooling to invoke GHC in a robust enough way to not be > > confused by the user's configuration? IMO, shifting the cost of > > passing > > an extra flag to a tool which doesn't feel any pain is the better > > tradeoff than to inconvience all cabal users to have rememeber to > pass > > an additional flag for what is designed to be the default UI/workflow > > idiom of cabal. And if we're talking of e.g. Cabal/NixOs users, > > the Nix > > environment which already controls environment vars can easily > > override > > GHC's or cabal's defaults to tailor them more towards Nix's specific > > assumptions/requirements. > > > > > > Long story short, I'm -1 on changing GHC's default as the resulting > > downsides clearly outweight IMO. > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Mon Apr 8 12:08:25 2019 From: me at ara.io (Ara Adkins) Date: Mon, 8 Apr 2019 13:08:25 +0100 Subject: Merge Request Submission Confusion Message-ID: Hey all, I'm trying to submit a minor MR as described on the wiki [0]. I can't seem to find the mentioned 'New Merge Request' button, however. Do I need a specific set of permissions to open MRs? Any pointers would be appreciated. Best, _ara [0] https://gitlab.haskell.org/ghc/ghc/wikis/home#opening-a-merge-request From ben at smart-cactus.org Mon Apr 8 12:56:04 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 08 Apr 2019 08:56:04 -0400 Subject: Merge Request Submission Confusion In-Reply-To: References: Message-ID: <87tvf8bqqo.fsf@smart-cactus.org> Ara Adkins writes: > Hey all, > > I'm trying to submit a minor MR as described on the wiki [0]. I can't > seem to find the mentioned 'New Merge Request' button, however. Do I > need a specific set of permissions to open MRs? > > Any pointers would be appreciated. > Do you see a "New merge request" button in the top right (below the navigation bar) of this page [1]? You can also navigate to any page under the ghc/ghc project and there should be a "New merge request" entry under the "+" menu in the navbar. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From me at ara.io Mon Apr 8 13:06:17 2019 From: me at ara.io (Ara Adkins) Date: Mon, 8 Apr 2019 14:06:17 +0100 Subject: Merge Request Submission Confusion In-Reply-To: <87tvf8bqqo.fsf@smart-cactus.org> References: <87tvf8bqqo.fsf@smart-cactus.org> Message-ID: I don't, which is the curious thing. There's just a gap above the filter dropdown where it should be. On Mon, 8 Apr 2019 at 13:56, Ben Gamari wrote: > > Ara Adkins writes: > > > Hey all, > > > > I'm trying to submit a minor MR as described on the wiki [0]. I can't > > seem to find the mentioned 'New Merge Request' button, however. Do I > > need a specific set of permissions to open MRs? > > > > Any pointers would be appreciated. > > > Do you see a "New merge request" button in the top right (below the > navigation bar) of this page [1]? > > You can also navigate to any page under the ghc/ghc project and there > should be a "New merge request" entry under the "+" menu in the navbar. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/merge_requests From sylvain at haskus.fr Mon Apr 8 13:21:48 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 8 Apr 2019 15:21:48 +0200 Subject: CI execution Message-ID: Hi devs, It seems that the CI doesn't check branches in GHC forks on Gitlab anymore. Is is intentional? Is there a way to trigger a CI execution manually on a specific branch? Thanks, Sylvain From matthewtpickering at gmail.com Mon Apr 8 13:57:32 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 8 Apr 2019 14:57:32 +0100 Subject: CI execution In-Reply-To: References: Message-ID: Yes, this is an consequence of a bug in gitlab which meant that pushes to branches which were also MRs were built twice. I'm not sure there is a way to manually trigger the CI pipeline. If you really want to you could modify the .gitlab-ci.yml file on your branch. If you want your commit to be built you could make a MR? Cheers, Matt On Mon, Apr 8, 2019 at 2:22 PM Sylvain Henry wrote: > > Hi devs, > > It seems that the CI doesn't check branches in GHC forks on Gitlab > anymore. Is is intentional? Is there a way to trigger a CI execution > manually on a specific branch? > > Thanks, > Sylvain > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sylvain at haskus.fr Mon Apr 8 14:16:24 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 8 Apr 2019 16:16:24 +0200 Subject: CI execution In-Reply-To: References: Message-ID: <74742e78-f309-e955-c52a-a5b89ff5e6f0@haskus.fr> > Yes, this is an consequence of a bug in gitlab which meant that pushes > to branches which were also MRs were built twice. Oh ok! > If you want your commit to be built you could make a MR? I don't like the idea of submitting a MR just to test some code. It isn't a merge request yet, yet I would like to check that I don't break something on platforms I don't have access to and check for performance regressions. > I'm not sure there is a way to manually trigger the CI pipeline. If > you really want to you could modify the .gitlab-ci.yml file on your > branch. I've just read on [1] that we can allow this. Hence: https://gitlab.haskell.org/ghc/ghc/merge_requests/730 Cheers, Sylvain [1] https://docs.gitlab.com/ee/ci/yaml/#using-your-own-runners On 08/04/2019 15:57, Matthew Pickering wrote: > Yes, this is an consequence of a bug in gitlab which meant that pushes > to branches which were also MRs were built twice. > > I'm not sure there is a way to manually trigger the CI pipeline. If > you really want to you could modify the .gitlab-ci.yml file on your > branch. > > If you want your commit to be built you could make a MR? > > Cheers, > > Matt > > > On Mon, Apr 8, 2019 at 2:22 PM Sylvain Henry wrote: >> Hi devs, >> >> It seems that the CI doesn't check branches in GHC forks on Gitlab >> anymore. Is is intentional? Is there a way to trigger a CI execution >> manually on a specific branch? >> >> Thanks, >> Sylvain >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Mon Apr 8 18:22:02 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 08 Apr 2019 14:22:02 -0400 Subject: Merge Request Submission Confusion In-Reply-To: References: <87tvf8bqqo.fsf@smart-cactus.org> Message-ID: <87pnpwbbnf.fsf@smart-cactus.org> Ara Adkins writes: > I don't, which is the curious thing. There's just a gap above the > filter dropdown where it should be. > Hmm, it's possible this is related to the fact that you had only reporter privileges. I just gave you the developer role; have things changed at all? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Apr 8 18:28:06 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 08 Apr 2019 14:28:06 -0400 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available Message-ID: <87o95gbbd8.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the first release candidate of 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5-rc1 This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. As always, if anything looks amiss do let us know. Happy testing! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From asr at eafit.edu.co Mon Apr 8 19:00:27 2019 From: asr at eafit.edu.co (Andres Sicard Ramirez) Date: Mon, 8 Apr 2019 19:00:27 +0000 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: <87o95gbbd8.fsf@smart-cactus.org> References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: Hi Ben, Using https://downloads.haskell.org/ghc/8.6.5-rc1/ghc-8.6.4.20190406-x86_64-deb8-linux.tar.xz I running as usual $ ./configure --prefix= $ make install I got the following error: ./template-haskell.cabal has been changed. Re-configuring with most recently used options. If this fails, please run configure manually. Configuring template-haskell-2.14.0.0... ghc-cabal: Cannot find the program 'ghc'. User-specified path '/builds/ghc/ghc/inplace/bin/ghc-stage1' does not refer to an executable and the program is not on the system path. ghc.mk:985: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 1 Makefile:51: recipe for target 'install' failed make: *** [install] Error 2 Best, On Mon, 8 Apr 2019 at 13:28, Ben Gamari wrote: > > Hello everyone, > > The GHC team is proud to announce the first release candidate of 8.6.5. > The source distribution, binary distributions, and documentation are > available at > > https://downloads.haskell.org/~ghc/8.6.5-rc1 > > This release fixes a handful of issues with 8.6.4: > > - Binary distributions once again ship with Haddock documentation including > syntax highlighted source of core libraries (#16445) > > - A build system issue where use of GCC with `-flto` broke `configure` > was fixed (#16440) > > - An bug affecting Windows platforms wherein XMM register values could be > mangled when entering STG has been fixed (#16514) > > - Several Windows packaging issues resulting from the recent CI rework. > (#16408, #16398, #16516) > > Since this is a relatively small bugfix release we are bypassing the > alpha releases and moving right to the release candidate stage. If all > goes well the final release will be cut next week. > > As always, if anything looks amiss do let us know. > > Happy testing! > > Cheers, > > - Ben > La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Andrés From me at ara.io Mon Apr 8 19:05:12 2019 From: me at ara.io (Ara Adkins) Date: Mon, 8 Apr 2019 20:05:12 +0100 Subject: Merge Request Submission Confusion In-Reply-To: <87pnpwbbnf.fsf@smart-cactus.org> References: <87tvf8bqqo.fsf@smart-cactus.org> <87pnpwbbnf.fsf@smart-cactus.org> Message-ID: Thanks so much Ben! That seems to have done the trick. Unfortunately I seem to have hit another hurdle, as my fork doesn't seem to be in the list of potential sources at all [0]. Similarly if I try and start the MR from within my fork, the only target is my fork. It's like it's lost its parent relationship to the main GHC repo. Any idea why that would be? I did fork quite a while back, so maybe something got borked in one of the various GitLab upgrade snafus. I tried to delete the fork and fork again, figuring that I could just push my changes from my local, but the deletion has failed with "This project was scheduled for deletion, but failed with the following message: Permission denied @ rb_sysopen - /var/lib/acme/gitlab.haskell.org/registry-auth.key " Remarkably odd. Sorry to load all these things onto your plate! Best, _ara [0] https://gitlab.haskell.org/iamrecursion/ghc On Mon, 8 Apr 2019 at 19:22, Ben Gamari wrote: > > Ara Adkins writes: > > > I don't, which is the curious thing. There's just a gap above the > > filter dropdown where it should be. > > > Hmm, it's possible this is related to the fact that you had only > reporter privileges. I just gave you the developer role; have things > changed at all? > > Cheers, > > - Ben > From asr at eafit.edu.co Mon Apr 8 19:09:17 2019 From: asr at eafit.edu.co (Andres Sicard Ramirez) Date: Mon, 8 Apr 2019 19:09:17 +0000 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: Hi Ben, On Mon, 8 Apr 2019 at 13:59, Andrés Sicard-Ramírez wrote: > Using https://downloads.haskell.org/ghc/8.6.5-rc1/ghc-8.6.4.20190406-x86_64-deb8-linux.tar.xz > I running as usual > > $ ./configure --prefix= > $ make install > > I got the following error: > > ./template-haskell.cabal has been changed. Re-configuring with most recently > used options. If this fails, please run configure manually. > Configuring template-haskell-2.14.0.0... > ghc-cabal: Cannot find the program 'ghc'. User-specified path > '/builds/ghc/ghc/inplace/bin/ghc-stage1' does not refer to an executable and > the program is not on the system path. > > ghc.mk:985: recipe for target 'install_packages' failed > make[1]: *** [install_packages] Error 1 > Makefile:51: recipe for target 'install' failed > make: *** [install] Error 2 > I could install the release candidate. There was a problem with my path. Sorry for the noise. Best, -- Andrés From pi.boy.travis at gmail.com Mon Apr 8 19:55:18 2019 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Mon, 8 Apr 2019 12:55:18 -0700 Subject: Validation Failures on aarch64 Message-ID: Hello GHC devs, When attempting to validate a patch on aarch64, it seems there are a large number of validation failures: SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC 0:15:35 spent to go through 6890 total tests, which gave rise to 17169 test cases, of which 10018 were skipped 41 had missing libraries 3151 expected passes 150 expected failures 11 caused framework failures 0 caused framework warnings 0 unexpected passes 3798 unexpected failures 0 unexpected stat failures The failures seem consistent on recent-ish master, specifically the neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be expected? Thanks, Travis Whitaker -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Apr 8 20:09:45 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 8 Apr 2019 21:09:45 +0100 Subject: Validation Failures on aarch64 In-Reply-To: References: Message-ID: What kinds of tests are failing? Have they always failed? On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker wrote: > > Hello GHC devs, > > When attempting to validate a patch on aarch64, it seems there are a large number of validation failures: > > SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC > 0:15:35 spent to go through > 6890 total tests, which gave rise to > 17169 test cases, of which > 10018 were skipped > 41 had missing libraries > 3151 expected passes > 150 expected failures > 11 caused framework failures > 0 caused framework warnings > 0 unexpected passes > 3798 unexpected failures > 0 unexpected stat failures > > The failures seem consistent on recent-ish master, specifically the neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be expected? > > Thanks, > > Travis Whitaker > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From lonetiger at gmail.com Mon Apr 8 20:26:21 2019 From: lonetiger at gmail.com (Phyx) Date: Mon, 8 Apr 2019 21:26:21 +0100 Subject: Validation Failures on aarch64 In-Reply-To: References: Message-ID: Just a wild guess, but considering the time it's taken to run through the testsuite you're running it on a reasonable AArch64 machine. You may be hitting the weak memory ordering bugs https://gitlab.haskell.org/ghc/ghc/issues/15449 , though I haven't followed the ticket very closely... On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker wrote: > Hello GHC devs, > > When attempting to validate a patch on aarch64, it seems there are a large > number of validation failures: > > SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC > 0:15:35 spent to go through > 6890 total tests, which gave rise to > 17169 test cases, of which > 10018 were skipped > 41 had missing libraries > 3151 expected passes > 150 expected failures > 11 caused framework failures > 0 caused framework warnings > 0 unexpected passes > 3798 unexpected failures > 0 unexpected stat failures > > The failures seem consistent on recent-ish master, specifically the > neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be > expected? > > Thanks, > > Travis Whitaker > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi.boy.travis at gmail.com Mon Apr 8 20:29:07 2019 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Mon, 8 Apr 2019 13:29:07 -0700 Subject: Validation Failures on aarch64 In-Reply-To: References: Message-ID: The patch I’m validating is actually to fix those memory barrier issues. It turns out these failures were all due to GHC complaining about the LLVM version on stderr; sorry for rubber ducking the list! On Mon, Apr 8, 2019 at 1:26 PM Phyx wrote: > Just a wild guess, but considering the time it's taken to run through the > testsuite you're running it on a reasonable AArch64 machine. > You may be hitting the weak memory ordering bugs > https://gitlab.haskell.org/ghc/ghc/issues/15449 , though I haven't > followed the ticket very closely... > > On Mon, Apr 8, 2019 at 8:55 PM Travis Whitaker > wrote: > >> Hello GHC devs, >> >> When attempting to validate a patch on aarch64, it seems there are a >> large number of validation failures: >> >> SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC >> 0:15:35 spent to go through >> 6890 total tests, which gave rise to >> 17169 test cases, of which >> 10018 were skipped >> 41 had missing libraries >> 3151 expected passes >> 150 expected failures >> 11 caused framework failures >> 0 caused framework warnings >> 0 unexpected passes >> 3798 unexpected failures >> 0 unexpected stat failures >> >> The failures seem consistent on recent-ish master, specifically the >> neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be >> expected? >> >> Thanks, >> >> Travis Whitaker >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Mon Apr 8 20:56:32 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 8 Apr 2019 16:56:32 -0400 Subject: Merge Request Submission Confusion In-Reply-To: <87pnpwbbnf.fsf@smart-cactus.org> References: <87tvf8bqqo.fsf@smart-cactus.org> <87pnpwbbnf.fsf@smart-cactus.org> Message-ID: On Mon, 8 Apr 2019 at 14:22 Ben Gamari wrote: > Ara Adkins writes: > > > I don't, which is the curious thing. There's just a gap above the > > filter dropdown where it should be. > > > Hmm, it's possible this is related to the fact that you had only > reporter privileges. Just a datapoint here: I have only Reporter rights, and I do see "New Merge Request" button on the "Merge Requests" page of the ghc/ghc project. And I'm pretty sure I had it back when I didn't have any (non-trivial) permissions. -- Best, Artem > I just gave you the developer role; have things > changed at all? > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Mon Apr 8 20:57:31 2019 From: me at ara.io (Ara Adkins) Date: Mon, 8 Apr 2019 21:57:31 +0100 Subject: Merge Request Submission Confusion In-Reply-To: References: <87tvf8bqqo.fsf@smart-cactus.org> <87pnpwbbnf.fsf@smart-cactus.org> Message-ID: Perhaps the current 'my fork is not available' mess is actually the root cause, then? On Mon, 8 Apr 2019 at 21:56, Artem Pelenitsyn wrote: > > On Mon, 8 Apr 2019 at 14:22 Ben Gamari wrote: >> >> Ara Adkins writes: >> >> > I don't, which is the curious thing. There's just a gap above the >> > filter dropdown where it should be. >> > >> Hmm, it's possible this is related to the fact that you had only >> reporter privileges. > > > Just a datapoint here: I have only Reporter rights, and I do see "New Merge Request" button on the "Merge Requests" page of the ghc/ghc project. And I'm pretty sure I had it back when I didn't have any (non-trivial) permissions. > > -- > Best, Artem > > >> >> I just gave you the developer role; have things >> changed at all? >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From juhpetersen at gmail.com Tue Apr 9 04:54:24 2019 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 9 Apr 2019 12:54:24 +0800 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: <87o95gbbd8.fsf@smart-cactus.org> References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: On Tue, 9 Apr 2019 at 02:28, Ben Gamari wrote: > The GHC team is proud to announce the first release candidate of 8.6.5. > The source distribution, binary distributions, and documentation are > available at > https://downloads.haskell.org/~ghc/8.6.5-rc1 I don't see any source tarball... Jens From merijn at inconsistent.nl Tue Apr 9 09:01:44 2019 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Tue, 9 Apr 2019 11:01:44 +0200 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: <87o95gbbd8.fsf@smart-cactus.org> References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: <2CE8C97B-D5DE-49F1-947A-A8014E4FA90B@inconsistent.nl> There doesn't appear to be a bindist for CentOS 7 (nor for 8.6.4, despite 8.6.3 having one). Cheers, Merijn > On 8 Apr 2019, at 20:28, Ben Gamari wrote: > > Signed PGP part > Hello everyone, > > The GHC team is proud to announce the first release candidate of 8.6.5. > The source distribution, binary distributions, and documentation are > available at > > https://downloads.haskell.org/~ghc/8.6.5-rc1 > > This release fixes a handful of issues with 8.6.4: > > - Binary distributions once again ship with Haddock documentation including > syntax highlighted source of core libraries (#16445) > > - A build system issue where use of GCC with `-flto` broke `configure` > was fixed (#16440) > > - An bug affecting Windows platforms wherein XMM register values could be > mangled when entering STG has been fixed (#16514) > > - Several Windows packaging issues resulting from the recent CI rework. > (#16408, #16398, #16516) > > Since this is a relatively small bugfix release we are bypassing the > alpha releases and moving right to the release candidate stage. If all > goes well the final release will be cut next week. > > As always, if anything looks amiss do let us know. > > Happy testing! > > Cheers, > > - Ben > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From matthewtpickering at gmail.com Tue Apr 9 09:17:09 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 9 Apr 2019 10:17:09 +0100 Subject: Losing (parallel) sleep over module dependencies Message-ID: Hi all, I get worried quite often about the interaction of two facts 1. Adding a new dependency to a module is easy. 2. Adding a new dependency changes the build graph and potentially reduces the amount of parallelism which the build is capable of. Has anyone thought of any strategies to analyse the dependency graph of GHC so that a linter can be created to warn against any changes which create dependencies which affect the parallelism? hs-boot files make this issue even worse I think but I'm not sure of the precise recompilation semantics. It would be quite straight forward to index ghc as it is being built to create a dependency graph (at the identifier) level but it's unclear to me whether it is possible to do anything productive with this information. Cheers, Matt From rsx at bluewin.ch Tue Apr 9 10:20:07 2019 From: rsx at bluewin.ch (Roland Senn) Date: Tue, 09 Apr 2019 12:20:07 +0200 Subject: Unable to build a profiled version of GHC Head Message-ID: <1554805207.23913.1.camel@bluewin.ch> Hi, I'm unable to build a profiled version of GHC Head. I did:   git clone --recursive https://gitlab.haskell.org/ghc/ghc ghcprof   cd ghcprof   git remote set-url --add origin https://gitlab.haskell.org/RolandSenn/ghc   git remote set-url --delete origin https://gitlab.haskell.org/ghc/ghc   git remote add upstream https://gitlab.haskell.org/ghc/ghc   git fetch upstream   git push origin master   hadrian/build.sh -c --flavour=prof -j2 I get the follwoing failure:   ...   | Run Ghc CompileCWithGhc Stage1: utils/hp2ps/Utilities.c => _build/stage1/utils/hp2ps/build/c/Utilities.dyn_o   | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o.d   | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o   | Run HsCpp: compiler/prelude/primops.txt.pp => _build/stage1/compiler/build/primops.txt   | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs   libraries/ghc-prim/cbits/atomic.c: In function ‘hs_atomic_nand8’:   libraries/ghc-prim/cbits/atomic.c:181:10: error:        note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4          return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val);                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~       |   181 |   return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val);       |          ^   | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o.d   | Run Cc FindCDependencies Stage1: utils/hp2ps/Main.c => _build/stage1/utils/hp2ps/build/c/Main.dyn_o.d   | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o   | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs   | Run Ghc FindHsDependencies Stage1: libraries/ghc-prim/GHC/CString.hs (and 7 more) => _build/stage1/libraries/ghc-prim/.dependencies.mk   | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.p_o   | Remove file _build/stage1/libraries/ghc-prim/.dependencies.mk.bak   Error when running Shake build system:     at action, called at src/Rules.hs:68:19 in main:Rules     at need, called at src/Rules.hs:85:5 in main:Rules   * Depends on: _build/stage1/bin/ghc     at need, called at src/Utilities.hs:71:18 in main:Utilities   * Depends on: _build/stage1/libraries/ghc-prim/build/libHSghc-prim-0.6.1_p-ghc8.9.20190408.so     at need, called at src/Rules/Library.hs:121:5 in main:Rules.Library   * Depends on: _build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o     at error, called at src/Hadrian/Oracles/TextFile.hs:65:20 in main:Hadrian.Oracles.TextFile   * Raised the exception:   No dependencies found for file '_build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o' I'm using Debian 9; x64_86; GHC 8.6.3; gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516   Any ideas what's wrong? Many thanks and kind regards Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Apr 9 12:40:09 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 09 Apr 2019 08:40:09 -0400 Subject: Validation Failures on aarch64 In-Reply-To: References: Message-ID: <66CD2B87-0FB1-4924-9F1D-62F8F443DDAC@smart-cactus.org> Indeed this is much worse than it used to be and quite unexpected. Last I knee there were only 100 or so failures, mostly external-interpeter related. Any investigation you could do would be greatly appreciated. I would be happy to offer access to hardware if this helps. Cheers, - Ben On April 8, 2019 3:55:18 PM EDT, Travis Whitaker wrote: >Hello GHC devs, > >When attempting to validate a patch on aarch64, it seems there are a >large >number of validation failures: > >SUMMARY for test run started at Mon Apr 8 07:19:05 2019 UTC > 0:15:35 spent to go through > 6890 total tests, which gave rise to > 17169 test cases, of which > 10018 were skipped > 41 had missing libraries > 3151 expected passes > 150 expected failures > 11 caused framework failures > 0 caused framework warnings > 0 unexpected passes > 3798 unexpected failures > 0 unexpected stat failures > >The failures seem consistent on recent-ish master, specifically the >neighborhood of 6113d0d4540af7853c71e9f42a41c3b0bab386fd. Is this to be >expected? > >Thanks, > >Travis Whitaker -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Apr 9 12:53:01 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 09 Apr 2019 08:53:01 -0400 Subject: Validation Failures on aarch64 In-Reply-To: <66CD2B87-0FB1-4924-9F1D-62F8F443DDAC@smart-cactus.org> References: <66CD2B87-0FB1-4924-9F1D-62F8F443DDAC@smart-cactus.org> Message-ID: <87k1g3bas8.fsf@smart-cactus.org> Ben Gamari writes: > Indeed this is much worse than it used to be and quite unexpected. > Last I knee there were only 100 or so failures, mostly > external-interpeter related. Any investigation you could do would be > greatly appreciated. I would be happy to offer access to hardware if > this helps. > Whoops. It looks like I was a bit late to the party here. Thanks for pinning down the issue, Travis. That being said, it seems that our CI job is failing due to missing bzip2. Fixed in https://gitlab.haskell.org/ghc/ci-images/merge_requests/10. It would be great if we could fix/mark-as-broken enough tests that we can remove allow_failure from the aarch64 job. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matthewtpickering at gmail.com Tue Apr 9 13:54:46 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 9 Apr 2019 14:54:46 +0100 Subject: Unable to build a profiled version of GHC Head In-Reply-To: <1554805207.23913.1.camel@bluewin.ch> References: <1554805207.23913.1.camel@bluewin.ch> Message-ID: Hi Roland, I can reproduce this. No idea about how to fix it at the moment but looks like a bug in hadrian. Matt On Tue, Apr 9, 2019 at 11:20 AM Roland Senn wrote: > > Hi, > > > I'm unable to build a profiled version of GHC Head. I did: > > > git clone --recursive https://gitlab.haskell.org/ghc/ghc ghcprof > > cd ghcprof > > git remote set-url --add origin https://gitlab.haskell.org/RolandSenn/ghc > > git remote set-url --delete origin https://gitlab.haskell.org/ghc/ghc > > git remote add upstream https://gitlab.haskell.org/ghc/ghc > > git fetch upstream > > git push origin master > > hadrian/build.sh -c --flavour=prof -j2 > > > I get the follwoing failure: > > > ... > > | Run Ghc CompileCWithGhc Stage1: utils/hp2ps/Utilities.c => _build/stage1/utils/hp2ps/build/c/Utilities.dyn_o > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o.d > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o > > | Run HsCpp: compiler/prelude/primops.txt.pp => _build/stage1/compiler/build/primops.txt > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs > > libraries/ghc-prim/cbits/atomic.c: In function ‘hs_atomic_nand8’: > > > libraries/ghc-prim/cbits/atomic.c:181:10: error: > > note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4 > > return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > | > > 181 | return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > | ^ > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o.d > > | Run Cc FindCDependencies Stage1: utils/hp2ps/Main.c => _build/stage1/utils/hp2ps/build/c/Main.dyn_o.d > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs > > | Run Ghc FindHsDependencies Stage1: libraries/ghc-prim/GHC/CString.hs (and 7 more) => _build/stage1/libraries/ghc-prim/.dependencies.mk > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.p_o > > | Remove file _build/stage1/libraries/ghc-prim/.dependencies.mk.bak > > Error when running Shake build system: > > at action, called at src/Rules.hs:68:19 in main:Rules > > at need, called at src/Rules.hs:85:5 in main:Rules > > * Depends on: _build/stage1/bin/ghc > > at need, called at src/Utilities.hs:71:18 in main:Utilities > > * Depends on: _build/stage1/libraries/ghc-prim/build/libHSghc-prim-0.6.1_p-ghc8.9.20190408.so > > at need, called at src/Rules/Library.hs:121:5 in main:Rules.Library > > * Depends on: _build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o > > at error, called at src/Hadrian/Oracles/TextFile.hs:65:20 in main:Hadrian.Oracles.TextFile > > * Raised the exception: > > No dependencies found for file '_build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o' > > > I'm using Debian 9; x64_86; GHC 8.6.3; gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > Any ideas what's wrong? > > > Many thanks and kind regards > > Roland > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Tue Apr 9 14:07:24 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 9 Apr 2019 15:07:24 +0100 Subject: Unable to build a profiled version of GHC Head In-Reply-To: References: <1554805207.23913.1.camel@bluewin.ch> Message-ID: Seems like the cause is that the `profiledDynamic` way is not enabled. Testing out a patch to fix this locally now. Matt On Tue, Apr 9, 2019 at 2:54 PM Matthew Pickering wrote: > > Hi Roland, > > I can reproduce this. No idea about how to fix it at the moment but > looks like a bug in hadrian. > > Matt > > On Tue, Apr 9, 2019 at 11:20 AM Roland Senn wrote: > > > > Hi, > > > > > > I'm unable to build a profiled version of GHC Head. I did: > > > > > > git clone --recursive https://gitlab.haskell.org/ghc/ghc ghcprof > > > > cd ghcprof > > > > git remote set-url --add origin https://gitlab.haskell.org/RolandSenn/ghc > > > > git remote set-url --delete origin https://gitlab.haskell.org/ghc/ghc > > > > git remote add upstream https://gitlab.haskell.org/ghc/ghc > > > > git fetch upstream > > > > git push origin master > > > > hadrian/build.sh -c --flavour=prof -j2 > > > > > > I get the follwoing failure: > > > > > > ... > > > > | Run Ghc CompileCWithGhc Stage1: utils/hp2ps/Utilities.c => _build/stage1/utils/hp2ps/build/c/Utilities.dyn_o > > > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o.d > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o > > > > | Run HsCpp: compiler/prelude/primops.txt.pp => _build/stage1/compiler/build/primops.txt > > > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs > > > > libraries/ghc-prim/cbits/atomic.c: In function ‘hs_atomic_nand8’: > > > > > > libraries/ghc-prim/cbits/atomic.c:181:10: error: > > > > note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4 > > > > return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > | > > > > 181 | return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > > > | ^ > > > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o.d > > > > | Run Cc FindCDependencies Stage1: utils/hp2ps/Main.c => _build/stage1/utils/hp2ps/build/c/Main.dyn_o.d > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o > > > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs > > > > | Run Ghc FindHsDependencies Stage1: libraries/ghc-prim/GHC/CString.hs (and 7 more) => _build/stage1/libraries/ghc-prim/.dependencies.mk > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.p_o > > > > | Remove file _build/stage1/libraries/ghc-prim/.dependencies.mk.bak > > > > Error when running Shake build system: > > > > at action, called at src/Rules.hs:68:19 in main:Rules > > > > at need, called at src/Rules.hs:85:5 in main:Rules > > > > * Depends on: _build/stage1/bin/ghc > > > > at need, called at src/Utilities.hs:71:18 in main:Utilities > > > > * Depends on: _build/stage1/libraries/ghc-prim/build/libHSghc-prim-0.6.1_p-ghc8.9.20190408.so > > > > at need, called at src/Rules/Library.hs:121:5 in main:Rules.Library > > > > * Depends on: _build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o > > > > at error, called at src/Hadrian/Oracles/TextFile.hs:65:20 in main:Hadrian.Oracles.TextFile > > > > * Raised the exception: > > > > No dependencies found for file '_build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o' > > > > > > I'm using Debian 9; x64_86; GHC 8.6.3; gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > > > Any ideas what's wrong? > > > > > > Many thanks and kind regards > > > > Roland > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Tue Apr 9 14:15:18 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 9 Apr 2019 15:15:18 +0100 Subject: Unable to build a profiled version of GHC Head In-Reply-To: References: <1554805207.23913.1.camel@bluewin.ch> Message-ID: Ticket: https://gitlab.haskell.org/ghc/ghc/issues/16562 Not working on this anymore today. Matt On Tue, Apr 9, 2019 at 3:07 PM Matthew Pickering wrote: > > Seems like the cause is that the `profiledDynamic` way is not enabled. > Testing out a patch to fix this locally now. > > Matt > > On Tue, Apr 9, 2019 at 2:54 PM Matthew Pickering > wrote: > > > > Hi Roland, > > > > I can reproduce this. No idea about how to fix it at the moment but > > looks like a bug in hadrian. > > > > Matt > > > > On Tue, Apr 9, 2019 at 11:20 AM Roland Senn wrote: > > > > > > Hi, > > > > > > > > > I'm unable to build a profiled version of GHC Head. I did: > > > > > > > > > git clone --recursive https://gitlab.haskell.org/ghc/ghc ghcprof > > > > > > cd ghcprof > > > > > > git remote set-url --add origin https://gitlab.haskell.org/RolandSenn/ghc > > > > > > git remote set-url --delete origin https://gitlab.haskell.org/ghc/ghc > > > > > > git remote add upstream https://gitlab.haskell.org/ghc/ghc > > > > > > git fetch upstream > > > > > > git push origin master > > > > > > hadrian/build.sh -c --flavour=prof -j2 > > > > > > > > > I get the follwoing failure: > > > > > > > > > ... > > > > > > | Run Ghc CompileCWithGhc Stage1: utils/hp2ps/Utilities.c => _build/stage1/utils/hp2ps/build/c/Utilities.dyn_o > > > > > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o.d > > > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/atomic.c => _build/stage1/libraries/ghc-prim/build/c/cbits/atomic.p_o > > > > > > | Run HsCpp: compiler/prelude/primops.txt.pp => _build/stage1/compiler/build/primops.txt > > > > > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs > > > > > > libraries/ghc-prim/cbits/atomic.c: In function ‘hs_atomic_nand8’: > > > > > > > > > libraries/ghc-prim/cbits/atomic.c:181:10: error: > > > > > > note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4 > > > > > > return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > | > > > > > > 181 | return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); > > > > > > | ^ > > > > > > | Run Cc FindCDependencies Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o.d > > > > > > | Run Cc FindCDependencies Stage1: utils/hp2ps/Main.c => _build/stage1/utils/hp2ps/build/c/Main.dyn_o.d > > > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.dyn_o > > > > > > | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt => _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs > > > > > > | Run Ghc FindHsDependencies Stage1: libraries/ghc-prim/GHC/CString.hs (and 7 more) => _build/stage1/libraries/ghc-prim/.dependencies.mk > > > > > > | Run Ghc CompileCWithGhc Stage1: libraries/ghc-prim/cbits/pext.c => _build/stage1/libraries/ghc-prim/build/c/cbits/pext.p_o > > > > > > | Remove file _build/stage1/libraries/ghc-prim/.dependencies.mk.bak > > > > > > Error when running Shake build system: > > > > > > at action, called at src/Rules.hs:68:19 in main:Rules > > > > > > at need, called at src/Rules.hs:85:5 in main:Rules > > > > > > * Depends on: _build/stage1/bin/ghc > > > > > > at need, called at src/Utilities.hs:71:18 in main:Utilities > > > > > > * Depends on: _build/stage1/libraries/ghc-prim/build/libHSghc-prim-0.6.1_p-ghc8.9.20190408.so > > > > > > at need, called at src/Rules/Library.hs:121:5 in main:Rules.Library > > > > > > * Depends on: _build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o > > > > > > at error, called at src/Hadrian/Oracles/TextFile.hs:65:20 in main:Hadrian.Oracles.TextFile > > > > > > * Raised the exception: > > > > > > No dependencies found for file '_build/stage1/libraries/ghc-prim/build/GHC/IntWord64.p_dyn_o' > > > > > > > > > I'm using Debian 9; x64_86; GHC 8.6.3; gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > > > > > Any ideas what's wrong? > > > > > > > > > Many thanks and kind regards > > > > > > Roland > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Tue Apr 9 14:22:34 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 09 Apr 2019 10:22:34 -0400 Subject: Losing (parallel) sleep over module dependencies In-Reply-To: References: Message-ID: <87bm1fb6mz.fsf@smart-cactus.org> Matthew Pickering writes: > Hi all, > > I get worried quite often about the interaction of two facts > > 1. Adding a new dependency to a module is easy. > 2. Adding a new dependency changes the build graph and potentially > reduces the amount of parallelism which the build is capable of. > > Has anyone thought of any strategies to analyse the dependency graph > of GHC so that a linter can be > created to warn against any changes which create dependencies which > affect the parallelism? > > hs-boot files make this issue even worse I think but I'm not sure of > the precise recompilation semantics. > > It would be quite straight forward to index ghc as it is being built > to create a dependency graph (at the identifier) level but it's > unclear to me whether it is possible to do anything productive with > this information. > In principle we could just produce a Hadrian profile as a CI product. From this you could compute the mean available parallelism over the course of the build and record this as a performance metric for, e.g., gipeda. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rsx at bluewin.ch Tue Apr 9 15:54:47 2019 From: rsx at bluewin.ch (Roland Senn) Date: Tue, 09 Apr 2019 17:54:47 +0200 Subject: Unable to build a profiled version of GHC Head In-Reply-To: References: <1554805207.23913.1.camel@bluewin.ch> Message-ID: <1554825287.1501.1.camel@bluewin.ch> Hi Matt, Thanks for looking into this and preparing a patch. Take your time, I don't need it urgently. Regards Roland Am Dienstag, den 09.04.2019, 15:15 +0100 schrieb Matthew Pickering: > Ticket: https://gitlab.haskell.org/ghc/ghc/issues/16562 > > Not working on this anymore today. > > Matt > > On Tue, Apr 9, 2019 at 3:07 PM Matthew Pickering > wrote: > > > > Seems like the cause is that the `profiledDynamic` way is not > > enabled. > > Testing out a patch to fix this locally now. > > > > Matt > > > > On Tue, Apr 9, 2019 at 2:54 PM Matthew Pickering > > wrote: > > > > > > Hi Roland, > > > > > > I can reproduce this. No idea about how to fix it at the moment > > > but > > > looks like a bug in hadrian. > > > > > > Matt > > > > > > On Tue, Apr 9, 2019 at 11:20 AM Roland Senn > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > I'm unable to build a profiled version of GHC Head. I did: > > > > > > > > > > > >   git clone --recursive https://gitlab.haskell.org/ghc/ghc > > > > ghcprof > > > > > > > >   cd ghcprof > > > > > > > >   git remote set-url --add origin https://gitlab.haskell.org/Ro > > > > landSenn/ghc > > > > > > > >   git remote set-url --delete origin https://gitlab.haskell.org > > > > /ghc/ghc > > > > > > > >   git remote add upstream https://gitlab.haskell.org/ghc/ghc > > > > > > > >   git fetch upstream > > > > > > > >   git push origin master > > > > > > > >   hadrian/build.sh -c --flavour=prof -j2 > > > > > > > > > > > > I get the follwoing failure: > > > > > > > > > > > >   ... > > > > > > > >   | Run Ghc CompileCWithGhc Stage1: utils/hp2ps/Utilities.c => > > > > _build/stage1/utils/hp2ps/build/c/Utilities.dyn_o > > > > > > > >   | Run Cc FindCDependencies Stage1: libraries/ghc- > > > > prim/cbits/atomic.c => _build/stage1/libraries/ghc- > > > > prim/build/c/cbits/atomic.p_o.d > > > > > > > >   | Run Ghc CompileCWithGhc Stage1: libraries/ghc- > > > > prim/cbits/atomic.c => _build/stage1/libraries/ghc- > > > > prim/build/c/cbits/atomic.p_o > > > > > > > >   | Run HsCpp: compiler/prelude/primops.txt.pp => > > > > _build/stage1/compiler/build/primops.txt > > > > > > > >   | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt > > > > => _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs > > > > > > > >   libraries/ghc-prim/cbits/atomic.c: In function > > > > ‘hs_atomic_nand8’: > > > > > > > > > > > >   libraries/ghc-prim/cbits/atomic.c:181:10: error: > > > > > > > >        note: ‘__sync_fetch_and_nand’ changed semantics in GCC > > > > 4.4 > > > > > > > >          return __sync_fetch_and_nand((volatile StgWord8 *) x, > > > > (StgWord8) val); > > > > > > > >                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ~~~~~~~~~~~~~~~ > > > > > > > >       | > > > > > > > >   181 |   return __sync_fetch_and_nand((volatile StgWord8 *) x, > > > > (StgWord8) val); > > > > > > > >       |          ^ > > > > > > > >   | Run Cc FindCDependencies Stage1: libraries/ghc- > > > > prim/cbits/pext.c => _build/stage1/libraries/ghc- > > > > prim/build/c/cbits/pext.dyn_o.d > > > > > > > >   | Run Cc FindCDependencies Stage1: utils/hp2ps/Main.c => > > > > _build/stage1/utils/hp2ps/build/c/Main.dyn_o.d > > > > > > > >   | Run Ghc CompileCWithGhc Stage1: libraries/ghc- > > > > prim/cbits/pext.c => _build/stage1/libraries/ghc- > > > > prim/build/c/cbits/pext.dyn_o > > > > > > > >   | Run GenPrimopCode: _build/stage1/compiler/build/primops.txt > > > > => _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs > > > > > > > >   | Run Ghc FindHsDependencies Stage1: libraries/ghc- > > > > prim/GHC/CString.hs (and 7 more) => > > > > _build/stage1/libraries/ghc-prim/.dependencies.mk > > > > > > > >   | Run Ghc CompileCWithGhc Stage1: libraries/ghc- > > > > prim/cbits/pext.c => _build/stage1/libraries/ghc- > > > > prim/build/c/cbits/pext.p_o > > > > > > > >   | Remove file _build/stage1/libraries/ghc- > > > > prim/.dependencies.mk.bak > > > > > > > >   Error when running Shake build system: > > > > > > > >     at action, called at src/Rules.hs:68:19 in main:Rules > > > > > > > >     at need, called at src/Rules.hs:85:5 in main:Rules > > > > > > > >   * Depends on: _build/stage1/bin/ghc > > > > > > > >     at need, called at src/Utilities.hs:71:18 in main:Utilities > > > > > > > >   * Depends on: _build/stage1/libraries/ghc- > > > > prim/build/libHSghc-prim-0.6.1_p-ghc8.9.20190408.so > > > > > > > >     at need, called at src/Rules/Library.hs:121:5 in > > > > main:Rules.Library > > > > > > > >   * Depends on: _build/stage1/libraries/ghc- > > > > prim/build/GHC/IntWord64.p_dyn_o > > > > > > > >     at error, called at src/Hadrian/Oracles/TextFile.hs:65:20 > > > > in main:Hadrian.Oracles.TextFile > > > > > > > >   * Raised the exception: > > > > > > > >   No dependencies found for file '_build/stage1/libraries/ghc- > > > > prim/build/GHC/IntWord64.p_dyn_o' > > > > > > > > > > > > I'm using Debian 9; x64_86;  GHC 8.6.3; gcc (Debian 6.3.0- > > > > 18+deb9u1) 6.3.0 20170516 > > > > > > > > Any ideas what's wrong? > > > > > > > > > > > > Many thanks and kind regards > > > > > > > >    Roland > > > > > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Thu Apr 11 22:24:05 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 11 Apr 2019 18:24:05 -0400 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: <2CE8C97B-D5DE-49F1-947A-A8014E4FA90B@inconsistent.nl> References: <87o95gbbd8.fsf@smart-cactus.org> <2CE8C97B-D5DE-49F1-947A-A8014E4FA90B@inconsistent.nl> Message-ID: <87sguow58f.fsf@smart-cactus.org> Merijn Verstraaten writes: > There doesn't appear to be a bindist for CentOS 7 (nor for 8.6.4, despite 8.6.3 having one). > We do not yet have CI automation to produce CentOS 7 builds. I have opened !758 fixing this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From william.hallahan at yale.edu Fri Apr 12 03:02:45 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Thu, 11 Apr 2019 23:02:45 -0400 Subject: Getting Rewrite Rules from ModGuts Message-ID: Hi, I'm trying to use the GHC API (8.2.2) to extract the rewrite rules from a module, but have run into some difficulties. I've written the following code (all code is also attached as files): module Main where import GHC import GHC.Paths import HscTypes main :: IO () main = do loadProj "Test.hs" loadProj :: FilePath -> IO () loadProj src = do modgutss <- runGhc (Just libdir) $ do flags <- getSessionDynFlags _ <- setSessionDynFlags flags target <- guessTarget src Nothing _ <- setTargets [target] _ <- load LoadAllTargets mod_graph <- getModuleGraph parsed_mods <- mapM parseModule mod_graph typed_mods <- mapM typecheckModule parsed_mods desug_mods <- mapM desugarModule typed_mods return $ map coreModule desug_mods let rules = map (\mg -> ( moduleNameString . moduleName $ mg_module mg , length $ mg_rules mg) ) modgutss print $ rules return () It loads Test.hs (see below my signature) which contains a single rewrite rule. Then, it obtains the ModGuts, and prints a tuple of the name of the module, and the length of the rule list. I would expect this to be ("Test", 1), but, in fact, what gets printed is ("Test", 0). For some reason, the ModGuts does not have the rewrite rule from the file. I'm guessing I'm misunderstanding something about how the GHC API works. If anyone has any advice about how to fix this code to load rewrite rules (or even where to begin looking) I would appreciate it! Thanks, Bill Hallahan Test.hs: module Test where import Prelude hiding (map) map :: (a -> b) -> [a] -> [b] map f (x:xs) = f x:map f xs map _ [] = [] {-# NOINLINE [0] map #-} {-# RULES "map/map" forall f g xs . map f (map g xs) = map (f . g) xs #-} -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: application/octet-stream Size: 822 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.hs Type: application/octet-stream Size: 224 bytes Desc: not available URL: From allbery.b at gmail.com Fri Apr 12 03:06:08 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 11 Apr 2019 23:06:08 -0400 Subject: Getting Rewrite Rules from ModGuts In-Reply-To: References: Message-ID: You might need to enable optimization for RULES to get picked up at all. On Thu, Apr 11, 2019 at 11:03 PM Bill Hallahan wrote: > Hi, > > I'm trying to use the GHC API (8.2.2) to extract the rewrite rules from a > module, but have run into some difficulties. I've written the following > code (all code is also attached as files): > > module Main where > > import GHC > import GHC.Paths > import HscTypes > > main :: IO () > main = do > loadProj "Test.hs" > > loadProj :: FilePath -> IO () > loadProj src = do > modgutss <- runGhc (Just libdir) $ do > flags <- getSessionDynFlags > _ <- setSessionDynFlags flags > > target <- guessTarget src Nothing > _ <- setTargets [target] > _ <- load LoadAllTargets > > mod_graph <- getModuleGraph > parsed_mods <- mapM parseModule mod_graph > typed_mods <- mapM typecheckModule parsed_mods > desug_mods <- mapM desugarModule typed_mods > > return $ map coreModule desug_mods > > let rules = map (\mg -> ( moduleNameString . moduleName $ > mg_module mg > , length $ mg_rules mg) > ) modgutss > print $ rules > > return () > > It loads Test.hs (see below my signature) which contains a single rewrite > rule. Then, it obtains the ModGuts, and prints a tuple of the name of the > module, and the length of the rule list. I would expect this to be > ("Test", 1), but, in fact, what gets printed is ("Test", 0). For some > reason, the ModGuts does not have the rewrite rule from the file. > > I'm guessing I'm misunderstanding something about how the GHC API works. > If anyone has any advice about how to fix this code to load rewrite rules > (or even where to begin looking) I would appreciate it! > > Thanks, > Bill Hallahan > > Test.hs: > module Test where > > import Prelude hiding (map) > > map :: (a -> b) -> [a] -> [b] > map f (x:xs) = f x:map f xs > map _ [] = [] > {-# NOINLINE [0] map #-} > > {-# RULES > "map/map" forall f g xs . map f (map g xs) = map (f . g) xs > #-} > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.hallahan at yale.edu Fri Apr 12 03:12:14 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Thu, 11 Apr 2019 23:12:14 -0400 Subject: Getting Rewrite Rules from ModGuts In-Reply-To: References: Message-ID: Thanks Brandon! Unfortunately, I don't think this is right (or at least it's not sufficient.) If I change the code to use: _ <- setSessionDynFlags $ gopt_set flags Opt_EnableRewriteRules I still read in 0 rewrite rules. (Unless I'm setting the wrong flag/not enough flags?) Bill > On Apr 11, 2019, at 11:06 PM, Brandon Allbery wrote: > > You might need to enable optimization for RULES to get picked up at all. > > On Thu, Apr 11, 2019 at 11:03 PM Bill Hallahan > wrote: > Hi, > > I'm trying to use the GHC API (8.2.2) to extract the rewrite rules from a module, but have run into some difficulties. I've written the following code (all code is also attached as files): > > module Main where > > import GHC > import GHC.Paths > import HscTypes > > main :: IO () > main = do > loadProj "Test.hs" > > loadProj :: FilePath -> IO () > loadProj src = do > modgutss <- runGhc (Just libdir) $ do > flags <- getSessionDynFlags > _ <- setSessionDynFlags flags > > target <- guessTarget src Nothing > _ <- setTargets [target] > _ <- load LoadAllTargets > > mod_graph <- getModuleGraph > parsed_mods <- mapM parseModule mod_graph > typed_mods <- mapM typecheckModule parsed_mods > desug_mods <- mapM desugarModule typed_mods > > return $ map coreModule desug_mods > > let rules = map (\mg -> ( moduleNameString . moduleName $ mg_module mg > , length $ mg_rules mg) > ) modgutss > print $ rules > > return () > > It loads Test.hs (see below my signature) which contains a single rewrite rule. Then, it obtains the ModGuts, and prints a tuple of the name of the module, and the length of the rule list. I would expect this to be ("Test", 1), but, in fact, what gets printed is ("Test", 0). For some reason, the ModGuts does not have the rewrite rule from the file. > > I'm guessing I'm misunderstanding something about how the GHC API works. If anyone has any advice about how to fix this code to load rewrite rules (or even where to begin looking) I would appreciate it! > > Thanks, > Bill Hallahan > > Test.hs: > module Test where > > import Prelude hiding (map) > > map :: (a -> b) -> [a] -> [b] > map f (x:xs) = f x:map f xs > map _ [] = [] > {-# NOINLINE [0] map #-} > > {-# RULES > "map/map" forall f g xs . map f (map g xs) = map (f . g) xs > #-} > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: application/octet-stream Size: 872 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Fri Apr 12 04:13:37 2019 From: juhpetersen at gmail.com (Jens Petersen) Date: Fri, 12 Apr 2019 12:13:37 +0800 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: On Tue, 9 Apr 2019 at 12:54, Jens Petersen wrote: > I don't see any source tarball... Okay I see one has been uploaded, thanks. Jens From rsx at bluewin.ch Fri Apr 12 08:25:03 2019 From: rsx at bluewin.ch (Roland Senn) Date: Fri, 12 Apr 2019 10:25:03 +0200 Subject: Getting Rewrite Rules from ModGuts In-Reply-To: References: Message-ID: <1555057503.2309.1.camel@bluewin.ch> Hi Bill, You may try to set the DynFlag Opt_IgnoreInterfacePragmas to False. If set to True,, which is the default, GHC doesn't load a lot of optimization stuff. Good luck and kind regards Roland Am Donnerstag, den 11.04.2019, 23:02 -0400 schrieb Bill Hallahan: > Hi, > > I'm trying to use the GHC API (8.2.2) to extract the rewrite rules > from a module, but have run into some difficulties.  I've written the > following code (all code is also attached as files): > >     module Main where > >     import GHC >     import GHC.Paths >     import HscTypes > >     main :: IO () >     main = do >         loadProj "Test.hs" > >     loadProj :: FilePath -> IO () >     loadProj src = do >         modgutss <- runGhc (Just libdir) $ do >             flags <- getSessionDynFlags >             _ <- setSessionDynFlags flags > >             target <- guessTarget src Nothing >             _ <- setTargets [target] >             _ <- load LoadAllTargets >              >             mod_graph <- getModuleGraph >             parsed_mods <- mapM parseModule mod_graph >             typed_mods <- mapM typecheckModule parsed_mods >             desug_mods <- mapM desugarModule typed_mods > >             return $ map coreModule desug_mods > >         let rules = map (\mg -> ( moduleNameString . moduleName $ > mg_module mg >                                 , length $ mg_rules mg) >                         ) modgutss >         print $ rules > >         return () > > It loads Test.hs (see below my signature) which contains a single > rewrite rule.  Then, it obtains the ModGuts, and prints a tuple of > the name of the module, and the length of the rule list.  I would > expect this to be ("Test", 1), but, in fact, what gets printed is > ("Test", 0).  For some reason, the ModGuts does not have the rewrite > rule from the file. > > I'm guessing I'm misunderstanding something about how the GHC API > works.  If anyone has any advice about how to fix this code to load > rewrite rules (or even where to begin looking) I would appreciate it! > > Thanks, > Bill Hallahan > > Test.hs: >     module Test where > >     import Prelude hiding (map) > >     map :: (a -> b) -> [a] -> [b] >     map f (x:xs) = f x:map f xs >     map _ [] = [] >     {-# NOINLINE [0] map #-} > >     {-# RULES >      "map/map"   forall f g xs . map f (map g xs) = map (f . g) xs >       #-} > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From william.hallahan at yale.edu Fri Apr 12 15:04:11 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Fri, 12 Apr 2019 11:04:11 -0400 Subject: Getting Rewrite Rules from ModGuts In-Reply-To: <1555057503.2309.1.camel@bluewin.ch> References: <1555057503.2309.1.camel@bluewin.ch> Message-ID: Thanks Roland. Unfortunately, this also doesn't seem to work- I tried unsetting Opt_IgnoreInterfacePragmas both with and without setting Opt_EnableRewriteRules, and no combination results in the rules being loaded. Bill > On Apr 12, 2019, at 4:25 AM, Roland Senn wrote: > > Opt_IgnoreInterfacePragmas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Apr 12 16:33:49 2019 From: ben at well-typed.com (Ben Gamari) Date: Fri, 12 Apr 2019 12:33:49 -0400 Subject: [ANNOUNCE] GHC 8.6.5-rc1 is now available In-Reply-To: References: <87o95gbbd8.fsf@smart-cactus.org> Message-ID: <87o95bw5cm.fsf@smart-cactus.org> Jens Petersen writes: > On Tue, 9 Apr 2019 at 02:28, Ben Gamari wrote: >> The GHC team is proud to announce the first release candidate of 8.6.5. >> The source distribution, binary distributions, and documentation are >> available at >> https://downloads.haskell.org/~ghc/8.6.5-rc1 > > I don't see any source tarball... > Whoops, I thought I had replied to this earlier this week but it looks like the reply never made it out. Sorry for the latency. Indeed this was an oversight. Now fixed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From william.hallahan at yale.edu Fri Apr 12 20:52:42 2019 From: william.hallahan at yale.edu (Bill Hallahan) Date: Fri, 12 Apr 2019 16:52:42 -0400 Subject: Getting Rewrite Rules from ModGuts In-Reply-To: References: <1555057503.2309.1.camel@bluewin.ch> Message-ID: <2D1DA1ED-AC12-40FB-A20D-4F2361C6461F@yale.edu> I figured out what was happening to the rules. In case anyone finds this thread later: rules for local functions do not go in the ModGuts or CgGuts, but are instead put in the IdInfo in individual Id's. A description of this is in the [Overall plumbing for rules] note in Rules: http://hackage.haskell.org/package/ghc-8.6.1/docs/src/Rules.html -Bill > On Apr 12, 2019, at 11:04 AM, Bill Hallahan wrote: > > Thanks Roland. Unfortunately, this also doesn't seem to work- I tried unsetting Opt_IgnoreInterfacePragmas both with and without setting Opt_EnableRewriteRules, and no combination results in the rules being loaded. > > Bill > >> On Apr 12, 2019, at 4:25 AM, Roland Senn > wrote: >> >> Opt_IgnoreInterfacePragmas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 15 11:27:41 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 11:27:41 +0000 Subject: Hadrian Message-ID: Andrey and other Hadrian heros Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged Simon Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs T16566.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "809020190414", got "8064") | 1 | module T16566 where | ^^^^^^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Mon Apr 15 11:52:33 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Mon, 15 Apr 2019 11:52:33 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Hi Simon, Apologies it's taking so long. It's not obvious how to fix this properly, and as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. Will this work for you? Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 15 April 2019 12:28 To: Andrey Mokhov Cc: ghc-devs at haskell.org Subject: Hadrian Andrey and other Hadrian heros Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged Simon Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs T16566.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "809020190414", got "8064") | 1 | module T16566 where | ^^^^^^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 15 12:11:06 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 12:11:06 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. That sound fine, thanks. Same for ghc-stage2.sh? My difficulty is that as of today I simply do not know how to invoke my freshly built GHC! Simon From: Andrey Mokhov Sent: 15 April 2019 12:53 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: RE: Hadrian Hi Simon, Apologies it's taking so long. It's not obvious how to fix this properly, and as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. Will this work for you? Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 15 April 2019 12:28 To: Andrey Mokhov > Cc: ghc-devs at haskell.org Subject: Hadrian Andrey and other Hadrian heros Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged Simon Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs T16566.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "809020190414", got "8064") | 1 | module T16566 where | ^^^^^^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Apr 15 12:39:48 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 15 Apr 2019 13:39:48 +0100 Subject: Hadrian In-Reply-To: References: Message-ID: Does the stage2 compiler which is found in `stage1/bin/ghc` not work for you? I thought the issue was that the stage1 compiler doesn't work. Matt On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs wrote: > > as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. > > That sound fine, thanks. Same for ghc-stage2.sh? > > My difficulty is that as of today I simply do not know how to invoke my freshly built GHC! > > Simon > > > > From: Andrey Mokhov > Sent: 15 April 2019 12:53 > To: Simon Peyton Jones > Cc: ghc-devs at haskell.org > Subject: RE: Hadrian > > > > Hi Simon, > > Apologies it’s taking so long. It’s not obvious how to fix this properly, and as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. > > Will this work for you? > > Cheers, > Andrey > > > > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > Sent: 15 April 2019 12:28 > To: Andrey Mokhov > Cc: ghc-devs at haskell.org > Subject: Hadrian > > > > Andrey and other Hadrian heros > > Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged > > Simon > > > > Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version > > The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 > > simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs > > > > T16566.hs:1:8: error: > > Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi > > mismatched interface file versions (wanted "809020190414", got "8064") > > | > > 1 | module T16566 where > > | ^^^^^^ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 15 12:47:14 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 12:47:14 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). Yes, that works. But perhaps a script to get to it would be helpful, otherwise invoking stage1 will look entirely different to invoking stage2. Not a bid deal, I grant you! S | -----Original Message----- | From: Matthew Pickering | Sent: 15 April 2019 13:40 | To: Simon Peyton Jones | Cc: Andrey Mokhov ; ghc-devs at haskell.org | Subject: Re: Hadrian | | Does the stage2 compiler which is found in `stage1/bin/ghc` not work for | you? I thought the issue was that the stage1 compiler doesn't work. | | Matt | | On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs wrote: | > | > as a temporary workaround we could create a top-level wrapper script, | say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, | just like Hadrian itself does during the build. | > | > That sound fine, thanks. Same for ghc-stage2.sh? | > | > My difficulty is that as of today I simply do not know how to invoke my | freshly built GHC! | > | > Simon | > | > | > | > From: Andrey Mokhov | > Sent: 15 April 2019 12:53 | > To: Simon Peyton Jones | > Cc: ghc-devs at haskell.org | > Subject: RE: Hadrian | > | > | > | > Hi Simon, | > | > Apologies it’s taking so long. It’s not obvious how to fix this | properly, and as a temporary workaround we could create a top-level | wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the | right arguments, just like Hadrian itself does during the build. | > | > Will this work for you? | > | > Cheers, | > Andrey | > | > | > | > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | > Sent: 15 April 2019 12:28 | > To: Andrey Mokhov | > Cc: ghc-devs at haskell.org | > Subject: Hadrian | > | > | > | > Andrey and other Hadrian heros | > | > Just to say that I am 100% stalled on using Hadrian because the | > in-tree binary uses the wrong library files. I reported this a few | > weeks ago, but it still seems unchanged | > | > Simon | > | > | > | > Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version | > | > The Glorious Glasgow Haskell Compilation System, version | > 8.9.0.20190414 | > | > simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c | > T16566.hs | > | > | > | > T16566.hs:1:8: error: | > | > Bad interface file: | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > mismatched interface file versions (wanted "809020190414", got | > "8064") | > | > | | > | > 1 | module T16566 where | > | > | ^^^^^^ | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01 | > %7Csimonpj%40microsoft.com%7Cdf9439b6d848493aca9608d6c19f79f6%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909288021992421&sdata=ddsV | > pnCFLP4D7dGqPtuMdv3oahBrOvRWVDlOV2GSwBU%3D&reserved=0 From simonpj at microsoft.com Mon Apr 15 13:37:06 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 13:37:06 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: sounds good to me! | -----Original Message----- | From: Moritz Angermann | Sent: 15 April 2019 14:29 | To: Simon Peyton Jones | Cc: Matthew Pickering ; Andrey Mokhov | ; ghc-devs at haskell.org | Subject: Re: Hadrian | | I guess we could add | | $root/ghc-stage1 (shell script) | $root/ghc-stage2 (shell script) | | As long as we understand that those are just convenience scripts. | | Why $root? Because we can have multiple build directories for different | configurations. Thus putting the scripts into the ghc folder would not | know which root you wanted. This for the default root this would be: | | _build/ghc-stage1 | _build/ghc-stage2 | | Does that sound like an intermittent solution? | | Cheers, | Moritz | | Sent from my iPhone | | > On 15 Apr 2019, at 8:47 AM, Simon Peyton Jones via ghc-devs wrote: | > | > Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). | Yes, that works. But perhaps a script to get to it would be helpful, | otherwise invoking stage1 will look entirely different to invoking stage2. | Not a bid deal, I grant you! | > | > S | > | > | -----Original Message----- | > | From: Matthew Pickering | > | Sent: 15 April 2019 13:40 | > | To: Simon Peyton Jones | > | Cc: Andrey Mokhov ; | > | ghc-devs at haskell.org | > | Subject: Re: Hadrian | > | | > | Does the stage2 compiler which is found in `stage1/bin/ghc` not | > | work for you? I thought the issue was that the stage1 compiler | doesn't work. | > | | > | Matt | > | | > | On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs | > | wrote: | > | > | > | > as a temporary workaround we could create a top-level wrapper | > | script, say `ghc-stage1.sh` that will call Stage1 GHC with the | > | right arguments, just like Hadrian itself does during the build. | > | > | > | > That sound fine, thanks. Same for ghc-stage2.sh? | > | > | > | > My difficulty is that as of today I simply do not know how to | > | invoke my freshly built GHC! | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Andrey Mokhov > Sent: 15 | > | April 2019 12:53 > To: Simon Peyton Jones | > | > Cc: ghc-devs at haskell.org > Subject: RE: Hadrian > > > > Hi | > | Simon, > > Apologies it’s taking so long. It’s not obvious how to | > | fix this properly, and as a temporary workaround we could create a | > | top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 | > | GHC with the right arguments, just like Hadrian itself does during | > | the build. | > | > | > | > Will this work for you? | > | > | > | > Cheers, | > | > Andrey | > | > | > | > | > | > | > | > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > Sent: | > | 15 April 2019 12:28 > To: Andrey Mokhov | > | > Cc: ghc-devs at haskell.org > | > | Subject: Hadrian > > > > Andrey and other Hadrian heros > > | > | Just to say that I am 100% stalled on using Hadrian because the > | > | in-tree binary uses the wrong library files. I reported this a few | > | > weeks ago, but it still seems unchanged > > Simon > > > > | > | Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version > > The Glorious | > | Glasgow Haskell Compilation System, version > 8.9.0.20190414 > > | > | simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c > | > | T16566.hs > > > > T16566.hs:1:8: error: | > | > | > | > Bad interface file: | > | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > | > | > mismatched interface file versions (wanted "809020190414", | got | > | > "8064") | > | > | > | > | | > | > | > | > 1 | module T16566 where | > | > | > | > | ^^^^^^ | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > | > | > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C | > | 01 > | > | %7Csimonpj%40microsoft.com%7Cdf9439b6d848493aca9608d6c19f79f6%7C72f9 | > | 88 > | > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909288021992421&sdata=dd | > | sV > pnCFLP4D7dGqPtuMdv3oahBrOvRWVDlOV2GSwBU%3D&reserved=0 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Apr 15 14:59:17 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 14:59:17 +0000 Subject: Proposal section numbering messed up Message-ID: Why does this proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst start with Section 36? (It is proposal 36.) Lots of other proposals do this too. Can it be fixed? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Apr 15 15:07:57 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 15 Apr 2019 11:07:57 -0400 Subject: Proposal section numbering messed up In-Reply-To: References: Message-ID: <874l6zwblg.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Why does this proposal > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst > start with Section 36? (It is proposal 36.) > Lots of other proposals do this too. That's a great question. The header contains .. sectnum:: :start: 36 which mpickering added in [1]. mpickering, what was the motivation for this? Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/commit/5c2fa009a369df39cf60ebda84debbf6e5b5490d#diff-f272dc8b5fdcaf6b06c33f7e52a815aa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From matthewtpickering at gmail.com Mon Apr 15 16:45:37 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 15 Apr 2019 17:45:37 +0100 Subject: Proposal section numbering messed up In-Reply-To: <874l6zwblg.fsf@smart-cactus.org> References: <874l6zwblg.fsf@smart-cactus.org> Message-ID: The ..sectnum is necessary so that when you render all the proposals together then the numbering is coherent. What happens if you move the ..sectnum to above the title? On that note, I think there should be a site where you can view the rendered proposals rather than having to do so via github preview. Cheers, Matt On Mon, Apr 15, 2019 at 4:08 PM Ben Gamari wrote: > > Simon Peyton Jones via ghc-devs writes: > > > Why does this proposal > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst > > start with Section 36? (It is proposal 36.) > > Lots of other proposals do this too. > > That's a great question. The header contains > > .. sectnum:: > :start: 36 > > which mpickering added in [1]. mpickering, what was the motivation for > this? > > Cheers, > > - Ben > > [1] https://github.com/ghc-proposals/ghc-proposals/commit/5c2fa009a369df39cf60ebda84debbf6e5b5490d#diff-f272dc8b5fdcaf6b06c33f7e52a815aa > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From matthewtpickering at gmail.com Mon Apr 15 16:47:46 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 15 Apr 2019 17:47:46 +0100 Subject: Proposal section numbering messed up In-Reply-To: References: <874l6zwblg.fsf@smart-cactus.org> Message-ID: It seems if you move all the metainfo to above the title then it renders correctly. Should be easy enough to fix if someone feels strongly about how these are rendered. Matt On Mon, Apr 15, 2019 at 5:45 PM Matthew Pickering wrote: > > The ..sectnum is necessary so that when you render all the proposals > together then the numbering is coherent. > > What happens if you move the ..sectnum to above the title? > > On that note, I think there should be a site where you can view the > rendered proposals rather than having to do so via github preview. > > Cheers, > > Matt > > > On Mon, Apr 15, 2019 at 4:08 PM Ben Gamari wrote: > > > > Simon Peyton Jones via ghc-devs writes: > > > > > Why does this proposal > > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst > > > start with Section 36? (It is proposal 36.) > > > Lots of other proposals do this too. > > > > That's a great question. The header contains > > > > .. sectnum:: > > :start: 36 > > > > which mpickering added in [1]. mpickering, what was the motivation for > > this? > > > > Cheers, > > > > - Ben > > > > [1] https://github.com/ghc-proposals/ghc-proposals/commit/5c2fa009a369df39cf60ebda84debbf6e5b5490d#diff-f272dc8b5fdcaf6b06c33f7e52a815aa > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sgraf1337 at gmail.com Mon Apr 15 20:08:42 2019 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 15 Apr 2019 20:08:42 +0000 Subject: Near-daily "Remote mirror update failed" e-mails from GitLab In-Reply-To: <871s2fc7kb.fsf@smart-cactus.org> References: , <871s2fc7kb.fsf@smart-cactus.org> Message-ID: Hey, sorry, I'm a little late to respond. I didn't push to GitHub, at least not consciously. Let me know if you find that I screwed up somewhere. Cheers, Sebastian ________________________________ Von: Ben Gamari Gesendet: Samstag, April 6, 2019 8:28 PM An: Ryan Scott; Sebastian Graf Cc: ghc-devs at haskell.org Betreff: Re: Near-daily "Remote mirror update failed" e-mails from GitLab Ryan Scott writes: > Almost every day now I receive an e-mail from GitLab titled "Remote > mirror update failed", which contains something like: > > To > > ! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot > lock ref 'refs/heads/wip/dmd-arity': is at > e1cc1254b81a7adadd8db77c7be625497264ab2b but expected > f07b61d047967129a3ae0c56f8894d41c5a9b036) > > error: failed to push some refs to '[FILTERED]@github.com/ghc/ghc' > Hmm, how annoying. Strangely, the `wip/dmd-arity` branch currently appears to be sitting at the same commit on GitLab and GitHub so I'm not really sure what to do here. sgraf, did you ever push a branch manually to the github.com/ghc/ghc mirror? Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 15 21:47:40 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 21:47:40 +0000 Subject: Cabal woes Message-ID: I'm trying to install 'hspec' on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar - isn't that what cabal is for?) But it helpfully suggests adding -lib. Alas, cabal then crashes outright, which should never happen. So I'm stuck. What should I do? Thanks Simon simonpj at MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj at MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj at MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj at MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj at MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj at MSRC-9870733:~$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 15 21:53:43 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 17:53:43 -0400 Subject: Cabal woes In-Reply-To: References: Message-ID: I think you wanted v1-install to install a library into the user package database, since your cabal is 3.x and the v2-* commands are now the default (that is, you did what used to be cabal new-install or cabal v2-install). On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) > system. > > But I fail; see below. > > For some reason cabal complains about installing a library. (That seems > peculiar – isn’t that what cabal is for?) But it helpfully suggests adding > –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no executables in > > target: hspec. Perhaps you want to use --lib to install libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for > pattern Just ghcPkgProg > > > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 15 22:00:48 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 22:00:48 +0000 Subject: Cabal woes In-Reply-To: References: Message-ID: Thanks. But alas I have no clue about whether I want a v1-install or a v2-install, nor how to achieve them if I knew what they were. I just want to install ‘hspec’ so that I can use it when compiling a program. How would I do that? The instructions here https://wiki.haskell.org/Cabal-Install just say “cabal install hspec” which is what I tried. Those instructions are pointed to from here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in turn are pointed to from the main Cabal home page https://www.haskell.org/cabal/. I must be missing something. Simon From: Brandon Allbery Sent: 15 April 2019 22:54 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Cabal woes I think you wanted v1-install to install a library into the user package database, since your cabal is 3.x and the v2-* commands are now the default (that is, you did what used to be cabal new-install or cabal v2-install). On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs > wrote: I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar – isn’t that what cabal is for?) But it helpfully suggests adding –lib. Alas, cabal then crashes outright, which should never happen. So I’m stuck. What should I do? Thanks Simon simonpj at MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj at MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj at MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj at MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj at MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj at MSRC-9870733:~$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Mon Apr 15 22:02:08 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Mon, 15 Apr 2019 17:02:08 -0500 Subject: Cabal woes In-Reply-To: References: Message-ID: If you want to install it globally for use by GHC, I think you want v1-install. On 4/15/19 5:00 PM, Simon Peyton Jones via ghc-devs wrote: > > Thanks.  But alas I have no clue about whether I want a v1-install or > a v2-install, nor how to achieve them if I knew what they were.  I > just want to install ‘hspec’ so that I can use it when compiling a > program.  How would I do that? > >   > > The instructions here https://wiki.haskell.org/Cabal-Install > just say “cabal install > hspec” which is what I tried.  Those instructions are pointed to from > here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, > which in turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/. > >   > > I must be missing something. > >   > > Simon > >   > > *From:*Brandon Allbery > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > >   > > I think you wanted v1-install to install a library into the user > package database, since your cabal is 3.x and the v2-* commands are > now the default (that is, you did what used to be cabal new-install or > cabal v2-install).  > >   > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs > > wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for > Linux) system. > > But I fail; see below. > > For some reason cabal complains about installing a library.  (That > seems peculiar – isn’t that what cabal is for?)  But it helpfully > suggests adding –lib.  > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck.  What should I do? > > Thanks > > Simon > >   > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no > executables in > > target: hspec. Perhaps you want to use --lib to install libraries > instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed > for pattern Just ghcPkgProg > >   > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > >   > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > >   > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output Twitter Github LinkedIn This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From allbery.b at gmail.com Mon Apr 15 22:02:31 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 18:02:31 -0400 Subject: Cabal woes In-Reply-To: References: Message-ID: Yes, I think a lot of documentation will need to be updated because this. You want "cabal v1-install" with cabal 3. On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones wrote: > Thanks. But alas I have no clue about whether I want a v1-install or a > v2-install, nor how to achieve them if I knew what they were. I just want > to install ‘hspec’ so that I can use it when compiling a program. How > would I do that? > > > > The instructions here https://wiki.haskell.org/Cabal-Install just say > “cabal install hspec” which is what I tried. Those instructions are > pointed to from here > https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in > turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/. > > > > I must be missing something. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > I think you wanted v1-install to install a library into the user package > database, since your cabal is 3.x and the v2-* commands are now the default > (that is, you did what used to be cabal new-install or cabal v2-install). > > > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) > system. > > But I fail; see below. > > For some reason cabal complains about installing a library. (That seems > peculiar – isn’t that what cabal is for?) But it helpfully suggests adding > –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no executables in > > target: hspec. Perhaps you want to use --lib to install libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for > pattern Just ghcPkgProg > > > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 15 22:13:43 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 22:13:43 +0000 Subject: Cabal woes In-Reply-To: References: Message-ID: Aha! That works. I would never in a million years have found that by myself. Thank you. But * It is terribly mysterious that “cabal install hspec” doesn’t, well, install hspec. * It must surely be a bug that “cabal install –lib hspec” simply crashes. Simon From: Brandon Allbery Sent: 15 April 2019 23:03 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Cabal woes Yes, I think a lot of documentation will need to be updated because this. You want "cabal v1-install" with cabal 3. On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones > wrote: Thanks. But alas I have no clue about whether I want a v1-install or a v2-install, nor how to achieve them if I knew what they were. I just want to install ‘hspec’ so that I can use it when compiling a program. How would I do that? The instructions here https://wiki.haskell.org/Cabal-Install just say “cabal install hspec” which is what I tried. Those instructions are pointed to from here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in turn are pointed to from the main Cabal home page https://www.haskell.org/cabal/. I must be missing something. Simon From: Brandon Allbery > Sent: 15 April 2019 22:54 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Cabal woes I think you wanted v1-install to install a library into the user package database, since your cabal is 3.x and the v2-* commands are now the default (that is, you did what used to be cabal new-install or cabal v2-install). On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs > wrote: I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar – isn’t that what cabal is for?) But it helpfully suggests adding –lib. Alas, cabal then crashes outright, which should never happen. So I’m stuck. What should I do? Thanks Simon simonpj at MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj at MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj at MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj at MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj at MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj at MSRC-9870733:~$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 15 22:17:29 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 18:17:29 -0400 Subject: Cabal woes In-Reply-To: References: Message-ID: I vaguely recall seeing that bug come up with respect to v2-install. And in fact am a bit surprised that 3 has been released, since this is highlighting that neither it nor the Haskell ecosystem is quite ready for it. I'd also have expected (and thought I'd seen) "cabal install" in recent 2.x warn that it would be "v1-install" in the future. On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones wrote: > Aha! That works. I would never in a million years have found that by > myself. Thank you. > > > > But > > - It is terribly mysterious that “cabal install hspec” doesn’t, well, > install hspec. > - It must surely be a bug that “cabal install –lib hspec” simply > crashes. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 23:03 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > Yes, I think a lot of documentation will need to be updated because this. > You want "cabal v1-install" with cabal 3. > > > > On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones > wrote: > > Thanks. But alas I have no clue about whether I want a v1-install or a > v2-install, nor how to achieve them if I knew what they were. I just want > to install ‘hspec’ so that I can use it when compiling a program. How > would I do that? > > > > The instructions here https://wiki.haskell.org/Cabal-Install > > just say “cabal install hspec” which is what I tried. Those instructions > are pointed to from here > https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package > , > which in turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/ > > . > > > > I must be missing something. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > I think you wanted v1-install to install a library into the user package > database, since your cabal is 3.x and the v2-* commands are now the default > (that is, you did what used to be cabal new-install or cabal v2-install). > > > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) > system. > > But I fail; see below. > > For some reason cabal complains about installing a library. (That seems > peculiar – isn’t that what cabal is for?) But it helpfully suggests adding > –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no executables in > > target: hspec. Perhaps you want to use --lib to install libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for > pattern Just ghcPkgProg > > > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Mon Apr 15 22:22:15 2019 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 16 Apr 2019 01:22:15 +0300 Subject: Cabal woes In-Reply-To: References: Message-ID: <4585856b-b899-1f90-033f-13808aa6c6f0@iki.fi> cabal-install-3 isn't released. Please check the facts. - Oleg On 16.4.2019 1.17, Brandon Allbery wrote: > I vaguely recall seeing that bug come up with respect to v2-install. > And in fact am a bit surprised that 3 has been released, since this is > highlighting that neither it nor the Haskell ecosystem is quite ready > for it. > > I'd also have expected (and thought I'd seen) "cabal install" in > recent 2.x warn that it would be "v1-install" in the future. > > On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones > > wrote: > > Aha!  That works.  I would never in a million years have found > that by myself.  Thank you. > > But > > * It is terribly mysterious that “cabal install hspec” doesn’t, > well, install hspec. > * It must surely be a bug that “cabal install –lib hspec” simply > crashes. > > Simon > > *From:*Brandon Allbery > > *Sent:* 15 April 2019 23:03 > *To:* Simon Peyton Jones > > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > Yes, I think a lot of documentation will need to be updated > because this. You want "cabal v1-install" with cabal 3. > > On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones > > wrote: > > Thanks.  But alas I have no clue about whether I want a > v1-install or a v2-install, nor how to achieve them if I knew > what they were.  I just want to install ‘hspec’ so that I can > use it when compiling a program.  How would I do that? > > The instructions here https://wiki.haskell.org/Cabal-Install > > just say “cabal install hspec” which is what I tried.  Those > instructions are pointed to from here > https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package > , > which in turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/ > . > > I must be missing something. > > Simon > > *From:*Brandon Allbery > > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > I think you wanted v1-install to install a library into the > user package database, since your cabal is 3.x and the v2-* > commands are now the default (that is, you did what used to be > cabal new-install or cabal v2-install). > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via > ghc-devs > > wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem > for Linux) system. > > But I fail; see below. > > For some reason cabal complains about installing a > library.  (That seems peculiar – isn’t that what cabal is > for?)  But it helpfully suggests adding –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are > no executables in > > target: hspec. Perhaps you want to use --lib to install > libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern > failed for pattern Just ghcPkgProg > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 15 22:23:57 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 18:23:57 -0400 Subject: Cabal woes In-Reply-To: <4585856b-b899-1f90-033f-13808aa6c6f0@iki.fi> References: <4585856b-b899-1f90-033f-13808aa6c6f0@iki.fi> Message-ID: The facts here are in the original message: Simon has a cabal-install that claims to be 3.0.0.0, and is treating "install" as "v2-install". So evidently *someone* has released it in some fashion, perhaps inappropriately. On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus wrote: > cabal-install-3 isn't released. Please check the facts. > > - Oleg > > On 16.4.2019 1.17, Brandon Allbery wrote: > > I vaguely recall seeing that bug come up with respect to v2-install. And > in fact am a bit surprised that 3 has been released, since this is > highlighting that neither it nor the Haskell ecosystem is quite ready for > it. > > I'd also have expected (and thought I'd seen) "cabal install" in recent > 2.x warn that it would be "v1-install" in the future. > > On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones > wrote: > >> Aha! That works. I would never in a million years have found that by >> myself. Thank you. >> >> >> >> But >> >> - It is terribly mysterious that “cabal install hspec” doesn’t, well, >> install hspec. >> - It must surely be a bug that “cabal install –lib hspec” simply >> crashes. >> >> >> >> Simon >> >> >> >> *From:* Brandon Allbery >> *Sent:* 15 April 2019 23:03 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: Cabal woes >> >> >> >> Yes, I think a lot of documentation will need to be updated because this. >> You want "cabal v1-install" with cabal 3. >> >> >> >> On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones >> wrote: >> >> Thanks. But alas I have no clue about whether I want a v1-install or a >> v2-install, nor how to achieve them if I knew what they were. I just want >> to install ‘hspec’ so that I can use it when compiling a program. How >> would I do that? >> >> >> >> The instructions here https://wiki.haskell.org/Cabal-Install >> >> just say “cabal install hspec” which is what I tried. Those instructions >> are pointed to from here >> https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package >> , >> which in turn are pointed to from the main Cabal home page >> https://www.haskell.org/cabal/ >> >> . >> >> >> >> I must be missing something. >> >> >> >> Simon >> >> >> >> *From:* Brandon Allbery >> *Sent:* 15 April 2019 22:54 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: Cabal woes >> >> >> >> I think you wanted v1-install to install a library into the user package >> database, since your cabal is 3.x and the v2-* commands are now the default >> (that is, you did what used to be cabal new-install or cabal v2-install). >> >> >> >> On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < >> ghc-devs at haskell.org> wrote: >> >> I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) >> system. >> >> But I fail; see below. >> >> For some reason cabal complains about installing a library. (That seems >> peculiar – isn’t that what cabal is for?) But it helpfully suggests adding >> –lib. >> >> Alas, cabal then crashes outright, which should never happen. >> >> So I’m stuck. What should I do? >> >> Thanks >> >> Simon >> >> >> >> simonpj at MSRC-9870733:~$ cabal --version >> >> cabal-install version 3.0.0.0 >> >> compiled using version 3.0.0.0 of the Cabal library >> >> simonpj at MSRC-9870733:~$ cabal install hspec >> >> Resolving dependencies... >> >> Up to date >> >> Warning: You asked to install executables, but there are no executables in >> >> target: hspec. Perhaps you want to use --lib to install libraries instead. >> >> simonpj at MSRC-9870733:~$ cabal install --lib hspec >> >> Resolving dependencies... >> >> Up to date >> >> Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for >> pattern Just ghcPkgProg >> >> >> >> simonpj at MSRC-9870733:~$ which ghc >> >> /opt/ghc/bin/ghc >> >> simonpj at MSRC-9870733:~$ which ghc-pkg >> >> /opt/ghc/bin/ghc-pkg >> >> simonpj at MSRC-9870733:~$ >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> >> >> -- >> >> brandon s allbery kf8nh >> >> allbery.b at gmail.com >> >> >> >> >> -- >> >> brandon s allbery kf8nh >> >> allbery.b at gmail.com >> > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Apr 15 22:38:45 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 15 Apr 2019 15:38:45 -0700 Subject: Cabal woes In-Reply-To: References: Message-ID: Hello, in case it is useful, here is how I think about what's happening with cabal. At present, `cabal-install` supports two different modes of operation: the old style (aka `v1`) and the new style (aka `v2`) and---at least for me---the two require a slightly different mental model of what is going on. In the old model, there is a user package database, and users would use "cabal install" to install libraries their manually (e.g., using `cabal-install`). Later, when building various artifacts cabal would prefer using the packages installed in the user's database. This database supported having multiple versions of a package, but NOT multiple builds of the same version of a package (e.g., against different dependencies). As a result, builds would sometimes fail, because the dependencies of packages would clash with each other (the unfortunate "cabal hell"). With the new model, there is still a "user" level location where libraries are installed, but it is not really directly manipulated by the user---rather it acts as more of a "cache" containing all versions of all libraries every built and---crucially---it supports having multiple builds of the same version of a package against different dependencies. When users build an artifact using the new style (aka "v2"), cabal automatically checks if a suitable version of the library is already built in its cache, and if not it adds it there. The important difference between the two (at least in my mind) is that with the new style, you never just install a library on its own. Rather, you install it as a part of a project, so Cabal can compute which version it should install so that you get a version compatible with the rest of the project. Since in this model you never really install libraries directly, the `install` command defaults to installing executables, which is what the first error is trying to say. So, if you want to try out `hspec` with the `v2` style of Cabal, you'd just add it as a dependencies in the `cabal` file of your project, and then use `cabal v2-build` to build the project, without having to install it manually first. I hope this helps, -Iavor On Mon, Apr 15, 2019 at 3:01 PM Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Thanks. But alas I have no clue about whether I want a v1-install or a > v2-install, nor how to achieve them if I knew what they were. I just want > to install ‘hspec’ so that I can use it when compiling a program. How > would I do that? > > > > The instructions here https://wiki.haskell.org/Cabal-Install just say > “cabal install hspec” which is what I tried. Those instructions are > pointed to from here > https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in > turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/. > > > > I must be missing something. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > I think you wanted v1-install to install a library into the user package > database, since your cabal is 3.x and the v2-* commands are now the default > (that is, you did what used to be cabal new-install or cabal v2-install). > > > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) > system. > > But I fail; see below. > > For some reason cabal complains about installing a library. (That seems > peculiar – isn’t that what cabal is for?) But it helpfully suggests adding > –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no executables in > > target: hspec. Perhaps you want to use --lib to install libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for > pattern Just ghcPkgProg > > > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.glushenkov at gmail.com Mon Apr 15 22:43:00 2019 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Mon, 15 Apr 2019 23:43:00 +0100 Subject: Cabal woes In-Reply-To: References: Message-ID: Hello Simon, On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs wrote: > > It is terribly mysterious that “cabal install hspec” doesn’t, well, install hspec. In the cabal v2-* model [1] installing libraries globally is no longer the recommended mode of operation, which is why you now need to pass --lib to 'install' to do that. There are now better alternatives for most use cases of 'install --lib': * For just trying out some set of libraries in REPL, you can use `cabal new-repl --build-depends=foo,bar,baz` outside of a project instead of ghci. [2] If you have .ghc.environment file generation turned on, you can also use plain ghci inside your project, and it will pick up the project context. [3] * For running Haskell scripts that expect extra libraries in the global package DB you can use `#! cabal` instead of `#! runghc`. [4] > It must surely be a bug that “cabal install –lib hspec” simply crashes. This is a bug that we haven't fixed yet [5]. Should've just worked. [1] https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html [2] https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl [3] https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-write-ghc-environment-files [4] https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-run [5] https://github.com/haskell/cabal/issues/5990 From simonpj at microsoft.com Mon Apr 15 22:44:32 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 22:44:32 +0000 Subject: Cabal woes In-Reply-To: References: <4585856b-b899-1f90-033f-13808aa6c6f0@iki.fi> Message-ID: Simon has a cabal-install that claims to be 3.0.0.0 Ah yes, I installed it thus: · sudo add-apt-repository ppa:hvr/ghc-wsl · sudo apt-get update · sudo apt install cabal-install-3.0 Why did I do that? Because earlier versions of cabal crashed with a mysterious “The futex facility returned an unexpected” something like this https://github.com/Microsoft/WSL/issues/3881 or this https://github.com/reflex-frp/reflex-platform/issues/293 Apparently Herbert’s 3.0 does not fail in this way. Simon From: ghc-devs On Behalf Of Brandon Allbery Sent: 15 April 2019 23:24 To: Oleg Grenrus Cc: ghc-devs at haskell.org Devs Subject: Re: Cabal woes The facts here are in the original message: Simon has a cabal-install that claims to be 3.0.0.0, and is treating "install" as "v2-install". So evidently *someone* has released it in some fashion, perhaps inappropriately. On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus > wrote: cabal-install-3 isn't released. Please check the facts. - Oleg On 16.4.2019 1.17, Brandon Allbery wrote: I vaguely recall seeing that bug come up with respect to v2-install. And in fact am a bit surprised that 3 has been released, since this is highlighting that neither it nor the Haskell ecosystem is quite ready for it. I'd also have expected (and thought I'd seen) "cabal install" in recent 2.x warn that it would be "v1-install" in the future. On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones > wrote: Aha! That works. I would never in a million years have found that by myself. Thank you. But * It is terribly mysterious that “cabal install hspec” doesn’t, well, install hspec. * It must surely be a bug that “cabal install –lib hspec” simply crashes. Simon From: Brandon Allbery > Sent: 15 April 2019 23:03 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Cabal woes Yes, I think a lot of documentation will need to be updated because this. You want "cabal v1-install" with cabal 3. On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones > wrote: Thanks. But alas I have no clue about whether I want a v1-install or a v2-install, nor how to achieve them if I knew what they were. I just want to install ‘hspec’ so that I can use it when compiling a program. How would I do that? The instructions here https://wiki.haskell.org/Cabal-Install just say “cabal install hspec” which is what I tried. Those instructions are pointed to from here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in turn are pointed to from the main Cabal home page https://www.haskell.org/cabal/. I must be missing something. Simon From: Brandon Allbery > Sent: 15 April 2019 22:54 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Cabal woes I think you wanted v1-install to install a library into the user package database, since your cabal is 3.x and the v2-* commands are now the default (that is, you did what used to be cabal new-install or cabal v2-install). On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs > wrote: I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar – isn’t that what cabal is for?) But it helpfully suggests adding –lib. Alas, cabal then crashes outright, which should never happen. So I’m stuck. What should I do? Thanks Simon simonpj at MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj at MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj at MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj at MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj at MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj at MSRC-9870733:~$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com -- brandon s allbery kf8nh allbery.b at gmail.com -- brandon s allbery kf8nh allbery.b at gmail.com _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 15 22:46:20 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 18:46:20 -0400 Subject: Cabal woes In-Reply-To: References: Message-ID: Mikhail, the use case not addressed here is people who are used to v1-style and want to keep using it — and possibly aren't in a great position to rewire their setup to fit how v2 thinks. Personally, I have situations where I use v2 and others where v1 works better. On Mon, Apr 15, 2019 at 6:43 PM Mikhail Glushenkov < mikhail.glushenkov at gmail.com> wrote: > Hello Simon, > > On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs > wrote: > > > > It is terribly mysterious that “cabal install hspec” doesn’t, well, > install hspec. > > In the cabal v2-* model [1] installing libraries globally is no longer > the recommended mode of operation, which is why you now need to pass > --lib to 'install' to do that. > > There are now better alternatives for most use cases of 'install --lib': > > * For just trying out some set of libraries in REPL, you can use > `cabal new-repl --build-depends=foo,bar,baz` outside of a project > instead of ghci. [2] If you have .ghc.environment file generation > turned on, you can also use plain ghci inside your project, and it > will pick up the project context. [3] > * For running Haskell scripts that expect extra libraries in the > global package DB you can use `#! cabal` instead of `#! runghc`. [4] > > > It must surely be a bug that “cabal install –lib hspec” simply crashes. > > This is a bug that we haven't fixed yet [5]. Should've just worked. > > > [1] https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > [2] > https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-repl > [3] > https://cabal.readthedocs.io/en/latest/nix-local-build.html#cfg-field-write-ghc-environment-files > [4] > https://cabal.readthedocs.io/en/latest/nix-local-build.html#cabal-v2-run > [5] https://github.com/haskell/cabal/issues/5990 > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 15 22:47:56 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Apr 2019 18:47:56 -0400 Subject: Cabal woes In-Reply-To: References: <4585856b-b899-1f90-033f-13808aa6c6f0@iki.fi> Message-ID: But it fails this way instead, because 3.x works differently. Probably should have checked docs given it's a new major version of cabal-install. On Mon, Apr 15, 2019 at 6:44 PM Simon Peyton Jones wrote: > Simon has a cabal-install that claims to be 3.0.0.0 > > > Ah yes, I installed it thus: > > · sudo add-apt-repository ppa:hvr/ghc-wsl > > · sudo apt-get update > > · sudo apt install cabal-install-3.0 > > > > Why did I do that? Because earlier versions of cabal crashed with a > mysterious “The futex facility returned an unexpected” something like this > https://github.com/Microsoft/WSL/issues/3881 or this > https://github.com/reflex-frp/reflex-platform/issues/293 > > > > Apparently Herbert’s 3.0 does not fail in this way. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Brandon > Allbery > *Sent:* 15 April 2019 23:24 > *To:* Oleg Grenrus > *Cc:* ghc-devs at haskell.org Devs > *Subject:* Re: Cabal woes > > > > The facts here are in the original message: Simon has a cabal-install that > claims to be 3.0.0.0, and is treating "install" as "v2-install". So > evidently *someone* has released it in some fashion, perhaps > inappropriately. > > > > On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus wrote: > > cabal-install-3 isn't released. Please check the facts. > > - Oleg > > On 16.4.2019 1.17, Brandon Allbery wrote: > > I vaguely recall seeing that bug come up with respect to v2-install. And > in fact am a bit surprised that 3 has been released, since this is > highlighting that neither it nor the Haskell ecosystem is quite ready for > it. > > > > I'd also have expected (and thought I'd seen) "cabal install" in recent > 2.x warn that it would be "v1-install" in the future. > > > > On Mon, Apr 15, 2019 at 6:13 PM Simon Peyton Jones > wrote: > > Aha! That works. I would never in a million years have found that by > myself. Thank you. > > > > But > > - It is terribly mysterious that “cabal install hspec” doesn’t, well, > install hspec. > - It must surely be a bug that “cabal install –lib hspec” simply > crashes. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 23:03 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > Yes, I think a lot of documentation will need to be updated because this. > You want "cabal v1-install" with cabal 3. > > > > On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones > wrote: > > Thanks. But alas I have no clue about whether I want a v1-install or a > v2-install, nor how to achieve them if I knew what they were. I just want > to install ‘hspec’ so that I can use it when compiling a program. How > would I do that? > > > > The instructions here https://wiki.haskell.org/Cabal-Install > > just say “cabal install hspec” which is what I tried. Those instructions > are pointed to from here > https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package > , > which in turn are pointed to from the main Cabal home page > https://www.haskell.org/cabal/ > > . > > > > I must be missing something. > > > > Simon > > > > *From:* Brandon Allbery > *Sent:* 15 April 2019 22:54 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Cabal woes > > > > I think you wanted v1-install to install a library into the user package > database, since your cabal is 3.x and the v2-* commands are now the default > (that is, you did what used to be cabal new-install or cabal v2-install). > > > > On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) > system. > > But I fail; see below. > > For some reason cabal complains about installing a library. (That seems > peculiar – isn’t that what cabal is for?) But it helpfully suggests adding > –lib. > > Alas, cabal then crashes outright, which should never happen. > > So I’m stuck. What should I do? > > Thanks > > Simon > > > > simonpj at MSRC-9870733:~$ cabal --version > > cabal-install version 3.0.0.0 > > compiled using version 3.0.0.0 of the Cabal library > > simonpj at MSRC-9870733:~$ cabal install hspec > > Resolving dependencies... > > Up to date > > Warning: You asked to install executables, but there are no executables in > > target: hspec. Perhaps you want to use --lib to install libraries instead. > > simonpj at MSRC-9870733:~$ cabal install --lib hspec > > Resolving dependencies... > > Up to date > > Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for > pattern Just ghcPkgProg > > > > simonpj at MSRC-9870733:~$ which ghc > > /opt/ghc/bin/ghc > > simonpj at MSRC-9870733:~$ which ghc-pkg > > /opt/ghc/bin/ghc-pkg > > simonpj at MSRC-9870733:~$ > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > > brandon s allbery kf8nh > > allbery.b at gmail.com > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.glushenkov at gmail.com Mon Apr 15 22:49:22 2019 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Mon, 15 Apr 2019 23:49:22 +0100 Subject: Cabal woes In-Reply-To: References: Message-ID: Hi Brandon, On Mon, 15 Apr 2019 at 23:46, Brandon Allbery wrote: > > Mikhail, the use case not addressed here is people who are used to v1-style and want to keep using it — and possibly aren't in a great position to rewire their setup to fit how v2 thinks. Personally, I have situations where I use v2 and others where v1 works better. Sure, that's why we kept v1-* set of commands for now, and also have implemented 'v2-install --lib' (which would have worked for Simon if not for the #5990 issue). From simonpj at microsoft.com Mon Apr 15 22:56:26 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Apr 2019 22:56:26 +0000 Subject: Cabal woes In-Reply-To: References: Message-ID: That’s a tremendously helpful summary, thank you Iavor. And Michail’s summary was also very helpful. Most of this is doubtless well-known to habitual cabal users, but it might be useful to explain the user model, in a way that covers these points, somewhere close to the Cabal home page. Simon From: Iavor Diatchki Sent: 15 April 2019 23:39 To: Simon Peyton Jones Cc: Brandon Allbery ; ghc-devs at haskell.org Subject: Re: Cabal woes Hello, in case it is useful, here is how I think about what's happening with cabal. At present, `cabal-install` supports two different modes of operation: the old style (aka `v1`) and the new style (aka `v2`) and---at least for me---the two require a slightly different mental model of what is going on. In the old model, there is a user package database, and users would use "cabal install" to install libraries their manually (e.g., using `cabal-install`). Later, when building various artifacts cabal would prefer using the packages installed in the user's database. This database supported having multiple versions of a package, but NOT multiple builds of the same version of a package (e.g., against different dependencies). As a result, builds would sometimes fail, because the dependencies of packages would clash with each other (the unfortunate "cabal hell"). With the new model, there is still a "user" level location where libraries are installed, but it is not really directly manipulated by the user---rather it acts as more of a "cache" containing all versions of all libraries every built and---crucially---it supports having multiple builds of the same version of a package against different dependencies. When users build an artifact using the new style (aka "v2"), cabal automatically checks if a suitable version of the library is already built in its cache, and if not it adds it there. The important difference between the two (at least in my mind) is that with the new style, you never just install a library on its own. Rather, you install it as a part of a project, so Cabal can compute which version it should install so that you get a version compatible with the rest of the project. Since in this model you never really install libraries directly, the `install` command defaults to installing executables, which is what the first error is trying to say. So, if you want to try out `hspec` with the `v2` style of Cabal, you'd just add it as a dependencies in the `cabal` file of your project, and then use `cabal v2-build` to build the project, without having to install it manually first. I hope this helps, -Iavor On Mon, Apr 15, 2019 at 3:01 PM Simon Peyton Jones via ghc-devs > wrote: Thanks. But alas I have no clue about whether I want a v1-install or a v2-install, nor how to achieve them if I knew what they were. I just want to install ‘hspec’ so that I can use it when compiling a program. How would I do that? The instructions here https://wiki.haskell.org/Cabal-Install just say “cabal install hspec” which is what I tried. Those instructions are pointed to from here https://wiki.haskell.org/Cabal/How_to_install_a_Cabal_package, which in turn are pointed to from the main Cabal home page https://www.haskell.org/cabal/. I must be missing something. Simon From: Brandon Allbery > Sent: 15 April 2019 22:54 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Cabal woes I think you wanted v1-install to install a library into the user package database, since your cabal is 3.x and the v2-* commands are now the default (that is, you did what used to be cabal new-install or cabal v2-install). On Mon, Apr 15, 2019 at 5:47 PM Simon Peyton Jones via ghc-devs > wrote: I’m trying to install ‘hspec’ on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar – isn’t that what cabal is for?) But it helpfully suggests adding –lib. Alas, cabal then crashes outright, which should never happen. So I’m stuck. What should I do? Thanks Simon simonpj at MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj at MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj at MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj at MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj at MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj at MSRC-9870733:~$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Tue Apr 16 10:12:49 2019 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Tue, 16 Apr 2019 10:12:49 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Hi all, Here is a patch for generating wrapper scripts from Hadrian: https://gitlab.haskell.org/ghc/ghc/merge_requests/780 While it's being reviewed and merged, you can create script `/ghc-stage1` with the following line yourself: "_build/stage0/bin/ghc.exe" "-package-db _build/stage1/lib/package.conf.d" "$@" It works for me, e.g. I can do ================ $ _build/ghc-stage1 helloWorld.hs [1 of 1] Compiling Main ( helloWorld.hs, helloWorld.o ) Linking helloWorld.exe ... $ ./helloWorld.exe Hello World ================ Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 15 April 2019 14:37 To: Moritz Angermann Cc: Matthew Pickering ; Andrey Mokhov ; ghc-devs at haskell.org Subject: RE: Hadrian sounds good to me! | -----Original Message----- | From: Moritz Angermann | Sent: 15 April 2019 14:29 | To: Simon Peyton Jones | Cc: Matthew Pickering ; Andrey Mokhov | ; ghc-devs at haskell.org | Subject: Re: Hadrian | | I guess we could add | | $root/ghc-stage1 (shell script) | $root/ghc-stage2 (shell script) | | As long as we understand that those are just convenience scripts. | | Why $root? Because we can have multiple build directories for different | configurations. Thus putting the scripts into the ghc folder would not | know which root you wanted. This for the default root this would be: | | _build/ghc-stage1 | _build/ghc-stage2 | | Does that sound like an intermittent solution? | | Cheers, | Moritz | | Sent from my iPhone | | > On 15 Apr 2019, at 8:47 AM, Simon Peyton Jones via ghc-devs wrote: | > | > Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). | Yes, that works. But perhaps a script to get to it would be helpful, | otherwise invoking stage1 will look entirely different to invoking stage2. | Not a bid deal, I grant you! | > | > S | > | > | -----Original Message----- | > | From: Matthew Pickering | > | Sent: 15 April 2019 13:40 | > | To: Simon Peyton Jones | > | Cc: Andrey Mokhov ; | > | ghc-devs at haskell.org | > | Subject: Re: Hadrian | > | | > | Does the stage2 compiler which is found in `stage1/bin/ghc` not | > | work for you? I thought the issue was that the stage1 compiler | doesn't work. | > | | > | Matt | > | | > | On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs | > | wrote: | > | > | > | > as a temporary workaround we could create a top-level wrapper | > | script, say `ghc-stage1.sh` that will call Stage1 GHC with the | > | right arguments, just like Hadrian itself does during the build. | > | > | > | > That sound fine, thanks. Same for ghc-stage2.sh? | > | > | > | > My difficulty is that as of today I simply do not know how to | > | invoke my freshly built GHC! | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Andrey Mokhov > Sent: 15 | > | April 2019 12:53 > To: Simon Peyton Jones | > | > Cc: ghc-devs at haskell.org > Subject: RE: Hadrian > > > > Hi | > | Simon, > > Apologies it’s taking so long. It’s not obvious how to | > | fix this properly, and as a temporary workaround we could create a | > | top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 | > | GHC with the right arguments, just like Hadrian itself does during | > | the build. | > | > | > | > Will this work for you? | > | > | > | > Cheers, | > | > Andrey | > | > | > | > | > | > | > | > From: Simon Peyton Jones [mailto:simonpj at microsoft.com] > Sent: | > | 15 April 2019 12:28 > To: Andrey Mokhov | > | > Cc: ghc-devs at haskell.org > | > | Subject: Hadrian > > > > Andrey and other Hadrian heros > > | > | Just to say that I am 100% stalled on using Hadrian because the > | > | in-tree binary uses the wrong library files. I reported this a few | > | > weeks ago, but it still seems unchanged > > Simon > > > > | > | Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version > > The Glorious | > | Glasgow Haskell Compilation System, version > 8.9.0.20190414 > > | > | simonpj at MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c > | > | T16566.hs > > > > T16566.hs:1:8: error: | > | > | > | > Bad interface file: | > | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > | > | > mismatched interface file versions (wanted "809020190414", | got | > | > "8064") | > | > | > | > | | > | > | > | > 1 | module T16566 where | > | > | > | > | ^^^^^^ | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs at haskell.org | > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > | > | > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C | > | 01 > | > | %7Csimonpj%40microsoft.com%7Cdf9439b6d848493aca9608d6c19f79f6%7C72f9 | > | 88 > | > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909288021992421&sdata=dd | > | sV > pnCFLP4D7dGqPtuMdv3oahBrOvRWVDlOV2GSwBU%3D&reserved=0 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mikhail.glushenkov at gmail.com Tue Apr 16 11:26:52 2019 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 16 Apr 2019 12:26:52 +0100 Subject: Cabal woes In-Reply-To: References: Message-ID: Hi, On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs wrote: > > That’s a tremendously helpful summary, thank you Iavor. And Michail’s summary was also very helpful. > > > > Most of this is doubtless well-known to habitual cabal users, but it might be useful to explain the user model, in a way that covers these points, somewhere close to the Cabal home page. If anyone reading this is interested in helping out with website and documentation, we'll gladly accept PRs. Documentation for Cabal lives at https://github.com/haskell/cabal/tree/master/Cabal/doc and the website sources are at https://github.com/haskell/cabal-website/ (see also the feature/next branch). From a.pelenitsyn at gmail.com Tue Apr 16 13:55:45 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Tue, 16 Apr 2019 09:55:45 -0400 Subject: Cabal woes In-Reply-To: References: Message-ID: Hi, Just wanted to note that the initial Simon's post also mentioned the outdated pages on haskell.org. It'd be good not to forget to purge them, maybe inserting links to cabal.readthedocs. -- Best, Artem On Tue, 16 Apr 2019 at 07:27 Mikhail Glushenkov < mikhail.glushenkov at gmail.com> wrote: > Hi, > > On Mon, 15 Apr 2019 at 23:56, Simon Peyton Jones via ghc-devs > wrote: > > > > That’s a tremendously helpful summary, thank you Iavor. And Michail’s > summary was also very helpful. > > > > > > > > Most of this is doubtless well-known to habitual cabal users, but it > might be useful to explain the user model, in a way that covers these > points, somewhere close to the Cabal home page. > > If anyone reading this is interested in helping out with website and > documentation, we'll gladly accept PRs. > > Documentation for Cabal lives at > https://github.com/haskell/cabal/tree/master/Cabal/doc and the website > sources are at https://github.com/haskell/cabal-website/ (see also the > feature/next branch). > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nboldi at elte.hu Tue Apr 16 14:11:59 2019 From: nboldi at elte.hu (=?UTF-8?B?TsOpbWV0aCBCb2xkaXpzw6Fy?=) Date: Tue, 16 Apr 2019 16:11:59 +0200 Subject: build .so from boot libraries Message-ID: <44f0f69d-703f-771a-f5db-d4383e2db3f5@elte.hu> Hi, I'm trying to run compiler plugins on the source code of GHC itself. (Has anyone done this before?) Somehow this forces the loading of .so files of boot libraries (like libHSterminfo-0.4.1.3.so and libHSghc-boot-th-8.9.so) during GHC's compilation. The .so files are not built at this stage (only in later stages) by default. Is there an option to create dynamically linked libraries from the boot libraries in stage 0? BR, Boldizsár From matthewtpickering at gmail.com Tue Apr 16 14:51:07 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 16 Apr 2019 15:51:07 +0100 Subject: build .so from boot libraries In-Reply-To: <44f0f69d-703f-771a-f5db-d4383e2db3f5@elte.hu> References: <44f0f69d-703f-771a-f5db-d4383e2db3f5@elte.hu> Message-ID: Boldi, I have tried to do this but the more ambitious goal of running the plugins on `base` as well. If you want to run plugins on base you have to build a stage3 compiler as stage1 doesn't have GHCi support so you can't run plugins whilst building stage2. After getting stage3 working I got blocked by another issue https://gitlab.haskell.org/ghc/ghc/issues/16561 So I will assume you are trying to run plugins whilst building stage1 with the stage0 compiler. Which indeed sounds possible. I added support to Hadrian to allow building shared objects for libraries built with stage0. I think you can enable it by just setting `libraryWays = pure [vanilla, dynamic] ` in a hadrian flavour. Otherwise you can try running the `./hadrian/build.sh tool-args` target which should build them for you. That's the target I use to load GHC into haskell-ide-engine and for ./hadrian/ghci.sh script which ran into similar issues with shared objects. Cheers, Matt On Tue, Apr 16, 2019 at 3:12 PM Németh Boldizsár wrote: > > Hi, > > I'm trying to run compiler plugins on the source code of GHC itself. > (Has anyone done this before?) Somehow this forces the loading of .so > files of boot libraries (like libHSterminfo-0.4.1.3.so and > libHSghc-boot-th-8.9.so) during GHC's compilation. The .so files are not > built at this stage (only in later stages) by default. > > Is there an option to create dynamically linked libraries from the boot > libraries in stage 0? > > BR, > Boldizsár > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From andreash87 at gmx.ch Tue Apr 23 16:51:47 2019 From: andreash87 at gmx.ch (Andreas Herrmann) Date: Tue, 23 Apr 2019 18:51:47 +0200 Subject: ZuriHac 2019 - GHC Track Message-ID: Dear GHC devs, This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Continuous Integration / DevOps, by Manual Chakravarty - PrimOps / PrimTypes, by Michal Terepeta - Performance Regression Tests, by Niklas Hambüchen - Newcomers Tutorial, by Andreas Herrmann Other possible subjects could be around: - Improving documentation - Extending GHC's test-suite - General GHC development workflows - The inner workings of some aspect of GHC Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers. Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message. Best, Niklas and Andreas ZuriHac 2019 GHC track coordinators [1]: https://zfoh.ch/zurihac2019/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Apr 24 04:55:39 2019 From: ben at well-typed.com (Ben Gamari) Date: Wed, 24 Apr 2019 00:55:39 -0400 Subject: [ANNOUNCE] GHC 8.6.5 is now available Message-ID: <8736m8uhme.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the release of GHC 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5 Release notes are also available [1]. This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Do note that due to linking issues (see #15934) profiling will be rather unreliable on Windows. This will be fixed in 8.8.1. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.5-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.jakobi at googlemail.com Wed Apr 24 06:22:38 2019 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Wed, 24 Apr 2019 08:22:38 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.6.5 is now available In-Reply-To: <8736m8uhme.fsf@smart-cactus.org> References: <8736m8uhme.fsf@smart-cactus.org> Message-ID: Hi Ben! Thanks for the release! Can you also upload the source tarballs? Cheers, Simon Am Mi., 24. Apr. 2019 um 06:56 Uhr schrieb Ben Gamari : > > Hello everyone, > > The GHC team is proud to announce the release of GHC 8.6.5. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.6.5 > > Release notes are also available [1]. > > This release fixes a handful of issues with 8.6.4: > > - Binary distributions once again ship with Haddock documentation > including > syntax highlighted source of core libraries (#16445) > > - A build system issue where use of GCC with `-flto` broke `configure` > was fixed (#16440) > > - An bug affecting Windows platforms wherein XMM register values could be > mangled when entering STG has been fixed (#16514) > > - Several Windows packaging issues resulting from the recent CI rework. > (#16408, #16398, #16516) > > Do note that due to linking issues (see #15934) profiling will be rather > unreliable on Windows. This will be fixed in 8.8.1. > > As always, if anything looks amiss do let us know. > > Happy compiling! > > Cheers, > > - Ben > > > [1] > http://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.5-notes.html > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 24 08:05:05 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 24 Apr 2019 08:05:05 +0000 Subject: Puzzled by GHC.Types.LiftedRep In-Reply-To: References: Message-ID: Try this paper The function type constructor actually has type (->) :: forall (r1::RuntimeRep) (r2::RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE LiftedRep But when it appears applied to two argument, thus ((->) r1 r2 t1 t2), we print it infix (t1 -> t2). So (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) is the same as (thing -> thing). I cannot explain why it is being printed in that non-infix way, but your email doesn’t give enough context to know. I hope this helps a bit. Where did you look for information? I’d like to add pointers that would have been helpful to you. Simon From: Ranjit Jhala Sent: 24 April 2019 04:56 To: ghc-devs at haskell.org; Simon Peyton Jones Subject: Puzzled by GHC.Types.LiftedRep Hi all, Consider the following program: ``` import Control.Arrow (second) import qualified Control.Monad.Trans.Reader as R myLocal :: (r -> r) -> R.ReaderT r m a -> R.ReaderT r m a myLocal = undefined foo :: (thing -> thing) -> R.ReaderT (d, thing) m a -> R.ReaderT (d, thing) m a foo arg = myLocal (second arg) ``` When compiled with GHC 8.6.4, I get the odd behavior that at the call `second arg`, the type of `arg` is just: thing -> thing but the *input* type of `second` (after applying the various type and dictionary parameters) is something that looks like while the *input* type of `second` (after the various type and dictionary applications etc.) is the mysterious (to me): (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) Can someone explain or point me to some documentation or paper that describes what the above means? Specifically, how/why does GHC "equate" the two things above in order to consider the core well-formed? Many thanks in advance! - Ranjit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Apr 24 09:58:03 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 24 Apr 2019 12:58:03 +0300 Subject: How do I find out which info table a continuation belongs to? In-Reply-To: References: Message-ID: Bumping thread, this is still a problem for me. I wonder if this ever worked. I should try this with older GHCs. Ömer Sergei Azovskov , 26 Şub 2019 Sal, 19:21 tarihinde şunu yazdı: > > Hey! > > Unfortunately, I'm not a big expert in gdb and debugging ghc runtime. I stripped some auto generated symbols from the symtab but they can still be found in dwarf section. I don't know how to force gdb to show them but you can manually check via dwarfdump. > ________________________________ > From: Ömer Sinan Ağacan > Sent: Sunday, February 10, 2019 6:45 PM > To: Simon Marlow > Cc: ghc-devs; Sergei Azovskov > Subject: Re: How do I find out which info table a continuation belongs to? > > I'm already using -g3. Here's my build.mk: > > BuildFlavour = quick > > ifneq "$(BuildFlavour)" "" > include mk/flavours/$(BuildFlavour).mk > endif > > GhcRtsHcOpts += -O0 -g3 > SRC_HC_OPTS += -g3 > GhcStage1HcOpts += -g3 > GhcStage2HcOpts += -g3 > GhcLibHcOpts += -g3 > > STRIP_CMD = : > > Ömer > > Simon Marlow , 10 Şub 2019 Paz, 19:00 tarihinde şunu yazdı: > > > > I believe this is due to https://urldefense.proofpoint.com/v2/url?u=https-3A__phabricator.haskell.org_D4722&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kdITsLFp8oDGMKQlc9eIzA&m=TC61xap_n2utc37GJd4nKe0d_swgwMyqoHVKekcPDZk&s=I_8-wOL9DBs5msIWONBC1IwDvNFG-rXrOgrXVhBqt6Q&e= > > > > (cc Sergei Azovskov) > > > > I'm a bit surprised that gdb isn't showing anything though, it should know that the address corresponds to a temporary symbol like `.L1234`. Perhaps you need to compile with -g to make this work, I'm not sure. > > > > On Sun, 10 Feb 2019 at 07:50, Ömer Sinan Ağacan wrote: > >> > >> I'm currently working on a bug and one of the things I often want to know is > >> what's on the stack. The problem is I can't see labels of continuations so the > >> information is really useless. Example: > >> > >> >>> call printStack(((StgTSO*)0x42000e0198)->stackobj) > >> 0x42000c8788: RET_SMALL (0x512d70) > >> 0x42000c8790: RET_SMALL (0x40edf0) > >> stk[5] (0x42000c8798) = 0x7b3938 > >> 0x42000c87a0: CATCH_FRAME(0x735a98,0x7d3ff2) > >> 0x42000c87b8: STOP_FRAME(0x7311b8) > >> > >> (I modified the printer to print stack locations when printing stacks) > >> > >> Here I need to know which info table the RET_SMALLs return to. Normally I do > >> this for other kinds of closures: > >> > >> >>> print ((StgClosure*)...)->header.info > >> $15 = (const StgInfoTable *) 0x404dc0 > >> > >> But for continuations that doesn't work: > >> > >> >>> print ((StgClosure*)0x42000c8788)->header.info > >> $11 = (const StgInfoTable *) 0x512d80 > >> >>> info symbol 0x512d80 > >> No symbol matches 0x512d80. > >> > >> Anyone know how to make this work? Can I maybe mark the continuations label in > >> the generated assembly somehow to make those labels available in gdb? > >> > >> Thanks > >> > >> Ömer > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2Dbin_mailman_listinfo_ghc-2Ddevs&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kdITsLFp8oDGMKQlc9eIzA&m=TC61xap_n2utc37GJd4nKe0d_swgwMyqoHVKekcPDZk&s=OIXAtMjQkAnHAverwOpWQrKM1GIy-Eo85s3wxcnOqfU&e= From omeragacan at gmail.com Thu Apr 25 06:23:56 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 25 Apr 2019 09:23:56 +0300 Subject: Marge bot UX improvement suggestion Message-ID: I think it'd be useful if Marge listed commits that it's trying to merge in the description of the MR so that we could get a list of commits in the emails. Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with an empty body. Ömer From ben at smart-cactus.org Thu Apr 25 15:05:54 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 25 Apr 2019 11:05:54 -0400 Subject: Marge bot UX improvement suggestion In-Reply-To: References: Message-ID: <87h8amt99r.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > I think it'd be useful if Marge listed commits that it's trying to merge in the > description of the MR so that we could get a list of commits in the emails. > Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with an empty > body. > I'm generally reluctant to invest any more effort into Marge. She's in general barely holding together and hopefully within a month we'll be able to move to GitLab's native merge train solution. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu Apr 25 23:51:17 2019 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Apr 2019 19:51:17 -0400 Subject: [ANNOUNCE] GHC 8.8.1-alpha1 is now available Message-ID: <87a7gdtziv.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the first alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha1 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release starts the pre-release cycle for GHC 8.8. This cycle is starting quite a bit later than expected due recent work on GHC's CI and release infrastructure. See the GHC Blog [2] for more on this. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-notes.html [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lonetiger at gmail.com Fri Apr 26 09:41:05 2019 From: lonetiger at gmail.com (Phyx) Date: Fri, 26 Apr 2019 10:41:05 +0100 Subject: Marge bot UX improvement suggestion In-Reply-To: <87h8amt99r.fsf@smart-cactus.org> References: <87h8amt99r.fsf@smart-cactus.org> Message-ID: Speaking of bots.. What's a Moe bot? Haha. Sent from my Mobile On Thu, Apr 25, 2019, 16:06 Ben Gamari wrote: > Ömer Sinan Ağacan writes: > > > I think it'd be useful if Marge listed commits that it's trying to merge > in the > > description of the MR so that we could get a list of commits in the > emails. > > Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with > an empty > > body. > > > I'm generally reluctant to invest any more effort into Marge. She's in > general barely holding together and hopefully within a month we'll be > able to move to GitLab's native merge train solution. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Fri Apr 26 09:42:40 2019 From: me at ara.io (Ara Adkins) Date: Fri, 26 Apr 2019 10:42:40 +0100 Subject: Marge bot UX improvement suggestion In-Reply-To: References: <87h8amt99r.fsf@smart-cactus.org> Message-ID: Yeah I just got a flood of a few hundred emails from ‘Moe Bot’. _ara > On 26 Apr 2019, at 10:41, Phyx wrote: > > Speaking of bots.. What's a Moe bot? Haha. > > Sent from my Mobile > >> On Thu, Apr 25, 2019, 16:06 Ben Gamari wrote: >> Ömer Sinan Ağacan writes: >> >> > I think it'd be useful if Marge listed commits that it's trying to merge in the >> > description of the MR so that we could get a list of commits in the emails. >> > Currently the emails just say "Marge Bot Barch MR - DO NOT TOUCH" with an empty >> > body. >> > >> I'm generally reluctant to invest any more effort into Marge. She's in >> general barely holding together and hopefully within a month we'll be >> able to move to GitLab's native merge train solution. >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Fri Apr 26 10:16:16 2019 From: davide at well-typed.com (David Eichmann) Date: Fri, 26 Apr 2019 11:16:16 +0100 Subject: Moe Bot Message-ID: <9e66322c-bd30-4947-4440-fc675ff62531@well-typed.com> Hello All, I've been working on Moe Bot recently who will quote commits that mention issues. When a commit is pushed to master, Moe will create a new comment on the referenced issue quoting the full commit message. This is for your convenience so you can avoid having to navigate off the page to see the full commit message. Unfortunately this has triggered a large number of notification emails as Moe works to quote existing commits. *You can safely ignore emails from Moe.* I've disabled him for now. Sorry for the disturbance this morning. David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at ara.io Fri Apr 26 10:29:33 2019 From: me at ara.io (Ara Adkins) Date: Fri, 26 Apr 2019 11:29:33 +0100 Subject: Moe Bot In-Reply-To: <9e66322c-bd30-4947-4440-fc675ff62531@well-typed.com> References: <9e66322c-bd30-4947-4440-fc675ff62531@well-typed.com> Message-ID: <80405277-B084-42C3-9691-4A7AA351362F@ara.io> Hey David, This is going to be a great boon! Thanks so much for your hard work on this! _ara > On 26 Apr 2019, at 11:16, David Eichmann wrote: > > Hello All, > > I've been working on Moe Bot recently who will quote commits that mention issues. When a commit is pushed to master, Moe will create a new comment on the referenced issue quoting the full commit message. This is for your convenience so you can avoid having to navigate off the page to see the full commit message. > > Unfortunately this has triggered a large number of notification emails as Moe works to quote existing commits. You can safely ignore emails from Moe. I've disabled him for now. Sorry for the disturbance this morning. > > David Eichmann > > -- > David Eichmann, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri Apr 26 12:48:21 2019 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 26 Apr 2019 09:48:21 -0300 Subject: [ANNOUNCE] GHC 8.8.1-alpha1 is now available In-Reply-To: <87a7gdtziv.fsf@smart-cactus.org> References: <87a7gdtziv.fsf@smart-cactus.org> Message-ID: It seems as if there is no migration documentation, https://gitlab.haskell.org/ghc/ghc/wikis/status/migration/8.8. Will that be forthcoming? Thanks George On Thu, Apr 25, 2019 at 8:51 PM Ben Gamari wrote: > Hello everyone, > > The GHC team is pleased to announce the first alpha release of GHC 8.8.1. > The source distribution, binary distributions, and documentation are > available at > > https://downloads.haskell.org/~ghc/8.8.1-alpha1 > > A draft of the release notes is also available [1]. > > This release is the culmination of over 3000 commits by over one hundred > contributors and has several new features and numerous bug fixes > relative to GHC 8.6: > > * Profiling now works correctly on 64-bit Windows (although still may > be problematic on 32-bit Windows due to platform limitations; see > #15934) > > * A new code layout algorithm for amd64's native code generator > > * The introduction of a late lambda-lifting pass which may reduce > allocations significantly for some programs. > > * Further work on Trees That Grow, enabling improved code re-use of the > Haskell AST in tooling > > * More locations where users can write `forall` (GHC Proposal #0007) > > * Further work on the Hadrian build system > > This release starts the pre-release cycle for GHC 8.8. This cycle is > starting quite a bit later than expected due recent work on GHC's CI and > release infrastructure. See the GHC Blog [2] for more on this. > > As always, if anything looks amiss do let us know. > > Happy compiling! > > Cheers, > > - Ben > > > [1] > https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-notes.html > [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri Apr 26 12:54:22 2019 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 26 Apr 2019 08:54:22 -0400 Subject: [ANNOUNCE] GHC 8.8.1-alpha1 is now available Message-ID: The 8.8 Migration Guide can be found here: https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8 Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Apr 26 23:08:13 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 26 Apr 2019 19:08:13 -0400 Subject: Gitlab down Message-ID: <87wojgs6uf.fsf@smart-cactus.org> Due to an unfortunate mis-typing of the word "restart" gitlab.haskell.org is currently rebooting. I'll let you know when it's back up. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From omeragacan at gmail.com Sat Apr 27 06:44:20 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 27 Apr 2019 09:44:20 +0300 Subject: Why not short out IND_STATICs in the GC? Message-ID: Hi Simon, I'm wondering why in the GC we don't short out IND_STATICs like we do in INDs and BLACKHOLEs. Is there a reason for that? In this code in evacuate(): case IND_STATIC: evacuate_static_object(IND_STATIC_LINK((StgClosure *)q), q); return; Why not do something like case IND_STATIC: q = ((StgIndStatic*)q)->indirectee; *p = q; goto loop; I actually tried it and it broke a lot of things, but I don't understand why. We basically turn this heap closure -> IND_STATIC -> heap closure into heap closure -> heap closure To me this should work, but for some reason it doesn't. Could you comment on why this doesn't work? Thanks, Ömer From omeragacan at gmail.com Sat Apr 27 11:12:43 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 27 Apr 2019 14:12:43 +0300 Subject: Locations in the codegen where we assume pointers tagged with certain values? Message-ID: Hi all, I'm trying to find all places in the code generator where we assume that a pointer is tagged with a certain value. A generated code for this looks like this: mov 0x6(%rbx),%rax This moves payload[0] of the closure in %rbx to %rax, but it assumes that %rbx is tagged with 2 so it does 0x6(%rbx) instead of 0x8(%rbx). Anyone know where I should be looking at? Context: I'm implementing shorting out indirections in the concurrent collector. The code is quite similar to the current collector, except we do a cas() when updating the IND/BLACKHOLE pointer with the pointer to the indirectee. The problem is this causes all kinds of problems, in our debugging mostly caused by pointer misalignment. One concrete example of where this happens is we do mov 0x6(%rbx),%rax but the pointer in %rbx is actually tagged 3 instead of 2. The reason is I think we're breaking some invariants in the generated code where we assume certain tags from pointers (2 in the example above), but I couldn't find where in the code generator we do this. Thanks, Ömer From matthewtpickering at gmail.com Sat Apr 27 11:37:12 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 27 Apr 2019 12:37:12 +0100 Subject: GHC API, GHCi, profiling, shared objects Message-ID: Hi, If I write a program using the GHC API then the resulting executable is sensitive to the version of GHC which I used to build the program. For example, if I build a version of GHC which has profiling enabled (prof flavour) then building my application (static linking) with this version means that I can only load packages which were also built with profiling enabled. This happens in particular when you load a module which uses TemplateHaskell which causes all the dependencies to be loaded. If the so isn't built with profiling then you get errors such as ``` : can't load .so/.DLL for: libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): image not found) ``` This seemed to somewhat make sense to me because compiling with/without profiling changes the heap representation but then I considered whether this also happens in GHCi and I concluded that it didn't. In particular, it seems to me that 1. GHCi is not built by a profiled version of GHC and is still a "GHC API application" 2. There is no problem loading profiled packages into GHCi despite this fact? 1. Does GHCi do something special to mitigate against these kinds of failures? 2. Is this a difference between staticly and dynamically linking the application executable (`ghc` in the case for ghci). ? Hopefully someone familiar with the implementation of the linker will be able to clear this up. Cheers, Matt From ben at smart-cactus.org Sat Apr 27 13:51:14 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 27 Apr 2019 09:51:14 -0400 Subject: Locations in the codegen where we assume pointers tagged with certain values? In-Reply-To: References: Message-ID: <87tvejsgj6.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > Hi all, > > I'm trying to find all places in the code generator where we assume that a > pointer is tagged with a certain value. A generated code for this looks like > this: > > mov 0x6(%rbx),%rax > > This moves payload[0] of the closure in %rbx to %rax, but it assumes that %rbx > is tagged with 2 so it does 0x6(%rbx) instead of 0x8(%rbx). > > Anyone know where I should be looking at? > I would start by looking at uses of tagForCon, lfDynTag and mkTaggedObjectLoad. Also, did you check that the tag we apply to the closure pointer matches the tag that the info table defines? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From omeragacan at gmail.com Sat Apr 27 14:51:59 2019 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 27 Apr 2019 17:51:59 +0300 Subject: Locations in the codegen where we assume pointers tagged with certain values? In-Reply-To: <87tvejsgj6.fsf@smart-cactus.org> References: <87tvejsgj6.fsf@smart-cactus.org> Message-ID: > Also, did you check that the tag we apply to the closure pointer matches the > tag that the info table defines? Yep, see my update in the Gitlab issue. Ömer Ben Gamari , 27 Nis 2019 Cmt, 16:51 tarihinde şunu yazdı: > > Ömer Sinan Ağacan writes: > > > Hi all, > > > > I'm trying to find all places in the code generator where we assume that a > > pointer is tagged with a certain value. A generated code for this looks like > > this: > > > > mov 0x6(%rbx),%rax > > > > This moves payload[0] of the closure in %rbx to %rax, but it assumes that %rbx > > is tagged with 2 so it does 0x6(%rbx) instead of 0x8(%rbx). > > > > Anyone know where I should be looking at? > > > I would start by looking at uses of tagForCon, lfDynTag and mkTaggedObjectLoad. > > Also, did you check that the tag we apply to the closure pointer matches > the tag that the info table defines? > > Cheers, > > - Ben From marlowsd at gmail.com Mon Apr 29 07:33:44 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 29 Apr 2019 08:33:44 +0100 Subject: Why not short out IND_STATICs in the GC? In-Reply-To: References: Message-ID: On Sat, 27 Apr 2019 at 07:44, Ömer Sinan Ağacan wrote: > Hi Simon, > > I'm wondering why in the GC we don't short out IND_STATICs like we do in > INDs > and BLACKHOLEs. Is there a reason for that? In this code in evacuate(): > > case IND_STATIC: > evacuate_static_object(IND_STATIC_LINK((StgClosure *)q), q); > return; > > Why not do something like > > case IND_STATIC: > q = ((StgIndStatic*)q)->indirectee; > *p = q; > goto loop; > > I actually tried it and it broke a lot of things, but I don't understand > why. > We basically turn this > > heap closure -> IND_STATIC -> heap closure > > into > > heap closure -> heap closure > > To me this should work, but for some reason it doesn't. Could you comment > on why > this doesn't work? > I think it might be to do with generational GC, although I'm not completely sure and it would be good to nail down the precise reasoning and document it. CAFs live in the old generation, and when we first enter a CAF we add it to the mutable list (remembered set). If we ignore the IND_STATIC, then the closure will never get re-added to the mutable list, even if it still points into the young generation. So the data will remain live for one GC, but not the next GC. When we do an old-generation GC we might find the CAF to be live (via the SRTs), but we've already GC'd the value it pointed to, so it's too late. Cheers Simon > > > Thanks, > > Ömer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi.boy.travis at gmail.com Tue Apr 30 04:25:18 2019 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Mon, 29 Apr 2019 21:25:18 -0700 Subject: Type Annotations in the Presence of Injective Type Families, Bidirectional Pattern Synonyms, and Data Kinds Message-ID: Hello GHC Devs, I've found a case in which annotating a bidirectional pattern synonym with a type signature causes the typechecker to reject an otherwise typeable program. Before filing a bug report I want to check that I'm thinking about this correctly. Consider this module: {-# LANGUAGE TypeFamilies , TypeFamilyDependencies , DataKinds , TypeOperators , GADTs , FlexibleContexts , PatternSynonyms #-} module Strange where data Expr a where Tuple :: NTup ts -> Expr (Flatten ts) data NTup (ts :: [*]) where Unit :: NTup '[] Pair :: Expr a -> NTup ts -> NTup (a ': ts) type family Flatten ts = r | r -> ts where Flatten '[] = () Flatten '[a, b] = (a, b) pattern P a b = Pair a (Pair b Unit) fstExpr :: Expr (a, b) -> (Expr a, Expr b) fstExpr (Tuple (P x y)) = (x, y) The idea is that an NTup '[a, b, c ...] should be isomorphic to an (a, b, c, ...), but removes a lot of repetitive code for dealing with Exprs of tuples. This module compiles with GHC 8.6.4 and GHC infers the expected type for P. P :: Expr a -> Expr a1 -> NTup '[a, a1] However, annotating P with this type causes typechecking fstExpr to fail with: Strange.hs:26:17: error: • Could not deduce: ts ~ '[a, b] from the context: (a, b) ~ Flatten ts bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 ‘ts’ is a rigid type variable bound by a pattern with constructor: Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), in an equation for ‘fstExpr’ at Strange.hs:26:10-22 Expected type: NTup ts Actual type: NTup '[a, b] • In the pattern: P x y In the pattern: Tuple (P x y) In an equation for ‘fstExpr’: fstExpr (Tuple (P x y)) = (x, y) • Relevant bindings include fstExpr :: Expr (a, b) -> (Expr a, Expr b) (bound at Strange.hs:26:1) | 26 | fstExpr (Tuple (P x y)) = (x, y) | ^^^^^ It seems that providing a type signature causes GHC to forget the injectivity of Flatten (i.e (a, b) ~ Flatten ts implies ts ~ '[a, b]). Is this a bug, some limitation of pattern synonyms, or am I missing something? Thanks as always, Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Apr 30 06:46:13 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 30 Apr 2019 07:46:13 +0100 Subject: Type Annotations in the Presence of Injective Type Families, Bidirectional Pattern Synonyms, and Data Kinds In-Reply-To: References: Message-ID: Please can you open a bug report anyway? It is easier to discuss it there than on the mailing list. Matt On Tue, Apr 30, 2019 at 5:25 AM Travis Whitaker wrote: > > Hello GHC Devs, > > I've found a case in which annotating a bidirectional pattern synonym with a type signature causes the typechecker to reject an otherwise typeable program. Before filing a bug report I want to check that I'm thinking about this correctly. Consider this module: > > {-# LANGUAGE TypeFamilies > , TypeFamilyDependencies > , DataKinds > , TypeOperators > , GADTs > , FlexibleContexts > , PatternSynonyms > #-} > > module Strange where > > data Expr a where > Tuple :: NTup ts -> Expr (Flatten ts) > > data NTup (ts :: [*]) where > Unit :: NTup '[] > Pair :: Expr a -> NTup ts -> NTup (a ': ts) > > type family Flatten ts = r | r -> ts where > Flatten '[] = () > Flatten '[a, b] = (a, b) > > pattern P a b = Pair a (Pair b Unit) > > fstExpr :: Expr (a, b) -> (Expr a, Expr b) > fstExpr (Tuple (P x y)) = (x, y) > > The idea is that an NTup '[a, b, c ...] should be isomorphic to an (a, b, c, ...), but removes a lot of repetitive code for dealing with Exprs of tuples. This module compiles with GHC 8.6.4 and GHC infers the expected type for P. > > P :: Expr a -> Expr a1 -> NTup '[a, a1] > > However, annotating P with this type causes typechecking fstExpr to fail with: > > Strange.hs:26:17: error: > • Could not deduce: ts ~ '[a, b] > from the context: (a, b) ~ Flatten ts > bound by a pattern with constructor: > Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), > in an equation for ‘fstExpr’ > at Strange.hs:26:10-22 > ‘ts’ is a rigid type variable bound by > a pattern with constructor: > Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), > in an equation for ‘fstExpr’ > at Strange.hs:26:10-22 > Expected type: NTup ts > Actual type: NTup '[a, b] > • In the pattern: P x y > In the pattern: Tuple (P x y) > In an equation for ‘fstExpr’: fstExpr (Tuple (P x y)) = (x, y) > • Relevant bindings include > fstExpr :: Expr (a, b) -> (Expr a, Expr b) > (bound at Strange.hs:26:1) > | > 26 | fstExpr (Tuple (P x y)) = (x, y) > | ^^^^^ > > It seems that providing a type signature causes GHC to forget the injectivity of Flatten (i.e (a, b) ~ Flatten ts implies ts ~ '[a, b]). Is this a bug, some limitation of pattern synonyms, or am I missing something? > > Thanks as always, > > Travis > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From pi.boy.travis at gmail.com Tue Apr 30 07:09:34 2019 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Tue, 30 Apr 2019 00:09:34 -0700 Subject: Type Annotations in the Presence of Injective Type Families, Bidirectional Pattern Synonyms, and Data Kinds In-Reply-To: References: Message-ID: Sure, here it is. https://gitlab.haskell.org/ghc/ghc/issues/16614 On Mon, Apr 29, 2019 at 11:46 PM Matthew Pickering < matthewtpickering at gmail.com> wrote: > Please can you open a bug report anyway? It is easier to discuss it > there than on the mailing list. > > Matt > > On Tue, Apr 30, 2019 at 5:25 AM Travis Whitaker > wrote: > > > > Hello GHC Devs, > > > > I've found a case in which annotating a bidirectional pattern synonym > with a type signature causes the typechecker to reject an otherwise > typeable program. Before filing a bug report I want to check that I'm > thinking about this correctly. Consider this module: > > > > {-# LANGUAGE TypeFamilies > > , TypeFamilyDependencies > > , DataKinds > > , TypeOperators > > , GADTs > > , FlexibleContexts > > , PatternSynonyms > > #-} > > > > module Strange where > > > > data Expr a where > > Tuple :: NTup ts -> Expr (Flatten ts) > > > > data NTup (ts :: [*]) where > > Unit :: NTup '[] > > Pair :: Expr a -> NTup ts -> NTup (a ': ts) > > > > type family Flatten ts = r | r -> ts where > > Flatten '[] = () > > Flatten '[a, b] = (a, b) > > > > pattern P a b = Pair a (Pair b Unit) > > > > fstExpr :: Expr (a, b) -> (Expr a, Expr b) > > fstExpr (Tuple (P x y)) = (x, y) > > > > The idea is that an NTup '[a, b, c ...] should be isomorphic to an (a, > b, c, ...), but removes a lot of repetitive code for dealing with Exprs of > tuples. This module compiles with GHC 8.6.4 and GHC infers the expected > type for P. > > > > P :: Expr a -> Expr a1 -> NTup '[a, a1] > > > > However, annotating P with this type causes typechecking fstExpr to fail > with: > > > > Strange.hs:26:17: error: > > • Could not deduce: ts ~ '[a, b] > > from the context: (a, b) ~ Flatten ts > > bound by a pattern with constructor: > > Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten > ts), > > in an equation for ‘fstExpr’ > > at Strange.hs:26:10-22 > > ‘ts’ is a rigid type variable bound by > > a pattern with constructor: > > Tuple :: forall (ts :: [*]). NTup ts -> Expr (Flatten ts), > > in an equation for ‘fstExpr’ > > at Strange.hs:26:10-22 > > Expected type: NTup ts > > Actual type: NTup '[a, b] > > • In the pattern: P x y > > In the pattern: Tuple (P x y) > > In an equation for ‘fstExpr’: fstExpr (Tuple (P x y)) = (x, y) > > • Relevant bindings include > > fstExpr :: Expr (a, b) -> (Expr a, Expr b) > > (bound at Strange.hs:26:1) > > | > > 26 | fstExpr (Tuple (P x y)) = (x, y) > > | ^^^^^ > > > > It seems that providing a type signature causes GHC to forget the > injectivity of Flatten (i.e (a, b) ~ Flatten ts implies ts ~ '[a, b]). Is > this a bug, some limitation of pattern synonyms, or am I missing something? > > > > Thanks as always, > > > > Travis > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 30 08:37:41 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Apr 2019 08:37:41 +0000 Subject: GHC loose ends Message-ID: Friends Like many people, I use my inbox as a to-do list. Over time, despite my best efforts, I accumulate a rising tide of GHC-related things (mostly tickets) where I feel I should do something, but it'd take too long to do today, so maybe tomorrow. Periodically I sweep all these into another folder, which makes me feel less oppressed by backlog. So this email is just to say: if you are waiting for some kind of response from me, please fell free to ping me. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 30 11:19:45 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Apr 2019 11:19:45 +0000 Subject: GHC user manual Message-ID: Where is the latest GHC user manual. I tried https://ghc.gitlab.haskell.org/ghc/doc/ but got a 502 failure. It would be good if it was easy to find the link from the developers home page https://gitlab.haskell.org/ghc/ghc/wikis/home Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Tue Apr 30 12:12:39 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Tue, 30 Apr 2019 21:12:39 +0900 Subject: GHC user manual In-Reply-To: References: Message-ID: Hi Simon, > Where is the latest GHC user manual. I tried Here is the latest (ghc-8.6.5) GHC user manual: https://downloads.haskell.org/ghc/latest/docs/html/users_guide > It would be good if it was easy to find the link from the developers home page > https://gitlab.haskell.org/ghc/ghc/wikis/home I added the link to the wiki's right side bar. Could you tell me if your intention is different? P.S. Currently, the link to the HEAD (master) document seems broken. https://ghc.gitlab.haskell.org/ghc/doc/ Regards, Takenobu On Tue, Apr 30, 2019 at 8:20 PM Simon Peyton Jones via ghc-devs wrote: > > Where is the latest GHC user manual. I tried > > https://ghc.gitlab.haskell.org/ghc/doc/ > > but got a 502 failure. > > It would be good if it was easy to find the link from the developers home page > > https://gitlab.haskell.org/ghc/ghc/wikis/home > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Apr 30 12:40:53 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Apr 2019 12:40:53 +0000 Subject: GHC user manual In-Reply-To: References: Message-ID: | I added the link to the wiki's right side bar. | Could you tell me if your intention is different? That's a help; but can the link say "GHC User's Guide (latest release)". We might also want to have "GHC User's Guide (master branch)" to be the one built last night from master. Or, at least, to have this linked from somewhere discoverable. Simon | -----Original Message----- | From: Takenobu Tani | Sent: 30 April 2019 13:13 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: GHC user manual | | Hi Simon, | | > Where is the latest GHC user manual. I tried | | Here is the latest (ghc-8.6.5) GHC user manual: | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownload | s.haskell.org%2Fghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide&data=01%7C01% | 7Csimonpj%40microsoft.com%7Cdc090c670a53491639c108d6cd652d3a%7C72f988bf86f | 141af91ab2d7cd011db47%7C1&sdata=QWyBRVeeE6iZZX67VLL3Eg55g0Weh8xrziXuZb | 0rxZY%3D&reserved=0 | | | > It would be good if it was easy to find the link from the developers | > home page | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fhome&data=01%7C01%7Csimonpj%4 | > 0microsoft.com%7Cdc090c670a53491639c108d6cd652d3a%7C72f988bf86f141af91 | > ab2d7cd011db47%7C1&sdata=GnAfp%2Bds1xhrgjZvK8hwBPukoF5DwOyk20APMPI | > tkak%3D&reserved=0 | | I added the link to the wiki's right side bar. | Could you tell me if your intention is different? | | | P.S. | Currently, the link to the HEAD (master) document seems broken. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.gitl | ab.haskell.org%2Fghc%2Fdoc%2F&data=01%7C01%7Csimonpj%40microsoft.com%7 | Cdc090c670a53491639c108d6cd652d3a%7C72f988bf86f141af91ab2d7cd011db47%7C1&a | mp;sdata=1UqeBf8dgdxmN4OsKoO%2BsyJXmrJc4P0bSFIMQiZPWpE%3D&reserved=0 | | Regards, | Takenobu | | On Tue, Apr 30, 2019 at 8:20 PM Simon Peyton Jones via ghc-devs wrote: | > | > Where is the latest GHC user manual. I tried | > | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc. | > gitlab.haskell.org%2Fghc%2Fdoc%2F&data=01%7C01%7Csimonpj%40microso | > ft.com%7Cdc090c670a53491639c108d6cd652d3a%7C72f988bf86f141af91ab2d7cd0 | > 11db47%7C1&sdata=1UqeBf8dgdxmN4OsKoO%2BsyJXmrJc4P0bSFIMQiZPWpE%3D& | > amp;reserved=0 | > | > but got a 502 failure. | > | > It would be good if it was easy to find the link from the developers | > home page | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fhome&data=01%7C01%7Csimonpj%4 | > 0microsoft.com%7Cdc090c670a53491639c108d6cd652d3a%7C72f988bf86f141af91 | > ab2d7cd011db47%7C1&sdata=GnAfp%2Bds1xhrgjZvK8hwBPukoF5DwOyk20APMPI | > tkak%3D&reserved=0 | > | > Simon | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=01%7C01 | > %7Csimonpj%40microsoft.com%7Cdc090c670a53491639c108d6cd652d3a%7C72f988 | > bf86f141af91ab2d7cd011db47%7C1&sdata=h6c5QcoZJHkHQt2KJBGP9sOXs9%2B | > 1PrRHop%2Fpsx7GFZs%3D&reserved=0 From takenobu.hs at gmail.com Tue Apr 30 13:45:34 2019 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Tue, 30 Apr 2019 22:45:34 +0900 Subject: GHC user manual In-Reply-To: References: Message-ID: > We might also want to have "GHC User's Guide (master branch)" to be the one built last > night from master. Or, at least, to have this linked from somewhere discoverable. I see. What you intend is the master (HEAD) document. I created the sub page for "GHC User's Guide" [1] and linked from the right side-bar on wiki [2]. >From that page, I made it possible to find both latest and master. I will brush up this page. [1]: https://gitlab.haskell.org/ghc/ghc/wikis/ghc-users-guide [2]: https://gitlab.haskell.org/ghc/ghc/wikis/home Regards, Takenobu From simonpj at microsoft.com Tue Apr 30 15:02:43 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Apr 2019 15:02:43 +0000 Subject: GHC user manual In-Reply-To: References: Message-ID: Great! | -----Original Message----- | From: Takenobu Tani | Sent: 30 April 2019 14:46 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: GHC user manual | | > We might also want to have "GHC User's Guide (master branch)" to be the | one built last > night from master. Or, at least, to have this linked | from somewhere discoverable. | | I see. What you intend is the master (HEAD) document. | | I created the sub page for "GHC User's Guide" [1] and linked from the | right side-bar on wiki [2]. | | From that page, I made it possible to find both latest and master. | I will brush up this page. | | [1]: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fghc-users- | guide&data=01%7C01%7Csimonpj%40microsoft.com%7C5a0825ba956e4954fb5f08d | 6cd722899%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=YzqUN%2Bg51gk6u | BAMJ2NJISXQ2JA%2BdQk065TxpsqpHmg%3D&reserved=0 | [2]: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h | askell.org%2Fghc%2Fghc%2Fwikis%2Fhome&data=01%7C01%7Csimonpj%40microso | ft.com%7C5a0825ba956e4954fb5f08d6cd722899%7C72f988bf86f141af91ab2d7cd011db | 47%7C1&sdata=KtubXOZoCymiQLvbDVinm1PfyaxO0gh%2BEAVG5HNPH3s%3D&rese | rved=0 | | Regards, | Takenobu From rae at richarde.dev Tue Apr 30 16:43:20 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 30 Apr 2019 12:43:20 -0400 Subject: ZuriHac 2019 - GHC Track In-Reply-To: References: Message-ID: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> I'm also happy to lead a session on GHC. I could perhaps give a high-level overview (no slides, just whiteboard & projected code) on the GHC compilation pipeline. I don't expect it would be terribly hands-on, though I would hope to get lots of questions from the audience. This might most easily come before Simon's presentation, which would doubtless be more detailed. I'm happy to assist others in their hacking efforts, too. I'll be around Fri - Sun. Richard > On Apr 23, 2019, at 12:51 PM, Andreas Herrmann wrote: > > Dear GHC devs, > > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. It was a great success last year, and we hope it will be a great success this year as well. > > For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. > > For some inspiration, these are the subjects from last year's track: > - Continuous Integration / DevOps, by Manual Chakravarty > - PrimOps / PrimTypes, by Michal Terepeta > - Performance Regression Tests, by Niklas Hambüchen > - Newcomers Tutorial, by Andreas Herrmann > > Other possible subjects could be around: > - Improving documentation > - Extending GHC's test-suite > - General GHC development workflows > - The inner workings of some aspect of GHC > > Aside from preparing a session, we are also looking for volunteers to be around as GHC mentors during hack sessions to help out newcomers. > > Please let us know if you'd be interested in leading a session, or being a mentor, or helping out with this track in any other way. You can contact either Niklas or myself, on this list or by private message. > > Best, > Niklas and Andreas > ZuriHac 2019 GHC track coordinators > > [1]: https://zfoh.ch/zurihac2019/ _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddu.druid at gmail.com Tue Apr 30 17:17:05 2019 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Tue, 30 Apr 2019 22:47:05 +0530 Subject: ZuriHac 2019 - GHC Track In-Reply-To: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> References: <5706C947-37F0-4640-9A59-99310AF00320@richarde.dev> Message-ID: I'm not sure if this is the right place, but I'm putting this out there at any rate: I'd be interested in a deep dive into STG and related shenanigans "within the compiler", since my understanding is that a decent amount has changed since the last paper on STG (eval/apply). This is out of an interest in understanding STG as-it-lives within GHC so I can get back to simplexhc(https://github.com/bollu/simplexhc), a pet project of mine. I meant to take some time and read through the GHC internals in this area, but college coursework does not really facilitate deep meditation about the GHC codebase ;) Would someone be willing to help with this? Thanks, ~Siddharth On Tue, Apr 30, 2019 at 10:13 PM Richard Eisenberg wrote: > I'm also happy to lead a session on GHC. I could perhaps give a high-level > overview (no slides, just whiteboard & projected code) on the GHC > compilation pipeline. I don't expect it would be terribly hands-on, though > I would hope to get lots of questions from the audience. This might most > easily come before Simon's presentation, which would doubtless be more > detailed. > > I'm happy to assist others in their hacking efforts, too. > > I'll be around Fri - Sun. > > Richard > > On Apr 23, 2019, at 12:51 PM, Andreas Herrmann wrote: > > Dear GHC devs, > > This year's ZuriHac 2019 [1] will again feature a dedicated GHC track to > foster contributions to GHC and teach newcomers how to participate in GHC's > development. It was a great success last year, and we hope it will be a > great success this year as well. > > For that we need your help: We would like to invite you to organize a > session in the GHC track. This could be in form of a presentation, a > workshop, or a hack session with topics centered around GHC. > > For some inspiration, these are the subjects from last year's track: > - Continuous Integration / DevOps, by Manual Chakravarty > - PrimOps / PrimTypes, by Michal Terepeta > - Performance Regression Tests, by Niklas Hambüchen > - Newcomers Tutorial, by Andreas Herrmann > > Other possible subjects could be around: > - Improving documentation > - Extending GHC's test-suite > - General GHC development workflows > - The inner workings of some aspect of GHC > > Aside from preparing a session, we are also looking for volunteers to be > around as GHC mentors during hack sessions to help out newcomers. > > Please let us know if you'd be interested in leading a session, or being a > mentor, or helping out with this track in any other way. You can contact > either Niklas or myself, on this list or by private message. > > Best, > Niklas and Andreas > ZuriHac 2019 GHC track coordinators > > [1]: https://zfoh.ch/zurihac2019/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: