August 2005 - Glasgow-haskell-users

upgrading Cabal in ghc-6.4.1-pre
by Serge D. Mechveliani 08 Aug '05

08 Aug '05

Dear Cabal developers, I have the following problem with upgrading Cabal in ghc-6.4.1.20050806-i386-unknown-linux. First, I have installed this ghc-6.4.1-pre binary to my home directory. > which ghc /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc Then, ghci -package Cabal reports of Cabal-1.0. I need to upgrade Cabal to 1.1.1. To do this, I unfold new Cabal to /home/mechvel/ghc/cabal/1.1.1/cabal/ Then I do cd /home/mechvel/ghc/cabal/1.1.1/cabal/ and edit in GNUmakefile the two lines to PREF=/home/mechvel/ghc/cabal/1.1.1/inst HCBASE=/home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ in order to install new Cabal to /home/mechvel/ghc/cabal/1.1.1/inst . Then I command make setup ./setup configure --prefix=/home/mechvel/ghc/cabal/1.1.1/inst ./setup build ./setup install --user Then, ghci -package Cabal reports --------------------------- GHC Interactive, version 6.4.1.20050806, for Haskell 98. ... Loading package base-1.0 ... linking ... done. Loading package mtl-1.0 ... linking ... done. Loading package lang-1.0 ... linking ... done. Loading package QuickCheck-1.0 ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package posix-1.0 ... linking ... done. Loading package util-1.0 ... linking ... done. Loading package Cabal-1.1.1 ... linking ... done. -------------------------------------------------------- Then I go to my application Dumatel and try to make it with GHC: ~/dm/1.03/dm/source> runhaskell Setup configure --ghc --prefix=$dmSource/inst ------------------------------------------------------ Configuring dumatel-1.3... configure: Using install prefix: /home/mechvel/dm/1.03/dm/source/inst configure: Using compiler: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1.20050806 configure: Using package tool: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency data-any: using data-1.0 -------------------------------------------------------------------- This looks all right. runhaskell Setup build --------------------------------------------------- Preprocessing library dumatel-1.3... Building dumatel-1.3... Chasing modules from: Dumatel,Dumatel.Prelude,Dumatel.Prelude5,Dumatel.TermComp,Dumatel.Reduce,Dumatel.CritPair,Dumatel.KBC,Dumatel.Bool,Dumatel.BTerm,Dumatel.ReduceBT,Dumatel.UKBB,Dumatel.Prover,Dumatel.DemoTest.Test,Dumatel.DemoTest.T_kbcTrad,Dumatel.DemoTest.T_ukb,Dumatel.DemoTest.T_logicSimp,Dumatel.DemoTest.T_nat,Dumatel.DemoTest.T_list,Prelude0,Prelude0_0,Prelude1,Prelude2,Prelude2_0,Prelude3,Prelude3_0,Prelude3_1,Prelude4,Bool0,BTerm0,BTerm1,Prover0,Parse1,Parse2,Parse3,Prover1,Prover2,Prover3,Dumatel.DemoTest.Test0 Could not find module `Prelude': it is a member of package base-1.0, which is hidden (imported from Dumatel.hs) --------------------------------------------------- And this differs from what it was with Cabal-1.0. I does not want to compile things. How to fix this, please? The file dm.cabal is ------------------------------------------------------ name: dumatel version: 1.3 build-depends: data exposed-modules: "Dumatel" "Dumatel.Prelude" "Dumatel.Prelude5" "Dumatel.TermComp" "Dumatel.Reduce" "Dumatel.CritPair" "Dumatel.KBC" "Dumatel.Bool" "Dumatel.BTerm" "Dumatel.ReduceBT" "Dumatel.UKBB" "Dumatel.Prover" "Dumatel.DemoTest.Test" "Dumatel.DemoTest.T_kbcTrad" "Dumatel.DemoTest.T_ukb" "Dumatel.DemoTest.T_logicSimp" "Dumatel.DemoTest.T_nat" "Dumatel.DemoTest.T_list" . other-modules: Prelude0 Prelude0_0 Prelude1 Prelude2 Prelude2_0 Prelude3 Prelude3_0 Prelude3_1 Prelude4 Bool0 BTerm0 BTerm1 Prover0 Parse1 Parse2 Parse3 Prover1 Prover2 Prover3 "Dumatel.DemoTest.Test0" . ghc-options: -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports --------------------------------------------------------------- When upgrading Cabal, `make setup' has produced many messages like -------------- Distribution/Compat/Directory.hs:2:24: Warning: `copyFile' is exported by `copyFile' and `module System.Directory' Distribution/Compat/FilePath.hs:298:15: Warning: This binding for `pre' shadows an existing binding In a case alternative -------------- ./setup configure ... produced ---------------------- Configuring Cabal-1.1.1... configure: Using install prefix: /home/mechvel/ghc/cabal/1.1.1/inst configure: Using compiler: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1.20050806 configure: Using package tool: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /home/mechvel/ghc/6.4.1-aug-1/binary/inst/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency base-any: using base-1.0 configure: Dependency util-any: using util-1.0 ----------------------------------------- ./setup build produced ------------------------------ ... ... Compiling Distribution.Compat.Directory ( ./Distribution/Compat/Directory.hs, dist/build/Distribution/Compat/Directory.o ) Distribution/Compat/Directory.hs:2:8: Warning: `findExecutable' is exported by `findExecutable' and `module System.Directory' ... ... Linking ... Preprocessing library Cabal-1.1.1... Preprocessing executables for Cabal-1.1.1... Building Cabal-1.1.1... hsSourceDirs: ["."] ------------------------------------ ./setup install --user produced ---------------------------------------------- building GHCi library /home/mechvel/ghc/cabal/1.1.1/inst/lib/Cabal-1.1.1/ ghc-6.4.1.20050806/HSCabal-1.1.1.o... done. Creating user package database in /home/mechvel/.ghc/i386-linux-6.4.1.20050806/package.conf Reading package info from ".installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /home/mechvel/ghc/cabal/1.1.1/inst/lib/Cabal-1.1.1/ghc-6.4.1.20050806 & /home/mechvel/ghc/cabal/1.1.1/inst/bin Cabal-1.1.1... Registering Cabal-1.1.1... ------------------------------------------- Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

