- Haskell-Cafe - Haskell.org

Re[2]: Ready for testing: Unicode support for Handle I/O
by Bulat Ziganshin 19 Feb '09

19 Feb '09

Hello Khudyakov, Thursday, February 19, 2009, 4:06:06 PM, you wrote: >> i think that FilePath=String is ok, we just need to use utf8 string >> encoding on unix/macs and utf-16 encoding with *W functions on >> Windows. i have implemented such support inside my own application, and >> would be happy to mentor appropriate gsoc project > It won't _always_ work. current solution works never :) > And there are still 8-bit locales lurking somewhere in bush. UTF8 isn't > appropriate for them at all. i think that SetFilenameEncoding whould solve this, among with access to lower-level openFileUsingCStringPath -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Ready for testing: Unicode support for Handle I/O
by Simon Marlow 19 Feb '09

19 Feb '09

I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: http://www.haskell.org/~simonmar/base-unicode.tar.gz That is a set of patches against a GHC repo tree: unpack the tarball, and say 'sh apply /path/to/ghc/repo' to apply all the patches. Then clean your tree and build it from scratch (or if you're using the new GHC build system, just say 'make' ;-). It should validate, bar one or two minor failures. Oh, it doesn't work on Windows yet. That's the major thing left to do. If anyone else felt like tackling this I'd be delighted: all you have to do is implement a Win32 equivalent of the module GHC.IO.Encoding.Iconv (see below), everything else should work unchanged. Depending on whether any further changes are required, I may amend-record some of these patches, so treat them as temporary patches for testing only. Below is what will be the patch description in the patch for libraries/base. Comments/discussion please! Cheers, Simon Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). Currently hSetEncoding is availble from GHC.IO.Handle, and the encodings are available from GHC.IO.Encoding. We may want to export these from somewhere more permanent; that's something for a library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance is about 30% slower on "hGetContents >>= putStr" than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. IO library restructuring ~~~~~~~~~~~~~~~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.

7 15

Hoogle and Network.Socket
by Felix Martini 19 Feb '09

19 Feb '09

The Network.Socket module works fine on Windows. The original Winsock implementation was based on the Berkeley sockets api.

1 0

Re: [Haskell-cafe] How to create an online poll
by gregg reynolds 19 Feb '09

19 Feb '09

I.e. war, plague.famine. etc. gregg reynolds <dev(a)mobileink.com> wrote: >But what about the side effects? > >Rick R <rick.richardson(a)gmail.com> wrote: > >>I'm sure Premier Election Solutions (formerly Diebold) can provide us with >>an online voting solution. >>Their value-add services allows us to set the outcome beforehand, so, in >>effect, the the voting process will be determinate. Which is certainly of >>interest to Haskell coders. >> >> >>On Wed, Feb 18, 2009 at 4:05 PM, Max Rabkin <max.rabkin(a)gmail.com> wrote: >> >>> On Wed, Feb 18, 2009 at 10:40 PM, Anton van Straaten >>> <anton(a)appsolutions.com> wrote: >>> > There's also the Condorcet Internet Voting Service: >>> > >>> > http://www.cs.cornell.edu/andru/civs.html >>> >>> This looks like exactly what we need! Any objections? >>> >>> --Max >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> >>-- >>We can't solve problems by using the same kind of thinking we used when we >>created them. >> - A. Einstein >>_______________________________________________ >>Haskell-Cafe mailing list >>Haskell-Cafe(a)haskell.org >>http://www.haskell.org/mailman/listinfo/haskell-cafe

6 6

Re: [Haskell-cafe] Haskell.org GSoC
by Daniel Kraft 19 Feb '09

19 Feb '09

Hi, sylvain wrote: > In my humble opinion, Haskell presently fall short of its promises > because it does not embed theorem proving. Quickcheck-like testing is > truly great, but can not replace proofs to produce bug free software. > > With use of equational reasoning + induction, one can already prove a > huge amount of useful properties of an Haskell program [1]. this sounds like a really interesting project to me... Especially as I'm doing maths instead of CS as main subject (and it is simply inherently interesting :D). > theorem : ( xs :: [a], ys :: [a], f :: a -> b) => > length (map f (xs ++ ys )) = length xs + length yx > proof > length (map f (xs ++ ys )) = > length (xs ++ ys) = {- use length++ -} > length xs ++ length ys That's of course nice, but I'm at the moment not yet convinced something like this could be more or less easily implemented also for larger programs; and, I don't see from your example how the real implementation of the program should play in. Do you expect that Haskell figures out from the implementation that (map f) does not alter a lists length? Or should this be an already available theorem within the Prelude? I guess it should be the former, as otherwise the whole proofing seems to be just documentation, without real connection to the Haskell code. But in this case, I wonder whether something like that can be successfully done on more sophisticated code, and especially done as part of a GSoC project... But I guess with a competent mentor and clearly defined goals it should be possible. But all in all, as stated above, this could be really interesting :) Thanks for this suggestion and your ideas! Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri

1 0

Memory
by Jeff Douglas 19 Feb '09

19 Feb '09

Hello All, The kind people at #haskell suggested I come to haskell-cafe for questions about haskell performance issues. I'm new to haskell, and I'm having a hard time understanding how to deal with memory leaks. I've been playing with some network server examples and I noticed with each new connection, the memory footprint increases by about 7k However, the leaks don't seem to have anything to do with the networking code. Actually I get a huge leak just from using using 'forever'. > import Control.Monad > import System.IO > > main = forever $ putStrLn "hi" When I run it for a few seconds with profiling... > total time = 0.36 secs (18 ticks @ 20 ms) > total alloc = 54,423,396 bytes (excludes profiling overheads) Can this be right?

4 5

Returned mail: see transcript for details
by malcolm.wallace＠cs.york.ac.uk 19 Feb '09

19 Feb '09

Message could not be delivered

1 0

Re: permuting a list
by Okasaki, C. DR EECS 19 Feb '09

19 Feb '09

The discussion of randomly permuting a list comes up every few years. Here's what I wrote last time (2005): "Clearly, you can do a perfect shuffle in O(N) time using mutable arrays, using the standard imperative algorithm. You can also do it in O(N) expected time using *immutable* arrays, using Haskell's bulk array operations. 1. Start with a list of length N. If N < 2, stop. 2. Pair each element with a random index in the range [1,2N] (or [0,2N-1]). 3. Use "accum" to create an array of size 2N, where slot I contains a list of all the elements paired with I. 4. Map the shuffle function recursively across the array to re-shuffle any slots that got more than one element. 5. Append all the slots together into the result list. If you leave out step 4, you get an algorithm that runs in O(N) worst-case time, rather than expected time, but you no longer have a perfect shuffle (although it might be good enough). Upping the size of the array from 2N to 3N or 4N will help reduce collisions, but will not entirely eliminate them. With step 4, you can imagine pathological cases where everything gets put in the same slot, but with a reasonable random number generator, it is vanishingly unlikely that you will have enough collisions to drive the cost higher than linear. Again, upping the size of the array from 2N to 3N or 4N makes this even more unlikely." Now, you can consider it cheating to say this is O(N) expected time because it uses O(N log N) random bits. Fair enough. It is O(N) to the same extent that the ordinary imperative algorithm is O(N), albeit expected rather than worst case. -- Chris

