From juhp at community.haskell.org  Mon Feb  3 03:13:18 2014
From: juhp at community.haskell.org (Jens Petersen)
Date: Mon, 3 Feb 2014 12:13:18 +0900
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
Message-ID: <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>

+1 for Carter's proposal - I had actually been planning to make the same
suggestion, but just saw this thread now...

On 27 January 2014 09:39, Austin Seipp <austin at well-typed.com> wrote:

> As for shipping with GHC itself: this is technically possible, but
> slightly annoying to implement, and it also makes the build processes
> for a release slightly more annoying (which is mostly my problem.) But
> it is all doable. However, keep in mind I *do not* maintain the binary
> distributions for everything, nor do Cabal devs have access to all
> hardware - so all people making upstream releases for their platforms
> (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal
> themselves. But perhaps that's not a huge deal.
>

If ghc provided cabal-install I would be happy to ship that in Fedora
instead of a separate package.  To me cabal-install is probably the most
important tool/package in HP (except for ghc itself of course): many people
build/bootstrap latest ghc themselves it seems and so providing
the latest cabal-install out of the box too would be a big win IMO,
making it much easier to test ghc.  (I wouldn't even mind if ghc
shipped cabal-install's dependencies too.)

Jens

ps Of course it could be made a configure option whether to build
cabal-install or now: the cabal-install source is already there. ;) :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/c4db9e6c/attachment.html>

From petersen at fedoraproject.org  Mon Feb  3 10:49:19 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Mon, 3 Feb 2014 19:49:19 +0900
Subject: test build of current ghc-7.8
Message-ID: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>

Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
devel,
which I think should also install to Fedora 20.

I put the packages for x86_64, i386 and armv7hl into the yum repos under
http://repos.fedorapeople.org/repos/petersen/ghc-7.7/

I haven't tested this latest build yet but wanted to announce its
availability.
Let me know if you hit any packaging problems with it.

Jens

ps I also upload the ghc-7.8.0.20140201 src tarball to
http://petersen.fedorapeople.org/ghc/ if you want to use
to build yourself.

pps Next time I will build it in copr.fedoraproject.org
which creates yum repos for one (like OBS).

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6483032
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/445ae420/attachment.html>

From mail at joachim-breitner.de  Mon Feb  3 12:06:48 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 03 Feb 2014 12:06:48 +0000
Subject: test build of current ghc-7.8
In-Reply-To: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>
References: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>
Message-ID: <1391429208.3196.8.camel@kirk>

Dear Jens,


Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
> devel, 
> which I think should also install to Fedora 20.

I?m surprised that it worked for you. Did not you not hit
http://ghc.haskell.org/trac/ghc/ticket/8725?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/d081b96e/attachment.sig>

From austin at well-typed.com  Mon Feb  3 22:35:14 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 3 Feb 2014 16:35:14 -0600
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Message-ID: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>

We are pleased to announce the first release candidate for GHC 7.8.1:

    http://www.haskell.org/ghc/dist/7.8.1-rc1/
    http://www.haskell.org/ghc/docs/7.8.1-rc1/html/

This includes the source tarball and bindists for Windows, Linux, OS
X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
the SHA256 hashes available (attached) using my GPG key (keyid
0x3B58D86F).

We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
some existing issues.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SHA256SUMS
Type: application/octet-stream
Size: 1329 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/bd524ee4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SHA256SUMS.sig
Type: application/octet-stream
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/bd524ee4/attachment-0001.obj>

From george.colpitts at gmail.com  Tue Feb  4 00:34:37 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 3 Feb 2014 20:34:37 -0400
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <CAB-d4A7Q2CpFqB5dyk7comAYnZYJQvAbyShZd4nufO5Etf8s8A@mail.gmail.com>

wrt existing issues, is there a list of these so we can avoid reporting
them?

Thanks
George



On Mon, Feb 3, 2014 at 6:35 PM, Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the first release candidate for GHC 7.8.1:
>
>     http://www.haskell.org/ghc/dist/7.8.1-rc1/
>     http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> the SHA256 hashes available (attached) using my GPG key (keyid
> 0x3B58D86F).
>
> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> some existing issues.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140203/df2a2d06/attachment.html>

From juhp at community.haskell.org  Tue Feb  4 00:52:17 2014
From: juhp at community.haskell.org (Jens Petersen)
Date: Tue, 4 Feb 2014 09:52:17 +0900
Subject: test build of current ghc-7.8
In-Reply-To: <1391429208.3196.8.camel@kirk>
References: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>
 <1391429208.3196.8.camel@kirk>
Message-ID: <CAEDGBqK=gdihGVaKBeA_Jyy-L=F3xN-OSn6dkea4EL_Jj7wYKw@mail.gmail.com>

Hi Joachim,


> Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> > Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
> > devel, which I think should also install to Fedora 20.
>
> I?m surprised that it worked for you. Did not you not hit
> http://ghc.haskell.org/trac/ghc/ticket/8725?
>

Does that also affect 7.8?  I see the report is for a 7.9 snapshot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140204/2b3b879c/attachment.html>

From ganesh at earth.li  Tue Feb  4 06:38:30 2014
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Tue, 04 Feb 2014 06:38:30 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <52F08AE6.3070506@earth.li>

Just to note a problem I encountered on Windows, which may well be user
error.

I unpacked the mingw tarball and added the bin directory from it to my
path. cabal install then failed with "cabal.exe: does not exist" after
producing some other output.

Running with -v3 suggested that the actual problem was that the ld on my
path couldn't read the .o files produced by GHC. I changed my path to
also include the mingw\bin directory from the tarball, and then all was
fine.


On 03/02/2014 22:35, Austin Seipp wrote:
> We are pleased to announce the first release candidate for GHC 7.8.1:
> 
>     http://www.haskell.org/ghc/dist/7.8.1-rc1/
>     http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
> 
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> the SHA256 hashes available (attached) using my GPG key (keyid
> 0x3B58D86F).
> 
> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> some existing issues.
> 
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
> 
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


From hvr at gnu.org  Tue Feb  4 07:40:44 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 04 Feb 2014 08:40:44 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 (Austin Seipp's message of "Mon, 3 Feb 2014 16:35:14 -0600")
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <87wqhbiav7.fsf@gnu.org>

On 2014-02-03 at 23:35:14 +0100, Austin Seipp wrote:
> We are pleased to announce the first release candidate for GHC 7.8.1:

[...]

> Please test as much as possible; bugs are much cheaper if we find them
> before the release!

Please note that GHC 7.8.1RC1 is also available for Travis-CI as part of
the multiple-ghc-versions repository[1].  So you can start continuously
testing your Haskell projects hosted at GitHub with GHC 7.8.1RC1 with
little effort.

Greetings,
  hvr

 [1]: https://github.com/hvr/multi-ghc-travis 

From mail at joachim-breitner.de  Tue Feb  4 09:03:28 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Feb 2014 09:03:28 +0000
Subject: test build of current ghc-7.8
In-Reply-To: <CAEDGBqK=gdihGVaKBeA_Jyy-L=F3xN-OSn6dkea4EL_Jj7wYKw@mail.gmail.com>
References: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>
 <1391429208.3196.8.camel@kirk>
 <CAEDGBqK=gdihGVaKBeA_Jyy-L=F3xN-OSn6dkea4EL_Jj7wYKw@mail.gmail.com>
Message-ID: <1391504608.2719.1.camel@kirk>

Hi,

Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen:

>         Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
>         > Hi, I did a test build [1] of the current ghc-7.8 branch for
>         Fedora 21
>         > devel, which I think should also install to Fedora 20.
>         
>         
>         I?m surprised that it worked for you. Did not you not hit
>         http://ghc.haskell.org/trac/ghc/ticket/8725?
> 
> 
> Does that also affect 7.8?  I see the report is for a 7.9 snapshot. 

yes, 7.9 and 7.8 are not so different yet. But I think I?ll resolve this
by making the Debian directory structure a bit more standard; much
easier than hacking the build system.

I?ll make sure it works and then close the bug.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140204/c02358ca/attachment.sig>

From barney_stratford at fastmail.fm  Tue Feb  4 13:15:37 2014
From: barney_stratford at fastmail.fm (Barney Stratford)
Date: Tue, 4 Feb 2014 13:15:37 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <mailman.13.1391515203.30932.glasgow-haskell-users@haskell.org>
References: <mailman.13.1391515203.30932.glasgow-haskell-users@haskell.org>
Message-ID: <B98FF0A7-4387-43D0-B58E-28F0AD4FA13C@fastmail.fm>

I've been attempting to build under Mac OS X Mavericks and have run into some problems. My iconv and gmp are installed in non-standard locations using Fink. When configuring http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-x86_64-apple-darwin-mavericks.tar.bz2 I get:

barneys-imac:ghc-7.8.20140130 bjs$ ./configure --prefix=/Users/bjs/Desktop/ghc --with-iconv-includes=/sw/include --with-gmp-includes=/sw/include --with-iconv-libraries=/sw/lib --with-gmp-libraries=/sw/lib
configure: WARNING: unrecognized options: --with-iconv-includes, --with-iconv-libraries

and then the installed executable can't itself build ghc from source because of the missing iconv libraries. I noticed that ./configure --help doesn't mention --with-iconv-* in the Mavericks install files but it does in the source build.

Any ideas?

Cheers,
Barney.

From mikesteele81 at gmail.com  Tue Feb  4 21:52:26 2014
From: mikesteele81 at gmail.com (Michael Steele)
Date: Tue, 4 Feb 2014 13:52:26 -0800
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F08AE6.3070506@earth.li>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F08AE6.3070506@earth.li>
Message-ID: <CAAFFR7CF9C4=SruO=XNQx6C9fsiYEoCbrZmQ4ELrXE4=RudODQ@mail.gmail.com>

I also ran into a problem on Windows.

c:\>cabal install safe
Resolving dependencies...
Configuring safe-0.3.4...
Building safe-0.3.4...
Preprocessing library safe-0.3.4...
[1 of 2] Compiling Safe.Foldable    ( Safe\Foldable.hs,
dist\build\Safe\Foldable.o )
Can't open perl script "C:\ghc-7.8\lib\ghc-split": No such file or directory
Failed to install safe-0.3.4
cabal: Error: some packages failed to install:
safe-0.3.4 failed during the building phase. The exception was:
ExitFailure 2

Copying "ghc-split" from the Haskell Platform into c:\ghc-7.8\lib seems to
work around the problem.

c:\>cabal install safe
Resolving dependencies...
Configuring safe-0.3.4...
Building safe-0.3.4...
Preprocessing library safe-0.3.4...
[1 of 2] Compiling Safe.Foldable    ( Safe\Foldable.hs,
dist\build\Safe\Foldable.o )
[2 of 2] Compiling Safe             ( Safe.hs, dist\build\Safe.o )
In-place registering safe-0.3.4...
Installing library in
C:\Users\Mike\AppData\Roaming\cabal\safe-0.3.4\ghc-7.8.20140130
Registering safe-0.3.4...
Installed safe-0.3.4

c:\>ghci
GHCi, version 7.8.20140130: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Safe
Prelude Safe> readMay "1" :: Maybe Int
Loading package safe-0.3.4 ... linking ... done.
Just 1
Prelude Safe> :quit
Leaving GHCi.


On Mon, Feb 3, 2014 at 10:38 PM, Ganesh Sittampalam <ganesh at earth.li> wrote:

> Just to note a problem I encountered on Windows, which may well be user
> error.
>
> I unpacked the mingw tarball and added the bin directory from it to my
> path. cabal install then failed with "cabal.exe: does not exist" after
> producing some other output.
>
> Running with -v3 suggested that the actual problem was that the ld on my
> path couldn't read the .o files produced by GHC. I changed my path to
> also include the mingw\bin directory from the tarball, and then all was
> fine.
>
>
> On 03/02/2014 22:35, Austin Seipp wrote:
> > We are pleased to announce the first release candidate for GHC 7.8.1:
> >
> >     http://www.haskell.org/ghc/dist/7.8.1-rc1/
> >     http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
> >
> > This includes the source tarball and bindists for Windows, Linux, OS
> > X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> > the SHA256 hashes available (attached) using my GPG key (keyid
> > 0x3B58D86F).
> >
> > We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> > some existing issues.
> >
> > Please test as much as possible; bugs are much cheaper if we find them
> > before the release!
> >
> >
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
-- Michael Steele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140204/37701ce0/attachment.html>

From mail at joachim-breitner.de  Tue Feb  4 23:35:56 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Feb 2014 23:35:56 +0000
Subject: test build of current ghc-7.8
In-Reply-To: <1391504608.2719.1.camel@kirk>
References: <CAEDGBqJzm7G5za9A=kqCz2TafYLAWZc7FGJ25cXc890QA7cnRQ@mail.gmail.com>
 <1391429208.3196.8.camel@kirk>
 <CAEDGBqK=gdihGVaKBeA_Jyy-L=F3xN-OSn6dkea4EL_Jj7wYKw@mail.gmail.com>
 <1391504608.2719.1.camel@kirk>
Message-ID: <1391556956.2719.47.camel@kirk>

Hi,

Am Dienstag, den 04.02.2014, 09:03 +0000 schrieb Joachim Breitner:
> Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen:
> 
> >         Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> >         > Hi, I did a test build [1] of the current ghc-7.8 branch for
> >         Fedora 21
> >         > devel, which I think should also install to Fedora 20.
> >         
> >         
> >         I?m surprised that it worked for you. Did not you not hit
> >         http://ghc.haskell.org/trac/ghc/ticket/8725?
> > 
> > 
> > Does that also affect 7.8?  I see the report is for a 7.9 snapshot. 
> 
> yes, 7.9 and 7.8 are not so different yet. But I think I?ll resolve this
> by making the Debian directory structure a bit more standard; much
> easier than hacking the build system.

different issue: It seems that "hpc" is build dynamically, but installed
to the binpath (/usr/bin) instead of ghclibdir (/usr/lib/ghc/bin), so
the linking against the haskell library via rpath does not work. I had
to apply

$ cat patches/hpc-wrapper 
Index: ghc-7.9.20140130/utils/hpc/ghc.mk
===================================================================
--- ghc-7.9.20140130.orig/utils/hpc/ghc.mk	2014-01-31 17:28:32.000000000 +0000
+++ ghc-7.9.20140130/utils/hpc/ghc.mk	2014-02-04 23:15:53.000000000 +0000
@@ -15,4 +15,7 @@
 utils/hpc_dist-install_INSTALL         = YES
 utils/hpc_dist-install_INSTALL_INPLACE = YES
 utils/hpc_dist-install_PROGNAME        = hpc
+utils/hpc_dist-install_SHELL_WRAPPER   = YES
+utils/hpc_dist-install_INSTALL_SHELL_WRAPPER_NAME = hpc
+
 $(eval $(call build-prog,utils/hpc,dist-install,1))
Index: ghc-7.9.20140130/utils/hpc/hpc.wrapper
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ ghc-7.9.20140130/utils/hpc/hpc.wrapper	2014-02-04 23:17:49.000000000 +0000
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec "$executablename" ${1+"$@"}


Jens, how does that work in the Fedora package?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140204/9c1d08b0/attachment.sig>

From ariep at xs4all.nl  Wed Feb  5 14:09:42 2014
From: ariep at xs4all.nl (Arie Peterson)
Date: Wed, 05 Feb 2014 15:09:42 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <1453384.1Qu4SgTUZG@u017021>

On Monday 03 February 2014 16:35:14 Austin Seipp wrote:
> We are pleased to announce the first release candidate for GHC 7.8.1:
> [?]
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. [?]

Has anyone by chance built it for arm, yet? If I understand correctly, with 
this new version, it should be possible to compile programs with a dependency 
on vector, on arm.


Regards,

Arie


From rrnewton at gmail.com  Wed Feb  5 14:26:00 2014
From: rrnewton at gmail.com (Ryan Newton)
Date: Wed, 5 Feb 2014 09:26:00 -0500
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <B98FF0A7-4387-43D0-B58E-28F0AD4FA13C@fastmail.fm>
References: <mailman.13.1391515203.30932.glasgow-haskell-users@haskell.org>
 <B98FF0A7-4387-43D0-B58E-28F0AD4FA13C@fastmail.fm>
Message-ID: <CACYs5Aaf7Fo5Lq1-sP-TsEz4NBkKkqQprVnYhPPjKgVN1FaRPQ@mail.gmail.com>

I had some similar problems and had to fiddle with my DYLD_LIBRARY_PATH so
that ghc-related executables would see the libffi.dylib that comes with GHC
before any of my system-wide installed libffi.dylib.

Why the permissive @rpath link for libffi.dylib if the GHC executables are
supposed to come with their own?


On Tue, Feb 4, 2014 at 8:15 AM, Barney Stratford <
barney_stratford at fastmail.fm> wrote:

> I've been attempting to build under Mac OS X Mavericks and have run into
> some problems. My iconv and gmp are installed in non-standard locations
> using Fink. When configuring
> http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-x86_64-apple-darwin-mavericks.tar.bz2I get:
>
> barneys-imac:ghc-7.8.20140130 bjs$ ./configure
> --prefix=/Users/bjs/Desktop/ghc --with-iconv-includes=/sw/include
> --with-gmp-includes=/sw/include --with-iconv-libraries=/sw/lib
> --with-gmp-libraries=/sw/lib
> configure: WARNING: unrecognized options: --with-iconv-includes,
> --with-iconv-libraries
>
> and then the installed executable can't itself build ghc from source
> because of the missing iconv libraries. I noticed that ./configure --help
> doesn't mention --with-iconv-* in the Mavericks install files but it does
> in the source build.
>
> Any ideas?
>
> Cheers,
> Barney.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140205/b08d1b0a/attachment.html>

From karel.gardas at centrum.cz  Wed Feb  5 14:53:41 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 05 Feb 2014 15:53:41 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <1453384.1Qu4SgTUZG@u017021>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021>
Message-ID: <52F25075.6070804@centrum.cz>

On 02/ 5/14 03:09 PM, Arie Peterson wrote:
> On Monday 03 February 2014 16:35:14 Austin Seipp wrote:
>> We are pleased to announce the first release candidate for GHC 7.8.1:
>> [?]
>> This includes the source tarball and bindists for Windows, Linux, OS
>> X, FreeBSD, and Solaris, on x86 and x86_64. [?]
>
> Has anyone by chance built it for arm, yet? If I understand correctly, with
> this new version, it should be possible to compile programs with a dependency
> on vector, on arm.

Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC 
requires alex 3.1 and cabal alex fails with (due to QuickCheck template 
haskell dependency):

$ cabal install alex
Resolving dependencies...
Downloading random-1.0.1.1...
Configuring random-1.0.1.1...
Building random-1.0.1.1...
Preprocessing library random-1.0.1.1...
[1 of 1] Compiling System.Random    ( System/Random.hs, 
dist/build/System/Random.o )
Registering random-1.0.1.1...
Installing library in /home/karel/.cabal/lib/random-1.0.1.1/ghc-7.4.1
Registering random-1.0.1.1...
Downloading QuickCheck-2.6...
Configuring QuickCheck-2.6...
Building QuickCheck-2.6...
Preprocessing library QuickCheck-2.6...
[ 1 of 13] Compiling Test.QuickCheck.Exception ( 
Test/QuickCheck/Exception.hs, dist/build/Test/QuickCheck/Exception.o )
[ 2 of 13] Compiling Test.QuickCheck.Text ( Test/QuickCheck/Text.hs, 
dist/build/Test/QuickCheck/Text.o )
[ 3 of 13] Compiling Test.QuickCheck.State ( Test/QuickCheck/State.hs, 
dist/build/Test/QuickCheck/State.o )
[ 4 of 13] Compiling Test.QuickCheck.Gen ( Test/QuickCheck/Gen.hs, 
dist/build/Test/QuickCheck/Gen.o )
[ 5 of 13] Compiling Test.QuickCheck.Arbitrary ( 
Test/QuickCheck/Arbitrary.hs, dist/build/Test/QuickCheck/Arbitrary.o )
[ 6 of 13] Compiling Test.QuickCheck.Poly ( Test/QuickCheck/Poly.hs, 
dist/build/Test/QuickCheck/Poly.o )
[ 7 of 13] Compiling Test.QuickCheck.Modifiers ( 
Test/QuickCheck/Modifiers.hs, dist/build/Test/QuickCheck/Modifiers.o )
[ 8 of 13] Compiling Test.QuickCheck.Function ( 
Test/QuickCheck/Function.hs, dist/build/Test/QuickCheck/Function.o )
[ 9 of 13] Compiling Test.QuickCheck.Property ( 
Test/QuickCheck/Property.hs, dist/build/Test/QuickCheck/Property.o )
[10 of 13] Compiling Test.QuickCheck.Test ( Test/QuickCheck/Test.hs, 
dist/build/Test/QuickCheck/Test.o )
[11 of 13] Compiling Test.QuickCheck.Monadic ( 
Test/QuickCheck/Monadic.hs, dist/build/Test/QuickCheck/Monadic.o )
[12 of 13] Compiling Test.QuickCheck  ( Test/QuickCheck.hs, 
dist/build/Test/QuickCheck.o )
[13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, 
dist/build/Test/QuickCheck/All.o )

Test/QuickCheck/All.hs:28:20:
     Template Haskell bracket illegal in a stage-1 compiler
       [| quickCheck ($(mono x)) |]

[...]
Test/QuickCheck/All.hs:111:22:
     Template Haskell splice illegal in a stage-1 compiler
       forAllProperties
cabal: Error: some packages failed to install:
QuickCheck-2.6 failed during the building phase. The exception was:
ExitFailure 1
alex-3.1.3 depends on QuickCheck-2.6 which failed to install.


So, well, Catch-22?

Karel



From mail at joachim-breitner.de  Wed Feb  5 14:56:40 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 05 Feb 2014 14:56:40 +0000
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F25075.6070804@centrum.cz>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021> <52F25075.6070804@centrum.cz>
Message-ID: <1391612200.2550.6.camel@kirk>

Hi,

Am Mittwoch, den 05.02.2014, 15:53 +0100 schrieb Karel Gardas:
> Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC 
> requires alex 3.1 and cabal alex fails with (due to QuickCheck template 
> haskell dependency):
> 
> $ cabal install alex

have you tried --disable-tests?

Greetings,
Joachim
-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140205/cc14121b/attachment.sig>

From Christian.Maeder at dfki.de  Wed Feb  5 15:28:50 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 05 Feb 2014 16:28:50 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <52F258B2.8090305@dfki.de>

Hi, I was surprised to find a Solaris bindist. However, on our SunOS 
5.10 ./configure failed miserably.

-bash-3.2$ ./configure
checking for path to top of build tree... 
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: 
LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib: 
is not an identifier
configure: error: cannot determine current directory

This happens, because our /bin/sh is a "real" sh (and not a bash) that 
only allows to "export LD_LIBRARY_PATH" as a separate command.

The next failure was:
ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or 
directory

So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After 
this I got:
ld.so.1: ghc-pwd: fatal: relocation error: file 
libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so: 
symbol clearenv: referenced symbol not found

Which of my libraries is wrong (or too old) despite a matching version 
number?
         libdl.so.1 =>    /lib/libdl.so.1
         libgmp.so.10 =>  /opt/csw/lib/libgmp.so.10
         libm.so.2 =>     /lib/libm.so.2
         librt.so.1 =>    /lib/librt.so.1
         libc.so.1 =>     /lib/libc.so.1
         libgcc_s.so.1 =>         /opt/csw/lib/libgcc_s.so.1
         libaio.so.1 =>   /lib/libaio.so.1
         libmd.so.1 =>    /lib/libmd.so.1

I had to give up! (I'll try to build it from sources if I find time.)

Cheers Christian

Am 03.02.2014 23:35, schrieb Austin Seipp:
> We are pleased to announce the first release candidate for GHC 7.8.1:
>
>      http://www.haskell.org/ghc/dist/7.8.1-rc1/
>      http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> the SHA256 hashes available (attached) using my GPG key (keyid
> 0x3B58D86F).
>
> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> some existing issues.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


From roma at ro-che.info  Wed Feb  5 15:45:58 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 5 Feb 2014 17:45:58 +0200
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F258B2.8090305@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de>
Message-ID: <20140205154558.GA9775@sniper>

* Christian Maeder <Christian.Maeder at dfki.de> [2014-02-05 16:28:50+0100]
> This happens, because our /bin/sh is a "real" sh (and not a bash)
> that only allows to "export LD_LIBRARY_PATH" as a separate command.

You mean it's a "real" sh and not a POSIX-compatible one.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140205/6a7c7aeb/attachment.sig>

From christiaan.baaij at gmail.com  Wed Feb  5 15:46:57 2014
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Wed, 5 Feb 2014 16:46:57 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CACYs5Aaf7Fo5Lq1-sP-TsEz4NBkKkqQprVnYhPPjKgVN1FaRPQ@mail.gmail.com>
References: <mailman.13.1391515203.30932.glasgow-haskell-users@haskell.org>
 <B98FF0A7-4387-43D0-B58E-28F0AD4FA13C@fastmail.fm>
 <CACYs5Aaf7Fo5Lq1-sP-TsEz4NBkKkqQprVnYhPPjKgVN1FaRPQ@mail.gmail.com>
Message-ID: <9CC6866E-A8AD-4EBC-8BAB-0802A780E3B0@gmail.com>


On Feb 5, 2014, at 3:26 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> I had some similar problems and had to fiddle with my DYLD_LIBRARY_PATH so that ghc-related executables would see the libffi.dylib that comes with GHC before any of my system-wide installed libffi.dylib.
> 
> Why the permissive @rpath link for libffi.dylib if the GHC executables are supposed to come with their own?

See https://ghc.haskell.org/trac/ghc/ticket/8266 for more information about the dynamic linking on OS X.

The reason is two-fold:

- During development, the ghc binary, ghc-stage2, lives in 'TOP/inplace/lib/bin', while libffi lives in 'TOP/rts/dist/build'.
  When deployed, the ghc binary lives in 'TOP/lib/ghc-<version>/bin', while libff lives in 'TOP/lib/ghc-<version>/rts-1.0'.
  So, the relative paths differ during development and installation, meaning a hard-coded relative path was not an option.
- After some iterations, I decided to make OS X behave as much as Linux as possible.
  Meaning that I just added LC_RPATH's for every library location on which a binary depends.
  And every library on which binary depend is made @rpath-relative.
  
From the very bottom of the page https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html it was my understanding that LC_RPATH were considered first when searching dylibs that had a path starting with @rpath.

But apparently that is not the case?

Christiaan


From Christian.Maeder at dfki.de  Wed Feb  5 16:02:10 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 05 Feb 2014 17:02:10 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <20140205154558.GA9775@sniper>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <20140205154558.GA9775@sniper>
Message-ID: <52F26082.4070402@dfki.de>

Am 05.02.2014 16:45, schrieb Roman Cheplyaka:
> * Christian Maeder <Christian.Maeder at dfki.de> [2014-02-05 16:28:50+0100]
>> This happens, because our /bin/sh is a "real" sh (and not a bash)
>> that only allows to "export LD_LIBRARY_PATH" as a separate command.
>
> You mean it's a "real" sh and not a POSIX-compatible one.
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html

Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does 
not support:

   export name=word

One has to write:

   name=word
   export name

C.

>
> Roman
>


From ariep at xs4all.nl  Wed Feb  5 16:03:32 2014
From: ariep at xs4all.nl (Arie Peterson)
Date: Wed, 05 Feb 2014 17:03:32 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F25075.6070804@centrum.cz>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021> <52F25075.6070804@centrum.cz>
Message-ID: <2020626.htZxNxydQz@u017021>

On Wednesday 05 February 2014 15:53:41 Karel Gardas wrote:

> Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC
> requires alex 3.1 and cabal alex fails with (due to QuickCheck template
> haskell dependency):
> 
> [?]
> 
> So, well, Catch-22?

You can avoid this by installing QuickCheck without template haskell parts:

$ cabal install -f -templateHaskell QuickCheck

(syntax could be off).


Regards,

Arie


From allbery.b at gmail.com  Wed Feb  5 16:06:04 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 5 Feb 2014 11:06:04 -0500
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F26082.4070402@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <20140205154558.GA9775@sniper>
 <52F26082.4070402@dfki.de>
Message-ID: <CAKFCL4WqDnU5Kk2sjy5GiJR8x-KVT_r9qqRXmfhiaX9Ot-PT7A@mail.gmail.com>

On Wed, Feb 5, 2014 at 11:02 AM, Christian Maeder
<Christian.Maeder at dfki.de>wrote:

> Am 05.02.2014 16:45, schrieb Roman Cheplyaka:
>
>> * Christian Maeder <Christian.Maeder at dfki.de> [2014-02-05 16:28:50+0100]
>>
>>> This happens, because our /bin/sh is a "real" sh (and not a bash)
>>> that only allows to "export LD_LIBRARY_PATH" as a separate command.
>>>
>>
>> You mean it's a "real" sh and not a POSIX-compatible one.
>> http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html
>>
>
> Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does
> not support:
>

The Korn shell is where the `export NAME=value` syntax originated.

I am tempted to suggest that we verify that this is still in current POSIX
standards (the cited one is from 2004); POSIX recently dropped a
significant number of Korn-shell-derived behaviors from the standard.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140205/728f45cd/attachment.html>

From roma at ro-che.info  Wed Feb  5 16:10:59 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 5 Feb 2014 18:10:59 +0200
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAKFCL4WqDnU5Kk2sjy5GiJR8x-KVT_r9qqRXmfhiaX9Ot-PT7A@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <20140205154558.GA9775@sniper>
 <52F26082.4070402@dfki.de>
 <CAKFCL4WqDnU5Kk2sjy5GiJR8x-KVT_r9qqRXmfhiaX9Ot-PT7A@mail.gmail.com>
Message-ID: <20140205161059.GB10049@sniper>

* Brandon Allbery <allbery.b at gmail.com> [2014-02-05 11:06:04-0500]
> On Wed, Feb 5, 2014 at 11:02 AM, Christian Maeder
> <Christian.Maeder at dfki.de>wrote:
> 
> > Am 05.02.2014 16:45, schrieb Roman Cheplyaka:
> >
> >> * Christian Maeder <Christian.Maeder at dfki.de> [2014-02-05 16:28:50+0100]
> >>
> >>> This happens, because our /bin/sh is a "real" sh (and not a bash)
> >>> that only allows to "export LD_LIBRARY_PATH" as a separate command.
> >>>
> >>
> >> You mean it's a "real" sh and not a POSIX-compatible one.
> >> http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html
> >>
> >
> > Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does
> > not support:
> >
> 
> The Korn shell is where the `export NAME=value` syntax originated.
> 
> I am tempted to suggest that we verify that this is still in current POSIX
> standards (the cited one is from 2004); POSIX recently dropped a
> significant number of Korn-shell-derived behaviors from the standard.

This one is from 2013:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140205/0296b6e6/attachment.sig>

From Christian.Maeder at dfki.de  Wed Feb  5 16:31:22 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed, 05 Feb 2014 17:31:22 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAKFCL4WqDnU5Kk2sjy5GiJR8x-KVT_r9qqRXmfhiaX9Ot-PT7A@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>	<52F258B2.8090305@dfki.de>	<20140205154558.GA9775@sniper>	<52F26082.4070402@dfki.de>
 <CAKFCL4WqDnU5Kk2sjy5GiJR8x-KVT_r9qqRXmfhiaX9Ot-PT7A@mail.gmail.com>
Message-ID: <52F2675A.4090209@dfki.de>

Am 05.02.2014 17:06, schrieb Brandon Allbery:
>     Whatever it is, maybe it is a Korn Shell under (older) Solaris, it
>     does not support:
>
>
> The Korn shell is where the `export NAME=value` syntax originated.

It is a Bourne Shell under (our) SunOS 5.10 (not to be mixed up with 
Bourne-again shell "bash")

I think it is easy to stay shell compatible.

C.

> I am tempted to suggest that we verify that this is still in current
> POSIX standards (the cited one is from 2004); POSIX recently dropped a
> significant number of Korn-shell-derived behaviors from the standard.
>
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com <mailto:allbery.b at gmail.com> ballbery at sinenomine.net
> <mailto:ballbery at sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net


From karel.gardas at centrum.cz  Wed Feb  5 22:38:39 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 05 Feb 2014 23:38:39 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <1391612200.2550.6.camel@kirk>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021> <52F25075.6070804@centrum.cz>
 <1391612200.2550.6.camel@kirk>
Message-ID: <52F2BD6F.2030202@centrum.cz>

On 02/ 5/14 03:56 PM, Joachim Breitner wrote:
> Hi,
>
> Am Mittwoch, den 05.02.2014, 15:53 +0100 schrieb Karel Gardas:
>> Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC
>> requires alex 3.1 and cabal alex fails with (due to QuickCheck template
>> haskell dependency):
>>
>> $ cabal install alex
>
> have you tried --disable-tests?

Do you mean:

$ cabal install alex --disable-tests

no, but tried now and the result is still the same:

cabal: Error: some packages failed to install:
QuickCheck-2.6 failed during the building phase. The exception was:
ExitFailure 1
alex-3.1.3 depends on QuickCheck-2.6 which failed to install.
karel at panda:~$

Thanks for any idea how to fix that!

Karel

From karel.gardas at centrum.cz  Wed Feb  5 22:43:02 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 05 Feb 2014 23:43:02 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F258B2.8090305@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de>
Message-ID: <52F2BE76.2000409@centrum.cz>


Hi Christian,

the bindist is compiled on Solaris 11.0 so probably of no use for you on 
Solaris 10. Also I needed to provide separate tarball of compiled and 
installed libgmp.so as the Solaris 11's provided does not satisfy GHC 
requirements and GHC refuses to use that...

Karel

On 02/ 5/14 04:28 PM, Christian Maeder wrote:
> Hi, I was surprised to find a Solaris bindist. However, on our SunOS
> 5.10 ./configure failed miserably.
>
> -bash-3.2$ ./configure
> checking for path to top of build tree...
> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist:
> LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib:
> is not an identifier
> configure: error: cannot determine current directory
>
> This happens, because our /bin/sh is a "real" sh (and not a bash) that
> only allows to "export LD_LIBRARY_PATH" as a separate command.
>
> The next failure was:
> ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or
> directory
>
> So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After
> this I got:
> ld.so.1: ghc-pwd: fatal: relocation error: file
> libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so:
> symbol clearenv: referenced symbol not found
>
> Which of my libraries is wrong (or too old) despite a matching version
> number?
> libdl.so.1 => /lib/libdl.so.1
> libgmp.so.10 => /opt/csw/lib/libgmp.so.10
> libm.so.2 => /lib/libm.so.2
> librt.so.1 => /lib/librt.so.1
> libc.so.1 => /lib/libc.so.1
> libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
> libaio.so.1 => /lib/libaio.so.1
> libmd.so.1 => /lib/libmd.so.1
>
> I had to give up! (I'll try to build it from sources if I find time.)
>
> Cheers Christian
>
> Am 03.02.2014 23:35, schrieb Austin Seipp:
>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>
>> http://www.haskell.org/ghc/dist/7.8.1-rc1/
>> http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>
>> This includes the source tarball and bindists for Windows, Linux, OS
>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>> the SHA256 hashes available (attached) using my GPG key (keyid
>> 0x3B58D86F).
>>
>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>> some existing issues.
>>
>> Please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


From karel.gardas at centrum.cz  Wed Feb  5 22:59:38 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 05 Feb 2014 23:59:38 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <2020626.htZxNxydQz@u017021>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021> <52F25075.6070804@centrum.cz>
 <2020626.htZxNxydQz@u017021>
Message-ID: <52F2C25A.9000004@centrum.cz>

On 02/ 5/14 05:03 PM, Arie Peterson wrote:
> On Wednesday 05 February 2014 15:53:41 Karel Gardas wrote:
>
>> Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC
>> requires alex 3.1 and cabal alex fails with (due to QuickCheck template
>> haskell dependency):
>>
>> [?]
>>
>> So, well, Catch-22?
>
> You can avoid this by installing QuickCheck without template haskell parts:
>
> $ cabal install -f -templateHaskell QuickCheck
>
> (syntax could be off).

It's worked perfectly!

Thanks!
Karel
PS: building now...

From voldermort at hotmail.com  Thu Feb  6 07:03:27 2014
From: voldermort at hotmail.com (harry)
Date: Wed, 5 Feb 2014 23:03:27 -0800 (PST)
Subject: empty stable and current bindist directories
Message-ID: <1391670207657-5743464.post@n5.nabble.com>

http://www.haskell.org/ghc/dist/current/dist/ and
http://www.haskell.org/ghc/dist/stable/dist/ are empty. Is this correct?



--
View this message in context: http://haskell.1045720.n5.nabble.com/empty-stable-and-current-bindist-directories-tp5743464.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From Christian.Maeder at dfki.de  Thu Feb  6 09:33:48 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 06 Feb 2014 10:33:48 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F2BE76.2000409@centrum.cz>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <52F2BE76.2000409@centrum.cz>
Message-ID: <52F356FC.5010808@dfki.de>

Hi Karel,

Ok, yet I suppose that the #!/bin/sh script in ghc-pwd-bindist will 
still fail for me on Solaris 10, even if I build ghc from sources.

Why was this script changed? (Or was it not?)

Is still a (non-trivial) haskell binary needed to compute the current 
directory for ./configure?

Alternatively, if one does not want to make "export LD_LIBRARY_PATH ..." 
Bourne shell compatible, one should start the script with:

#!/bin/bash

  or (as I've seen elsewhere) better (?)

#!/usr/bin/env bash

Cheers Christian

Am 05.02.2014 23:43, schrieb Karel Gardas:
>
> Hi Christian,
>
> the bindist is compiled on Solaris 11.0 so probably of no use for you on
> Solaris 10. Also I needed to provide separate tarball of compiled and
> installed libgmp.so as the Solaris 11's provided does not satisfy GHC
> requirements and GHC refuses to use that...
>
> Karel
>
> On 02/ 5/14 04:28 PM, Christian Maeder wrote:
>> Hi, I was surprised to find a Solaris bindist. However, on our SunOS
>> 5.10 ./configure failed miserably.
>>
>> -bash-3.2$ ./configure
>> checking for path to top of build tree...
>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist:
>> LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib:
>>
>> is not an identifier
>> configure: error: cannot determine current directory
>>
>> This happens, because our /bin/sh is a "real" sh (and not a bash) that
>> only allows to "export LD_LIBRARY_PATH" as a separate command.
>>
>> The next failure was:
>> ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or
>> directory
>>
>> So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After
>> this I got:
>> ld.so.1: ghc-pwd: fatal: relocation error: file
>> libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so:
>> symbol clearenv: referenced symbol not found
>>
>> Which of my libraries is wrong (or too old) despite a matching version
>> number?
>> libdl.so.1 => /lib/libdl.so.1
>> libgmp.so.10 => /opt/csw/lib/libgmp.so.10
>> libm.so.2 => /lib/libm.so.2
>> librt.so.1 => /lib/librt.so.1
>> libc.so.1 => /lib/libc.so.1
>> libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
>> libaio.so.1 => /lib/libaio.so.1
>> libmd.so.1 => /lib/libmd.so.1
>>
>> I had to give up! (I'll try to build it from sources if I find time.)
>>
>> Cheers Christian
>>
>> Am 03.02.2014 23:35, schrieb Austin Seipp:
>>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>>
>>> http://www.haskell.org/ghc/dist/7.8.1-rc1/
>>> http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>>
>>> This includes the source tarball and bindists for Windows, Linux, OS
>>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>>> the SHA256 hashes available (attached) using my GPG key (keyid
>>> 0x3B58D86F).
>>>
>>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>>> some existing issues.
>>>
>>> Please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
...

From karel.gardas at centrum.cz  Thu Feb  6 13:19:12 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 06 Feb 2014 14:19:12 +0100
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <1453384.1Qu4SgTUZG@u017021>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1453384.1Qu4SgTUZG@u017021>
Message-ID: <52F38BD0.8020801@centrum.cz>

On 02/ 5/14 03:09 PM, Arie Peterson wrote:
> On Monday 03 February 2014 16:35:14 Austin Seipp wrote:
>> We are pleased to announce the first release candidate for GHC 7.8.1:
>> [?]
>> This includes the source tarball and bindists for Windows, Linux, OS
>> X, FreeBSD, and Solaris, on x86 and x86_64. [?]
>
> Has anyone by chance built it for arm, yet? If I understand correctly, with
> this new version, it should be possible to compile programs with a dependency
> on vector, on arm.

unfortunately build on ubuntu 12.04.2 lts still fails with:


"inplace/bin/ghc-stage2" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O 
    -package-name vector-0.10.9.1 -hide-all-packages -i 
-ilibraries/vector/. -ilibraries/vector/dist-install/build 
-ilibraries/vector/dist-install/build/autogen 
-Ilibraries/vector/dist-install/build 
-Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include 
-Ilibraries/vector/internal   -optP-DVECTOR_BOUNDS_CHECKS -optP-include 
-optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package 
base-4.7.0.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package 
primitive-0.5.2.0 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 
-no-user-package-db -rtsopts      -odir 
libraries/vector/dist-install/build -hidir 
libraries/vector/dist-install/build -stubdir 
libraries/vector/dist-install/build   -c 
libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o 
libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... Illegal instruction
make[1]: *** 
[libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 
132
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2


So either I made some mistake or we're not there yet.

Karel

From Christian.Maeder at dfki.de  Thu Feb  6 12:43:11 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 06 Feb 2014 13:43:11 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F2BE76.2000409@centrum.cz>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <52F2BE76.2000409@centrum.cz>
Message-ID: <52F3835F.9010600@dfki.de>

I can no longer build ghc from sources for yet another reason (attached 
log).

"sed" reports "command garbled". I do not even know where to find this 
call in the makefile infrastructure. I suspect "gsed" must be used 
instead (on our Solaris installation).

Cheers Christian

Am 05.02.2014 23:43, schrieb Karel Gardas:
>
> Hi Christian,
>
> the bindist is compiled on Solaris 11.0 so probably of no use for you on
> Solaris 10. Also I needed to provide separate tarball of compiled and
> installed libgmp.so as the Solaris 11's provided does not satisfy GHC
> requirements and GHC refuses to use that...
>
> Karel
>
> On 02/ 5/14 04:28 PM, Christian Maeder wrote:
>> Hi, I was surprised to find a Solaris bindist. However, on our SunOS
>> 5.10 ./configure failed miserably.
>>
>> -bash-3.2$ ./configure
>> checking for path to top of build tree...
>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist:
>> LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib:
>>
>> is not an identifier
>> configure: error: cannot determine current directory
>>
>> This happens, because our /bin/sh is a "real" sh (and not a bash) that
>> only allows to "export LD_LIBRARY_PATH" as a separate command.
>>
>> The next failure was:
>> ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or
>> directory
>>
>> So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After
>> this I got:
>> ld.so.1: ghc-pwd: fatal: relocation error: file
>> libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so:
>> symbol clearenv: referenced symbol not found
>>
>> Which of my libraries is wrong (or too old) despite a matching version
>> number?
>> libdl.so.1 => /lib/libdl.so.1
>> libgmp.so.10 => /opt/csw/lib/libgmp.so.10
>> libm.so.2 => /lib/libm.so.2
>> librt.so.1 => /lib/librt.so.1
>> libc.so.1 => /lib/libc.so.1
>> libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
>> libaio.so.1 => /lib/libaio.so.1
>> libmd.so.1 => /lib/libmd.so.1
>>
>> I had to give up! (I'll try to build it from sources if I find time.)
>>
>> Cheers Christian
>>
>> Am 03.02.2014 23:35, schrieb Austin Seipp:
>>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>>
>>> http://www.haskell.org/ghc/dist/7.8.1-rc1/
>>> http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>>
>>> This includes the source tarball and bindists for Windows, Linux, OS
>>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>>> the SHA256 hashes available (attached) using my GPG key (keyid
>>> 0x3B58D86F).
>>>
>>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>>> some existing issues.
>>>
>>> Please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.gz
Type: application/x-gzip
Size: 742 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140206/8cee0697/attachment.bin>

From mail at joachim-breitner.de  Thu Feb  6 13:36:02 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Feb 2014 13:36:02 +0000
Subject: RC1 build failures on Debian
Message-ID: <1391693762.2555.9.camel@kirk>

Hi,

with RC1 in experimental, the Debian auto-builders have now picked up
building 7.8, and it is failing on armel, hurd-i386, mips and mipsel:

armel (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140130-1&stamp=1391666879)
"inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -lffi -optl-pthread -optc-mlong-calls    -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.20140130 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010  -no-user-package-db -rtsopts      -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build     utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o    
/?PKGBUILDDIR?/compiler/stage2/build/libHSghc-7.8.20140130.a(genSym.o): In function `genSym':
genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock'
genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock'
collect2: error: ld returned 1 exit status
make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1
make[1]: *** [all] Error 2
make[1]: Leaving directory `/?PKGBUILDDIR?'
make: *** [build-stamp] Error 2


hurd (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-i386&ver=7.8.20140130-1&stamp=1391625204)
"inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic  -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2    -c rts/hooks/StackOverflow.c -o rts/dist/build/hooks/StackOverflow.dyn_o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.8.20140130 for i386-unknown-gnu):
	howToAccessLabel: PIC not defined for this platform

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

"inplace/bin/ghc-stage1" -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic  -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2    -c rts/sm/BlockAlloc.c -o rts/dist/build/sm/BlockAlloc.dyn_o
make[2]: *** [rts/dist/build/Apply.dyn_o] Error 1
make[1]: *** [all] Error 2
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2



mips (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mips&ver=7.8.20140130-1&stamp=1391631539)
mipsel (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mipsel&ver=7.8.20140130-1&stamp=1391660280)
In file included from rts/sm/Evac.c:21:0:
rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable!
 #error Cannot find a way to declare the thread-local gc variable!
  ^
make[2]: *** [rts/dist/build/.depend-v-p-dyn-l-debug-thr-thr_debug-thr_l-thr_p-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn-thr_debug_p.c_asm] Error 1
make[2]: *** Waiting for unfinished jobs....
echo "compiler_stage2_depfile_haskell_EXISTS = YES" >> compiler/stage2/build/.depend-v-p-dyn.haskell.tmp
for dir in compiler/stage2/build/./ compiler/stage2/build/CodeGen/ compiler/stage2/build/CodeGen/Platform/ compiler/stage2/build/Hoopl/ compiler/stage2/build/Llvm/ compiler/stage2/build/LlvmCodeGen/ compiler/stage2/build/PPC/ compiler/stage2/build/RegAlloc/ compiler/stage2/build/RegAlloc/Graph/ compiler/stage2/build/RegAlloc/Linear/ compiler/stage2/build/RegAlloc/Linear/PPC/ compiler/stage2/build/RegAlloc/Linear/SPARC/ compiler/stage2/build/RegAlloc/Linear/X86/ compiler/stage2/build/RegAlloc/Linear/X86_64/ compiler/stage2/build/SPARC/ compiler/stage2/build/SPARC/CodeGen/ compiler/stage2/build/Vectorise/ compiler/stage2/build/Vectorise/Builtins/ compiler/stage2/build/Vectorise/Generic/ compiler/stage2/build/Vectorise/Monad/ compiler/stage2/build/Vectorise/Type/ compiler/stage2/build/Vectorise/Utils/ compiler/stage2/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done
grep -v ' : [a-zA-Z]:/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp > compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2
sed '/hs$/ p                                      ; /hs$/ s/o /hi /g                             ; /hs$/ s/:/ : %hi: %o /                       ; /hs$/ s/^/$(eval $(call hi-rule,/      ; /hs$/ s/$/))/                             ; /hs-boot$/ p                                 ; /hs-boot$/ s/o-boot /hi-boot /g              ; /hs-boot$/ s/:/ : %hi-boot: %o-boot /        ; /hs-boot$/ s/^/$(eval $(call hi-rule,/ ; /hs-boot$/ s/$/))/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2 > compiler/stage2/build/.depend-v-p-dyn.haskell
make[1]: *** [all] Error 2
make[1]: Leaving directory `/?PKGBUILDDIR?'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Can anyone tell already from what the problem is, and preferably how to fix it?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140206/01f952d6/attachment.sig>

From karel.gardas at centrum.cz  Thu Feb  6 11:18:03 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 06 Feb 2014 12:18:03 +0100
Subject: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F356FC.5010808@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <52F2BE76.2000409@centrum.cz>
 <52F356FC.5010808@dfki.de>
Message-ID: <52F36F6B.50601@centrum.cz>


Hi Christian,

honestly speaking I've not touched ghc-pwd-bindist script at all. 
Everything I did was Austin's recommended: get the source in appropriate 
way, make, make binary-dist. It produced tarball and I've uploaded it.

Generally speaking if you are not satisfied with support for Solaris 10, 
please change it as you like and submit your patch to 
ghc-devs at haskell.org, people there are very friendly to merge if they 
see patch is all right...

Thanks!
Karel

On 02/ 6/14 10:33 AM, Christian Maeder wrote:
> Hi Karel,
>
> Ok, yet I suppose that the #!/bin/sh script in ghc-pwd-bindist will
> still fail for me on Solaris 10, even if I build ghc from sources.
>
> Why was this script changed? (Or was it not?)
>
> Is still a (non-trivial) haskell binary needed to compute the current
> directory for ./configure?
>
> Alternatively, if one does not want to make "export LD_LIBRARY_PATH ..."
> Bourne shell compatible, one should start the script with:
>
> #!/bin/bash
>
> or (as I've seen elsewhere) better (?)
>
> #!/usr/bin/env bash
>
> Cheers Christian
>
> Am 05.02.2014 23:43, schrieb Karel Gardas:
>>
>> Hi Christian,
>>
>> the bindist is compiled on Solaris 11.0 so probably of no use for you on
>> Solaris 10. Also I needed to provide separate tarball of compiled and
>> installed libgmp.so as the Solaris 11's provided does not satisfy GHC
>> requirements and GHC refuses to use that...
>>
>> Karel
>>
>> On 02/ 5/14 04:28 PM, Christian Maeder wrote:
>>> Hi, I was surprised to find a Solaris bindist. However, on our SunOS
>>> 5.10 ./configure failed miserably.
>>>
>>> -bash-3.2$ ./configure
>>> checking for path to top of build tree...
>>> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist:
>>> LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib:
>>>
>>>
>>> is not an identifier
>>> configure: error: cannot determine current directory
>>>
>>> This happens, because our /bin/sh is a "real" sh (and not a bash) that
>>> only allows to "export LD_LIBRARY_PATH" as a separate command.
>>>
>>> The next failure was:
>>> ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or
>>> directory
>>>
>>> So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After
>>> this I got:
>>> ld.so.1: ghc-pwd: fatal: relocation error: file
>>> libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so:
>>> symbol clearenv: referenced symbol not found
>>>
>>> Which of my libraries is wrong (or too old) despite a matching version
>>> number?
>>> libdl.so.1 => /lib/libdl.so.1
>>> libgmp.so.10 => /opt/csw/lib/libgmp.so.10
>>> libm.so.2 => /lib/libm.so.2
>>> librt.so.1 => /lib/librt.so.1
>>> libc.so.1 => /lib/libc.so.1
>>> libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
>>> libaio.so.1 => /lib/libaio.so.1
>>> libmd.so.1 => /lib/libmd.so.1
>>>
>>> I had to give up! (I'll try to build it from sources if I find time.)
>>>
>>> Cheers Christian
>>>
>>> Am 03.02.2014 23:35, schrieb Austin Seipp:
>>>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>>>
>>>> http://www.haskell.org/ghc/dist/7.8.1-rc1/
>>>> http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>>>
>>>> This includes the source tarball and bindists for Windows, Linux, OS
>>>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>>>> the SHA256 hashes available (attached) using my GPG key (keyid
>>>> 0x3B58D86F).
>>>>
>>>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>>>> some existing issues.
>>>>
>>>> Please test as much as possible; bugs are much cheaper if we find them
>>>> before the release!
> ...
>


From Christian.Maeder at dfki.de  Thu Feb  6 13:51:05 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 06 Feb 2014 14:51:05 +0100
Subject: [OS X mavericks and lifted-base] Re: ANNOUNCE: GHC 7.8.1 Release
 Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <52F39349.6080402@dfki.de>

cabal install lifted-base

   finally fails with:

[5 of 6] Compiling Control.Exception.Lifted ( 
Control/Exception/Lifted.hs, dist/build/Control/Exception/Lifted.p_o )

Control/Exception/Lifted.hs:82:1: Warning:
     The import of ?Monad? from module ?Control.Monad? is redundant
[6 of 6] Compiling Control.Concurrent.Lifted ( 
Control/Concurrent/Lifted.hs, dist/build/Control/Concurrent/Lifted.p_o )
ld: library not found for -lHSmonad-control-0.3.2.2-ghc7.8.20140130
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
Failed to install lifted-base-0.2.1.1

    base-unicode-symbols-0.2.2.4
    monad-control-0.3.2.2
    transformers-base-0.4.1

are properly installed.

There is a library libHSmonad-control-0.3.2.2.a
(but no "libHSmonad-control-0.3.2.2-ghc7.8.20140130.a")

Cheers Christian

Am 03.02.2014 23:35, schrieb Austin Seipp:
> We are pleased to announce the first release candidate for GHC 7.8.1:
>
>      http://www.haskell.org/ghc/dist/7.8.1-rc1/
>      http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> the SHA256 hashes available (attached) using my GPG key (keyid
> 0x3B58D86F).
>
> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> some existing issues.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


From karel.gardas at centrum.cz  Thu Feb  6 13:53:02 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Thu, 06 Feb 2014 14:53:02 +0100
Subject: RC1 build failures on Debian
In-Reply-To: <1391693762.2555.9.camel@kirk>
References: <1391693762.2555.9.camel@kirk>
Message-ID: <52F393BE.5090203@centrum.cz>

On 02/ 6/14 02:36 PM, Joachim Breitner wrote:
> Hi,
>
> with RC1 in experimental, the Debian auto-builders have now picked up
> building 7.8, and it is failing on armel, hurd-i386, mips and mipsel:
>
> armel (https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140130-1&stamp=1391666879)
> "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -lffi -optl-pthread -optc-mlong-calls    -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen    -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.20140130 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010  -no-user-package-db -rtsopts      -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build     utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documenta
 tion/Hadd
ock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Ut
 f8.o util
s/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o uti
 ls/haddoc
k/dist/build/Paths_haddock.o
> /?PKGBUILDDIR?/compiler/stage2/build/libHSghc-7.8.20140130.a(genSym.o): In function `genSym':
> genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock'
> genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock'
> collect2: error: ld returned 1 exit status
> make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/?PKGBUILDDIR?'
> make: *** [build-stamp] Error 2

Looks like this is for pre-ARMv6 platform. Also it looks like probably 
OldARMAtomic.c is not compiled or/not linked into the RTS?

Karel

From merijn at inconsistent.nl  Thu Feb  6 12:39:51 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Thu, 6 Feb 2014 13:39:51 +0100
Subject: [Solaris bindist] ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52F356FC.5010808@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <52F2BE76.2000409@centrum.cz>
 <52F356FC.5010808@dfki.de>
Message-ID: <20B0536D-221E-4A0F-8CA6-334438B71CF3@inconsistent.nl>


On Feb 6, 2014, at 10:33 , Christian Maeder wrote:
> or (as I've seen elsewhere) better (?)
> 
> #!/usr/bin/env bash

Definitely use this, FreeBSD (for example) does not ship with bash so /bin/bash will *not* exist.

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140206/a4bb7567/attachment.sig>

From lukexipd at gmail.com  Thu Feb  6 14:03:47 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 6 Feb 2014 06:03:47 -0800
Subject: GHC iOS 7.8.1 RC1 for Device & Simulator
Message-ID: <CAGo83Cgie8FOHtZ7a8Ls0KM_1YsbBF_YccV_41CaSv5kz+DZdA@mail.gmail.com>

Hi folks,

RC builds of GHC iOS are now ready for devices and the iOS simulator.

https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simulator/ghc-7.8.20140130-i386-apple-ios.tar.bz2

You'll find complete instructions on their usage here, including compiling
cabal packages:
https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md

Please let me know how it goes!
Cheers
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140206/bc649fea/attachment.html>

From pali.gabor at gmail.com  Thu Feb  6 14:27:54 2014
From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=)
Date: Thu, 6 Feb 2014 15:27:54 +0100
Subject: [Solaris bindist] ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <20B0536D-221E-4A0F-8CA6-334438B71CF3@inconsistent.nl>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52F258B2.8090305@dfki.de> <52F2BE76.2000409@centrum.cz>
 <52F356FC.5010808@dfki.de>
 <20B0536D-221E-4A0F-8CA6-334438B71CF3@inconsistent.nl>
Message-ID: <CAHnG2Cw64v5HFAoc0_iG1eeK7ku0A=NWQ_o-YGQUXqohpGx0GA@mail.gmail.com>

On Thu, Feb 6, 2014 at 1:39 PM, Merijn Verstraaten
<merijn at inconsistent.nl> wrote:
>
> On Feb 6, 2014, at 10:33 , Christian Maeder wrote:
>> or (as I've seen elsewhere) better (?)
>>
>> #!/usr/bin/env bash
>
> Definitely use this, FreeBSD (for example) does not ship with bash so /bin/bash will *not* exist.

Please, do not introduce dependency on bash unless it is really necessary.

From voldermort at hotmail.com  Thu Feb  6 19:05:46 2014
From: voldermort at hotmail.com (harry)
Date: Thu, 6 Feb 2014 11:05:46 -0800 (PST)
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <1391713546737-5743506.post@n5.nabble.com>

Would it be possible for the bindist to link to libgmp.so instead of
libgmp.so.10? Are you expecting core dumps with the wrong version?



--
View this message in context: http://haskell.1045720.n5.nabble.com/ANNOUNCE-GHC-7-8-1-Release-Candidate-1-tp5743256p5743506.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From voldermort at hotmail.com  Thu Feb  6 19:19:48 2014
From: voldermort at hotmail.com (harry)
Date: Thu, 6 Feb 2014 11:19:48 -0800 (PST)
Subject: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <1391713546737-5743506.post@n5.nabble.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <1391713546737-5743506.post@n5.nabble.com>
Message-ID: <1391714388708-5743507.post@n5.nabble.com>

> Would it be possible for the bindist to link to libgmp.so instead of
libgmp.so.10? Are you expecting core dumps with the wrong version?

I tried faking it, and now it's complaining about GLIBC_2.15. Seems like I
might just have to build from source on Red Hat.



--
View this message in context: http://haskell.1045720.n5.nabble.com/ANNOUNCE-GHC-7-8-1-Release-Candidate-1-tp5743256p5743507.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From mechvel at botik.ru  Thu Feb  6 20:05:59 2014
From: mechvel at botik.ru (Sergei Meshveliani)
Date: Fri, 07 Feb 2014 00:05:59 +0400
Subject: 7.8.1-candidate fail
Message-ID: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>

Dear GHC team,

I am trying to test    ghc-7.8.20140130-src.tar.bz2

I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).

./configure  looks all right.

And `make' reports after 40 minutes:

-------------------------------------------------------
...
...
"inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
-optc-I'/home/mechvel/g.....
...
...
/usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: ***
[libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
-ghc7.8.20140130.so] Error 1
-------------------------------------------------------


What might this mean? Need I to install a fresher  libgmp ?

Thanks,

------
Sergei


From jan.stolarek at p.lodz.pl  Thu Feb  6 20:50:55 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Feb 2014 21:50:55 +0100
Subject: 7.8.1-candidate fail
In-Reply-To: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
Message-ID: <201402062150.55164.jan.stolarek@p.lodz.pl>

I had the same problem on Debian Squeeze:

https://ghc.haskell.org/trac/ghc/ticket/8666

What is your distro?

CCing ghc-devs.

Janek

Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> Dear GHC team,
>
> I am trying to test    ghc-7.8.20140130-src.tar.bz2
>
> I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
>
> ./configure  looks all right.
>
> And `make' reports after 40 minutes:
>
> -------------------------------------------------------
> ...
> ...
> "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> -optc-I'/home/mechvel/g.....
> ...
> ...
> /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> object; recompile with -fPIC
> libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[1]: ***
> [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> -ghc7.8.20140130.so] Error 1
> -------------------------------------------------------
>
>
> What might this mean? Need I to install a fresher  libgmp ?
>
> Thanks,
>
> ------
> Sergei
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



From nikita at karetnikov.org  Fri Feb  7 07:59:40 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Fri, 07 Feb 2014 11:59:40 +0400
Subject: RC1 build failures on Debian
In-Reply-To: <1391693762.2555.9.camel@kirk> (Joachim Breitner's message of
 "Thu, 06 Feb 2014 13:36:02 +0000")
References: <1391693762.2555.9.camel@kirk>
Message-ID: <87zjm3gxoz.fsf@karetnikov.org>

> In file included from rts/sm/Evac.c:21:0:
> rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable!
>  #error Cannot find a way to declare the thread-local gc variable!
>   ^

I built GHC from the source tarball on mips64el and hit the same error.
Any suggestions?

Funnily, the comment in the corresponding file says

/* Impossible! */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140207/53a84b3b/attachment-0001.sig>

From karel.gardas at centrum.cz  Fri Feb  7 08:36:38 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Fri, 07 Feb 2014 09:36:38 +0100
Subject: RC1 build failures on Debian
In-Reply-To: <87zjm3gxoz.fsf@karetnikov.org>
References: <1391693762.2555.9.camel@kirk> <87zjm3gxoz.fsf@karetnikov.org>
Message-ID: <52F49B16.50606@centrum.cz>


IMHO this should already be fixed in HEAD with patch by Peter Trommler: 
298a25bdfd02bb591fde2dd0590bd7af81a91b94 which fixes #8722: 
https://ghc.haskell.org/trac/ghc/ticket/8722

Karel

On 02/ 7/14 08:59 AM, Nikita Karetnikov wrote:
>> In file included from rts/sm/Evac.c:21:0:
>> rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable!
>>   #error Cannot find a way to declare the thread-local gc variable!
>>    ^
>
> I built GHC from the source tarball on mips64el and hit the same error.
> Any suggestions?
>
> Funnily, the comment in the corresponding file says
>
> /* Impossible! */
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From mail at joachim-breitner.de  Fri Feb  7 09:15:15 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 07 Feb 2014 09:15:15 +0000
Subject: RC1 build failures on Debian
In-Reply-To: <52F49B16.50606@centrum.cz>
References: <1391693762.2555.9.camel@kirk> <87zjm3gxoz.fsf@karetnikov.org>
 <52F49B16.50606@centrum.cz>
Message-ID: <1391764515.2608.12.camel@kirk>

Hi,

Am Freitag, den 07.02.2014, 09:36 +0100 schrieb Karel Gardas:
> IMHO this should already be fixed in HEAD with patch by Peter Trommler: 
> 298a25bdfd02bb591fde2dd0590bd7af81a91b94 which fixes #8722: 
> https://ghc.haskell.org/trac/ghc/ticket/8722

thanks for spotting. I?ll wait for RC2 and report back.


By now, also sparc has tried building GHC, and it also fails:
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140130-1&stamp=1391733028
/tmp/ghc18306_0/ghc18306_2.hc:928:1:
     error: 'MainCapability' undeclared (first use in this function)
/tmp/ghc18306_0/ghc18306_2.hc: In function 'ghczm7zi8zi20140130_ExtsCompat46_geCharzh_entry':

/tmp/ghc18306_0/ghc18306_2.hc:948:1:
     error: 'MainCapability' undeclared (first use in this function)
/tmp/ghc18306_0/ghc18306_2.hc: In function 'ghczm7zi8zi20140130_ExtsCompat46_gtCharzh_entry':

/tmp/ghc18306_0/ghc18306_2.hc:968:1:
     error: 'MainCapability' undeclared (first use in this function)
make[2]: *** [compiler/stage2/build/ExtsCompat46.o] Error 1

Any ideas?

Things have quite deteriorated on non-mainstream-architectures. Maybe I
should, for the next release cycle, do a maybe weekly upload of GHC head
to Debian experimental, so that these problems are found closer to their
cause. Or hope for the builders network resurrection.

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140207/f45fa012/attachment.sig>

From nikita at karetnikov.org  Fri Feb  7 09:36:30 2014
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Fri, 07 Feb 2014 13:36:30 +0400
Subject: RC1 build failures on Debian
In-Reply-To: <52F49B16.50606@centrum.cz> (Karel Gardas's message of "Fri, 07
 Feb 2014 09:36:38 +0100")
References: <1391693762.2555.9.camel@kirk> <87zjm3gxoz.fsf@karetnikov.org>
 <52F49B16.50606@centrum.cz>
Message-ID: <874n4bi7s1.fsf@karetnikov.org>

> IMHO this should already be fixed in HEAD with patch by Peter
> Trommler: 298a25bdfd02bb591fde2dd0590bd7af81a91b94 which fixes #8722:
> https://ghc.haskell.org/trac/ghc/ticket/8722

Thanks for letting me know.  The ticket mentions DYNAMIC-BY_DEFAULT=NO,
should I specify anything in the ?build.mk? file?  Or will it work
without that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140207/bbf79722/attachment.sig>

From voldermort at hotmail.com  Sat Feb  8 18:24:30 2014
From: voldermort at hotmail.com (harry)
Date: Sat, 8 Feb 2014 10:24:30 -0800 (PST)
Subject: 7.8.1, template haskell, and dynamic libraries
Message-ID: <1391883870488-5743587.post@n5.nabble.com>

The docs for 7.8.1 say "Template Haskell must now load dynamic object files,
not static ones". Does this mean that, if I'm using Template Haskell, every
package which the templates depend on have to be built with --enable-shared?



--
View this message in context: http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From voldermort at hotmail.com  Sat Feb  8 18:33:36 2014
From: voldermort at hotmail.com (harry)
Date: Sat, 8 Feb 2014 10:33:36 -0800 (PST)
Subject: target audience for the binary distribution
Message-ID: <1391884416819-5743588.post@n5.nabble.com>

I'm unable to install the binary distribution of 7.8.1 on RHEL because it
requires libgmp.so.10 and GLIBC_2.15, which are much greater than the
version available on Red Hat. (I'm on a shared system without root access,
so upgrading libc is out of the question, even if it could be done.) If this
is what most users would like, I certainly don't want to be the Luddite
trying to hold them back.

Who actually are "most users" for the bindist? Debian & derivatives have the
latest GHC in the package repository, so it's presumably Red Hat & Co, and
people without root. If the bindist is only relevant to rootless users on a
modern Debian derived distro, is it targeting the right audience?



--
View this message in context: http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From davean at xkcd.com  Sat Feb  8 18:43:01 2014
From: davean at xkcd.com (davean)
Date: Sat, 8 Feb 2014 13:43:01 -0500
Subject: target audience for the binary distribution
In-Reply-To: <1391884416819-5743588.post@n5.nabble.com>
References: <1391884416819-5743588.post@n5.nabble.com>
Message-ID: <CABFs2VgQmbf+AJEZXNgGBS2h0GsuAELMscwZsa=k0PvjwGizEA@mail.gmail.com>

As a Debian user, I always do a home directory install. I also am root.


On Sat, Feb 8, 2014 at 1:33 PM, harry <voldermort at hotmail.com> wrote:

> I'm unable to install the binary distribution of 7.8.1 on RHEL because it
> requires libgmp.so.10 and GLIBC_2.15, which are much greater than the
> version available on Red Hat. (I'm on a shared system without root access,
> so upgrading libc is out of the question, even if it could be done.) If
> this
> is what most users would like, I certainly don't want to be the Luddite
> trying to hold them back.
>
> Who actually are "most users" for the bindist? Debian & derivatives have
> the
> latest GHC in the package repository, so it's presumably Red Hat & Co, and
> people without root. If the bindist is only relevant to rootless users on a
> modern Debian derived distro, is it targeting the right audience?
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140208/dac463ce/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  8 18:51:37 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 8 Feb 2014 13:51:37 -0500
Subject: target audience for the binary distribution
In-Reply-To: <CABFs2VgQmbf+AJEZXNgGBS2h0GsuAELMscwZsa=k0PvjwGizEA@mail.gmail.com>
References: <1391884416819-5743588.post@n5.nabble.com>
 <CABFs2VgQmbf+AJEZXNgGBS2h0GsuAELMscwZsa=k0PvjwGizEA@mail.gmail.com>
Message-ID: <CAHYVw0yNQ45DDgYwHdtvnmgT2e91u9=G4+NACHwzJEBZhAoxNw@mail.gmail.com>

its important to note that this is still  a release candidate!  Your
feedback means we can try to support you better with the final "OFFICIAL"
7.8.1 release! :)

seriously, thanks for taking the time to try out the RC, please holler with
any other issues you hit


On Sat, Feb 8, 2014 at 1:43 PM, davean <davean at xkcd.com> wrote:

> As a Debian user, I always do a home directory install. I also am root.
>
>
> On Sat, Feb 8, 2014 at 1:33 PM, harry <voldermort at hotmail.com> wrote:
>
>> I'm unable to install the binary distribution of 7.8.1 on RHEL because it
>> requires libgmp.so.10 and GLIBC_2.15, which are much greater than the
>> version available on Red Hat. (I'm on a shared system without root access,
>> so upgrading libc is out of the question, even if it could be done.) If
>> this
>> is what most users would like, I certainly don't want to be the Luddite
>> trying to hold them back.
>>
>> Who actually are "most users" for the bindist? Debian & derivatives have
>> the
>> latest GHC in the package repository, so it's presumably Red Hat & Co, and
>> people without root. If the bindist is only relevant to rootless users on
>> a
>> modern Debian derived distro, is it targeting the right audience?
>>
>>
>>
>> --
>> View this message in context:
>> http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588.html
>> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
>> Nabble.com.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140208/2172d7a9/attachment.html>

From carter.schonwald at gmail.com  Sat Feb  8 19:21:20 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 8 Feb 2014 14:21:20 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <1391883870488-5743587.post@n5.nabble.com>
References: <1391883870488-5743587.post@n5.nabble.com>
Message-ID: <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>

Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)

On Saturday, February 8, 2014, harry <voldermort at hotmail.com> wrote:

> The docs for 7.8.1 say "Template Haskell must now load dynamic object
> files,
> not static ones". Does this mean that, if I'm using Template Haskell, every
> package which the templates depend on have to be built with
> --enable-shared?
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140208/b414541a/attachment.html>

From voldermort at hotmail.com  Sun Feb  9 08:30:48 2014
From: voldermort at hotmail.com (harry)
Date: Sun, 9 Feb 2014 00:30:48 -0800 (PST)
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
Message-ID: <1391934648414-5743624.post@n5.nabble.com>

Carter Schonwald wrote
> Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)
> 
>> The docs for 7.8.1 say "Template Haskell must now load dynamic object
>> files,
>> not static ones". Does this mean that, if I'm using Template Haskell,
>> every
>> package which the templates depend on have to be built with
>> --enable-shared?

Perhaps there should be a clear warning about this? If I've understood
correctly, anything using Template Haskell will break when upgrading to 7.8,
until all the dependencies are reinstalled with  --enable-shared.



--
View this message in context: http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743624.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From michael at snoyman.com  Sun Feb  9 08:35:53 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 9 Feb 2014 10:35:53 +0200
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <1391934648414-5743624.post@n5.nabble.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
Message-ID: <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>

On Sun, Feb 9, 2014 at 10:30 AM, harry <voldermort at hotmail.com> wrote:

> Carter Schonwald wrote
> > Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)
> >
> >> The docs for 7.8.1 say "Template Haskell must now load dynamic object
> >> files,
> >> not static ones". Does this mean that, if I'm using Template Haskell,
> >> every
> >> package which the templates depend on have to be built with
> >> --enable-shared?
>
> Perhaps there should be a clear warning about this? If I've understood
> correctly, anything using Template Haskell will break when upgrading to
> 7.8,
> until all the dependencies are reinstalled with  --enable-shared.
>
>
>
When upgrading to a new version of GHC, you'll have to reinstall all of the
packages anyway. You can't simply use GHC 7.6 compiled packages with your
new GHC 7.8.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/72cf8fba/attachment-0001.html>

From voldermort at hotmail.com  Sun Feb  9 09:04:00 2014
From: voldermort at hotmail.com (harry)
Date: Sun, 9 Feb 2014 01:04:00 -0800 (PST)
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
Message-ID: <1391936640650-5743628.post@n5.nabble.com>

Michael Snoyman wrote
> When upgrading to a new version of GHC, you'll have to reinstall all of
> the
> packages anyway. You can't simply use GHC 7.6 compiled packages with your
> new GHC 7.8.

This is probably the point at which it would be useful to know that all this
recompilation will have to be done with dynamic libraries, to avoid having
to do it all a second time when the user tries to use templates.



--
View this message in context: http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From gregmainland at gmail.com  Sun Feb  9 14:28:22 2014
From: gregmainland at gmail.com (Greg Horn)
Date: Sun, 9 Feb 2014 15:28:22 +0100
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <1391936640650-5743628.post@n5.nabble.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
Message-ID: <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>

Is --enable-shared off by default?
On Feb 9, 2014 9:04 AM, "harry" <voldermort at hotmail.com> wrote:

> Michael Snoyman wrote
> > When upgrading to a new version of GHC, you'll have to reinstall all of
> > the
> > packages anyway. You can't simply use GHC 7.6 compiled packages with your
> > new GHC 7.8.
>
> This is probably the point at which it would be useful to know that all
> this
> recompilation will have to be done with dynamic libraries, to avoid having
> to do it all a second time when the user tries to use templates.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/7dbb90dc/attachment.html>

From allbery.b at gmail.com  Sun Feb  9 14:41:48 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 9 Feb 2014 09:41:48 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
Message-ID: <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>

On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com> wrote:

> Is --enable-shared off by default?
>
It's supposed to be on by default in 7.8. That said, not sure how many
people have played with ~/.cabal/config....

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/55d13293/attachment.html>

From carter.schonwald at gmail.com  Sun Feb  9 17:11:42 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 9 Feb 2014 12:11:42 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
Message-ID: <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>

Indeed. The problem is that many folks might have cabal config files that
explicitly disable shared.  (For the compile times!).  They might need
clear information about wiping that field.

On Sunday, February 9, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com<javascript:_e(%7B%7D,'cvml','gregmainland at gmail.com');>
> > wrote:
>
>> Is --enable-shared off by default?
>>
> It's supposed to be on by default in 7.8. That said, not sure how many
> people have played with ~/.cabal/config....
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
> ballbery at sinenomine.net<javascript:_e(%7B%7D,'cvml','ballbery at sinenomine.net');>
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/a48daa2d/attachment.html>

From trebla at vex.net  Sun Feb  9 18:58:36 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sun, 09 Feb 2014 13:58:36 -0500
Subject: target audience for the binary distribution
In-Reply-To: <1391884416819-5743588.post@n5.nabble.com>
References: <1391884416819-5743588.post@n5.nabble.com>
Message-ID: <52F7CFDC.9090107@vex.net>

On 14-02-08 01:33 PM, harry wrote:
> Who actually are "most users" for the bindist? Debian & derivatives have the
> latest GHC in the package repository

No. The other pasture is not greener. The distro you don't use is not 
more up to date. Chinese proverb: all crows in the whole world are 
equally black.

Debian and derivatives almost always have the wrong version. Wrong 
version means:

* Lagging behind Haskell Platform. And Haskell Platform is already very 
conservative and has its own wait-and-see period.

* If one version has a serious bug, then long after the bugfix version 
is released, Debian and derivatives still cling on to the bug. Here is a 
historical example: 6.12.1 had a serious bug, fixed in 6 months. Ubuntu 
10.04 and 10.10 both provided 6.12.1, this means 12 months of living 
with the bug for you. (10.04's case was justifiable, 10.10's was 
inexcusable.)
http://www.vex.net/~trebla/haskell/sicp.xhtml#ghc6121

I use the bindist.


From george.colpitts at gmail.com  Sun Feb  9 19:37:09 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 9 Feb 2014 15:37:09 -0400
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
Message-ID: <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>

Yes, in general I think the doc needs a section: Incompatible changes. The
hope is that you can take the release and just work as usual but when (for
good reasons as in this release) it is not true is is important to have
such a section. Another case that needs to be there is how to compile so
you can load compile object files into ghci as what you did in 7.6.3 won't
work in this release.


On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> Indeed. The problem is that many folks might have cabal config files that
> explicitly disable shared.  (For the compile times!).  They might need
> clear information about wiping that field.
>
>
> On Sunday, February 9, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:
>
>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com> wrote:
>>
>>> Is --enable-shared off by default?
>>>
>> It's supposed to be on by default in 7.8. That said, not sure how many
>> people have played with ~/.cabal/config....
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/1a24b6d5/attachment.html>

From austin at well-typed.com  Sun Feb  9 20:37:23 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 9 Feb 2014 14:37:23 -0600
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
Message-ID: <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>

It is correct that Template Haskell now requires dynamic objects.
However, GHC can produce static and dynamic objects at the same time,
so you don't have to recompile a package twice (it's a big
optimization, basically).

Furthermore, if TemplateHaskell is enabled as a requirement for a
package, and GHC is built dynamically, Cabal will do The Right Thing
by building the shared objects for the dependencies as well. It will
save time by doing so using -dynamic-too, if possible. This is because
it queries GHC before compilation to figure this out (you can run 'ghc
--info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
dynamic-too" fields.)

Finally, if you simply run 'ghc Foo.hs' on a file that requires
TemplateHaskell, it will also switch on -dynamic-too for the needed
objects in this simple case.

There is one caveat, if I remember correctly: if a package uses
TemplateHaskell, it must declare it as such in the Cabal file. This is
because Cabal does not parse the source to detect if TemplateHaskell
is needed in the dependency graph of the compiled modules. Only GHC
can do this reliably. If you don't specify TemplateHaskell as an
extension, Cabal might not do the right thing. This is noted in the
release notes:

> Note that Cabal will correctly handle -dynamic-too for you automatically, especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are using the TemplateHaskell extension.

However, based on the other suggestions in the thread and confusion
around this, a big "Incompatible changes" section with this listed as
the first thing with clear detail would be a good idea. I'll do so.

If something else is going on, please file a bug.

On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> Yes, in general I think the doc needs a section: Incompatible changes. The
> hope is that you can take the release and just work as usual but when (for
> good reasons as in this release) it is not true is is important to have such
> a section. Another case that needs to be there is how to compile so you can
> load compile object files into ghci as what you did in 7.6.3 won't work in
> this release.
>
>
> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>>
>> Indeed. The problem is that many folks might have cabal config files that
>> explicitly disable shared.  (For the compile times!).  They might need clear
>> information about wiping that field.
>>
>>
>> On Sunday, February 9, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:
>>>
>>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com> wrote:
>>>>
>>>> Is --enable-shared off by default?
>>>
>>> It's supposed to be on by default in 7.8. That said, not sure how many
>>> people have played with ~/.cabal/config....
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Sun Feb  9 21:13:17 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Feb 2014 21:13:17 +0000
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
Message-ID: <1391980397.3007.7.camel@kirk>

Hi,

Am Sonntag, den 09.02.2014, 14:37 -0600 schrieb Austin Seipp:
> There is one caveat, if I remember correctly: if a package uses
> TemplateHaskell, it must declare it as such in the Cabal file. This is
> because Cabal does not parse the source to detect if TemplateHaskell
> is needed in the dependency graph of the compiled modules. Only GHC
> can do this reliably. If you don't specify TemplateHaskell as an
> extension, Cabal might not do the right thing. This is noted in the
> release notes:
> 
> > Note that Cabal will correctly handle -dynamic-too for you automatically, especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are using the TemplateHaskell extension.

we need -dynamic-too also for everything that a user ever might want to
load in GHCi, right? So doesn?t that already imply that Cabal should and
will build libHS*so files always anyways?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/a39c8027/attachment.sig>

From austin at well-typed.com  Sun Feb  9 21:14:02 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 9 Feb 2014 15:14:02 -0600
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
Message-ID: <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>

Actually, just to keep it even simpler, so nobody else is confused
further: Cabal will *also* properly turn on dynamic builds for regular
packages if GHC is dynamic, TemplateHaskell or not. So any library you
compile will still work in GHCi as expected.

So here's the breakdown:

  1) Cabal 1.18 will handle dynamical GHCi correctly, including
compiling things dynamically, however it must.
  2) Per #1, libraries are compiled dynamically. This means libraries
work in GHCi, just like they did.
  3) -Executables- are statically linked by default, still. (But
because of #1 and #2, it's very easy to turn on dynamic exes as well,
without needing to recompile a lot.)
  4) TemplateHaskell works as expected due to #1 and #2. But there is
one caveat for executables, noted separately below.

The caveat with TemplateHaskell is for executables: This is because if
you end up with an executable that needs TH and profiling, Cabal must
be aware of this. Why? Because GHCi cannot load *profiled* objects,
only normal ones. So we must compile twice: once without profiling,
and once with profiling. The second compilation will use the 'normal'
objects, even though the final executable will be profiled. Cabal
doesn't know to do this if it doesn't know TemplateHaskell is a
requirement.

Does this clear things up? My last message might give the impression
some things aren't compiled dynamically, because I merely ambiguously
referred to 'packages'.

On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp <austin at well-typed.com> wrote:
> It is correct that Template Haskell now requires dynamic objects.
> However, GHC can produce static and dynamic objects at the same time,
> so you don't have to recompile a package twice (it's a big
> optimization, basically).
>
> Furthermore, if TemplateHaskell is enabled as a requirement for a
> package, and GHC is built dynamically, Cabal will do The Right Thing
> by building the shared objects for the dependencies as well. It will
> save time by doing so using -dynamic-too, if possible. This is because
> it queries GHC before compilation to figure this out (you can run 'ghc
> --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
> dynamic-too" fields.)
>
> Finally, if you simply run 'ghc Foo.hs' on a file that requires
> TemplateHaskell, it will also switch on -dynamic-too for the needed
> objects in this simple case.
>
> There is one caveat, if I remember correctly: if a package uses
> TemplateHaskell, it must declare it as such in the Cabal file. This is
> because Cabal does not parse the source to detect if TemplateHaskell
> is needed in the dependency graph of the compiled modules. Only GHC
> can do this reliably. If you don't specify TemplateHaskell as an
> extension, Cabal might not do the right thing. This is noted in the
> release notes:
>
>> Note that Cabal will correctly handle -dynamic-too for you automatically, especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are using the TemplateHaskell extension.
>
> However, based on the other suggestions in the thread and confusion
> around this, a big "Incompatible changes" section with this listed as
> the first thing with clear detail would be a good idea. I'll do so.
>
> If something else is going on, please file a bug.
>
> On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
>> Yes, in general I think the doc needs a section: Incompatible changes. The
>> hope is that you can take the release and just work as usual but when (for
>> good reasons as in this release) it is not true is is important to have such
>> a section. Another case that needs to be there is how to compile so you can
>> load compile object files into ghci as what you did in 7.6.3 won't work in
>> this release.
>>
>>
>> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>>>
>>> Indeed. The problem is that many folks might have cabal config files that
>>> explicitly disable shared.  (For the compile times!).  They might need clear
>>> information about wiping that field.
>>>
>>>
>>> On Sunday, February 9, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:
>>>>
>>>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com> wrote:
>>>>>
>>>>> Is --enable-shared off by default?
>>>>
>>>> It's supposed to be on by default in 7.8. That said, not sure how many
>>>> people have played with ~/.cabal/config....
>>>>
>>>> --
>>>> brandon s allbery kf8nh                               sine nomine
>>>> associates
>>>> allbery.b at gmail.com
>>>> ballbery at sinenomine.net
>>>> unix, openafs, kerberos, infrastructure, xmonad
>>>> http://sinenomine.net
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From petersen at fedoraproject.org  Mon Feb 10 01:49:49 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Mon, 10 Feb 2014 10:49:49 +0900
Subject: RHEL/EPEL 5 ghc packages
Message-ID: <CAEDGBqKGB9W7iPSPAuqYf5fDKOHaAYi=+hbhHky-9FKAXyQZ3Q@mail.gmail.com>

Hi,

I wanted to mention some newer ghc builds I have made for RHEL5.

EPEL5 currently has ghc-6.12.3 in stable, but I have built
ghc-7.0.4 which has been in EPEL5 testing now for over a month.
The update also includes cabal-install.  I am planning to push it to
stable this month but I wanted to mention it first here as a heads-up.

https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5

Please report any problems with this in bugzilla:
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=ghc

Jens

ps Additionally I have a new ghc-7.4.2 repo for EPEL5
(which should also work on RHEL6) and includes haskell-platform:

http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/

which is a backport from Fedora 19.
Please report any problems with this directly to me.

pps Later this year I plan to backport ghc-7.4.2 officially to EPEL6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140210/ff15c241/attachment.html>

From carter.schonwald at gmail.com  Mon Feb 10 02:27:11 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 9 Feb 2014 21:27:11 -0500
Subject: RHEL/EPEL 5 ghc packages
In-Reply-To: <CAEDGBqKGB9W7iPSPAuqYf5fDKOHaAYi=+hbhHky-9FKAXyQZ3Q@mail.gmail.com>
References: <CAEDGBqKGB9W7iPSPAuqYf5fDKOHaAYi=+hbhHky-9FKAXyQZ3Q@mail.gmail.com>
Message-ID: <CAHYVw0zooPbcnjvV82GAPy4MX0KtKGOw0TOmfHGq3JXqtr2voQ@mail.gmail.com>

please holler if you need help backporting 7.6 and 7.8 please :)


