September 2002 - Glasgow-haskell-users

RE: comparison of execution speed of array types
by Zdenek Dvorak 20 Jan '03

20 Jan '03

Hello, >DiffArray seems to be broken :). Either that or I'm using it >incorrectly. I've attached the relevant code, but when I don't reverse >the array everything works fine; when I reverse it the program doesn't >(seem to) halt. I've tried to use DiffArray recently and it is terribly slow. I was forced to write my own version (it is a bit faster, but still nothing great). My suspicion about the result of your measuring is that it does the updates in reversing the array one by one, thus leading to quadratic behavior. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

mergesort. Reply
by Serge D. Mechveliani 21 Oct '02

21 Oct '02

Ketil Z. Malde <ketil(a)ii.uib.no> writes > I'll hereby argue for using a quicksort implementation akin to > >> sortBy' _ [] = [] >> sortBy' pc (x:xs) = let (l,e,g) = part3 (`pc` x) xs >> in sortBy' pc l ++ (x:e) ++ sortBy' pc g >> where >> part3 comp xs = p3 [] [] [] comp xs >> p3 ls es gs _ [] = (ls,es,gs) >> p3 ls es gs comp (x:xs) = case comp x of >> LT -> p3 (x:ls) es gs comp xs >> EQ -> p3 ls (x:es) gs comp xs >> GT -> p3 ls es (x:gs) comp xs > > (hopefully this is fairly bug-free) At least for my data (lots of > values, limited range), it appears to speed things up tremendously. I > haven't measured more general cases in any detail, though. And one > obvious drawback may be that it's not stable, which I think can be > alleviated by a few well placed 'reverse's. > > Comments welcome! But sortBy' (compare) [1 .. n] costs too much, even for n = 11000. It costs (on worst data) many times more than mergeSort. ----------------- Serge Mechveliani mechvel(a)botik.ru

8 11

RE: unsafePerformIO
by Simon Marlow 09 Oct '02

09 Oct '02

> But it is a fact that many of us have at least some idea of > what happens "under the hood" when we use unsafePerformIO. > This is also described in your paper "Stretching the storage > manager: weak pointers and stable names in Haskell". > > However, I for example have no idea what happens when > unsafely executing something that throws exceptions, > performs a forkIO, something that uses MVar's, etc. Exceptions: an exception raised by the computation inside unsafePerformIO will be propagated to the enclosing expression, as per the normal semantics for imprecise exceptions. The exception raised by an application of unsafePerformIO may of course also be imprecise; consider 'unsafePerformIO $ (1/0 + error "foo") `seq` return ()'. The behaviour of forkIO and other side-effecting operations inside unsafePerforIO can I think be explained by the following statement: if an expression "unsafePerformIO e" has been reduced to head normal form, then all the I/O computations in e have been performed. The exact timing of the evaluation is underspecified, just as any other expression in Haskell. However, if you're using unsafePerformIO with real side effects, then I suspect that what you're doing is highly dodgy and you should find another way to do it :-) Does that help? As for sharing, we currently don't provide any guarnatees, although we should. It is currently the case that if you write a = unsafePerformIO (putStr "hello") b = unsafePerformIO (putStr "hello") and both a and b are evaluated, then you may get either one or two "hello"s on stdout. You can currently make things more deterministic by (a) adding NOINLINE pragmas for a and b, and (b) using the flag -fno-cse to disable common sub-expression elimination. Then you'll get exactly two instances of "hello" on stdout, although we won't guarantee that behaviour for ever. At some point we'll fix it so that unsafePerformIO applications are never duplicated or coalesced. If you're interested in when unsafePerformIO is "safe" to use, see: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003683. html (and see my followups for an alternative view). Cheers, Simon

2 1

RE: IO-System
by Simon Marlow 01 Oct '02

01 Oct '02

> I'm, analysing the IO-system of the GHC and need more > information about > it. > More precisely: How switches the run-time-system between (normal) > evaluation and performing of IO-actions? > > I read the rts-paper, but didn't find any information about this. > > Can somebody give a short review, or are ther any other > papers available? The runtime system mostly has no concept of IO vs. non-IO evaluation. The IO monad is implemented as the following type: newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #) which means that an IO action is simply a function from the world state to a pair of a new world state and a value. In other words, it's a straightfoward state monad, except that we use some optimised representations to eliminate some of the overhead of passing the state around. Cheers, Simon

6 8

RedHat 7.2 RPMs available
by Simon Marlow 27 Sep '02

27 Sep '02

