- Glasgow-haskell-users

RE: [Haskell] Dynamically loading wxhaskell?
by Simon Marlow 14 Apr '04

14 Apr '04

> On Fri, Apr 02, 2004 at 01:59:08PM +0100, Simon Marlow wrote: > > Very strange. Is /usr/lib/libdl.so perhaps a symlink to a > library that > > doesn't exist? That could happen if an upgrade had gone > wrong, perhaps. > > Thanks, it was a dangling symlink due to my filesystem layout. Sorry > for the stupidity. > > But it still won't run, because (apparently) ghci won't work with > stripped .so files, and Debian policy is to strip them. From the > Debian policy manual, section 10.2: > > All installed shared libraries should be stripped with > strip --strip-unneeded <your-lib> > (The option `--strip-unneeded' makes `strip' remove only > the symbols > which aren't needed for relocation processing.) Shared > libraries can > function perfectly well when stripped, since the symbols > for dynamic > linking are in a separate part of the ELF object file.[1] > > [1] You might also want to use the options > `--remove-section=.comment' and > `--remove-section=.note' on both shared libraries and > executables, and > `--strip-debug' on static libraries. > > Any chance of fixing this in ghci, or do I have to keep an extra copy > of wxwidgets installed? What tool does ghci use for its dynamic > loading? I tried stripping /usr/lib/libwx_gtk-2.4.so.0.1.1 and libwxc-0.6.so, and GHCi was still able to load the wx package successfully. In fact, libwx_gtk appeared to be already stripped. What error messages do you get, specifically? Cheers, Simon

2 1

RE: [Haskell-cafe] Building Haddock on Windows
by Bayley, Alistair 13 Apr '04

13 Apr '04

> Try upgrading GHC. Thanks, I'll try that. Would it be too much to ask that Haddock be distributed with GHC? Reasons for: - GHC library docs are produced with Haddock - GHC library docs already include Haddock interface files - would ensure version of Haddock matches that used to produce interface files - would save lazy developers like myself from downloading and compiling. Think of it as one less barrier to overcome; a small step closer to more widespread adoption. Reasons against: - would favour one documentation tool over others - would add an unnecessary item to GHC build/packaging procedure (is this much of an overhead?) Mind you, if you include Haddock, why stop there? Why not include other developers tools, like (say) Hmake, Happy, Hat, ...? Alistair. > -----Original Message----- > From: Simon Marlow [mailto:simonmar@microsoft.com] > Sent: 13 April 2004 10:59 > To: Bayley, Alistair > Cc: haskell-cafe(a)haskell.org > Subject: RE: [Haskell-cafe] Building Haddock on Windows > > > Yes, I suspect you have a mismatch between the version of Haddock on > your system and the version of Haddock used to produce the interfaces. > Try upgrading GHC. > > Cheers, > Simon > > > -----Original Message----- > > From: Bayley, Alistair [mailto:Alistair_Bayley@ldn.invesco.com] > > Sent: 05 April 2004 16:19 > > To: Simon Marlow > > Cc: haskell-cafe(a)haskell.org > > Subject: RE: [Haskell-cafe] Building Haddock on Windows > > > > Trying to invoke Haddock with > > --read-interface=c:\ghc\ghc-6.0\doc\html\base\base.haddock > > > > Initially I get a stack overflow, so I added: +RTS -K2M -RTS ... > > > > and now I get: > > Fail: end of file > > Action: Data.Binary.getWord8 > > > > Is the --read-interface option specified correctly? This is > > where my GHC > > installation is, and the base.haddock file exists in there. I > > assume this is > > the interface file. > > > > Is this a compatibility problem? i.e. haddock file > > distributed with GHC 6.0 > > too old for Haddock 0.6? ----------------------------------------- ***************************************************************** 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: [Haskell] Dynamically loading wxhaskell?
by Simon Marlow 13 Apr '04

13 Apr '04

> But it still won't run, because (apparently) ghci won't work with > stripped .so files, and Debian policy is to strip them. From the > Debian policy manual, section 10.2: > > All installed shared libraries should be stripped with > strip --strip-unneeded <your-lib> > (The option `--strip-unneeded' makes `strip' remove only > the symbols > which aren't needed for relocation processing.) Shared > libraries can > function perfectly well when stripped, since the symbols > for dynamic > linking are in a separate part of the ELF object file.[1] > > [1] You might also want to use the options > `--remove-section=.comment' and > `--remove-section=.note' on both shared libraries and > executables, and > `--strip-debug' on static libraries. > > Any chance of fixing this in ghci, or do I have to keep an extra copy > of wxwidgets installed? What tool does ghci use for its dynamic > loading? Hmmm.... GHCi just uses the system's dynamic linker to link .so files (i.e. dlopen()/dlsym()), so I don't understand why it should behave differently. I'll look into it. Cheers, Simon

1 0

turn off let floating
by Bernard James POPE 10 Apr '04

10 Apr '04

