- Glasgow-haskell-users

STM and unsafePerformIO
by Robert van Herk 03 Aug '05

03 Aug '05

Hello All, I think I've read somewhere that STM doesn't like unsafePerformIO. However, I would like to use a global STM variable. Something like this: *module* Main *where* import GHC.Conc import System.IO.Unsafe tSid = unsafePerformIO (atomically (newTVar 0)) tickSessionID :: STM Int tickSessionID = *do* sid <- readTVar tSid writeTVar tSid (sid + 1) return sid main = atomically tickSessionID But, when I try this, the evaluation of main causes a segmentation fault. Is there a workaround for this bug? Regards, Robert

2 3

RE: STM and unsafePerformIO
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 11:51, Robert van Herk wrote: > I think I've read somewhere that STM doesn't like unsafePerformIO. > However, I would like to use a global STM variable. Something like > this: > > *module* Main *where* > import GHC.Conc > import System.IO.Unsafe > > tSid = unsafePerformIO (atomically (newTVar 0)) > > tickSessionID :: STM Int > tickSessionID = > *do* sid <- readTVar tSid > writeTVar tSid (sid + 1) > return sid > > main = atomically tickSessionID > > But, when I try this, the evaluation of main causes a segmentation > fault. Is there a workaround for this bug? You're ok as long as the global variable doesn't get evaluated inside another atomically. The problem is that nested atomically isn't supported; the RTS gets confused. For example, you could say main = do evaluate tSid ... to force evaluation of tSid before doing anything else. Cheers, Simon

1 0

RE: Bug in placing _stub.o files with HEAD
by Simon Marlow 03 Aug '05

03 Aug '05

On 01 August 2005 15:19, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> I thought I fixed this in CVS recently (rev. 1.54 of >> Distribution.Simple.Build to be exact). Are you running Cabal from >> CVS, or some other version? > > Cabal from CVS. The versions are GHC 6.5.20050728 and Cabal-1.1.2. > > I created a small Cabal package to demonstrate the problem. > http://www.cs.helsinki.fi/u/ekarttun/haskell/test-hs-source-dirs-w-fexp. tar.gz > > The _stub.o file is not added into the static library. Thanks, should be fixed now. Cheers, Simon

1 0

RE: Installation problem
by Simon Marlow 03 Aug '05

03 Aug '05

On 02 August 2005 20:00, Dieter Büttner wrote: > I have a X86_64 architecture. So you may be right. In which lib > directory ghc-6.4-1 is looking for libgmp? There I could install the > 32 bit version. It depends on which flavour of Linux you have, but for example on our Fedora Core 3 box here: > locate libgmp /usr/lib64/libgmpxx.so.3 /usr/lib64/libgmpxx.so.3.0.5 /usr/lib64/libgmp.so.3.3.3 /usr/lib64/libgmp.a /usr/lib64/libgmpxx.so /usr/lib64/libgmpxx.a /usr/lib64/libgmp.so.3 /usr/lib64/libgmp.so /usr/lib/libgmpxx.so.3 /usr/lib/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libgmpxx.so.3.0.5 /usr/lib/sse2/libgmp.so.3.3.3 /usr/lib/sse2/libgmp.so.3 /usr/lib/libgmp.so.3.3.3 /usr/lib/libgmp.so.3 Cheers, Simon

1 0

RE: making ghc-6.4.1-august-1
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 08:06, Serge D. Mechveliani wrote: > I tried to make ghc-6.4.1.20050801-src.tar.bz2 > > with ghc-cvs-6.4.1-july-12 on Debian Linux. > > ( > uname -m > i686 > > uname -r > 2.4.27-2-686-smp > ). > > It reports > > --------------------------------- > ... > System/Directory/Internals.hs:1:0: > conflict: module `System.Directory.Internals' > belongs to the current program/library and also to package > base-1.0 <<ghc: 19592712 bytes, 5 GCs, 79280/79280 avg/max bytes > residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.11 MUT > (0.33 elapsed), > 0.10 GC (0.09 elapsed) :ghc>> > make[4]: *** [System/Directory/Internals.o] Error 1 > --------------------------------- > > Should I install ghc-6.4.1.20050801-binary and then compile its > source? Yes, please try building with either 6.4 or the latest 6.4.1. There may be intermediate stages that have problems. Cheers, Simon

1 0

making ghc-6.4.1-august-1
by Serge D. Mechveliani 03 Aug '05

03 Aug '05

I tried to make ghc-6.4.1.20050801-src.tar.bz2 with ghc-cvs-6.4.1-july-12 on Debian Linux. ( > uname -m i686 > uname -r 2.4.27-2-686-smp ). It reports --------------------------------- ... System/Directory/Internals.hs:1:0: conflict: module `System.Directory.Internals' belongs to the current program/library and also to package base-1.0 <<ghc: 19592712 bytes, 5 GCs, 79280/79280 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.00 elapsed), 0.11 MUT (0.33 elapsed), 0.10 GC (0.09 elapsed) :ghc>> make[4]: *** [System/Directory/Internals.o] Error 1 --------------------------------- Should I install ghc-6.4.1.20050801-binary and then compile its source? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Installation problem
by Simon Marlow 02 Aug '05

