February 2012 - Haskell-Cafe

How far away is a release of cabal-install that works with ghc 7.4?
by Magnus Therning 25 Feb '12

25 Feb '12

It looks like HEAD on the dev branch of cabal (cabal/cabal-install) compiles fine with 7.4.1, so any thoughts on when we see an update posted on Hackage? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

1 0

Monadic Design Patterns for the Web Chapter Review
by Greg Meredith 25 Feb '12

25 Feb '12

*Dear Supporters, Friends and Colleagues, i’m writing to you to say that i will be going over the material in Chapters 3 through 9 of the book, MDP4tW in a Google+ hangout, 1 Chapter / week. If any would like to participate in reviewing the material presented, please let me know. i will limit participation in these reviews to 5 people / session with preference give to people who contributed to the Kickstarter campaign. Please RSVP to me at lgreg.meredith(a)gmail.com and i will let you know the dates and times.* Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

Call for Journal Papers: STVR Special Issue on Tests and Proofs
by Achim D. Brucker 25 Feb '12

25 Feb '12

Apologies for duplicates. CALL FOR PAPERS STVR Special Issue on Tests and Proofs http://lifc.univ-fcomte.fr/tap2012/stvr/ The Software Testing, Verification & Reliability (STVR) journal (http://www3.interscience.wiley.com/journal/13635/home) invites authors to submit papers to a Special Issue on Tests and Proofs. Background ========== The increasing use of software and the growing system complexity make focused software testing a challenging task. Recent years have seen an increasing industrial and academic interest in the use of static and dynamic analysis techniques together. Success has been reported combining different test techniques such as model-based testing, structural testing, or concolic testing with static techniques such as program slicing, dependencies analysis, model-checking, abstract interpretation, predicate abstraction, or verification. This special issue serves as a platform for researchers and practitioners to present theory, results, experience and advances in Tests and Proofs (TAP). Topics ====== This special issue focuses on all topics relevant to TAP. In particular, the topics of interest include, but are not limited to: * Program proving with the aid of testing techniques * New challenges in automated reasoning emerging from specificities of test generation * Verification and testing techniques combining proofs and tests * Generation of test data, oracles, or preambles by deductive techniques such as: theorem proving, model checking, symbolic execution, constraint logic programming, SAT and SMT solving * Model-based testing and verification * Automatic bug finding * Debugging of programs combining static and dynamic analysis * Transfer of concepts from testing to proving (e.g., coverage criteria) and from proving to testing * Formal frameworks for test and proof * Tool descriptions, experience reports and evaluation of test and proof * Case studies combining tests and proofs * Applying combination of test and proof techniques to new application domains such as validating security procotols or vulnerability detection of programs * The processes, techniques, and tools that support test and proof Submission Information ====================== The deadline for submissions is 17th December, 2012. Notification of decisions will be given by April 15th, 2013. All submissions must contain original unpublished work not being considered for publication elsewhere. Original extensions to conference papers - identifing clearly additional contributions - are also encouraged unless prohibited by copyright. Submissions will be refereed according to standard procedures for Software Testing, Verification and Reliability. Please submit your paper electronically using the Software Testing, Verification & Reliability manuscript submission site. Select "Special Issue Paper" and enter "Tests and Proofs" as title. Important Dates: ================ * Paper submission: December 17, 2012 * Notification: April 15, 2013 Guest Editors ============= * Achim D. Brucker, SAP Research, Germany http://www.brucker.ch/ * Wolfgang Grieskamp, Google, U.S.A. http://www.linkedin.com/in/wgrieskamp * Jacques Julliand, University of Franche-Comté, France http://lifc.univ-fcomte.fr/page_personnelle/accueil/8 -- Dr. Achim D. Brucker, SAP Research, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch

1 0

ANN: generic-deepseq 1.0.0.0
by Maxime Henrion 25 Feb '12

25 Feb '12

Hello all, Yesterday I uploaded a new package on Hackage called generic-deepseq. It implements the 'deepseq' function generically using the new GHC.Generics framework as found in GHC >= 7.2. It can be used as a replacement for the deepseq package. Given that hackage is currently down, here is an URL from a mirror where the package description & documentation can be found: http://hackage.factisresearch.com/package/generic-deepseq-1.0.0.0 Any suggestions are welcome. Cheers, Maxime Henrion

