Re: multiple top level Main.main binders in STG

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

Re: multiple top level Main.main binders in STG

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

Re: multiple top level Main.main binders in STG

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

multiple top level Main.main binders in STG

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

Re: Visible dependent quantification / CUSKs

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

Re: Visible dependent quantification / CUSKs

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

Re: [GHC DevOps Group] The future of Phabricator

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

Re: [GHC DevOps Group] The future of Phabricator

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 >

Re: [GHC DevOps Group] The future of Phabricator

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

Re: [GHC DevOps Group] The future of Phabricator

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 >

Re: [GHC DevOps Group] The future of Phabricator

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. >

Re: [GHC DevOps Group] The future of Phabricator

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'

Re: [GHC DevOps Group] The future of Phabricator

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

Re: [GHC DevOps Group] The future of Phabricator

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.

Re: [GHC DevOps Group] The future of Phabricator

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