Re: Gitlab workflow
On 11/07/2019 17.47, Ben Gamari wrote: [--snip--] I'm just going to snip all of that because that was an almost perfect summary of why rebase-always is best. I'm *not* talking about rebasing willy-nilly, but I agree that rebasing private branches and rebasing-with-agreement is superior in every way to the just-merge-things approach... and you formulated it perfectly. Thank you. Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab workflow
Am Do., 11. Juli 2019 um 14:32 Uhr schrieb Bryan Richter : > [...] When references to commits (in emails etc.) get invalidated, > it adds confusion and extra work. Seeing this happen is what led me to > wonder why people even prefer this strategy. > I think there is a misunderstanding here: You never ever force-push rebased commits to a public repo, this would indeed change commit hashes and annoy all your collaborators like hell. In a rebase-only workflow you rebase locally, pushing your then fast-forward-only merge to the public repo. You can even disable force-pushed on the receiving side, an that's what is normally done (well, not on GitHub...). > [...] One final thing I like about merges is conflict resolution. Resolving > conflicts via rebase is something I get wrong 40% of the time. It's > hard. Even resolving a conflict during a merge is hard, but it's > easier. Hmmm, I don't see a difference with conflict resolution in both cases, the work involved is equivalent. > Plus, the eventual merge commit keeps a record of the > resolution! (I only learned this recently, since `git log` doesn't > show it by default.) Keeping a public record of how a conflict was > resolved seems like a huge benefit. [...] > To me it is quite the opposite: In a collaborative environment, I don't care even the tiniest bit about how somebody resolved the conflicts of his branch: This is a technical artifact about when the branch was made and when it is merged. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Issue weight migration
Brandon Allbery writes: > Isn't there already a "needs triage" label separate from this? Which would > make that plus explicit priority a suggested priority to guide whoever's > doing triage. (I expect triage goes beyond simply priority setting, e.g. > making sure it has the right component(s) and maybe assigning specific > people who know that component.) > Yes, this is precisely my concern. If our experience with Trac is any guide it seems likely that reporters will indeed set issues priorities and it's not clear that this is something that we want to discourage. For this reason I haven't yet removed the "needs triage" label and won't do so until we get a sense for how frequently reporters set the priority themselves. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cabal reports mismatched interface file ways dyn
Yes, it looks so: $ ls -1 libraries/ghc-prim/dist-install/build/GHC/CString.* libraries/ghc-prim/dist-install/build/GHC/CString.dyn_hi libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o libraries/ghc-prim/dist-install/build/GHC/CString.hi libraries/ghc-prim/dist-install/build/GHC/CString.o $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist-install/build/GHC/CString.hi | grep --after-context=1 Way Way: Wanted [d, y, n], got[] On Thu, Jul 11, 2019 at 11:03:16AM +0100, Matthew Pickering wrote: > Does the quick flavour build the dynamic libraries? > > On Thu, Jul 11, 2019 at 10:07 AM Stefan Schulze Frielinghaus > wrote: > > > > Hi all, > > > > I'm trying to compile GHC 8.6.5 using the LLVM backend and dynamic linking. > > My > > build.mk file looks as follows: > > > > include mk/flavours/quick-llvm.mk > > DYNAMIC_BY_DEFAULT = YES > > > > I can build a stage3 compiler. However while executing `make install` the > > following error shows up: > > > > "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install > > "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" > > "/devel/ghc86/lib/ghc-8.6.5/bin/ghc-pkg" "/devel/ghc86/lib/ghc-8.6.5" '' > > '/devel/ghc86' '/devel/ghc86/lib/ghc-8.6.5' > > '/devel/ghc86/share/doc/ghc-8.6.5/html/libraries' NO > > ghc-cabal: '/devel/ghc86/lib/ghc-8.6.5/bin/ghc' exited with an error: > > Bad interface file: dist-install/build/GHC/CString.hi > > mismatched interface file ways (wanted "dyn", got "") > > > > I found similar reports [1,2] from 2013 but no solution. Any ideas how to > > fix > > this? > > > > Cheers, > > Stefan > > > > [1] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003488.html > > [2] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003507.html > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab workflow
On 7/7/19 7:53 PM, Sven Panne wrote:> Am So., 7. Juli 2019 um 17:06 Uhr schrieb Bryan Richter : > > How does the scaling argument reconcile with the massive scope > > of the Linux kernel, the project for which git was created? I > > can find some middle ground with the more specific points > > you made in your email, but I have yet to understand how the > > scaling argument holds water when Linux trucks along with "4000 > > developers, 450 different companies, and 200 new developers each > > release"[1]. What makes Linux special in this regard? Is there > > some second inflection point? > > > Well, somehow I saw that example coming... :-D I think the main > reason why things work for Linux is IMHO the amount of highly > specialized high-quality maintainers, i.e. the people who pick the > patches into the (parts of) the releases they maintain, and who do > it as their main (sole?) job. In addition they have a brutal review > system plus an army of people continuously testing *and* they have > Linus. :D I would add to your argument that they appear to use git primarily to *keep a record of merges*. Incoming patches have no history whatsoever; they're just individual patches. I guess that could be considered a simpler-to-use version of the fast-forward-only strategy! Perhaps Linux isn't such a great counterexample after all Once they have committed patches to some particular history, though, they don't rebase, since that would rewrite important audit history. > I would very much like to turn the question around: I never fully > understood why some people like merge-based workflows so much. OK, > you can see that e.g. commits A, B, and C together implement feature > X, but to be honest: After the feature X landed, probably nobody > really cares about the feature's history anymore, you normally care > much more about: Which commit broke feature Y? Which commit slowed > down things? Which commit introduced a space leak/race condition? What I *don't* like is rewriting history, for all the reasons I don't like mutable state. As you say, what you're generally interested in is commits. When references to commits (in emails etc.) get invalidated, it adds confusion and extra work. Seeing this happen is what led me to wonder why people even prefer this strategy. On top of that, many of the problems people have with merges actually seem to be problems with bad commits, as you yourself hinted. Other concerns seem to be based in unfamiliarity with git's features, or an irrational desire for "pure history". (Merges *are* history!) One final thing I like about merges is conflict resolution. Resolving conflicts via rebase is something I get wrong 40% of the time. It's hard. Even resolving a conflict during a merge is hard, but it's easier. Plus, the eventual merge commit keeps a record of the resolution! (I only learned this recently, since `git log` doesn't show it by default.) Keeping a public record of how a conflict was resolved seems like a huge benefit. In the end, my main takeaway is that good commits are just as important as good code, regardless of strategy. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cabal reports mismatched interface file ways dyn
Does the quick flavour build the dynamic libraries? On Thu, Jul 11, 2019 at 10:07 AM Stefan Schulze Frielinghaus wrote: > > Hi all, > > I'm trying to compile GHC 8.6.5 using the LLVM backend and dynamic linking. My > build.mk file looks as follows: > > include mk/flavours/quick-llvm.mk > DYNAMIC_BY_DEFAULT = YES > > I can build a stage3 compiler. However while executing `make install` the > following error shows up: > > "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install > "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" "/devel/ghc86/lib/ghc-8.6.5/bin/ghc-pkg" > "/devel/ghc86/lib/ghc-8.6.5" '' '/devel/ghc86' '/devel/ghc86/lib/ghc-8.6.5' > '/devel/ghc86/share/doc/ghc-8.6.5/html/libraries' NO > ghc-cabal: '/devel/ghc86/lib/ghc-8.6.5/bin/ghc' exited with an error: > Bad interface file: dist-install/build/GHC/CString.hi > mismatched interface file ways (wanted "dyn", got "") > > I found similar reports [1,2] from 2013 but no solution. Any ideas how to fix > this? > > Cheers, > Stefan > > [1] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003488.html > [2] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003507.html > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cleanly setting C compiler options when building RTS
That's indeed one Hadrian solution. An alternative one (requires
'master' from yesterday) is:
$ hadrian/build.sh --flavour=... "stage1.rts.cc.c.opts +=
-fsanitize=address -fsanitize=undefined"
Note that I'm not quite sure who between GHC and the C compiler gets
invoked to build the RTS. If it's GHC, then you'll need to replace
'builder Cc' in Matthew's solution with 'builder (Ghc CompileCWithGhc)',
or with the key-value style approach:
$ hadrian/build.sh --flavour=... "stage1.rts.ghc.c.opts +=
-fsanitize=address -fsanitize=undefined"
You can find more about how both of those settings mechanisms work here:
https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md
... once GitLab works again. :-)
Until then:
https://github.com/ghc/ghc/blob/master/hadrian/doc/user-settings.md
On 11/07/2019 11:49, Matthew Pickering wrote:
Hi Siddharth,
The correct way is to create a custom flavour with something like the
following in.
grts = quickFlavour { name = "grts", args = args quickFlavour <>
(builder Cc ? package rts ? arg "-g3" <> arg "-O0") }
Cheers,
Matt
On Thu, Jul 11, 2019 at 10:20 AM Siddharth Bhat wrote:
Hello all,
I was interested in building the GHC RTS with GCC's AddressSanitizer and Ubsan
enabled.
What I want to do very specifically is to pass "-fsanitize=address
-fsanitize=undefined" when compiling the RTS.
What's the "correct" way to set this up in the build system? Is there a
configure flag? Do I need to change the Shake script?
Thanks,
~Siddharth
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Alp Mestanogullari, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/
Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cleanly setting C compiler options when building RTS
Hi Siddharth,
The correct way is to create a custom flavour with something like the
following in.
grts = quickFlavour { name = "grts", args = args quickFlavour <>
(builder Cc ? package rts ? arg "-g3" <> arg "-O0") }
Cheers,
Matt
On Thu, Jul 11, 2019 at 10:20 AM Siddharth Bhat wrote:
>
> Hello all,
>
> I was interested in building the GHC RTS with GCC's AddressSanitizer and
> Ubsan enabled.
>
> What I want to do very specifically is to pass "-fsanitize=address
> -fsanitize=undefined" when compiling the RTS.
>
> What's the "correct" way to set this up in the build system? Is there a
> configure flag? Do I need to change the Shake script?
> Thanks,
> ~Siddharth
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cleanly setting C compiler options when building RTS
Since you mention the Shake script, should we assume you're using Hadrian, or the Make build system? On 11/07/2019 11:19, Siddharth Bhat wrote: Hello all, I was interested in building the GHC RTS with GCC's AddressSanitizer and Ubsan enabled. What I want to do very specifically is to pass "-fsanitize=address -fsanitize=undefined" when compiling the RTS. What's the "correct" way to set this up in the build system? Is there a configure flag? Do I need to change the Shake script? Thanks, ~Siddharth ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Cleanly setting C compiler options when building RTS
Hello all, I was interested in building the GHC RTS with GCC's AddressSanitizer and Ubsan enabled. What I want to do very specifically is to pass "-fsanitize=address -fsanitize=undefined" when compiling the RTS. What's the "correct" way to set this up in the build system? Is there a configure flag? Do I need to change the Shake script? Thanks, ~Siddharth ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Cabal reports mismatched interface file ways dyn
Hi all, I'm trying to compile GHC 8.6.5 using the LLVM backend and dynamic linking. My build.mk file looks as follows: include mk/flavours/quick-llvm.mk DYNAMIC_BY_DEFAULT = YES I can build a stage3 compiler. However while executing `make install` the following error shows up: "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" "/devel/ghc86/lib/ghc-8.6.5/bin/ghc-pkg" "/devel/ghc86/lib/ghc-8.6.5" '' '/devel/ghc86' '/devel/ghc86/lib/ghc-8.6.5' '/devel/ghc86/share/doc/ghc-8.6.5/html/libraries' NO ghc-cabal: '/devel/ghc86/lib/ghc-8.6.5/bin/ghc' exited with an error: Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") I found similar reports [1,2] from 2013 but no solution. Any ideas how to fix this? Cheers, Stefan [1] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003488.html [2] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003507.html ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
