April 2004 - Glasgow-haskell-users

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

15 Apr '04

> On Fri, Apr 09, 2004 at 03:27:01PM +0200, David Sabel wrote: > > > you can turn off let-floating by compiling without optimizations, > > i.e. without using a -O flag or using -O0 explicitly. > > The disadvantage is that most of all other optimizations > > are turned off too. > > That is exactly what I'm doing at the moment. The module that has the > nasty impure bits in it is not compiled with optimisations. > I will improve this when GHC regains the non-let floating flag. If you need -ffull-laziness to force a certain behaviour when using unsafePerformIO, I say that what you're doing is at the very least unsupported ;-) However, there are occasoinally good uses for this: HOOD is one; I imagine your case is similar? Cheers, Simon

3 2

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

14 Apr '04

> On Tue, Apr 13, 2004 at 03:53:31PM +0100, Simon Marlow wrote: > > 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? > > Here it is: > ------------------------------- > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package lang ... linking ... done. > Loading package concurrent ... linking ... done. > Loading package QuickCheck ... linking ... done. > Loading package readline ... linking ... done. > Loading package unix ... linking ... done. > Loading package posix ... linking ... done. > Loading package util ... linking ... done. > Loading package data ... linking ... done. > Loading package wxcore ... ghc-6.2.1: can't load .so/.DLL > for: wxc-gtk2.4.2-0.7 > (/usr/local/stow/wxhaskell//lib/libwxc-gtk2.4.2-0.7.so: > undefined symbol: > _ZN10wxGLCanvasC1EP8wxWindowiRK7wxPointRK6wxSizelRK8wxStringPi > RK9wxPalette) > ------------------------------ > > I suspect it's something funny with Debian's setup, and quite possibly > a bug somewhere else in Debian. That symbol looks suspiciously like it comes from the separate OpenGL parts of WX, which reside in a separate library (/usr/lib/libwx_gtk_gl-2.4.so here). On my system, libwxc has an explicit dependency on libwx_gtk_gl, because it was linked against it. Did you configure wxHaskell with --with-opengl? Cheers, Simon

4 3

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

13 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