7 25

SURVEY: hledger, shelltestrunner, rss2irc, FunGEn usage 2012
by Simon Michael 24 Feb '12

24 Feb '12

Hey all, I'm gathering usage data on my main FOSS projects, to help me prioritize and steer them. I've prepared a short survey, 10 optional questions that should take 1-5 minutes per project. If you use any of these projects and/or would like them to continue, you can help a lot by adding your experience to: hledger: https://docs.google.com/spreadsheet/viewform?formkey=dHVGUHBXRUhRNWF3Y2RsZG… shelltestrunner: https://docs.google.com/spreadsheet/viewform?formkey=dGpZSzdhWHlCUkJpR2hjX1… rss2irc (& hackagebot): https://docs.google.com/spreadsheet/viewform?formkey=dFhhLWZrZ3l4elFYa3M1Zm… FunGEn: https://docs.google.com/spreadsheet/viewform?formkey=dFN5dllFTGFFU3ZhclcxWT… Don't hold back! Honest critique welcome. You'll see a summary report after submitting your answers, and before long I'll follow up with the urls for full results. Note that contact info will be public, except that I'll keep email addresses private. It's optional but at least a little is quite useful in several ways. I made the survey generic, so feel free to re-use it. Best, -Simon

1 1

Re: [Haskell-cafe] Streaming to JuicyPixels
by Vincent Berthoux 24 Feb '12

24 Feb '12