mixing x86_64 and i386
by John Meacham 08 Aug '05

08 Aug '05

Just thought I'd share a little hack... linux has a command 'setarch' which changes the current architecture so you can do things like build i386 rpms on a x86_64 system... by installing both a i386 and x86_64 ghc (both from the fedora repo work great) and replacing the ghc driver with something like the below makes ghc "just work" too. (replace paths as appropriate) I wonder if we should make the driver script a bit smarter in general to allow multiple versions of ghc normally so you can just pass a version and arch command line argument to ghc and the driver will intpret it and call the appropriate back end. #!/bin/sh case `uname -m` in x86_64) GHCBIN="/usr/lib64/ghc-6.4.1.20050626/ghc-6.4.1.20050626" TOPDIROPT="-B/usr/lib64/ghc-6.4.1.20050626" EXTRA_OPTS="" ;; i*86) GHCBIN="/usr/lib/ghc-6.4/ghc-6.4" TOPDIROPT="-B/usr/lib/ghc-6.4" EXTRA_OPTS=" -optc-m32 -optl-m32 -opta-m32 " ;; *) echo "Unknown architecture" ; exit 2;; esac echo $GHCBIN $TOPDIROPT $EXTRA_OPTS ${1+"$@"} exec $GHCBIN $TOPDIROPT $EXTRA_OPTS ${1+"$@"} -- John Meacham - ⑆repetae.net⑆john⑈

3 2

Idempontent IO actions and unsafeSTMToIO
by Robert van Herk 06 Aug '05

06 Aug '05

Hi all, Is it true to say that to perform idempotent IO actions inside a STM monad by using unsafeSTMToIO is safe? I mean something like: do ... -- some STM actions unsafeSTMToIO a -- Here, a is an idempotent IO action ... -- some other STM actions What I read from the various sources on the web is that unsafeSTMToIO is just unsafe in the sence that the IO actions may be performed multiple times. So I recon that, if the IO actions are idempotent, there would be no problem. Am I correct? Regards, Robert

2 1

Re: ghc and cabal
by Lemmih 06 Aug '05

06 Aug '05