2 1

Re: [Haskell-cafe] How to create an online poll
by gregg reynolds 19 Feb '09

19 Feb '09

Perhaps you are a subversive functor, hmm? We have monadic ways of conrolling you, fiend! Tellus who your natural tansformations are, or else! Andrew Wagner <wagner.andrew(a)gmail.com> wrote: >Help! Help! I'm being suppressed!! > >On Feb 18, 2009, at 5:05 PM, Rick R <rick.richardson(a)gmail.com> wrote: > >> I can't comment on any quantitative side effects, but the some >> intangible side effects include Distrustful Populace and >> MaliciousDissenters. However, if ghc is run with the - >> XUnscrupulousPolitics flag, those can be suppressed. >> >> On Wed, Feb 18, 2009 at 4:33 PM, gregg reynolds <dev(a)mobileink.com> >> wrote: >> I.e. war, plague.famine. etc. >> >> gregg reynolds <dev(a)mobileink.com> wrote: >> >> >But what about the side effects? >> > >> >Rick R <rick.richardson(a)gmail.com> wrote: >> > >> >>I'm sure Premier Election Solutions (formerly Diebold) can provide >> us with >> >>an online voting solution. >> >>Their value-add services allows us to set the outcome beforehand, >> so, in >> >>effect, the the voting process will be determinate. Which is >> certainly of >> >>interest to Haskell coders. >> >> >> >> >> >>On Wed, Feb 18, 2009 at 4:05 PM, Max Rabkin <max.rabkin(a)gmail.com> >> wrote: >> >> >> >>> On Wed, Feb 18, 2009 at 10:40 PM, Anton van Straaten >> >>> <anton(a)appsolutions.com> wrote: >> >>> > There's also the Condorcet Internet Voting Service: >> >>> > >> >>> > http://www.cs.cornell.edu/andru/civs.html >> >>> >> >>> This looks like exactly what we need! Any objections? >> >>> >> >>> --Max >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe(a)haskell.org >> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>> >> >> >> >> >> >> >> >>-- >> >>We can't solve problems by using the same kind of thinking we used >> when we >> >>created them. >> >> - A. Einstein >> >>_______________________________________________ >> >>Haskell-Cafe mailing list >> >>Haskell-Cafe(a)haskell.org >> >>http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> >> -- >> We can't solve problems by using the same kind of thinking we used >> when we created them. >> - A. Einstein >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: [Haskell-cafe] How to create an online poll
by gregg reynolds 19 Feb '09

19 Feb '09

Ok, that might protect us against the 7 plagues, so I'm not so worried about locusts. But what about Java, PHP etc. Is the monad sufficient protection against ultra-supernatural evil? Andrew Wagner <wagner.andrew(a)gmail.com> wrote: >Just wrap it in a ReallySafeWePromiseMonad > >2009/2/18 gregg reynolds <dev(a)mobileink.com> > >> I.e. war, plague.famine. etc. >> >> gregg reynolds <dev(a)mobileink.com> wrote: >> >> >But what about the side effects? >> > >> >Rick R <rick.richardson(a)gmail.com> wrote: >> > >> >>I'm sure Premier Election Solutions (formerly Diebold) can provide us >> with >> >>an online voting solution. >> >>Their value-add services allows us to set the outcome beforehand, so, in >> >>effect, the the voting process will be determinate. Which is certainly of >> >>interest to Haskell coders. >> >> >> >> >> >>On Wed, Feb 18, 2009 at 4:05 PM, Max Rabkin <max.rabkin(a)gmail.com> >> wrote: >> >> >> >>> On Wed, Feb 18, 2009 at 10:40 PM, Anton van Straaten >> >>> <anton(a)appsolutions.com> wrote: >> >>> > There's also the Condorcet Internet Voting Service: >> >>> > >> >>> > http://www.cs.cornell.edu/andru/civs.html >> >>> >> >>> This looks like exactly what we need! Any objections? >> >>> >> >>> --Max >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe(a)haskell.org >> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>> >> >> >> >> >> >> >> >>-- >> >>We can't solve problems by using the same kind of thinking we used when >> we >> >>created them. >> >> - A. Einstein >> >>_______________________________________________ >> >>Haskell-Cafe mailing list >> >>Haskell-Cafe(a)haskell.org >> >>http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>

2 1

Re: [Haskell-cafe] How to create an online poll
by gregg reynolds 19 Feb '09

19 Feb '09

But what about the side effects? Rick R <rick.richardson(a)gmail.com> wrote: >I'm sure Premier Election Solutions (formerly Diebold) can provide us with >an online voting solution. >Their value-add services allows us to set the outcome beforehand, so, in >effect, the the voting process will be determinate. Which is certainly of >interest to Haskell coders. > > >On Wed, Feb 18, 2009 at 4:05 PM, Max Rabkin <max.rabkin(a)gmail.com> wrote: > >> On Wed, Feb 18, 2009 at 10:40 PM, Anton van Straaten >> <anton(a)appsolutions.com> wrote: >> > There's also the Condorcet Internet Voting Service: >> > >> > http://www.cs.cornell.edu/andru/civs.html >> >> This looks like exactly what we need! Any objections? >> >> --Max >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > >-- >We can't solve problems by using the same kind of thinking we used when we >created them. > - A. Einstein >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Haskell users in the Houston area??
by Galchin, Vasili 19 Feb '09

19 Feb '09

Hello, Are there Haskell users in the Houston area? Regards, Vasili

2 1

question on types
by Daryoush Mehrtash 19 Feb '09

19 Feb '09

Is there a way to define a type with qualification on top of existing type (e.g. prime numbers)? Say for example I want to define a computation that takes a prime number and generates a string. Is there any way I can do that in Haskell? thanks, Daryoush

9 12

How to create an online poll
by Bulat Ziganshin 19 Feb '09

19 Feb '09

Hello haskell-cafe, http://zohopolls.com/ -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

ANN: The Typeclassopedia, and request for feedback
by Brent Yorgey 19 Feb '09

19 Feb '09

Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-fee… happy haskelling! -Brent

17 19

what is [::]
by Daniel van den Eijkel 18 Feb '09

18 Feb '09

Dear Haskellers, please can anybody tell me what [::] means or where to read about it? A few days ago I saw this for the first time in my life, at the list of instances of the Functor class, and I don't know where to look for information. The search engines I tried didn't produce results for [::]. Thanks, Daniel

2 2

estimating the speed of operation
by Belka 18 Feb '09

18 Feb '09

