December 2013 - Haskell-Cafe

Help with profiling
by Uri Braun 05 Dec '13

05 Dec '13

Hi Café, I'm attempting to profile my rather large (~18K LOC) Haskell program that primarily manipulates graph structures based on Data.IntMap. The program is chewing up _lots_ of memory (approx. 4G for 2.5K nodes & 2.5K edges) and I have profiled it in an attempt to figure out why. It appears that the .prof and .hp (which I visualize with hp2ps -c) files do not agree on the source of the problem. The hp results are located at: http://www.eecs.harvard.edu/~uribraun/sybil.ps and the top of the .prof file looks like this: COST CENTRE MODULE %time %alloc compare Policy.Edge 21.7 50.0 eqPartition.edges Policy.EdgeQuad 6.5 3.7 toConstructedSet Types.TaggedIntMultimap 6.1 3.6 elems Types.TaggedIntMap 6.0 6.8 elems Types.TaggedIntSet 5.7 3.8 toPairs Types.TaggedIntMultimap 3.9 5.2 assocs Types.TaggedIntMap 3.2 4.1 eqIsValid Policy.EdgeQuad 2.9 0.5 rIsValid Policy.Relations 2.2 0.2 assocs.\ Types.TaggedIntMap 1.8 0.0 keysSet Types.TaggedIntMap 1.5 1.7 mergeIdenticalNodesT.exactMap Minimize.MergeIdentical 1.4 1.2 fromList Types.TaggedIntSet 1.3 1.6 tePartitionSrc Policy.TaggedEdge 1.2 0.9 null Types.TaggedIntSet 1.2 0.0 scc.comps Policy.Scc 1.2 0.9 tePartitionTgt Policy.TaggedEdge 1.1 0.8 member Types.TaggedIntSet 1.1 0.8 alter Types.TaggedIntMap 1.0 1.1 Also, the line in the .prof that corresponds to the anormUnion.name (what the hprof image claims is taking up space) looks like (some spaces removed): anormUnion.name Anormalize.Anormalize 2914 60 0.0 0.0 0.0 0.0 My main questions at this point are: 1. What are the chances the hprof image is just wrong? 2. What would you suggest I try next in debugging my space issue? This is my first big Haskell program, please do inform me of any big war tools I dont know about. Many thanks in advance! +Uri

2 2

Re: [Haskell-cafe] free vs. operational vs. free-operational
by oleg＠okmij.org 05 Dec '13

05 Dec '13

Alejandro Serrano Mena wrote: > I really like the separation between providing a data type and then a > interpretation that operational embodies... Then perhaps you may like extensible effects then. They are designed around the separation of requestors and their interpreters. However, the set of requests is open (and can be extended at any time without recompiling the program). Likewise the interpreters can be extended incrementally. One can add an interpreter for an effect without caring what other effects are there -- unless one has some reason for caring about other effects (e.g.,m for finalization). One may then snoop on other effects while interpreting. Moreover, the handlers may be scattered around program; they don't have to be all at the very top. Crucially, unlike data types a la carte, extensible effects provide effect encapsulation: one can not only add effects but subtract them, by completely handling the effects. The type system ensures that all effects must be completely handled at the end.

7 13

Cannot find HS*.o linked object for loading into ghci after last update
by Thiago Padilha 05 Dec '13

05 Dec '13

Hi After last update, cabal-install stopped generating an HSfoo-VERSION.o(assuming the package name is 'foo') in the dist/build directory. How can I force cabal to generate this file again?

2 2

Simple script to make existing GHC or HP installation work with Xcode 5
by Mark Lentczner 05 Dec '13

05 Dec '13

Friends - I've developed a simple shell script that should enable your existing GHC 7. or HP installation work with Xcode 5. https://gist.github.com/mzero/7245290 Place that script somewhere, make it executable, and run it. *Then follow the instructions it tells you!* You will end up having to run it more than once: First time it will tell you where to install a copy of the script Second time it will patch your GHC settings file(s) The script is safe to install and setup before you upgrade to Xcode 5, as it reverts to "getting out of the way" if it detects Xcode 4 based installation. It has been tested on two machines: - OS X 10.8 and Xcode 4 - OS X 10.9 and Xcode 5 If a few more intrepid souls test it and it works, I'll post instructions in more prominent places! I'll be testing OS X 10.9 and Xcode 4, tomorrow, and expect it should work fine on OS X10.8 with Xcode 5. But looking for reports that it all works. - Mark "Mac Packager" Lentczner

3 2

Re: [Haskell-cafe] Writer + log each computation to stdout
by oleg＠okmij.org 04 Dec '13

