RE: problems building the GHC as a package
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC CVS refusing connections...
Sigbjorn Finne [EMAIL PROTECTED] writes: Thanks to the hard work of Jeff Lewis, the CVS pserver at cvs.haskell.org is now back up again, Good, and well done. Unfortunately, ssh-based connections to the writable repository have now started to fail for me. The ssh server does not respond to my public key, and instead asks for my password. I don't even know my password on cvs.haskell.org! Has there been an inadvertent configuration change somewhere? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
UTF-8 encode/decode
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 10xx
0 -
fail UTF8 escape sequence starts 1110
-1 -
fail UTF8 escape sequence starts
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 10xx)
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
Re: UTF-8 encode/decode
On Tue, Apr 27, 2004 at 10:55:57AM +0200, George Russell wrote: 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. What license is your code covered under? As it stands now, it is an informative example, but cannot be used by anybody. Thanks, Dave Brown ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sizeFM type
On Sun, Apr 25, 2004 at 11:38:19PM +0200, Tomasz Zielonka wrote: On Sun, Apr 25, 2004 at 04:12:25PM -0400, David Roundy wrote: On the other hand, since they are still 32 bit computers, any given application can still only access 4G of memory. This issue will only be a problem on 64 bit platforms which have a 32 bit Int. Here is a funny program that gives wrong result because of length returning Int on a 32-bit computer. import Data.List main = print (length (genericTake 50 (repeat ( Running it shows $ ./A 705032704 But this is a strange piece of code and I agree that it will hardly be a problem on a 32 bit platform. In fact, the only way this will be a problem is if your list is lazy and consumed by the length function, but it's hard to see how that could happen except in strange example code. That is, it's hard to imagine when you'd need to know the length of a data structure you don't need... A perhaps slightly less contrived example (although far slower) would be to try to write hFileSize as: hStupidFileSize f = do h - hOpen f ReadMode length `liftM` hGetContents h which would give wrong results for large files. But of course this is why hFileSize returns Integer... -- David Roundy http://www.abridgegame.org ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 encode/decode
David Brown wrote (snipped): What license is your code covered under? As it stands now, it is an informative example, but cannot be used by anybody. As author, I am quite happy for it to be used and modified by other people for non-commercial purposes. As far as I know my employers wouldn't any problem with that either. If it is important to your lawyers that you have a definite licence, say so, and I'll see if I can do something. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: sizeFM type
On Mon, Apr 26, 2004 at 06:42:20AM -0400, David Roundy wrote: On Sun, Apr 25, 2004 at 11:38:19PM +0200, Tomasz Zielonka wrote: On Sun, Apr 25, 2004 at 04:12:25PM -0400, David Roundy wrote: On the other hand, since they are still 32 bit computers, any given application can still only access 4G of memory. This issue will only be a problem on 64 bit platforms which have a 32 bit Int. Here is a funny program that gives wrong result because of length returning Int on a 32-bit computer. import Data.List main = print (length (genericTake 50 (repeat ( Running it shows $ ./A 705032704 But this is a strange piece of code and I agree that it will hardly be a problem on a 32 bit platform. In fact, the only way this will be a problem is if your list is lazy and consumed by the length function, but it's hard to see how that could happen except in strange example code. That is, it's hard to imagine when you'd need to know the length of a data structure you don't need... Think `wc -l'. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. pgp0.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling for Sparc v9 / Solaris 8 using 64-Bit!
bvoss: 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? I don't know the exact details of Solaris, but it may be similar to the mips64/irix. mips64/irix lets you run either 32 and 64 bit binaries on the OS. If this sounds like what you are trying to do, then read on... Building GHC as a 32 bit port didn't work for some reason, 64 bits did work. You would need to port GHC to run in 64 bit world, following: http://www.haskell.org/ghc/docs/6.2.1/html/building/sec-porting-ghc.html The main problem is making sure the tools you need are all passed the correct flags to trigger 64 bit mode results. This, in the mips64 case, involves setting some environment vars, and some flags. You need to read man pages for cc, ld, and the binary format probably. They're all useful. Environment stuff I had to set up the C tools to produce 64 bits: export LDFLAGS=-mabi=64 export CFLAGS=-mabi=64 export LD=/usr/bin/ld -64 And we have to tell GHC to pass flags through to gcc, the assembler and the linker when bootstrapping from .hc files: mk/build.mk: SRC_CC_OPTS+=-mabi=64 SRC_HC_OPTS+=-optc-mabi=64 -opta-mabi=64 -optl-mabi=64 Once this was all in place, you could run ./configure and it would give you 8 byte longs. You can use the config files generated to build some .hc src on another machine, following the bootstrap instructions, and then bring them back and continue the bootstrap. You should generate a 64 bit GHC, that thinks it is on a 64 bit machine. Still one last problem: GHC *also* needs to pass the 64 bit flags when it is compiling its own Haskell binaries. Use the package system! I had to patch fptools/ghc/rts/package.conf.in with: @@ -63,9 +67,15 @@ c_includes = [ Stg.h ], package_deps = [], +#if defined(mips_sgi_irix_TARGET) + extra_ghc_opts = [-opta-mabi=64], +#else extra_ghc_opts = [], +#endif #if defined(THREADED_RTS) defined(freebsd_TARGET_OS) extra_cc_opts = [ -pthread ], +#elif defined(mips_sgi_irix_TARGET) + extra_cc_opts = [-mabi=64], #else And that's it. So it is harder than a normal .hc bootstrap, because tools don't like to behave, and keep dropping back to 32 bit mode. Good luck, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc and signal processing
I think the HEAD goes just as fast as 6.2 now. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Jeremy Shaw | Sent: 24 February 2004 04:04 | To: [EMAIL PROTECTED] | 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 | | real0m0.414s | user0m0.361s | sys 0m0.016s | | Athlon 600MHz + FreeBSD + GHC 6.3 (built from CVS HEAD on Feb 15, 2004) | | real0m2.517s | user0m2.289s | sys 0m0.069s | | Pentium III 1.13GHz + Debian + GHC 6.2 | | real0m0.305s | user0m0.196s | sys 0m0.027s | | Pentium III 1.13GHz + Debian + GHC 6.3 (built from CVS HEAD on Feb 1, 2004) | | | real0m1.302s | user0m1.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,180) | b - mapArray id a | c - mapArray id b | hPutArray h c 180 | | | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