Hello, communion people! I have a little problem and ask for an advice. I'm trying to estimate the performance speed of one pure function, but get some strange results. ------------------------------------- import qualified module Data.ByteString.Lazy.Char8 as L8 import module Data.Digest.Pure.MD5 import module System.IO.Unsafe import module System.Time import module System.Random import module Data.Char clockTime2Tuple (TOD sec pic) = (sec, pic) getClockTimeTuple = getClockTime >>= (\ x -> return $ clockTime2Tuple x) subTimeTuples (s2,ps2) (s1,ps1) = let dps = ps2-ps1 in let (s,ps) = (s2-s1-(if dps<0 then 1 else 0), if dps<0 then dps+(10^12) else dps) in (s, (div) ps (10^6)) test_md5 test_input n = flip mapM test_input ( \ input_row -> do t1 <- getClockTimeTuple sequence_ (replicate n (return $ md5 input_row)) t2 <- getClockTimeTuple dt <- subTimeTuples t2 t1 return (dt) ) test_list = [ pack "Hello world!"] ++ [L8.replicate 1000000 ':'] ------------------------------------- The results are (iterations_count, microseconds): (1000, [105,105]) (+/- 10) (10000, [1000,950]) (+/- 50) (100000, [9050,9000]) (+/- 50) (1000000, [89200,89150]) (+/- 100) ------------------------------------- I suspect following problems, which make the results non-objective: 1. I cant get out of laziness 2. I don't turn off GHC internal optimizers So, perhaps, GHC evaluates the MD5 once, but cycles on something else?.. For now I can only guess. Could anybody, please clarify and maybe suggest configuration, which would allow objective speed estimation? Thanks in advance, Best regards, Belka -- View this message in context: http://www.nabble.com/estimating-the-speed-of-operation-tp22075843p22075843… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 3

Bug in Cabal?
by Martin Huschenbett 18 Feb '09

18 Feb '09

Hello haskell-cafe, trying to install ghci-haskeline I got the following error message: $ cabal install ghci-haskeline Resolving dependencies... cabal.exe: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 Looks like this is a bug in Cabal or cabal-install? Regards, Martin.

3 3

concurrent haskell debugging
by Jianzhou Zhao 18 Feb '09

18 Feb '09

Hi Folks, If I am using Control.Concurrent package, does GHC have any static or runtime tools or debuggers to detect problems, such as deadlock, data races? Cheers Jianzhou

2 1

Fwd: [Haskell-cafe] question on types
by Alberto G. Corona 18 Feb '09

18 Feb '09

As allways, I forgot to forward the message to the list, but the Conor response makes it irrelevant: ---------- Forwarded message ---------- From: Alberto G. Corona <agocorona(a)gmail.com> Date: 2009/2/18 Subject: Re: [Haskell-cafe] question on types To: Ryan Ingram <ryani.spam(a)gmail.com> > Seriously, I love undecidable instances, but there's gotta be a way to > make type-level programming less painful. GHC team: please give us > type-level integers that don't suck! If I ever have to see S (S (S (S > Z))) again it's too soon. I´m starting to read about dependent types and it´s very promising. Maybe my suggestion makes sense: is to "compress" recursive types such are S(S(S(S Z))) into internal compiler representations S <n> Z. This would type match faster and will generate much more clear and compact compilation errors.

1 0

Gtk2HS 0.10.0 Released
by Peter Gavin 18 Feb '09

18 Feb '09

Hi everyone, Oh, dear... it seems I've forgotten how to spell "cafe", and sent this message to haskell-caft(a)haskell.org the first time around. I resent it to all the lists again (just to make sure everyone interested receives it), so I apologize for any duplicated messages you might have received. In any case... I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff has gone into this release, including: - Support for GHC 6.10 - Bindings to GIO and GtkSourceView-2.0 - Full switch to the new model-view implementation using a Haskell model - Support for many more model-based widgets such as IconView and an updated binding for ComboBox - Full Drag-and-Drop support - Better support for Attributes in Pango - Replaced Event for EventM monad, thereby improving efficiency and convenience - Functions for interaction between Cairo and Pixbuf drawing - Lots of bug fixes, code cleanups, and portability improvements With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been deprecated. The TreeList modules have been deprecated from the Gtk+ bindings. Source and Win32 binaries are available at: https://sourceforge.net/project/showfiles.php?group_id=49207package_id=4244… Thanks to everyone who submitted bug fixes and features this time around! Thanks, Peter Gavin Gtk2HS Release Manager

10 13

"first class" tuples?
by Peter Verswyvelen 18 Feb '09

18 Feb '09

Tuples in Haskell always have annoyed me a bit since each tuple of different dimension is hardcoded (I guess compilers enforce a maximum dimension on tuples?) Since a tuple represents a fixed size data structure with different types at each coordinate, it feels as it should be possible to have a couple of type and data constructors to build a tuple, and to use recursion at the type level to have functions operate on tuples of any dimension. E.g. one could then have a tmap function that takes a tuple of functions and a tuple of values and applies the function at coordinate N to the value at coordinate N. Is something like this possible today in Haskell, e.g. using new features like type families, GADTs, template haskell, etc? Or do we need dependent types for it? In C++x0 I believe it is now possible to do so, since they even allow a variable number of template arguments, using recursion at compile time (see e.g. http://publib.boulder.ibm.com/infocenter/comphelp/v9v111/index.jsp?topic=/c… ) Grapefruit has something like first class records, so I guess it should be possible (and simpler) to do this for tuples?

4 3

C-like Haskell
by drblanco 18 Feb '09

18 Feb '09

I'm trying to do a calculation for Gauss' circle problem, which counts the integer lattice points with distance to the origin <= r. It's sequence A000328 on the AT&T integer sequence database. I can't figure out a way to do it quickly in Haskell for r around 10^9. Here's my attempt, which takes about 75s for r=10^8. circ2 r = (1+4*r) + 4 * (circ2' (rs+1) r 1 0) where rs = r^2 -- circ2' :: Int64 -> Int64 -> Int64 -> Int64 -> Int64 circ2' rad x y sum | x<y = sum | rad<=rs = circ2' (rad+1+2*y) x (y+1) (sum+1+2*(x-y)) | otherwise = circ2' (rad+1-2*x) (x-1) y sum The commented out line was to try to force it to use machine-size ints, but instead it made it eat memory like mad. It overflows if everything is forced to be ints, and isn't much faster. Making rad and sum Integers fixes the overflow but still takes ~45 secs. I do already have the number I wanted, but was wondering how this could be made faster, or even why it's so slow. This is all on GHC 6.8.3 under OS X Intel, using ghc -O2. For comparison, the C code below runs in <1 second. typedef unsigned long long bigint; bigint gausscount(bigint r) { bigint sum=0; bigint x, y; bigint rs=r*r; bigint rad=rs+1; x=r; y=1; while (y<x) { while (rad>rs) { rad-=2*x; rad++; x--; } sum+=1+2*(x-y); rad+=2*y+1; y++; } sum*=4; sum++; return sum; } -- View this message in context: http://www.nabble.com/C-like-Haskell-tp21717584p21717584.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 11

Postdoctoral Research Position at Yale University
by Paul Hudak 18 Feb '09

18 Feb '09

