- Haskell-Cafe - Haskell.org

[ANNOUNCE] hierarchical-clustering-diagrams 0.1: diagrams of dendrograms
by Felipe Almeida Lessa 02 Nov '11

02 Nov '11

Hello! I'm pleased to announce the very first version of hierarchical-clustering-diagrams [1]. This library builds upon Brent Yorgey's great diagrams library to draw diagrams of dendrograms. You can see an example diagram at [2]. This library has already been tested with a Real World Big Data dendrogram and has a pretty nice performance. It generates a 20,000 x 5,000 px PNG in less than 15s on a 2 years-old Core 2 laptop. Note that while this library depends on the hierarchical-clustering library [3], nothing stops you from using any other method of creating your dendrogram. You only need to convert your dendrogram to the data type provided by hierarchical-clustering, which should be straightforward. However, I'd love to hear if someone finds both libraries useful =). Cheers, =D [1] http://hackage.haskell.org/package/hierarchical-clustering-diagrams [2] https://patch-tag.com/r/felipe/hierarchical-clustering-diagrams/snapshot/cu… [3] http://hackage.haskell.org/package/hierarchical-clustering-diagrams -- Felipe.

1 0

Tell cabal-install to generate only shared libraries
by Yves Parès 02 Nov '11

02 Nov '11

Hello, When I tell cabal-install to build shared libraries (with "Shared: True" in .cabal/config), it doubles the libraries installation time since it compiles them twice, since it seems that is what GHC's flag "-shared" does. Is there a way to generate only the .so and not the the .a libs? Furthermore, I have the impression that the executables compiled by cabal-install are always linked statically... Can I tell cabal-install to activate the GHC's flag "-dynamic" for executables? Thanks.

1 0

Haskell hackers send an idea to the "off the beaten track" workshop at POPL
by David Walker 02 Nov '11

02 Nov '11

Haskell is an amazing language for implementing Domain-Specific Languages. If you have an idea about a new domain-specific language you'd like to implement, a new problem that needs to be solved or any other new and unusual idea concerning programming language research, submit it to OBT: "Off the Beaten Track: Under-represented Problems for Programming Language Researchers." This is a new, informal, lively workshop associated with POPL in Philadelphia, Saturday January 28. It is easy to submit something, just write up a 1-page or 2-page PDF on your idea and submit it here: http://www.cs.princeton.edu/~dpw/obt/ We are eager to have lots of 5-minute talks as well as longer talks interleaved with discussion. Don't be shy: submit your off-the-beaten-track problems and ideas. The deadline is Nov 14. See the web site or below for more info Thanks, David Walker Program Chair ------ Dates: ------ Paper submission Monday November 14, 2011 (11:59PM US EST) Author notification Friday December 9, 2011 Conference Saturday January 28, 2012 ------ Scope: ------ Programming language researchers have the principles, tools, algorithms and abstractions to solve all kinds of problems, in all areas of computer science. However, identifying and evaluating new problems, particularly those that lie outside the typical core PL problems we all know and love, can be a significant challenge. Hence, the goal of this workshop is to identify and discuss problems that do not often show up in our top conferences, but where programming language researchers can make a substantial impact. The hope is that by holding such a forum and associating it directly with a top conference like POPL, we can slowly start to increase the diversity of problems that are studied by PL researchers and that by doing so we will increase the impact that our community has on the world. While many workshops associated with POPL have become more like mini-conferences themselves, this is not the goal for Off the Beaten Track. The workshop will be informal and structured to encourage discussion. It will also be centered around problems and problem areas as opposed to fully-formed solutions. A good submission is one that outlines a new problem or an interesting, underrepresented problem domain. Good submissions may also remind the PL community of problems that were once in vogue but have not recently been seen in top PL conferences. Good submissions do not need to propose complete or even partial solutions, though there should be some reason to believe that programming languages researchers have the tools necessary to search for solutions in the area at hand. Submissions that seem likely to stimulate discussion about the direction of programming language research are encouraged. Possible topics include any of the following. Biology, chemistry, or other natural sciences Art, music, graphics and animation Networking, cloud computing, systems programming Linguistics Economics, law, politics or other social sciences Web programming, social computing Algorithms and complexity Mathematics, statistics Machine learning or artificial intelligence Education Unusual compilers; underrepresented programming languages Surprise us We certainly hope to see submissions on topics not mentioned above. The goal of the workshop is to be inclusive, not exclusive. Submissions are evaluated on the basis of creativity, novelty, clarity, possible impact and potential for stimulating discussion. ------------------ Submission Details ------------------ See the web site: http://www.cs.princeton.edu/~dpw/obt/ ----------------- Program Committee ----------------- Program Chair: David Walker (Princeton University) Program Committee: Thomas Ball (Microsoft Research, Redmond) Trevor Jim (AT&T) Julia Lawall (DIKU) Boon Thau Loo (University of Pennsylvania) Geoff Mainland (Microsoft Research, Cambridge) Chung-chieh Shan (Cornell)

