- ghc-devs - Haskell.org

missing darcs repos?
by Malcolm Wallace 02 Mar '13

02 Mar '13

Hello, Has someone recently removed the (old) darcs repos for libraries from e.g. http://darcs.haskell.org/packages/array etc? My nightly builds of nhc98 have recently started failing because this is (and no doubt others are) missing. It is not a disaster, since I can start publishing the most recent state of these repos myself, but I just wanted to check that the removal was intentional. I con't recall any specific email about it, although I admit I do not keep up very well with mailing list traffic these days. Regards, Malcolm

2 2

Fixing "breaking packages"
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

Duncan, Mark, Simon Here's another cry of pain: http://fluffynukeit.com/2013/02/reflections-after-a-hard-day-in-haskell-gui… "Cabal is a frustratingly constraining tool. Far too frequently I encountered packages that, when trying to install, would say installing this package will break a dozen others. If not that, then I often would be notified that the dependencies could not be resolved. " What is frustrating that we KNOW how to fix this, don't we? (Allow multiple installations of package P-3.2.5, each depending on different versions of its dependencies.) We just need to liberate enough effort to do it. Indeed, more people seem to be joining in with GHC/Cabal these days. How hard would it be to write a detailed description of the implementation changes needed to support side-by-side installations, and project-manage a group to do it? Simon

10 13

TH in Cross-GHC
by Gabor Greif 01 Mar '13

01 Mar '13

Hi Stephen, on the wiki page you mention that you work on TH for cross-GHC. What is the status / attack plan on that? Here is something I was thinking all the time: What about enabling TH in the STAGE1 GHC (i.e. the final cross-GHC) iff the bootstrap compiler has exactly the same version as the one to be built? I understood that TH cannot be part of STAGE1 because of version mismatch issues in TH-internal data structures. Since TH is bytecode based, the target architecture should not be a concern. This could be a stopgap measure until we figure out the details how to switch over the build system so that STAGE2 is the cross-compiler (with TH), and optionally STAGE3 a native target compiler. Is there a reason why such a trick would not work in short term? I'd like to know. Cheers, Gabor

1 0

RE: libtoolize
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

Is this new? Does it matter? Can I ignore it? Does everyone now need to install a new tool? I'm not sure how to "install libtool on my linux". (I thought we'd been using libtool, whatever it is, for years, so I'm puzzled why this has just started to happen.) Simon | -----Original Message----- | From: Karel Gardas [mailto:karel.gardas@centrum.cz] | Sent: 27 February 2013 11:18 | To: Simon Peyton-Jones | Subject: Re: libtoolize | | | Simon, | | those messages should go away if you install libtool package on your linux. | | Cheers, | Karel | | On 02/27/13 11:17 AM, Simon Peyton-Jones wrote: | > I've started to get this when I say "sh validate". What's up? | > | > Simon | > | > Booting . | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > Booting libraries/base/ | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs

3 7

I can't clone
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

I keep getting this when attempting to clone a fresh repo. Can anyone help? Thanks SImon == running git submodule update Cloning into 'libraries/Win32'... error: Empty reply from server while accessing http://darcs.haskell.org/libraries/Win32.git/info/refs fatal: HTTP request failed Clone of 'http://darcs.haskell.org/libraries/Win32.git/' into submodule path 'libraries/Win32' failed git failed: 256 at ./sync-all line 199. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball simonpj@cam-05-unx:~/code/HEAD-1$

5 8

sync-all remote set-url broken
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