Postdoctoral Research Position at Yale University The Nettle Project in the Computer Science Department at Yale University seeks applicants for a one-year (minimum) postdoctoral research position. The successful candidate will apply modern, high-level programming language ideas (such as embodied in Haskell) to help design and implement a language for the control of BGP-based network routers, with the goal of realizing high-level networking protocols for traffic engineering, security, and related networking concerns. The ideal candidate will have strength both in programming language concepts and implementation techniques, as well as networking fundamentals. A PhD in computer science or related field is required. Yale is an affirmative action, equal opportunity employer. Interested candidates should send their CV or resume to Professor Paul Hudak at paul.hudak(a)yale.edu.

1 0

Polymorphism overhead
by Louis Wasserman 18 Feb '09

18 Feb '09

I have (roughly) the following code: data Foo e type MFoo e = Maybe (Foo e) instance Ord e => Monoid (Foo e) where f1 `mappend` f2 = <code invoking the mappend instance from Maybe (Foo e)> I'd expect this to optimize to the same thing as if I had implemented: meld :: Ord e => Foo e -> Foo e -> Foo e f1 `meld` f2 = -- code invoking meld' meld' :: Ord e => Maybe (Foo e) -> Maybe (Foo e) -> Maybe (Foo e) meld' (Just f1) (Just f2) = meld f1 f2 meld' m1 Nothing = m1 meld' Nothing m2 = m2 instance Ord e => Monoid (Foo e) where mappend = meld However, GHC's Core output tells me that the first piece of code reexamines the polymorphism in every recursion, so that mappend, which is used in the Monoid instance of Foo, looks up the Monoid instance of Foo *again* (for the sole purpose of looking itself up) and recurses with that. Why is this, and is there a way to fix that? Louis Wasserman wasserman.louis(a)gmail.com

2 1

Haskell Weekly News: Issue 105 - February 17, 2009
by Brent Yorgey 18 Feb '09