Hi, Please go ahead, and github is the perfect medium for code sharing :) Regards Vincent Berthoux Le 22 février 2012 20:20, Myles C. Maxfield <myles.maxfield(a)gmail.com> a écrit : Let's put aside the issue of getting access to the pixels before the stream > is complete. > > How would you feel if I implemented use of the STT monad transformer on > top of Get in JuicyPixels, in order to get rid of the (remaining >> > getBytes) call, and then expose the underlying Get interface to callers? > This would allow use for streaming. > > Is this something that you feel that I should pursue? I can send you a > GitHub Pull Request when I'm done. > > Thanks, > Myles > > On Wed, Feb 22, 2012 at 5:01 AM, Vincent Berthoux < > vincent.berthoux(a)gmail.com> wrote: > >> Hi, >> >> I can understand your performance problems, I bumped into them before >> the first release of Juicy Pixels and took a long time to get 'correct' >> performance out of the box, and the IDCT is not the only 'hot point', I got >> problems with intermediate data structure as well. Any list has proven a >> bit problematic performance wise, so I rewrote some things which would have >> been easily implemented with forM_ or mapM_ with manual recursion. >> >> I didn't knew STT existed, so it open a new area of reflection for the >> streaming Jpeg decoder, instead of using the (remaining >> getBytes) combo, >> staying in the Get monad might help. The reason to expose the ST monad is >> that I use it internally to mutate the final image directly, and I'd prefer >> to avoid freezing/unfreezing the underlying array. So in order to give >> access to the intermediate representation, a type could be (STT s (StateT >> JpegDecodingState Get) (MutableImage s PixelYCbCr8)) (the Jpeg decoder only >> produce (Image PixelYCbCr8 internally)). This should allow a freeze then a >> color conversion. >> >> As it would induce performance loss, this version should exist >> alongside current implementation. This is not trivial, but it's far from >> impossible. For the IDCT implementation, I don't think a package make much >> sense, if you want to use it, just grab it and customize the interface to >> your needs :). >> >> Regards >> >> Vincent Berthoux >> >> Le 21 février 2012 06:16, Myles C. Maxfield <myles.maxfield(a)gmail.com> a >> écrit : >> >> Hello, and thanks for the quick reply. >>> >>> You're right that using (remaining >> getBytes) won't work for >>> streaming, as it would pull the rest of the stream into a buffer, thereby >>> delaying further processing until the image is completely downloaded. :-( >>> >>> I'm a little unclear about what you mean about the use of the ST monad. >>> There is an STT<http://hackage.haskell.org/packages/archive/STMonadTrans/0.2/doc/html/Contr…> monad >>> transformer, so you could wrap that around Get. Is that what you're >>> referring to? >>> >>> As an aside: I didn't realize that JuicyPixels existed, so I wrote a >>> JPEG decoder specifically designed for streaming - it doesn't request a >>> byte of input unless it has to, uses a StateT (wrapped around Attoparsec) >>> to keep track of which bit in the current byte is "next", and does the >>> Huffman decoding in-line. However, I didn't use ST for the IDCT, so my own >>> decoder has serious performance problems. This prompted me to start >>> searching around for a solution, and I came across JuicyPixels, which >>> already exists and is much faster than my own implementation. I'm hoping to >>> get rid of my own decoder and just use JuicyPixels. If you're curious, my >>> own code is here: https://github.com/litherum/jpeg. >>> >>> Is it reasonable to extend JuicyPixels to fit my use case? It sounds >>> like JuicyPixels wouldn't work so well as it stands. I'd be happy to do >>> whatever work is necessary to help out and get JuicyPixels usable for me. >>> However, if that would require a full (or near-full) rewrite, it might make >>> more sense for me to use my own implementation with your IDCT. Is there a >>> way we can share just the IDCT between our two repositories? Perhaps making >>> a new IDCT8 library that we can both depend on? >>> >>> As for what API I'd like to be able to use, just a "Get DynamicImage" >>> should suffice (assuming it has streaming semantics as described above). It >>> would be really nice if it was possible to get at the incomplete image >>> before the stream is completed (so the image could slowly update as more >>> data arrives from the network), but I'm not quite sure how to elegantly >>> express that. Do you have any ideas? >>> >>> I think that having 2 native jpeg decoders (Actually 3, because of this >>> package <http://hackage.haskell.org/package/jpeg>) is detrimental to >>> the Haskell community, and I would really like to use JuicyPixels :D >>> >>> Thanks, >>> Myles C. Maxfield >>> >>> >>> On Mon, Feb 20, 2012 at 3:01 PM, Vincent Berthoux < >>> vincent.berthoux(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I can expose the low level parsing, but you would only get the >>>> chunks/frames/sections of the image, Cereal is mainly used to parse the >>>> structure of the image, not to do the raw processing. For the raw >>>> processing, I rely on `remaining >> getBytes` to be able to manipulate data >>>> at bit level or to feed it to zlib, and the documentation clearly state >>>> that remaining doesn't work well with runGetPartial, so no read ahead, but >>>> even worse for streaming :). >>>> >>>> To be fair, I never thought of this use case, and exposing a partially >>>> decoded image would impose the use of the ST Monad somehow, and Serialize >>>> is not a monad transformer, making it a bit hard to implement. >>>> >>>> By curiosity what kind of API would you hope for this kind of >>>> functionality? >>>> >>>> Regards >>>> >>>> Vincent Berthoux >>>> >>>> Le 20 février 2012 22:08, Myles C. Maxfield <myles.maxfield(a)gmail.com>a écrit : >>>> >>>> Hello, >>>>> I am interested in the possibility of using JuicyPixels for streaming >>>>> images from the web. It doesn't appear to expose any of its internally-used >>>>> Serialize.Get functionality, which is problematic for streaming - I would >>>>> not like to have to stream the whole image into a buffer before the decoder >>>>> can start decoding. Are there any plans on exposing this API, so I can use >>>>> the runGetPartial function to facilitate streaming? >>>>> >>>>> In addition, does the library do much readahead? There's no point in >>>>> exposing a Get interface if it's just going to wait until the stream is >>>>> done to start decoding anyway. >>>>> >>>>> Thanks, >>>>> Myles C. Maxfield >>>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

2 1

Hackage documentation down?
by wren ng thornton 23 Feb '12

23 Feb '12

Hello all, I posted a minor update to unix-bytestring a few days ago in order to deal with the Num not implying Eq thing in GHC 7.4, but it looks like the documentation still hasn't been made (nor the built-on field). Are the Hackage builders down intentionally since the recent crash, or accidentally? -- Live well, ~wren

1 0

Re: [Haskell-cafe] network-2.3.0.10 compiled for ghc 7.4.1 windows
by Holger Reinhardt 23 Feb '12

23 Feb '12