After an unreasonable amount of thrashing around, I finally discovered what was causing my pain: the set-url bit of sync-all doesn't work. Look at this. See the red below. The sub-modules don't have a ".git" suffix. The other packages do. Geoff thinks that the sync-all script has code for deciding whether to add the ".git" or not, but the code was omitted when adding the sub-module stuff. Result: in subsequent stuff, git looks in a darcs repo, with consequent terribly confusing results. Ian could you fix please? Simon simonpj@cam-05-unx:~/code/HEAD-1$ ./sync-all -r http://darcs.haskell.org remote set-url origin == ghc-tarballs: running git remote set-url origin http://darcs.haskell.org/ghc-tarballs.git == utils/hsc2hs: running git remote set-url origin http://darcs.haskell.org/hsc2hs.git == utils/haddock: running git remote set-url origin http://darcs.haskell.org/haddock.git == libraries/array: running git remote set-url origin http://darcs.haskell.org/packages/array.git == libraries/base: running git remote set-url origin http://darcs.haskell.org/packages/base.git == libraries/binary: running git remote set-url origin http://darcs.haskell.org/libraries/binary == libraries/bytestring: running git remote set-url origin http://darcs.haskell.org/libraries/bytestring == libraries/Cabal: running git remote set-url origin http://darcs.haskell.org/libraries/Cabal == libraries/containers: running git remote set-url origin http://darcs.haskell.org/libraries/containers == libraries/deepseq: running git remote set-url origin http://darcs.haskell.org/packages/deepseq.git == libraries/directory: running git remote set-url origin http://darcs.haskell.org/packages/directory.git == libraries/filepath: running git remote set-url origin http://darcs.haskell.org/packages/filepath.git == libraries/ghc-prim: running git remote set-url origin http://darcs.haskell.org/packages/ghc-prim.git == libraries/haskeline: running git remote set-url origin http://darcs.haskell.org/libraries/haskeline == libraries/haskell98: running git remote set-url origin http://darcs.haskell.org/packages/haskell98.git == libraries/haskell2010: running git remote set-url origin http://darcs.haskell.org/packages/haskell2010.git == libraries/hoopl: running git remote set-url origin http://darcs.haskell.org/packages/hoopl.git == libraries/hpc: running git remote set-url origin http://darcs.haskell.org/packages/hpc.git == libraries/integer-gmp: running git remote set-url origin http://darcs.haskell.org/packages/integer-gmp.git == libraries/integer-simple: running git remote set-url origin http://darcs.haskell.org/packages/integer-simple.git == libraries/old-locale: running git remote set-url origin http://darcs.haskell.org/packages/old-locale.git == libraries/old-time: running git remote set-url origin http://darcs.haskell.org/packages/old-time.git == libraries/pretty: running git remote set-url origin http://darcs.haskell.org/libraries/pretty == libraries/process: running git remote set-url origin http://darcs.haskell.org/packages/process.git == libraries/template-haskell: running git remote set-url origin http://darcs.haskell.org/packages/template-haskell.git == libraries/terminfo: running git remote set-url origin http://darcs.haskell.org/libraries/terminfo == libraries/time: running git remote set-url origin http://darcs.haskell.org/libraries/time == libraries/transformers: running git remote set-url origin http://darcs.haskell.org/libraries/transformers == libraries/unix: running git remote set-url origin http://darcs.haskell.org/packages/unix.git == libraries/Win32: running git remote set-url origin http://darcs.haskell.org/libraries/Win32 == libraries/xhtml: running git remote set-url origin http://darcs.haskell.org/libraries/xhtml == testsuite repo not present; skipping == nofib repo not present; skipping == libraries/parallel repo not present; skipping == libraries/stm repo not present; skipping == libraries/random: running git remote set-url origin http://darcs.haskell.org/libraries/random == libraries/primitive: running git remote set-url origin http://darcs.haskell.org/libraries/primitive == libraries/vector: running git remote set-url origin http://darcs.haskell.org/libraries/vector == libraries/dph: running git remote set-url origin http://darcs.haskell.org/packages/dph.git == running git remote set-url origin http://darcs.haskell.org/ghc.git == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball

2 1

Fwd: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable
by José Pedro Magalhães 01 Mar '13

01 Mar '13

