- Glasgow-haskell-users

Re: 7.8.1-candidate fail
by Jan Stolarek 17 Feb '14

17 Feb '14

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(a)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(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs

2 1

Functional dependencies can "return" kinds, type families cannot
by José Pedro Magalhães 14 Feb '14

14 Feb '14

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

2 1

target audience for the binary distribution
by harry 11 Feb '14

11 Feb '14

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-distrib… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

5 5

RHEL/EPEL 5 ghc packages
by Jens Petersen 10 Feb '14

10 Feb '14

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… Please report any problems with this in bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=g… 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.

2 2

7.8.1-candidate fail
by Sergei Meshveliani 06 Feb '14

06 Feb '14

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

2 1

GHC iOS 7.8.1 RC1 for Device & Simulator
by Luke Iannini 06 Feb '14

06 Feb '14

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… https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simula… 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

1 0

empty stable and current bindist directories
by harry 06 Feb '14

06 Feb '14

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-direc… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

1 0

Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
by Barney Stratford 05 Feb '14

05 Feb '14

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-dar… 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.

3 2

test build of current ghc-7.8
by Jens Petersen 05 Feb '14

05 Feb '14

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

3 4

Static values language extension proposal
by Facundo Domínguez 30 Jan '14

30 Jan '14

Hello, With the support of Tweag I/O, Mathieu and I have been assembling a design proposal for the language extension for Static values that will take Cloud Haskell a big step forward in usability. Please, find the proposal inlined below. We are looking forward to discuss its feasibility and features with the community. Best, Facundo -- In these notes we discuss a design of the language extension proposed in [1] for Cloud Haskell. That is, support from the compiler to produce labels that can be used to identify Haskell top-level bindings across processes in a network. Static values ========= Following [1], the extension consists of a new syntactic form `static e`, along with a type constructor `StaticRef` and a function unstatic :: StaticRef a -> a The idea is that values of type `StaticRef a` uniquely identify a value that can be referred to by a global name rather than serialized over the network between processes that are instances of a single binary, because all such processes share the same top-level bindings. Generating static references ==================== We start by introducing global names. A `GlobalName` is a symbol bound in the top-level environment. It is much like global names in Template Haskell, but `GlobalNames` always refer to terms, and they include a package version. data GlobalName = GlobalName PkgName PkgVersion ModName OccName `GlobalNames` can be used as references to static values. newtype StaticRef a = StaticRef GlobalName `StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper with a phantom type parameter that keeps track of the type of the value that is referenced. The special form static e is an expression of type `StaticRef a` where `e :: a` is a closed expression (meaning any free variables in `e` are bound in the top-level environment). If `e` is an identifier, `static e` just refers to it. Otherwise, the compiler needs to introduce a new top-level binding with a fresh name and the expression used as right-hand side, and the static reference would point to this top-level binding instead. Looking up static references ==================== `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system’s dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system’s dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won’t be able to find the private bindings of a module. For this sake, the implementation of static should in addition ensure that the bindings it gets will appear in the symbol table when they are not exported by their defining modules. Template Haskell support ================== The static keyword needs to be made available in Template Haskell so the distributed-static package can benefit from this language extension. Rationale ======= We want the language extension to meet the following requirements: 1. It must be a practical alternative to the remoteTable functions in the distributed-static package. 2. It must not change the build scheme used for Haskell programs. A collection of .o files produced from Haskell source code should still be possible to link with the system linking tools. 3. It must not restrict all communicating processes using the extension to be launched from the same binary. 4. It must not significantly increase the binary size. (1) is addressed by replacing remote tables with the symbol tables produced by the compiler. Additionally, Template Haskell support is included so that the existing distributed-static package can be adapted and extended to include this extension. (2) is addressed by choosing a scheme which does not require the linker to perform any extension-specific procedure to collect the static values in various modules. There’s a trade off here though, since symbols in statically linked modules cannot be accessed unless -optl-Wl,--export-dynamic is supplied during linking. (3) is addressed by allowing programs to exchange static values for any bindings found in the modules they share. (4) is addressed by reusing the symbol tables produced by the compiler in object files rather than creating separate remote tables. About the need for using different binaries ============================== While using distributed-process we found some use cases for supporting communicating closures between multiple binaries. One of these use cases involved a distributed application and a monitoring tool. The monitoring tool would need to link in some graphics libraries to display information on the screen, none of which were required by the monitored application. Conversely, the monitored application would link in some modules that the monitoring application didn’t need. Crucially, both applications are fairly loosely coupled, even if they both need to exchange static values about bindings in some modules they shared. An analogous use case involved the distributed application and a control application that would be used to change dynamic settings of the former. Further Work ========== As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won’t delve further into this problem. Another possible line of work is extending this approach so a process can pull shared objects from a remote peer, when this remote peer sends a static value that is defined in a shared object not available to the process. Integration with distributed-static ======================= The package distributed-static could either adopt this extension as the only implementation of static values, or it could support many notions of static references, say by using a type class to overload `unstatic`. class Static st s | s -> st where unstatic :: st -> s a -> Either String a where the class parameter `st` is provided for backwards compatibility with the existing scheme to provide context-dependent information. The extension we present here does not depend on this parameter, so `()` could be used for the `StaticRef` instance. instance Static () StaticRef where ... References ======== [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN 0362-1340.

9 24