Hi all, In the documentation for System.IO.Unsafe it says: Make sure that the either you switch off let-floating, or that the call to unsafePerformIO cannot float outside a lambda. My question is how can you turn off let floating? I can't seem to find a flag that suggests this behaviour. Cheers, Bernie.

2 2

Announcement: GHC 6.2.1 under darwinports
by Gregory Wright 09 Apr '04

09 Apr '04

Hi, The Glasgow Haskell Compiler supported under darwinports has been bumped to version 6.2.1. By default, GHC now builds with OpenGL support. The build should work for both OS X 10.2.x and 10.3.x. This lets Mac OS X jaguar users to get the latest version of GHC, as Wolfgang Thaller's binary release is only tested with panther. It can also provide amusement for those who just like to build from source. For information on getting darwinports, see http://darwinports.opendarwin.org. Best Wishes, Greg Wright Gregory Wright Antiope Associates LLC gwright(a)antiope.com

1 0

Re: unsafePerformIO
by George Russell 08 Apr '04

08 Apr '04

Sven Panne wrote: > Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO > and a pragma for clever compilers you can simulate something like a global > variable in Haskell. Here an excerpt from the GLUT menu handling module: > > {-# NOINLINE theMenuTable #-} > theMenuTable :: IORef MenuTable > theMenuTable = unsafePerformIO (newIORef emptyMenuTable) ... > > Definitely not something to be proud of, but quite handy from time to time. :-) > Alternatives are passing the IORef to every function which needs it (but this > would clutter up the GLUT API in the above case) or using the FFI for holding > global data on the C side. GHC uses a similar hack internally, too, BTW. This is not just handy from time to time, but very frequently. I've just discovered it occurs about 100 times in 100K LOC that I am responsible for, so often that I have stopped feeling guilty about it. I don't really know what else I could do. One solution would be to use implicit parameters to pass a global state variable around, but this would require me to change the type of huge numbers of functions, since implicit parameters are still explicit in types. I don't remember having any actual bugs caused by unsafePerformIO. Well, only one, before I knew about putting NOINLINE in.

1 0

What means MutVar# ?
by HNBeck＠t-online.de 08 Apr '04

08 Apr '04

Hi, by trying to understand how "writeIORef" works, I looked at data STRef s a = STRef (MutVar# s a) what is MutVar# ? (especially zhe "#" ) ? I've readed tha writeIORef (and readIoRef etc) is used to write directly to memory places fo implementing variables, as in example in HOpenGL used. Is this also Haskell standard ? Thanks for help Hans

2 1

RE: Haskell profiling and performance
by Simon Peyton-Jones 08 Apr '04

08 Apr '04

That's unexpected to me at least. We'll investigate. But probably not until after Easter. If you can send a program (smaller the better) that demonstrates this performance difference, we'd make much faster progress. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ketil Malde | Sent: 07 April 2004 07:33 | To: glasgow-haskell-users(a)haskell.org | Subject: Haskell profiling and performance | | | Hi, | | Am I doing something wrong, or did profiling performance drop an order | of magnitude with GHC 6.2? When I compile my program with '-prof | -auto-all', it takes about ten times as long to run as it does | without. I use -O2 in both cases, and run without any run-time | profiling options switched on. | | (The reported time, OTOH, seems about right) | | I though that previously profiling-compiling programs would only have | marginal effects, and only running with heap profiling on would really | slow things down. | | If this is a recent 'feature' and not just my brain getting its wires | crossed again, is there any way to alleviate this (downgrade to x.y, | build CVS HEAD, whatever)? | | (GHC 6.2 on Linux, tested with RPM package and Gentoo binary | distribution) | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Haskell performance
by Simon Marlow 07 Apr '04

07 Apr '04

> Okay. What's really bothering me is that I can't find any good > indication of what to do to get IO faster. Do I need to FFI the whole > thing and have a C library give me large chunks? Or can I get by with > hGet/PutArray? If so, what sizes should they be? Should I use memory > mapped files? hGet/PutArray should be pretty quick. For small requests, they get the usual buffering treatment that other Handle operations have, and for large requests the buffer is bypassed. For reading a file in one go, hGetArray (or hGetBuf) is the way to go. GHC itself uses hGetBuf for reading source files, hGetArray for reading interface files, and hPutBuf for writing output. Memory mapped files (mmap) should be even quicker. But then you'll have to use peek & co from Foreign to access the bytes. Cheers, Simon

2 1

RE: turn off let floating
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

Strangely (and bogusly) there is no such flag in GHC6.2. Someone must have noticed this already because it's there in the HEAD (-fno-full-laziness), and has been since Feb 2004. Strange. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bernard James POPE | Sent: 06 April 2004 09:24 | To: glasgow-haskell-users(a)haskell.org | Cc: Bernard James POPE | Subject: turn off let floating | | Hi all, | | In the documentation for System.IO.Unsafe | it says: | | Make sure that the either you switch off let-floating, | or that the call to unsafePerformIO cannot float outside a lambda. | | My question is how can you turn off let floating? I can't seem to | find a flag that suggests this behaviour. | | Cheers, | Bernie. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1