August 2005 - Glasgow-haskell-users

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

04 Aug '05

Please ignore last night's snapshot (3/8), something is broken. Cheers, Simon

2 1

problems building trhsx-0.2 with ghc-6.5.20050723
by Niklas Broberg 04 Aug '05

04 Aug '05

> Cabal hides all packages when using GHC 6.5. Add 'base' to > build-depends in trhsx's cabal file and send a patch to the author. Lemmih has it right, I haven't gone over and fixed this in my packages. I guess I should... Vadim, thanks for the patch. /Niklas

1 0

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

04 Aug '05

On 03 August 2005 16:35, Gour wrote: > Christian Maeder (maeder(a)tzi.de) wrote: > >> What is the name of the cvs tag that I sould use, then? >> >> (currently I have "ghc-6-4-branch") > > I'm not sure about that. > > I simply downloaded from ghc-6.4.1.20050801-src.tar.bz2 from > > http://www.haskell.org/ghc/dist/stable/dist/. ghc-6-4-branch is the right tag if you're getting sources from CVS. Cheers, Simon

1 0

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

03 Aug '05

On 03 August 2005 09:58, Gour wrote: > Gabriel Ebner (ge(a)gabrielebner.at) wrote: > >> I think you can do away with the first line too, I've just done a >> successful build with split objects on gentoo/amd64. > > Is there any advantage in split-build? Binary sizes are smaller (much smaller). Cheers, Simon

3 4

RE: 6.4.1 release candidate testing under solaris
by Simon Marlow 03 Aug '05

03 Aug '05

On 03 August 2005 12:54, Christian Maeder wrote: > I get for the cvs version of today under solaris: > > Cheers Christian > > [...] > stage1/ghci/ByteCodeItbls.o: In function `s641_info': > ghc11717.hc:(.text+0x2c38): undefined reference to `stgMallocBytesRWX' > collect2: ld returned 1 exit status > <<ghc: 13100660 bytes, 3 GCs, 145896/145896 avg/max bytes residency (1 > sample > s), 15M in use, 0.01 INIT (0.00 elapsed), 0.13 MUT (11.37 elapsed), > 0.01 GC ( > 0.04 elapsed) :ghc>> > gmake[2]: *** [stage1/ghc-6.4.1] Error 1 > gmake[1]: *** [all] Error 1 I think you must be building using an earlier 6.4.1 snapshot. You can workaround the problem by disabling GHCI: add GhcWithInterpreter=NO to mk/build.mk. You can turn it back on again before building stage2, if you like. Cheers, Simon

1 0

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

03 Aug '05

On 03 August 2005 13:20, Gour wrote: > Simon Marlow (simonmar(a)microsoft.com) wrote: > >> That's right, split objects is now working on amd64 too. > > Confirmed. > >> That's what I like to hear, bugs that fix themselves! > > Here is another one of those, i.e. there are several problems with > the docs > building, e.g.: Thanks, fixed. Simon

1 0

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

03 Aug '05

On 03 August 2005 09:27, Gabriel Ebner wrote: > Gour wrote: > >>> I don't notice any particular tweaking in the ghc ebuild. Did you >>> uncomment the GhcWithInterpreter and SplitObjs lines in the ebuild? >> >> I just tweaked the 2nd line to: >> >> use ppc64 && echo "GhcWithInterpreter=NO" >> mk/build.mk >> >> so I can get 'ghci' built. > > I think you can do away with the first line too, I've just done a > successful build with split objects on gentoo/amd64. That's right, split objects is now working on amd64 too. >>> I'll try to rebuild ghc on my gentoo box, maybe it works this >>> time... >> >> Pls. report back if everything is fine. > > I must've touched the magic switch. Now it's running just fine. > Apparently HTYPE_TCFLAGS_T got undef'd the first time, but now it's > good, although I don't know what I did. That's what I like to hear, bugs that fix themselves! Cheers, Simon

2 1

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