18 Feb '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090217 Issue 105 - February 17, 2009 --------------------------------------------------------------------------- Welcome to issue 105 of HWN, a newsletter covering developments in the [1]Haskell community. And here's the Belated Valentine's Day HWN! Motto: "Remembering that you love someone three days after you were supposed to is better than not remembering at all." Of course, it's late because I spent the weekend working on the Typeclassopedia (although you won't find a link to it in this HWN because I've only included things through Saturday). Much Haskell love to all! Announcements Plans for GHC 6.10.2. Ian Lynagh [2]announced a quick summary of the plans for GHC 6.10.2. If there is a bug not on the [3]high-priority list that is causing you major problems, please let the developers know. A release candidate is expected to be ready by the end of the week. Bug fix to regex-tdfa, new version 0.97.3. ChrisK [4]announced a [5]new release of regex-tdfa which fixes some additional bugs. Three Cheers For QuickCheck! Google Summer of Code 2009. Malcolm Wallace [6]announced that haskell.org will once again be applying to be a Google Summer of Code mentor organization. Now is the time to begin discussing ideas for student projects. Also, if you wish to help publicize GSoC amongst students, there are [7]official posters/fliers available. A long discussion of various project ideas followed, including some analysis of the factors which contribute to project success. happs-tutorial 0.7. Creighton Hogg [8]announced the release of [9]happs-tutorial 0.7, the first release of happs-tutorial built against the new [10]Happstack project. Creighton has now taken over development of the tutorial from Thomas Hartman. first Grapefruit release. Wolfgang Jeltsch [11]announced the first official release of [12]Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. CFP: 5th Haskell Hackathon, April 17-19, Utrecht. Sean Leather [13]issued a call for participation in the [14]5th Haskell Hackathon, which will be held in Utrecht, The Netherlands, from 17-19 April. The Haskell Hackathon is a collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure. All are welcome! See the website for more information, or join the IRC channel (#haskell-hac5). Please register if you plan to attend! Take a break: write an essay for Onward! Essays. Simon Peyton-Jones [15]announced a call for submissions to [16]Onward! Essays. An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma. The deadline is 20 April. Data.Stream 0.3. Wouter Swierstra [17]announced a new version of the [18]Data.Stream package, a modest library for manipulating infinite lists. Changes include support for lazy SmallCheck, an improved Show instance, stricter scans, various documentation fixes, and several new functions from Data.List. X Haskell Bindings 0.1. Antoine Latter [19]announced a new release of the [20]X Haskell Bindings (XHB) library. The goal of XHB is to provide a Haskell implementation of the X11 wire protocol, similar in spirit to the X protocol C-language Binding (XCB). Gtk2HS 0.10.0 released. Peter Gavin [21]announced a [22]new release of [23]Gtk2HS, the Haskell GTK bindings. Notable changes include support for GHC 6.10, bindings to GIO and GtkSourceView-2.0, a full switch to the new model-view implementation using a Haskell model, and many others. Discussion Haskell.org GSoC. Daniel Kraft began a [24]discussion about good topics for a Haskell GSoC project. Painting logs to get a coloured tree. Joachim Breitner asked about elegant ways to annotate trees, leading to an interesting [25]discussion. Blog noise [26]Haskell news from the [27]blogosphere. * Conor McBride: [28]FP Lunch: Djinn, monotonic. * Gregg Reynolds: [29]"Computation" considered harmful. "Value" not so hot either.. * Darcs: [30]darcs weekly news #17. * Antoine Latter: [31]Dependencies in Hackage, revisited. * GHC / OpenSPARC Project: [32]Allocate!. * Chris Done: [33]Updates: RSS and highlighting. * Chris Done: [34]Simple SMTP library with plain/login authentication. * The GHC Team: [35]Ever wondered how big a closure is?. * Luke Palmer: [36]Dana update: Core execution language, dependent combinators. * John Van Enk: [37]Distraction: Fun with diagrams!. * Magnus Therning: [38]New backend for epilicious pushed.. * Alex Mason: [39]Shootout PiDigits program kinda sucks (and possibly so does GHC). * Gtk2HS: [40]Gtk2Hs version 0.10.0 released. * Ketil Malde: [41]Notes from PADL. * Alson Kemp: [42]Kudos to Bodo. * xmonad: [43]New layout: XMonad.Layout.Cross. * Gregg Reynolds: [44]Programming Language Semiotics. * Gregg Reynolds: [45]Formal semantics for side effects. * xmonad: [46]contribs review: CycleWindows, multimedia keys, runOrCopy. * Conal Elliott: [47]From the chain rule to automatic differentiation. * Arnar Birgisson: [48]The Non-Determinism Monad. * Matthew Jones: [49]XMonad: A tiling window manager written in Haskell. * Gregg Reynolds: [50]Moggi :: CT -> Hask. * Lennart Augustsson: [51]More BASIC. Quotes of the Week * chrisdone: zipWith3 ($) (cycle [const,flip const]) "hai! haha!" "yarlysotense!" * quicksilver: I'm very unlikely to give the time of day to anything which doesn't let me continue to use emacs. * roconnor: don't let Float do your finance homework for you. * quicksilver: @go is made of STRING and FAIL. * drhodes: We're sorry Mr. Thunk, but this program is on a need to run basis, and you don't need to run. Now go away before I call the garbage collector. About the Haskell Weekly News New editions are posted to [52]the Haskell mailing list as well as to [53]the Haskell Sequence and [54]Planet Haskell. [55]RSS is also available, and headlines appear on [56]haskell.org. To help create new editions of this newsletter, please see the information on [57]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [58]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/16304 3. http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… 4. http://article.gmane.org/gmane.comp.lang.haskell.general/16859 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa 6. http://article.gmane.org/gmane.comp.lang.haskell.general/16857 7. http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers 8. http://article.gmane.org/gmane.comp.lang.haskell.general/16848 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52847 12. http://haskell.org/haskellwiki/Grapefruit 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52689 14. http://haskell.org/haskellwiki/Hac5 15. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52660 16. http://onward-conference.org/calls/foressays 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52558 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream/ 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52364 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb 21. http://www.haskell.org//pipermail/haskell-cafe/2009-February/055490.html 22. https://sourceforge.net/project/showfiles.php?group_id=49207package_id=4244… 23. http://www.haskell.org/gtk2hs/ 24. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52553 25. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52461 26. http://planet.haskell.org/ 27. http://haskell.org/haskellwiki/Blog_articles 28. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=187 29. http://syntax.wikidot.com/blog:5 30. http://blog.darcs.net/2009/02/news-and-discussions-1_13.html 31. http://panicsonic.blogspot.com/2009/02/dependencies-in-hackage-revisited.ht… 32. http://ghcsparc.blogspot.com/2009/02/allocate.html 33. http://chrisdone.com/blog/html/2009-02-13-lang-spec-tag-rss.html 34. http://chrisdone.com/blog/html/2009-02-13-smtp.html 35. http://ghcmutterings.wordpress.com/2009/02/12/53/ 36. http://lukepalmer.wordpress.com/2009/02/12/dana-update-core-execution-langu… 37. http://blog.sw17ch.com/wordpress/?p=18 38. http://therning.org/magnus/archives/499 39. http://axman6.homeip.net/blog/2009/02/shootout-pidigits-program-kinda-sucks… 40. http://haskell.org/gtk2hs/archives/2009/02/11/gtk2hs-version-0100-released/ 41. http://blog.malde.org/index.php/2009/02/11/notes-from-padl/ 42. http://www.alsonkemp.com/haskell/kudos-to-bodo/ 43. http://xmonad.wordpress.com/2009/02/10/new-layout-xmonadlayoutcross/ 44. http://syntax.wikidot.com/blog:4 45. http://syntax.wikidot.com/blog:3 46. http://xmonad.wordpress.com/2009/02/08/contribs-review-cyclewindows-multime… 47. http://conal.net/blog/posts/from-the-chain-rule-to-automatic-differentiatio… 48. http://www.hvergi.net/2009/02/the-non-determinism-monad/ 49. http://matburt.net/?p=36 50. http://syntax.wikidot.com/blog:1 51. http://augustss.blogspot.com/2009/02/more-basic-not-that-anybody-should-car… 52. http://www.haskell.org/mailman/listinfo/haskell 53. http://sequence.complete.org/ 54. http://planet.haskell.org/ 55. http://sequence.complete.org/node/feed 56. http://haskell.org/ 57. http://haskell.org/haskellwiki/HWN 58. http://code.haskell.org/~byorgey/code/hwn/

1 0

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Feb '09

17 Feb '09

Am Montag, 16. Februar 2009 22:04 schrieben Sie: > As for how I want Hieroglyph to work interactively, I think the easiest way > is to react to the input data considered as a coherent whole. The semantic > model for visualization is that a Visualization is a function from Data to > Visual. Hmm, doesn’t this approach result in scalability problems? You always have to analyse the complete input data if a small part of it changes and you always have to update the complete picture. This is similar to the problems I see with Yampa-based UI approaches. However, you might be interested in things like incremental list signals which I’m (re-)implementing at the moment. To a large degree, the library user sees a time-varying list but internally the library takes care of not updating the whole list all the time but only the parts which actually change. > The main problem I have, which is what I want FRP for, is that to consider > the data as a coherent whole, the data have to be composable. I don’t really understand this. Could you explain this, please? Best wishes, Wolfgang

1 0

Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Feb '09

17 Feb '09

Am Montag, 16. Februar 2009 22:43 schrieben Sie: > * Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> [2009-02-16 14:51:18+0100] > > > Maybe there is someone interested in helping me with the graphics > > support? There is already quite some stuff implemented (thanks to > > Matthias Reisner), it’s just that this is based on the classic interface > > of Grapefruit. > > Yep, I'd like to help with graphics support. Thanks a lot. > Currently I'm still learning about all these things (FRP, arrows, Grapefruit > particularly), but if there are things which does not require deep > understanding of these concepts (or even help to gain one), please tell me. I think, you need to understand what discrete and segmented signals are. Which is not very difficult, in my opinion. You only have to know what they mean not how they are implemented. So you don’t need a deep understanding of all kinds of FRP things in order to hack on Grapfruit graphics support. Did you have a look at my e-mail conversation with Jeff Heard (in the same haskell-cafe thread)? He thinks about adapting the Hieroglyph 2D graphics library to Grapefruit. There is also the graphics implementation of classic Grapefruit which is for 3D graphics and OpenGL-based. These may be things, you want to have a look at. > Also, I'm yet not sure about Utrecht, but if Grapefruit hacking is > planned, it's worth coming for me :) This sounds very good. It’s not yet sure whether I will go to Utrecht for supervising Grapefruit hacking but it’s very likely that I will. Best wishes, Wolfgang

1 0

StableFunPtr?
by Maurício 17 Feb '09

17 Feb '09

Hi, I've seen that if I'm going to leave a pointer to data in the hands of foreign code, I should use StablePtr so that the value it points to doesn't change. However, we also usually give FunPtr to foreign code, like when registering callbacks, but I can't found any kind of "StableFunPtr". Are all FunPtrs stable? Thanks, Maurício

4 3

Functional GUIs again
by Fraser Wilson 17 Feb '09

