July 2005 - Glasgow-haskell-users

RE: switching off let-floating
by Simon Marlow 28 Jul '05

28 Jul '05

On 28 July 2005 10:41, Wolfgang Jeltsch wrote: > Am Mittwoch, 27. Juli 2005 21:39 schrieben Sie: >> "Wolfgang Jeltsch" <wolfgang(a)jeltsch.net> writes: >> >> .... >> >>> But how do I switch off let-floating? >> >> -fno-full-laziness, I believe. > > I just tried using this flag. Result: GHC 6.2.2 doesn't recognize > it. :-( That switch was added in 6.4. In 6.2 and earlier, there's no way to turn off full-laziness other than -Onot, as far as I'm aware. Cheers, Simon

4 7

GHC 6.4 Debian packages (was: Re: switching off let-floating)
by Wolfgang Jeltsch 28 Jul '05

28 Jul '05

Am Donnerstag, 28. Juli 2005 16:45 schrieben Sie: > On Thu, 28 Jul 2005, Wolfgang Jeltsch wrote: > (snip) > > > Related question: Can anybody tell me when there will be Debian packages > > of GHC 6.4 available? > > See http://packages.debian.org/unstable/devel/ghc6 > > -- Mark Okay, I wasn't precise enough. What I'm looking for are GHC 6.4 packages for Debian stable. Alas, the GHC website as well as Haskell Experimental or whatever it is called now don't have a respective backport. Regards, Wolfgang

1 0

switching off let-floating
by Wolfgang Jeltsch 28 Jul '05

28 Jul '05

Hello, I thought I had asked this before but I cannot find a corresponding mail from me in the archives and, in addition, cannot remember to have gotten an answer. The library documentation of unsafePerformIO in http://haskell.org/ghc/docs/latest/html/libraries/base/ System.IO.Unsafe.html#v%3AunsafePerformIO says: "Make sure that the[?] either you switch off let-floating, [...]". But how do I switch off let-floating? Regards, Wolfgang

2 4

RE: turning off garbage collection
by Simon Marlow 27 Jul '05

27 Jul '05

On 27 July 2005 05:48, Bernard Pope wrote: > I'm fairly sure this has been asked before (and recently too), but I > can't seem to find it in the archives. Sorry for the repetition. > > Is there a way I can turn garbage collection off in GHC? I'm happy to > hack the runtime and comment out code if that is the only way. I just > don't know which code. > > I want to see what effect GC is having on programs that run under > buddha. I suspect it is costing me a lot in time traversing large > amounts of data that the debugger is hanging on to. You can always see the proportion of GC time by using +RTS -sstderr. You can also set a gigantic allocation area with +RTS -A1G. Really disabling GC would entail just allocating more and more memory in the allocation area, and the RTS doesn't know how to do that at the moment (the alloc area is more or less fixed between GCs). Also, you'd very quickly eat all the swap in your system, so perhaps this isn't what you want. Cheers, Simon

2 1

turning off garbage collection
by Bernard Pope 27 Jul '05

27 Jul '05

Hi, I'm fairly sure this has been asked before (and recently too), but I can't seem to find it in the archives. Sorry for the repetition. Is there a way I can turn garbage collection off in GHC? I'm happy to hack the runtime and comment out code if that is the only way. I just don't know which code. I want to see what effect GC is having on programs that run under buddha. I suspect it is costing me a lot in time traversing large amounts of data that the debugger is hanging on to. Cheers, Bernie.

1 1

RE: ghc-pkg query feature request
by Simon Marlow 26 Jul '05

26 Jul '05

On 26 July 2005 09:23, Lennart Kolmodin wrote: > When working with multiple versions of a package you often want to use > the most recent version. > A feature that would help for package systems is to be able to query > ghc-pkg for the best version, or to list the versions in increasing > version order. > > Something like: > > $ ghc-pkg best_version Cabal > Cabal-1.1.1 > > $ ghc-pkg versions Cabal > Cabal-1.0 Cabal-1.1.1 > > You get the picture. Obviously, this feature isn't critical since we > could use 'ghc-pkg list' and work our way from there, but it would be > nice. If you like the idea we might send you a patch. > What do you think? Sure, I'll commit a patch if you send one. Perhaps $ ghc-pkg list Cabal Cabal-1.0 Cabal-1.1.1 would be the simplest extension? Cheers, Simon

2 1

RE: Contexts differ in length
by Simon Peyton-Jones 26 Jul '05

26 Jul '05