Hi Simon, How should an instance of Typeable for a polykinded tycon look like? E.g. if we have data Proxy (a :: k) = Proxy -- Proxy :: forall (k :: BOX). k -> * I suppose we want an instance forall k. instance Typeable (k -> *) (Proxy k) Right? So the universally quantified kind variables of the tycon should end up universally quantified in the instance as well. How does this translate to the ds_tvs, ds_tys, and ds_tc_args arguments of a DerivSpec?... Thanks, Pedro ---------- Forwarded message ---------- From: GHC <cvs-ghc(a)haskell.org> Date: Mon, Feb 18, 2013 at 8:42 PM Subject: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable To: Cc: ghc-tickets(a)haskell.org #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This test program, reduced from an attempt to bring ekmett's tagged package to HEAD, {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} newtype Tagged s b = Tagged { unTagged :: b } }}} results in {{{ GHCi, version 7.7.20130218: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( typeable.hs, interpreted ) typeable.hs:5:1: Derived typeable instance must be of form (Typeable Tagged) In the stand-alone deriving instance for `Data.Typeable.Internal.Typeable Tagged' }}} This message is also emitted if I replace `AutoDeriveTypeable` `StandaloneDeriving` and `deriving instance Typeable Tagged`. However, a "deriving (Typeable)" clause on the newtype definition works just fine. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets

2 2

RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 01 Mar '13

01 Mar '13

Hi all, from what I gathered so far no emission of write barriers is needed when - running on a uniprocessor (-threaded or not) - running on a multiprocessor sans having linked with -threaded. Below patch suppresses the emission of 'lwsync' when no '-threaded' is specified on PPC only. So it does not cover both criteria above. It helps me a lot since I have a uniprocessor target that does not understand the 'lwsync' instruction (instruction is newer than core). Still, I have some doubts: o do we want to extend this approach to other archs? o possibly suppress the emission of MO_WriteBarrier in compiler/codeGen/StgCmmBind.hs (more care is needed to also cover compiler/cmm/CmmParse.y). Anyway this should be a safe first step, and I'd like to push it. When we find a general solution be can back this commit out. What do you think? Cheers, Gabor $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Feb 22 18:47:00 2013 +0100 Do not emit barriers on PPC unless we go the threaded way diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 92eff36..6c33cca 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -1,9 +1,8 @@ - ----------------------------------------------------------------------------- -- -- Generating machine code (instruction selection) -- --- (c) The University of Glasgow 1996-2004 +-- (c) The University of Glasgow 1996-2013 -- ----------------------------------------------------------------------------- @@ -906,8 +905,10 @@ genCCall' -} -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ - = return $ unitOL LWSYNC +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ + = return (if WayThreaded `elem` ways dflags + then unitOL LWSYNC + else nilOL) genCCall' _ _ (PrimTarget MO_Touch) _ _ = return $ nilOL

3 8

Confusing commit messages about `type-nats`?
by Iavor Diatchki 28 Feb '13

28 Feb '13

Hello, I am receiving a bunch of commit messages for branch `type-nats`, that seem to be fake (i.e., by folks committing to other branches). Does any one know why that is? It seems to have started after my merge commit from yesterday, so did I mess something up? -Iavor

3 3

Build errors on HEAD
by Jan Stolarek 28 Feb '13

28 Feb '13

I get this error when building HEAD (8fe04eb): utils/ghc-pkg/Main.hs:881:3: No instance for (Bin.Binary (InstalledPackageInfo_ String)) arising from a use of `writeBinaryFileAtomic' Possible fix: add an instance declaration for (Bin.Binary (InstalledPackageInfo_ String)) In the first argument of `catchIO', namely `writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db))' In a stmt of a 'do' block: writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e In the expression: do { let filename = location db </> cachefilename; when (verbosity > Normal) $ infoLn ("writing cache " ++ filename); writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e } Anyone else getting this or is it just me? Janek

1 0