On Sun, Feb 9, 2014 at 8:49 PM, Jens Petersen <petersen at fedoraproject.org>wrote:

> Hi,
>
> I wanted to mention some newer ghc builds I have made for RHEL5.
>
> EPEL5 currently has ghc-6.12.3 in stable, but I have built
> ghc-7.0.4 which has been in EPEL5 testing now for over a month.
> The update also includes cabal-install.  I am planning to push it to
> stable this month but I wanted to mention it first here as a heads-up.
>
>
> https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5
>
> Please report any problems with this in bugzilla:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=ghc
>
> Jens
>
> ps Additionally I have a new ghc-7.4.2 repo for EPEL5
> (which should also work on RHEL6) and includes haskell-platform:
>
> http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/
>
> which is a backport from Fedora 19.
> Please report any problems with this directly to me.
>
> pps Later this year I plan to backport ghc-7.4.2 officially to EPEL6.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140209/71ab78df/attachment.html>

From petersen at fedoraproject.org  Mon Feb 10 05:19:20 2014
From: petersen at fedoraproject.org (Jens Petersen)
Date: Mon, 10 Feb 2014 00:19:20 -0500 (EST)
Subject: RHEL/EPEL 5 ghc packages
In-Reply-To: <CAHYVw0zooPbcnjvV82GAPy4MX0KtKGOw0TOmfHGq3JXqtr2voQ@mail.gmail.com>
References: <CAEDGBqKGB9W7iPSPAuqYf5fDKOHaAYi=+hbhHky-9FKAXyQZ3Q@mail.gmail.com>
 <CAHYVw0zooPbcnjvV82GAPy4MX0KtKGOw0TOmfHGq3JXqtr2voQ@mail.gmail.com>