17 Feb '09

Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is ... not what I expect from a beautiful program, and because what I often need is a GUI that manipulates a state, and because I don't understand arrows, and having been intrigued by a recent cafe thread, I threw together a prototype GUI library with the following features: - the GUI is defined on three levels: gadgets, widgets and styles - gadgets are functions on a state - widgets are data structures which define the layout - styles are ways to modify the appearance of widgets The following quick example shows a text box and a button. Clicking on the button reverses the text in the text box. > module Main where > import Barrie > demoWidget :: Widget > demoWidget = vbox [ui "demo entry" textBox, > ui "demo command" (labelButton "click me")] > type DemoState = String > type DemoGadget = Gadget DemoState > demoGUI :: DemoGadget > demoGUI = localG "demo gui" [editorG "demo entry" id const, > commandG "demo command" reverse] > main = gtkMain demoGUI demoWidget "Hello, world" Two gadgets are used: editorG :: String -> (a -> b) -> (b -> a -> a) -> Gadget a commandG :: String -> (a -> a) -> Gadget a The editor gadget can show a value from a state, and update a state with a value. The command gadget can transform a state to a new state. gtkMain connects the gadgets to a widget, which specifies layout using the vbox, attaching the editor gadget to a text box, and the command gadget to a button. Well, that's all pretty trivial. The key thing for me was that I can easily slap a GUI onto the the front of a class of applications, which happen to be the sort of applications I've been writing lately. Also, arbitrary parts of the GUI can respond to things that happen miles away, without really having to worry about it too much. In barrie-0.1 and 0.2, which used stream-based approaches, the problem of getting state from one end of the application to the other was non-trivial. I'll sketch another quick example: > data BridgeGame = ... And a bunch of things you can do with the state: > makeBid :: Bid -> BridgeGame -> BridgeGame > playCard :: Card -> BridgeGame -> BridgeGame For bidding, each bid is represented by a gadget: > bidG :: Bid -> Gadget BridgeGame > bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid) 'enabled' switches the gadget on if its first argument returns true when applied to the current state. However, the decision about what to do with a disabled gadget is made by its corresponding widget. We get one button for each bid: > biddingG :: Gadget BridgeGame > biddingG = localG "bidding" (map bidG allBids) And they can be displayed in any old order using a widget: > biddingW :: Widget > biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids]) > where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7] > ntBids = hbox $ map (bidButton . NT) [1 .. 7] > bidButton bid = ui (show bid) $ labelButton (show bid) (You're right, double, redouble and pass are not represented. They make the lines too long). Screenshot here: http://thewhitelion.org/images/4D.png I've just bid four diamonds, so everything lower than that is automatically disabled. Currently, Barrie implements buttons, text boxes, labels, vertical/horizontal layout, single-column lists and drop lists. It current uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first renderer was putStrLn/getLine). You can have a look by using darcs: darcs get http://thewhitelion.org/darcs/barrie Or get the tarball at http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz One note: this is not intended to be a theoretically sound approach, merely a way of getting something done quickly. I would expect it to be most useful in putting a GUI front-end onto an existing application, in particular, an application that is driven by user actions which update a state; e.g. a calculator, a bridge game, a 4th edition D&D character creator (but that leads to a critical mass of nerdiness, so it's off the table for now) cheers, Fraser. -- http://thewhitelion.org/mysister

4 8

Does gtk2hs support VTE?
by Magicloud Magiclouds 17 Feb '09

17 Feb '09

Hi, I always see a file named vte something in "doc" folder, but I never see vte in reference or source. So I wonder if gtk2hs actually supports VTE. And I'd like to have that supporting.... -- 竹密岂妨流水过山高哪阻野云飞

2 1

ANN : Crypto 4.2.0 & Related News
by Creighton Hogg 17 Feb '09

17 Feb '09

Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage & that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Cheers, Creighton

3 3

Complex C99 type in Foreign
by Maurício 17 Feb '09

17 Feb '09

Hi, Are there plans to include C99 'complex' type in Foreign, maybe as CFloatComplex, CDoubleComplex and CLongDoubleComplex? This seems an easy addition to the standard and would allow binding of a few interesting libraries, like GSL. Best, Maurício

3 8

Low-level high-level languages?
by Maurício 17 Feb '09

17 Feb '09

Hi, I've checked this 'BitC' language (www.bitc-lang.org) It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Thanks, Maurício

7 6

Re: [Haskell-cafe] Functional GUIs again
by Fraser Wilson 17 Feb '09

17 Feb '09

Oh, cheers! Newtype deriving is more general than I expected. Thanks for the comment. I've requested a hackage account, so I expect it to be there shortly :-) cheers, Fraser. On Mon, Feb 16, 2009 at 9:12 PM, Ryan Ingram <ryani.spam(a)gmail.com> wrote: > Tiny code-review comment: > > > data Style = Style [(String, StyleValue)] > > deriving (Read, Show) > > > instance Monoid Style where > > mempty = Style [] > > mappend (Style xs) (Style ys) = Style (xs ++ ys) > > => > > > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > > > > newtype Style = Style [(String, StyleValue)] > > deriving (Read, Show, Monoid) > > Also, put it on hackage! :) It looks pretty cool. > > -- ryan > > 2009/2/16 Fraser Wilson <blancolioni(a)gmail.com>: > > Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is > > ... not what I expect from a beautiful program, and because what I often > > need is a GUI that manipulates a state, and because I don't understand > > arrows, and having been intrigued by a recent cafe thread, I threw > together > > a prototype GUI library with the following features: > > > > - the GUI is defined on three levels: gadgets, widgets and styles > > - gadgets are functions on a state > > - widgets are data structures which define the layout > > - styles are ways to modify the appearance of widgets > > > > The following quick example shows a text box and a button. Clicking on > the > > button reverses the text in the text box. > > > >> module Main where > > > >> import Barrie > > > >> demoWidget :: Widget > >> demoWidget = vbox [ui "demo entry" textBox, > >> ui "demo command" (labelButton "click me")] > > > >> type DemoState = String > > > >> type DemoGadget = Gadget DemoState > > > >> demoGUI :: DemoGadget > >> demoGUI = localG "demo gui" [editorG "demo entry" id const, > >> commandG "demo command" reverse] > > > >> main = gtkMain demoGUI demoWidget "Hello, world" > > > > Two gadgets are used: > > > > editorG :: String -> (a -> b) -> (b -> a -> a) -> Gadget a > > commandG :: String -> (a -> a) -> Gadget a > > > > The editor gadget can show a value from a state, and update a state with > a > > value. The command gadget can transform a state to a new state. gtkMain > > connects the gadgets to a widget, which specifies layout using the vbox, > > attaching the editor gadget to a text box, and the command gadget to a > > button. > > > > Well, that's all pretty trivial. The key thing for me was that I can > easily > > slap a GUI onto the the front of a class of applications, which happen to > be > > the sort of applications I've been writing lately. Also, arbitrary parts > of > > the GUI can respond to things that happen miles away, without really > having > > to worry about it too much. In barrie-0.1 and 0.2, which used > stream-based > > approaches, the problem of getting state from one end of the application > to > > the other was non-trivial. > > > > I'll sketch another quick example: > > > >> data BridgeGame = ... > > > > And a bunch of things you can do with the state: > > > >> makeBid :: Bid -> BridgeGame -> BridgeGame > >> playCard :: Card -> BridgeGame -> BridgeGame > > > > For bidding, each bid is represented by a gadget: > > > >> bidG :: Bid -> Gadget BridgeGame > >> bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid) > > > > 'enabled' switches the gadget on if its first argument returns true when > > applied to the current state. However, the decision about what to do > with a > > disabled gadget is made by its corresponding widget. > > > > We get one button for each bid: > > > >> biddingG :: Gadget BridgeGame > >> biddingG = localG "bidding" (map bidG allBids) > > > > And they can be displayed in any old order using a widget: > > > >> biddingW :: Widget > >> biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids]) > >> where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7] > >> ntBids = hbox $ map (bidButton . NT) [1 .. 7] > >> bidButton bid = ui (show bid) $ labelButton (show bid) > > > > (You're right, double, redouble and pass are not represented. They make > the > > lines too long). > > > > Screenshot here: http://thewhitelion.org/images/4D.png > > > > I've just bid four diamonds, so everything lower than that is > automatically > > disabled. > > > > Currently, Barrie implements buttons, text boxes, labels, > > vertical/horizontal layout, single-column lists and drop lists. It > current > > uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first > > renderer was putStrLn/getLine). > > > > You can have a look by using darcs: > > darcs get http://thewhitelion.org/darcs/barrie > > > > Or get the tarball at > > http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz > > > > One note: this is not intended to be a theoretically sound approach, > merely > > a way of getting something done quickly. I would expect it to be most > > useful in putting a GUI front-end onto an existing application, in > > particular, an application that is driven by user actions which update a > > state; e.g. a calculator, a bridge game, a 4th edition D&D character > creator > > (but that leads to a critical mass of nerdiness, so it's off the table > for > > now) > > > > cheers, > > Fraser. > > > > -- > > http://thewhitelion.org/mysister > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- http://thewhitelion.org/mysister

