- Glasgow-haskell-users

RE: Optimizations for mutable structures?
by Simon Marlow 07 Dec '05

07 Dec '05

On 07 December 2005 15:14, Ian Lynagh wrote: > On Wed, Dec 07, 2005 at 02:15:24PM -0000, Simon Marlow wrote: >> On 07 December 2005 13:38, Malcolm Wallace wrote: >> >>> Jan-Willem Maessen <jmaessen(a)alum.mit.edu> writes: >>> >>>> - Fetch elimination for imperative reads: >>>> writeIORef r e >> acts >> readIORef r >>>> === writeIORef r e >> acts >> return e >>> >>> This transformation is valid only on single-threaded systems. >>> If there is any possibility of an IORef being shared across threads, >>> you are out of luck. >> >> (assuming 'acts' doesn't modify 'r'). >> >> No, Jan's transformation is correct even in a multithreaded setting. >> It might eliminate some possible outcomes from a non-deterministic >> program, but that's ok. There's no requirement that all >> interleavings according to the semantics have to be implemented. >> This is a hard property to state precisely, indeed we gave up trying >> to in the concurrency/FFI paper: >> http://www.haskell.org/~simonmar/papers/conc-ffi.pdf, see Section >> 6.1. > > I don't think it's true for this program: > > import Data.IORef > import Control.Concurrent > > main = do m1 <- newEmptyMVar > m2 <- newEmptyMVar > let e = 6 > not_e = 7 > acts = putMVar m1 () >> takeMVar m2 > r <- newIORef 5 > forkIO $ do takeMVar m1 > writeIORef r not_e > putMVar m2 () > writeIORef r e > acts > readIORef r >>= print Sorry for not being clear enough, see my other message. I agree the transformation is not valid in this case. putMVar and takeMVar count as modifying the IORef. However... remove all the putMVars and takeMVars. Do you think it's valid now? Even though after the transformation the program might deliver a different answer? (I claim yes). Now, take the original program, but change the creation of m2 to "newMVar ()", i.e. m2 starts off full. Is the transformation valid now? Well maybe, because in some interleavings acts does not block, and we can prove that at compilation time. Interesting - I think you could justify doing the transformation in this case too, but I doubt any compiler would go that far. Cheers, Simon

1 0

RE: calling system gives exception, waitForProcess
by Simon Marlow 07 Dec '05

07 Dec '05

On 28 November 2005 23:16, Neil Mitchell wrote: > On Windows XP, with GHC 6.4.1, I get the following error consistently > when calling "system", from the module System. I get this error on two > entirely different computers, one slow (750Mhz) system, and one fast > (3Ghz) system. > > Its easiest to demonstrate when using GHCi, but the problem also > occurs when running Haskell programs compiled with GHC. > > Prelude System> system "yhi Main" > PreludeList.!!: on empty list > *** Exception: waitForProcess: does not exist (No such file or > directory) > >> From a windows standard console, in the same current directory, I >> get: > Windows> yhi Main > PreludeList.!!: on empty list > > When calling yhi using system in other circumstances (on other > programs), it works fine. The "PreludeList.!! ..." text is being > generated by the yhi program. > > The yhi program is written in C, and is available from > http://www.cs.york.ac.uk/~ndm/yhc/. Unfortunately this is probably a > bit too large to use as a minimal test case, and takes quite a while > to install/configure at the moment. > > Any idea why the waitForProcess error is being raised? I don't know why this is happening, sorry. waitForProcess does this: if (WaitForSingleObject((HANDLE) handle, INFINITE) == WAIT_OBJECT_0) { if (GetExitCodeProcess((HANDLE) handle, &retCode) == 0) { maperrno(); return -1; } return retCode; } So it seems that GetExitCodeProcess is returning ENOENT (or the Windows equivalent) for some reason. Could something else be calling GetExitCodeProcess() first? If you can find a smaller test case, I can probably look into it. Cheers, Simon

2 1

RE: New bug tracker: Trac
by Simon Marlow 07 Dec '05

07 Dec '05

On 07 December 2005 13:17, Gour wrote: > Simon Marlow (simonmar(a)microsoft.com) wrote: > > Hi Simon! > >> Unfortunately there isn't a way for users to register themselves, we >> have to create them manually using htpasswd. I'm sure someone must >> have implemented an online user-registration system for Trac though? > > This is what I got on #trac channel from one of the devs: > > "they created a 'guest/guest' login/password, and apparently that's > enough for discouraging spam attempts" and it refers to: > > http://initd.org/tracker/pysqlite/wiki Ah yes, good idea, I'll do that. Cheers, Simon

1 0

GCC in the Windows distribution of GHC
by cschmidt＠deds.nl 07 Dec '05

07 Dec '05

The Windows distribution of GHC includes GCC. Some header files (such as iostream, algorithm, and so forth), however, are missing (at least I was not able to find them). I could, of course, download the correct version of GCC (this must be version 3.2.3 for GHC 6.4), and put the header files where GCC can find them. I only wonder if this is the right thing to do. Were the header files omitted just to make the distribution smaller, or for some other reason? Cheers, Cyril

1 0

RE: New bug tracker: Trac
by Simon Marlow 07 Dec '05

07 Dec '05

On 06 December 2005 19:52, Gour wrote: > Simon Marlow (simonmar(a)microsoft.com) wrote: > >> The wiki is currently closed because I don't want to have to deal >> with spam. Use HaWiki for now. > > I got responses from people on #trac to disable entries from > non-registered user as a spam-prevention mechanism. Unfortunately there isn't a way for users to register themselves, we have to create them manually using htpasswd. I'm sure someone must have implemented an online user-registration system for Trac though? Cheers, Simon

2 1

RE: Happiness! Re: New bug tracker: Trac
by Simon Marlow 07 Dec '05

07 Dec '05

On 06 December 2005 17:45, Malcolm Wallace wrote: > Just one minor nit: the front page URL tells me a lot about Trac, > but nothing at all about ghc! > > Eventually, I worked out that I needed to click on "View tickets", > but it took a while to realise this. The top page of the wiki is now a bit more informative. This Trac thing is great! Cheers, Simon

1 0

Strictness annotations on type parameters
by Mario Blazevic 06 Dec '05

06 Dec '05

I spent several days last week trying to track a cause of a 100% slowdown after some trivial changes I made. The profiler didn't show any slowdown, presumably because it was dependent on optimizations, so I had to revert to tweak-run-measure cycle. It turned out the slowdown was caused by some unevaluated thunks that were kept around in long-lived IORefs. This is not the first time I was bitten by too laziness, either. What made things worse this time is that there is no way do declare the following: data Label = LabelRef {labelId:: !Unique, reference:: (IORef !LabelState), -- illegal origin:: Maybe !Label} -- illegal No container data type can be annotated as strict. That means I have to pepper my code with explicit evaluations to HNF before every writeIORef (reference label): newState `seq` writeIORef (reference label) newState What is the reason for this restriction on where strictness annotations can appear? Is it purely an implementation problem or is there a reason emanating from Haskell design? If former, how hard would it be to fix?

2 1

recommended build system
by Frederik Eaton 05 Dec '05

05 Dec '05

Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because "ghc --make" and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik

2 1

RE: Data.Typeable and default instances
by Simon Peyton-Jones 05 Dec '05

05 Dec '05

Jim You've found a strange corner case. Here's a cut-down example, which fails in exactly the same way. class Baz v x where foo :: x -> x -- Notice that v is not mentioned foo y = y instance Baz Int Int But it succeeds if you put the instance explicitly: instance Baz Int Int where foo y = y GHC does not actually macro-expand the instance decl. Instead, it defines a default method function, thus $dmfoo :: Baz v x => x -> x $dmfoo y = y Notice that this is an ambiguous type: you can't call $dmfoo without triggering an error. And when you write an instance decl, it calls the default method: instance Baz Int Int where foo = $dmfoo I'd never thought of that. You might think that we should just *infer* the type of the default method (here forall a. a->a), but in the presence of higher rank types etc we can't necessarily do that. So I'm not sure what to do. I've added it as an expected-failure test (tc199). I have not added a SourceForge bug because the original program seems so implausible. Meanwhile, the workaround is to define your own default method, thus: dmfoo :: x -> x dmfoo y = y instance Baz Int Int where foo = dmfoo Simom | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jim Apple | Sent: 04 December 2005 17:24 | To: glasgow-haskell-users(a)haskell.org | Subject: Data.Typeable and default instances | | > {-# OPTIONS -fglasgow-exts #-} | > | > import Maybe | > import Data.Typeable | > | > data Nil = Nil deriving (Eq,Typeable,Show) | > | > class (Typeable t) => List a t where | > init :: (t -> b) -> (forall y . (List a y) => y -> b) | > init f z = fromJust $ do x <- cast z | > return $ f x | > | > instance List a Nil where | | Could not deduce (List a1 y) | from the context (List a Nil, Typeable Nil, List a y) | arising from use of `Main.$dminit' at Main.hs:21:0 | Probable fix: add (List a1 y) to the class or instance method | `Main.init' | In the definition of `init': init = Main.$dminit | In the definition for method `Main.init' | In the instance declaration for `List a Nil' | | but copying and pasting the code from init to the instance declaration | works fine. | | Jim | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: GHCI and archive libraries.
by Simon Peyton-Jones 05 Dec '05

05 Dec '05

I believe that it ought to be fairly straightforward to modify GHCi's linker (which is written in C) to understand .a files. Would someone like to try? Failing that, it'd be great if someone would feel able to write a few paras to summarise this thread, for us to add to the documentation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Keean Schupke | Sent: 04 December 2005 14:28 | To: Sven Panne | Cc: Lennart Augustsson; glasgow-haskell-users(a)haskell.org | Subject: Re: GHCI and archive libraries. | | Thaks guys... I realise it is a simple matter of unpacking the object | files, however when using ghci for prototyping, it can be more | convenient to have all the '.o's packed into a '.a'. As it is a simple | matter to extract the .o files from the .a, I would have thought a | fairly small change to the ghci code would have enabled using archive | libraries. I think this change would aid usability. I don't know the | ghci code at all, so it would take me a long time to make this change, | as I would first have to understand the existing code. I was wondering | if anyone familier with the ghci code could add archive library support? | I suppose as a work around I could write a wrapper for ghci that | extracts the .o files from the .a to a temp directory, and then calls | ghci with the .o files on the command line. | | Regards, | Keean. | | Sven Panne wrote: | | >Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson: | > | > | >>And on many platforms (well, at least a few years ago) a "shared" | >>library doesn't have to be PIC. The dynamic loader can do relocation | >>when it loads the file. (Then it can't be shared.) | >> | >>But this was a few years ago on Solaris and BSDs, it could be | >>different now. | >> | >> | > | >After a quick look this seems to be the case on current x86 Linux systems, | >too: "Real" shared libraries consist of PIC to enhance sharing code at | >runtime, but nevertheless the dynamic loader seems to be able to load and | >relocate non-PIC, at the cost of less sharing, but often slightly better code | >quality. So the mentioned repacking of a static library into a partially | >linked object file might work for most common platforms. | > | >Cheers, | > S. | >_______________________________________________ | >Glasgow-haskell-users mailing list | >Glasgow-haskell-users(a)haskell.org | >http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0