April 2003 - Glasgow-haskell-users

RE: ANNOUNCE: GHC vesrion 5.04.3 released
by Simon Marlow 09 May '03

09 May '03

> Actually, I find it difficult to extract the sometimes drastic > differences between releases from that document (just one example: > does this release include last week's bugfixes in the Network > module?). How do I find out about the various bugfixes between > releases, to decide whether or not to upgrade (and whether or not > upgrading will help with specific problems)? > > After all, the reason for patchlevel releases is that you've fixed > some bugs, so why be so secretive about what these fixes are?-) The release notes doesn't contain bugfixes, and the reason we don't have a list of them is because I'm too lazy to keep track of what bug fixes have been merged in, sorry! The Network fix wasn't merged in (just too late). Ok, I'll take a look at the diffs and summarise the fixes... here goes: - Literal strings could be duplicated sometimes - fixes for deriving Eq/Enum on large datatypes in GHCi - -no-hs-main has a sensible meaning in --make mode now (it forces linking even if there's no Main) - Fix for avoiding recompilation when there are stub files around (didn't pick up the stubs properly before) - Fixes for FFI decls containing type variables - MacOS X fixes for GHCi - Filenames with spaces don't cause problems in GHCi now - GHCi doesn't get confused if your code installs a signal handler for ^C - -pgmL now works as advertised - specifying filenames without the trailing .hs/.lhs works again in --make and GHCi. - Fix for "class ops that do not introduce foralls" (a cause of crashes with certain kinds of class methods). - Fix a crash when a class op is used as a record selector - Fix for deriving on records with fields with names with leading underscores. - Fixes for passing/returning FunPtr in the FFI - hsc2hs works in a binary distribution - Fixes for crashes in the biographical and retainer profilers. - Some signals were inadvertently blocked by the RTS - Uninitialised variable in the storage manager causes crashes - Fix for hp2ps -c - hsc2hs should now work on Windows - Fix off-by-one in Data.PackedString.splitWithPS - uninitialised elements in UArrays are now filled with zero. - Integer divide by zero is now consistently a catchable exception (previously it could just result in SIGFPE). - Fix for terminal buffering on Solaris - System.Console.GetOpt fixes - Fix for converting Integer to Int64/Word64 - Network.accept doesn't fail if the host fails to reverse-lookup. Cheers, Simon

5 7

RE: Histogram-building code (was: Re: Yet another weakly defined bug report)
by Simon Marlow 08 May '03

08 May '03

> One question though, about hFlush. I print out the status by > repeatedly putStr'ing "blah blah \r". With NoBuffering set, it works, > but when following the putStr with 'hFlush stdout', it doesn't (only > outputs very sporadically. I guess I'm misunderstanding the function > of hFlush, anybody care to elaborate?) It could be a bug. Can you provide us with a cut-down example? Cheers, Simon

3 2

Sockets again
by George Russell 30 Apr '03

30 Apr '03

The attached short program (compile with "ghc VServer.hs -o v -package net") is supposed to set up a server on port 15151, wait for a connection, read the first character from the connection, and print it out. Unfortunately if I test it, by running it, and starting up "telnet [machine] 15151" somewhere else, and then type some random text, EG "foo[RETURN]", it does not work. It looks as if the problem is that VServer.hs issues the command hSetBuffering handle (BlockBuffering (Just 4096)) on the connection, because when I change it to hSetBuffering handle NoBuffering the program works. However this is not what I want to do!! Because setting NoBuffering on the handle is going to mean that when the Server *outputs* something, it will potentially be done very expensively character by character. How do I get block buffering on the Server's output, but not have input to the server held up? The same thing seems to happen with client Handles by the way. -- Test program for server using GHC Socket library. module Main(main) where import IO import Network main = do socket <- listenOn (PortNumber 15151) (handle,hostName,_) <- accept socket hSetBuffering handle (BlockBuffering (Just 4096)) putStr ("Accepted: "++hostName++"\n") c <- hGetChar handle putStrLn (show c)

4 6

RE: Problem Building Package
by Simon Marlow 30 Apr '03

30 Apr '03

> I am having a bit of trouble builing local packages. > > I have three libraries, A, B, and C, that I want to make into local > packages. A and B depend only on base, while C depends on > base, A, and > B. > > The souces gets built with > > ghc --make -package-name=A {list of files} > ghc --make -package-name=B {list of files} > ghc --make -package-name=C {list of files} > > and I create the archives libHS[A,B,C].a This all works fine. > > I have three simple .pkg. If I add the dependencies into > package-deps, > then ghc-pkg says that the dependencies do not exist. If I leave that > blank, then I can create my local .conf file. I can't tell what the problem is from this description. Are the dependencies between your packages, or on other packages? It will help if you send us the .conf files, and cut-n-paste the exact command lines and the errors GHC produces. Cheers, Simon

1 0

RE: eta-expansion
by Simon Marlow 30 Apr '03

30 Apr '03

> | In the same paper is the case-eta-expansion, but I don't understand > | the correctness of this transformation: > | > | case e of {p1 -> e1,...,pn -> en} > | ===> \y -> case e of {p1 -> e1 y, ..., pn -> en y} > | > | The rhs is a WHNF, but the lhs isn't, so the rule > | can't be correct in general. For example, assume that e is bot. > > Right. It's only done if 'e' is cheap (a variable, or something like > that). Actually, looking at the code, we also do it if 'e' is known to be bottom: CoreUtils.exprIsCheap returns True for known-divergent expressions. Which seems wrong for eta expansion, no? It's probably the case that if we have 'case _|_ of ...' then the simplifier will already have turned it into _|_, so it won't crop up. But it still looks wrong, unless I'm missing something? Cheers, Simon

1 0

"less polymophic" problem
by Seth Kurtzberg 30 Apr '03

30 Apr '03

Hello list, I don't know how to solve this problem. Using GHC 5.04.3. The following snippet shows the problem, as minimally as I could. tl2 = ["123","abc","def"] tl3 = newSTRef tl2 -- this works: tl3unref = runST(tl3 >>= \ref -> readSTRef ref) -- this code, the same but with a formal parameter, doesn't compile: -- this is line 61 in the error message below getaline rlines = runST(rlines >>= \ref -> readSTRef ref) --ghci complains as follows: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It is mentioned in the environment: rlines :: ST s (STRef s a) (bound at misstring.hs:61) In the first argument of `runST', namely `(rlines >>= (\ ref -> readSTRef ref))' In the definition of `getaline': runST (rlines >>= (\ ref -> readSTRef ref)) -- I tried the following signature for getaline: getaline :: forall s. ST s (STRef s [[Char]]) -> [[Char]] -- which does not change the error. The type in the signature for -- rlines is that displayed by ghci for tl3 Any help will be greatly appreciated. TIA -- Seth Kurtzberg MIS Corp 480-661-1849 seth(a)cql.com

2 1

RE: eta-expansion
by Simon Peyton-Jones 29 Apr '03

29 Apr '03

| v = \a1 ... an -> f a1 ... an | ===> v = \a1 ...an ... am -> f a1 ... an ...am | | assuming f has arity m > n. | | arity is something like "how many arguments can be applied, without | perfoming work" | | My questions: | 1) How do you compute this arity. Take a look at ghc/compiler/coreSyn/CoreUtils.exprEtaExpandArity. Basically, we just look for partial applications of functions with already-known arity. We consider an expression to have arity N if eta-expansion to put N lambdas at the front would not waste a significant amoutn of work. So (+) 3 would eta expand do \x -> (+) 3 x but (+) (g 3) would not, unless g has arity greater than 1. The idea is to avoid pushing an arbitrarily expensive redex (or in the worst case, bottom) inside a lambda. | 2) What's the expression f in the general rule, is it a variable or | a term, or could it be both? As I mention above, it can be an expression, provided adding the lambda doesn't duplicate work, even if the lambda is applied more than once. | In the same paper is the case-eta-expansion, but I don't understand | the correctness of this transformation: | | case e of {p1 -> e1,...,pn -> en} | ===> \y -> case e of {p1 -> e1 y, ..., pn -> en y} | | The rhs is a WHNF, but the lhs isn't, so the rule | can't be correct in general. For example, assume that e is bot. Right. It's only done if 'e' is cheap (a variable, or something like that). Eta expansion is very important in practice, because it makes head-normal forms show up more, which in turn makes more inlining happen, which can be a really big win. Simon

