Re: [Haskell-cafe] Hackage checking maintainership of packages
+1. I would be more than happy to receive such an email every 3 months and quickly scan the page to update the maintained status for each of the packages where I'm marked as the maintainer. One modification I would make is to persist the checked state across emails. They should all be unchecked in the very first email for a given user. Later emails should preload the previous submission, i.e. the current state, so the user doesn't have to do a bunch of work if nothing is changed. That could get annoying for people who maintain 10s of packages on Hackage. This is obvious, but that page should also be accessible through some My Profile page so that I don't have to wait until I get the email if I want to modify a status. I also wonder if it might be worth it to have a little bit more detail than just maintained and not maintained as possible flags. Something like the following would be nice (I'm sure there are better names; I just don't have the time right now) : - Actively Developed (Meaning: The package is alive, it's a priority and it's actively improved) - Maintained (Meaning: I make sure it doesn't break, semantics are preserved but no major enhancements) - Life Support (Meaning: I just keep it compiling with no effort towards correctness, i.e. use with caution) - Deprecated/Unmaintained On Monday, May 6, 2013 at 10:55 PM, Dan P. wrote: On Monday 06 May 2013 14:34:13 Tobias Dammers wrote: The problem is that people tend to (truthfully) check such a box, then stop maintaining the package for whatever reasons, and never bother unchecking the box. I think there should be just one mail per maintainer mail address, not per package. The notification mail should provide a link to a page, that shows all packages maintained by this user (mail address). Every checkbox should be unchecked by default whether there is activity in the repo or not. This way, the maintainers wouldn't get annoyed by hackage mail spam and to check a couple of checkboxes just takes a few minutes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: retry 0.1 - retry combinators for monadic actions that often fail
Good point - I'll put an option in for the next release. On Wednesday, March 13, 2013 at 4:32 AM, Simon Marechal wrote: On 13/03/2013 05:14, Ozgun Ataman wrote: In either case, there is a ceiling for the number of total retries. This is something that I might want to use in many places. Is it possible to have an infinite number of retries, instead of specifying impossibly large values ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: retry 0.1 - retry combinators for monadic actions that often fail
Dear Cafe, I'm happy to announce the availability of the retry package on Hackage[1] and Github[2]. The package provides a few useful combinators for monadic actions that often fail and should be retried in cases of a certain set of exceptions (or failure modes). Such cases are quite common when querying databases (e.g. ResponseTimeout) or uploading files (e.g. socket closed), particularly in busy production systems. The library exposes 'retrying' for failures encoded explicitly in the type and 'recovering' for failures through exceptions, respectively. You can choose either an exponential back off series of delays or a simple static delay between retries. In either case, there is a ceiling for the number of total retries. The haddocks provide further documentation and a few examples. This library simply wraps around the given actions and does not really do anything fancy or unexpected. Nevertheless, the widespread applicability of this functionality justified a generic package to address the need centrally. Suggestions and bug reports are most welcome. [1] http://hackage.haskell.org/package/retry [2] https://github.com/Soostone/retry Cheers, Ozgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
I would encourage you to take a look at the snap (the web framework) package, where this concern is handled for you as part of the session snaplet. The Snap.Snaplet.Sessionhttp://hackage.haskell.org/packages/archive/snap/0.11.2/doc/html/Snap-Snaplet-Session.html module and the Snap.Snaplet.Session.Backends.CookieSessionhttp://hackage.haskell.org/packages/archive/snap/0.11.2/doc/html/Snap-Snaplet-Session-Backends-CookieSession.html ensure that contents of the cookie-persistent sessions are encrypted and so you can place anything from user ids to other secret information there, although I would certainly keep it to a minimum for size concerns. Here it is: http://hackage.haskell.org/package/snap Hope this helps, Oz On Wed, Feb 27, 2013 at 2:08 PM, Corentin Dupont corentin.dup...@gmail.comwrote: So I need to encrypt the user ID in some way? What I need is to associate the user ID to a random number and store the association is a table? On Wed, Feb 27, 2013 at 3:52 PM, Erik Hesselink hessel...@gmail.comwrote: Note that cookies are not the solution here. Cookies are just as user controlled as the url, just less visible. What you need is a session id: a mapping from a non-consecutive, non-guessable, secret token to the user id (which is sequential and thus guessable, and often exposed in urls etc.). It doesn't matter if you then store it in the url or a cookie. Cookies are just more convenient. Erik On Wed, Feb 27, 2013 at 3:30 PM, Corentin Dupont corentin.dup...@gmail.com wrote: Yes, having a cookie to keep track of the session if something I plan to do. On Wed, Feb 27, 2013 at 3:16 PM, Mats Rauhala mats.rauh...@gmail.com wrote: The user id is not necessarily the problem, but rather that you can impose as another user. For this, one solution is to keep track of a unique (changing) user token in the cookies and use that for verifying the user. -- Mats Rauhala MasseR -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlEuFVQACgkQHRg/fChhmVMu3ACeLLjbluDQRYekIA2XY37Xbrql tH0An1eQHrLLxCjHHBQcZKmy1iYxCxTt =tf0d -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
You probably can't use it directly but it should at least show you how we did it. In particular, the Snap.Snaplet.Session.SecureCookie module (internal, I think, so look at source) may be of interest to you as it implements the self-contained idea of encrypted cookies. - Oz On Wednesday, February 27, 2013 at 4:43 PM, Corentin Dupont wrote: Thanks Ozgun, but I'm using Happstack: this will be compatible? On Wed, Feb 27, 2013 at 10:30 PM, Ozgun Ataman ozata...@gmail.com (mailto:ozata...@gmail.com) wrote: I would encourage you to take a look at the snap (the web framework) package, where this concern is handled for you as part of the session snaplet. The Snap.Snaplet.Session (http://hackage.haskell.org/packages/archive/snap/0.11.2/doc/html/Snap-Snaplet-Session.html) module and the Snap.Snaplet.Session.Backends.CookieSession (http://hackage.haskell.org/packages/archive/snap/0.11.2/doc/html/Snap-Snaplet-Session-Backends-CookieSession.html) ensure that contents of the cookie-persistent sessions are encrypted and so you can place anything from user ids to other secret information there, although I would certainly keep it to a minimum for size concerns. Here it is: http://hackage.haskell.org/package/snap Hope this helps, Oz On Wed, Feb 27, 2013 at 2:08 PM, Corentin Dupont corentin.dup...@gmail.com (mailto:corentin.dup...@gmail.com) wrote: So I need to encrypt the user ID in some way? What I need is to associate the user ID to a random number and store the association is a table? On Wed, Feb 27, 2013 at 3:52 PM, Erik Hesselink hessel...@gmail.com (mailto:hessel...@gmail.com) wrote: Note that cookies are not the solution here. Cookies are just as user controlled as the url, just less visible. What you need is a session id: a mapping from a non-consecutive, non-guessable, secret token to the user id (which is sequential and thus guessable, and often exposed in urls etc.). It doesn't matter if you then store it in the url or a cookie. Cookies are just more convenient. Erik On Wed, Feb 27, 2013 at 3:30 PM, Corentin Dupont corentin.dup...@gmail.com (mailto:corentin.dup...@gmail.com) wrote: Yes, having a cookie to keep track of the session if something I plan to do. On Wed, Feb 27, 2013 at 3:16 PM, Mats Rauhala mats.rauh...@gmail.com (mailto:mats.rauh...@gmail.com) wrote: The user id is not necessarily the problem, but rather that you can impose as another user. For this, one solution is to keep track of a unique (changing) user token in the cookies and use that for verifying the user. -- Mats Rauhala MasseR -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlEuFVQACgkQHRg/fChhmVMu3ACeLLjbluDQRYekIA2XY37Xbrql tH0An1eQHrLLxCjHHBQcZKmy1iYxCxTt =tf0d -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: conduit-network-stream, A base layer for network protocols with Conduits
One question - and sorry that I didn't get a chance to try some examples myself - but can bi-directional conversations be carried between server/client in interleaving fashion using your library? Something like (simplified): myClient = receive = send . compute I have previously accomplished this using TBMChan and cereal-conduit to achieve the message delineation, but your library would certainly remove a layer of complexity if interleaved bi-directional talk is possible. - Ozgun On Monday, February 25, 2013 at 8:09 AM, Nils wrote: Of course you don't have to use my library if your library already solves the same problem. Am 25.02.2013 13:10, schrieb Alexander V Vershilov: data Result = Error Text ByteString | NeedMore (ByteString - Result a) | HaveResult a I still see an issue with this if you're receiving multiple messages in one `ByteString` chunk. A type like `HaveResult a ByteString` which also returns the leftover `ByteString` after the first result has been found could solve this, but you'd still have to re-yield this bytestring by hand and you'll possible end up with more calls to decode than necessary. Of course, with json you could avoid this problem by wrapping all messages into a json-list and sending this list as one big message. But that way you lose almost all advantages of a conduit - you cannot map over those list iems, you cannot process each item one by one, you cannot fold or filter them. When using this approach I don't really see the advantage over using the plain old connectTo/hGetContents method? Anyway, my library is independent of the bytestring encoding you want to use with it. I think it's the most general solution and avoids having to re-implement the same solution for each and every protocol design over and over again. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
On Monday, February 25, 2013 at 2:59 PM, Johan Tibell wrote: On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez nico...@incubaid.com (mailto:nico...@incubaid.com) wrote: - cereal supports chunk-based 'partial' parsing (runGetPartial). It looks like support for this is introduced in recent versions of 'binary' as well (runGetIncremental) Yes. Binary now support an incremental interface. We intend to make sure binary has all the same functionality as cereal. We'd like to move away from having two packages if possible and since binary has the larger installed user base we're trying to make that the go-to package. As a minor side note: Just wanted to point out that safecopy (http://hackage.haskell.org/package/safecopy) provides a nice migration framework for production use cases and is based on cereal. Migration becomes an issue in production sooner or later, and I think safecopy is a nice alternative to the approach Google's protocol buffers takes (for example). For eventual unification on binary, it may be a good idea to port it (and other useful libs that build on cereal) as well. - cereal can output a strict bytestring (runPut) or a lazy one (runPutLazy), whilst binary only outputs lazy ones (runPut) The lazy one is more general and you can use toStrict (from bytestring) to get a strict ByteString from a lazy one, without loss of performance. - Next to binary and cereal, there's bytestring's Builder interface for serialization, and Simon Meier's blaze-binary prototype Simon's builder (originally developed in blaze-binary) has been merged into the bytestring package. In the future binary will just re-export that builder. There are some blog posts and comments out there about merging cereal and binary, is this what's the goal/going on (cfr runGetIncremental)? It's most definitely the goal and it's basically done. The only thing I don't think we'll adopt from cereal is the instances from container types. In my use-case I think using Builder instead of binary/cereal's PutM monad shouldn't be a major problem. Is this advisable performance-wise? You can go ahead and use the builder directly if you like. Overall: what's the advised future-proof strategy of handling binary (de)serialization? Use binary or the builder from bytestring whenever you can. Since the builder in bytestring was recently added you might have to fall back to blaze-builder if you believe your users can't rely on the latest version of bytestring. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: lazy-csv - the fastest and most space-efficient parser for CSV
I'd also like to point to a couple of CSV libraries I released a long time ago and have been maintaining that both target constant-space operation and try (and hope) for the best in terms of speed. I'd be very interested to know how they fare in terms of performance benchmarking: Latest, based on conduit: http://hackage.haskell.org/package/csv-conduit (just released the latest version) Older, based on enumerator: http://hackage.haskell.org/package/csv-enumerator Notice how both are based on IO streaming libraries of fame to achieve both constant space operation AND nice interoperability with their habitat. I have found this to be especially true in the case of conduit. If you end up designing a benchmark, I'd be happy to get it working with my library. - Oz On Monday, February 25, 2013 at 5:16 PM, John Wiegley wrote: Malcolm Wallace malcolm.wall...@me.com (mailto:malcolm.wall...@me.com) writes: Simple answer - I have never heard of cassava, and suspect it did not exist when I first did the benchmarking. I'd be happy to re-do my performance comparison, including cassava and any other recent-ish CSV libraries, if I can find them. I would be very interested in those results, Malcolm. Thanks, -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net (http://irc.freenode.net) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-dev add-source
On Friday, February 8, 2013 at 1:19 PM, Johan Tibell wrote: On Fri, Feb 8, 2013 at 10:07 AM, JP Moresmau jpmores...@gmail.com (mailto:jpmores...@gmail.com) wrote: Johan, thanks, that brings me to a point that I wanted to raise. I'm playing with cabal-dev because users have asked me to add support for it in EclipseFP (so projects could have their own sandbox and have dependencies between projects without polluting the main package databases). It is worth it, or should I just wait for cabal 1.18 and use the sandboxing facility? Or will the two work similarly enough that supporting both will be easy? Does the sandboxing in cabal means that tools like cabal-dev are going to get deprecated? I think they will be similar enough that you could easily port the code. The new cabal sandboxing will work as follows: cabal sandbox --init cabal add-source dir and then you use cabal commands like normal (e.g. configure, build, test). No installing necessary. I cannot speak for the cabal-dev developers. We do intend to support a superset of the cabal-dev functionality eventually. What we're missing now is ghci support. Which, thanks to Johan's help yesterday, can still be worked around (for now) by starting ghci with: ghci -package-conf ./cabal-sandbox/your-package-conf-folder-here/ I'm trying to get Emacs haskell-mode and inferior-haskell to play nice with this, but it's not working so far for some reason. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Substantial (1:10??) system dependencies of runtime performance??
If you are doing row-by-row transformations, I would recommend giving a try to my csv-conduit or csv-enumerator packages on Hackage. They were designed with constant space operation in mind, which may help you here. If you're keeping an accumulator around, however, you may still run into issues with too much laziness. Ozgun On Feb 2, 2013, at 7:17 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Nick Rudnick wrote: thanks for the interesting info. I quite often have processing of CSV file data of about 100M-1G done. What library are you using to process the CSV? I have had problems with excessive laziness causing processing of a 75Meg CSV file consuming 500+ megabytes and after I fixed it memory usage dropped to under a megabyte. Processing time dropped from over 10 minutes to about 2 minutes. I blogged my problem and solution here: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/my_space_is_leaking.html I probably need to revisit that because the problem can probably be fixed without deepseq-generics and just using BangPatterns. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads
We could debate this endlessly (as is common), but I would argue that a clean design would make the option and alternative of multiplying explicit in its design instead of including calls to fetch command line arguments in an ad-hoc fashion everywhere. The Haskell way of encoding this would be to define an app configuration data type (say AppConfig), parse the command line arguments into it upfront in IO and then run your application either in a in a monad that's an instance of (MonadReader MyConfig) or explicitly pass the option in where needed by a function. If you've designed your application this way, adding a new command line option would cause very little -if any- refactoring. If not, in my experience it is usually a 30 minute intense refactoring campaign. I suspect there might be a way to use implicit arguments here as well, but that's something I've never felt compelled to use. This kind of separation of concerns and pure application design is one of the things that (I think) many people really like about Haskell. Cheers, Oz On Tuesday, June 26, 2012 at 6:19 PM, Tillmann Rendel wrote: Hi, MightyByte wrote: Of course every line of your program that uses a Foo will change if you switch to IO Foo instead. But we often have to also change lines that don't use Foo at all. For example, here is the type of binary trees of integers: data Tree = Leaf Integer | Branch (Tree Integer) (Tree Integer) A function to add up all integers in a tree: amount:: Tree - Integer amount (Leaf x) = x amount (Branch t1 t2) = amountt1 + amountt2 All fine so far. Now, consider the following additional requirement: If the command-line flag --multiply is set, the function amount computes the product instead of the sum. In a language with implicit side effects, it is easy to implement this. We just change the third line of the amount function to check whether to call (+) or (*). In particular, we would not touch the other two lines. How would you implement this requirement in Haskell without changing the line amount (Leaf x) = x? (I actually see three ways of doing this in Haskell, but all have serious drawbacks and do not fully solve the problem). Here it seems not so bad just to change all three lines of the amount function, even if they are not strictly related to the semantic change we want to make. But in a real program, this situation can translate to changing thousands of lines of code in many functions just to implement a minor change to a single requirement. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the difference between runhaskell and compile?
Maybe try with ghc --make -O0. Afaik, ghci and runhaskell don't do any optimization, which could be the difference. On May 27, 2012, at 5:12 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, Sorry for the delayed reply. I am using ghc 7.4.1 and LDAP 0.6.6. When you said configuration of the OpenLDAP client library, may I have more information? Since ldap-utils and other client (php, perl, etc) do not have any problem. This might be the only clue to me. On Fri, May 25, 2012 at 4:43 PM, Chris Dornan ch...@chrisdornan.com wrote: I have been using LDAP with GHC without a problem – I get this error often but the problems have been with the configuration of the OpenLDAP client library or the OpenLDAP server. We are all taking about LDAP-0.6.6? Which version of GHC are we talking about? (I don’t think I have tested this on GHC-7.4.1, and maybe the others haven’t either.) Chris From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Brandon Allbery Sent: 25 May 2012 04:21 To: Magicloud Magiclouds Cc: Haskell-Cafe Subject: Re: [Haskell-cafe] What is the difference between runhaskell and compile? On Thu, May 24, 2012 at 11:05 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi there, The code could not be simpler. Just ldapInit, ldapSimpleBind. I just found that the code works with ghci, too. So to sum up, ghci/runhaskell works, ghc not. A possibility that occurs to me: does it by any chance work with ghc -threaded? Perhaps the issue relates to the different behavior of the threaded runtime (which is used automatically by ghci/runghc). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] too many open files using snap
Not knowing how exactly you set up your interop with mysql, is there any chance your application tries to keep too many mysql connections open? A simple show processlist; inside of a mysql console should rule out this possibility. Also, are you reading to or writing from any files at any point independently of the snap infrastructure? I have had issues in the past with intermittent background file reads not being strict enough and eventually starving the system of file descriptors. Cheers, Ozgun On Sunday, January 8, 2012 at 4:27 PM, Gregory Collins wrote: On Sun, Jan 8, 2012 at 7:25 AM, Eric Wong wsy...@gmail.com (mailto:wsy...@gmail.com) wrote: Hi haskellers, I wrote a web server using snap framework. Basically, it's an API server using hdbc-mysql to connect to a mysql server. But it also serves some static web pages and images, using the serveDirectory function in snap-core. The program eats more and more memory slowly, but I couldn't spot the leak. It uses less than 10MB memory when starting. Sometimes, it can grow to 60-70MB and stop working correctly. Then I find that the log file is full of too many open files error. As I don't have any code open any files, I suspect it's the serveDirectory leaking. But I don't have any expertise on the core of snap, so, could some one give me some advice on this problem? I'm fairly certain there's no leak in Snap in this code, although I will gladly accept evidence to the contrary -- I've been load-testing serveDirectory at 20,000 qps for a couple of minutes now, with no increase in the memory resident size. A too many open files error is usually due to running out of file descriptors for network sockets. On my Linux machine the per-process limit for file descriptors defaults to 1024, and on my Mac the default is 256. You can see your current limit by running ulimit -a from the terminal. Each incoming socket occupies a file descriptor, as does every open connection to your database and every open file. When these run out, calls to accept() or to open files start failing and you get this error message. Memory profiling should help you find the leak. G -- Gregory Collins g...@gregorycollins.net (mailto:g...@gregorycollins.net) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto:Haskell-Cafe@haskell.org) http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] External system connections
Have you looked at Bryan O'Sullivan's resource-pool[1] library? I've used it with MySQL, Redis and Riak connection pooling. It's been robust and easy to use. It seems like it would be a good fit for your application. Cheers, Ozgun [1] http://hackage.haskell.org/package/resource-pool On Sun, Jul 10, 2011 at 3:04 PM, Richard Wallace rwall...@thewallacepack.net wrote: Hello all, I'm trying to understand how to properly structure a connection to an external system. I'm writing an application that processes requests (it's an IRC bot - ya, I've looked at lambabot but it's a bit beyond my current understanding and I'm really trying to learn this stuff and find the best way to do that is to write it myself) and sends requests to an external system, via SOAP. The SOAP requests should be sent on separate threads. The SOAP server requires an initial request for authentication be made to obtain a token used on subsequent requests. There are three ways I can structure this. One is to do the authentication with the SOAP server when the application starts up and just use that token for all subsequent requests. This will fall over if the token times out and I'd have to restart the application. Another way is to do authenticate with the server and get a new token for each request. This is obviously really inefficient. What I'd like to do is something a bit smarter. When a request to the SOAP server is to be made, if we have a token then we try and use it. If it fails, we reauthenticate and get a new token. When establishing a new token, other threads trying to send SOAP requests should block until a new token is available. There are other conditions that should be handled - such as an exponential back-off when the SOAP server can't be reached - but I feel like reestablishing the authentication token is really the key concern here. Unfortunately, I have no idea right now how to write this in Haskell. Any pointers would be awesome. Thanks! Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem building with Cabal + TH + Library with FFI to C++ via C Wrapper
Dear Cafe, I have recently run into a very annoying issue that I was not able to get around. I have a local package that makes use of the snappy compression library, which boasts bindings to C++ through a C wrapper. Everything compiles fine with ghc --make, but cabal install hits a wall when TemplateHaskell kicks in and decides to load the entire dependency chain. Here is the important bit of the error message I get after running cabal install Loading package snappy-0.2.0.0 ... linking ... ghc: /home/ubuntu/.cabal/lib/snappy-0.2.0.0/ghc-7.0.3/HSsnappy-0.2.0.0.o: unknown symbol `_ZTV8BSSource' ghc: unable to load package `snappy-0.2.0.0' I'm quite certain all the libs are in PATH. cabal install snappy installs fine when typed separately by itself and everything works fine (the program works, including compression via snappy) when I compile my local package with ghc --make. The problem only occurs on a Ubuntu 64-bit server, and I wasn't able to replicate the issue on my local OS X box. On my local, cabal install works just fine. I did find a previous note on Cafe with the exact same problem, but no solution was posted at the time: http://www.haskell.org/pipermail/haskell-cafe/2010-December/087748.html Any help is much appreciated. Cheers, Ozgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State of the Haskell Web Application Stack
Greetings all. I have been for quite some time trying to assess the feasibility of using Haskell in relatively large, high volume, high availability, long-running web application projects. I have enjoyed learning and using Haskell very much for the past year and I often find myself missing various language features when reasoning about alternatives like Ruby (on Rails). If I can identify the right set of tools for the job, I would really like to take the plunge and make Haskell my standard go-to language in web applications. Here are the couple of key questions that I wanted get your feedback on: Do you consider Haskell and its environment of libraries ready for prime time in web app development as defined above? What collection of libraries would you use in such an effort? What are the up and coming packages/technologies in Haskell-land you would watch out for? Also, here are some core requirements that I would define for such a project: Ease/speed of development in both back and front-ends, minimal boilerplate Extendability and flexibility in iterative development Robustness and reliability in production environment High performance Scalability Ability to interface with new technologies in the future: Cassandra, Redis, memcached, etc. Ease of implementing common/reusable features across web applications: user authentication, S3 file uploads, thumbnail/image handling, exception notifications, etc. In terms of libraries, I can think of a few key components (as pointed out by several others before) that one would need to arrange: Choice of server (happstack vs. alternatives) Templating (xhtml vs. file templates vs. newer efforts like BlazeHtml) Data/storage layer: HDBC vs. HaskellDB vs. others I know this is a common topic in Haskell-Cafe, but I have failed to identify conclusive opinions from experienced Haskellers out there in previous discussions. My apologies in advance if this is a blatantly redundant post. All the best, Ozgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
