Re: Tooling-friendly ModSummary

[Edward Z. Yang]

Hello Alan,

SPJ and I both think that GhcMake is well overdue for a rewrite.
But it's not altogether obvious what the rewrite should look like.
I've made some remarks here: 
https://gist.github.com/ezyang/50004e0f842eec5848acad5cf1c22240

I'm OK with small, incremental changes that make tooling's life better.
But adding renamed/typechecked ASTs is almost certainly the wrong
thing to do.  The ModSummary is produced by looking at an hs file
and doing the bare minimum processing to get the import graph.

The way the pipeline works is a ModSummary is eventually turned into a
HomeModInfo by the typechecking process. So one possibility is that
if it is requested (retaining renamed, typechecked ASTs increases
memory consumption for clients that don't need it) the things you want
could be stashed in HomeModInfo.  So you'd probably augment
FrontendResult to return the information you need, and then
hscIncrementalCompile to stick it in HomeModInfo.

Things to be careful about:

- You will NOT get this info if you load the HomeModInfo from
  disk rather than compile it directly.  I am assuming that you
  have a way to convince 'load' to rebuild; I don't actually
  know how to do this.

- We don't want to save this info by default; it will increase
  memory usage for anyone who doesn't need it (e.g., ghc --make)

Hope that helps,
Edward

Excerpts from Alan & Kim Zimmerman's message of 2016-09-05 20:27:26 +0200:
> At the moment the standard way to use the GHC API is something like
> 
> _ <- load LoadAllTargets
> modSum <- getModSummary mn
> p <- parseModule modSum
> 
> And likewise if renamed or typechecked ASTs are needed.
> 
> But the `load` step already does all those phases.
> 
> So, would there be any objection to modifying the ModSummary to possibly
> retain those artifacts, configurable via a DynFlag?
> 
> I would expect the flag would default to retaining none, but could then
> either provide for returning all artifacts, or just for the targets
> explicitly listed in the `setTargets` call (i.e. not the full `depanal`
> result).
> 
> Regards
>   Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: cabal

[Simon Peyton Jones via ghc-devs]

Thanks Brandon.  But I think Ben was probably right; I need cabal install 
cabal-install.  Somehow this ought to be easier.

I’ll try that when I next get a chance

SImion

From: Brandon Allbery [mailto:allber...@gmail.com]
Sent: 05 September 2016 17:50
To: Simon Peyton Jones 
Cc: GHC developers 
Subject: Re: cabal


On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs 
> wrote:

bash$ which cabal

/home/simonpj/.cabal/bin/cabal
Maybe I need 1.24.  Which claims to be installed.  But WHERE is it installed?

Try "type cabal". "which" has a nasty tendency to show you what the next shell 
you open (or sometimes the next time you login) will see; shells remember what 
they've already seen, so it's probably still running the old one (likely in 
/usr/bin or /usr/local/bin). POSIX requires "type" to show what the *current* 
shell (thinks it) knows, not what some future shell will see.

"hash -r" should work to reset the shell's idea of where cabal is, if "type" 
says it's running a different cabal.

--
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com 
 ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Tooling-friendly ModSummary

[Alan & Kim Zimmerman]

At the moment the standard way to use the GHC API is something like

_ <- load LoadAllTargets
modSum <- getModSummary mn
p <- parseModule modSum

And likewise if renamed or typechecked ASTs are needed.

But the `load` step already does all those phases.

So, would there be any objection to modifying the ModSummary to possibly
retain those artifacts, configurable via a DynFlag?

I would expect the flag would default to retaining none, but could then
either provide for returning all artifacts, or just for the targets
explicitly listed in the `setTargets` call (i.e. not the full `depanal`
result).

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

Re: cabal

[Brandon Allbery]

On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> bash$ which cabal
>
> /home/simonpj/.cabal/bin/cabal
>
> Maybe I need 1.24.  Which claims to be installed.  But WHERE is it
> installed?
>
>
Try "type cabal". "which" has a nasty tendency to show you what the next
shell you open (or sometimes the next time you login) will see; shells
remember what they've already seen, so it's probably still running the old
one (likely in /usr/bin or /usr/local/bin). POSIX requires "type" to show
what the *current* shell (thinks it) knows, not what some future shell will
see.

"hash -r" should work to reset the shell's idea of where cabal is, if
"type" says it's running a different cabal.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

cabal

[Simon Peyton Jones via ghc-devs]

I’m trying to follow the instructions for
https://ghc.haskell.org/trac/ghc/ticket/12562
But I get

cabal new-build llvm-general 
--with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2

cabal: unrecognised command: new-build (try --help)

simonpj@cam-05-unx:~/tmp/llvm-general$
Maybe my Cabal is too old.  I tried

bash$ cabal install Cabal

Resolving dependencies...

Downloading Cabal-1.24.0.0...

Configuring Cabal-1.24.0.0...

Building Cabal-1.24.0.0...

Installed Cabal-1.24.0.0
That worked.  But I get the same message.   Alas

bash$ cabal --version

cabal-install version 1.23.0.0

compiled using version 1.23.1.0 of the Cabal library

bash$ which cabal

/home/simonpj/.cabal/bin/cabal
Maybe I need 1.24.  Which claims to be installed.  But WHERE is it installed?

Thanks

Simon

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

Call for Nominations: GHC Steering Committee

[Ben Gamari]

Hello everyone,

As you likely know, over the last few months we have been discussing
options for reforming the process for proposing language and
compiler changes to GHC. After much discussion, we have a process [1]
which, while not perfect, is acceptable to a majority of our contributor
base and will be an improvement over the status quo. While we invite
suggestions for future improvements, we are at a point where we can move
ahead with implementation.

Consequently, we are seeking nominations for the initial GHC steering
committee. This body is responsible for overseeing the progression of
proposals through the process, working with authors on refining their
ideas, and evaluating proposals for acceptance. The committee will
consist of five to eight members of diverse backgrounds.

We would like to offer the following as a criteria for membership. Note
that a candidate is not expected to satisfy all or even most of these
criteria, but a good candidate should satisfy at least one:

* A history of contributions to the design of new language features

* Experience developing Haskell libraries and applications

* A demonstrated track record of contributing code to GHC

* A pedagogical background, with experience in either teaching or
  authoring educational materials

* Experience in compiler development

* Knowledge of functional programming language theory

I'd like to emphasize that committee membership is as much a duty as it
is a privilege. Membership is not intended to be a platform to be used
by members to drive their own ideas; rather it is a way of serving the
Haskell community by helping other community members refine and advance
their proposals. This, of course, requires an investment of
time and effort, which you should be willing and able to consistently
put forth.

If you'd like to be considered for committee membership then please
write a statement describing why you feel you are well-qualified to
serve, in terms of the criteria above and any others that you would like
to offer. Please send your statements to b...@well-typed.com by September
30th. The initial committee selection will be made by the Simons soon
thereafter.

Thanks to everyone for their feedback and cooperation so far!

Cheers,

- Ben


[1] http://github.com/ghc-proposals/ghc-proposals


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