As a result of this thread I have created Phab Diff [1]. It contains
required fixes in compiler and ghc-transformers-instance package.
I have tested result on 2 following usecases:
1. I have installed in a sandox transformers-0.3 and ghc-heap-view
that uses them and ghc-lib. (Doesn't require
Don't worry about the merge commit.
On Jan 22, 2015 11:57 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
BOTHER!
I have no idea how my commit, which was meant to change two all.T files,
also ended up adding libraries/haskell98.
I'll revert and re-commit.
I also inadvertently did 'git
The current situation is that DPH is not being built or maintained at
all. Given this state of affairs, it is hard to justify keeping it
around---DPH is just bitrotting.
I am proposing that we reconnect it to the build and keep it building,
putting it in minimal maintenance mode. This will at
On 22 January 2015 at 09:34, Joachim Breitner m...@joachim-breitner.de wrote:
Hi,
Am Donnerstag, den 22.01.2015, 08:37 +0100 schrieb Herbert Valerio
Riedel:
One thing to keep in mind though is that then 'haskeline' (which is
needed by GHCi) still remains a consumer of 'transformers', so we'd
I'm getting these validate failures from sh validate -fast:
Unexpected failures:
../../libraries/directory/tests getHomeDirectory001 [exit code non-0]
(normal)
.. and about 20 more similar complaints ...
The failure report is this:
Compile failed (status 256) errors were:
[1 of 1]
The issue that Richard Eisenberg raised is not
DPH doesn't compile (which Geoff might fix)
but rather
no one is working on DPH, but having it all in the tree
imposes a small cost on a large number of people
(build/validate cycle time, grep hits, etc)
So re-adding the DPH library would
On 22 January 2015 at 10:37, Herbert Valerio Riedel hvrie...@gmail.com wrote:
On 2015-01-21 at 17:19:42 +0100, Alexander V Vershilov wrote:
I thought about providing package ghc-transformers-instances, that will
provide instances for transformers's type classes for user. So
ghc-tf-instances
Hi,
Am Donnerstag, den 22.01.2015, 08:37 +0100 schrieb Herbert Valerio
Riedel:
One thing to keep in mind though is that then 'haskeline' (which is
needed by GHCi) still remains a consumer of 'transformers', so we'd
still have to bundle a 'transformers' package version with GHC even if
`ghc`
On 21/01/15 21:51, Simon Marlow wrote:
Adam, do you have any measurements for how much code gets generated for
a record declaration with ORF, compared with a record declaration in GHC
right now? That's one thing that has been a nagging worry for me with
ORF, but I just don't have any idea if
On 22/01/15 05:38, Edward Kmett wrote:
On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry wrote:
I'm surprised and interested that you view this as a major source of
complexity. From my point of view, I quite liked how the ability to
overload fields as both selector functions and
Would it be possible to turn vectorisation into a compiler plugin? This would
kill two birds with
one stone: vectorisation would be removed from GHC sources and at the same time
the code could be
maintained by Geoffrey or anyone else who would want to take it up. I'm not
sure what would
I think there is significant infrastructure in the parser, not sure how
that could be managed via a plugin.
Alan
On Thu, Jan 22, 2015 at 10:55 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
Would it be possible to turn vectorisation into a compiler plugin? This
would kill two birds with
one
| One thing to keep in mind though is that then 'haskeline' (which is
| needed by GHCi) still remains a consumer of 'transformers', so we'd
| still have to bundle a 'transformers' package version with GHC even if
| `ghc` doesn't depend on it anymore. Somewhat related, the `ghc` -
couldn't we
BOTHER!
I have no idea how my commit, which was meant to change two all.T files, also
ended up adding libraries/haskell98.
I'll revert and re-commit.
I also inadvertently did 'git pull' rather than 'git pull --rebase' so there's
a merge node too. But I don't know how to undo that, and
On 2015-01-22 at 12:40:05 +0100, Boespflug, Mathieu wrote:
[...]
It sounds to me like Alexander's patch, plus the
solution alluded by Joachim above for invisible packages that don't
clash with ones registered in the ghc-pkg db, would allow us to avoid
having any of the following packages
On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote:
On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote:
The current situation is that DPH is not being built or maintained at
all. Given this state of affairs, it is hard to justify keeping it
around---DPH is just bitrotting.
I am
On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:
On 21/01/2015 16:01, Johan Tibell wrote:
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
Backwards compatible in what sense? Extension flags provide backwards
On Jan 22, 2015 8:12 PM, Johan Tibell johan.tib...@gmail.com wrote:
On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:
On 21/01/2015 16:01, Johan Tibell wrote:
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
The best way to move beyond the somewhat dated version of the Haskell
Platform that is distributed with Fedora 21 is to install the version
available at http://www.haskell.org/platform instead of the version
installed by yum. This fixes all of the shared library issues that
arise when installing
On Thu, Jan 22, 2015 at 4:31 AM, Adam Gundry a...@well-typed.com wrote:
Actually, the simplifications I recently came up with could allow us to
make uses of the field work as van Laarhoven lenses, other lenses *and*
selector functions. In practice, however, I suspect this might lead to
Hello,
last night build on i386-freebsd, i386/amd64-solaris and smartos-x86
failed with problem on configuring haddock:
inplace/bin/ghc-cabal check utils/haddock
'ghc-options: -O2' is rarely needed. Check that it is giving a real
benefit and not just imposing longer compile times on your
21 matches
Mail list logo
