- Haskell-Cafe - Haskell.org

FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell)
by Daan Leijen 03 Aug '06

03 Aug '06

Dear wxHaskell users, First of all, I apologize for not being responsive on the wxHaskell users mailing list. I recently changed jobs and countries and didn't properly take care of older email aliases. Anyway, even though I am motivated to support wxHaskell, practice proves that the project is too large for me to do alone. It would be great if someone or a group of people feel motivated enough to take over the project and release new versions that are compatible with the latest Ghc versions. One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I am happy to give volunteers administrator privileges on the sourceforge site and help out with the initial transition and building the initial new release (which is generally a lot of careful work in compiling and packaging correctly). All the best, -- Daan Leijen. Ps. Include me on the reply list as I am not subscribed properly to either mailing list at the moment. From: Simon Peyton-Jones Sent: Tuesday, August 01, 2006 4:46 AM To: Daan Leijen Subject: FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Daan Have you seen this thread? Would you care to respond to it? Simon From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jeremy O'Donoghue Sent: 01 August 2006 09:37 Cc: haskell-cafe(a)haskell.org; wxhaskell-users(a)lists.sourceforge.net Subject: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Hi list, Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active. It seems like there may be enough interest in wxHaskell to justify trying to revive the project. At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with newer wxWidgets versions or on Unicode systems requires the application of various patches (for which the interested potential user must search diligently). Ideally, it would be best Daan for to enable new CVS committers to the project (or even to hand over project administration), but if this is not an option, is there a possibility of hosting a fork on hackage.haskell.org (I think there's a benefit in hosting Haskell-specific projects in a Haskell-friendly location). I don't have the time to nurture huge ambitions for wxHaskell, but I think it is realistic to aim for the following in the short term: * Patches to ensure that wxHaskell compiles against latest wxWidgets versions on Mac, Linux and Windows (exists today) * Add Eric Kow's Unicode patches (exist today) * Produce suitable binary packages for whatever targets we can get maintainers for, compatible with up-to-date versions of both GHC and wxWidgets. * Improve samples and documentation. In the longer term, we could look at: * Fixing operation with sash windows (a personal gripe ;-) - easy * Wrapping some of the more complex widgets - easy. * Subclassing of widgets in Haskell ( i.e. allow C++ virtual methods to be redefined in Haskell) - moderately hard * Move from the Eiffel wxc bindings to wxC project to give better maintained interface to wxWidgets - time consuming, but easy * Porting to other Haskell implementations (Hugs, YHC etc) Taking on a project like this is a very significant commitment, and only makes sense if there are a number of willing contributors. I'm happy to kick this off and try to cover some of the boring 'administrative' bits, as well as contributing on documentation and smaller bug fixes, but I don't have time to save wxHaskell from permanent bit-rot. If there's enough interest, I'll push ahead with trying to organize this. Regards Jeremy On 01/08/06, shelarcy <shelarcy(a)gmail.com> wrote: > On 7/31/06, David F. Place <d(a)vidplace.com> wrote: >> Hi: >> >> I'm having trouble compiling wxhaskell 0.9.4 under both ghc 6.4.2 and >> ghc 6.5. Does anyone know where I should direct my queries? If you use ghc 6,4,2 under Windows platform, you can use my patched version of wxHaskell. And you can get my patch from Kamiariduki's source. http://www.haskell.org/pipermail/haskell/2006-June/018043.html https://sourceforge.net/project/showfiles.php?group_id=168626 I also know Eric Y. Kow's unicode patch doesn't include db problems fix. These problems has not only wxWidgets 2.6.x change, but also unicode change. I try to fix latter case, use attached after unicode patch, this fixes compile problem ... but it has another problem that can't use non-ascii characters correctly. So, if want to accesss DB by wxHaskell's ODBC, data is garbled and cause problems. I don't know how to fix that. Attached is already sent wxhaskell-user's list, but you can't get this file. So I send again. http://sourceforge.net/mailarchive/message.php?msg_id=16222530 My patch where I put Kamiariduki's project page doesn't include unicode support that I noticed above Mailng-List's log. Don't worry about this. You can use both my patch and unicode patch, if you want. These cause conflict message but this is not problem. On Tue, 01 Aug 2006 08:18:27 +0900, Jason Dagit <dagit(a)eecs.oregonstate.edu> wrote: > I've done this recently. I put my notes on the wiki: > http://www.haskell.org/haskellwiki/WxHaskell/Install#Windows I don't know this problem when I made patch. So, my patch doesn't fix this problem. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/ ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ wxhaskell-users mailing list wxhaskell-users(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

6 7

Can Your Programming Language Do This?
by Stephane Bortzmeyer 03 Aug '06

03 Aug '06

>From the excellent programming blog "Joel on software", a very good text if you need to convince Java or C programmers that functional programming is a A Good Thing. Probably all the readers of this list will find it brings nothing new (that's perfectly right) but it is oriented towards ordinary programmers :-) http://www.joelonsoftware.com/items/2006/08/01.html

6 9

ANN: TextRegexLazy-0.56, (=~) and (=~~) are here
by Chris Kuklewicz 03 Aug '06

03 Aug '06

Announcing: TextRegexLazy version 0.56 Where: Tarball from http://sourceforge.net/projects/lazy-regex darcs get --partial [--tag=0.56] http://evenmere.org/~chrisk/trl/stable/ License : BSD, except for DFAEngine.hs which is LGPL (derived from CTK light) Development/unstable version is at: darcs get [--partial] http://evenmere.org/~chrisk/trl/devel/ This is the version that has eaten John Meacham's JRegex library and survived to become strong. Thanks John! It now compiles against the posix regexp provided by the c library and the pcre library, in addition to the "full lazy" and the "DFA" backends. All 4 backends can accept regular expressions given as String and as ByteString. All 4 backends can run regular expressions against String and ByteString. In particular, the PosixRE and PCRE can run very efficiently against ByteString. (Though the input for the PosixRE needs to end in a \NUL character for efficiency). So there are 4*2*2 = 16 ways to use to provide input to this library. And the RegexContext class has at least 11 instances that both (=~) and (=~~) can target. So that is 4*2*2*11*2 = 352 things you can do with this library! Get your copy today! To run with cabal before 1.1.4 you will need to comment out the "Extra-Source-Files:" line in the TextRegexLazy.cabal file. The Example.hs file: > {-# OPTIONS_GHC -fglasgow-exts #-} > import Text.Regex.Lazy > import Text.Regex.Full((=~),(=~~)) -- or DFA or PCRE or PosixRE > > main = let b :: Bool > b = ("abaca" =~ "(.)a") > c :: [MatchArray] > c = ("abaca" =~ "(.)a") > d :: Maybe (String,String,String,[String]) > d = ("abaca" =~~ "(.)a") > in do print b > print c > print d This produces: > True > [array (0,1) [(0,(1,2)),(1,(1,1))],array (0,1) [(0,(3,2)),(1,(3,1))]] > Just ("a","ba","ca",["b"]) You can also use makeRegex and makeRegexOpts to compile and save a regular expression which will be used multiple times. Each of the 4 backends has a separate "Regex" data type with its own option types. For low level access, the WrapPCRE and WrapPosix modules expose a typesafe layer around the c libraries. You can query the "getVersion :: Maybe String" to see if the have been compiled into the library. It may be possible to use WrapPCRE and the UTF8 option flags to do unicode regex matching with PCRE. ( The Full and DFA backends use the Haskell unicode Char already ). Adding new types to String/ByteString is a matter of adding instances to the existing classes. Feedback and comments of any length is welcome. -- Chris Kuklewicz

2 2

Re: [Haskell-cafe] ANN: TextRegexLazy-0.56, (=~) and (=~~) are here
by Chris Kuklewicz 03 Aug '06

03 Aug '06

Bulat Ziganshin wrote: > Hello Chris, > > Wednesday, August 2, 2006, 3:16:58 PM, you wrote: > >> Announcing: TextRegexLazy version 0.56 > > your feature list is really strong! it will be great now to make it > a part of GHC standard distribution > > afaiu, selection of regex engine implemented via import statements? > You can actually choose which backend (=~) uses at runtime: > {-# OPTIONS_GHC -fglasgow-exts #-} > import Text.Regex.Lazy > > import qualified Text.Regex.PCRE as R > import qualified Text.Regex.PosixRE as S > import qualified Text.Regex.Full as F > > -- Choose which library to use depending on presence of PCRE library > > (=~) :: (RegexMaker R.Regex R.CompOption R.ExecOption a,RegexContext R.Regex b t > ,RegexMaker F.Regex F.CompOption F.ExecOption a,RegexContext F.Regex b t > ,RegexMaker S.Regex S.CompOption S.ExecOption a,RegexContext S.Regex b t) > => b -> a -> t > (=~) = case R.getVersion of > Just _ -> (R.=~) > Nothing -> case S.getVersion of > Just _ -> (S.=~) > Nothing -> (F.=~) > > main = print (("ba" =~ "(.)a") :: (String,String,String,[String])) The R.getVersion and S.getVersion detect whether it was compiled against PCRE or PosixRE. The (=~) is then chosen at run time.

1 0

[Parsec] Backtracking with try does not work for me?
by Stephane Bortzmeyer 03 Aug '06

03 Aug '06

I'm trying to write a Parsec parser for a language which authorizes (this is a simplified example) "a" or "a,b,c" or "a,c" or "a,b". (I can change the grammar but not the language.) The first attempt was: ***** CUT HERE **** import Text.ParserCombinators.Parsec import System (getArgs) comma = char ',' minilang = do char 'a' optional (do {comma ; char 'b'}) optional (do {comma ; char 'c'}) eof return "OK" run parser input = case (parse parser "" input) of Left err -> putStr ("parse error at " ++ (show err) ++ "\n") Right x -> putStr (x ++ "\n") main = do args <- getArgs run minilang (head args) ***** CUT HERE **** Of course, it fails for "a,c": parse error at (line 1, column 3): unexpected "c" expecting "b" for a reason explained in Parsec's documentation (the parser "optional (do {comma ; char 'b'})" already consumed the input, do note the column number). What puzzles me is that the solution suggested in Parsec's documentation does not work either: ********* CUT HERE ******************* minilang = do char 'a' try (optional (do {comma ; char 'b'})) optional (do {comma ; char 'c'}) eof return "OK" ********* CUT HERE ******************* parse error at (line 1, column 2): unexpected "c" expecting "b" Apparently, "try" was used (do note that the column number indicates that there was backtracking) but the parser still fails for "a,c". Why?

5 10

Future Edison directions
by Robert Dockins 02 Aug '06

02 Aug '06

Hello all, There has been very recently a thread discussing the design decisions involved in creating a sequence abstraction. This was naturally of interest to me as the current Edison maintainer, and generated a fair bit of interesting discussion. I'd like to kick off a new thread here to talk about future directions for the Edison API in particular. 1) Regarding Sequence, I have become convinced by the discussion that the Edison Sequence class should be broken down into smaller classes. Furthermore, it would be very nice to make these smaller classes shared across the various families of data structure abstractions in Edison (Sequences, Collections and Associative Collections). The formulation of Sequence of kind * -> * may need to be sacrificed to this end. I am not convinced that losing the maps and zips would be a major blow; however there are a couple of strategies for retaining them in some form. 2) The associated collection API is in a similar situation, except there are no zips. 3) I am reluctant to undertake a major overhaul of the Edison API while the future of type classes in Haskell' is so hazy. I haven't heard any news from the Haskell' type classes focus group in quite some time, and last I was aware, discussion was somewhat stalled. I there any hope for a coherent story here in the nearish future? 4) I am on the verge of deciding that nobody wants non-observable collections (ie, collections in which the element values are not available for inspection). Currently Edison has no implementations which are non-observable, and I am not aware of anyone else creating a datastructure implementation in Haskell which is non-observable. Therefore, I am considering removing this feature of the Edison typeclass hierarchy to reduce complexity. Shout if you think this would be a terrible mistake. 5) OTOH, something people DO seem to want is collection "views", or the ability to treat a datastructure as though it were something else. For example, it would be nice to transparently treat the keys of a finite map as a set, or to treat a nested sequence as a single flattened sequence. Such uses require the separation of operations which can create datastructures from those which merely inspect them (or some fancy bidirectional stuff I don't think I want to get into). 6) Edison 1.2 has now been out for a couple of months. If you've used or looked at the new Edison, I'd love to hear what you think. I think the next development cycle will involve pretty substantial changes, and if you want to get your gripes addressed, now is a good time to voice them. Alternately, if you think there are some aspects that are very important to keep, that's also good information. 7) Finally, I somehow feel like there should be a nice categorical formulation of these datastructure abstractions which would help to drive a refactoring of the API typeclasses in a principled way, rather than on an ad-hoc I-sort-of-think-these-go-together sort of way. Unfortunately, my category-fu is quite weak, so all I have is this vague intuition that I can't substantiate. I'm sort of familiar with initial algebras, but I think they may be too concrete. I'm looking for some way to classify algebras that have, eg, the property of having folds, or of being set-like, etc. If anybody can point me in the right direction wrt this, that would be great. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

3 5

A program which never crashes (even when a function calls "error")
by Stephane Bortzmeyer 02 Aug '06

02 Aug '06

[It is a philosophical question, not a practical programming problem.] I'm used, in imperative programming languages with exceptions (like Python) to call any function without fear of stopping the program because I can always catch the exceptions with things like (Python): while not over: try: code which may raise an exception... except Exception e: do something clever How to do it in Haskell? How can I call functions like Prelude.head while being sure my program won't stop, even if I call head on an empty list (thus calling "error")?

6 5

Fw: [Haskell-cafe] The difficulty of designing a sequence class
by Brian Hulley 02 Aug '06

02 Aug '06

David Menendez wrote: > Brian Hulley writes: > >> 1) Did Edison choose MonadPlus just because this fitted in with the >> lack of multi-parameter typeclasses in H98? > > Instances of Monoid (and your ISeq) have kind *. Instances of > MonadPlus (and Edison's Sequence) have kind * -> *. > > Functions like map, zip, and their variants are best defined in terms > of type constructors. > > With Sequence, you have > > zipWith :: (Sequence s) => (a -> b -> c) -> s a -> s b -> s c > > With ISeq, you'd have to do something like > > zipWith :: (ISeq s1 a, ISeq s2 b, ISeq s3 c) => > (a -> b -> c) -> s1 -> s2 -> s3 > > which isn't able to make any assumptions about s1, s2, and s3 having > the same structure. On the other hand it's more powerful because they can now have different structures ie was there any reason not to have: zipWith :: (Sequence s1, Sequence s2, Sequence s3) => (a -> b -> c) -> s1 a -> s2 b -> s3 c >> 3) Is it worth bothering to derive ISeq from Monoid (with the >> possible extra inefficiency of the indirection through the >> definitions for append = mappend etc or does the compiler completely >> optimize this out)? > > I would expect the compiler to inline append. Thanks - that's good news. I' probably still too much in C++ mode. >> 4) Would it be worth reconsidering the rules for top level names so >> that class methods could always be local to their class (ditto for >> value constructors and field names being local to their type >> constructor). > > Qualified module imports are the way to go, here. Do you really want > to start writing "if x Eq/== y Num/+ 1 then ... "? I'm beginning to see that qualified module imports are indeed the only way to go, because the methods in a type class are only the "virtual" methods - often there are many other "methods" which are put outside the class to save space in the dictionary but which conceptually belong to the class thus putting the class + these extra functions in a single module wraps everything up into a conceptual unit. eg: module Foldable ( Foldable(..) , reduceR ) where class Foldable c a | c -> a where foldR :: (a -> b -> b) -> b -> [a] -> b -- ... reduceR :: Foldable c a => (a -> b -> b) -> (c -> b -> b) reduceR f xs y = foldR f y xs forms the single conceptual unit to use Foldable.foldR, Foldable.reduceR etc so I'll have to retract my suggestion as regards classes... (Although I'm still concerned about value constructors and field names being in the top level instead of local to their type but changing this would require some changes to type inference (so that the constructors and field names could be used unqualified when the type at the given position is known eg by a top level type signature for the function or value) so that's more of a long term idea.) Regards, 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