1 0

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Feb '09

17 Feb '09

Am Montag, 16. Februar 2009 19:27 schrieben Sie: > Ah. Copy, don't darcs get. If you copy a repository which was itself fetched from somewhere using this lazy patch fetching feature, you’ll probably experience problems too. If it’s the repository you work in and you never fetched any patches into it, you might be successful. This is how I understand it. We see that this lazy patch fetching thing is dangerous. ;-) > If you want to take a look, I'd love to hear your thought. > demos/BarrieCalc has some commentary, and the other applications in demos > are all very simple. I just executed the demos. At the moment, I have no time to look at the code but I think I will have a look in the future. Best wishes, Wolfgang

1 0

Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
by Fraser Wilson 17 Feb '09

17 Feb '09

(Wolfgang is probably wondering why I sent him an email about how great Utrecht is) Oh, yeah, that's coming up, isn't it? Utrecht finally gets the glory she deserves (for those who aren't aware, Utrecht has the most beautiful canals in the Netherlands, which is saying something, and is largely undiscovered by English bachelor parties, which is why it's such a great place to live). I think your footnote with what I assume is a link got lost, so here it is: http://haskell.org/haskellwiki/Hac5 I'd love to hack on Grapefruit. I'll do some study (and take a break from my own world-changing functional GUI :-) cheers, Fraser. On Mon, Feb 16, 2009 at 5:56 PM, Wolfgang Jeltsch < g9ks157k(a)acme.softbase.org> wrote: > Am Montag, 16. Februar 2009 17:46 schrieb Wolfgang Jeltsch: > > Am Montag, 16. Februar 2009 16:27 schrieb Gour: > > > Do you anticipate that Grapefruit will be capable for writing > real-world > > > GUI apps quit soon? > > > > I have no concrete anticipation. It depends very much on the community. > If > > there is notable interest and this interest makes people hacking on > > Grapefruit then it might not take so long until you can write real-world > > apps in Grapefruit. > > By the way, are there people out there who would like to hack on Grapefruit > during the Utrecht Hackathon [1]? > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://thewhitelion.org/mysister -- http://thewhitelion.org/mysister

2 3

Arch Haskell News: Feb 16 2009
by Don Stewart 17 Feb '09

17 Feb '09

Arch now has 926 Haskell packages in AUR. That’s an increase of 27 new packages in the last 8 days, or 3.38 new Haskell apps a day. This weekly news includes: * Noteworthy updates: grapefruit, haskelldb, gtk2hs * A video on how to use Arch packages * Updated releases by category Read it all: http://archhaskell.wordpress.com/2009/02/16/arch-haskell-news-feb-16-2009/ Enjoy! -- Don

1 0

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Feb '09

17 Feb '09

[redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: > Great, does it run well on Windows and Mac platforms in addition to Linux > platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) > I am planning to create video phone software and I was looking for > good GUI toolkit that supports FRP so it looks like it is right time to > use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. > Thanks > > Jamie Best wishes, Wolfgang

5 12

hslogger bugs or features?
by Marc Weber 17 Feb '09

17 Feb '09

Following the advice on the hslogger wiki (http://software.complete.org/software/wiki/hslogger) I'm posting my thoughts about hslogger here: What is wired? This piece of code (src/System/Log/Logger.hs): parentHandlers name = let pname = (head . drop 1 . reverse . componentsOfName) name in do [...] next <- parentHandlers pname return ((handlers parent) ++ next) Why? Because when logging to "A.B.C" it splits the String once to get ["A","B","C"], then it drops the last part and runs the same again for "A.B" and so on.. So A string is split > 3 times for one logging action. I think this is a waste of cpu cycles.. I'm going to improve this. While reading the code i noticed two issues: ====================================================================== issue 1 That's not the most awkward thing: When logging to "A.B.C" hslogger does add 3 loggers to the global logger Map: "A" "A.B" "A.B.C" all three inheriting the default priority level of the default rootLogger "" A test application illustrating this (feature ?) module Main where -- packages: hslogger import System.Log.Logger as HL import System.Log.Handler.Simple as HL main = do -- the default logger logs to stderr level WARNING -- that's why the following message should be shown -- a) logM "A.B.C" HL.ALERT "ALERT test, should be shown and should create the sublogger" -- b) updateGlobalLogger rootLoggerName (setLevel EMERGENCY) logM "A.B.C" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" which prints: tmp %./test1 /tmp nixos ALERT test, should be shown and should create the sublogger ALERT test, should not be shown cause we have changed to EMERGENCY which is quite confusing because I haven't told hslogger explicitely to use a log level printing ALERTs on "A.B.C". so I'd expect that only the first message is shown. This behaviour is explained by the inheritance of the loglevel when hslogger creates them (without attaching handlers) automatically. I don't want the logging behaviour depend on wether a log line has been emitted before or not. Do you agree? Have I missed something? solution: replacing data Logger = Logger { level :: Priority, handlers :: [HandlerT], name :: String} type LogTree = Map.Map String Logger by a real log tree: data LogTree = LogTree { level :: Priority, -- level only applies to handlers, not to subLoggers handlers :: [HandlerT], subLoggers :: Map.Map String LogTree } ====================================================================== issue 2 The second ineresting point is (bug or feature?) that you can make the root logger shut up by setting different log levels to sub loggers: this sample does illustrate it: module Main where -- packages: hslogger import System.Log.Logger as HL import System.Log.Handler.Simple as HL main = do updateGlobalLogger "" (setLevel DEBUG) updateGlobalLogger "A" (setLevel EMERGENCY) logM "A" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" It doesn't print anything although the default log handler on root (="") is set to loglever DEBUG. So there is no way to get all logmessages without removing all all setLevel calls to subloggers? Is this desirable? ====================================================================== my conclusion: About issue 1 I think its a bug About issue 2 I don't know. I think there should be a way to get all log messages. So I feel this is a bug as well. I neither have checkeg the logcxx nor log4j nor the reference implementation in python. Thoughts? Sincerly Marc Weber

3 12

HaskellDB is alive?
by Felipe Lessa 17 Feb '09

17 Feb '09

Hello! There was a new HaskellDB release, but I didn't see any announcement here. Is it back alive? What happened to 0.11? Thanks =) -- Felipe.

4 3

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 16 Feb '09

16 Feb '09

[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: > One more thing, would Grapefruit work with files created by Glade (UI > builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. Best wishes, Wolfgang

2 1

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Jamie 16 Feb '09

16 Feb '09

On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: > [redirecting to haskell-cafe] > > Am Samstag, 14. Februar 2009 23:13 schrieben Sie: >> Great, does it run well on Windows and Mac platforms in addition to Linux >> platform which should run fine? > > Actually, I have no idea. ;-) > > Well, Grapefruit is a pure Haskell library without any own binding to C > libraries or whatever. For GUI stuff, Grapefruit relies completely on > Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t > tested it so far. Earlier Grapefruit code was successfully executed on > the Windows box of my co-developer. > > On the other hand, Grapefruit is designed to be implemented on top of > different toolkits, although currently there is only the Gtk2Hs backend. > So if you want to write a backend based on the Win32 API or Cocoa, this > would be very welcome. :-) Great. Well thought out design :) Other possible backends would be FLTK, GLUI, XBMC/Boxee (for set-top box apps) as well Qt and wxWidgets. I guess backends using Win32 API/Cocoa and FLTK would be the least bloated ones. >> I am planning to create video phone software and I was looking for good >> GUI toolkit that supports FRP so it looks like it is right time to use >> Grapefruit :) > > This would be really great. Writing applications with Grapefruit gives > me useful feedback and pressure for improvement. Note that currently the > set of supported widgets is very low but this is likely to change during > the next weeks and it should often be very easy to port Gtk2Hs widgets > to Grapefruit. Awesome! I'll be looking forward start using Grapefruit soon! :) >> Thanks >> >> Jamie > > Best wishes, > Wolfgang Jamie Clark

