- Glasgow-haskell-users

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 27 Apr '04

27 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

RE: sizeFM type
by Simon Marlow 26 Apr '04

26 Apr '04

On 26 April 2004 02:49, S. Alexander Jacobson wrote: > Sun and Dell both sell 64-bit boxes. But the core > question is why have two different types at all? > > This issue is timely because I just got an error > in code that looks vaguely like: > > h<-openFile "foo" AppendMode > pos <- hFileSize h > hPutStr $ show something > hClose h > content <- readFile "foo" > return $ take pos content > > This code produces an error because (madness!): > > hFileSize::Handle -> IO Integer > take::forall a. Int -> [a]->[a] > > I have to assume conversion between files and > lists is not all that rare even in beginner code. > > Note: I don't really care whether everything is > 64bit Int or Integer. I just find having to care > about this point in such trivial code ridiculous. 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. Cheers, Simon

2 1

RE: Safe use of unsafeCoerce?
by Simon Marlow 26 Apr '04

26 Apr '04

On 24 April 2004 17:38, Duncan Coutts wrote: > 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 If the runtime representation of Foo' and Bar' is the same, then this is safe. In this case the runtime representation is the same, so you're ok. However, it might not always be a good idea, because the compiler's optimiser gets a bit stuck when it sees an unsafeCoerce. I'd like to be a bit more specific, but I'm not sure I can remember the specific example. On the other hand, Happy makes extensive use of unsafeCoerce in its generated code (when you use -c), so in some cases the benefits can definitely outweigh the costs. > Here's the context/motivation: [ snip ] > 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? I think so. On the other hand, you might want to look at using the trick that wxHaskell uses for encoding the widget hierarchy, which also has zero runtime cost. Cheers, Simon

1 0