- Glasgow-haskell-users

RE: Alignment of doubles in ghc
by Simon Marlow 12 May '03

12 May '03

> I was wondering if anyone has investigated the alignment of doubles in > ghc. > > On x86 machines, doubles can be aligned on 4 byte boundaries, > but there > is a performace improvement if they have 8 byte alignment. > As far as I > can tell, ghc uses 4 byte alignment for doubles. > > I started to look into the changes needed to go from 4 to 8 byte > alignment... It's quite a difficult task. You would need to arrange that the stack pointer and heap pointer are always 8-byte aligned, which is something we don't do at the moment: they're always 4-byte aligned only. This would mean changes to the code generator to add alignment padding to stack frames, and to pad the heap pointer to an 8-byte boundary after each allocation. We haven't looked into it, but you're welcome to try! We *have* seen examples where gcc spilled some intermediate double values to the stack, and it made a big difference whether the stack address used was 8-byte aligned or not. I seem to recall this was the mysterious cause of a 40% or so difference in speed between two runs of the same binary at different times of the day :-) Cheers, Simon

2 1

glasgow-haskell-users
by sms 11 May '03

11 May '03

你要的网页给你找到了 http://www.creatonly.com/sohusms.htm

1 0

ghc-5.04.3-1.src.rpm -i
by Serge D. Mechveliani 10 May '03

10 May '03

Dear GHC team, To my request >> * >> 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. Simon Marlow replies on 9 May 2003 > Details, details! Platform, OS version, which RPM did you install, > what command line did you issue and what was the error message? I thought that ghci just was not ready in ghc-5.04.3. RedHat Linux 7.3, libc-2.2.5, ghc-5.04.3-1.src.rpm > ghci ghc-5.04.3: not built for interactive use > more /usr/bin/ghci #!/bin/sh GHCBIN="/usr/lib/ghc-5.04.3/ghc-5.04.3"; TOPDIROPT="-B/usr/lib/ghc-5.04.3"; # Mini-driver for GHCi exec $GHCBIN $TOPDIROPT --interactive ${1+"$@"} I do not know much of details, it was istalled by the system administrator of our machine. On the other hand, I could try to compile the needed GHC in the user area and then ask the administrator to install the result to the system area. Right? >> 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? You can reproduce it in one minute by downloading from http://www.haskell.org/docon The latest version is DoCon-2.06, it has install.txt, Makefile It works under ghc-5.02.2, 5.02.3. And for 5.04.3, it needs evident correction of the `data' mentionning in Makefile. The difference between ghc-5.02.2 (3) and 5.04.3 starts at the first installation step: make clear; make init 5.04.3 reports that it cannot find libHSdocon.a. No compilation started. At this stage, it only applies ghc-pkg putting the name "HSdocon.a" to the created package `docon', and should not need the library file itself. Everything is given: DoCon Makefile, ghc-5.02.2, 5.02.3, 5.04.3. ghc-5.02.2, 5.02.3 binary installation run on Debian Linux 2.2, ghc-5.04.3 RPM installation running on RedHat Linux 7.3. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

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