Message-ID: <2141476979.781693.1392009560426.JavaMail.zimbra@redhat.com>

> please holler if you need help backporting 7.6 and 7.8 please :)

It would be good to have repos for those too, I agree. 

What I would like to do in the future is to use Software Collections [1] 
to provide multiple versions of ghc, etc for RHEL in particular. 
With RHEL's long lifetime, providing just a single version of ghc 
seems inadequate. This should provide more flexibility and 
allow people to choose whether they want to use new ghc 
or to stick with an older version, or both. :) 

[1] https://fedorahosted.org/SoftwareCollections/ 
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/ 

> > https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5
> 

> > http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140210/117e276c/attachment.html>

From austin at well-typed.com  Tue Feb 11 03:56:00 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 10 Feb 2014 21:56:00 -0600
Subject: target audience for the binary distribution
In-Reply-To: <1391884416819-5743588.post@n5.nabble.com>
References: <1391884416819-5743588.post@n5.nabble.com>
Message-ID: <CAEs96n0XmVbDMHevmj5p9z4HAce6cXaxjXvu98uGOsrLQ05ThA@mail.gmail.com>

I asked on the mailing list a few days prior to RC1 if anyone was
interested in a binary build based on an older glibc distribution
(e.g. CentOS.) Nobody replied, so I didn't bother building it. I also
accidentally had RC1 use glibc_2.15, when it should have been 2.13
(Debian stable version.)