5 6

The difficulty of designing a sequence class
by Brian Hulley 02 Aug '06

02 Aug '06

Hi - Part 1 of 2 - Monoid versus MonadPlus =========================== I've just run into a troublesome question when trying to design a sequence class: class ISeq c a | c -> a where empty :: c single :: a -> c append :: c -> c -> c However I've noticed that people sometimes separate the empty and append operations out as sequences with these ops form a Monoid therefore: class Monoid c => ISeq c a | c -> a where single :: a -> c -- now outside the class append :: ISeq c a => c -> c -> c append = mappend empty :: ISeq c a => c empty = mempty Another option, is the Edison library which uses: class (Functor s, MonadPlus s) => Sequence s where so here MonadPlus is used instead of Monoid to provide empty and append. So I've got three main questions: 1) Did Edison choose MonadPlus just because this fitted in with the lack of multi-parameter typeclasses in H98? 2) Are there any reasons to prefer the Edison design over the MPTC design (apart from H98 compatibility) or vice versa? 3) Is it worth bothering to derive ISeq from Monoid (with the possible extra inefficiency of the indirection through the definitions for append = mappend etc or does the compiler completely optimize this out)? and a fourth more long term question: 4) Would it be worth reconsidering the rules for top level names so that class methods could always be local to their class (ditto for value constructors and field names being local to their type constructor). For example it would be nice imho to be able to write: class Monoid c => ISeq c a | c -> a where length :: c -> Int f x y = Monoid/append x y -- or ISeq/append x y g x = ISeq/length x instead of having all names collide in the top level of a module, since at the moment it is difficult to think of method names that don't collide with the Prelude, and it's not nice to have to write "mempty" in place of "empty". Part 2 of 2 - Monad versus Ancillary result type ================================ Another issue relates to left and right views of a sequence. If a sequence is non-empty, the left view is just the leftmost element and the rest of the sequence. The problem arises when the sequence is empty. In the Edison library, this is solved by returning a monadic value ie: lview :: Monad m => s a -> m (a, s a) whereas from the paper "Finger trees: a simple general purpose data structure" by Ralf Hinze and Ross Paterson they use an ancillary data type to store the result of a view: data ViewL s a = NilL | ConsL a (s a) viewL :: FingerTree a -> ViewL FingerTree a So my question here is: what's the best choice? I can see that the monadic version has the advantage that it could be used in do notation in cases where you expect the sequence to be non-empty, but has the disadvantage that it treats the empty sequence as something special (resulting in Monad/fail) and an extra indirection to find the components when the sequence is non-empty. Anyway these are my main questions for now - any feedback appreciated ;-) Thanks, 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