Thanks to Jeff Lewis, there are now RedHat 7.2 RPMs available from the GHC download page. http://www.haskell.org/ghc/download_ghc_504.html If you're running RedHat 7.2, and previously downloaded the 7.3 RPMs, we recommend you install these instead to avoid some strange behaviour with System.system. Cheers, Simon

1 0

RE: specifying the name of the executable under Windows
by Simon Peyton-Jones 25 Sep '02

25 Sep '02

foo.exe, not foo. I'll mention this in the user manual S | -----Original Message----- | From: Wolfgang Jeltsch [mailto:wolfgang@jeltsch.net] | Sent: 24 September 2002 22:30 | To: The Glasgow Haskell Users Mailing List | Subject: specifying the name of the executable under Windows | | Hi, | | if I enter | ghc -o foo foo.hs | under Windows, is the resulting executable named foo or foo.exe? | | (Please send replies not only to the list as I'm not subscribed to it.) | | Wolfgang | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Newbie building GHC
by Simon Marlow 25 Sep '02

25 Sep '02

> The reason that this worries me is that Cygwin "ld" links > with libraries > from the Cygwin "lib" directory rather than the Mingw > equivalent, regardless > of which "gcc" was used to compile the object files. We only use ld directly when building the GHCi libraries (HSbase.o etc.), and this doesn't use any external libraries, so I think we're ok here. Normal linking of Haskell programs is done using gcc, so we'll get the right version of ld there. Cheers, Simon

1 0

Kanser Tedavisi
by carctol＠yahoo.com 24 Sep '02

24 Sep '02

charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII" Reply-To: carctol(a)yahoo.com Date: Wed, 25 Sep 2002 01:19:00 +0300 X-Priority: 3 X-Library: Indy 9.00.10 X-Mailer: Foxmail Kemoterapinin yan etkileri nedeniyle yorgun ve bitkin d�sm�s bir yakininiz mi var? Yanitiniz evetse vakit kaybetmeyin ve CARCTOL'u denemesini saglayin. Genelde ancak klasik tedavinin ise yaramadiginin anlasilmasi, insanlari baska se�enekler aramaya itmektedir, ancak o durumda maalesef yapacak fazla birsey kalmamaktadir. Ayni hatanin yapilmasina izin vermeyin ve hi�bir yan etkisi olmayan, Himalaya Dagi bitkilerinden �retilen Carctol'u denemesini saglayin. CARCTOL, birka� bin yillik, alternatif Hint Tibbinin (Ayuverda'nin) insanliga sundugu bir umut isigidir. �nceleri v�cudu takviye edici tonik olarak kullanilan bu �r�n simdi yeni form�l�yle kansere karsi etkili bir ila�tir L�tfen asagidaki siteye ugrayin ve Carctol'u yakindan taniyin. http://www.kanser-tedavisi.com esenlikler dileriz. Listeden adinizin silinmesini istiyorsaniz a_cengiz2002(a)yahoo.com a bos e posta yollayin. Tesekk�rler

1 0

specifying the name of the executable under Windows
by Wolfgang Jeltsch 24 Sep '02

24 Sep '02

Hi, if I enter ghc -o foo foo.hs under Windows, is the resulting executable named foo or foo.exe? (Please send replies not only to the list as I'm not subscribed to it.) Wolfgang

1 0

RE: Newbie building GHC
by Simon Marlow 24 Sep '02

24 Sep '02

> | In retrospect I think that unless "configure" is doing something > really > | tricky, if you want the Mingw32 "ar" and "ld" to be picked > up instead > of the > | Cygwin equivalents then you must have the Mingw32 bin directory in > your path > | ahead of the Cygwin bin directory. > > The right thing to do is what the building guide says. > > The GHC build system is careful to use the newly-built GHC > for compiling > even .c files, and for doing linking. The newly-built GHC > will use the > gcc that you point to with the --with-gcc configure command. > It will not > use a path in any shape or form (unless you omit --with-gcc in which > case it'll pick whatever random gcc is lying around; probably not the > right one). > > The only way I know to make all this work is to use a straightforward > Cygwin environment for building (with absolutely no mingw > stuff in your > path) and use --with-gcc in your configure line. Other > things may work, > but you're on your own. I think Mike has a point here - unless mingw is first in your PATH, you get the cygwin binutils (ar, ld, maybe even as?) which could conceivably be a problem if they behave differently from the mingw versions. Presumably they don't, however, so we get away with it. FWIW, I recently build GHC on cygwin/mingw using the instructions from the building guide and it worked fine. Cheers, Simon

2 1