April 2004 - Glasgow-haskell-users

GHC CVS refusing connections...
by MR K P SCHUPKE 28 Apr '04

28 Apr '04

tried to update to update GHC from CVS today, with CVSROOT= :pserver:anoncvs@glass.cse.ogi.edu:/cvs but got the error: cvs [login aborted]: connect to glass.cse.ogi.edu(129.95.44.145):2401 failed: Connection refused Is it my ISP, or is everyone having the same problem? Regards, Keean.

5 5

RE: ghc and signal processing
by Simon Peyton-Jones 27 Apr '04

27 Apr '04

I think the HEAD goes just as fast as 6.2 now. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jeremy Shaw | Sent: 24 February 2004 04:04 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc and signal processing | | Hrm, | | Okay, it seems that my problems maybe be due to using ghc 6.3. | | Here are the results of running test under different compiler versions | (see end of message for code): | | | Athlon 600MHz + FreeBSD + GHC 6.0.1 | | real 0m0.414s | user 0m0.361s | sys 0m0.016s | | Athlon 600MHz + FreeBSD + GHC 6.3 (built from CVS HEAD on Feb 15, 2004) | | real 0m2.517s | user 0m2.289s | sys 0m0.069s | | Pentium III 1.13GHz + Debian + GHC 6.2 | | real 0m0.305s | user 0m0.196s | sys 0m0.027s | | Pentium III 1.13GHz + Debian + GHC 6.3 (built from CVS HEAD on Feb 1, 2004) | | | real 0m1.302s | user 0m1.196s | sys 0m0.044s | | | So it seems like maybe GHC 6.3's performance for this particular test | is around 3-5 slower? | | Jeremy Shaw. | | | module Main where | | import Data.Array | import Data.Array.IO | | import System.IO | | main = do h <- openFile "test.b" WriteMode | a <- newArray_ (1,1800000) | b <- mapArray id a | c <- mapArray id b | hPutArray h c 1800000 | | | At Mon, 23 Feb 2004 13:37:45 -0800, | Mike Gunter wrote: | > | > | > Hmmm. With -O2 on GHC 6.2, I get 0.177s, 0.217s, and 0.348s for your | > three Haskell examples and 0.187s (with gcc -O2) for your C example. | > The output of -ddump-simpl for the looks perfect for the second | > Haskell example. My GHC seems to be doing a bang-up job here. What's | > wrong with yours? (For the third example GHC's code could be improved | > by additional inlining or hoisting of a constant array outside of the | > loop.) | > | > mike | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Compiling for Sparc v9 / Solaris 8 using 64-Bit!
by Bjoern Voss 27 Apr '04

27 Apr '04

Dear all, I would like to compile my haskell-scripts on a Sparc v9 / Solaris 8 machine using 64-Bit, cause of insufficient memory using 32-Bit. GHC is installed on this machine and works fine. The Problem is, that it only produces 32-Bit binaries. Checking the GHC manual and the web didn't deliver me the solution how to get GHC to compile for 64-Bit. I just got some hints that it should work, but not how. Has anyone an idea? Best regards Bjoern Voss -- Bjoern Voss AG- PI / Technische Fakultaet EMail: bvoss(a)techfak.uni-bielefeld.de Postfach 100131 D-33501 BIELEFELD Fon: ++49-521-106-2905 Germany

2 1

sizeFM type
by Serge D. Mechveliani 27 Apr '04

27 Apr '04

Dear GHC developers, Probably, it is better to provide Integer or Integral a => a instead of Int in the function sizeFM :: FiniteMap k e -> Int What do you think of this? Copy, please, the answer to mechvel(a)botik.ru --------------------- Dr. Serge Mechveliani mechvel(a)botik.ru

8 10

UTF-8 encode/decode
by George Russell 27 Apr '04

27 Apr '04

I have implemented UTF8-encode/decode. Unlike the code someone has already posted it handles all UTF8 sequences, including those longer than 3 bytes. It also catches all illegal UTF8 sequences (such as characters encoded with a longer sequence than necessary). Here is the code. -------------------------- cut here ------------------------------------------- {- This module contains functions for converting to and from the UTF8 representations for Strings. -} module UTF8( toUTF8, -- :: String -> String -- Converts a String (whose characters must all have codes <2^31) into -- its UTF8 representation. fromUTF8WE, -- :: Monad m => String -> m String -- Converts a UTF8 representation of a String back into the String, -- catching all possible format errors. -- -- Example: With the Haskell module Control.Monad.Error, you can -- instance this as -- (fromUTF8WE :: String -> Either String String) -- to get a conversion function which either succeeds (Right) or -- returns an error message (Left). ) where import Char import List import Data.Bits import Computation -- -------------------------------------------------------------------------- -- Encoding -- -------------------------------------------------------------------------- -- | Converts a String into its UTF8 representation. toUTF8 :: String -> String toUTF8 [] = [] toUTF8 (x:xs) = let xs1 = toUTF8 xs ox = ord x mkUTF8 :: Int -> String -> Int -> Int -> String mkUTF8 x0 xs0 xmask0 xmax0 = let xbot = 0x80 .|. (x0 .&. 0x3f) x1 = x0 `shiftR` 6 xs1 = chr xbot : xs0 in if x1 < xmax0 then chr (xmask0 .|. x1) : xs1 else let xmask1 = xmask0 .|. xmax0 xmax1 = xmax0 `shiftR` 1 in mkUTF8 x1 xs1 xmask1 xmax1 in if ox <= 0x7f then x : xs1 else if ox `shiftR` 31 /= 0 then error ("Huge character with code " ++ show ox ++ " detected in string being converted to UTF8.") else mkUTF8 ox xs1 0xc0 0x20 -- | Converts a UTF8 representation of a String back into the String, -- catching all possible format errors. -- -- Example: With the Haskell module Control.Monad.Error, you can -- instance this as -- (fromUTF8WE :: String -> Either String String) -- to get a conversion function which either succeeds (Right) or -- returns an error message (Left). fromUTF8WE :: Monad m => String -> m String fromUTF8WE [] = return [] fromUTF8WE (x0 : xs0) = let ox = ord x0 in case topZero8 ox of 7 -> do xs1 <- fromUTF8WE xs0 return (x0 : xs1) 6 -> fail "UTF8 escape sequence starts 10xxxxxx" 0 -> fail "UTF8 escape sequence starts 11111110" -1 -> fail "UTF8 escape sequence starts 11111111" n -> let r = 6 - n -- number of 6-bit pieces xtop = ox .&. ones n minx = bit ( if r == 1 then 7 else 5*r + 1 ) mkx [] _ _ = fail "UTF8 string ends in middle of escape sequence" mkx (ch : xs1) x0 count0 = do let och = ord ch if och .&. 0x80 /= 0x80 then fail ("UTF8 escape sequence contains continuing " ++ "character not of form 10xxxxxx") else return () let xbot = och .&. 0x3f x1 = (x0 `shiftL` 6) .|. xbot count1 = count0 - 1 if count1 == 0 then return (x1,xs1) else mkx xs1 x1 count1 in do (x,xs1) <- mkx xs0 xtop r if x < minx then fail ("UTF8 escape sequence contains character not " ++ "optimally encoded") else do xs2 <- fromUTF8WE xs1 return (chr x : xs2) -- -------------------------------------------------------------------------- -- Binary utilities -- -------------------------------------------------------------------------- -- | return the number of the top bit which is zero, or -1 if they -- are all zero, for a number between 0 and 255. topZero8 :: Int -> Int topZero8 i = case (findIndex not (map (\ bn -> testBit i bn) [7,6..0] )) of Just n -> 7 - n Nothing -> -1 -- | (ones i) is number with binary representation 1 written i times. ones :: Int -> Int ones i = bit i -

2 2

RE: sizeFM type
by Simon Marlow 27 Apr '04

27 Apr '04

On 26 April 2004 16:02, S. Alexander Jacobson wrote: > On Mon, 26 Apr 2004, Simon Marlow wrote: >> Probably if the take function were being designed today, there would >> be no question about whether it should take Int or Integer. Back >> then, the Integer overhead was high enough to worry about, and lots >> of benchmark programs used take/drop. Nowadays, we can't really >> change the type of take without breaking just about every Haskell >> program. > > Ok, but the whole library hierarchy is pretty new, > right? There is no reason for > Data.FiniteMap.sizeFM to be Int. Moreover take > and drop in Data.List could be redefined to take > Integer without breakage etc. It is likely that Data.FiniteMap will be replaced soon anyway. See recent discussions on libraries(a)haskell.org. Cheers, Simon

1 0

RE: problems building the GHC as a package
by Simon Marlow 27 Apr '04

27 Apr '04

On 26 April 2004 19:59, Mauro La Salete Costa Lima de Araujo wrote: > Hi folks, > > I'm having a little problem when building the GHC as a package. > I've set the option 'BuildPackageGHC=YES' in the build.mk file and > done the usual steps to build the GHC under windows > (including the './configure --host=i386-unknown-mingw32 > --with-gcc=c:/mingw/bin/gcc'). > But I'm getting the following error in the middle of the build > process: > > ------------------------------------------------------------------- > (cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la) > make[5]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' > make[4]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' > ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall > -optc-W -optc-Wstrict-p > missing-declarations -optc-Winline -optc-Waggregate-return > -optc-Wbad-function-cast -optc- > -DCOMPILING_RTS -optc-Iwin32 -optc-fomit-frame-pointer -H32m -O0 -W > -fno-warn-unused-match > Adjustor.c -o Adjustor.o > exec: C:/haskell/cygwin/home/legionario_k/fptools/ghc/compiler/: not > found make[2]: *** [Adjustor.o] Error 127 > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/legionario_k/fptools/ghc' > make: *** [build] Error 1 > ------------------------------------------------------------------ > > any sugestions? You don't need to build the RTS when building GHC as a package. If you want to do this, you have to remove BuildPackageGHC=YES from build.mk, build the compiler, RTS and libraries, and then add BuildPackageGHC=YES again. But I don't think you need to do this; just build the compiler in ghc/compiler. Cheers, Simon

1 0

ANNOUNCE: GHC version 6.2.1
by Simon Marlow 26 Apr '04

26 Apr '04

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 6.2.1 ============================================================ We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 6.2.1. As usual for patchlevel releases, this is mainly a bugfix release and should not break any code that was working with the previous major release (6.2). We did sneak a couple of new features into the compiler: - The "threaded runtime system" is included by default. To link a program with this variant of the RTS, add the -threaded option when linking. The main advantage of the threaded RTS is that it allows calls to foreign functions which block, while allowing other concurrent Haskell threads to continue running. - A debugging variant of the RTS is also included. Use -debug when linking to get it. The debugging RTS includes lots of sanity checking and has some extra options for producing debugging output while your Haskell program is running. How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

3 2

problems building the GHC as a package
by Mauro La Salete Costa Lima de Araujo 26 Apr '04

26 Apr '04

Hi folks, I'm having a little problem when building the GHC as a package. I've set the option 'BuildPackageGHC=YES' in the build.mk file and done the usual steps to build the GHC under windows (including the './configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc'). But I'm getting the following error in the middle of the build process: ------------------------------------------------------------------- (cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la) make[5]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' make[4]: Leaving directory `/home/legionario_k/fptools/ghc/rts/gmp' ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall -optc-W -optc-Wstrict-p missing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- -DCOMPILING_RTS -optc-Iwin32 -optc-fomit-frame-pointer -H32m -O0 -W -fno-warn-unused-match Adjustor.c -o Adjustor.o exec: C:/haskell/cygwin/home/legionario_k/fptools/ghc/compiler/: not found make[2]: *** [Adjustor.o] Error 127 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/legionario_k/fptools/ghc' make: *** [build] Error 1 ------------------------------------------------------------------ any sugestions? Cheers, ------------------------------------------------- | Mauro La-Salette C. L. de Araújo | | Undergraduating Computer Science Student | | mscla at cin.ufpe.br | | http://www.cin.ufpe.br/~mscla | ------------------------------------------------- "If this is true, building software will always be hard. There is inherently no silver bullet." (F.P.Brooks)

1 0

Safe use of unsafeCoerce?
by Duncan Coutts 26 Apr '04

26 Apr '04

All, I'm after advice on whether the following example is a safe use of unsafeCoerce, and if it is safe, if it's worth it. In summary, if the following is ok: castFooToBar :: Ptr Foo -> Ptr Bar castFooToBar = castPtr then is the following ok? newtype Foo' = Foo' (Ptr Foo) newtype Bar' = Bar' (Ptr Bar) castFooToBar' :: Foo' -> Bar' castFooToBar' = unsafeCoerce Here's the context/motivation: In the gtk2hs bindings for Haskell we model Gtk's object hierarchy by a hierarchy of Haskell classes and corresponding instances (and newtypes of ForeignPtrs). Here's the pattern: --The base class: newtype GObject = GObject (ForeignPtr GObject) mkGObject = GObject unGObject (GObject o) = o class GObjectClass o where toGObject :: o -> GObject fromGObject :: GObject -> o instance GObjectClass GObject where toGObject = id fromGObject = id --A derived class newtype Widget = Widget (ForeignPtr Widget) mkWidget = Widget unWidget (Widget o) = o class GObjectClass o => WidgetClass o toWidget :: WidgetClass o => o -> Widget toWidget = fromGObject . toGObject fromWidget :: WidgetClass o => Widget -> o fromWidget = fromGObject . toGObject instance WidgetClass Widget instance GObjectClass Widget where toGObject = mkGObject.castForeignPtr.unWidget fromGObject = mkWidget.castForeignPtr.unGObject So you can see in the instance of Widget for the GObjectClass we're basically doing a pointer cast (and wrapping & unwrapping newtypes). In C they just cast pointers. I'm wondering if we can do the same, ie define the instance like so: instance GObjectClass Widget where toGObject = unsafeCoerce fromGObject = unsafeCoerce Of course there's not much point, but if we know that toGObject & fromGObject are just doing a cast, then we can get rid of the class methods on GObjectClass and just implement them as ordinary class constrained functions: toGObject :: GObjectClass o => o -> GObject toGObject = unsafeCoerce fromGObject :: GObjectClass o => GObject -> o fromGObject = unsafeCoerce So, the point is we can remove entirely the class dictionary that otherwise has to be carried round for every object and the upcasting & downcasting functions no longer need to do slow dictionary lookups when all they are really doing is casting C pointers. So is it a) safe? b) kosher? BTW I know fromGObject is doing an unchecked downcast, it is only used internally, we have safe checked ones that we expose in the interface. Duncan

2 2