Re: Reproducing bugs without Stack

[Michael Sloan]

I don't have a good answer to your overall question, particularly when
reproducing the issue necessarily requires a large set of build
dependencies.  However, one thing that may be helpful is to use `stack
build --cabal-verbose`.  This will pass `--verbose` when running
Setup.hs, and ghc invocations are included in its verbose output.

Assuming your terminal's current dir is the package that the ghc
invocation is building, and the dependencies are built, you can run
paste the ghc invocation after `stack exec -- ` and it should work.
So, for example:

```
stack exec -- /home/mgsloan/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc
--make -no-link -fbuilding-cabal-package ...
```

Then, perhaps you can try removing arguments of the ghc invocation to
attempt to arrive at a more minimal reproduction.

-Michael

On Sat, Jan 19, 2019 at 9:08 PM Eric Crockett  wrote:
>
> Devs,
>
> I use Stack for all of my Haskell development. I recently ran into several 
> bugs, which I suspected to be GHC bugs. In the process of creating new 
> tickets, I noticed a banner reading "Please try to provide reproduction 
> instructions which do not require "Stack"." The request is reasonable to help 
> weed out bugs in Stack itself, but I could use some advice on how to do that.
>
> In particular, I'm having trouble reproducing bugs related to profiling. For 
> example, #16182 is about runtime crashes with the -hr profiling option. This 
> was clearly a GHC bug rather than a problem with stack, yet I have so far 
> been unable to produce the bug without Stack. Similarly, for #16166, I filed 
> the ticket, then after failing to reproduce the bug with cabal, assumed it 
> must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm 
> that it is in fact a GHC bug. Ryan explained that my problem reproducing with 
> cabal is due to differences in the profiling options used by stack and cabal.
>
> In summary, it would be helpful to have some instructions on how to take a 
> bug produced using Stack to one produced without. For example, if `stack 
> build [--profile] foo` produces a compile bug, how should I use cabal to 
> definitively determine if the bug is a problem with Stack or GHC? Presumably 
> it would begin with `cabal sandbox init`. Are there special options to put in 
> the cabal.config file so that cabal uses the same profiling options as stack? 
> Will those options be used when building all dependencies?
>
> Thanks,
> Eric Crockett
> ___
> 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

Reproducing bugs without Stack

[Eric Crockett]

Devs,

I use Stack for all of my Haskell development. I recently ran into several
bugs, which I suspected to be GHC bugs. In the process of creating new
tickets, I noticed a banner reading "*Please try to provide reproduction
instructions which do not require "Stack"." *The request is reasonable to
help weed out bugs in Stack itself, but I could use some advice on how to
do that.

In particular, I'm having trouble reproducing bugs related to profiling.
For example, #16182  is
about runtime crashes with the -hr profiling option. This was clearly a GHC
bug rather than a problem with stack, yet I have so far been unable to
produce the bug without Stack. Similarly, for #16166
, I filed the ticket, then
after failing to reproduce the bug with cabal, assumed it must be a stack
bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in
fact a GHC bug. Ryan explained that my problem reproducing with cabal is
due to differences in the profiling options used by stack and cabal.

In summary, it would be helpful to have some instructions on how to take a
bug produced using Stack to one produced without. For example, if `stack
build [--profile] foo` produces a compile bug, how should I use cabal to
definitively determine if the bug is a problem with Stack or GHC?
Presumably it would begin with `cabal sandbox init`. Are there special
options to put in the cabal.config file so that cabal uses the same
profiling options as stack? Will those options be used when building all
dependencies?

Thanks,
Eric Crockett
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thoughts on the Contributing page

[Ben Gamari]

For those following along at home:

   David has been looking at revising our contributor documentation.
   He has started consolidating a variety of relevant content on the
   Contributing page of the Wiki [1]. Below are my thoughts; feel free
   to chime in with your own.


David,

The contributing page is looking quite good. However, I do wonder
whether we could reduce the link "fan-out" a bit more: it still rather
feels like a collection of links with no clear "beginning".

