May 2003 - Glasgow-haskell-users

RE: file too large
by Simon Marlow 09 May '03

09 May '03

> On Fri, May 09, 2003 at 02:43:58PM +0100, Alastair Reid wrote: > > man 2 open describes O_LARGEFILE as follows: > > O_LARGEFILE: On 32-bit systems that support the Large Files > System, allow > > files whose sizes cannot be represented in 31 bits to be opened. > > I'm slightly puzzled about why you would need to specify > this flag. That is, > > why would it not just go ahead and open the file anyway? > > My best guess is that you are promising that all indexes > into the file will be > > 64 bit (unsigned?) ints and not a 32 bit unsigned int. In > other words, it's > > a backward compatability feature with a little typechecking > thrown in. > > SuSv3 doesn't specify a difference between RW and RO. My > first guess is > unexpected nontermination could occur if something loops until getting > some kind of sign it's passed EOF since offsets would wrap so they > wanted to avoid that compatibility issue. > > Anyway, will the following kernel update help clarify things? > I'll send > it in to akpm et al if so. I've checked with a couple of people and it > appears the code is what was intended, not the comment. A man page update might be nice too. I checked 'man open' on Linux and it says nothing about EFBIG, although it does mention O_LARGEFILE. Cheers, Simon

4 3

RE: STArray and Lazy ST
by Simon Marlow 09 May '03

09 May '03

> I would say that the 'bug' is that Data.Array.ST does not export ST. > > GHC's policy is to report error messages in the same vocabulary as the > user would use. Even though you have imported > Control.Monad.ST.Lazy and > Data.Array.ST, you can still say "ST" unambiguously, because > Control.Monad.ST.Lazy exports ST, but Data.Array.ST does not -- so > there's only one ST in scope. > > If you imported only Data.Array.ST you wouldn't be able to > mention "ST" > at all. > > If Data.Array.ST exported ST, the error message would give a qualified > name for the ST constructor -- qualified by one of its import modules, > that is. > > I'll ask Simon M if we should export a bit more from > Data.Array.ST, but > actually I think the compiler is behaving right. It'd be > pain if every > error message used fully-qualified names! Exporting ST from Data.Array.ST looks like the wrong fix to me. It's fixing a tools problem by changing the library interface - we'd have to do it each time this issue came up. Perhaps the real source of the problem is that the lazy ST monad is called ST? Ok, so that's just blaming the library again, but the fact that two different types have the same name is bound to lead to confusion. Cheers, Simon

2 1

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: interpreter in 5.04.3
by Simon Marlow 09 May '03

09 May '03