02 Aug '05

On 30 July 2005 12:58, Dieter wrote: > I'm using Linux 9.3 on a PC with a 64-architecture. > > I'd like to install GHC and thought the easiest way would be to take > an appropriate rpm-file.So I downloaded an rpm file, it was said to > running with SUSE 9.2 without problems. > But when starting rpm -i ghc.-6.4-1.i386.rpm I got the message: > > error: Failed dependencies: > libgmp.so.3 is needed by ghc-6.4-1 > > But it is installed on my systems. I downloaded it again and > installed it again and copied it (3 files: - the symlink libgmp.so, > the symlink libgmp.so.3 and the file the libgmp.so.3.3.3) into > several lib directories. NO SUCCESS > > What is wrong? > Has anyone an idea? Are you running an x86_64 OS, or just a plain i386 one? If you're running x86_64, then perhaps you only have the 64-bit version of libgmp installed? Cheers, Simon

2 1

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

02 Aug '05

On 01 August 2005 15:07, Simon Marlow wrote: > 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. I forgot to mention: 6.4.1 will also have some big changes to the package system. Primarily: - A local module can shadow a package module with the same name, as long as the conflicting package is not otherwise depended upon somehow. - If two modules are in scope with the same name, the conflict will not be reported until you try to import the module. these together mean it is much less likely that you can render your GHC installation unusable by installing packages. Also, as discussed on the libraries list recently: - specifying -package P without an explicit version number on P gets you the most recent version of P, instead of an error. - if multiple versions of a package are exposed, then GHC takes the one with the latest version in the absence of any -package options that specify otherwise. We'd like to hear from anyone involved in packaging libraries whether these changes work for you. The new version of Cabal will *not* be in 6.4.1, but it'll be easy to upgrade. Cheers, Simon

1 0

problems building trhsx-0.2 with ghc-6.5.20050723
by Konovalov, Vadim 01 Aug '05

01 Aug '05

I built and installed ghc-6.5.20050723 on Linux from sources successfully, and it looks quite normally-working. I've stepped into a problem building trhsx from a package haskell-src-exts-0.2.tar.gz with a quite unexpected (for me) message: Preprocessing executables for trhsx-0.2... Building trhsx-0.2... hsSourceDirs: ["."] Chasing modules from: Hsx.hs Hsx.hs:6:7: Could not find module `Data.List': it is a member of package base-1.0, which is hidden Lines in error is quite innocent-looking: import Data.List (intersperse, isPrefixOf) GHC version 6.4 builds that module okay. Is that error is due to beta version of ghc-6.5.20050723, or I am misunderstanding some configuration issues? TIA, Vadim.

2 1

RE: Bug in placing _stub.o files with HEAD
by Simon Marlow 01 Aug '05

01 Aug '05

On 30 July 2005 01:21, Einar Karttunen wrote: > I noticed the following behaviour using GHC 6.5.20050728: > If compiling a Cabal package containing hs-source-dirs it > places the _stub.o under dist/build/<source-dir>/path/to/Module > when Cabal expects it in dist/build/path/to/Module. Things > appear to work without hs-source-dirs. > > For example with "hs-source-dirs: src" > Network/GnuTLS/IOWrap.hs contains foreign export declarations. > runnning Setup build creates the files: > dist/build/src/Network/GnuTLS/IOWrap_stub.o > src/Network/GnuTLS/IOWrap_stub.h > src/Network/GnuTLS/IOWrap_stub.c > > But Cabal fails to include the IOWrap_stub.o as it is > expected as dist/build/Network/GnuTLS/IOWrap_stub.o I thought I fixed this in CVS recently (rev. 1.54 of Distribution.Simple.Build to be exact). Are you running Cabal from CVS, or some other version? Cheers, Simon

2 1