The "Newcomers to GHC" section is a great start but I see two
potential issues:

 * we don't clearly articulate the precise steps that a newcomer will
   need to take

 * the first thing we mention are four links which, while useful,
   constitute a significant volume of reading for a newcomer.
   I fear we may lose people at this point.

Regarding the second point, I think that WorkingConventions/FixingBugs is a
good model in that it clearly lists a series of concrete steps that the
contributor should take. Admittedly, I think some of the detail should
be dropped or moved (e.g. the mention of setting git's user.name
variable is likely unnecessary in 2019).

I think that something similar to this list should be the first thing
one sees when they reach the contributing page. Ideally the "typical"
case of a new contributor wanting to submit their first patch would be
able to gather everything they need to get started in one or two
screenfuls of text. After that prose can come additional links to
more in-depth documentation.

Other various issues I noticed:

 * We link to wiki:WorkingConventions from a variety of places
   (including wiki:Contributing) but it is now just a link to
   wiki:Contributing.

 * wiki:WorkingConventions/FixingBugs still has references to
   Phabricator. In general we should start culling such references.

 * wiki:WorkingConventions/FixingBugs also has references to Trac
   documentation. We should try to replace these with the relevant
   GitLab documentation when we migrate.

 * wiki:WorkingConventions/FixingBugs should be updated to reflect
   that GitLab CI is now the source of truth for validation.

 * I don't know exactly how this should look but I think we need to do a
   better job of concisely stating what we expect of contributions. That
   is:

 * commit messages should be readable and discuss what the patch
   does. "Fixes #" is not an adequate commit message.

 * changes should be commented where necessary (my usual rule of
   thumb is "write the comment you would have liked to read when you
   started writing your patch"). We should mention the Note
   convention.

 * commit messages and comments should refer to ticket numbers where
   appropriate (e.g. using usual # syntax; people often get this
   wrong).

 * commits should be either squashed or logically distinct,
   individually buildable changes.

 * changes to most of `base` need to go through the CLC (this may be
   optional as defining what set of `base` this applies to is a bit
   tricky; in the interest of keeping things concise we may be
   better off handling this personally on a case-by-case basis)

 * code changes should conform to GHC's (somewhat fluid, for better
   or worse) code style
   (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle)

 * thought should be given to testing

Having a document which succinctly summarised these expectations as
we could easily refer to it during code review. Even better, we
could excerpt it as a checklist in our merge request description
template (I have put up an initial attempt at this as !149).

Anyways, there is more to be said here but this email is getting a bit
long so let's leave it for future discussions.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Contributing


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Gabor Greif]

I have just tried putting following URL into the discussion tab's URL bar

 javascript: $(".discussion-toggle-button:has(i.fa-chevron-down)").click()

and it seems to work.

Cheers,

Gabor

On 1/4/19, Artem Pelenitsyn  wrote:
> It seems you'd want the "Toggle All" button. There is an issue for that:
>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/19149
>
> There is even a beautiful workaround given there with typing the following
> command in the JavaScript console in a browser:
> $(".discussion-toggle-button:has(i.fa-chevron-down)").click()
> After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
> module should reference the symbol") while before I could not.
>
> --
> Best, Artem
>
> On Fri, 4 Jan 2019 at 21:48 Ben Gamari  wrote:
>
>> Quite right. I will bring this up with upstream.
>>
>> On January 4, 2019 1:04:43 PM EST, Brandon Allbery 
>> wrote:
>>>
>>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:
>>>
 As mentioned by others, discussions that have been marked as "resolved"
 are collapsed by default. If you search for the text "Toggle
 discussion"
 you will find that the collapsed discussions have link on their
 right-hand side which you can click on to expand the hidden comments.

>>>
>>> The problem there being there's a lot of such, and no way to tell which
>>> one is relevant unless you have both original links and enough context.
>>> Finding stuff like that absent context doesn't look at all easy. :/
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allber...@gmail.com
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> 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