I just use the version of MSys that is included with Git [1]. This puts a "Git bash" icon on your desktop which you can then use to build the network library. [1] http://code.google.com/p/msysgit/ 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> > Nothing bur a long history of failures. The problem is the > configuration and versioning of MinGW and MSys. This is a nighmare. > > 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: > > Oh you are using Cygwin. I'm using MSys so this is why I cannot reproduce > > your problem. Is there anything preventing you from using MSys? > > > > > > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> > >> > >> The "problem" this time is in "Configure" : > >> > >> case "$host" in > >> *-mingw32) > >> EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c, > >> cbits/asyncAccept.c" > >> EXTRA_LIBS=ws2_32 > >> CALLCONV=stdcall ;; > >> *-solaris2*) > >> EXTRA_SRCS="cbits/ancilData.c" > >> EXTRA_LIBS="nsl, socket" > >> CALLCONV=ccall ;; > >> *) > >> EXTRA_SRCS="cbits/ancilData.c" > >> EXTRA_LIBS= > >> CALLCONV=ccall ;; > >> esac > >> > >> > >> > >> Since I´m cross-compiling with cygwin, the variable Host does not > >> contain ¨*-muingw32" but "i686-pc-cygwin" > >> > >> changing the case , the library incorporates the lost C coded files. > >> > >> Now the library links fine win imported, but there is a runtime error: > >> > >> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in case > >> > >> maybe it is due to some other preprocessor directive mismatch > >> > >> > >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: > >> > Did you also change the files in the /cbits/ folder? Because they also > >> > check > >> > for HAVE_WINSOCK_H. > >> > > >> > > >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> > >> >> > >> >> The code is evolving and none of the versions match exactily with the > >> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these files > >> >> solves the compilation problem at least in the network 2.3.0.10 > >> >> version from hackage. > >> >> > >> >> However it produces the same undefined references when this library > is > >> >> imported in my application. It seems that some object code is not > >> >> included in the final library. I verified that at least some of > these > >> >> undefined references correspond with C code in the source, but > >> >> somehow this is not included in the object library.... > >> >> > >> >> 2012/2/7 Johan Tibell <johan.tibell(a)gmail.com>: > >> >> > Note that there are two branches on github, master and stable. You > >> >> > want > >> >> > the > >> >> > latter. > >> >> > > >> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" <agocorona(a)gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> This is quite different. > >> >> >> I don´t know how but I was looking at some other older patch > around > >> >> >> the same issue and I supposed that it was the one refered by Yohan > >> >> >> Tibell. > >> >> >> > >> >> >> I´ll try your patch. > >> >> >> > >> >> >> Thanks!. > >> >> >> > >> >> >> 2012/2/7 Holger Reinhardt <hreinhardt(a)gmail.com>: > >> >> >> > Hi, > >> >> >> > > >> >> >> > (I submitted the patch that Johan linked to) > >> >> >> > Network/Socket/Internal.hsc has the following code: > >> >> >> > > >> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS) > >> >> >> > type CSaFamily = (#type unsigned short) > >> >> >> > #elif defined(darwin_HOST_OS) > >> >> >> > type CSaFamily = (#type u_char) > >> >> >> > #else > >> >> >> > type CSaFamily = (#type sa_family_t) > >> >> >> > #endif > >> >> >> > > >> >> >> > You have patched this part to always use 'unsigned short'. But > the > >> >> >> > real > >> >> >> > issue is that WITH_WINSOCK is not defined, even though it should > >> >> >> > be. The > >> >> >> > reason for this lies in include/HsNet.h: > >> >> >> > > >> >> >> > #if defined(HAVE_WINSOCK_H) && !defined(cygwin32_HOST_OS) > >> >> >> > # define WITH_WINSOCK 1 > >> >> >> > #endif > >> >> >> > > >> >> >> > The problem here is that it checks for HAVE_WINSOCK_H, but the > >> >> >> > configure > >> >> >> > script never defines this variable. Instead it > >> >> >> > defines HAVE_WINSOCK2_H. > >> >> >> > It > >> >> >> > seems that the network library used Winsock1 in the past and in > >> >> >> > the > >> >> >> > transition to Winsock2 someone forgot to change a few of the > >> >> >> > #ifdefs. > >> >> >> > > >> >> >> > My patch just changes all occurences of HAVE_WINSOCK_H > >> >> >> > to HAVE_WINSOCK2_H. > >> >> >> > You might want to try that and report back if it works for you. > >> >> >> > > >> >> >> > 2012/2/7 Alberto G. Corona <agocorona(a)gmail.com> > >> >> >> >> > >> >> >> >> Hi Johan, > >> >> >> >> The patch is not for the current version of network and the > code > >> >> >> >> is > >> >> >> >> quite different. Basically it is necesary to define this > >> >> >> >> variable > >> >> >> >> as > >> >> >> >> "unsigned short" that is the thing intended in the patch. > however > >> >> >> >> I > >> >> >> >> put it by brute force, without regard of the prerpocessor > >> >> >> >> directives. > >> >> >> >> With this change the code compiles well with: > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library… > >> >> >> >> > >> >> >> >> However my compiled library lack the methods defined as > foreign. > >> >> >> >> I´ll > >> >> >> >> keep trying. > >> >> >> >> > >> >> >> >> 2012/2/6 Johan Tibell <johan.tibell(a)gmail.com>: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > Someone recently contributed a fix that should make network > >> >> >> >> > build > >> >> >> >> > with > >> >> >> >> > 7.4: https://github.com/haskell/network/pull/25 > >> >> >> >> > > >> >> >> >> > Can you see if that works for you? I haven't yet had time to > >> >> >> >> > merge > >> >> >> >> > and > >> >> >> >> > release that fix (I'm on vacation.) > >> >> >> >> > > >> >> >> >> > -- Johan > >> >> >> >> > > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Haskell-Cafe mailing list > >> >> >> >> Haskell-Cafe(a)haskell.org > >> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> >> >> > > >> >> >> > > >> > > >> > > > > > >