I think having a version for RHEL and Debian is a reasonable request,
and it's entirely valid to ask for it. Primarily because glibc & gmp
are undoubtly the two dependencies we have which are most likely to be
different across various distributions.

But, I don't use RHEL products. Can you please specifically tell me
what you're looking for? CentOS 6.5 apparently ships with glibc 2.12 -
is this acceptable, or how far back do we need to turn the wheel? And
it's not unheard of that GHC has hit bugs in older versions of
binutils or associated projects. So hopefully we're not talking CentOS
5.4 or something here (which is still on support, as far as I know.)

On Sat, Feb 8, 2014 at 12:33 PM, harry <voldermort at hotmail.com> wrote:
> I'm unable to install the binary distribution of 7.8.1 on RHEL because it
> requires libgmp.so.10 and GLIBC_2.15, which are much greater than the
> version available on Red Hat. (I'm on a shared system without root access,
> so upgrading libc is out of the question, even if it could be done.) If this
> is what most users would like, I certainly don't want to be the Luddite
> trying to hold them back.
>
> Who actually are "most users" for the bindist? Debian & derivatives have the
> latest GHC in the package repository, so it's presumably Red Hat & Co, and
> people without root. If the bindist is only relevant to rootless users on a
> modern Debian derived distro, is it targeting the right audience?
>
>
>
> --
> View this message in context: http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From voldermort at hotmail.com  Tue Feb 11 05:25:52 2014
From: voldermort at hotmail.com (harry)
Date: Mon, 10 Feb 2014 21:25:52 -0800 (PST)
Subject: target audience for the binary distribution
In-Reply-To: <CAEs96n0XmVbDMHevmj5p9z4HAce6cXaxjXvu98uGOsrLQ05ThA@mail.gmail.com>
References: <1391884416819-5743588.post@n5.nabble.com>
 <CAEs96n0XmVbDMHevmj5p9z4HAce6cXaxjXvu98uGOsrLQ05ThA@mail.gmail.com>