1 0

Problem with TemplateHaskell
by Magicloud Magiclouds 02 Nov '11

02 Nov '11

Hi, I have code as following, to make a toDocument function (using Data.Bsin.=:) for a data structure. bson :: DecsQ -> DecsQ bson decsq = do decs <- decsq let datad = head decs DataD _ _ _ cons _ = datad to = mkName "toDocument" from = mkName "fromDocument" fund <- mapM (\con -> case con of RecC n types -> do let nvs = map (\(nv, _, _) -> nv ) types funD to [clause [conP n $ map varP nvs] (normalB $ listE $ map (\nv -> infixE (Just $ litE $ stringL $ show nv) (varE $ mkName "=:") $ Just $ appE (varE $ mkName "val") $ varE nv ) nvs) []] ) cons return (datad : fund) Testing code is as: data T = T { a :: Int , b :: Char } *TH> runQ (bson [d|data T = T {a :: Int, b :: Char}|]) [DataD [] T_0 [] [RecC T_1 [(a_2,NotStrict,ConT GHC.Types.Int),(b_3,NotStrict,ConT GHC.Types.Char)]] [],FunD toDocument [Clause [ConP T_1 [VarP a_2,VarP b_3]] (NormalB (ListE [InfixE (Just (LitE (StringL "a_2"))) (VarE =:) (Just (AppE (VarE val) (VarE a_2))),InfixE (Just (LitE (StringL "b_3"))) (VarE =:) (Just (AppE (VarE val) (VarE b_3)))])) []]] So you see that, it changed the name from T/a/b to T_0/T_1/a_2/b_3. Why is that? I did not have code to modify original data declaration. -- 竹密岂妨流水过山高哪阻野云飞

2 4

HDBC SQLite error
by Jurriën Stutterheim 02 Nov '11

02 Nov '11

Hi all, I have recently switched one of my web applications to SQLite via HDBC. I use it to store some user credentials and data. Initially it seemed to work fine, until I tried logging in from two different browsers. That's when I got the following error when trying to log in: SqlError {seState = "", seNativeError = 5, seErrorMsg = "step: database is locked"} My application only uses two functions (query and query', see [1]) directly, and the authentication code[2] uses HDBC directly. I'm not sure why I'm getting this error, because as far as I can see, I'm not keeping any transactions open longer than I have to in the auth code. Does anyone have an idea what might be wrong and how to fix it? Cheers, Jurriën [1] https://github.com/norm2782/snaplet-hdbc/blob/master/src/Snap/Snaplet/Hdbc.… [2] https://github.com/norm2782/snaplet-hdbc/blob/master/src/Snap/Snaplet/Auth/…

2 2

Hackage feature request: E-mail author when a package breaks
by Gregory Crosswhite 02 Nov '11

02 Nov '11

Hey everyone, I have uploaded a number of small packages to Hackage that I no longer actively use so that I don't find out immediately when a new version of GHC has broken them. Since Hackage is going to the trouble of finding out when a package no longer builds anyway, could it have a feature where when a working package breaks with a new version of GHC the author is automatically e-mailed? This would make me (and probably others) a lot more likely to notice and proactively fix broken packages. (Heck, I wouldn't even necessarily mind being nagged about it from time to time. :-) ) Cheers, Greg

16 24

Persistent Concurrent Data Structures
by dokondr 02 Nov '11

02 Nov '11