> * > Is it possible to build ghc-5.04.3 > with interpreter? > For we have installed it from RPM, and it reports that ghci > would not work. Details, details! Platform, OS version, which RPM did you install, what command line did you issue and what was the error message? [snip] > This DoCon installation aims at the following meaning: > > initially, HSdocon.o, libHSdocon.a are absent, > compile DoCon modules > making libraries $(e)/HSdocon.o, $(e)/libHSdocon.a, > and these libraries have to link when using the package docon. > > It works in ghc-5.02 > > (see haskell.org/docon, version 2.06, Makefile), > > and quotations look all right, because it is in Makefile and it > issues `echo' ... > But in ghc-5.04.3, Makefile needs to skip "HSdocon", > and someone has to set it to docon.conf after the installation. > > Maybe, it is a trivial question, but still I wonder how to improve > Makefile in a proper way. I still can't tell what's wrong. You need to show us the *actual* contents of docon.conf, and where exactly does the library libHSdocon.a reside? Cheers, Simon

1 0

RE: STArray and Lazy ST
by Simon Peyton-Jones 09 May '03

09 May '03

I would say that the 'bug' is that Data.Array.ST does not export ST. GHC's policy is to report error messages in the same vocabulary as the user would use. Even though you have imported Control.Monad.ST.Lazy and Data.Array.ST, you can still say "ST" unambiguously, because Control.Monad.ST.Lazy exports ST, but Data.Array.ST does not -- so there's only one ST in scope. If you imported only Data.Array.ST you wouldn't be able to mention "ST" at all. If Data.Array.ST exported ST, the error message would give a qualified name for the ST constructor -- qualified by one of its import modules, that is. I'll ask Simon M if we should export a bit more from Data.Array.ST, but actually I think the compiler is behaving right. It'd be pain if every error message used fully-qualified names! Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Josef Svenningsson | Sent: 08 May 2003 16:20 | To: glasgow-haskell-users(a)haskell.org | Subject: STArray and Lazy ST | | Hi, | | I've spent some time running after a little bug in my code that seems to | be caused by the following fact: | If I want to use Data.Array.ST I can only use it with the strict ST monad. | I would really like to use it with the lazy ST monad. Is there any way to | do it? | | Further more, I got some really weird error messages. My file looked | something like this: | | \begin{pseudocode} | import Control.Monad.ST.Lazy | import Data.Array.ST | | ... further down I have the following function.... | | foo :: Ix v => STArray s v Bool -> v -> ST s Bool | foo a b = readArray a b | \end{pseudocode} | | Now I got the following error message: | | formats/Graph.hs:91: | Could not deduce (MArray (STArray s) Bool (ST s)) | from the context (Ix v) | Probable fix: | Add (MArray (STArray s) Bool (ST s)) | to the type signature(s) for `contains' | Or add an instance declaration for (MArray (STArray s) Bool (ST s)) | arising from use of `readArray' at formats/Graph.hs:91 | In the definition of `foo': readArray a b | | The thing is, there is already an instance MArray (STArray s) e (ST s)! So | what is the compiler complaining about? The problem is, it's not the right | ST type! In the error message the name ST means two different things which | is REALLY confusing and it took me a while to figure it out. One ST comes | from Control.Monad.ST.Lazy and the other from Data.Array.ST. | | Is there any way to improve the situation? I'm not claiming these issues | are bugs, but they certainly made my life a lot harder for a while. | | Cheers, | | /Josef | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

STArray and Lazy ST
by Josef Svenningsson 08 May '03

08 May '03

Hi, I've spent some time running after a little bug in my code that seems to be caused by the following fact: If I want to use Data.Array.ST I can only use it with the strict ST monad. I would really like to use it with the lazy ST monad. Is there any way to do it? Further more, I got some really weird error messages. My file looked something like this: \begin{pseudocode} import Control.Monad.ST.Lazy import Data.Array.ST ... further down I have the following function.... foo :: Ix v => STArray s v Bool -> v -> ST s Bool foo a b = readArray a b \end{pseudocode} Now I got the following error message: formats/Graph.hs:91: Could not deduce (MArray (STArray s) Bool (ST s)) from the context (Ix v) Probable fix: Add (MArray (STArray s) Bool (ST s)) to the type signature(s) for `contains' Or add an instance declaration for (MArray (STArray s) Bool (ST s)) arising from use of `readArray' at formats/Graph.hs:91 In the definition of `foo': readArray a b The thing is, there is already an instance MArray (STArray s) e (ST s)! So what is the compiler complaining about? The problem is, it's not the right ST type! In the error message the name ST means two different things which is REALLY confusing and it took me a while to figure it out. One ST comes from Control.Monad.ST.Lazy and the other from Data.Array.ST. Is there any way to improve the situation? I'm not claiming these issues are bugs, but they certainly made my life a lot harder for a while. Cheers, /Josef

2 1

Mutable arrays
by Koen Claessen 08 May '03

08 May '03

Dear all, I wonder if anyone knows a good way of giving an unboxed mutable array (e.g. IOUArray) to the C world using the FFI in constant time? (I.e. a conversion to a Ptr.) I presume that an IOUArray is implemented as nothing but a Haskell object that has some information plus a pointer to a "normal" C array. I would like to get to that pointer! I could of course implement my own verion of IOUArray which uses a Ptr inside, but it seems silly to redo all the work that has gone into IOUArray. I have also a feature request for mutable arrays: Is it possible to prove a function like "realloc" which extends the array to a larger size, copying all existing information? Right now, I have to do this myself; I am using a type 'IORef (UArray ..)' which seems kind of silly and unnecessarily inefficient. Regards, /Koen

3 2

interpreter in 5.04.3
by Serge D. Mechveliani 08 May '03

08 May '03

Dear GHC team, * Is it possible to build ghc-5.04.3 with interpreter? For we have installed it from RPM, and it reports that ghci would not work. * Concerning my previous question on packages: Makefile prepares docon.conf by packDocon = Package {name = "\"docon\"", \ import_dirs = ["\"$(e)\""], \ source_dirs = ["\"$(e)\""], \ library_dirs = ["\"$(e)\""], \ hs_libraries = ["\"HSdocon\""], \ ... } , ... echo $(packDocon) | ghc-pkg -f $(s)/docon.conf -a ... With ghc-5.04.3, this leads to Reading package info from stdin... done. Expanding embedded variables...done. cannot find `libHSdocon.a' on library path Simon Marlow writes > The error is self-explanatory: it can't find libHSdocon.a on the path > given in the package specification. It looks like you might have some > extra quotation marks in there. This DoCon installation aims at the following meaning: initially, HSdocon.o, libHSdocon.a are absent, compile DoCon modules making libraries $(e)/HSdocon.o, $(e)/libHSdocon.a, and these libraries have to link when using the package docon. It works in ghc-5.02 (see haskell.org/docon, version 2.06, Makefile), and quotations look all right, because it is in Makefile and it issues `echo' ... But in ghc-5.04.3, Makefile needs to skip "HSdocon", and someone has to set it to docon.conf after the installation. Maybe, it is a trivial question, but still I wonder how to improve Makefile in a proper way. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Naming and subexpressions
by Simon Marlow 08 May '03

08 May '03

> I have a program, structured approximately like so > > main = do > let stage1 = e1... > let stage2 = e2...stage1... > stage3 <- e3...stage2 > case something of > foo -> output stage1 > bar -> output stage2 > baz -> output stage3 > > I think this is an improvement from using multiple main functions, > since it reveals the pipeline structure of the program and the > modularity of the stages. > > It appears¹, however, that naming the result of stage1 > prevents it from > being garbage collected when subsequent stages are produced. Since > stage1 is a huge list, this leads to a space leak. Hard to tell, but from the code above it looks like stage1 would be retained because it might need to be output after stage3. Could you perhaps move the output of stage1 up the pipeline? If you suspect there's a bug and something is being retained when it shouldn't be, then send us the code and we'll happily investigate. > So, is there any way to avoid this? Do I need to restructure my > program? I could conceivably do > > main = do > let stage1 = e1... > let stage2 = e2...(e1...)... > : > > and so on, but an aggressive (but slightly dumb) compiler might > rediscover the similarity and CSE it. > > Suggestions more than welcome. > > -kzm > > ¹ Memory retainer profiling shows the product being retained by > SYSTEM, so I *think* this is the right interpretation. A SYSTEM retainer is usually the stack. Cheers, Simon

2 1

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