- Haskell - Haskell.org

Re[2]: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Bulat Ziganshin 07 May '09

07 May '09

Hello FFT, Wednesday, May 6, 2009, 11:59:53 PM, you wrote: > I've heard it's hard to contain a long-running Haskell application in > a finite amount of memory not exactly. you may alloc fixed pool of memory to application (say, 1gb) if you know that it never need more memory. but as far as you don't do it, memory usage grows with each major GC. ghc just don't provide any way to return memory to OS (there is a ticket on it, you can add yourself to CC list to vote for its resolution) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Anton van Straaten 07 May '09

07 May '09

Jason Dagit wrote: > On Wed, May 6, 2009 at 3:54 PM, Anton van Straaten > <anton(a)appsolutions.com> wrote: >> FWIW, I have an internal HAppS application that's been running continuously >> since November last year, used daily, with stable memory usage. > > Do you have advice about the way you wrote you app? Things you > knowingly did to avoid space leaks? Maybe a blog about your HAppS > app? The app is written for a client under NDA, so a blog about it would have to be annoyingly vague. But I don't think there's much mystery about why it doesn't leak: The app does simulations. Each simulation uses at least about 10MB of memory, more depending on parameters. Typically a few thousand simulations are run successively, and the results are aggregated and analyzed. The computation itself is purely functional - it takes some input parameters and produces results. The results are written to a file. Since each run of a set of simulations is essentially independent, there's not much risk of space leaks persisting across runs. No doubt the potential for encountering space leaks goes up as one writes less pure code, persist more things in memory, and depend on more libraries. My main point in mentioning my app is that "long-running" isn't really the issue - that's just a way of saying that an app has space leaks that are small enough not to be noticed until it's stressed. >> In my experience, it's not hard to write stable long-running code >> in good implementations of languages like Haskell, Scheme, Common Lisp, or >> Java. > > There are certainly cases where no automatic garbage collector could > know when it is safe to collect certain things. If there are bugs in the user's program, sure - but that still doesn't make it "hard" to write applications that don't leak, given a decent GC. On the contrary, I'd say it's very easy, in the great majority of cases. > A quick google search > for java space leaks turned up this article: > http://www.ibm.com/developerworks/java/library/j-leaks/ > > I think wikipedia uses the term "logical leak" for the type of space > leak I'm thinking of. The garbage collector thinks you care about an > object but in fact, you want it to be freed. Yes, it's because of a > bug, but these are bugs that tend to be subtle and tedious. The example given in the IBM article is quite typical, but isn't subtle at all - it was simply an object being added to a table and never being removed. You can often find such bugs quite easily by searching the source tree, without touching a debugging tool. It's also possible to prevent them quite easily, with good coding practices (e.g. centralize uses of long-lived tables) and some simple code auditing practices. If you're dealing with code that's complex enough to involve the kinds of non-trivial mutually dependent references that you need in order to encounter truly subtle instances of these bugs, the increased difficulty of memory management comes with the territory, i.e. it's harder because the application is harder. > The ambiguity is me thinking of relative cost of finding/fixing these > bugs. To put this back into context, I was objecting to your having extended the space leak worrying to all GC'd languages. I'm saying that it isn't hard, using most decent language implementations, to avoid space leaks. For trivial cases such as the IBM example, it should be no harder in Haskell, either - possibly easier, since use of things like mutable tables is more controlled, and may be rarer. However, Haskell does theoretically introduce a new class of dangers for space leaks, I'm not denying that. Being pure and lazy introduces its own set of space leak risks. But on that front, I was disturbed by the vagueness of the claims about long-running apps. I haven't seen any solid justification for scaring people off about writing long-running apps in Haskell. If there is such a justification, it needs to be more clearly identified. > Testing for correctness is something we tend to automate very > well. How do you automate testing for performance under load? Space usage is a similar kind of dynamic issue, in general. > So then, at some point we must have a bag of tricks for dealing with > these space leaks. I want to talk about those tricks. I'm not > talking about bugs in a specific program, but instead about techniques > and styles that are known to work well in practice. OK. That's a bit different from FFT's original contention, "hard to contain a long-running Haskell application in a finite amount of memory." For my own part, I'm at least as non-strict as Haskell, and that bag of tricks, for me, is a thunk that hasn't yet been forced. Anton

