- Glasgow-haskell-users

UTF-8 encode/decode libraries.
by David Brown 03 May '04

03 May '04

I am writing some utilities to deal with UTF-8 encoded text files (not source). Currently, I'm just reading in the UTF-8 directly, and things work reasonably well, since my parse tokens are ASCII, they are easy to parse. However, the character type seems perfectly happy with larger values for each character. Is anyone aware of any Haskell libraries for doing UTF-8 decoding and encoding? If not, I'll write something simple. Thanks, Dave Brown

4 4

RE: GHC 6.2.1 retaining profiling broken?; program segfaults with -hrflag
by Simon Marlow 30 Apr '04

30 Apr '04

On 30 April 2004 14:25, Bayley, Alistair wrote: > I've tried to get a heap retaining profile (-hr) of my (largish) > program with GHC 6.2.1 (on Windows NT4), but it segfaults when run. I > can produce a -hc profile without grief. Is this a known problem? > > P.S. I've trimmed my program back a bit to provide a test case (and to > remove FFI code), but there are still five modules involved. It's not a known problem, but I think it has been reported once before. I'll get around to looking into it at some point. Cheers, Simon

1 0

GHC 6.2.1 retaining profiling broken?; program segfaults with -hr flag
by Bayley, Alistair 30 Apr '04

30 Apr '04

I've tried to get a heap retaining profile (-hr) of my (largish) program with GHC 6.2.1 (on Windows NT4), but it segfaults when run. I can produce a -hc profile without grief. Is this a known problem? P.S. I've trimmed my program back a bit to provide a test case (and to remove FFI code), but there are still five modules involved. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

RE: Dynamic loading problem
by Simon Marlow 30 Apr '04

30 Apr '04

On 29 April 2004 16:55, Hampus Ram wrote: > by using the RTS I've made it possible to dynamically load modules for > quite some time now. However, recently I've stumbled inte quite a > problem. > > I've created a bunch of modules to handle all dynamic loading for me > and things are good for simple programs. But now I want to load my > dynamic loading modules dynamically (yes, it sounds weird) and that > can't be done - not on linux anyways. > > The functions from the rts are ffi:ed into my program but when > dynamically loading the module, these functions can't be found > ("unknown symbol `lookupSymbol`") and neither can I load the > HSrts.o package to make them visible due to duplicate functions > ("I found a duplicate definition for symbol makeStableNamezh_fast"). > How can I proceed? Can I pass some flag to the linker or such to force > them to behave as I want? The linker (ghc/rts/Linker.c) has an explicit symbol table for symbols in the RTS that need to be visible in dynamically loaded code. Not pretty, but it works and is cross-platform. You need to add some more symbols to this table, and recompile the RTS. Alternatively, you might be able to re-link HSrts.o with --export-dynamic (something like 'ld -r --export-dynamic HSrts.o -o my-HSrts.o') and then link this object into your program. This works by making all the symbols in HSrts.o visible to the system's dynamic linker, which is used to resolve symbols that the RTS dynamic linker can't find. > I only have this problem with linux (tested on Debian and Redhat) > using ghc 6.2.1. On Solaris everything works just great (one doesn't > even have to load any extra packages there) with ghc 6.0.1. Not sure why it works on Solaris. Cheers, Simon

2 1

RE: turn off let floating
by Simon Marlow 30 Apr '04

30 Apr '04

On 29 April 2004 10:17, David Sabel wrote: >> You could try out that theory by copying the definition of >> unsafePerformIO into your code, and putting an INLINE pragma on it. >> I think it's safe to do this in your case (it's not safe in general). > > That's interesting for me, in which situations isn't it safe to inline > the definition of unsafePerformIO? We try to maintain the invariant that the IO action that is the argument to unsafePerformIO is atomic, in the sense that it is either completely performed or not performed when the application of unsafePerformIO is evaluated (ignoring exceptions). If we let the compiler inline unsafePerformIO, then the compiler would sometimes be able to share part of the IO computation amongst multiple instances, because it can see that the first action is applied to the realWorld# constant. Cheers, Simon

1 0

Dynamic loading problem
by Hampus Ram 29 Apr '04

29 Apr '04

Hi, by using the RTS I've made it possible to dynamically load modules for quite some time now. However, recently I've stumbled inte quite a problem. I've created a bunch of modules to handle all dynamic loading for me and things are good for simple programs. But now I want to load my dynamic loading modules dynamically (yes, it sounds weird) and that can't be done - not on linux anyways. The functions from the rts are ffi:ed into my program but when dynamically loading the module, these functions can't be found ("unknown symbol `lookupSymbol`") and neither can I load the HSrts.o package to make them visible due to duplicate functions ("I found a duplicate definition for symbol makeStableNamezh_fast"). How can I proceed? Can I pass some flag to the linker or such to force them to behave as I want? I only have this problem with linux (tested on Debian and Redhat) using ghc 6.2.1. On Solaris everything works just great (one doesn't even have to load any extra packages there) with ghc 6.0.1. /Hampus ps. my library can be found at http://www.dtek.chalmers.se/~d00ram/dynamic/ -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: d00ram(a)dtek.chalmers.se "Det är aldrig försent att ge upp"

3 4

RE: turn off let floating
by Simon Marlow 29 Apr '04

29 Apr '04

On 20 April 2004 12:48, Bernard James POPE wrote: > Results: > > method runtime (s) > --------------------------- > pure 0.7 > ffi 3.2 > fastMut 15 > ioref 23 I very strongly suspect that it is the unsafePerformIO that hurts performance in the fastMut case. Otherwise this case would be around the same speed as the FFI example, perhaps faster. You could try out that theory by copying the definition of unsafePerformIO into your code, and putting an INLINE pragma on it. I think it's safe to do this in your case (it's not safe in general). Cheers, Simon

3 2

wanted: tester for libraries/Win32
by Ross Paterson 28 Apr '04

28 Apr '04

Would someone who's building from CVS under Windows like to try make in libraries/Win32, libraries/HGL and libraries/HGL/examples, and even run the programs in the latter directory (should they happen to compile)?

1 0

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