- Glasgow-haskell-users

wx library trouble
by Patrick Scheibe 21 Apr '05

21 Apr '05

Hi, I compiled successful the wxHaskell lib. But when I want to start ghci -package wx following error occurs: Loading package concurrent-1.0 ... linking ... done. Loading package wxcore-0.9 ... linking ... ghc-6.4.20050320: /home/izbifs/scheibe/built/lib/wxcore2.o: unknown symbol `wxcWakeUpIdle' *** Deleting temp files Deleting: ghc-6.4.20050320: unable to load package `wxcore-0.9' I have a running wxHaskell home. Same configuration... wxGtk version, wxhaskell version, same config options except of the prefix. In university it is installed local but I set the LD_LIBRARY_PATH. How can I figure out what's wrong? Can find out where and why the function `wxcWakeUpIdle' is available home and where are the differences? Has anybody a good hint where to start or what to check? Any help is welcome Cheers Patrick PS: Additional informations.. i386 GNU/Linux Fedora gtk+-1.2.10-33 gtk+-devel-1.2.10-33 wxGTK-2.4.2 wxHaskell 0.9 ghc version 6.4.20050320

4 3

existential & GADT & escape
by Jim Apple 20 Apr '05

20 Apr '05

> data Z > data S a > > data L a n where > Nil :: L a Z > Con :: a -> L a b -> L a (S b) > > data LL a = forall n . LL (L a n) > > class Append p q r where > nappend' :: L a p -> L a q -> L a r > > instance Append Z q q where > nappend' _ y = y > > instance (Append p q r) => Append (S p) q (S r) where > nappend' (Con x y) z = Con x (nappend' y z) > > nappend (LL x) (LL y) = LL (nappend' x y) No instance for (Append n n1 r) arising from use of `nappend'' at NList.lhs: :29-36 Probable fix: add (Append n n1 r) to the existential context for `LL' In the first argument of `LL', namely `(nappend' x y)' In the definition of `nappend': nappend (LL x) (LL y) = LL (nappend' x y) Clearly I can write nappend like: nappend :: LL a -> LL a -> LL a nappend (LL Nil) y = y nappend (LL (Con x Nil)) (LL z) = LL (Con x z) nappend (LL (Con x y)) (LL z) = nappend (LL (Con x Nil)) (nappend (LL y) (LL z)) but I'd rather keep the nice guarentee from nappend'. Any ideas? Jim

2 1

RE: Porting the GHC to GNU/Hurd
by Simon Marlow 20 Apr '05

20 Apr '05

On 10 April 2005 14:20, Thomas Schwinge wrote: > [ Grrr. Why do I have to subscribe just to post this message? ] Sorry for the inconvenience, it's because I don't have time to wade through all the spam. > Is someone aware of any efforts to port the GHC to GNU/Hurd? > If not, I'd like to give that a try. No, and good luck! Cheers, Simon

3 2

RE: garbage collection
by Simon Marlow 20 Apr '05

20 Apr '05

On 12 April 2005 15:59, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > 1) can you add disableGC and enableGC procedures? this can > significantly improve performance in some cases Sure. I imagine you want to do this to avoid a major collection right at the peak of a residency spike. You probably only want to disable major collections though: it's safe for minor collections to happen. You might be better off using System.Mem.performGC just before the residency spike. This doesn't have the pitfalls of enable/disableGC, but it might entail doing more GC than necessary. > 2) if, for example, program's data before GC is 80 mb and after GC is > 60 mb then the program will occupy after GC the whole 140 mb and ALL > this space will be marked by OS as used! if there's a memory shortage, > old program data even can be swapped to disk despite the fact that we > absolutely don't need them! that behaviour significantly enlarge > memory needs of GHC-compiled programs > > if this unused memory will be returned to OS or marked as unneeded > after GC then will problem will go on. preferably this must be done > during the time of GC, on each page which contents has been already > compacted. in this case such program will never use more than 80mb of > real memory (+ 1 page + memory for GC) I guess you're proposing using madvise(M_FREE) (or whatever the equivalent is on your favourite OS). This would certainly be a good idea if the program is swapping, but might impose an overhead when running in memory. I don't know, I haven't tried. Also, you might be better off using +RTS -c or +RTS -M<size> to avoid swapping in the first place. Cheers, Simon

2 1

RE: Why this happens?
by Simon Marlow 20 Apr '05

20 Apr '05

On 19 April 2005 15:37, Santoemma Enrico wrote: > I've always thought that compilers for functional languages were able > to recognize tail recursion and to transform it into a loop. So, why > this line eats all my machine's memory (and then runs out of stack > space)? > > sum [1..10000000] -- ten millions Without optimisation, or in GHCi, you get the overloaded version of sum: sum :: (Num a) => [a] -> a the compiler therefore cannot assume that (+) is strict. If you compile with optimisation, you'll get sum specialised to Int or Integer, which will use the strict definition. Cheers, Simon

