Re: multiple top level Main.main binders in STG

[Csaba Hruska]

Unfortunately it is dumped by my custom added code. (source code

)
I rerun my custom stg dump and it seems the unique values (in {--}
comments) are different.
How can I tell which is the real *Main.main* function?

Cheers,
Csaba

*Main.main {-r1550-}* =
  closure (F:) (B:
  void.040 {-040-}) {
  Main.main1 {-r16514-}
GHC.Prim.void# {-021-}}

Main.main3 {-r16518-} =
  closure (F:) (B:
  void.040 {-040-}) {
  GHC.TopHandler.runMainIO1 {-r9161-}
Main.main1 {-r16514-}
GHC.Prim.void# {-021-}}

*Main.main {-0101-}* =
  closure (F:) (B:
  void.040 {-040-}) {
  Main.main3 {-r16518-}
GHC.Prim.void# {-021-}}



On Fri, Nov 2, 2018 at 11:18 PM Ben Gamari  wrote:

> Csaba Hruska  writes:
>
> > Hello,
> >
> > I added an STG exporter to my modified GHC to do experiments with the STG
> > representation of the program.
> > I noticed that there are multiple top-level binders for *Main.main*
> > function.
> > Is this a convention or a bug?
> >
> What GHC command line did you use to produce this output? Is it possible
> that you passed -dsuppress-uniques? If so the multiple `main`s probably
> differ in unique.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: multiple top level Main.main binders in STG

[Ben Gamari]

Csaba Hruska  writes:

> Hello,
>
> I added an STG exporter to my modified GHC to do experiments with the STG
> representation of the program.
> I noticed that there are multiple top-level binders for *Main.main*
> function.
> Is this a convention or a bug?
>
What GHC command line did you use to produce this output? Is it possible
that you passed -dsuppress-uniques? If so the multiple `main`s probably
differ in unique.

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: multiple top level Main.main binders in STG

[Csaba Hruska]

P.S.
I'd like to emphasize that this is produced by GHC and GHC's codegen
compiles it properly to a working executable.

On Fri, Nov 2, 2018 at 10:18 PM Csaba Hruska  wrote:

> Hello,
>
> I added an STG exporter to my modified GHC to do experiments with the STG
> representation of the program.
> I noticed that there are multiple top-level binders for *Main.main*
> function.
> Is this a convention or a bug?
>
> Regards,
> Csaba Hruska
>
> Here is an example code snippet of the exported STG of the Main module:
> Main.main2 =
>   closure (F:) (B:) {
>   case Main.$wupto 1# 1000#
>   of sat.s16537 {
> DEFAULT ->
>   case Main.$wxsum 0# sat.s16537
>   of ww.s16538 {
> DEFAULT ->
>   case GHC.Show.$wshowSignedInt
>  0# ww.s16538 GHC.Types.[]
>   of ww4.s16539 {
> GHC.Prim.(#,#) ww5.s16540 ww6.s16541 ->
>   GHC.Types.:
> ww5.s16540 ww6.s16541
>   }
>   }
>   }}
>
> Main.main1 =
>   closure (F:) (B: void.040) {
>   GHC.IO.Handle.Text.hPutStr2
> GHC.IO.Handle.FD.stdout
> Main.main2
> GHC.Types.True
> GHC.Prim.void#}
>
> *Main.main* =
>   closure (F:) (B: void.040) {
>   Main.main1 GHC.Prim.void#}
>
> Main.main3 =
>   closure (F:) (B: void.040) {
>   GHC.TopHandler.runMainIO1
> Main.main1 GHC.Prim.void#}
>
> *Main.main* =
>   closure (F:) (B: void.040) {
>   Main.main3 GHC.Prim.void#}
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

multiple top level Main.main binders in STG

[Csaba Hruska]

Hello,

I added an STG exporter to my modified GHC to do experiments with the STG
representation of the program.
I noticed that there are multiple top-level binders for *Main.main*
function.
Is this a convention or a bug?

Regards,
Csaba Hruska

Here is an example code snippet of the exported STG of the Main module:
Main.main2 =
  closure (F:) (B:) {
  case Main.$wupto 1# 1000#
  of sat.s16537 {
DEFAULT ->
  case Main.$wxsum 0# sat.s16537
  of ww.s16538 {
DEFAULT ->
  case GHC.Show.$wshowSignedInt
 0# ww.s16538 GHC.Types.[]
  of ww4.s16539 {
GHC.Prim.(#,#) ww5.s16540 ww6.s16541 ->
  GHC.Types.:
ww5.s16540 ww6.s16541
  }
  }
  }}

Main.main1 =
  closure (F:) (B: void.040) {
  GHC.IO.Handle.Text.hPutStr2
GHC.IO.Handle.FD.stdout
Main.main2
GHC.Types.True
GHC.Prim.void#}

*Main.main* =
  closure (F:) (B: void.040) {
  Main.main1 GHC.Prim.void#}

Main.main3 =
  closure (F:) (B: void.040) {
  GHC.TopHandler.runMainIO1
Main.main1 GHC.Prim.void#}

*Main.main* =
  closure (F:) (B: void.040) {
  Main.main3 GHC.Prim.void#}
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Visible dependent quantification / CUSKs

[Richard Eisenberg]

Feared as much. I'd love for these to be implemented and was excited to see 
them listed!

I do expect to implement these some day. But certainly not for 8.8.

Thanks,
Richard

> On Nov 2, 2018, at 1:00 PM, Ben Gamari  wrote:
> 
> Richard Eisenberg  writes:
> 
>> Hi all,
>> 
>> I see visible dependent quantification and top-level kind signatures
>> on the release plan for GHC 8.8. Is there a diff for these I've
>> missed? Or is something in the works?
>> 
> I don't believe so; it sounds like this was just a mistake. If anyone
> was to know about these happening I would expect it to be you.
> 
> Cheers,
> 
> - Ben
> 

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

Re: Visible dependent quantification / CUSKs

[Ben Gamari]

Richard Eisenberg  writes:

> Hi all,
>
> I see visible dependent quantification and top-level kind signatures
> on the release plan for GHC 8.8. Is there a diff for these I've
> missed? Or is something in the works?
>
I don't believe so; it sounds like this was just a mistake. If anyone
was to know about these happening I would expect it to be you.

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: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Ben Gamari  writes:

> Herbert Valerio Riedel  writes:
>
...
>> I wonder too how this is represented in GitLab... especially when a MR
>> is comprised of multiple commits, and those individual commits evolve,
>> might get reordered, commits added or removed fromt he stack, or when
>> the whole MR gets rebased in the process...
>
> To be clear, GitLab saves each head commit that you push to an MR
> branch. These iterations are known in the review interface as "versions".
> The review interface then allows you to view differences between either
>
>  a. any two versions
>  b. any version and the target branch (e.g. master)
>
> Unfortunately (but perhaps not unexpectedly) this scheme does not deal
> well with changes due to a change in base commit (as would happen in the
> case of rebasing). It appears that GitLab must just run `git diff`
> between the two heads when asked to compare two versions of a MR.
>
It sounds as though this is something on upstream's radar as something
to improve upon in the near future [1].

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23269


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

Re: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Imants Cekusins  writes:

> Are other alternatives being considered?
>
I generally focused on GitHub and GitLab as these are the two options
that are widely used in the open-source community and received the most
attention in our survey results.

> You may find these examples relevant:
>
> TFS
> https://visualstudio.microsoft.com/tfs/   (Git repos is an option)
>
It seems the server requires a Windows machine to run. I consider this
to be an immediate dealbreaker.

> Atlassian
> https://www.atlassian.com/

I have worked with Atlassian products in the past and have not
found them to be convenient to use. Furthermore, neither of these
options are open source, which raises some serious lock-in concerns.

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: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Arian van Putten  writes:

> Once you rebase you simply move the branch pointer to a new chain of
> commits (they're rewritten because of the rebase, and thus have different
> hashes), however the old version of the branch still exists in the reflog.
> So locally you can definitely see your previous versions of your 'commit
> stack' by just pointing the branch pointer to the old commit hash or
> checking out that commit hash directly. However as far as I'm aware neither
> GitHub and gitlab expose this in their UI.
>
As pointed out earlier in the thread, GitLab does expose this in its UI [1]

Cheers,

- Ben


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/13570


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

Re: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Herbert Valerio Riedel  writes:

> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>
>> What about the wiki? Can we migrate that off Trac too?
>
> I worry that it's a lot of work to migrate it away while preserving the
> special markup and features that Trac provides; so the resulting pages
> will require a significant amount of manual cleanup and finding ways to
> emulate the previous features; for instance, I've been using features
> like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
> to highlight important information and footnote-like annotations in; and
> thus IMO help contribute to present the information less
> wall-of-text-ish which is harder to digest.
>
> [...]
>
>> I suppose we can do a squash-merge when committing to keep the history
>> clean, but then contributors have a choice - either do GitHub-style
>> where you add commits to a PR to update it and we squash on merge, OR
>> Phabricator-style where you keep the same set of commits and rebase
>> the stack to update it.
>
> (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
> they're called "MRs" for "merge-request", which is probably a more
> accurate term to describe the concept than "PR" is)
>
> Well, if MRs are to be squashed on merge anyway, I'm definitely not
> going to waste my time carefully grooming a stack of atomic individually
> validating commits via git-rebase-interactive...
>
>> If you want to do dependent commits then you have to use Phabricator
>> style. Choices between workflows make things more complicated for
>> contributors, and that worries me.
>
> ...submitting a stacked set of commits as invidual overlapping MRs
> (i.e. where the first MR has only the first commit, the 2nd has the
> first two commits from the stack, and so on) -- if that's what you're
> referring to as "Phabricator-style" -- sounds like an awkward workflow
> to me.
>
Right this is not the workflow I would advocate. Rather, just submit a
single MR with your atomic changes represented as commits. In fact, this
is already what I do locally when preparing stacked Phabricator
differentials (to put another way, one commit == one differential).

GitLab has good support for reviewing commit-by-commit.

>> Does GitLab keep the history of a PR after it has been updated, like in
>> Phabricator? So we can see what happened between versions of a PR?
>
> I wonder too how this is represented in GitLab... especially when a MR
> is comprised of multiple commits, and those individual commits evolve,
> might get reordered, commits added or removed fromt he stack, or when
> the whole MR gets rebased in the process...

To be clear, GitLab saves each head commit that you push to an MR
branch. These iterations are known in the review interface as "versions".
The review interface then allows you to view differences between either

 a. any two versions
 b. any version and the target branch (e.g. master)

Unfortunately (but perhaps not unexpectedly) this scheme does not deal
well with changes due to a change in base commit (as would happen in the
case of rebasing). It appears that GitLab must just run `git diff`
between the two heads when asked to compare two versions of a MR.

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: [GHC DevOps Group] The future of Phabricator

[Ben Gamari]

Simon Marlow  writes:

> What about the wiki? Can we migrate that off Trac too?
>
Yes, we certainly can. As Herbert mentioned, some of the fancier markup
in Trac will require a bit of manual grooming. However, the basic idea
is easily implemented with the migration that I already developed.

> We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
> links to tickets and wiki pages from elsewhere.
>
Yes, absolutely.

> If we really can do a stacked-diff-style workflow using PRs on GitLab then
> that at least for me removes one of the big drawbacks of moving. But how
> easy will it be to enforce that workflow and will it be going against the
> grain on GitLab? I imagine people used to adding extra commits to a PR will
> tend to do that rather than amending+rebasing. I suppose we can do a
> squash-merge when committing to keep the history clean, but then
> contributors have a choice - either do GitHub-style where you add commits
> to a PR to update it and we squash on merge, OR Phabricator-style where you
> keep the same set of commits and rebase the stack to update it. If you want
> to do dependent commits then you have to use Phabricator style. Choices
> between workflows make things more complicated for contributors, and that
> worries me.
>
This shouldn't be a problem. One can easily configure a project such
that users are *only* allowed to fast-forward/rebase, disallowing the
creation of merge commits.

> Does GitLab keep the history of a PR after it has been updated, like in
> Phabricator? So we can see what happened between versions of a PR?
>
Yes it does.

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: [GHC DevOps Group] The future of Phabricator

[Arian van Putten]

Once you rebase you simply move the branch pointer to a new chain of
commits (they're rewritten because of the rebase, and thus have different
hashes), however the old version of the branch still exists in the reflog.
So locally you can definitely see your previous versions of your 'commit
stack' by just pointing the branch pointer to the old commit hash or
checking out that commit hash directly. However as far as I'm aware neither
GitHub and gitlab expose this in their UI.

On Fri, Nov 2, 2018, 09:59 Herbert Valerio Riedel  On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>
> > What about the wiki? Can we migrate that off Trac too?
>
> I worry that it's a lot of work to migrate it away while preserving the
> special markup and features that Trac provides; so the resulting pages
> will require a significant amount of manual cleanup and finding ways to
> emulate the previous features; for instance, I've been using features
> like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
> to highlight important information and footnote-like annotations in; and
> thus IMO help contribute to present the information less
> wall-of-text-ish which is harder to digest.
>
> [...]
>
> > I suppose we can do a squash-merge when committing to keep the history
> > clean, but then contributors have a choice - either do GitHub-style
> > where you add commits to a PR to update it and we squash on merge, OR
> > Phabricator-style where you keep the same set of commits and rebase
> > the stack to update it.
>
> (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
> they're called "MRs" for "merge-request", which is probably a more
> accurate term to describe the concept than "PR" is)
>
> Well, if MRs are to be squashed on merge anyway, I'm definitely not
> going to waste my time carefully grooming a stack of atomic individually
> validating commits via git-rebase-interactive...
>
> > If you want to do dependent commits then you have to use Phabricator
> > style. Choices between workflows make things more complicated for
> > contributors, and that worries me.
>
> ...submitting a stacked set of commits as invidual overlapping MRs
> (i.e. where the first MR has only the first commit, the 2nd has the
> first two commits from the stack, and so on) -- if that's what you're
> referring to as "Phabricator-style" -- sounds like an awkward workflow
> to me.
>
> > Does GitLab keep the history of a PR after it has been updated, like in
> > Phabricator? So we can see what happened between versions of a PR?
>
> I wonder too how this is represented in GitLab... especially when a MR
> is comprised of multiple commits, and those individual commits evolve,
> might get reordered, commits added or removed fromt he stack, or when
> the whole MR gets rebased in the process...
> ___
> 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: [GHC DevOps Group] The future of Phabricator

[Herbert Valerio Riedel]

On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:

> What about the wiki? Can we migrate that off Trac too?

I worry that it's a lot of work to migrate it away while preserving the
special markup and features that Trac provides; so the resulting pages
will require a significant amount of manual cleanup and finding ways to
emulate the previous features; for instance, I've been using features
like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
to highlight important information and footnote-like annotations in; and
thus IMO help contribute to present the information less
wall-of-text-ish which is harder to digest.

[...]

> I suppose we can do a squash-merge when committing to keep the history
> clean, but then contributors have a choice - either do GitHub-style
> where you add commits to a PR to update it and we squash on merge, OR
> Phabricator-style where you keep the same set of commits and rebase
> the stack to update it.

(Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
they're called "MRs" for "merge-request", which is probably a more
accurate term to describe the concept than "PR" is)

Well, if MRs are to be squashed on merge anyway, I'm definitely not
going to waste my time carefully grooming a stack of atomic individually
validating commits via git-rebase-interactive...

> If you want to do dependent commits then you have to use Phabricator
> style. Choices between workflows make things more complicated for
> contributors, and that worries me.

...submitting a stacked set of commits as invidual overlapping MRs
(i.e. where the first MR has only the first commit, the 2nd has the
first two commits from the stack, and so on) -- if that's what you're
referring to as "Phabricator-style" -- sounds like an awkward workflow
to me.

> Does GitLab keep the history of a PR after it has been updated, like in
> Phabricator? So we can see what happened between versions of a PR?

I wonder too how this is represented in GitLab... especially when a MR
is comprised of multiple commits, and those individual commits evolve,
might get reordered, commits added or removed fromt he stack, or when
the whole MR gets rebased in the process...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Imants Cekusins]

Are other alternatives being considered?

You may find these examples relevant:

TFS
https://visualstudio.microsoft.com/tfs/   (Git repos is an option)

Atlassian
https://www.atlassian.com/
Atlassian offers rich set of integrated products.
https://www.atlassian.com/software/views/open-source-license-request
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] The future of Phabricator

[Simon Marlow]

What about the wiki? Can we migrate that off Trac too?

We'd have to keep redirects in place on ghc.haskell.org to avoid breaking
links to tickets and wiki pages from elsewhere.

If we really can do a stacked-diff-style workflow using PRs on GitLab then
that at least for me removes one of the big drawbacks of moving. But how
easy will it be to enforce that workflow and will it be going against the
grain on GitLab? I imagine people used to adding extra commits to a PR will
tend to do that rather than amending+rebasing. I suppose we can do a
squash-merge when committing to keep the history clean, but then
contributors have a choice - either do GitHub-style where you add commits
to a PR to update it and we squash on merge, OR Phabricator-style where you
keep the same set of commits and rebase the stack to update it. If you want
to do dependent commits then you have to use Phabricator style. Choices
between workflows make things more complicated for contributors, and that
worries me.

Does GitLab keep the history of a PR after it has been updated, like in
Phabricator? So we can see what happened between versions of a PR?

Cheers
Simon

On Tue, 30 Oct 2018 at 19:22, Ben Gamari  wrote:

> Simon Marlow  writes:
>
> > I'm entirely happy to move, provided (1) whatever we move to provides the
> > functionality we need, and (2) it's clearly what the community wants
> > (considering both current and future contributors). In the past when
> moving
> > to GitHub was brought up, there were a handful of core contributors who
> > argued strongly in favour of Phabricator, do we think that's changed? Do
> we
> > have any indication of whether the survey respondents who were
> > anti-Phabricator would be pro- or anti-GitLab?
> >
> The comments fell into several buckets:
>
>  a. Those who spoke in favor of GitHub in particular
>  b. Those who spoke in favor of GitHub and GitLab
>  c. Those who spoke against Phabricator
>
> I seem to recall that (a) was the largest group. No one explicitly
> stated that they would be against GitLab, although this is not terribly
> surprising given we didn't ask.
>
> Frankly I doubt there would be people who would actively support GitHub
> but not GitLab given how similar the workflows are. However, collecting
> data for this hunch is one of the reasons for this thread.
>
> > Personally I'd like to optimise for more code review, because I think
> that
> > more than anything else will increase quality and community ownership of
> > the project. If using new tooling will make code review a more central
> part
> > of our workflow, then that would be a good thing.
>
> Agreed, currently we have too few reviewers for the volume of code we
> are pushing into the tree.
>
> > Right now I think we're
> > very Trac-centric, and the integration between Trac and Phabricator isn't
> > great; if we could move to a solution with tighter integration between
> > tickets/code-review/wiki, that would be an improvement in my view. But
> not
> > GitHub, for the reasons you gave.
> >
> Yes, I agree. Currently I spend too much time keeping tickets in sync and
> this is almost entirely wasted time.
>
>
> > Would GitLab solve the CI issues? I don't think you mentioned that
> > explicitly.
> >
> It helps, yes. As Andres pointed out, Appveyor has native support for
> GitLab, which we use for Windows validation. Furthermore, GitLab's
> native CI would allow us to test non-x86 platforms.
>
> CircleCI lacks GitLab support however I believe the integration we have
> already developed to support integration with Phabricator could be
> easily adapted for GitLab.
>
> Moreover, given that the "Add GitLab support" request is at the top of
> CircleCI's feature request tracker, it seems likely that there will be
> native support in the future.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs