[Haskell-cafe] Fwd: [GHC] #939: Possible bug building wxhaskell
I reported the following bug and received the response below. Any wxhaskell hackers up to the challenge? I'd really love to see the makefiles go away and see wxhaskell just use cabal but I don't know if that's possible given the wxhaskell build requirements. Any help is much appreciated. Thanks Jason -- Forwarded message -- From: GHC <[EMAIL PROTECTED]> Date: Oct 13, 2006 5:21 PM Subject: Re: [GHC] #939: Possible bug building wxhaskell To: [EMAIL PROTECTED] #939: Possible bug building wxhaskell -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.6 Severity: normal| Resolution: invalid Keywords:| Difficulty: Unknown Architecture: x86 | Os: Unknown -+-- Changes (by duncan): * resolution: => invalid * status: new => closed Comment: It's not a GHC bug. It's a problem with the way wxHaskell is built. Admitidedly this is due to a slight change in the way GHC manages packages but it's not a bug as such, wxHaskell just needs fixing. What needs to happen is that the packages must be registered locally before they get used in other packages. Also, instead of importing the modules from the other package directly from the directory with -i foo/, it must be via -package foo. So you'll need to get in contact with someone who knows enough about wxHaskell's build system to fix it. Try asking on the ghc-users or haskell-cafe mailing lists. The bug report: I appologize if this isn't a GHC bug but since it started happening after a GHC upgrade I suspect it's a GHC bug. After upgrading to ghc6.6 on windows (using the release binary) I tried to install the current wxhaskell release found here: http://wxhaskell.sourceforge.net/download.html (version wxhaskell-src-0.9.4-1.zip) I have used wxhaskell on this machine before with older version of ghc (including ghc6.5, specifically visual haskell) so my environment for building the wxhaskell source was already setup. When I first got the error below I thought maybe my version of wxhaskell was messed up so I redownloaded the above zip file and unzipped a fresh copy. I unziped the source then I typed: configure && make Things went along fairly smoothly for a while then suddenly I got this error message: ghc -c wx/src/Graphics/UI/WX/Types.hs -o out/wx/imports/Graphics/UI/WX/Types.o -iout/wx/imports -odir out/wx/imports -hidir out/wx/imports -fvia-C -package-name wx -iout/wx/imports wx/src/Graphics/UI/WX/Types.hs:94:0: Bad interface file: out/wx/imports/Graphics/UI/WXCore/Types.hi Something is amiss; requested module wx:Graphics.UI.WXCore.Types differs from name found in the interface file wxcore:Graphics.UI.WXCore.Types make: *** [out/wx/imports/Graphics/UI/WX/Types.o] Error 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's going on in our courses?
Hi Is there a list or forum that talks about teaching our students about Haskell? Haskell Communities and Activities Report has a little place to put things like this: http://haskell.org/communities/ Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2Hs and Glade Tutorial
On Fri, 2006-10-13 at 15:18 +0200, Hans van Thiel wrote: > Hello Duncan, > > Thanks for your reply, and here's the pdf. Thanks. > One of the things to be improved, which I note myself, is something on > how to do it on the Windows platform. It's much the same of course, but yes that would be nice. > (This is assuming there is a Glade for Windows.) There is. It comes with the dev flavour of the Gtk+ installer. > Another thing is the terminology, for example about handles, actions and > functions. Glade uses 'signals' and 'callback functions' and you can > specify them visually. I believe (I'll have to check this) you can look > up the names in a file 'callbacks.c'. Of course you have to substitute > those for the Gtk2Hs equivalents, but it might make it easier to find > the appropriate ones in the Gtk2Hs API. We do have slightly different terminology in a few places and usually for good reason. For example the idea of a callback function makes a lot of sense in C where you really do have to have a named function that gets called in response to a signal. I Haskell we don't need a named function of course we can just say: onClicked button $ do ... ... > I'll check out the link you provided in the next few days, and I'm > looking forward to your comments. I'll also have to wait and see what > Eddy Ahmed, the author of the Glade tutorial, thinks about this idea. > It would be nice to reuse that, and to put the Haskell version on his > more general web site as well. Why re-invent the wheel.. I'll send you some more comments when I've had a full read through. Perhaps we should use the haskell.org wiki for this. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What's going on in our courses?
All, Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Thanks, Walt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Friday 13 October 2006 16:15, Ketil Malde wrote: > "Silviu Gheorghe" <[EMAIL PROTECTED]> writes: > > slowFunctionCacheList= [slowFunction (i) | i <-[0..500]] > > and use "slowFunctionCacheList !! i" instead of "slowFunction (i)" > > > > i am still curious about a better method (and a general one) > > Not much different in principle, but better in practice - you could > use an array rather than a list. O(1) lookups should make things (a > lot) faster. Well, this is true only if the range of the domain function is small and fairly dense. He said it was large and sparsely populated. With 500 elements, you're looking at allocating about 20Mb of memory _just to hold pointers to closures_ and then allocating and filling out 500 closures, all before you get down to doing any real work! That's just not going to be very fast. You're going to take a HUGE constant runtime and space penalty for that O(1) lookup. Little-endian patricia trees are probably the right way to go here (which I think has been mentioned already). You get O(log n) lookup and good behavior for a sparse and/or infinite domain because only the parts of the tree that are explored get unfolded. > -k -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
"Silviu Gheorghe" <[EMAIL PROTECTED]> writes: > slowFunctionCacheList= [slowFunction (i) | i <-[0..500]] > and use "slowFunctionCacheList !! i" instead of "slowFunction (i)" > i am still curious about a better method (and a general one) Not much different in principle, but better in practice - you could use an array rather than a list. O(1) lookups should make things (a lot) faster. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: optimization help
In fact avoiding space leaks was one of the motivations for our moving to an arrow framework for FRP (now called Yampa). Arrows amount to a point-free coding style, although with "arrow syntax" the cumbersomeness of programming in that style is largely alleviated. -Paul jeff p wrote: Hello, The (almost) point-free versions run faster than my "fast" imperative version and take up significantly less heap space-- even the version which reads everything and then writes takes up about 1/3 the heap space as my version. I get the impression that point-free style is a preventive measure against space leaks. thanks again, Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Porting content from the old wiki
On Fri, 13 Oct 2006, Henning Thielemann wrote: > > On Sun, 8 Oct 2006, Donald Bruce Stewart wrote: > > > The main thing holding up porting of content from the old wiki is > > licensing. In order to help this, could people who've written for the > > old wiki, and are happy to have that work moved to the new wiki and > > relicensed, add their names to the list here: > > > > http://haskell.org/haskellwiki/HaWiki_migration > > > > Or email me and I'll add the name. > > Then anyone can move your work over, which should really speed things up. > > What about adding a hint to Hawiki, that the reader should consider adding > new content to Haskellwiki instead of Hawiki? Is there some guide on how to translate Hawiki syntax to Haskellwiki syntax? Is there even some tool where I can say "move that article to HaskellWiki" and then it is translated and the Hawiki article is replaced by a link to the HaskellWiki article? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Porting content from the old wiki
On Sun, 8 Oct 2006, Donald Bruce Stewart wrote: > The main thing holding up porting of content from the old wiki is > licensing. In order to help this, could people who've written for the > old wiki, and are happy to have that work moved to the new wiki and > relicensed, add their names to the list here: > > http://haskell.org/haskellwiki/HaWiki_migration > > Or email me and I'll add the name. > Then anyone can move your work over, which should really speed things up. What about adding a hint to Hawiki, that the reader should consider adding new content to Haskellwiki instead of Hawiki? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] quick trivial question on records
I was reading Daan's paper on scoped labels and it struck me... has anyone tried a variation of the language where records are by dafault strict? and unboxed when appropriate? extended question: doesn't it makes more sense? laziness and partial applications go very well together, and the ADT constructors are often partially applied... __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Fri, Oct 13, 2006 at 08:52:09AM -0400, Jan-Willem Maessen wrote: > >I guess the reason is balancing. I can't think of any way of > >balancing a > >lazy tree that wouldn't break abstraction. > > Uh, Patricia trees aren't balanced in the usual sense. > There is exactly one tree structure for a given set of keys, > regardless of insertion order etc. (IntSet and IntMap workes > approximately as Carl Witty described last I checked, though I won't > swear to whether bits are taken low to high or vice versa.) Ah, IntMaps! Forget what I said. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Oct 13, 2006, at 4:05 AM, Tomasz Zielonka wrote: On Thu, Oct 12, 2006 at 08:40:44PM -0700, John Meacham wrote: it is too bad IntSet and IntMap are strict in their subtrees, it would have been nice to provide things like out of curiosity, why are IntMap and IntSet strict in their subtrees. I guess the reason is balancing. I can't think of any way of balancing a lazy tree that wouldn't break abstraction. Uh, Patricia trees aren't balanced in the usual sense. There is exactly one tree structure for a given set of keys, regardless of insertion order etc. (IntSet and IntMap workes approximately as Carl Witty described last I checked, though I won't swear to whether bits are taken low to high or vice versa.) I had assumed the strictness was to avoid deferring O(n) insertion work to the first lookup operation---though really it makes no difference in an amortized sense. -Jan-Willem Maessen Perhaps I would be possible to use some trick to rebalance an existing tree to account for what's currently evaluated. But it could be very tricky to get it right and it would certainly go beyond Haskell 98. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe smime.p7s Description: S/MIME cryptographic signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A type in search of a name...
Albert Lai wrote: "Brian Hulley" <[EMAIL PROTECTED]> writes: You'll never believe it but I've been struggling last night and all of today to try and think up a name for the following type and I'm still nowhere near a solution: data ??? = VarId | VarSym | ConId | ConSym Perhaps Atom. Thanks for the suggestion, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: optimization help
> The (almost) point-free versions run faster than my "fast" > imperative version and take up significantly less heap space-- even > the version which reads everything and then writes takes up about 1/3 > the heap space as my version. That was not intended, though I'm very pleased :-D > I get the impression that point-free style is a preventive measure > against space leaks. Ah, good point, I didn't think about it that way. Point-less makes a bit sure that old values are not leaking around as they are not passed through the "pipe". Yet, I'm a bit astonished. I thought that when compiling with -O2, cosmetic changes should become negligible. Perhaps the strict foldl' has an effect? Regards, afpelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: function result caching
Carl Witty wrote: > Instead of using an infinite list, you can use an infinite binary tree, > with a cached result at every node. This, also known as patricia tree, is indeed the canonical answer. In general, one can always construct an (in)finite map from keys (Ints in the present case) to values as a trie. See also Ralf Hinze. Generalizing generalized tries. Journal of Functional Programming, 10(4):327-351, July 2000 http://www.informatik.uni-bonn.de/~ralf/publications/GGTries.ps.gz This paper uses generic programming, but that should not be the problem as concrete cases can always be constructed "by hand" in plain Haskell. To apply this to Ints, one should view them as type Int = [Digit] data Digit = Zero | One Also note that there is absolutely no balancing involved (which would break infinite and lazy stuff). Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Thu, Oct 12, 2006 at 08:40:44PM -0700, John Meacham wrote: > it is too bad IntSet and IntMap are strict in their subtrees, it would > have been nice to provide things like > > out of curiosity, why are IntMap and IntSet strict in their subtrees. I guess the reason is balancing. I can't think of any way of balancing a lazy tree that wouldn't break abstraction. Perhaps I would be possible to use some trick to rebalance an existing tree to account for what's currently evaluated. But it could be very tricky to get it right and it would certainly go beyond Haskell 98. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