04 Dec '13

Bryan Vicknair wrote: > I have a bunch of little database IO functions. Each does something to the > database, and returns a log string describing what it did, and possibly a > meaningful result from the database. > ...and a few functions that orchestrate all the little functions into doing > useful work. > > I don't want the individual functions to know what is done with the log string > describing what they did. Top-level orchestrating functions should make that > decision, which can be one of: > > 1) Collect and print all to a log once all computations are done. > 2) Print to stdout *as each computation is run*. > 3) Ignore them. What an excellent case for extensible effects! Many thanks to Ben Foppa for making the package available on hackage, as extensible-effects. Extensible Effects designed specifically to separate a client (the requestor of an action) from a handler, the executor of an action. A logging client merely requests a string to be logged. It has no idea what happens when that request is executed. Therefore, the same client can be used with several handlers, even within the same expression. One can also build various interceptors, such as logIntercept, which is similar to Unix' tee. The following file illustrates how to solve the problem with all three scenarios. http://okmij.org/ftp/ The extensible effects package actually defines a very similar function, calls trace. For illustration and clarity, the file develops the Logging effect from scratch. After all, Extensible Effects encourages developing effects to suit the problem at hand. Defining a new effect is as simple as -- The request to log a string -- The request carries the String to log. It seems no particular -- reply is needed for the request (other than the simple acknowledgment), -- so we set the reply to be unit. data Log v = Log String (() -> v) deriving (Typeable, Functor) Clients use the function logit :: Member Log r => [Char] -> Eff r () (this signature, as all signatures in the code, are inferred). The signature says that the function request Log effect to be done. It does not concern itself how this effect its to be done. The file shows three handlers: runLogCollect, runLogTrace, runLogIgnore. There is also another handler, logIntercept, that like Unix 'tee', prints out the log message immediately while still propagating it. It can be used with any of the three handlers.

2 2

PhD at age 45?
by Dennis Raddle 04 Dec '13

04 Dec '13

A more specific question than my last post. I guess I'm wondering if it's a good idea to begin a PhD in CS at age 45 (currently having a BS in CS). My goal is to obtain work that interests me, work that really draws on the skills one develops in a PhD program. Work in academia is hard to obtain, I understand, but I could take an industry job. I'm wondering if I'll just be postponing a job with no financial gain afterward and poor prospects for work. Or if there is ageism that will work against a guy coming out of school at age 52. Or, if it will truly lead to an interesting job with good pay. Dennis

18 25

Need help: Cabal rejecting stringsearch, conflict in base
by Thiago Negri 04 Dec '13

04 Dec '13

I don't know what to do. :-( I can't install scotty or yesod. $ cabal install scotty cabal: Could not resolve dependencies: trying: scotty-0.5.0 (user goal) trying: base-4.7.0.0/installed-dc1... (dependency of scotty-0.5.0) trying: wai-extra-1.3.4.6 (dependency of scotty-0.5.0) trying: stringsearch-0.3.6.4 (dependency of wai-extra-1.3.4.6) rejecting: stringsearch-0.3.6.4:-base3 (conflict: base==4.7.0.0/installed-dc1..., stringsearch-0.3.6.4:base3 => base>=2 && <3) rejecting: stringsearch-0.3.6.4:+base3 (conflict: base==4.7.0.0/installed-dc1..., stringsearch-0.3.6.4:base3 => base>=3 && <4) Backjump limit reached (change with --max-backjumps).

6 6

Trouble cabal installing uniplate?
by David Banas 04 Dec '13

04 Dec '13

Has anyone else bumped into this error, when cabal installing uniplate? Data/Generics/Uniplate/Direct.hs:78:4: error: invalid preprocessing directive #-} ^ 1 error generated. Failed to install uniplate-1.6.11 Thanks, -db

2 1

Writer + log each computation to stdout
by Bryan Vicknair 04 Dec '13

04 Dec '13

