Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On 5 August 2011 05:27, Ian Lynagh ig...@earth.li wrote: from http://koji.fedoraproject.org/koji/getfile?taskID=3251249name=build.log . | *** unexpected failure for fed001(normal) but it works fine for me on x86/Linux. Note the Fedora build is patched to use system libffi. Hmm. What happens if you don't patch it? More hmmm: that makes the x86 unexpected errors go to 0! http://koji.fedoraproject.org/koji/taskinfo?taskID=3253482 I attach system libffi patch if anyone wants to look at it, but I don't see anything particularly arch-specific about it though so I still don't understand why it fails for 7.2. A similar patch for ghc-7.0.4 doesn't seem to have any ill-effects on the test results: eg http://koji.fedoraproject.org/koji/buildinfo?buildID=248071 I'd be interested to know if any other distros can reproduces or not. I think the system libffi patch originally comes from Debian. It would be good to make Linux default to use system libffi anyway. Is there any good reason not to do so? As you know copy libraries are frowned upon in the linux world. I can't remember if such an RFE already exists in trac? Thanks, Jens diff -up ghc-7.2.0.20110728/compiler/ghc.cabal.in.libffi ghc-7.2.0.20110728/compiler/ghc.cabal.in --- ghc-7.2.0.20110728/compiler/ghc.cabal.in.libffi 2011-07-29 02:12:04.0 +0900 +++ ghc-7.2.0.20110728/compiler/ghc.cabal.in 2011-08-03 14:28:19.447190200 +0900 @@ -81,7 +81,7 @@ Library if flag(ghci) Build-Depends: template-haskell CPP-Options: -DGHCI -Include-Dirs: ../libffi/build/include +pkgconfig-depends: libffi Build-Depends: bin-package-db Build-Depends: hoopl diff -up ghc-7.2.0.20110728/ghc.mk.libffi ghc-7.2.0.20110728/ghc.mk --- ghc-7.2.0.20110728/ghc.mk.libffi 2011-07-29 02:12:04.0 +0900 +++ ghc-7.2.0.20110728/ghc.mk 2011-08-03 14:35:16.766340182 +0900 @@ -449,7 +449,6 @@ utils/runghc/dist-install/package-data.m # add the final two package.conf dependencies: ghc-prim depends on RTS, # and RTS depends on libffi. libraries/ghc-prim/dist-install/package-data.mk : rts/package.conf.inplace -rts/package.conf.inplace : libffi/package.conf.inplace endif # @@ -467,11 +466,6 @@ ALL_STAGE1_LIBS += $(foreach lib,$(PACKA endif BOOT_LIBS = $(foreach lib,$(PACKAGES_STAGE0),$(libraries/$(lib)_dist-boot_v_LIB)) -OTHER_LIBS = libffi/dist-install/build/libHSffi$(v_libsuf) libffi/dist-install/build/HSffi.o -ifeq $(BuildSharedLibs) YES -OTHER_LIBS += libffi/dist-install/build/libHSffi$(dyn_libsuf) -endif - # # Special magic for the ghc-prim package @@ -560,7 +554,6 @@ BUILD_DIRS += \ driver/ghci \ driver/ghc \ driver/haddock \ - libffi \ includes \ rts @@ -865,11 +858,10 @@ INSTALL_DISTDIR_compiler = stage2 # Now we can do the installation install_packages: install_libexecs -install_packages: libffi/package.conf.install rts/package.conf.install +install_packages: rts/package.conf.install $(call INSTALL_DIR,$(DESTDIR)$(topdir)) $(RM) $(RM_OPTS_REC) $(INSTALLED_PACKAGE_CONF) $(call INSTALL_DIR,$(INSTALLED_PACKAGE_CONF)) - $(INSTALLED_GHC_PKG_REAL) --force --global-conf $(INSTALLED_PACKAGE_CONF) update libffi/package.conf.install $(INSTALLED_GHC_PKG_REAL) --force --global-conf $(INSTALLED_PACKAGE_CONF) update rts/package.conf.install $(foreach p, $(INSTALLED_PKG_DIRS), \ $(call make-command, \ @@ -957,7 +949,7 @@ BIN_DIST_MK = $(BIN_DIST_PREP_DIR)/bindi unix-binary-dist-prep: $(RM) $(RM_OPTS_REC) bindistprep/ $(MKDIRHIER) $(BIN_DIST_PREP_DIR) - set -e; for i in packages LICENSE compiler ghc rts libraries utils docs libffi includes driver mk rules Makefile aclocal.m4 config.sub config.guess install-sh settings.in ghc.mk inplace distrib/configure.ac distrib/README distrib/INSTALL; do ln -s ../../$$i $(BIN_DIST_PREP_DIR)/; done + set -e; for i in packages LICENSE compiler ghc rts libraries utils docs includes driver mk rules Makefile aclocal.m4 config.sub config.guess install-sh settings.in ghc.mk inplace distrib/configure.ac distrib/README distrib/INSTALL; do ln -s ../../$$i $(BIN_DIST_PREP_DIR)/; done echo HADDOCK_DOCS = $(HADDOCK_DOCS)$(BIN_DIST_MK) echo LATEX_DOCS = $(LATEX_DOCS) $(BIN_DIST_MK) echo BUILD_DOCBOOK_HTML = $(BUILD_DOCBOOK_HTML) $(BIN_DIST_MK) @@ -1042,7 +1034,7 @@ SRC_DIST_DIR=$(TOP)/$(SRC_DIST_NAME) # # Files to include in source distributions # -SRC_DIST_DIRS = mk rules docs distrib bindisttest libffi includes utils docs rts compiler ghc driver libraries ghc-tarballs +SRC_DIST_DIRS = mk rules docs distrib bindisttest includes utils docs rts compiler ghc driver libraries ghc-tarballs SRC_DIST_FILES += \ configure.ac config.guess config.sub configure \ aclocal.m4 README ANNOUNCE HACKING LICENSE Makefile install-sh \ diff -up ghc-7.2.0.20110728/rts/ghc.mk.libffi
Re: GHCJS
On 04/08/2011 21:02, Simon Peyton-Jones wrote:
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to control the desugaring of literals. Why
literals? And why is literals enough?
| But I don't still understand what can I do with foreign
| imports/exports. DsForeign module seems to be too complicated. As I
| can see, I shouldn't make whole dsForeigns function replaceable, but I
| can't understand what part of it should be replaceble.
I still think that the stub generation for foreign declarations should be
easily separable. The desugarer generates a certainly amount of unwrapping,
but you'll want that for JavaScript too. The actual calling convention is
embedded inside the Id: see the FCallId constructor of IdDetails in IdInfo.lhs,
and the ForeignCall type in ForiegnCall.lhs.
There's a lot that's backend-specific about the way we desugar foreign
import wrapper - calls to createAdjustor passing magic strings and
suchlike. It would be nice to identify the stuff that is
backend-specific and separate it out, I think.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On 05/08/2011 08:45, Jens Petersen wrote: On 5 August 2011 05:27, Ian Lynaghig...@earth.li wrote: from http://koji.fedoraproject.org/koji/getfile?taskID=3251249name=build.log . | *** unexpected failure for fed001(normal) but it works fine for me on x86/Linux. Note the Fedora build is patched to use system libffi. Hmm. What happens if you don't patch it? More hmmm: that makes the x86 unexpected errors go to 0! http://koji.fedoraproject.org/koji/taskinfo?taskID=3253482 I attach system libffi patch if anyone wants to look at it, but I don't see anything particularly arch-specific about it though so I still don't understand why it fails for 7.2. A similar patch for ghc-7.0.4 doesn't seem to have any ill-effects on the test results: eg http://koji.fedoraproject.org/koji/buildinfo?buildID=248071 I'd be interested to know if any other distros can reproduces or not. I think the system libffi patch originally comes from Debian. This is surprising because I don't think ordinary FFI code should be even using libffi on x86 - we have our own implementation in rts/Adjustors.c. In 7.2 there are some changes in this area because we now guarantee to keep the C stack pointer aligned on a 16-byte boundary (see http://hackage.haskell.org/trac/ghc/ticket/5250), and as a result we switched to using the Mac OS X implementation in rts/Adjustors.c which was already doing the necessary alignment. You aren't setting UseLibFFIForAdjustors=YES anywhere, are you? (even if you were, I would expect it to still work though, albeit a bit more slowly). It would be good to make Linux default to use system libffi anyway. Is there any good reason not to do so? As you know copy libraries are frowned upon in the linux world. I can't remember if such an RFE already exists in trac? I don't like having to do this, but it reduces our testing surface (we don't want to have to test against N different versions of libffi). I'm quite happy for distros to build against their system libffi though, and we should make that easier. Note that if you build against the system libffi you are responsible for fully testing the combination (I know you already do that, which is great). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FlexibleInstances Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Hi, I've noticed that with ghc-7.2 many modules with LANGUAGE TypeSynonymInstances now also require FlexibleInstances Two examples are in the HTTP package Network.TCP and Network.BufferType Was ghc-7.0 wrong about this, before? Cheers Christian Am 29.07.2011 20:21, schrieb Ian Lynagh: We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Hi, Am Freitag, den 05.08.2011, 09:46 +0100 schrieb Simon Marlow: I don't like having to do this, but it reduces our testing surface (we don't want to have to test against N different versions of libffi). I'm quite happy for distros to build against their system libffi though, and we should make that easier. Note that if you build against the system libffi you are responsible for fully testing the combination (I know you already do that, which is great). after this broad hint, I ran the full testsuite, getting this result on Debian: OVERALL SUMMARY for test run started at Fr 5. Aug 11:02:03 CEST 2011 2894 total tests, which gave rise to 12535 test cases, of which 0 caused framework failures 2327 were skipped 9823 expected passes 351 expected failures 1 unexpected passes 33 unexpected failures Unexpected passes: concurrent/should_run throwto002 (ghci) Unexpected failures: cabal ghcpkg05 [bad stderr] (normal) concurrent/prog002 concprog002 [exit code non-0] (threaded2,threaded2_hT) concurrent/prog003 concprog003 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/prog003 concprog003 [bad stdout or stderr] (ghci) concurrent/should_run conc023 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/should_run conc023 [bad stdout or stderr] (ghci) ffi/should_run ffi009 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ffi/should_run ffi009 [bad stdout or stderr] (ghci) pluginsplugins05 [exit code non-0] (profasm,dyn,profthreaded) Without looking into details yet, or comparing it with the test suite in 7.0.4. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FlexibleInstances Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
I've just found http://hackage.haskell.org/trac/ghc/ticket/5377 which explains it. C. Am 05.08.2011 12:56, schrieb Christian Maeder: Hi, I've noticed that with ghc-7.2 many modules with LANGUAGE TypeSynonymInstances now also require FlexibleInstances Two examples are in the HTTP package Network.TCP and Network.BufferType Was ghc-7.0 wrong about this, before? Cheers Christian Am 29.07.2011 20:21, schrieb Ian Lynagh: We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On 05/08/2011 12:08, Joachim Breitner wrote: Hi, Am Freitag, den 05.08.2011, 09:46 +0100 schrieb Simon Marlow: I don't like having to do this, but it reduces our testing surface (we don't want to have to test against N different versions of libffi). I'm quite happy for distros to build against their system libffi though, and we should make that easier. Note that if you build against the system libffi you are responsible for fully testing the combination (I know you already do that, which is great). after this broad hint, I ran the full testsuite, getting this result on Debian: OVERALL SUMMARY for test run started at Fr 5. Aug 11:02:03 CEST 2011 2894 total tests, which gave rise to 12535 test cases, of which 0 caused framework failures 2327 were skipped 9823 expected passes 351 expected failures 1 unexpected passes 33 unexpected failures Unexpected passes: concurrent/should_run throwto002 (ghci) Unexpected failures: cabal ghcpkg05 [bad stderr] (normal) concurrent/prog002 concprog002 [exit code non-0] (threaded2,threaded2_hT) concurrent/prog003 concprog003 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/prog003 concprog003 [bad stdout or stderr] (ghci) concurrent/should_run conc023 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) concurrent/should_run conc023 [bad stdout or stderr] (ghci) ffi/should_run ffi009 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ffi/should_run ffi009 [bad stdout or stderr] (ghci) pluginsplugins05 [exit code non-0] (profasm,dyn,profthreaded) Without looking into details yet, or comparing it with the test suite in 7.0.4. This result is fine. Most of those failures have been cleaned up in HEAD already, but the changes haven't been merged into the branch yet. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote: The RC unfortunately doesn't build on Lion (OS X 10.7). I've put the latest 7.2 source here, along with OS X builds: http://www.haskell.org/ghc/dist/7.2.1-rc2/ My guess is that the bindists will work on Lion, but that the installers will use the wrong gcc. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