I revisited the typechecking of binding groups, partly to fix the shortcomings of SPECIALISE pragmas. On the way, I implemented the refined dependency analysis described by Mark Jones in "Typing Haskell in Haskell". As a result, this "Contexts differ in length" problem has gone away. Robert, would you like to give it a try? Your example below is now part of GHC's test suite. It'll be in the next major release, but not in 6.4. Simon | -----Original Message----- | From: Robert van Herk [mailto:rherk@cs.uu.nl] | Sent: 24 May 2005 13:31 | To: glasgow-haskell-users(a)haskell.org; Simon Peyton-Jones | Subject: Contexts differ in length | | Hi all, | | A while ago I sent an email to the glasgow haskell users maillinglist to | explain how the "Contexts differ in length" feature (or bug :-)) | restricted me in writing a haskell application. I was hoping for a | reply, however I didn't receive one (yet). | | Therefore, I will explain the problem again: | | I am writing (for my master's thesis project) a webdevelopment framework | in Haskell, with features somewhat comparable to Apple's WebObjects. | Amongst others, session state and database interaction is transparent, etc. | | In my framework, functions that generate HTML are called WFComponents. | These functions are monadic since they can generate IO (because they may | do database interaction etc). Also, components can generate links to | other components. However, since component a may generate a link to | component b (so that when the user clicks that link component b will be | evaluated) and component b may link to component a, there will occur | errors when I try to do this, since the contexts of component a and b | may not be the same. A minimal example of this will be something like: | | {-# OPTIONS -fglasgow-exts #-} | | module Main where | import Data.IORef | | class MyReader r v | r -> v where | myRead :: r -> IO v | | data R v = R (IORef v) | instance MyReader (R v) v where | myRead (R v) = | do v <- readIORef v | return v | | | a :: IO () | a = | do r <- createReader | b r | | b :: MyReader r Int => r -> IO () | b r = | do i <- myRead r | if i > 10 | then a | else putStrLn (show i) | | createReader :: IO (R Int) | createReader = | do ref <- newIORef 0 | return (R ref) | | | | A real example will be a bit more complicated, but this is basically | what I need to do and currently am not able to. Of course, when needed, | I can show you the real example. Somewhere in the history of this | mailling list I read that people have had this program before, but only | in toy programs. However, I am experincing this problem currently in | something that is not a toy program. Therefore, my question is if it | would be possible to lift this constraint on the language, and also, if | the developers of GHC are currently planning to do this... | | Thanks, | | Robert

2 1

ghc-pkg query feature request
by Lennart Kolmodin 26 Jul '05

26 Jul '05

Hi! When working with multiple versions of a package you often want to use the most recent version. A feature that would help for package systems is to be able to query ghc-pkg for the best version, or to list the versions in increasing version order. Something like: $ ghc-pkg best_version Cabal Cabal-1.1.1 $ ghc-pkg versions Cabal Cabal-1.0 Cabal-1.1.1 You get the picture. Obviously, this feature isn't critical since we could use 'ghc-pkg list' and work our way from there, but it would be nice. If you like the idea we might send you a patch. What do you think? Cheers, Lennart Kolmodin -- "The only thing that interferes with my learning is my education." -- Albert Einstein

1 0

RE: the FFI and C reference counting
by Simon Marlow 25 Jul '05

25 Jul '05

On 24 July 2005 14:05, Peter Gammie wrote: > After much head scratching I can only think that the following is > happening: > > 1. Create BDD, BDD.refcount++, add finalizer. > 2. BDD becomes unreferenced but not yet GC'd. > 3. Call BDD operation returning the same BDD as step 1. (call it BDD') > 4. GHC's GC kicks in and BDD.refcount--. (*) > 5. BDD'.refcount++, add finalizer. > > At (*), CUDD deallocates BDD (== BDD') and BDD' becomes a dangling > pointer. > > Is this plausible? Looks plausible to me. The API is being a bit naughty by not incrementing the reference count on an object it returns - this would be ok if the API function returning the object can be sure that the ref count is already at least 1, but in this case it appears that you have been handed an object which has a ref count of possibly 0, which seems bad. I wonder what reasoning the API is using to justify this. COM is another reference-counted API. In COM, the convention is that a returned object will have its reference count already bumped, you have to explicitly Release() it. See QueryInterface(), for example. However, passing an object to a method in COM doesn't require bumping the reference count, but the caller is holding the object so it can be sure the reference count remains non-zero for the duration of the call. > On a related note: what impact will multi-core GHC have on code like > this? > I get queasy thinking of how it will interact with all those > non-threadsafe C libraries bound in a style similar to the above... Using COM in the Visual Studio extension, we ran into trouble just using the multi-threaded RTS, never mind multi-core. The problem is that the finalizer runs in a different thread than the original thread that created the object, so if the act of decrementing the reference count is not a thread-safe operation, you're in trouble. We had to switch to explicit reference counting operations instead of finalizers in COM code (it isn't too bad, actually). Cheers, Simon

1 0

RE: Performance week 25/6-29/6
by Simon Marlow 25 Jul '05

25 Jul '05

On 25 July 2005 10:07, Ketil Malde wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> We're interested in performance issues with both GHC itself and >> GHC-compiled code. > > I can think of a couple of things. > > One is the performance of Int64 (which unsurprisingly is inferior to > Int(32) but more surprisingly, also to Integer). I've reported it > previously, but can dig it up again, if desired. Added to the list, thanks. > The other is probably not as relevant, but I'll mention it anyway. I > occasionally use rather large arrays, and UArrays can save a > considerable amount of space. Sometimes, however, I want to store > more complex structures than those UArrays are provided for. It seems > to me that what I really want are *strict* arrays (which the compiler > then can unbox automatically), and that these could be provided for > any (single constructor) data type? Manuel Chakravarty's flattened arrays are what you want; I'm not sure of the implementation status though. Also, once we have associated types it will be easier to do this (see the associated types paper for an example). Cheers, Simon

1 0