6 15

Haskell compilers targeting VMs
by Carlton Mills 23 Feb '12

23 Feb '12

LLVM has a .net and JVM code generator. I don't think it is production ready yet. GHC can generate code via LLVM. So in theory one could run on either VM. However, see the "Why isn't GHC available ..." link below. The GC and library integration would require lot's of work. Good senior project for someone who wishes to spend 3 years as a senior. -Carlton Daniel Peebles pumpkingod at gmail.com A more subtle issue is that there's some sort of memory leak that arises when you can't instruct the GC to follow projection functions of datatypes. I believe the GHC heap representation has a built-in notion of theseforwarding closures and the GC follows them when possible, but most VM GCsare just black boxes. It might still be possible to create an artificialfield in a representation of your closure that the GC can follow, but itcould be tricky.On Thu, Feb 23, 2012 at 11:59 AM, Tom Murphy <amindfv at gmail.com> wrote: >There are some substantial technical challenges: >>http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.N… >>Not that it can't be done, but there's nothing ready yet. >>Tom (IRC: amindfv) >>> >> Does any one knows of an Haskell compiler targeting the JVM ? And of one >> targeting the .Net virtual machine ? >> >> Regards, >> ARJANEN Loïc

1 0

ANN: network-socket-options 0.1
by Joey Adams 23 Feb '12

23 Feb '12

I added a new package containing wrappers for getsockopt and setsockopt: http://hackage.haskell.org/package/network-socket-options The network package already has getSocketOption and setSocketOption. The problem is, these don't work for socket options that aren't represented by integers, such as SO_LINGER: http://trac.haskell.org/network/ticket/23 Another, less serious problem is that getSocketOption and setSocketOption don't leverage the type system as well as they could. Many options are boolean values; it'd be better to get and set them with 'Bool's instead of 'Int's. network-socket-options implements options using getter and setter functions, e.g.: getLinger :: HasSocket sock => sock -> IO (Maybe Seconds) setLinger :: HasSocket sock => sock -> Maybe Seconds -> IO () type Seconds = Int The HasSocket type class is defined to overload the getters and setters to work on raw file descriptors, not just Socket objects. This functionality should probably go in the network package itself. However, I decided to release it as a separate package so I could start using it sooner. If people like it enough, perhaps the network package can absorb it, as was done with network-bytestring. -Joey Adams

3 8