1 0

RE: Sockets again
by Simon Marlow 29 Apr '03

29 Apr '03

> The attached short program (compile with "ghc VServer.hs -o v > -package net") > is supposed to set up a server on port 15151, wait for a > connection, read > the first character from the connection, and print it out. > Unfortunately > if I test it, by running it, and starting up "telnet [machine] 15151" > somewhere else, and then type some random text, EG > "foo[RETURN]", it does > not work. It looks as if the problem is that VServer.hs issues the > command > hSetBuffering handle (BlockBuffering (Just 4096)) > on the connection, because when I change it to > hSetBuffering handle NoBuffering > the program works. > > However this is not what I want to do!! Because setting > NoBuffering on the > handle is going to mean that when the Server *outputs* > something, it will > potentially be done very expensively character by character. How do I > get block buffering on the Server's output, but not have input to the > server held up? Hmm. I rather think that hGetChar should always return a character immediately if there is one available, regardless of the buffering mode. Looking at the source, it appears that hGetLine behaves like this, as does lazy reading with hGetContents. I can't see any reason for waiting for the buffer to be completely full before returning anything. If you have a source tree handy, try the enclosed patch. If not, make a copy of hGetChar from the sources in libraries/base/GHC/IO.hs, apply the patch, and compile it separately (you'll need to import GHC.Handle explicitly, amongst other things). Cheers, Simon

3 4

How to diagnose exception <<loop>> ?
by Guest, Simon 28 Apr '03

28 Apr '03

Hi all, I'm using GHC 5.04.2 on Windows. I made some changes which broke my application, in that certain input now causes *** Exception: <<loop>> I can't work out what I did to introduce an infinite loop. Is there something I can do to extract more information to narrow this down? Any pointers appreciated. cheers, Simon

2 1

Arkadasa yardimci olalim
by Dr. Ahmet Yalcin 27 Apr '03

27 Apr '03

Arkadaslar, lütfen dikkate alin, yardimci olalim: Merhaba, cok zor durumda ve baska caresi kalmamis biri olarak hosgörünüze ve insan sevginize siginarak sizden bana cok kisada olsa kulak vermenizi rica edecegim. Ben, 34 yasinda evli ve 4 yasinda olan bir cocuk babasiyim. Aile hayatimizin sorunsuz ve mutlu sekilde devam ederken biricik oglumuz aniden rahatsizlandi. Uzun süren arastirmalar sonucu oglumuz Ali Can'in kalbinde hayati bir fonksiyon bozuklugunun bulundugu doktorlar tarafindan tespit edildi. Oglumuz cok acil sekilde ameliyat olmazsa maalesef hayata gözlerini yumacak. Ancak ne varki ameliyat icin gerekli olan parayi ödememiz bizim icin mümkün gözükmüyor. Bu nedenle uzun ugraslar sonucu iki önemli Internet sirketi ile yaptigimiz görüsme sonucu, bize her mailde gönderecegimiz link'in tiklanmasi durumunda cocugumuzun ameliyat masraflarina 10 Cent (= 0,10 Euro) katkida bulunacaklari yönünde anlasmaya varabildik. Bu dogrultuda sizden rica edecegimiz, sizi sözkonusu sirketlerin sayfalarina yönelten bu linki tiklamaniz. Bu linki tiklayarak sizinde ameliyat masraflarini karsilamamizda katkiniz olabilir. Sizden bu zor durumumuzda istedigimiz sadece bir tik. >> TIKLAYINIZ --> http://partners.webmasterplan.com/click.asp?ref=160073&site=2514&type=text&… Bunun yaninda bu emaili tüm tanidiklariniza gönderirseniz bize son derece yardimci olursunuz. Ne kadar kisi linki tiklarsa, gerekli olan ameliyat masrafini yakalayabilmemiz o kadar olasi olur. Hos görünüz icin tesekkür eder, saygilarimi sunarim. Mehmet Can Yakupoglu.

1 0