Thanks. Some quick questions
1. What's the difference between ghc.haskell.org and git.haskell.org?
2. Is there anything to choose between these two?
./sync-all -r git://git.haskell.org remote set-url origin
./sync-all -rhttp://git.haskell.org remote set-url origin
3. The
The more I think about this, the more I wonder if we shouldn't treat NT in a
similar way that we treat (~); that is, with built-in rules. The point is, we
use
(a) roles, and
(b) visibility of the data constructor
to control abstraction via existence/visibility of the instance. We don't
Good morning,
Am Dienstag, den 20.08.2013, 07:24 + schrieb Simon Peyton-Jones:
The more I think about this, the more I wonder if we shouldn't treat
NT in a similar way that we treat (~); that is, with built-in rules.
The point is, we use
(a) roles, and
(b) visibility of the data
| However, in order to facilitate future migrations, git.haskell.org
| should be used, as then we could relocate git.haskell.org to a different
| IP without needing to update the URLs in all documents again.
Why? If we only had ghc.haskell.org, we could just migrate that couldn't we?
Or are
Hi,
Am Dienstag, den 20.08.2013, 07:43 + schrieb Simon Peyton-Jones:
| Questions:
| * Will this annotation have other, possibly unwanted effects?
The role annotation will have exactly the *right* effect;
great.
| * Should we also simplify constraints like (NT Age a) to (NT Int a)
|
On 2013-08-20 at 09:48:48 +0200, Simon Peyton-Jones wrote:
| However, in order to facilitate future migrations, git.haskell.org
| should be used, as then we could relocate git.haskell.org to a different
| IP without needing to update the URLs in all documents again.
Why? If we only had
Right now we have a git hook that prevents pushing a file containing tabs,
unless that file had them already (in other words: no new files with tabs in
our repos). I propose to add similar hook for trailing whitespaces. Herbert
says he can implement that. What do others think? Would you find
Would be nice to have. How about a third hook that disallows commits
that include whitespace-only changes unless *all* changes are
whitespace-only? ;)
Geoff
On 08/20/2013 10:59 AM, Jan Stolarek wrote:
Right now we have a git hook that prevents pushing a file containing tabs,
unless that file
On 2013-08-20 at 13:21:02 +0200, Geoffrey Mainland wrote:
How about a third hook that disallows commits that include
whitespace-only changes unless *all* changes are whitespace-only? ;)
The other two validations were about preserving an invariant (file has
no tabs file has no trailing
All,
GHC 7.8's release is drawing near. We would like to make a release
candidate sometime around ICFP, which will be in late September.
Unfortunately that's just over a month a way, so the clock is ticking!
The tree will need a few weeks of stabilization. After that, we will
release an RC, and
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
S
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin Seipp
Sent: 20 August 2013 18:01
To: ghc-devs@haskell.org
Subject: 7.8 Feature window
All,
GHC 7.8's release is drawing near.
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
Feature I was working on has been merged into HEAD. Should I remove it from the
list?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
Yes - but leavae it to me. I'll do some cleanup since some of Richard's
work was also merged.
On Tue, Aug 20, 2013 at 12:14 PM, Jan Stolarek jan.stola...@p.lodz.plwrote:
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
Feature I was working on
Hello,
For the constraint solver for type naturals: I think we should certainly
have some form of it in 7.8, even if it is the really simple version that
just knows things like: 5 + 3 = 8.There is a bit of work to be done to
catch up the type-nats branch to HEAD, mainly to do with Richard's
On Aug 21, 2013 1:05 AM, Austin Seipp ase...@pobox.com wrote:
* ERDI was working on pattern synonyms. I believe you were having some
trouble with the implementation. Can someone help him if necessary?
Hi,
I've updated the Trac ticket with the latest status of my work. There are
only two loose
hi all,
Sorry for taking so long to get back with this. I'm proposing a somewhat
general way for adding 'hooks' to the GHC API, where users can override
parts of the default compiling pipeline.
Hooks are simply functions or actions that replace existing compiler
functionality. This means that
16 matches
Mail list logo