8 19

Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Trouble compiling wxhaskell)
by Jeremy O'Donoghue 01 Aug '06

01 Aug '06

Hi list, Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active. It seems like there may be enough interest in wxHaskell to justify trying to revive the project. At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with newer wxWidgets versions or on Unicode systems requires the application of various patches (for which the interested potential user must search diligently). Ideally, it would be best Daan for to enable new CVS committers to the project (or even to hand over project administration), but if this is not an option, is there a possibility of hosting a fork on hackage.haskell.org (I think there's a benefit in hosting Haskell-specific projects in a Haskell-friendly location). I don't have the time to nurture huge ambitions for wxHaskell, but I think it is realistic to aim for the following in the short term: * Patches to ensure that wxHaskell compiles against latest wxWidgets versions on Mac, Linux and Windows (exists today) * Add Eric Kow's Unicode patches (exist today) * Produce suitable binary packages for whatever targets we can get maintainers for, compatible with up-to-date versions of both GHC and wxWidgets. * Improve samples and documentation. In the longer term, we could look at: * Fixing operation with sash windows (a personal gripe ;-) - easy * Wrapping some of the more complex widgets - easy. * Subclassing of widgets in Haskell (i.e. allow C++ virtual methods to be redefined in Haskell) - moderately hard * Move from the Eiffel wxc bindings to wxC project to give better maintained interface to wxWidgets - time consuming, but easy * Porting to other Haskell implementations (Hugs, YHC etc) Taking on a project like this is a very significant commitment, and only makes sense if there are a number of willing contributors. I'm happy to kick this off and try to cover some of the boring 'administrative' bits, as well as contributing on documentation and smaller bug fixes, but I don't have time to save wxHaskell from permanent bit-rot. If there's enough interest, I'll push ahead with trying to organize this. Regards Jeremy On 01/08/06, shelarcy <shelarcy(a)gmail.com> wrote: > > > On 7/31/06, David F. Place <d(a)vidplace.com> wrote: > >> Hi: > >> > >> I'm having trouble compiling wxhaskell 0.9.4 under both ghc 6.4.2 and > >> ghc 6.5. Does anyone know where I should direct my queries? > > If you use ghc 6,4,2 under Windows platform, you > can use my patched version of wxHaskell. > > And you can get my patch from Kamiariduki's source. > > http://www.haskell.org/pipermail/haskell/2006-June/018043.html > https://sourceforge.net/project/showfiles.php?group_id=168626 > > > I also know Eric Y. Kow's unicode patch doesn't > include db problems fix. These problems has not > only wxWidgets 2.6.x change, but also unicode > change. > > I try to fix latter case, use attached after unicode > patch, this fixes compile problem ... but it has > another problem that can't use non-ascii characters > correctly. So, if want to accesss DB by wxHaskell's > ODBC, data is garbled and cause problems. > > I don't know how to fix that. > > Attached is already sent wxhaskell-user's list, but > you can't get this file. So I send again. > http://sourceforge.net/mailarchive/message.php?msg_id=16222530 > > > My patch where I put Kamiariduki's project page doesn't > include unicode support that I noticed above Mailng-List's > log. > > Don't worry about this. You can use both my patch and > unicode patch, if you want. These cause conflict message > but this is not problem. > > > On Tue, 01 Aug 2006 08:18:27 +0900, Jason Dagit > <dagit(a)eecs.oregonstate.edu> wrote: > > I've done this recently. I put my notes on the wiki: > > http://www.haskell.org/haskellwiki/WxHaskell/Install#Windows > > I don't know this problem when I made patch. > So, my patch doesn't fix this problem. > > > -- > shelarcy <shelarcy capella.freemail.ne.jp> > http://page.freett.com/shelarcy/ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > wxhaskell-users mailing list > wxhaskell-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > > >

1 0