1 0

Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Bryan O'Sullivan 06 May '09

06 May '09

On Wed, May 6, 2009 at 4:12 PM, Jason Dagit <dagit(a)codersbase.com> wrote: > > While I'm thinking out loud, it would be very cool if someone wrote > some articles, say for the monad reader, that follow the formula of > the Effective C++ books. The last couple of times I've wanted a book like that, I wrote the book myself. It's a very effective way to get the book you want, compared to wishing.

1 0

Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Anton van Straaten 06 May '09

06 May '09

Jason Dagit wrote: > I know from experience that lambdabot tends to be leaky. Otherwise, > lambdabot wouldn't be running on my server to begin with. And, even > so, Cale monitors lambdabot to make sure it is not using too many > resources (and I complain when/if I notice it). I have heard similar > stories related to hpaste and happs. FWIW, I have an internal HAppS application that's been running continuously since November last year, used daily, with stable memory usage. > I have also experienced it with > writing a forever loop in Haskell that did polling from channels. I > would leave my app running for, say, 4 hours and it would be using > tons of memory. If you posted an example of that, there are probably people who'd be interested in debugging it. > I think it's fair to say that keeping the memory usage low of a long > running Haskell app is hard, but that is a general issue not just a > Haskell issue. It's hard in most languages. I don't agree with this. This should not be hard in language implementations with good garbage collectors, that don't have known limitations (this excludes e.g. conservative GC and reference-counting systems). In my experience, it's not hard to write stable long-running code in good implementations of languages like Haskell, Scheme, Common Lisp, or Java. > I think what we need to > address this is more information about preventative measures. What > programming styles cause the problem and which ones solve it. I would > say that I lack confidence recommending anyone to use Haskell for long > running processes because I don't understand well the problem of > keeping the usage low. If it is a well documented problem with > documented solutions (more than just profiling), then I would regain > my confidence because I know the problem can be worked around > reliably. Does this make sense? Maybe it's already well documented? This doesn't completely make sense to me, in that either a program has a space leak, or it doesn't. If it does, you debug it and resolve it. If a leak really is due to a problem with the language implementation or standard libraries, then that should be identified and reported. There shouldn't be any deep mystery here. At the very least, it should be possible to point to the relevant trac tickets if there really is a problem. Anton

1 0

Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Don Stewart 06 May '09

06 May '09

dagit: > In particular, we need expert Haskell programmers, such as Don, to > write more about how they avoid space leaks in long running apps. > Again, profiling is nice, but that's more of a tuning effort. I talk a bit about that in my LondonHUG talk: http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell… As I said earlier: stress test with heap profiling on (is one way to absolutely ensure you know what's going on). -- Don

1 0

Re: [Haskell-cafe] Is Haskell a Good Choice for Web Applications? (ANN: Vocabulink)
by Don Stewart 06 May '09

06 May '09

fft1976: > I've heard it's hard to contain a long-running Haskell application in > a finite amount of memory, but this is probably not a problem if your Hmm. Gossip driven development? > web site sleeps 0.001% of the time (like XMonad), or you can restart > it every once in a while without anyone noticing. Keeping footprints small and stable isn't so hard. After all, we have wonderful heap profiling tools. I recommend the type-based heap profiler, in particular. Run your app for a week, and look at the heap graph. You'll know if things are ok. (Try this in C++ !) -- Don

1 0

Haskell Arrows Application
by Hannousse 06 May '09

06 May '09

Hello, I'm interested to the concept of arrows in Haskell, however, I couldn't find a real application or example using this new technology in a real world application. All what I found are just academic examples and other people developing new specific libraries using arrows.Could someone, please, give me a reference to one of the real applications that uses arrows. Thank you for all Hannousse. -- View this message in context: http://www.nabble.com/Haskell-Arrows-Application-tp23402523p23402523.html Sent from the Haskell - Haskell mailing list archive at Nabble.com.