On 8/6/05, Serge D. Mechveliani <mechvel(a)botik.ru> wrote: > On Aug 05, 2005 we wrote: > > > "Serge D. Mechveliani" <mechvel(a)botik.ru> writes: > > > > > Which Cabal version will be in official ghc-6.4.1 by default? > > > > > It'll be 1.0 with some bug fixes (Simon: can you please make the > > version number '1.0.1'?) > > > > > > If it is 1.0, then ghc-6.4.1 will fail with `make' for profiling. > > > So, the user needs to install another Cabal version and to link it > > > to GHC, and this occurs difficult. This is likely to complicate the > > > usage of GHC > > > > Yep. Profiling support won't be there, but some of the problems you > > faced in building a separate Cabal will hopefully be fixed in the new > > version of GHC. > > > First, I tried to test profiling in ghc-6.4.1-pre-release, > and could not -- due to this misfeature with "_p" modules in > Cabal-1.0. > Generally, what I need: > fresh GHC with working profiling, with Cabal processing > "_p" module suffixes, and such > (in runhaskell Setup build, install). > > If official ghc-6.4.1 (with default Cabal version) has not the > needed feature, then, the next question is > > which higher Cabal version supports such `make' for profiling? > > After I know the answer to this, I could start searching for possible > _simple instructions_ for the users of GHC and its applications on > how to upgrade Cabal in their installed ghc-6.4.1. Such instructions > that are clear almost to everyone, not only to system hackers. > > If all this occurs difficult to arrange, then the profiling occurs > delayed to future official GHC versions. (If I've completely misunderstood the question please ignore me :) Guide to profiling in Cabal: Step 1: Installing a new Cabal You can either download Cabal 1.1.1 from the webpage or pull it from http://cvs.haskell.org/darcs/cabal with darcs. When you got the source tree you install it as any other Cabal package. [global installation] $ runhaskell Setup.lhs configure $ runhaskell Setup.lhs build $ sudo runhaskell Setup.lhs install [user installation, GHC <= 6.4 wont like this] $ runhaskell Setup.lhs configure --prefix=/your/desired/prefix $ runhaskell Setup.lhs build $ runhaskell Setup.lhs install --user Step 2: Compiling Cabal packages with profiling. You can now pass '-p' or '--enable-library-profiling' when you configure a package and the .cabal file will have a new stanza call GHC-prof-options for profiling options. -- Friendly, Lemmih

1 0

unsafePerformIO and optimizations
by Wolfgang Jeltsch 06 Aug '05

06 Aug '05

Hello, http://haskell.org/ghc/docs/latest/html/libraries/base/ System.IO.Unsafe.html#v%3AunsafePerformIO talks about what optimizations you should disable if you apply unsafePerformIO to an action which contains side effects. These are: * inlining of functions which call unsafePerformIO * common subexpression elimination (on the module which contains the unsafePerformIO application, if I understand correctly) * let-floating Alas, the documentation is very terse, in my opinion, and I don't understand these things fully. First, what is the problem with inlining a function call? Say, I have a function f defined as follows: f :: Char -> () f c = unsafePerformIO (putChar c) If inlining is allowed, the expression f '*' becomes unsafePerformIO (putChar '*'). Is this a problem? Or is inlining dangerous in other situations? On the other hand, I can see that inlining non-functions could cause harm. Say I have something like this: u :: () u = unsafePerformIO (putChar '*') Now, inlining u would transform (u,u) to (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) which could result in putChar '*' being executed multiple times. So why does the library documentation only talk about disabling inlining of functions? I understand that common subexpression elimination could cause harm. It could transform the expression (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) to let u = unsafePerformIO (putChar '*') in (u,u), couldn't it? This would result in the I/O action be performed at most once which is not what was intended. But couldn't the same thing also happen if I use the expression (f '*',f '*'), probably in a different module? Does this mean that I have to use -fno-cse not only in the module which contains the unsafePerformIO application but also in every other module which uses unsafePerformIO indirectly via f or functions using f? Does let-floating only have to be disabled in the module which uses unsafePerformIO? Say, I have f defined as above and have the following definition in a module different from the one f is defined in: g :: Int -> () g n = f '*' Couldn't it be that the asterisk is output only once instead of every time, g is called? I would be thankful for any help. Best regards, Wolfgang

1 0

Inductive kinds
by Geoffrey Alan Washburn 06 Aug '05

06 Aug '05

Are there any plans for inductively defined kinds in some future version of GHC?

1 0

ghc and cabal
by Serge D. Mechveliani 06 Aug '05

06 Aug '05

Dear GHC developers, dear Cabal developers, To my report >> I have `made' ghc-6.4.1.20050801 >> >> Without profiling, it `makes' and installs. >> For profiling, dm.cabal adds >> -prof -auto-all -hisuf p_hi -osuf p_o >> to its options. >> The commands >> runhaskell Setup configure --ghc --prefix=$dmSource/inst >> runhaskell Setup build >> >> seem to work all right. Then, runhaskell Setup install --user >> reports >> Installing: /home/mechvel/dm/1.03/dm/source/inst/lib/dumatel-1.3 & >> /home/mechvel/dm/1.03/dm/source/inst/bin dumatel-1.3... >> Error: Could not find module: Dumatel with any suffix: ["hi"] >> >> And the directory $dmSource/dist/build/ contains >> Dumatel.p_hi, Dumatel.p_o >> among its files. >> [..] Simon Marlow writes that I need to install the later version of Cabal independently on GHC. I do have some difficulties with this, because Cabal-1.1.1 `README' suggests just to run `make install' as a root, I do not see any configureing possibility for the installation, and so on. But, in principle, what is the relation between Cabal and GHC installation? In ghc-6.4.1.20050801, `ghci -package Cabal' says "Cabal-1.0". I have read some of Cabal manual, about how to use runhaskell. But as I recall, I never installed Cabal. GHC has installed it itself. (?) Which Cabal version will be in official ghc-6.4.1 by default? If it is 1.0, then ghc-6.4.1 will fail with `make' for profiling. So, the user needs to install another Cabal version and to link it to GHC, and this occurs difficult. This is likely to complicate the usage of GHC (?) Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

6.4.1 release candidate testing
by Simon Marlow 05 Aug '05

05 Aug '05

This is to announce that testing for 6.4.1 has begun. Snapshots from 20050730 onwards are release candidates - please test if you can. Snapshots are available from here: http://www.haskell.org/ghc/dist/stable/dist/ we have source snapshots, and binaries for Linux/x86 (RH 9.1 era), Linux/x86_64 (FC3 era), and Windows. A *huge* number of fixes have gone in since 6.4. Also, big news is that Linux/x86_64 will have a new native code generator and GHCi support (including Template Haskell), so we'd especially like to hear from anyone that can test on Linux/x86_64. The GHCi support isn't complete: the interpreter can't currently handle FFI, and there are problems with data references to shared libraries from dynamically-loaded .o files, but otherwise it should be functional. We're planning for a release in 1-2 weeks. I'm going to be offline for a while from mid-Aug, but hopefully we'll get the release out before then. Please remember to put the full version number in any bug report, and happy testing! Cheers, Simon

7 10

Problem with SHGetFolderPath using Cabal on Windows 98
by Toby Allsopp 05 Aug '05

05 Aug '05

When trying to use Cabal (e.g. running `runghc Setup.lhs' for HSQL or running `ghci -package Cabal') on Windows 98, I get an error like the following: C:/GHC/GHC-6.4.1/HSCabal.o: unknown symbol `_SHGetFolderPathA' This happens with GHC 6.4 and ghc-6.4.1.20050803-i386-unknown-mingw32.tar.gz. I believe that the problem is that the SHGetFolderPath function is not included in SHELL32.DLL in Windows 98. If the appropriate updates are installed (new IE, I think) then it is available in SHFOLDER.DLL. It is also available in SHFOLDER.DLL in later versions of Windows. I also believe, but haven't been able to verify, that #includeing <shfolder.h> before using SHGetFolderPath will fix it. I guess changing something in libraries/Cabal/Distribution/Simple/Configure.hs will do the trick, but I don't know much about the FFI. Cheers, Toby.

1 1

RE: 6.4.1 release candidate testing
by Simon Marlow 04 Aug '05

04 Aug '05

On 04 August 2005 11:43, Ralf Hinze wrote: >> Please ignore last night's snapshot (3/8), something is broken. > > The message came in too late ;-). Anyway, 3/8 compiled fine (using > 1/8) > and it seems to work. Environment: > > patronus ghc-6.4.1.20050803 # uname -a > Linux patronus 2.6.12-gentoo-r7 #1 Wed Aug 3 18:57:28 CEST 2005 > x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux > > BTW, I am especially thankful that ghci works again! 3/8 works, but there is a bug in the simplifier that means that in rare cases your program may go *very* slowly. I've just fixed it, anyway. Cheers, Simon

1 0