- Glasgow-haskell-users

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

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