- Glasgow-haskell-users

RE: Inlining question
by Simon Marlow 20 Apr '04

20 Apr '04

On 20 April 2004 01:40, Donald Bruce Stewart <> wrote: > It is sometimes very slightly annoying that misspelling a pragma will > mean that it is silently ignored. Oh well. I've typed: > > {-# OPITONS -fglasgow-exts #-} > or > {- # OPTIONS -fglasgow-exts #-} > > many times. I usually expect that GHC knows what I'm thinking, and am > surprised when it doesn't get it right ;) You probably don't want the warning on by default, since it is a Feature that unrecognised pragmas are ignored by default. I'd add the warning, except that it's not trivial - the pragmas are thrown away in the lexer, and the monad doesn't have a way to collect up warnings. I'll put it on the task list though. Cheers, Simon

1 0

RE: type checker tree output
by Simon Peyton-Jones 20 Apr '04

20 Apr '04

You can ask to dump the syntax tree of the program after type checking. This includes the type abstractions and applications inserted by the type checker. -ddump-tc But that's all. I'm not sure what the "search tree" is, but GHC certainly doesn't maintain one, nor does it print out one, I'm afraid. If type checking fails, you can still do a -ddump-tc, but what you get may be rather abbreviated. I doubt it's what you want. Other people have paid much more direct attention to type debugging, as I'm sure you know. Joe Wells, Martin Sulzmann, Greg Michaelson, Olaf Chitil, spring to mind among others. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Gregory Wright | Sent: 19 April 2004 16:25 | To: glasgow-haskell-users(a)haskell.org | Subject: type checker tree output | | | Hi, | | Is there any way to make GHC dump the type checker tree in some kind of | human readable format? I'm not interested in it when it is successful, | but I'd | like to look at the search tree when type checking fails. | | Is this possible? | | Best Wishes, | Greg Wright | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Inlining question
by Simon Peyton-Jones 20 Apr '04

20 Apr '04

| > Does inlining work with any function definitions (including those | > defined locally following a where.. say), or only with top level | > function definitions? If you mean In GHC, if I use an {-# INLINE #-} pragma on a nested function definition, should it be inlined? then the answer is yes, unless the function is recursive in which case the pragma is ignored. Do you have reason to suppose the contrary? If so, do send a test case Simon

3 3

type checker tree output
by Gregory Wright 19 Apr '04

19 Apr '04

Hi, Is there any way to make GHC dump the type checker tree in some kind of human readable format? I'm not interested in it when it is successful, but I'd like to look at the search tree when type checking fails. Is this possible? Best Wishes, Greg Wright

1 0

RE: amd64 seems to work
by Simon Peyton-Jones 19 Apr '04

19 Apr '04

That's great! Well done Don! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Donald Bruce Stewart | Sent: 19 April 2004 08:04 | To: glasgow-haskell-users(a)haskell.org | Subject: amd64 seems to work | | Hey, | | OVERALL SUMMARY for test run started at Sun Apr 18 23:53:04 MDT 2004 | 1040 total tests, which gave rise to | 2906 test cases, of which | 0 caused framework failures | 339 were skipped | | 2459 expected passes | 20 expected failures | 0 unexpected passes | 88 unexpected failures | | $ uname -msrp | OpenBSD 3.5 amd64 AMD Athlon(tm) 64 Processor 3200+ | | Most of those failures are 64bit results where the testsuite was expecting | 32bits. These amd64 boxes are nice. | | Cheers, | Don | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

amd64 seems to work
by dons＠cse.unsw.edu.au 19 Apr '04

19 Apr '04

Hey, OVERALL SUMMARY for test run started at Sun Apr 18 23:53:04 MDT 2004 1040 total tests, which gave rise to 2906 test cases, of which 0 caused framework failures 339 were skipped 2459 expected passes 20 expected failures 0 unexpected passes 88 unexpected failures $ uname -msrp OpenBSD 3.5 amd64 AMD Athlon(tm) 64 Processor 3200+ Most of those failures are 64bit results where the testsuite was expecting 32bits. These amd64 boxes are nice. Cheers, Don

1 0

Unreg linking runs out of memory (a soln)
by dons＠cse.unsw.edu.au 18 Apr '04

18 Apr '04

Just for any poor soul doing some linking tricks who gets hit by ld saying: /usr/obj/ports/ghc-6.2.1/scratch/ghc-6.2.1/libraries/base/libHSbase.a: could not read symbols: Memory exhausted This, for once, really is ld running at out memory, and you can fix it by adding: EXTRA_CC_OPTS="-Wl,-no-keep-memory" Happy porting, Don

1 1

Inlining question
by Adrian Hey 15 Apr '04

15 Apr '04

Hello, Does inlining work with any function definitions (including those defined locally following a where.. say), or only with top level function definitions? Thanks -- Adrian Hey

1 1

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