Message-ID: <1392096352313-5743762.post@n5.nabble.com>

Something that works on CentOS 6.5 would be much appreciated, thank you.



--
View this message in context: http://haskell.1045720.n5.nabble.com/target-audience-for-the-binary-distribution-tp5743588p5743762.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From jpm at cs.uu.nl  Thu Feb 13 09:28:08 2014
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Thu, 13 Feb 2014 09:28:08 +0000
Subject: Functional dependencies can "return" kinds, type families cannot
Message-ID: <CA+ZFbn8ShRBS9d7fvyc7pUjUn-zsqZHLBmcbZKmoUiAhpN=+-g@mail.gmail.com>

Hello,

Maybe this is well known already (or maybe it's a bug), but lately I've
again found that functional
dependencies are more versatile than type families. In particular, they can
be used to compute
kinds from types, whereas type families cannot. Consider the code below,
which implements a
class for generic (working for types other than lists) map:

{-# LANGUAGE DataKinds                  #-}
{-# LANGUAGE PolyKinds                  #-}
{-# LANGUAGE TypeFamilies               #-}
{-# LANGUAGE GADTs                      #-}
{-# LANGUAGE FlexibleInstances          #-}
{-# LANGUAGE ScopedTypeVariables        #-}
{-# LANGUAGE TypeOperators              #-}
{-# LANGUAGE MultiParamTypeClasses      #-}
{-# LANGUAGE FunctionalDependencies     #-}

module MapN where

-- (Type-level) Peano naturals
data Nat = Ze | Su Nat

-- Proxy
data Proxy t = Proxy

-- Singleton type for promoted lists
data SList (l :: [*]) where
  SNil  :: SList '[]
  SCons :: h -> SList t -> SList (h ': t)

-- Apply a type to a list of variables
type family AppVars (t :: k) (vs :: [*]) :: *
type instance AppVars t '[]       = t
type instance AppVars t (v ': vs) = AppVars (t v) vs

-- Domains of a list of functions
type family Doms (funs :: [*]) :: [*]
type instance Doms '[]              = '[]
type instance Doms ((a -> b) ': ts) = a ': Doms ts

-- Codomains of a list of functions
type family CoDoms (funs :: [*]) :: [*]
type instance CoDoms '[]              = '[]
type instance CoDoms ((a -> b) ': ts) = b ': CoDoms ts

-- Generalised map
-- How can I get rid of the FD below? I know how to do so by using a proxy
-- argument of type |Proxy t|, but I don't want an extra argument. The usual
-- trick of replacing the FD by a TF doesn't work here because the TF would
have
-- to return a *kind*, not a type.
class GMap (t :: k) (fs :: [*]) | fs -> k where
  gmap :: SList fs -> AppVars t (Doms fs) -> AppVars t (CoDoms fs)

-- List instance
instance GMap [] '[a -> b] where
  gmap _                 []    = []
  -- The line below does not typecheck without the above FD
  gmap fs@(SCons f SNil) (h:t) = f h : (gmap fs t)

The most interesting part here is the functional dependency fs -> k,
where kis a kind variable!
If this is not a bug (and it does seem to work as I expect it to), then
could we have type families
return kinds too?...


Cheers,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140213/dcca1e55/attachment.html>

From Christian.Maeder at dfki.de  Thu Feb 13 13:01:03 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 13 Feb 2014 14:01:03 +0100
Subject: [Solaris bindist] ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAHnG2Cw64v5HFAoc0_iG1eeK7ku0A=NWQ_o-YGQUXqohpGx0GA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>	<52F258B2.8090305@dfki.de>	<52F2BE76.2000409@centrum.cz>	<52F356FC.5010808@dfki.de>	<20B0536D-221E-4A0F-8CA6-334438B71CF3@inconsistent.nl>
 <CAHnG2Cw64v5HFAoc0_iG1eeK7ku0A=NWQ_o-YGQUXqohpGx0GA@mail.gmail.com>
Message-ID: <52FCC20F.2040001@dfki.de>

Am 06.02.2014 15:27, schrieb P?li G?bor J?nos:
> On Thu, Feb 6, 2014 at 1:39 PM, Merijn Verstraaten
> <merijn at inconsistent.nl> wrote:
>>
>> On Feb 6, 2014, at 10:33 , Christian Maeder wrote:
>>> or (as I've seen elsewhere) better (?)
>>>
>>> #!/usr/bin/env bash
>>
>> Definitely use this, FreeBSD (for example) does not ship with bash so /bin/bash will *not* exist.
>
> Please, do not introduce dependency on bash unless it is really necessary.

In fact ./configure detects "/bin/bash" as SHELL under Solaris, so this 
setting could be used (instead of hard coding "bin/sh")!

(Under FreeBSD a proper other SHELL might be found by ./configure.)

Many configure files of libraries also set SHELL this way.

Yet, for this ghc-pwd-bindist script it is easier to make the script 
(Bourne) /bin/sh compatible. Yet, I have not found out, how this script 
is created!

utils/ghc-pwd/ghc.mk contains
"utils/ghc-pwd_dist-install_WANT_BINDIST_WRAPPER = YES"
but then I'm lost what build-prog does from rules/build-prog.mk.

Maybe somehow the code in
libraries/Cabal/Cabal/Distribution/Simple/Program/Script.hs is called, 
then the second line should be changed from:

     setEnv (var, Nothing)  = ["unset " ++ var, "export " ++ var]
     setEnv (var, Just val) = ["export " ++ var ++ "=" ++ quote val]
to:
     setEnv (var, Nothing)  = ["unset " ++ var, "export " ++ var]
     setEnv (var, Just val) = [var ++ "=" ++ quote val, "export " ++ var]

I guess that is still POSIX compliant.

Cheers Christian


From Christian.Maeder at dfki.de  Thu Feb 13 13:22:04 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 13 Feb 2014 14:22:04 +0100
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
Message-ID: <52FCC6FC.6090704@dfki.de>

Hi,

with ghc-7.8.20140130 I get the compilation error:

     Not in scope: type constructor or class ?Typeable2?
     Perhaps you meant ?Typeable? (imported from Data.Typeable)

What is the recommend way to adjust my code or my dependencies?

Cheers Christian

Am 03.02.2014 23:35, schrieb Austin Seipp:
> We are pleased to announce the first release candidate for GHC 7.8.1:
>
>      http://www.haskell.org/ghc/dist/7.8.1-rc1/
>      http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>
> This includes the source tarball and bindists for Windows, Linux, OS
> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
> the SHA256 hashes available (attached) using my GPG key (keyid
> 0x3B58D86F).
>
> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> some existing issues.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>


From difrumin at gmail.com  Thu Feb 13 14:36:42 2014
From: difrumin at gmail.com (Daniil Frumin)
Date: Thu, 13 Feb 2014 18:36:42 +0400
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52FCC6FC.6090704@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52FCC6FC.6090704@dfki.de>
Message-ID: <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>

I think that the preferred solution is to get rid of the custom
Typeable(2) instances and just derive Typeable

On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
<Christian.Maeder at dfki.de> wrote:
> Hi,
>
> with ghc-7.8.20140130 I get the compilation error:
>
>     Not in scope: type constructor or class 'Typeable2'
>     Perhaps you meant 'Typeable' (imported from Data.Typeable)
>
> What is the recommend way to adjust my code or my dependencies?
>
> Cheers Christian
>
> Am 03.02.2014 23:35, schrieb Austin Seipp:
>>
>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>
>>      http://www.haskell.org/ghc/dist/7.8.1-rc1/
>>      http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>
>> This includes the source tarball and bindists for Windows, Linux, OS
>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>> the SHA256 hashes available (attached) using my GPG key (keyid
>> 0x3B58D86F).
>>
>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>> some existing issues.
>>
>> Please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
Sincerely yours,
-- Daniil

From eir at cis.upenn.edu  Thu Feb 13 23:28:58 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 13 Feb 2014 18:28:58 -0500
Subject: Functional dependencies can "return" kinds, type families cannot
In-Reply-To: <CA+ZFbn8ShRBS9d7fvyc7pUjUn-zsqZHLBmcbZKmoUiAhpN=+-g@mail.gmail.com>
References: <CA+ZFbn8ShRBS9d7fvyc7pUjUn-zsqZHLBmcbZKmoUiAhpN=+-g@mail.gmail.com>
Message-ID: <7A7F4017-7D01-4587-82B1-DB559B96CB89@cis.upenn.edu>


On Feb 13, 2014, at 4:28 AM, Jos? Pedro Magalh?es <jpm at cs.uu.nl> wrote:

> 
> The most interesting part here is the functional dependency fs -> k, where k is a kind variable!
> If this is not a bug (and it does seem to work as I expect it to), then could we have type families
> return kinds too?...

Yes, I ran into this a while ago. A function dependency on a kind seems to work remarkably well.

Can we have type families that return kinds? No. Well, not yet. Functional dependencies inform type inference but don't produce any evidence in Core -- a dependency is only ever used to eliminate ambiguity. On the other hand, a type family does produce evidence (in the form of a type coercion) in Core, and kind coercions turn out to be challenging. How challenging? See "System FC with Explicit Kind Equality", ICFP '13 (http://www.cis.upenn.edu/~eir/papers/2013/fckinds/fckinds-extended.pdf)

How does this difference between fundeps and type families manifest itself? Type families work much better with GADTs. I don't have an example to hand, but if you're doing GADT programming, using fundeps won't get you very far. That's because the GADTs use the Core coercions internally... and the fundeps don't produce them.

Nevertheless, having done the theory behind a Core language with explicit kind coercions, I'm now in the midst of implementing (on a branch -- don't expect anything soon!) type inference for that Core language. In effect, it would be the resolution of GHC bug #7961 (https://ghc.haskell.org/trac/ghc/ticket/7961), but with fairly far-reaching consequences in the implementation. So, if all goes well, we'll have type families returning kinds at some point in the not-too-distant future.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140213/c2ffbccb/attachment.html>

From Christian.Maeder at dfki.de  Fri Feb 14 15:37:05 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri, 14 Feb 2014 16:37:05 +0100
Subject: [Solaris bindist] ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <52FCC20F.2040001@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>	<52F258B2.8090305@dfki.de>	<52F2BE76.2000409@centrum.cz>	<52F356FC.5010808@dfki.de>	<20B0536D-221E-4A0F-8CA6-334438B71CF3@inconsistent.nl>
 <CAHnG2Cw64v5HFAoc0_iG1eeK7ku0A=NWQ_o-YGQUXqohpGx0GA@mail.gmail.com>
 <52FCC20F.2040001@dfki.de>
Message-ID: <52FE3821.4080309@dfki.de>

see https://ghc.haskell.org/trac/ghc/ticket/8783 how this issue may be 
solved. Any (or both) of the two proposed patches work for me.

C.

Am 13.02.2014 14:01, schrieb Christian Maeder:
> Am 06.02.2014 15:27, schrieb P?li G?bor J?nos:
>> On Thu, Feb 6, 2014 at 1:39 PM, Merijn Verstraaten
>> <merijn at inconsistent.nl> wrote:
>>>
>>> On Feb 6, 2014, at 10:33 , Christian Maeder wrote:
>>>> or (as I've seen elsewhere) better (?)
>>>>
>>>> #!/usr/bin/env bash
>>>
>>> Definitely use this, FreeBSD (for example) does not ship with bash so
>>> /bin/bash will *not* exist.
>>
>> Please, do not introduce dependency on bash unless it is really
>> necessary.
>
> In fact ./configure detects "/bin/bash" as SHELL under Solaris, so this
> setting could be used (instead of hard coding "bin/sh")!
>
> (Under FreeBSD a proper other SHELL might be found by ./configure.)
>
> Many configure files of libraries also set SHELL this way.
>
> Yet, for this ghc-pwd-bindist script it is easier to make the script
> (Bourne) /bin/sh compatible. Yet, I have not found out, how this script
> is created!
>
> utils/ghc-pwd/ghc.mk contains
> "utils/ghc-pwd_dist-install_WANT_BINDIST_WRAPPER = YES"
> but then I'm lost what build-prog does from rules/build-prog.mk.
>
> Maybe somehow the code in
> libraries/Cabal/Cabal/Distribution/Simple/Program/Script.hs is called,
> then the second line should be changed from:
>
>      setEnv (var, Nothing)  = ["unset " ++ var, "export " ++ var]
>      setEnv (var, Just val) = ["export " ++ var ++ "=" ++ quote val]
> to:
>      setEnv (var, Nothing)  = ["unset " ++ var, "export " ++ var]
>      setEnv (var, Just val) = [var ++ "=" ++ quote val, "export " ++ var]
>
> I guess that is still POSIX compliant.
>
> Cheers Christian
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>


From jan.stolarek at p.lodz.pl  Mon Feb 17 09:46:06 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 17 Feb 2014 10:46:06 +0100
Subject: 7.8.1-candidate fail
In-Reply-To: <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
 <201402062150.55164.jan.stolarek@p.lodz.pl>
 <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>
Message-ID: <201402171046.07052.jan.stolarek@p.lodz.pl>

Thanks. I upgraded Squeeze to Wheezy recently just because of that issue, so it's kinda solved for 
me.

Janek

Dnia pi?tek, 14 lutego 2014, Tyler Huffman napisa?:
> I added a comment in the ticket, but it looks like Debian Squeeze is using
> libgmp3-dev 2:4.3.2, which was the same version that I had when I was
> running into this issue.
>
> Using an updated version of libgmp3-dev will fix the issue, but I'm not
> entirely sure if we need to consider supporting the packages in Debian
> Squeeze repository since Debian Wheezy is the new stable distribution, and
> it uses libgmp-dev 2:5.0.5. Someone with more intimate knowledge of GHC
> development might be able to speak on this issue.
>
>
> Regards,
> Tyler Huffman
>
> On Thu, Feb 6, 2014 at 1:50 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > I had the same problem on Debian Squeeze:
> >
> > https://ghc.haskell.org/trac/ghc/ticket/8666
> >
> > What is your distro?
> >
> > CCing ghc-devs.
> >
> > Janek
> >
> > Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> > > Dear GHC team,
> > >
> > > I am trying to test    ghc-7.8.20140130-src.tar.bz2
> > >
> > > I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
> > >
> > > ./configure  looks all right.
> > >
> > > And `make' reports after 40 minutes:
> > >
> > > -------------------------------------------------------
> > > ...
> > > ...
> > > "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> > > -optc-I'/home/mechvel/g.....
> > > ...
> > > ...
> > > /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> > > R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> > > object; recompile with -fPIC
> > > libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad
> > > value collect2: ld returned 1 exit status
> > > make[1]: ***
> > > [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> > > -ghc7.8.20140130.so] Error 1
> > > -------------------------------------------------------
> > >
> > >
> > > What might this mean? Need I to install a fresher  libgmp ?
> > >
> > > Thanks,
> > >
> > > ------
> > > Sergei
> > >
> > > _______________________________________________
> > > Glasgow-haskell-users mailing list
> > > Glasgow-haskell-users at haskell.org
> > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs



From marlowsd at gmail.com  Mon Feb 17 10:07:05 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 17 Feb 2014 10:07:05 +0000
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
 <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>
Message-ID: <5301DF49.6090807@gmail.com>

I think you can summarise all that with "tl;dr the right thing will 
happen, you don't have to remember to give any new flags to GHC or Cabal".

Cheers,
Simon

On 09/02/2014 21:14, Austin Seipp wrote:
> Actually, just to keep it even simpler, so nobody else is confused
> further: Cabal will *also* properly turn on dynamic builds for regular
> packages if GHC is dynamic, TemplateHaskell or not. So any library you
> compile will still work in GHCi as expected.
>
> So here's the breakdown:
>
>    1) Cabal 1.18 will handle dynamical GHCi correctly, including
> compiling things dynamically, however it must.
>    2) Per #1, libraries are compiled dynamically. This means libraries
> work in GHCi, just like they did.
>    3) -Executables- are statically linked by default, still. (But
> because of #1 and #2, it's very easy to turn on dynamic exes as well,
> without needing to recompile a lot.)
>    4) TemplateHaskell works as expected due to #1 and #2. But there is
> one caveat for executables, noted separately below.
>
> The caveat with TemplateHaskell is for executables: This is because if
> you end up with an executable that needs TH and profiling, Cabal must
> be aware of this. Why? Because GHCi cannot load *profiled* objects,
> only normal ones. So we must compile twice: once without profiling,
> and once with profiling. The second compilation will use the 'normal'
> objects, even though the final executable will be profiled. Cabal
> doesn't know to do this if it doesn't know TemplateHaskell is a
> requirement.
>
> Does this clear things up? My last message might give the impression
> some things aren't compiled dynamically, because I merely ambiguously
> referred to 'packages'.
>
> On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp <austin at well-typed.com> wrote:
>> It is correct that Template Haskell now requires dynamic objects.
>> However, GHC can produce static and dynamic objects at the same time,
>> so you don't have to recompile a package twice (it's a big
>> optimization, basically).
>>
>> Furthermore, if TemplateHaskell is enabled as a requirement for a
>> package, and GHC is built dynamically, Cabal will do The Right Thing
>> by building the shared objects for the dependencies as well. It will
>> save time by doing so using -dynamic-too, if possible. This is because
>> it queries GHC before compilation to figure this out (you can run 'ghc
>> --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports
>> dynamic-too" fields.)
>>
>> Finally, if you simply run 'ghc Foo.hs' on a file that requires
>> TemplateHaskell, it will also switch on -dynamic-too for the needed
>> objects in this simple case.
>>
>> There is one caveat, if I remember correctly: if a package uses
>> TemplateHaskell, it must declare it as such in the Cabal file. This is
>> because Cabal does not parse the source to detect if TemplateHaskell
>> is needed in the dependency graph of the compiled modules. Only GHC
>> can do this reliably. If you don't specify TemplateHaskell as an
>> extension, Cabal might not do the right thing. This is noted in the
>> release notes:
>>
>>> Note that Cabal will correctly handle -dynamic-too for you automatically, especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are using the TemplateHaskell extension.
>>
>> However, based on the other suggestions in the thread and confusion
>> around this, a big "Incompatible changes" section with this listed as
>> the first thing with clear detail would be a good idea. I'll do so.
>>
>> If something else is going on, please file a bug.
>>
>> On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts
>> <george.colpitts at gmail.com> wrote:
>>> Yes, in general I think the doc needs a section: Incompatible changes. The
>>> hope is that you can take the release and just work as usual but when (for
>>> good reasons as in this release) it is not true is is important to have such
>>> a section. Another case that needs to be there is how to compile so you can
>>> load compile object files into ghci as what you did in 7.6.3 won't work in
>>> this release.
>>>
>>>
>>> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald
>>> <carter.schonwald at gmail.com> wrote:
>>>>
>>>> Indeed. The problem is that many folks might have cabal config files that
>>>> explicitly disable shared.  (For the compile times!).  They might need clear
>>>> information about wiping that field.
>>>>
>>>>
>>>> On Sunday, February 9, 2014, Brandon Allbery <allbery.b at gmail.com> wrote:
>>>>>
>>>>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn <gregmainland at gmail.com> wrote:
>>>>>>
>>>>>> Is --enable-shared off by default?
>>>>>
>>>>> It's supposed to be on by default in 7.8. That said, not sure how many
>>>>> people have played with ~/.cabal/config....
>>>>>
>>>>> --
>>>>> brandon s allbery kf8nh                               sine nomine
>>>>> associates
>>>>> allbery.b at gmail.com
>>>>> ballbery at sinenomine.net
>>>>> unix, openafs, kerberos, infrastructure, xmonad
>>>>> http://sinenomine.net
>>>>
>>>>
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>
>
>

From mechvel at botik.ru  Mon Feb 17 16:52:32 2014
From: mechvel at botik.ru (Sergei Meshveliani)
Date: Mon, 17 Feb 2014 20:52:32 +0400
Subject: 7.8.1-candidate fail
In-Reply-To: <201402171046.07052.jan.stolarek@p.lodz.pl>
References: <1391717159.13808.11.camel@one.mechvel.pereslavl.ru>
 <201402062150.55164.jan.stolarek@p.lodz.pl>
 <CAMYb46AzG=LfLnMZ_VfKA9VwC7D3OewOp9JF8TxOakCBhNhTYg@mail.gmail.com>
 <201402171046.07052.jan.stolarek@p.lodz.pl>
Message-ID: <1392655952.2318.24.camel@one.mechvel.pereslavl.ru>

I have another machine, which is under Wheezy. 
And there
* ghc-7.6.3  has made successfully  ghc-7.8.20140130  from source,
* ghc-7.8.20140130  cannot make itself from source, reporting 

-------------------
...
Configuring ghc-7.8.20140130...
ghc-cabal: The following installed packages are broken because other
packages they depend on are missing. These broken packages must be
rebuilt before they can be used.
package Cabal-1.18.1.3 is broken due to missing package
array-0.4.0.1-3b78425c10ff2dad7acf7e8c8ae014c3,
base-4.6.0.1-8aa5d403c45ea59dcd2c39f123e27d57
...
...
-------------------

I am sorry, I understand very few in the installation techniques, nor in
the system matters. May I, please, ask the following question?  

Does the above situation mean that 
(1) the GHC `maker' has Cabal inside it
    (or it calls for Cabal which needs to be in the System?)
(2) ghc-7.8.20140130  has a higher Cabal version than ghc-7.6.3,
(3) this higher Cabal version needs different packages than Cabal in  
    ghc-7.6.3
? 

Thanks,

------
Sergei




On Mon, 2014-02-17 at 10:46 +0100, Jan Stolarek wrote:
> Thanks. I upgraded Squeeze to Wheezy recently just because of that issue, so it's kinda solved for 
> me.
> 
> Janek
> 
> Dnia pi?tek, 14 lutego 2014, Tyler Huffman napisa?:
> > I added a comment in the ticket, but it looks like Debian Squeeze is using
> > libgmp3-dev 2:4.3.2, which was the same version that I had when I was
> > running into this issue.
> >
> > Using an updated version of libgmp3-dev will fix the issue, but I'm not
> > entirely sure if we need to consider supporting the packages in Debian
> > Squeeze repository since Debian Wheezy is the new stable distribution, and
> > it uses libgmp-dev 2:5.0.5. Someone with more intimate knowledge of GHC
> > development might be able to speak on this issue.
> >
> >
> > Regards,
> > Tyler Huffman
> >
> > On Thu, Feb 6, 2014 at 1:50 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> > > I had the same problem on Debian Squeeze:
> > >
> > > https://ghc.haskell.org/trac/ghc/ticket/8666
> > >
> > > What is your distro?
> > >
> > > CCing ghc-devs.
> > >
> > > Janek
> > >
> > > Dnia czwartek, 6 lutego 2014, Sergei Meshveliani napisa?:
> > > > Dear GHC team,
> > > >
> > > > I am trying to test    ghc-7.8.20140130-src.tar.bz2
> > > >
> > > > I make it from source with   ghc-7.6.3  on Debian Linux (64 bit).
> > > >
> > > > ./configure  looks all right.
> > > >
> > > > And `make' reports after 40 minutes:
> > > >
> > > > -------------------------------------------------------
> > > > ...
> > > > ...
> > > > "inplace/bin/ghc-stage1" -optc-Ilibraries/integer-gmp/.
> > > > -optc-I'/home/mechvel/g.....
> > > > ...
> > > > ...
> > > > /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation
> > > > R_X86_64_32 against `__gmpz_sub' can not be used when making a shared
> > > > object; recompile with -fPIC
> > > > libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad
> > > > value collect2: ld returned 1 exit status
> > > > make[1]: ***
> > > > [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0\
> > > > -ghc7.8.20140130.so] Error 1
> > > > -------------------------------------------------------
> > > >
> > > >
> > > > What might this mean? Need I to install a fresher  libgmp ?
> > > >
> > > > Thanks,
> > > >
> > > > ------
> > > > Sergei
> > > >
> > > > _______________________________________________
> > > > Glasgow-haskell-users mailing list
> > > > Glasgow-haskell-users at haskell.org
> > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> > >
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



From nomeata at debian.org  Tue Feb 18 22:22:13 2014
From: nomeata at debian.org (Joachim Breitner)
Date: Tue, 18 Feb 2014 22:22:13 +0000
Subject: ghc-7.8.1 and stm
In-Reply-To: <CAJN_RF5m3NWkUTPgWj6VLEHCpNndq_UxH-CNNs_uvnQu4CMiow@mail.gmail.com>
References: <CAJN_RF5m3NWkUTPgWj6VLEHCpNndq_UxH-CNNs_uvnQu4CMiow@mail.gmail.com>
Message-ID: <1392762133.30243.1.camel@kirk>

Hi David,

Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox:
> It seems to me that the stm library that is supposed to be built into
> ghc-7.8.1 is missing.  The deb provides and conflicts with
> libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde.

this seems to be the result of a possible inadvertent change in the GHC
source tarball creation: stm had been a "extra" lib already in 7.6 and
before, but was not part of the tarball.

Herbert or Austin, is the sdist code not doing the right thing here?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140218/0c0146ce/attachment.sig>

From carter.schonwald at gmail.com  Tue Feb 18 23:23:45 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 18 Feb 2014 18:23:45 -0500
Subject: ghc-7.8.1 and stm
In-Reply-To: <1392762133.30243.1.camel@kirk>
References: <CAJN_RF5m3NWkUTPgWj6VLEHCpNndq_UxH-CNNs_uvnQu4CMiow@mail.gmail.com>
 <1392762133.30243.1.camel@kirk>
Message-ID: <CAHYVw0yJgcxJF=DvwPGcsWs6DGE8kMQFqyNS95W0uYNOy+Uk-Q@mail.gmail.com>

Huh.  I've just been assuming STM is a user land lib! Been installing it
from hackage...

On Tuesday, February 18, 2014, Joachim Breitner <nomeata at debian.org> wrote:

> Hi David,
>
> Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox:
> > It seems to me that the stm library that is supposed to be built into
> > ghc-7.8.1 is missing.  The deb provides and conflicts with
> > libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde.
>
> this seems to be the result of a possible inadvertent change in the GHC
> source tarball creation: stm had been a "extra" lib already in 7.6 and
> before, but was not part of the tarball.
>
> Herbert or Austin, is the sdist code not doing the right thing here?
>
> Greetings,
> Joachim
>
> --
> Joachim "nomeata" Breitner
> Debian Developer
>   nomeata at debian.org <javascript:;> | ICQ# 74513189 | GPG-Keyid: 4743206C
>   JID: nomeata at joachim-breitner.de <javascript:;> |
> http://people.debian.org/~nomeata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140218/bcfc4955/attachment.html>

From trebla at vex.net  Wed Feb 19 02:48:55 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Tue, 18 Feb 2014 21:48:55 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <5301DF49.6090807@gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
 <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>
 <5301DF49.6090807@gmail.com>
Message-ID: <53041B97.30500@vex.net>

The new dynamism is pretty nice! I even used GHC 7.6.3 to build 
cabal-install 1.18, then played with PATH so that when I said "cabal 
install mtl" it saw GHC 7.8. It correctly added -dynamic-too and built 
both *.a and *.so in one go. This is very user-friendly.

Still, I observed a few oddities.

1. Referring to the user guide section 2.3 "loading compiled code", it 
is now insufficient to "ghc -c D.hs". It has to be "ghc -c -dynamic D.hs".

Perhaps more importantly, "ghc -c -dynamic-too D.hs" is also 
insufficient. Apparently, while TemplateHaskell considers both *.hi and 
*.dyn_hi, :load considers *.hi only.

2. My experiment began with just QuasiQuote. QuasiQuote needs as much 
dynamism as TemplateHaskell. Yet, QuasiQuote does not trigger a nice 
implicit -dynamic-too, unlike TemplateHaskell.


From carter.schonwald at gmail.com  Wed Feb 19 03:44:43 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 18 Feb 2014 22:44:43 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <53041B97.30500@vex.net>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
 <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>
 <5301DF49.6090807@gmail.com> <53041B97.30500@vex.net>
Message-ID: <CAHYVw0yNuG-Ski7RFcueJcmrKbA=gHPXA-+o6+qxeOJM03PgFg@mail.gmail.com>

hey Albert, could you open a ticket on ghc Trac about the QuasiQuot thing?


On Tue, Feb 18, 2014 at 9:48 PM, Albert Y. C. Lai <trebla at vex.net> wrote:

> The new dynamism is pretty nice! I even used GHC 7.6.3 to build
> cabal-install 1.18, then played with PATH so that when I said "cabal
> install mtl" it saw GHC 7.8. It correctly added -dynamic-too and built both
> *.a and *.so in one go. This is very user-friendly.
>
> Still, I observed a few oddities.
>
> 1. Referring to the user guide section 2.3 "loading compiled code", it is
> now insufficient to "ghc -c D.hs". It has to be "ghc -c -dynamic D.hs".
>
> Perhaps more importantly, "ghc -c -dynamic-too D.hs" is also insufficient.
> Apparently, while TemplateHaskell considers both *.hi and *.dyn_hi, :load
> considers *.hi only.
>
> 2. My experiment began with just QuasiQuote. QuasiQuote needs as much
> dynamism as TemplateHaskell. Yet, QuasiQuote does not trigger a nice
> implicit -dynamic-too, unlike TemplateHaskell.
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140218/9ce4e324/attachment.html>

From hvr at gnu.org  Wed Feb 19 10:13:04 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 19 Feb 2014 11:13:04 +0100
Subject: ghc-7.8.1 and stm
In-Reply-To: <1392762133.30243.1.camel@kirk> (Joachim Breitner's message of
 "Tue, 18 Feb 2014 22:22:13 +0000")
References: <CAJN_RF5m3NWkUTPgWj6VLEHCpNndq_UxH-CNNs_uvnQu4CMiow@mail.gmail.com>
 <1392762133.30243.1.camel@kirk>
Message-ID: <8738jftnpr.fsf@gnu.org>

On 2014-02-18 at 23:22:13 +0100, Joachim Breitner wrote:
> Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox:
>> It seems to me that the stm library that is supposed to be built into
>> ghc-7.8.1 is missing.  The deb provides and conflicts with
>> libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde.
>
> this seems to be the result of a possible inadvertent change in the GHC
> source tarball creation: stm had been a "extra" lib already in 7.6 and
> before, but was not part of the tarball.
>
> Herbert or Austin, is the sdist code not doing the right thing here?

Afaics, 'stm' is only used as an "extra" lib by testsuite (and only for
one test-case) and nofib; therefore I don't think the GHC source tarball
is supposed to contain 'stm'...

From mail at joachim-breitner.de  Wed Feb 19 10:20:18 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 19 Feb 2014 10:20:18 +0000
Subject: ghc-7.8.1 and stm
In-Reply-To: <8738jftnpr.fsf@gnu.org>
References: <CAJN_RF5m3NWkUTPgWj6VLEHCpNndq_UxH-CNNs_uvnQu4CMiow@mail.gmail.com>
 <1392762133.30243.1.camel@kirk> <8738jftnpr.fsf@gnu.org>
Message-ID: <1392805218.2521.10.camel@kirk>

Hi,

Am Mittwoch, den 19.02.2014, 11:13 +0100 schrieb Herbert Valerio Riedel:
> On 2014-02-18 at 23:22:13 +0100, Joachim Breitner wrote:
> > Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox:
> >> It seems to me that the stm library that is supposed to be built into
> >> ghc-7.8.1 is missing.  The deb provides and conflicts with
> >> libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde.
> >
> > this seems to be the result of a possible inadvertent change in the GHC
> > source tarball creation: stm had been a "extra" lib already in 7.6 and
> > before, but was not part of the tarball.
> >
> > Herbert or Austin, is the sdist code not doing the right thing here?
> 
> Afaics, 'stm' is only used as an "extra" lib by testsuite (and only for
> one test-case) and nofib; therefore I don't think the GHC source tarball
> is supposed to contain 'stm'...

precisely. So someone needs to remove it. Created
https://ghc.haskell.org/trac/ghc/ticket/8801
so that it is not forgotten.

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140219/eb00d56b/attachment.sig>

From merijn at inconsistent.nl  Wed Feb 19 12:07:25 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Wed, 19 Feb 2014 13:07:25 +0100
Subject: State of -XImpredicativeTypes
Message-ID: <31AA5C38-BA32-4291-AF9B-FA5190E8795B@inconsistent.nl>

Lectori salutem,

What is the actual state of ImpredicativeTypes? It appears documented as a "properly" finished GHC extension, but on IRC and other places I keep hearing it's poorly tested, buggy or incomplete. Is this true or just FUD?

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140219/99f64c14/attachment.sig>

From simonpj at microsoft.com  Wed Feb 19 13:48:24 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 Feb 2014 13:48:24 +0000
Subject: State of -XImpredicativeTypes
In-Reply-To: <31AA5C38-BA32-4291-AF9B-FA5190E8795B@inconsistent.nl>
References: <31AA5C38-BA32-4291-AF9B-FA5190E8795B@inconsistent.nl>
Message-ID: <59543203684B2244980D7E4057D5FBC14879E896@DB3EX14MBXC308.europe.corp.microsoft.com>

ImpredicativeTypes is not properly finished.  When I first implemented it I implemented a fairly ambitious design based on "boxy types" (see paper with that in the title).  But it proved unsustainably complicated, both in the implementation and indeed for programmers to reason about which programs should be accepted and which should not.

So I took most of it out.  There are some vestiges but to a first approximation it isn't really there at all.

My plan is to do something along the lines of QML (again, look at the paper), plus add explicit type application.  But there are always too many other things to do.

This is swampy territory, and I have spent more time on it that I care to tell you without producing a design that I am satisfied with.  So while I would be very happy if someone wants to start helping, you do need a good grasp of type inference first.  It's not a project to learn on.

However the *internal* intermediate language, Core, is fully impredicative and always has been.  No difficulties there.

Simon

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Merijn Verstraaten
| Sent: 19 February 2014 12:07
| To: glasgow-haskell-users at haskell.org
| Subject: State of -XImpredicativeTypes
| 
| Lectori salutem,
| 
| What is the actual state of ImpredicativeTypes? It appears documented as
| a "properly" finished GHC extension, but on IRC and other places I keep
| hearing it's poorly tested, buggy or incomplete. Is this true or just
| FUD?
| 
| Cheers,
| Merijn

From trebla at vex.net  Wed Feb 19 23:37:04 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Wed, 19 Feb 2014 18:37:04 -0500
Subject: 7.8.1, template haskell, and dynamic libraries
In-Reply-To: <CAHYVw0yNuG-Ski7RFcueJcmrKbA=gHPXA-+o6+qxeOJM03PgFg@mail.gmail.com>
References: <1391883870488-5743587.post@n5.nabble.com>
 <CAHYVw0zv73o8+fY9rXqpA8LssXPn4gZQw8qyMVsbNJSdKNke9Q@mail.gmail.com>
 <1391934648414-5743624.post@n5.nabble.com>
 <CAKA2JgJNeoXtnUocr58KYP4-H7yCpkpWsUDdQvSvpoA=RDB5fQ@mail.gmail.com>
 <1391936640650-5743628.post@n5.nabble.com>
 <CAAr-h4s7jy60uLcC8-xazofBzmEodXrqd_nupNVXXoF5O8oiRg@mail.gmail.com>
 <CAKFCL4UBYSY2CHPrq=8i3q0gwOLfAd=HR-O9XoDNG8qci5La-A@mail.gmail.com>
 <CAHYVw0zdRA=PbYK3ANTYYn2vxU7zeAwJzWJdjZuSRDn6tbpqgw@mail.gmail.com>
 <CAB-d4A6XKxHhBsXsbrXP1cn+o2nKA6hDGHVasyp1iHNHB=QOMg@mail.gmail.com>
 <CAEs96n0fhfSNYnsEK__JdRJfxYA7K+ppqdYWm6v2ERWJ2ioTiQ@mail.gmail.com>
 <CAEs96n3sgH1LgLQGCoL+_x1zKmcwT8Cu5+pZ3HVK_VB0NZD-vQ@mail.gmail.com>
 <5301DF49.6090807@gmail.com> <53041B97.30500@vex.net>
 <CAHYVw0yNuG-Ski7RFcueJcmrKbA=gHPXA-+o6+qxeOJM03PgFg@mail.gmail.com>
Message-ID: <53054020.3080601@vex.net>

On 14-02-18 10:44 PM, Carter Schonwald wrote:
> hey Albert, could you open a ticket on ghc Trac about the QuasiQuot thing?

It is now https://ghc.haskell.org/trac/ghc/ticket/8805

From Christian.Maeder at dfki.de  Thu Feb 20 11:30:48 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 20 Feb 2014 12:30:48 +0100
Subject: haskell xml parsing for larger files?
Message-ID: <5305E768.40002@dfki.de>

Hi,

I've got some difficulties parsing "large" xml files (> 100MB).
A plain SAX parser, as provided by hexpat, is fine. However, 
constructing a tree consumes too much memory on a 32bit machine.

see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248

I suspect that sharing strings when constructing trees might greatly 
reduce memory requirements. What are suitable libraries for string pools?

Before trying to implement something myself, I'ld like to ask who else 
has tried to process large xml files (and met similar memory problems)?

I have not yet investigated xml-conduit and hxt for our purpose. (These 
look scary.)

In fact, I've basically used the content trees from "The (simple) xml 
package" and switching to another tree type is no fun, in particular if 
this gains not much.

Thanks Christian

From cdsmith at gmail.com  Thu Feb 20 14:30:35 2014
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 20 Feb 2014 06:30:35 -0800
Subject: haskell xml parsing for larger files?
In-Reply-To: <CAPq5PvJC0MQ33J0VVG4DN19exuipWW3LWH+hFhEBcZpszw-4uw@mail.gmail.com>
References: <5305E768.40002@dfki.de>
 <CAPq5PvJC0MQ33J0VVG4DN19exuipWW3LWH+hFhEBcZpszw-4uw@mail.gmail.com>
Message-ID: <CAPq5Pv+SbCoPYBhH_BC4HGrHcArJHmi9drSn0Y_a8wa+NcM_5A@mail.gmail.com>

Have you looked at tagsoup?
On Feb 20, 2014 3:30 AM, "Christian Maeder" <Christian.Maeder at dfki.de>
wrote:

Hi,

I've got some difficulties parsing "large" xml files (> 100MB).
A plain SAX parser, as provided by hexpat, is fine. However, constructing a
tree consumes too much memory on a 32bit machine.

see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248

I suspect that sharing strings when constructing trees might greatly reduce
memory requirements. What are suitable libraries for string pools?

Before trying to implement something myself, I'ld like to ask who else has
tried to process large xml files (and met similar memory problems)?

I have not yet investigated xml-conduit and hxt for our purpose. (These
look scary.)

In fact, I've basically used the content trees from "The (simple) xml
package" and switching to another tree type is no fun, in particular if
this gains not much.

Thanks Christian
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140220/ffccdae2/attachment.html>

From Christian.Maeder at dfki.de  Thu Feb 20 14:56:59 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 20 Feb 2014 15:56:59 +0100
Subject: haskell xml parsing for larger files?
In-Reply-To: <CAPq5Pv+SbCoPYBhH_BC4HGrHcArJHmi9drSn0Y_a8wa+NcM_5A@mail.gmail.com>
References: <5305E768.40002@dfki.de>	<CAPq5PvJC0MQ33J0VVG4DN19exuipWW3LWH+hFhEBcZpszw-4uw@mail.gmail.com>
 <CAPq5Pv+SbCoPYBhH_BC4HGrHcArJHmi9drSn0Y_a8wa+NcM_5A@mail.gmail.com>
Message-ID: <530617BB.9070500@dfki.de>

I've just tried:

   import Text.HTML.TagSoup
   import Text.HTML.TagSoup.Tree

   main :: IO ()
   main = getContents >>= putStr . renderTags . flattenTree . tagTree . 
parseTags

which also ends with the getMBlock error.
Only "renderTags . parseTags" works fine (like the hexpat SAX parser).

Why should tagsoup be better suited for building trees from large files?

C.

Am 20.02.2014 15:30, schrieb Chris Smith:
> Have you looked at tagsoup?
>
> On Feb 20, 2014 3:30 AM, "Christian Maeder" <Christian.Maeder at dfki.de
> <mailto:Christian.Maeder at dfki.de>> wrote:
>
>     Hi,
>
>     I've got some difficulties parsing "large" xml files (> 100MB).
>     A plain SAX parser, as provided by hexpat, is fine. However,
>     constructing a tree consumes too much memory on a 32bit machine.
>
>     see http://trac.informatik.uni-__bremen.de:8080/hets/ticket/__1248
>     <http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248>
>
>     I suspect that sharing strings when constructing trees might greatly
>     reduce memory requirements. What are suitable libraries for string
>     pools?
>
>     Before trying to implement something myself, I'ld like to ask who
>     else has tried to process large xml files (and met similar memory
>     problems)?
>
>     I have not yet investigated xml-conduit and hxt for our purpose.
>     (These look scary.)
>
>     In fact, I've basically used the content trees from "The (simple)
>     xml package" and switching to another tree type is no fun, in
>     particular if this gains not much.
>
>     Thanks Christian
>     _________________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.__org
>     <mailto:Glasgow-haskell-users at haskell.org>
>     http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
>     <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>


From cdsmith at gmail.com  Thu Feb 20 15:01:50 2014
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 20 Feb 2014 07:01:50 -0800
Subject: haskell xml parsing for larger files?
In-Reply-To: <530617BB.9070500@dfki.de>
References: <5305E768.40002@dfki.de>
 <CAPq5PvJC0MQ33J0VVG4DN19exuipWW3LWH+hFhEBcZpszw-4uw@mail.gmail.com>
 <CAPq5Pv+SbCoPYBhH_BC4HGrHcArJHmi9drSn0Y_a8wa+NcM_5A@mail.gmail.com>
 <530617BB.9070500@dfki.de>
Message-ID: <CAPq5Pv+xE4Bg95c93+CEXeK8kJ-SWXVA9M5cLzkX6tAszY-Q8Q@mail.gmail.com>

Ah, I'd misunderstood your question, and thought you were looking for a
sax-like alternative.
On Feb 20, 2014 6:57 AM, "Christian Maeder" <Christian.Maeder at dfki.de>
wrote:

> I've just tried:
>
>   import Text.HTML.TagSoup
>   import Text.HTML.TagSoup.Tree
>
>   main :: IO ()
>   main = getContents >>= putStr . renderTags . flattenTree . tagTree .
> parseTags
>
> which also ends with the getMBlock error.
> Only "renderTags . parseTags" works fine (like the hexpat SAX parser).
>
> Why should tagsoup be better suited for building trees from large files?
>
> C.
>
> Am 20.02.2014 15:30, schrieb Chris Smith:
>
>> Have you looked at tagsoup?
>>
>> On Feb 20, 2014 3:30 AM, "Christian Maeder" <Christian.Maeder at dfki.de
>> <mailto:Christian.Maeder at dfki.de>> wrote:
>>
>>     Hi,
>>
>>     I've got some difficulties parsing "large" xml files (> 100MB).
>>     A plain SAX parser, as provided by hexpat, is fine. However,
>>     constructing a tree consumes too much memory on a 32bit machine.
>>
>>     see http://trac.informatik.uni-__bremen.de:8080/hets/ticket/__1248
>>     <http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248>
>>
>>     I suspect that sharing strings when constructing trees might greatly
>>     reduce memory requirements. What are suitable libraries for string
>>     pools?
>>
>>     Before trying to implement something myself, I'ld like to ask who
>>     else has tried to process large xml files (and met similar memory
>>     problems)?
>>
>>     I have not yet investigated xml-conduit and hxt for our purpose.
>>     (These look scary.)
>>
>>     In fact, I've basically used the content trees from "The (simple)
>>     xml package" and switching to another tree type is no fun, in
>>     particular if this gains not much.
>>
>>     Thanks Christian
>>     _________________________________________________
>>     Glasgow-haskell-users mailing list
>>     Glasgow-haskell-users at haskell.__org
>>     <mailto:Glasgow-haskell-users at haskell.org>
>>     http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
>>     <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140220/8141cd36/attachment.html>

From m at tweag.io  Thu Feb 20 15:06:10 2014
From: m at tweag.io (Mathieu Boespflug)
Date: Thu, 20 Feb 2014 16:06:10 +0100
Subject: haskell xml parsing for larger files?
In-Reply-To: <5305E768.40002@dfki.de>
References: <5305E768.40002@dfki.de>
Message-ID: <CAJ0eudr6j-_zqQC2L2hnGp=qUm5Dn3D3fe1VvnJppqYFOjqV=Q@mail.gmail.com>

Hi Christian,

as regards your question about sharing strings, there are a number of
libraries on Hackage to achieve this, e.g. in the context of compiler
symbols. To cite only a few: intern, stringtable-atom, simple-atom.
I'm sure there are others.

Best,
--
Mathieu Boespflug
Founder at http://tweag.io.


On Thu, Feb 20, 2014 at 12:30 PM, Christian Maeder
<Christian.Maeder at dfki.de> wrote:
> Hi,
>
> I've got some difficulties parsing "large" xml files (> 100MB).
> A plain SAX parser, as provided by hexpat, is fine. However, constructing a
> tree consumes too much memory on a 32bit machine.
>
> see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248
>
> I suspect that sharing strings when constructing trees might greatly reduce
> memory requirements. What are suitable libraries for string pools?
>
> Before trying to implement something myself, I'ld like to ask who else has
> tried to process large xml files (and met similar memory problems)?
>
> I have not yet investigated xml-conduit and hxt for our purpose. (These look
> scary.)
>
> In fact, I've basically used the content trees from "The (simple) xml
> package" and switching to another tree type is no fun, in particular if this
> gains not much.
>
> Thanks Christian
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From malcolm.wallace at me.com  Thu Feb 20 15:49:21 2014
From: malcolm.wallace at me.com (malcolm.wallace)
Date: Thu, 20 Feb 2014 15:49:21 +0000 (GMT)
Subject: haskell xml parsing for larger files?
In-Reply-To: <5305E768.40002@dfki.de>
Message-ID: <a6d97430-b1ec-47fd-b7be-85a40779a02b@me.com>

Is your usage pattern over the constructed tree likely to be a lazy prefix traversal? ?If so, then HaXml supports lazy construction of the parse tree. ?Some plots?appear at the end of this paper,?showing how memory usage can be reduced to a constant, even for very large inputs (1 million tree nodes):

http://www.cs.york.ac.uk/plasma/publications/pdf/partialparse.pdf
Regards,
    Malcolm

On 20 Feb, 2014,at 11:30 AM, Christian Maeder <Christian.Maeder at dfki.de> wrote:

Hi,

I've got some difficulties parsing "large" xml files (> 100MB).
A plain SAX parser, as provided by hexpat, is fine. However, 
constructing a tree consumes too much memory on a 32bit machine.

see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248

I suspect that sharing strings when constructing trees might greatly 
reduce memory requirements. What are suitable libraries for string pools?

Before trying to implement something myself, I'ld like to ask who else 
has tried to process large xml files (and met similar memory problems)?

I have not yet investigated xml-conduit and hxt for our purpose. (These 
look scary.)

In fact, I've basically used the content trees from "The (simple) xml 
package" and switching to another tree type is no fun, in particular if 
this gains not much.

Thanks Christian
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140220/afde4e92/attachment.html>

From Christian.Maeder at dfki.de  Thu Feb 20 15:51:20 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 20 Feb 2014 16:51:20 +0100
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>	<52FCC6FC.6090704@dfki.de>
 <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>
Message-ID: <53062478.3010104@dfki.de>

Yes, changing Typeable2 to Typeable in:

{-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-}
...
deriving instance Typeable Gr

goes through with ghc-7.8-rc1.

However, this change refuses to compile with ghc-7.6.3:

     Expecting two more arguments to `Gr'
     In the stand-alone deriving instance for `Typeable Gr'

This is unfortunate, because I need to add conditional compilation to 
make my code compilable for the two most recent major versions of GHC.

Can you not simply let ghc-7.8 interpret TypeableN as Typeable?

Cheers Christian

Am 13.02.2014 15:36, schrieb Daniil Frumin:
> I think that the preferred solution is to get rid of the custom
> Typeable(2) instances and just derive Typeable
>
> On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
> <Christian.Maeder at dfki.de> wrote:
>> Hi,
>>
>> with ghc-7.8.20140130 I get the compilation error:
>>
>>      Not in scope: type constructor or class 'Typeable2'
>>      Perhaps you meant 'Typeable' (imported from Data.Typeable)
>>
>> What is the recommend way to adjust my code or my dependencies?
>>
>> Cheers Christian
>>
>> Am 03.02.2014 23:35, schrieb Austin Seipp:
>>>
>>> We are pleased to announce the first release candidate for GHC 7.8.1:
>>>
>>>       http://www.haskell.org/ghc/dist/7.8.1-rc1/
>>>       http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
>>>
>>> This includes the source tarball and bindists for Windows, Linux, OS
>>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of
>>> the SHA256 hashes available (attached) using my GPG key (keyid
>>> 0x3B58D86F).
>>>
>>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
>>> some existing issues.
>>>
>>> Please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>


From simonpj at microsoft.com  Thu Feb 20 16:00:04 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 20 Feb 2014 16:00:04 +0000
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <53062478.3010104@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52FCC6FC.6090704@dfki.de>
 <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>
 <53062478.3010104@dfki.de>
Message-ID: <59543203684B2244980D7E4057D5FBC1487A345A@DB3EX14MBXC308.europe.corp.microsoft.com>

| Can you not simply let ghc-7.8 interpret TypeableN as Typeable?

Not really: ghc-7.8 does still support TypeableN I think (for backward compat reasons).  So it can't take it to mean two different things.

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Christian Maeder
| Sent: 20 February 2014 15:51
| To: Daniil Frumin
| Cc: glasgow-haskell-users at haskell.org
| Subject: Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
| 
| Yes, changing Typeable2 to Typeable in:
| 
| {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} ...
| deriving instance Typeable Gr
| 
| goes through with ghc-7.8-rc1.
| 
| However, this change refuses to compile with ghc-7.6.3:
| 
|      Expecting two more arguments to `Gr'
|      In the stand-alone deriving instance for `Typeable Gr'
| 
| This is unfortunate, because I need to add conditional compilation to
| make my code compilable for the two most recent major versions of GHC.
| 
| Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
| 
| Cheers Christian
| 
| Am 13.02.2014 15:36, schrieb Daniil Frumin:
| > I think that the preferred solution is to get rid of the custom
| > Typeable(2) instances and just derive Typeable
| >
| > On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
| > <Christian.Maeder at dfki.de> wrote:
| >> Hi,
| >>
| >> with ghc-7.8.20140130 I get the compilation error:
| >>
| >>      Not in scope: type constructor or class 'Typeable2'
| >>      Perhaps you meant 'Typeable' (imported from Data.Typeable)
| >>
| >> What is the recommend way to adjust my code or my dependencies?
| >>
| >> Cheers Christian
| >>
| >> Am 03.02.2014 23:35, schrieb Austin Seipp:
| >>>
| >>> We are pleased to announce the first release candidate for GHC
| 7.8.1:
| >>>
| >>>       http://www.haskell.org/ghc/dist/7.8.1-rc1/
| >>>       http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
| >>>
| >>> This includes the source tarball and bindists for Windows, Linux, OS
| >>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy
| >>> of the SHA256 hashes available (attached) using my GPG key (keyid
| >>> 0x3B58D86F).
| >>>
| >>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
| >>> some existing issues.
| >>>
| >>> Please test as much as possible; bugs are much cheaper if we find
| >>> them before the release!
| >>>
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> Glasgow-haskell-users mailing list
| >>> Glasgow-haskell-users at haskell.org
| >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >>>
| >>
| >> _______________________________________________
| >> Glasgow-haskell-users mailing list
| >> Glasgow-haskell-users at haskell.org
| >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >
| >
| >
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From Christian.Maeder at dfki.de  Thu Feb 20 16:02:28 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 20 Feb 2014 17:02:28 +0100
Subject: haskell xml parsing for larger files?
In-Reply-To: <a6d97430-b1ec-47fd-b7be-85a40779a02b@me.com>
References: <a6d97430-b1ec-47fd-b7be-85a40779a02b@me.com>
Message-ID: <53062714.3050604@dfki.de>

I'm afraid our use case is not a lazy prefix traversal.
I'm more shocked that about 100 MB xml content do not fit (as tree) into 
3 GB memory.

Christian

Am 20.02.2014 16:49, schrieb malcolm.wallace:
> Is your usage pattern over the constructed tree likely to be a lazy
> prefix traversal?  If so, then HaXml supports lazy construction of the
> parse tree.  Some plots appear at the end of this paper, showing how
> memory usage can be reduced to a constant, even for very large inputs (1
> million tree nodes):
>
> http://www.cs.york.ac.uk/plasma/publications/pdf/partialparse.pdf
>
> Regards,
>      Malcolm
>
>
> On 20 Feb, 2014,at 11:30 AM, Christian Maeder <Christian.Maeder at dfki.de>
> wrote:
>
>> Hi,
>>
>> I've got some difficulties parsing "large" xml files (> 100MB).
>> A plain SAX parser, as provided by hexpat, is fine. However,
>> constructing a tree consumes too much memory on a 32bit machine.
>>
>> see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248
>>
>> I suspect that sharing strings when constructing trees might greatly
>> reduce memory requirements. What are suitable libraries for string pools?
>>
>> Before trying to implement something myself, I'ld like to ask who else
>> has tried to process large xml files (and met similar memory problems)?
>>
>> I have not yet investigated xml-conduit and hxt for our purpose. (These
>> look scary.)
>>
>> In fact, I've basically used the content trees from "The (simple) xml
>> package" and switching to another tree type is no fun, in particular if
>> this gains not much.
>>
>> Thanks Christian
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> <mailto:Glasgow-haskell-users at haskell.org>
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From Christian.Maeder at dfki.de  Thu Feb 20 16:08:40 2014
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu, 20 Feb 2014 17:08:40 +0100
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <59543203684B2244980D7E4057D5FBC1487A345A@DB3EX14MBXC308.europe.corp.microsoft.com>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>	<52FCC6FC.6090704@dfki.de>
 <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>
 <53062478.3010104@dfki.de>
 <59543203684B2244980D7E4057D5FBC1487A345A@DB3EX14MBXC308.europe.corp.microsoft.com>
Message-ID: <53062888.8020107@dfki.de>

With "TypeableN " I mean, Typeable1, Typeable2, etc.
Typeable2 was not supported (below) by ghc-7.8-rc1.

Where is the "backward compat"?

In fact, Typeable and Typeable2 mean the same thing for ghc-7.8-rc1 and 
ghc-7.6 resp.!

C.

Am 20.02.2014 17:00, schrieb Simon Peyton Jones:
> | Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
>
> Not really: ghc-7.8 does still support TypeableN I think (for backward compat reasons).  So it can't take it to mean two different things.
>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of Christian Maeder
> | Sent: 20 February 2014 15:51
> | To: Daniil Frumin
> | Cc: glasgow-haskell-users at haskell.org
> | Subject: Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
> |
> | Yes, changing Typeable2 to Typeable in:
> |
> | {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} ...
> | deriving instance Typeable Gr
> |
> | goes through with ghc-7.8-rc1.
> |
> | However, this change refuses to compile with ghc-7.6.3:
> |
> |      Expecting two more arguments to `Gr'
> |      In the stand-alone deriving instance for `Typeable Gr'
> |
> | This is unfortunate, because I need to add conditional compilation to
> | make my code compilable for the two most recent major versions of GHC.
> |
> | Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
> |
> | Cheers Christian
> |
> | Am 13.02.2014 15:36, schrieb Daniil Frumin:
> | > I think that the preferred solution is to get rid of the custom
> | > Typeable(2) instances and just derive Typeable
> | >
> | > On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
> | > <Christian.Maeder at dfki.de> wrote:
> | >> Hi,
> | >>
> | >> with ghc-7.8.20140130 I get the compilation error:
> | >>
> | >>      Not in scope: type constructor or class 'Typeable2'
> | >>      Perhaps you meant 'Typeable' (imported from Data.Typeable)
> | >>
> | >> What is the recommend way to adjust my code or my dependencies?
> | >>
> | >> Cheers Christian
> | >>
> | >> Am 03.02.2014 23:35, schrieb Austin Seipp:
> | >>>
> | >>> We are pleased to announce the first release candidate for GHC
> | 7.8.1:
> | >>>
> | >>>       http://www.haskell.org/ghc/dist/7.8.1-rc1/
> | >>>       http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
> | >>>
> | >>> This includes the source tarball and bindists for Windows, Linux, OS
> | >>> X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy
> | >>> of the SHA256 hashes available (attached) using my GPG key (keyid
> | >>> 0x3B58D86F).
> | >>>
> | >>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
> | >>> some existing issues.
> | >>>
> | >>> Please test as much as possible; bugs are much cheaper if we find
> | >>> them before the release!
> | >>>
> | >>>
> | >>>
> | >>>
> | >>> _______________________________________________
> | >>> Glasgow-haskell-users mailing list
> | >>> Glasgow-haskell-users at haskell.org
> | >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> | >>>
> | >>
> | >> _______________________________________________
> | >> Glasgow-haskell-users mailing list
> | >> Glasgow-haskell-users at haskell.org
> | >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> | >
> | >
> | >
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>


From simonpj at microsoft.com  Thu Feb 20 16:11:17 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 20 Feb 2014 16:11:17 +0000
Subject: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
In-Reply-To: <53062888.8020107@dfki.de>
References: <CAEs96n0D4MdUKO-1DRyV2pvkog8ntS99EbeQqn2vjaUfRPYefA@mail.gmail.com>
 <52FCC6FC.6090704@dfki.de>
 <CACxkR4Cd=T2ibUSSFW74yKi4RjAkysdxBPirbsqR0uVEYkbS+Q@mail.gmail.com>
 <53062478.3010104@dfki.de>
 <59543203684B2244980D7E4057D5FBC1487A345A@DB3EX14MBXC308.europe.corp.microsoft.com>
 <53062888.8020107@dfki.de>
Message-ID: <59543203684B2244980D7E4057D5FBC1487A34EE@DB3EX14MBXC308.europe.corp.microsoft.com>

I think you need to import Data.OldTypeable to get Typeable2 and friends.  Pedro may remember more of the reasoning about backward compatibility.

| -----Original Message-----
| From: Christian Maeder [mailto:Christian.Maeder at dfki.de]
| Sent: 20 February 2014 16:09
| To: Simon Peyton Jones; Daniil Frumin
| Cc: glasgow-haskell-users at haskell.org
| Subject: Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
| 
| With "TypeableN " I mean, Typeable1, Typeable2, etc.
| Typeable2 was not supported (below) by ghc-7.8-rc1.
| 
| Where is the "backward compat"?
| 
| In fact, Typeable and Typeable2 mean the same thing for ghc-7.8-rc1 and
| ghc-7.6 resp.!
| 
| C.
| 
| Am 20.02.2014 17:00, schrieb Simon Peyton Jones:
| > | Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
| >
| > Not really: ghc-7.8 does still support TypeableN I think (for backward
| compat reasons).  So it can't take it to mean two different things.
| >
| > | -----Original Message-----
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | bounces at haskell.org] On Behalf Of Christian Maeder
| > | Sent: 20 February 2014 15:51
| > | To: Daniil Frumin
| > | Cc: glasgow-haskell-users at haskell.org
| > | Subject: Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
| > |
| > | Yes, changing Typeable2 to Typeable in:
| > |
| > | {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} ...
| > | deriving instance Typeable Gr
| > |
| > | goes through with ghc-7.8-rc1.
| > |
| > | However, this change refuses to compile with ghc-7.6.3:
| > |
| > |      Expecting two more arguments to `Gr'
| > |      In the stand-alone deriving instance for `Typeable Gr'
| > |
| > | This is unfortunate, because I need to add conditional compilation
| > | to make my code compilable for the two most recent major versions of
| GHC.
| > |
| > | Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
| > |
| > | Cheers Christian
| > |
| > | Am 13.02.2014 15:36, schrieb Daniil Frumin:
| > | > I think that the preferred solution is to get rid of the custom
| > | > Typeable(2) instances and just derive Typeable
| > | >
| > | > On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
| > | > <Christian.Maeder at dfki.de> wrote:
| > | >> Hi,
| > | >>
| > | >> with ghc-7.8.20140130 I get the compilation error:
| > | >>
| > | >>      Not in scope: type constructor or class 'Typeable2'
| > | >>      Perhaps you meant 'Typeable' (imported from Data.Typeable)
| > | >>
| > | >> What is the recommend way to adjust my code or my dependencies?
| > | >>
| > | >> Cheers Christian
| > | >>
| > | >> Am 03.02.2014 23:35, schrieb Austin Seipp:
| > | >>>
| > | >>> We are pleased to announce the first release candidate for GHC
| > | 7.8.1:
| > | >>>
| > | >>>       http://www.haskell.org/ghc/dist/7.8.1-rc1/
| > | >>>       http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
| > | >>>
| > | >>> This includes the source tarball and bindists for Windows,
| > | >>> Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a
| > | >>> signed copy of the SHA256 hashes available (attached) using my
| > | >>> GPG key (keyid 0x3B58D86F).
| > | >>>
| > | >>> We plan to make the 7.8.1 RC2 release quite soon, as we're aware
| > | >>> of some existing issues.
| > | >>>
| > | >>> Please test as much as possible; bugs are much cheaper if we
| > | >>> find them before the release!
| > | >>>
| > | >>>
| > | >>>
| > | >>>
| > | >>> _______________________________________________
| > | >>> Glasgow-haskell-users mailing list
| > | >>> Glasgow-haskell-users at haskell.org
| > | >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| > | >>>
| > | >>
| > | >> _______________________________________________
| > | >> Glasgow-haskell-users mailing list
| > | >> Glasgow-haskell-users at haskell.org
| > | >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| > | >
| > | >
| > | >
| > |
| > | _______________________________________________
| > | Glasgow-haskell-users mailing list
| > | Glasgow-haskell-users at haskell.org
| > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| >
| >


From fuuzetsu at fuuzetsu.co.uk  Thu Feb 20 16:42:05 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 20 Feb 2014 16:42:05 +0000
Subject: haskell xml parsing for larger files?
In-Reply-To: <5305E768.40002@dfki.de>
References: <5305E768.40002@dfki.de>
Message-ID: <5306305D.8010600@fuuzetsu.co.uk>

On 20/02/14 11:30, Christian Maeder wrote:
> Hi,
> 
> I've got some difficulties parsing "large" xml files (> 100MB).
> A plain SAX parser, as provided by hexpat, is fine. However, 
> constructing a tree consumes too much memory on a 32bit machine.
> 
> see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248
> 
> I suspect that sharing strings when constructing trees might greatly 
> reduce memory requirements. What are suitable libraries for string pools?
> 
> Before trying to implement something myself, I'ld like to ask who else 
> has tried to process large xml files (and met similar memory problems)?
> 
> I have not yet investigated xml-conduit and hxt for our purpose. (These 
> look scary.)
> 
> In fact, I've basically used the content trees from "The (simple) xml 
> package" and switching to another tree type is no fun, in particular if 
> this gains not much.
> 
> Thanks Christian
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

HXT will not work for you, you will run out of memory on files ~30MB. I
don't know about xml-conduit, I'd love to hear how it goes if you try it.

-- 
Mateusz K.

From carter.schonwald at gmail.com  Sun Feb 23 04:48:38 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 22 Feb 2014 23:48:38 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
Message-ID: <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>

Bump!

have we reached any consensus on the different variations of this proposal?

a) i seem to recall some of the cabal maintainers expressing interest in
hosting binaries for major platforms

b) some sort of platform-lite thats the ghc bin dist + cabal-install,
targeted at folks using haskell on server rather than desktop envs -- there
was a bunch of strong support for this (esp those using haskell and aren't
on the major linux distros)

c)  incuding a cabal install binary in the release build bin dist for ghc
(there were some reasonable arguments against this)

am I missing any major ideas folks had?
both the "mini lite platform for servers" and "cabal binaries to easily
download" are great ideas.

-Carter


On Sun, Feb 2, 2014 at 10:13 PM, Jens Petersen
<juhp at community.haskell.org>wrote:

> +1 for Carter's proposal - I had actually been planning to make the same
> suggestion, but just saw this thread now...
>
> On 27 January 2014 09:39, Austin Seipp <austin at well-typed.com> wrote:
>
>> As for shipping with GHC itself: this is technically possible, but
>> slightly annoying to implement, and it also makes the build processes
>> for a release slightly more annoying (which is mostly my problem.) But
>> it is all doable. However, keep in mind I *do not* maintain the binary
>> distributions for everything, nor do Cabal devs have access to all
>> hardware - so all people making upstream releases for their platforms
>> (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal
>> themselves. But perhaps that's not a huge deal.
>>
>
> If ghc provided cabal-install I would be happy to ship that in Fedora
> instead of a separate package.  To me cabal-install is probably the most
> important tool/package in HP (except for ghc itself of course): many people
> build/bootstrap latest ghc themselves it seems and so providing
> the latest cabal-install out of the box too would be a big win IMO,
> making it much easier to test ghc.  (I wouldn't even mind if ghc
> shipped cabal-install's dependencies too.)
>
> Jens
>
> ps Of course it could be made a configure option whether to build
> cabal-install or now: the cabal-install source is already there. ;) :)
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140222/1161f04c/attachment.html>

From voldermort at hotmail.com  Sun Feb 23 07:59:15 2014
From: voldermort at hotmail.com (harry)
Date: Sat, 22 Feb 2014 23:59:15 -0800 (PST)
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
 <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
Message-ID: <1393142354919-5744504.post@n5.nabble.com>

Carter Schonwald wrote
> b) some sort of platform-lite thats the ghc bin dist + cabal-install,
> targeted at folks using haskell on server rather than desktop envs --
> there
> was a bunch of strong support for this (esp those using haskell and aren't
> on the major linux distros)

Would like the platform-lite (if there is one) to exclude profiling
libraries, and other stuff that isn't needed for servers (see the Heroku
build packs for examples of everything they delete after installing the
bindist).



--
View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5744504.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From carter.schonwald at gmail.com  Sun Feb 23 14:50:41 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Feb 2014 09:50:41 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <1393142354919-5744504.post@n5.nabble.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
 <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
 <1393142354919-5744504.post@n5.nabble.com>
Message-ID: <CAHYVw0y3wmkKny3fxXnoC2WQyn=FdVDT=MpXiNYDz8vX5eLBpA@mail.gmail.com>

Let's not get off track :-).  I'm pretty sure some folks occasionally need
to do profiling/perf debugging on a live server.

So you support there being some easy way to get ghc and cabal-install
together or no? (Heroku is a good example I guess)

On Sunday, February 23, 2014, harry <voldermort at hotmail.com> wrote:

> Carter Schonwald wrote
> > b) some sort of platform-lite thats the ghc bin dist + cabal-install,
> > targeted at folks using haskell on server rather than desktop envs --
> > there
> > was a bunch of strong support for this (esp those using haskell and
> aren't
> > on the major linux distros)
>
> Would like the platform-lite (if there is one) to exclude profiling
> libraries, and other stuff that isn't needed for servers (see the Heroku
> build packs for examples of everything they delete after installing the
> bindist).
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5744504.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140223/96089619/attachment.html>

From voldermort at hotmail.com  Sun Feb 23 15:19:34 2014
From: voldermort at hotmail.com (harry)
Date: Sun, 23 Feb 2014 07:19:34 -0800 (PST)
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0y3wmkKny3fxXnoC2WQyn=FdVDT=MpXiNYDz8vX5eLBpA@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
 <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
 <1393142354919-5744504.post@n5.nabble.com>
 <CAHYVw0y3wmkKny3fxXnoC2WQyn=FdVDT=MpXiNYDz8vX5eLBpA@mail.gmail.com>
Message-ID: <1393168774177-5744511.post@n5.nabble.com>

Carter Schonwald wrote
> Let's not get off track :-).  I'm pretty sure some folks occasionally need
> to do profiling/perf debugging on a live server.
> 
> So you support there being some easy way to get ghc and cabal-install
> together or no? (Heroku is a good example I guess)

If the only difference between the proposed platform-lite and the regular
bindist is the inclusion of cabal-install, which will be separately
downloadable anyway, then it doesn't seem worth the bother. I'd be more
interested in a slimmed-down bindist for those who need it.



--
View this message in context: http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5744511.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From carter.schonwald at gmail.com  Sun Feb 23 15:24:42 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Feb 2014 10:24:42 -0500
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <1393168774177-5744511.post@n5.nabble.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
 <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
 <1393142354919-5744504.post@n5.nabble.com>
 <CAHYVw0y3wmkKny3fxXnoC2WQyn=FdVDT=MpXiNYDz8vX5eLBpA@mail.gmail.com>
 <1393168774177-5744511.post@n5.nabble.com>
Message-ID: <CAHYVw0xBtG6ZXQr0nF20nA6dG3Pi16r25ocOBtg0pPbsrNfV=g@mail.gmail.com>

Umm, then it wouldn't be lite!  Most of the libs in Haskell platform aren't
needed in the server context.  Ghc + builtin libs/bind + cabal-install is
what I really mean.  :-)

On Sunday, February 23, 2014, harry <voldermort at hotmail.com> wrote:

> Carter Schonwald wrote
> > Let's not get off track :-).  I'm pretty sure some folks occasionally
> need
> > to do profiling/perf debugging on a live server.
> >
> > So you support there being some easy way to get ghc and cabal-install
> > together or no? (Heroku is a good example I guess)
>
> If the only difference between the proposed platform-lite and the regular
> bindist is the inclusion of cabal-install, which will be separately
> downloadable anyway, then it doesn't seem worth the bother. I'd be more
> interested in a slimmed-down bindist for those who need it.
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/RFC-include-a-cabal-install-executable-in-future-GHC-releases-tp5742543p5744511.html
> Sent from the Haskell - Glasgow-haskell-users mailing list archive at
> Nabble.com.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140223/e2cdb392/attachment.html>

From the.dead.shall.rise at gmail.com  Sun Feb 23 16:31:20 2014
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Sun, 23 Feb 2014 17:31:20 +0100
Subject: RFC: include a cabal-install executable in future GHC releases
In-Reply-To: <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
References: <CAHYVw0zBmtyDp3pVJPjuZ6SzO1upGLcYFx7L1QZsKzwdMqovMQ@mail.gmail.com>
 <CAPoegsy8aMmqjmjtHowqR3YCfQQe55UtRqN3ugA8xPkDUQpOhA@mail.gmail.com>
 <CACxkR4B+1OhwxpxiKUODS2YGzcVsLaG7c_wAw84kzbbLdpHL9w@mail.gmail.com>
 <CAEs96n33kcNjt+qbfX_X4TKvWhAeDfnNJU0xRVnoZuL8HobxGg@mail.gmail.com>
 <CAEDGBqJopvQmfHS=2zAKVpp0M54GePLKjCUJ+8emzbQCqp1K1g@mail.gmail.com>
 <CAHYVw0w5_iNM8X=EsQvU4oEWE7WHw9kVHJmaMd9+FpGr_t56Xw@mail.gmail.com>
Message-ID: <CA+tcxkDSd5vqGyTLhs5Pz6twX793-SQHF0hAwvCYaHCCbe0HLA@mail.gmail.com>

Hi,

On 23 February 2014 05:48, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> Bump!
>
> have we reached any consensus on the different variations of this proposal?
>
> a) i seem to recall some of the cabal maintainers expressing interest in hosting binaries for major platforms

Austin promised to provide us with build bots for 3/4 of the tier 1
platforms. I assume that he is busy with preparing with the 7.8
release now.

From trupill at gmail.com  Thu Feb 27 09:39:39 2014
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 27 Feb 2014 10:39:39 +0100
Subject: OutsideIn(X) question
Message-ID: <CAHnFXOu=BVBfvOFpqKbrFWw=cand60hDcM6g-VLCCmazFtJ3zA@mail.gmail.com>

(Cross-posted from Haskell-Caf?)

I don't know if this is the best forum to ask questions about the
OutsideIn(X) paper that lies below type inference in GHC. Any way, I sent
it to Haskell-caf? and was advised to send it here also.

My question related about the proof of soundness and principality,
specifically Lemma 7.2 (to be found in page 67). In that lemma, it's stated
that QQ and \phi' Q_q ||- \phi Q_w <-> \phi' Q_w'. I'm trying to recover
the proof (which is omitted in the text), but I stumble upon a wall when
trying to work out what happens in the case an axiom is applied.

In particular, I'm playing with an example where

QQ (the set of axioms) = { forall. C a => D a } (where C and D are
one-parameter type classes)
Q_q = { }
Q_w = { D Int }

Thus, if I apply the rule DINSTW (to be found in page 65), I get a new

Q_w' = { C Int }

Now, if the lemma 7.2 is true, it should be the case that

(1)  QQ ||- C Int <-> D Int

which in particular means that I have the two implications

(2)  { forall. C a => D a, C Int } ||- D Int
(3)  { forall. C a => D a, D Int } ||- C Int

(2) follows easily by applying the AXIOM rule of ||- (as shown in page 54).
However, I don't see how to make (3) work :(
I think that understanding this example will be key for my understanding of
the whole system.

Anybody could point to the error in my reasoning or to places where I could
find more information?
Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140227/5e343c0c/attachment.html>