3 2

Haskell Symposium deadline: May 8, 3PM EDT
by Stephanie Weirich 06 May '09

06 May '09

Reminder: The deadline for the Haskell Symposium is Friday, May 8th at 3PM Eastern Daylight Time. Important: this is 3PM in Philadelphia, not in Apia or wherever you are. There will be NO EXTENSIONS. Find the deadline for your time zone from a link on the Haskell 09 webpage. http://haskell.org/haskell-symposium/2009/ Submission to the Haskell Symposium is now open at: http://www.easychair.org/conferences/?conf=haskell09 You can update your submission(s) anytime up to the deadline, so give it a try now. Cheers, Stephanie --------------------------------------------------------------- Haskell 09 ACM SIGPLAN Haskell Symposium 2009 Edinburgh, Scotland, UK September 3, 2009 CALL FOR PAPERS http://haskell.org/haskell-symposium/2009/ The ACM SIGPLAN Haskell Symposium 2009 will be co-located with the 2009 International Conference on Functional Programming (ICFP). The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Topics of interest include, but are not limited to, the following: * Language Design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, in the form of a formal treatment of the semantics of the present language or future extensions, type systems, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management as well as foreign function and component interfaces; * Tools, in the form of profilers, tracers, debuggers, pre-processors, and so forth; * Applications, Practice, and Experience, with Haskell for scientific and symbolic computing, database, multimedia and Web applications, and so forth as well as general experience with Haskell in education and industry; * Functional Pearls, being elegant, instructive examples of using Haskell. Papers in the latter two categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a program! Before 2008, the Haskell Symposium was known as the Haskell Workshop. The name change reflects both the steady increase of influence of the Haskell Workshop on the wider community as well as the increasing number of high quality submissions. The acceptance process is highly competitive. After eleven Haskell Workshops between 1995 and 2007, the first Haskell Symposium was held in Victoria in 2008. Submission Details * Submission Deadline: Friday, May 8th 2009 (3:00 pm, Eastern US Time) * Author Notification: Monday, June 1st 2009 * Final Papers Due : Monday, June 15th 2009 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (http://www.acm.org/sigs/sigplan/authorInformation.htm) The length is restricted to 12 pages, and the font size 9pt. Each submission must adhere to SIGPLAN's republication policy, as explained on the web. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. If there is sufficient demand, we will try to organize a time slot for system or tool demonstrations. If you are interested in demonstrating a Haskell related tool or application, please send a brief demo proposal to Stephanie Weirich, sweirich(a)cis.upenn.edu. Links * http://haskell.org/haskell-symposium, the permanent homepage of the Haskell Symposium. * http://haskell.org/haskell-symposium/2009/, the 2009 Haskell Symposium web page. * http://www.icfpconference.org/icfp2009, the ICFP 2009 web page. Program Committee * Jeremy Gibbons, Oxford University * Bastiaan Heeren, Open Universiteit Nederland * John Hughes, Chalmers/Quviq * Mark Jones, Portland State University * Simon Marlow, Microsoft Research * Ulf Norell, Chalmers * Chris Okasaki, United States Military Academy * Ross Paterson, City University London * Alexey Rodriguez Yakushev, Vector Fabrics * Don Stewart, Galois * Janis Voigtlaender, TU Dresden * Stephanie Weirich, University of Pennsylvania (Chair) _______________________________________________ Haskell-pc mailing list Haskell-pc(a)lists.seas.upenn.edu http://lists.seas.upenn.edu/mailman/listinfo/haskell-pc

1 0

ANNOUNCE: The Haskell Platform
by Don Stewart 06 May '09

06 May '09