Hi, Please comment on the idea and advise on steps to implement it. Real world applications need persistent data, that can be accessed and modified concurrently by several clients, in a way that preserves "happen-before" relationship. Idea: Design and implement Persistent Concurrent Data Types in Haskell. These data types should mirror existing Data.List , Data.Map and similar types but provide persistency and support consistent concurrent access and modification (or simply - "concurrency"). Persistency and concurrency should be configurable through these type interfaces. Configuration should include: 1) Media to persist data, such as file, DBMS, external key-value store (for example Amazon SimpleDB, CouchDB, MongoDB, Redis, etc) 2) Caching policy - when (on what events) and how much data to read/write from/to persistent media. Media reads / writes can be done asynchronously in separate threads. 3) Concurrency configuration: optimistic or pessimistic data locking. One may ask why encapsulate persistency and concurrency in the data type instead of using "native" storage API, such as for example key-value / row-column API that NoSQL databases provide? The answer is simple: APIs that your code use greatly influence the code itself. Using low-level storage API directly in your code results in bloated obscure code, or you need to encapsulate this low-level API in clear and powerful abstractions. So why not to do this encapsulation once and for all for such powerful types as Data.Map, for example, and forget all Cassandra and SimpleDB low-level access method details? When the right time comes and you will need to move your application to the next new "shiny_super_cloud", you will just write the implementation of NData.Map backed by Data.Map in terms of low-level API of this super-cloud. (Side note: I really need such a NData.Map type. I was requested to move my code that heavily uses Data.Map and simple text file persistence into Amazon AWS cloud. Looking at SimpleDB API, I realized that I will have to rewrite 90% of code. This rewrite will greatly bloat my code and will make it very unreadable. In case I had NData.Map I would just switch implementation from 'file' to SimpleDB persistency inside my NData.Map type.) Implementation: To start playing with this idea, NData.Map persisted in a regular file will do, no concurrency yet. Next step - NData.Map persisted in SimpleDB or Cassandra or Redis, with concurrent access supported. So it looks like NData.Map should be a monad ... Any ideas on implementation and similar work? Thanks! Dmitri --- http://sites.google.com/site/dokondr/welcome

5 6

Re: [Haskell-cafe] How to implement digital filters using Arrows
by Captain Freako 01 Nov '11

01 Nov '11

Hi John, Thanks for all your help. I've been studying your suggested code: > type FilterAu b c = Automaton (->) b c > liftAu :: ((x,FilterState s)->(y,FilterState s)) -> FilterState s -> FilterAu x y > liftAu f s0 = proc x -> do > rec (y,s') <- arr f -< (x,s) > s <- delay s0 -< s' > returnA -< y runAutomaton is a bit cumbersome, so define a custom run function that takes a list > runAuto a [] = [] > runAuto (Automaton f) (x:xs) = let > (y,a) = f xt > in y:runAuto a xs as well as the various instance definitions for Automaton. I think I understand how the `returnA' in the last line of your `liftAu' function is getting translated by those instance definitions into: c where c = Automaton ( arr id &&& arr (const c) ) and, furthermore, how that is passing the supplied `y' into the first element of the resulting couple. However, I don't understand how the recursively defined `c' is capturing the modified filter state and preserving it for the next call. It seems like the Automaton being referred to by `c' is a newly constructed entity, which knows nothing about the current state of the running Automaton. Any help in understanding this would be greatly appreciated. Thanks! -db

3 7

happstack file serving
by Antoine Latter 01 Nov '11

01 Nov '11

Including list. ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Tue, Nov 1, 2011 at 11:33 AM Subject: Re: [Haskell-cafe] happstack file serving To: Gary Klindt <gary.klindt(a)googlemail.com> On Tue, Nov 1, 2011 at 11:24 AM, Gary Klindt <gary.klindt(a)googlemail.com> wrote: > Hey Antoine, > > thank you for answering. Your strategy is quite similar to the one I prefer. > I misunderstood the behaviour of serveDirectory. The problem with external > javascript files is solved. > The other problem I had, was, that the argument 'msum' is a list, which has > elements with the same type, so I needed a conversion from > m [Char] to m Response. > In Happstack.Server.Response there is a function, which actually does that: > flatten: > > module Main where > > import Happstack.Server > import Control.Monad > > main :: IO () > main = simpleHTTP nullConf $ > msum [ flatten $ dir "ok" $ ok "jeahh!" > , serveDirectory DisableBrowsing ["index.html"] "static" ] > I would likely write that particular example: > dir "ok" $ ok $ toResponse "jeahh!" I find it convenient to convert to a 'Response' as close to the 'bottom' of the stack as possible. Antoine

1 0

LDTA 2012: Call for Papers
by Anya Helene Bagge 01 Nov '11

01 Nov '11