1 0

createProcess shutting file handles
by Neil Mitchell 16 Feb '09

16 Feb '09

Hi, I want to run multiple programs and dump the stdout/stderr to a file, I've tried doing: h <- openFile file WriteMode let c = CreateProcess (RawCommand file []) Nothing Nothing Inherit (UseHandle h) (UseHandle h) False (_,_,_,pid) <- createProcess c waitForProcess pid hPutStrLn h "Test" But by the time I get to the hPutStrLn line it says: Main: test.log: hPutStr: illegal operation (handle is closed) What have I done wrong? Did createProcess close the handle, and is there a way round this? This is using GHC 6.10 on Windows with the new process-1.0.1.1 Thanks Neil

4 8

Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 16 Feb '09

16 Feb '09

Am Sonntag, 15. Februar 2009 16:27 schrieben Sie: > Hi Wolfgang, > > Thank you for the excellent introduction Oh, I thought that you didn’t send you original question to the list and therefore answered you only privately. So the others don’t know yet the introduction you refer to (but see below). > (this would be good material to put on your Wiki). Done. :-) <http://haskell.org/haskellwiki/Grapefruit/Comparison_to_other_FRP_libraries> Conal, are you listening? If yes, could you please look over this page to make sure that I described your work correctly? Best wishes, Wolfgang

1 0

Ann: Yogurt-0.3
by Martijn van Steenbergen 16 Feb '09

16 Feb '09

Dear Haskellers, I'm pleased to announce the release of Yogurt-0.3! This version improves over 0.2 in several ways: * It compiles and runs with GHC 6.10. * The Mud monad is now built on top of IO. * Vars are expressed as IORefs. No more unsafeCoerce needed. * Forking of threads is supported, with callback into the Mud monad: > type RunMud = forall a. Mud a -> IO a > forkWithCallback :: (RunMud -> IO ()) -> Mud ThreadId * Timers are no longer a primitive: they can be expressed as function of forkWithCallback. * Refactorings in the architecture: the features are a strict superset of the previous version while the number of lines of code has decreased by 10%. All feedback is appreciated! Thanks to Saizan on #haskell for helping me work around the predicative types. :-) The code is available at Google: http://code.google.com/p/yogurt-mud/ Kind regards, Martijn.

1 0

Amazing
by Peter Verswyvelen 16 Feb '09

16 Feb '09

One of the things I liked a lot when working with C# was that as soon as my code compiled, it usually worked after an iteration of two.At least if we forget about the nasty imperative debugging that is needed after a while because of unanticipated and unchecked runtime side effects. After heaving read about Haskell and having written some small programs for the last year or so, I'm now finally writing a bigger program with it. It is not so easy yet since learning a language and trying to reach a deadline at the same time is hard :) However, it is just amazing that whenever my Haskell program compiles (which to be fair can take a while for an average Haskeller like me ;-), it just... works! I have heard rumors that this was the case, but I can really confirm it. A bit hurray for strong typing! (and if you don't like it, you can still use Dynamic and Typeable ;-)

13 14

Re: permuting a list
by Jon Fairbairn 16 Feb '09

16 Feb '09

Heinrich Apfelmus <apfelmus(a)quantentunnel.de> writes: > The answer is a resounding "yes" and the main idea is that shuffling a > list is *essentially the same* as sorting a list; the minor difference > being that the former chooses a permutation at random while the latter > chooses a very particular permutation, namely the one that sorts the input. > > For the full exposition, see > > http://apfelmus.nfshost.com/random-permutations.html I haven't been following the thread, but my initial reaction would have been something like use System.Random.randoms to get a list rs and then do (roughly) randomPerm = map snd . sortBy (compare `on` fst) . zip rs How bad is that? I mean, how unfair does it get? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31)

5 6

ANNOUNCE: hslibsvm-2.88.0.1 - A FFI binding to LibSVM
by S. Günther 16 Feb '09

16 Feb '09

The result of the fact that I needed to use a support vector machine and didn't want to leave haskell land. LibSVM is a support vector machine library written in C++ with an exposed C interface. More information about LibSVM can be found at: http://www.csie.ntu.edu.tw/~cjlin/libsvm/ This is my first haskell package so any suggestions for improvement are welcome. kind regards Stephan Günther ----------------------------------------------------------------------------

2 1

Re: [Haskell-beginners] Re: [Haskell-cafe] Re: permuting a list
by Alberto Ruiz 16 Feb '09

16 Feb '09

Heinrich Apfelmus wrote: > Alberto Ruiz wrote: >> How about using random doubles? >> >> randomPerm xs = fmap (map snd . sort . flip zip xs) rs >> where rs = fmap (randoms . mkStdGen) randomIO :: IO [Double] > > Interesting idea. The chance of duplicates should be negligible now, but > that's because we're using a large amount of random bits, far more than > n! would require. Another possibility is using infinite lists of random bits as keys. Then we only extract from the random number generator the number of bits required to avoid duplicates. -Alberto

1 0