We're pleased to announce the first release of the Haskell Platform: a single, standard Haskell distribution for every system. Download the Haskell Platform 2009.2.0 installers and specification: http://hackage.haskell.org/platform/ The Haskell Platform is a blessed library and tool suite for Haskell culled from Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with. *Please note that this is a beta release*. We do not expect all the installers to work perfectly, nor every developer need met, and we would appreciate feedback. You can help out by packaging the platform for your distro, or reporting bugs and feature requests, or installing Haskell onto your friends' machines. The process for adding new tools and libraries will be outlined in coming weeks. The Haskell Platform would not have been possible without the hard work of the Cabal development team, the Hackage developers and maintainers, the individual compiler, tool and library authors who contributed to the suite, and the distro maintainers who build and distribute the Haskell Platform. Thanks! -- The Platform Infrastructure Team

1 0

Last CFP: Trends in Functional Programming
by Horváth Zoltán 05 May '09

05 May '09

Last call for papers 10th SYMPOSIUM ON TRENDS IN FUNCTIONAL PROGRAMMING TFP 2009 SELYE JANOS UNIVERSITY, KOMARNO, SLOVAKIA June 2-4, 2009 http://www.inf.elte.hu/tfp_cefp_2009 *** Submission deadline extended until 10th of May! *** The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results. Acceptance for the conference is based on full papers or extended abstracts, and a formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2009 is hosted by the Selye Janos University, Komarno, Slovakia, and it is co-located with the 3rd Central-European Functional Programming School (CEFP 2009), which is held immediately before TFP 2009 (May 25-30). IMPORTANT DATES (ALL 2009) * Paper Submission: May 10 (extended) * Notification of Acceptance: May 12 * Camera Ready Symposium Proceedings Paper: May 14 * TFP Symposium: June 2-4, 2009 * Post Symposium Paper Submission: June 30 * Notification of Acceptance: September 7 * Camera Ready Revised Paper: September 21 SCOPE OF THE SYMPOSIUM 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: leading-edge, previously unpublished research. * Position: on what new trends should or should not be. * Project: descriptions of recently started new projects. * Evaluation: what lessons can be drawn from a finished project. * Overview: 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. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional 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 2009 program chairs, Zoltan Horvath and Viktoria Zsok at tfp2009(a)inf.elte.hu<mailto:tfp2009@inf.elte.hu> SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the screening process of full papers (15 pages) and extended abstracts (at least 3 pages). TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings. Further details can be found at the TFP 2009 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. PROGRAM COMMITTEE * Peter Achten (symp-chair), Radboud University Nijmegen, NL * John Clements, California Polytechnic State University, USA * Cormac Flanagan, University of California at Santa Cruz, USA * Jurriaan Hage, Utrecht University, NL * Kevin Hammond, University of St. Andrews, UK * Michael Hanus, Christian-Albrechts University zu Kiel, DE * Ralf Hinze, University of Oxford, UK * Zoltan Horvath (PC co-chair), Eotvos Lorand University, HU * Graham Hutton, University of Nottingham, UK * Johan Jeuring, Utrecht University, NL * Pieter Koopman (symp-chair), Radboud University Nijmegen, NL * Hans-Wolfgang Loidl, Ludwig-Maximilians University Munchen, DE * Rita Loogen, Philipps-University Marburg, DE * Greg Michaelson, Heriot-Watt University, UK * Marco T. Morazan, Seton Hall University, USA * Rex L Page, University of Oklahoma, USA * Sven-Bodo Scholz, University of Hertfordshire, UK * Clara Segura, University Complutense de Madrid, ES * Mary Sheeran, Chalmers University of Technology, SE * Phil Trinder, Heriot-Watt University, UK * Marko van Eekelen, Radboud University Nijmegen, NL * Varmo Vene, University of Tartu, EE * Viktoria Zsok (PC co-chair), Eotvos Lorand University, HU LOCATION The Conference Centre of Selye University, Komarno, Slovakia (http://www.selyeuni.sk/) is a new and excellent conference centre with modern equipment, lecture rooms and computer labs. Komarno is on the north bank of river Danube, the northern part of the city Komarom / Komarno. It is a charming old city with about 30 000 inhabitants, 90 km away from Budapest (the capital of Hungary), with good highway and railway connections and 90 km away from Bratislava (the capital of Slovakia), about 100 km from Vienna International Airport.

1 0