LDTA 2012 Call for Papers 12th International Workshop on Language Descriptions, Tools, and Applications www.ldta.info Tallinn, Estonia March 31 & April 1, 2012 an ETAPS workshop LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. A primary focus of LDTA is grammarware that is generated from high-level grammar-centric specifications and thus submissions on parser generation, attribute grammar systems, term/graph rewriting systems, and other grammar-related meta-programming tools, techniques, and formalisms are encouraged. LDTA is also a forum in which theory is put to the test, in many cases on real-world software engineering challenges. Thus, LDTA also solicits papers on the application of grammarware to areas including, but not limited to, the following: - program analysis, transformation, generation, and verification, - implementation of Domain-Specific Languages, - reverse engineering and re-engineering, - refactoring and other source-to-source transformations, - language definition and language prototyping, and - debugging, profiling, IDE support, and testing. Note that LDTA is a well-established workshop similar to other conferences on (programming) language engineering topics such as SLE and GPCE, but is solely focused on grammarware. Paper Submission ---------------- LDTA solicits papers in the following categories. - research papers: original research results within the scope of LDTA with a clear motivation, description, analysis, and evaluation. - short research papers: new innovative ideas that have not been completely fleshed out. As a workshop, LDTA strongly encourages these types of submissions. - experience report papers: description of the use of a grammarware tool or technique to solve a non-trivial applied problem with an emphasis on the advantages and disadvantages of the chosen approach to the problem. - tool demo papers: discussion of a tool or technique that explains the contributions of the tool and what specifically will be demonstrated. Each submission must clearly state in which of these categories it falls, and must not be published or submitted elsewhere. Papers are to use the standard LaTeX article style and the authblk style for affiliations; a sample of which is provided at www.ldta.info. Research and experience papers are limited to 15 pages, tool demonstration papers are limited to 10 pages, and short papers are limited to 6 pages. The final version of the accepted papers will, pending approval, be published in the ACM Digital Library and will also be made available during the workshop. Please submit your abstract and paper using EasyChair at http://www.easychair.org/conferences/?conf=ldta2012. The authors of each submission are required to give a presentation at LDTA 2011 and tool demonstration paper presentations are intended to include a significant live, interactive demonstration. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years this will be done in a special issue of the journal Science of Computer Programming (Elsevier Science). Invited Speaker --------------- To be announced Important Dates --------------- Abstract submission: Nov. 28, 2011 Full paper submission: Dec. 5, 2011 Author notification: Jan. 20, 2012 Camera-ready papers: Feb. 05, 2012 LDTA Workshop: Mar. 31 - Apr. 1, 2012 LDTA Tool Challenge ------------------- The 2011 Workshop pioneered the LDTA Tool Challenge where tool developers were invited to develop solutions to a range of language processing tasks over a simple but evolving set of imperative programming languages. We expect a challenge to form part of LDTA every two years. The 2012 workshop will feature presentations devoted to a de-brief of the 2011 challenge, based on the paper currently being prepared by challenge participants. Program Committee ----------------- Suzana Andova, Eindhoven University of Technology, The Netherlands (co-chair) Anya Helene Bagge, University of Bergen, Norway Kyung-Goo Doh, Hanyang University, Ansan, South Korea Jeff Gray, University of Alabama, USA Görel Hedin, Lund Institute of Technology, Sweden Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary Zhenjiang Hu, National Institute of Informatics, Japan Roberto Ierusalimschy, Pontifícia Universidade Católica do Rio de Janeiro, Brazil Ivan Kurtev, University of Twente, The Netherlands Marjan Mernik, University of Maribor, Slovenia Nate Nystrom, University of Lugano, Switzerland João Saraiva, Universidade do Minho, Braga, Portuga Sylvain Schmitz, Ecole Normale Supérieure de Cachan, France Anthony Sloane, Macquarie University, Australia (co-chair) Robert Tairas, Inria, France Laurence Tratt, King's College London, UK Vadim Zaytsev, Centre for Mathematics & Computer Science, The Netherlands Organizing Committee -------------------- Anya Helene Bagge, University of Bergen, Norway Emilie Balland, INRIA, France Steering Committee ------------------ Mark van den Brand, Eindhoven University of Technology, The Netherlands Görel Hedin, Lund University, Sweden Tony Sloane, Macquarie University, Australia Eric Van Wyk, University of Minnesota, United States

1 0