Hello, I have a bunch of little database IO functions. Each does something to the database, and returns a log string describing what it did, and possibly a meaningful result from the database. query :: IO (String, a) update :: a -> IO (String, ()) ...and a few functions that orchestrate all the little functions into doing useful work. syncWeek :: Week -> IO () syncAll : : IO () I don't want the individual functions to know what is done with the log string describing what they did. Top-level orchestrating functions should make that decision, which can be one of: 1) Collect and print all to a log once all computations are done. 2) Print to stdout *as each computation is run*. 3) Ignore them. Here is my understanding of how common monads would handle these requirements: Writer: 1 and 3 are easy. This is what I originally attempted to use, but I couldn't figure out how to accomplish #2. Reader: 2 and 3 can be accomplished if each function reads a shouldLog config variable from the reader and does a putStrLn depending on the value. Very ugly, as now each function has to know how to log output. State: Not sure, but the Writer docs in the transformers package points to this monad as maybe solving requirement #2 above. The use case is that when I call the top-level functions from a command line script, I want to see logging happening in real-time to stdout, but I may call the same top-level functions from a larger application that may be logging to somewhere other than stdout, and may call the top-level functions from yet another larger application which doesn't want anything to be logged. How can I glue together a bunch of smaller computations, which may call each other, and decide at a higher level what to do with the logging result of each computation? Seems like a perfect fit for Writer, except for the requirement to be able to print to stdout at each step. Bryan Vicknair

5 4

[TFP 2014] 1st Call For Papers
by Peter Achten 03 Dec '13

03 Dec '13

Dear reader, Please find included the first call for papers for next year's Trends In Functional Programming event, organized by Jurriaan Hage from Utrecht University, The Netherlands. With kind regards, Peter Achten Communication chair TFP ----------------------------- C A L L F O R P A P E R S ----------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and submitted for formal publication. Selected papers will be published as a Springer Lecture Notes in Computer Science (LNCS) volume. TFP 2014 will be the main event of a pair of functional programming events. The other is the International Workshop on Trends in Functional Programming in Education (TFPIE). TFPIE will take place on May 25th. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh (Scotland) in 2003, in Munich (Germany) in 2004, in Tallinn (Estonia) in 2005, in Nottingham (UK) in 2006, in New York (USA) in 2007, in Nijmegen (The Netherlands) in 2008, in Komarno (Slovakia) in 2009, in Oklahoma (USA) in 2010, in Madrid (Spain) in 2011, St. Andrews (UK) in 2012 and Provo (Utah, USA) in 2013. For further general information about TFP please see the TFP homepage. INVITED SPEAKERS TFP is pleased to announce talks by the following two invited speakers: John Hughes of Chalmers, Goteborg, Sweden, is well-known as author of Why Functional Programming Matters, and as one of the designers of QuickCheck (together with Koen Claessen); the paper on QuickCheck won the ICFP Most Influential Paper Award in 2010. Currently he divides his time between his professorship and Quviq, a company that performs property-based testing of software with a tool implemented in Erlang. Dr. Geoffrey Mainland received his PhD from Harvard University where he was advised by Greg Morrisett and Matt Welsh. After a two year postdoc with the Programming Principles and Tools group at Microsoft Research Cambridge, he is now an assistant professor at Drexel University. His research focuses on high-level programming language and runtime support for non-general purpose computation. SCOPE The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Using functional techniques to reason about imperative/object-oriented programs Debugging for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2014 program chair, Jurriaan Hage at J.Hage(a)uu.nl. BEST PAPER AWARDS To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. SPONSORS TFP is financially supported by NWO (Netherlands Organisation for Scientific Research), Well-Typed and Erlang Solutions. PAPER SUBMISSIONS Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (16 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate whether the main author or authors are research students. In the case of a full student paper, the paper will receive additional feedback by one of the PC members shortly after the symposium has taken place. We shall use EasyChair for the refereeing process. IMPORTANT DATES Submission of draft papers: March 17, 2014 Notification: March 24, 2014 Registration: April 7, 2014 TFP Symposium: May 26-28, 2014 Student papers feedback: June 9th, 2014 Submission for formal review: July 1st, 2014 Notification of acceptance: September 8th, 2014 Camera ready paper: October 8th, 2014 PROGRAM COMMITTEE Peter Achten Radboud University Nijmegen Emil Axelsson Chalmers Lucilia Camarao de Figueiredo Universidade Federal de Ouro Preto Laura Castro University of A Coruna Frank Huch Christian-Albrechts-University of Kiel Matthew Fluet Rochester Institute of Technology Jurriaan Hage (chair) University of Utrecht Yukiyoshi Kameyama University of Tsukuba Andrew Kennedy Microsoft Research Tamas Kozsik Eotvos Lorand University Ben Lippmeier University of New South Wales Luc Maranget INRIA Jay McCarthy Brigham Young University Marco T. Morazan Seton Hall University Ricardo Pena Universidad Complutense de Madrid Alexey Rodriguez madvertise Sven-Bodo Scholz Heriot-Watt University Manuel Serrano INRIA Sophia Antipolis Simon Thompson University of Kent Tarmo Uustalu Inst of Cybernetics David Van Horn Maryland University Janis Voigtlaender University of Bonn

2 1