1 0

RE: Partial application of type constructors?
by Simon Peyton-Jones 19 Apr '05

19 Apr '05

Allowing partially applied type synonyms amounts to allowing lambda at the type level, and that requires higher-order unification, and loses principal types (I think). So as of today, they are definitely out. If you look at the paper about "boxy types" on my home page, you'll see ways of extending type inference to support higher rank types and impredicativity. Next on the list is lambdas at the type level, in the same spirit: that is, support type inference by asking the programmer to help at "key moments". But don't hold your breath. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Conal Elliott | Sent: 19 April 2005 05:21 | To: glasgow-haskell-users(a)haskell.org | Subject: Partial application of type constructors? | | GHC 6.4 objects to the following simple program, pointing to the partial | application of the type constructor AddL. Is there a work-around? | | {-# OPTIONS -fglasgow-exts #-} | data LMap a b | type AddL arr a b = a `arr` LMap a b | data DFunA arr a b = DFunA (a `arr` b) (DFunA (AddL arr) a b) | | The complete error message: | | Type synonym `AddL' should have 3 arguments, but has been given 1 | When checking the data constructor: | forall arr a b. DFunA (arr a b) (DFunA (AddL arr) a b) | In the data type declaration for `DFunA' | | Is there a serious difficulty with handling partial type applications? | | - Conal | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

How to write an interpreter?
by Santoemma Enrico 19 Apr '05

19 Apr '05

Hello, may somebody give the directions to write an interpreter in Haskell? Is the parsec package enough, or I'll also need to write a 'grammar' and feed some tool with it? I want to put the language's source into xml and parse the file at runtime, so an embedded language isn't the right choice, I guess. Thanks, Enrico

2 1

RE: Edison Libraries in ghc 6.4
by Simon Marlow 19 Apr '05

19 Apr '05

On 17 April 2005 11:28, Carlos Areces wrote: > We are using Glasgow Haskell for the implemenation of a theorem > prover. > We use the Edison Libraries for efficient implementations of Sets and > Heaps. > We have a stable version of the prover with no problems and fairly > good performance working on ghc 6.2. > We have just installed ghc 6.4 and when compiling the source code > we've > received many warnings like the following one: > > ./src/hylores/ComplClauseSet.hs:51:0: > Warning: Deprecated use of type constructor or class `Min' > (imported from MinHeap) > This module is unmaintained, and will disappear soon > > We are making heavy use of types from the Edison library, so we > get quite a number of warnings, implying changes all over our code to > correct them. > > Which are exactly the problems with the Edison Library? And > what's its future with respect to ghc? Edison hasn't been converted to use hierarchical modules, and it doesn't have an active maintainer. Also, we're trying to slim down the default GHC install and move more libraries into external packages. We don't have any plans to replace it, except that we will provide a few of the more common concrete data structures (eg. Data.Map, Data.Set). We hope that third-party data structure libraries will fill the gap. Cheers, Simon

2 1

Why this happens?
by Santoemma Enrico 19 Apr '05

19 Apr '05

I've always thought that compilers for functional languages were able to recognize tail recursion and to transform it into a loop. So, why this line eats all my machine's memory (and then runs out of stack space)? sum [1..10000000] -- ten millions Enrico

2 1

RE: runghc badly broken
by Simon Marlow 19 Apr '05

19 Apr '05

On 18 April 2005 19:33, Niklas Broberg wrote: >> I'm trying to use runghc (6.4 release version, redhat linux), but it >> appears to be badly broken. It only processes the first argument >> given to it... > [snip] > > As a friend pointed out to me, some of this behavior may not be so > strange. Clearly, if you give arguments _after_ the specified source > file, you expect these to be arguments to that source file and not to > runghc itself. Thus the example > --------------------------- >> runghc Foo.hs -v1 > hello > --------------------------- > > executes as expected, since Foo.hs makes no use of -v1. That leaves > the other case, when the argument(s) is given _before_ the file > argument. It's obviously possible to give flags to runghc, shown by > runghc being verbose in the example > --------------------------- >> runghc -v1 Foo.hs > Loading package base-1.0 ... linking ... done. > > <interactive>:1:78: > Failed to load interface for `Main': > Could not find module `Main': > it is not a module in the current program, or in any known > package. Leaving GHCi. > --------------------------- > > but only the first one is processed. IMHO the preferred behavior is > that any arguments given before the single file argument is given to > runghc itself, while any given after the file argument is given to the > script in that file. Comments? Ok, I can make this change unless there are any objections? Cheers, Simon

1 0