[Haskell-cafe] minimizing jitter while maximizing throughput
Greeting, Jitter vs Throughput Scenario I have the following scenario: CPU with [C] cores concurrent program the 1 main thread uses OpenGL for animated visual output [W] worker threads uses FFI to lengthy numerical computations with the following desires : (J) minimize jitter: the 1 main thread needs to be responsive (T) maximize throughput: idle CPU time is a waste of time The problem is, I want both (J) and (T)! Benchmarks -- Some rough benchmarks from my 'production' implementation[1] where: jitter = stddev of actual period (target period = 40ms) idle = C - (real time) / (user+sys time)(cores used elsewhere) (but for example Xorg will use some time for the OpenGL output, etc) C W jitter idle 2 0 1.5ms 168% threaded RTS 2 1 1.9ms 65% 2 2 9.4ms 46% 2 3 13.3ms 37% For comparison, a (very) minimal GLUT program gives: 0.3ms threaded RTS 0.5ms non-threaded RTS Picking (J) over (T), then setting W=1 when C=2 gives best jitter Picking (T) over (J), then setting W=2 when C=2 gives best throughput Question What is the best way to re-structure the program to have both low jitter and high throughput? Options I am considering: 1. worker threads estimate the time needed to complete each job, and don't start a job if it is likely to break the deadline (bonus points if just those worker Haskell threads running on the same OS thread as the main Haskell thread need to pause) 2. change the foreign code to break jobs into smaller pieces, for example perhaps something like: worker :: IO (IO Bool) - IO () worker getJob = forever $ do job - getJob whileM_ job yield -- [2] instead of worker :: IO (IO ()) - IO () worker = forever . join 3. re-implement the foreign code in Haskell instead of C and hope that GHC makes the Haskell go as fast as GCC makes the C go 5. wait (for a long time) for a new RTS with: full pre-emption (including interrupting/resuming foreign code) user settable thread priorities (1) is a fun challenge (there may be PhDs awarded for less, I imagine) (2) isn't quite trivial, some scope for tuning subjob chunk size (3) is boring translation but could lead to interesting benchmarks even (especially?) if it fails to be as fast as C Which would you pick? Links - [1] http://hackage.haskell.org/package/mandulia [2] http://hackage.haskell.org/packages/archive/monad-loops/latest/doc/html/Control-Monad-Loops.html#v:whileM_ Thanks for any insight and advice, Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Chart package segfaults when rendering to window
bri...@aracnet.com writes: Seems to be ok rendering to png files. I'm using timeplot, which is based on Chart, to plot temperatures from my server in the attic (http://malde.org/~ketil/temp.png if you're curious :-). This runs from crontab, and I notice that I occasionally get mails saying tplot was Killed - possibly this is the same thing? I /am/ rendering to PNG, however. I'll see if I can tease out more information and/or a reproducible case. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: what's the best environment for haskell work?
rustom rustompm...@gmail.com writes: However I do have an issue regarding debian packaging. At first I installed ghc This brought in ghc6 ghc6-doc libbsd-dev libgmp3-dev libgmpxx4ldbl I also added haskell98-report haskell98-tutorial darcs Then I discovered haskell-platform. I was pleased to discover that the link took me directly to the squeeze repos so there is no version mismatch between haskell-platorm and squeeze. apt-getting haskell-platform gave me alex cabal-install happy haskell-platform libghc6-cgi-dev libghc6-deepseq-dev libghc6-glut-dev libghc6-haskell-src-dev libghc6-html-dev libghc6-http-dev libghc6-hunit-dev libghc6-network-dev libghc6-opengl-dev libghc6-parallel-dev libghc6-parsec2-dev libghc6-quickcheck2-dev libghc6-stm-dev libghc6-xhtml-dev However when trying to compile ghc from source I got an error that wanted ghc6-prof So I got that Why are you trying to compile GHC from source if you have a distribution package and are using that? Looking around in synaptic (gui for apt) I find that there are a large number of libghc-somethings that I still have not got. So then the question: Whats the real point of the haskell-platform package -- if specific libraries have to be got separately? That Platform is a starter kit; there are way too many Haskell packages available for every distribution to ship all of them! (Well, it's possible, but infeasible due to the number of packages that are distro/OS specific, are no longer maintained, etc.). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
Brandon S Allbery KF8NH allb...@ece.cmu.edu writes: Exactly. (I was being cagey because the first response was cagey, possibly suspecting a homework question although it seems like an odd time for it.) Why is it an odd time for it? Here in Australia (and presumably other countries in the southern hemisphere) this week will be the second or third week of semester... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem loading hxt
David Place d...@vidplace.com writes: Hello: I am trying to load hxt into my Haskell Platform 2010.2.0.0 on OSX. I get the following bizarre comment: David-Places-Mac-Mini:dev2 davidplace$ cabal install hxt Resolving dependencies... cabal: dependencies conflict: ghc-6.12.3 requires directory ==1.0.1.1 however directory-1.0.1.1 was excluded because ghc-6.12.3 requires directory ==1.0.1.2 I see that I have the older directory in my global package list and the newer one in my local list. Help? Thanks. David-Places-Mac-Mini:dev2 davidplace$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.3/package.conf.d [snip] directory-1.0.1.1 [snip] /Users/davidplace/.ghc/i386-darwin-6.12.3/package.conf.d [snip] directory-1.0.1.2 [snip] You should remove the version in your home directory (ghc-pkg unregister directory-1.0.1.2 --user) and refrain from using cabal upgrade in future. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
On Sat, 31 Jul 2010 17:30:54 -0400, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 16:58 , wren ng thornton wrote: Brandon S Allbery KF8NH wrote: michael rice wrote: Are you saying: [ head x ] - [ *thunk* ] and length [ *thunk* ] - 1, independent of what *thunk* is, even head [], i.e., *thunk* never needs be evaluated? Exactly. (I was being cagey because the first response was cagey, possibly suspecting a homework question although it seems like an odd time for it.) length not only does not look inside of the thunk, it *can't* look inside it; all it knows is that it has a list, it specifically does *not* know what that list can hold. So the only thing it can do is count the number of unknown somethings in the list. Not entirely true: stupidlyStrictLength :: [a] - Integer stupidlyStrictLength [] = 0 stupidlyStrictLength (x:xs) = x `seq` 1 + stupidlyStrictLength xs Given all the messes seq makes (hey, go behind the compiler's back and touch this arbitrary value of arbitrary type), I generally consider it to be unsafeSeq :) I would deeply in favor of renaming seq to unsafeSeq, and introduce a type class to reintroduce seq in a disciplined way. -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
Nicolas, I would deeply in favor of renaming seq to unsafeSeq, and introduce a type class to reintroduce seq in a disciplined way. There is a well-documented [1] trade-off here: Often, calls to seq are introduced late in a developing cycle; typically after you have discovered a space leak and figured out how to resolve it. Then you introduce a call to seq somewhere deep in a call chain. If seq were a class method, you would know have to work your way upward in the call chain to update all type signatures you had written there. Clearly, this is quite tedious. And then, almost just as often, you find out that actually you did not quite figure out how to resolve the space leak, because it's still there. So, you remove your freshly introduced call to seq and, indeed, work your way to the call chain again to remove all now superfluous class constraints from the type signatures. (By the way, this is typically the sort of task, IDEs with refactoring support excel at, but these are unfortunately not ubiquitous for Haskell yet.) More importantly, the type-class approach is flawed [2]. It assumes that all seq-related constraints can be read off from type variables, which is in fact not the case. Cheers, Stefan [1] Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. A history of Haskell: Being lazy with class. In Barbara G. Ryder and Brent Hailpern, editors, Proceedings of the Third ACM SIGPLAN History of Programming Languages Conference (HOPL-III), San Diego, California, USA, 9–10 June 2007, pages 1–55. ACM Press, 2007. http://doi.acm.org/10.1145/1238844.1238856 [2] Daniel Seidel and Janis Voigtländer. Taming selective strictness. In Stefan Fischer, Erik Maehle, and Rüdiger Reischuk, editors, INFORMATIK 2009 – Im Focus das Leben, Beiträge der 39. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 28. September – 2. Oktober, in Lübeck, volume 154 of Lecture Notes in Informatics, pages 2916–2930. GI, 2009.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Anyone here from New Zealand?
On 24 July 2010 09:58, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: On 24 Jul 2010, at 02:15, Tim Matthews wrote: Any of the haskellers here from NZ? I am in Wellington, Stephen is near Palmerston North. There are a few others elsewhere I think. I'm currently moving from the UK back to Wellington (well, Paraparaumu, but looking for work in Wgtn), so maybe will try to get in touch when we're there. Won't actually be there until September. There is this page, which has not been promoted in a while, I think: http://www.haskell.org/haskellwiki/Haskell_user_locations (Frappr seems to be dead, now.) Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Anyone here from New Zealand?
On Sun, Aug 1, 2010 at 9:18 PM, Alistair Bayley alist...@abayley.orgwrote: On 24 July 2010 09:58, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: On 24 Jul 2010, at 02:15, Tim Matthews wrote: Any of the haskellers here from NZ? I am in Wellington, Stephen is near Palmerston North. There are a few others elsewhere I think. I'm currently moving from the UK back to Wellington (well, Paraparaumu, but looking for work in Wgtn), so maybe will try to get in touch when we're there. Won't actually be there until September. There is this page, which has not been promoted in a while, I think: http://www.haskell.org/haskellwiki/Haskell_user_locations (Frappr seems to be dead, now.) Alistair So am I like the only haskeller in NZ that doesn't live in wellington? I'm stuck down here in Christchurch and traveling to wellington is not something I think I can do very often. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
Kevin Jardine kevinjard...@gmail.com wrote: Or is it possible to call a function in a monad and return a pure result? I think that is what the original poster was asking? I know that unsafePerformIO can do this, but I thought that was a bit of a hack. What most people forget is that in Haskell there is /no/ impure stuff involved. Even the IO monad is completely pure. The unsafePerformIO function breaks this rule, hence it's unsafe. Take as an example the following toy implementation of the 'cat' program: main :: IO () main = do args - getArgs case args of []- getContents = putStr files - mapM_ (readFile = putStr) files Here the domain-specific language, which is defined by the IO monad, is used to model a computation, which interacts with the outside world. All of this code is completely pure. But the DSL models computations, which may change the world during (=). Even the 'putStr' function is well referentially transparent. You can safely replace its application by its result. But note that its result is /not/ of type (), but of type 'IO ()'. Its result is an IO computation, i.e. a statement in the DSL defined by IO. As a clarifying example look at this function: printAndSquare :: Integer - IO Integer printAndSquare x = print x return (x^2) If you write 'printAndSquare 5' somewhere in your code, then you're calling the function 'printAndSquare' with the argument 5, which gives a result of type 'IO Integer'. You can safely replace any occurence of 'printAndSquare 5' by its result. The following four computations are equivalent: fmap read getLine = printAndSquare = print fmap read getLine = (\x - print x return (x^2)) = print do num - fmap read getLine square - printAndSquare num print square do num - fmap read getLine square - print num return (num^2) print square I have made direct use of the referential transparency rule. The result of applying the function 'printAndSquare' is not the same as the run-time result of the computation, which it expresses. Everything between (=) is pure. You're dealing with normal Haskell expressions here, and there is no magic involved, since IO is really just a language. You never get out of IO, because as soon as you do '-' in do-notation, you are giving the result of an IO computation a certain name. Instead of saying getContents = putStr you say do content - getContents putStr content The only difference is that you have named the result explicitly. Don't try to give this operational meaning. It's just a different way to express the same statement in the IO language. If you want to write a function, which returns a random boolean, the correct way to do it is one of these: randomBool :: RngState - (Bool, RngState) randomBool :: State RngState Bool randomBool :: IO Bool In fact, the two latter examples aren't even functions. They are simply values -- statements in a domain-specific language. For the second example it's the 'State RngState' language, for the third example it's the IO language. The following is also simply a value: randomBool :: Bool But it's really a value of type Bool. It's not a statement in some DSL. It's not a computation. It's not a function. Just a constant value. I'm still trying to understand how monads interact with types so I am interested in this as well. A monad is a type constructor, which is an instance of the Monad class and which obeys the monad laws. That's it. On Jul 30, 10:11 am, Kevin Jardine kevinjard...@gmail.com wrote: Oops, I should have written IO ByteString as the State stuff is only *inside* execState. But a monad none the less? Kevin On Jul 30, 9:59 am, Kevin Jardine kevinjard...@gmail.com wrote: The original poster states that the type of modifiedImage is simply ByteString but given that it calls execState, is that possible? Would it not be State ByteString? Kevin On Jul 30, 9:49 am, Anton van Straaten an...@appsolutions.com wrote: C K Kashyap wrote: In the code here - http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28393#a28393 If I look at the type of modifiedImage, its simply ByteString - but isn't it actually getting into and back out of the state monad? I am of the understanding that once you into a monad, you cant get out of it? Is this breaking the monad scheme? modifiedImage uses the execState function, which has the following type: execState :: State s a - s - s In other words, it applies a State monad value to a state, and returns a new state. Its entire purpose is to run the monad and obtain the resulting state. A monadic value of type State s a is a kind of delayed computation that doesn't do anything until you apply it to a state, using a function like execState or evalState. Once you do that, the computation runs, the monad is evaluated away,
[Haskell-cafe] Re: Can we come out of a monad?
Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 1 Aug 2010, at 11:43, Ertugrul Soeylemez wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. This is why we badly need a new term, say, io-pure. That means, neither has side effects, nor produces an action that when run by the runtime has side effects. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Chart package segfaults when rendering to window
On 27/07/10 21:37, bri...@aracnet.com wrote: I can run any of the examples from the home page that render to screen. the AM chart is the one I'm using. BTW, the AM chart has a bug. It does not include the proper color modules and needs a (opaque color) instead of just color. gtk2hs is 11 gtk+ C library appars to be (debian package) 2.20.1 Which version of the chart library are you running? Can you provide a small example that reproduces the seg fault? Note that there's a mailing list for this library: http://groups.google.com/group/haskell-charts I'm more likely to notice questions that arise there. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
On Sun, Aug 1, 2010 at 2:53 AM, Stefan Holdermans ste...@vectorfabrics.com wrote: Nicolas, I would deeply in favor of renaming seq to unsafeSeq, and introduce a type class to reintroduce seq in a disciplined way. There is a well-documented [1] trade-off here: Often, calls to seq are introduced late in a developing cycle; typically after you have discovered a space leak and figured out how to resolve it. Then you introduce a call to seq somewhere deep in a call chain. If seq were a class method, you would know have to work your way upward in the call chain to update all type signatures you had written there. Clearly, this is quite tedious. And then, almost just as often, you find out that actually you did not quite figure out how to resolve the space leak, because it's still there. So, you remove your freshly introduced call to seq and, indeed, work your way to the call chain again to remove all now superfluous class constraints from the type signatures. (By the way, this is typically the sort of task, IDEs with refactoring support excel at, but these are unfortunately not ubiquitous for Haskell yet.) That's a reasonable concern. I suppose that would be the reason for keeping unsafeSeq around if we do typeclassify seq. More importantly, the type-class approach is flawed [2]. It assumes that all seq-related constraints can be read off from type variables, which is in fact not the case. Could you provide an example (or a specific example or explanation in the paper) of what you mean by this? Luke Cheers, Stefan [1] Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. A history of Haskell: Being lazy with class. In Barbara G. Ryder and Brent Hailpern, editors, Proceedings of the Third ACM SIGPLAN History of Programming Languages Conference (HOPL-III), San Diego, California, USA, 9–10 June 2007, pages 1–55. ACM Press, 2007. http://doi.acm.org/10.1145/1238844.1238856 [2] Daniel Seidel and Janis Voigtländer. Taming selective strictness. In Stefan Fischer, Erik Maehle, and Rüdiger Reischuk, editors, INFORMATIK 2009 – Im Focus das Leben, Beiträge der 39. Jahrestagung der Gesellschaft für Informatik e.V. (GI), 28. September – 2. Oktober, in Lübeck, volume 154 of Lecture Notes in Informatics, pages 2916–2930. GI, 2009.___ 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] Anyone here from New Zealand?
On Aug 1, 2010, at 11:39 AM, Tim Matthews wrote: So am I like the only haskeller in NZ that doesn't live in wellington? I'm stuck down here in Christchurch and traveling to wellington is not something I think I can do very often. There must be a few more. Didn't Computer Science at Canterbury include haskell as one of the two main first year languages, at least up until the mid 90s?___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
On Sun, 1 Aug 2010 10:53:24 +0200, Stefan Holdermans ste...@vectorfabrics.com wrote: Nicolas, I would deeply in favor of renaming seq to unsafeSeq, and introduce a type class to reintroduce seq in a disciplined way. There is a well-documented [1] trade-off here: Often, calls to seq are introduced late in a developing cycle; typically after you have discovered a space leak and figured out how to resolve it. Then you introduce a call to seq somewhere deep in a call chain. If seq were a class method, you would know have to work your way upward in the call chain to update all type signatures you had written there. Clearly, this is quite tedious. And then, almost just as often, you find out that actually you did not quite figure out how to resolve the space leak, because it's still there. So, you remove your freshly introduced call to seq and, indeed, work your way to the call chain again to remove all now superfluous class constraints from the type signatures. (By the way, this is typically the sort of task, IDEs with refactoring support excel at, but these are unfortunately not ubiquitous for Haskell yet.) Only in the case where the type of the value being forced is not known, otherwise the class constraint get silently discarded. More importantly, the type-class approach is flawed [2]. It assumes that all seq-related constraints can be read off from type variables, which is in fact not the case. Indeed they give some account to the type class approach but not enough IMHO. Sure forcing functions is a tricky business and having a generic instance for functions is clearly not the solution (as they explain it with foldl vs foldl'''). However I absolutely do not buy their argument using as example a function f :: Eval (a - Int) = (a - Int) - (a - Int) - Int. They consider as an issue the fact that the type does not tell us on which argument seq is used. I think it is fine we may want a more precise type for it to get more properties out of it but it is not flawed. As much as we don't know where (==) is used given a function of type ∀ a. Eq a = [a] - [a]. Actually my point is that if we do not use any polymorphic primitive to implement a family of seq functions then it cannot be flawed. Indeed if you read type classes as a way to implicitly pass and pick functions then it cannot add troubles. Finally maybe we can simply forbidden the forcing of function (as we do with Eq). The few cases where it does matter will rescue to unsafeSeqFunction. Cheers, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
On Sun, Aug 1, 2010 at 11:29 AM, Nicolas Pouillard nicolas.pouill...@gmail.com wrote: Finally maybe we can simply forbidden the forcing of function (as we do with Eq). The few cases where it does matter will rescue to unsafeSeqFunction. What's the problem with class Eval a where seq :: a - t - t instance Eval b = Eval (a - b) where seq f = seq (f undefined) It would reduce at least to WHNF as unsafeSeq would. Does it compute more than WHNF? Hmmm, I see, if we had f :: Int - Int f _ = undefined Then my seq above would diverge while unsafeSeq wouldn't. Perhaps that instance would be a good compromise if we insist in not using 'unsafeSeq' to define it. Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Laziness question
On Sunday 01 August 2010 10:52:48 am Felipe Lessa wrote: On Sun, Aug 1, 2010 at 11:29 AM, Nicolas Pouillard nicolas.pouill...@gmail.com wrote: Finally maybe we can simply forbidden the forcing of function (as we do with Eq). The few cases where it does matter will rescue to unsafeSeqFunction. What's the problem with class Eval a where seq :: a - t - t instance Eval b = Eval (a - b) where seq f = seq (f undefined) It would reduce at least to WHNF as unsafeSeq would. Does it compute more than WHNF? Hmmm, I see, if we had f :: Int - Int f _ = undefined Then my seq above would diverge while unsafeSeq wouldn't. Perhaps that instance would be a good compromise if we insist in not using 'unsafeSeq' to define it. It also diverges for every strict function f. seq id x = seq (id undefined) x = seq undefined x = undefined -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
Congrats on the release. Just one humble suggestion: your email assumes that the reader already knows what Takusen is. Reading the email, all I can infer is that it has something to do with databases, because of the ODBC reference. The only link in the email also does nothing to explain, since it just links to a ball of code. The README there also assumes that I already know that I want Takusen, and so doesn't bother to explain what it does, only how to use it. Ideally, release announcements should always include a 1-sentence executive summary of what the project is, before heading on to what is new. Say, The Takusen team would like to announce the latest release of Takusen, 0.8.6. Takusen is insert description here, 'cos I'm still not quite sure. This is primarily a bugfix release... - Dave On Sat, Jul 31, 2010 at 8:10 PM, Jason Dagit da...@codersbase.com wrote: Hello, The Takusen team would like to announce the latest release of Takusen, 0.8.6. This is primarily a bug fix and test suite enhancement release. The most notable new feature is limited support for string encodings with ODBC. The full list of changes is included at the at the end of this announcement. = Interested in Takusen development? = Takusen is looking for a new long term maintainer. I have agreed to fill the role of maintainer for now, but we are seeking an enthusiastic individual with spare time and a desire to lead Takusen development. = How to get it = This release is available on hackage: cabal update cabal install Takusen The source code is available on code.haskell.org: darcs get http://code.haskell.org/takusen = New features = - Alistair Bayley: * Database/PostgreSQL/PGFunctions.lhs: show instance for UUID prints Word64s in hex. * Database/PostgreSQL/Enumerator.lhs: add UUID and marshaling functions. * Database/PostgreSQL/PGFunctions.lhs: add UUID and marshalling functions. * Database/ODBC/OdbcFunctions.hsc: add support for different String encodings. New functions to marshal to/from various encodings (Latin1, UTF8, UTF16), and bind/get functions changed to use these. - Daniel Corson * binary data with postgres = Bug fixes = - Alistair Bayley: * Database/ODBC/OdbcFunctions.hsc: fix bug in mkBindBufferForStorable for Nothing (null) case: pass -1 (sqlNullData) as value size. * Database/ODBC/OdbcFunctions.hsc: use sqlNullData in bindParamString Nothing case, rather than -1. A bit more descriptive. * Database/ODBC/Enumerator.lhs: store bind buffers in stmt object, so we retain reference to them for lifetime of statement. Destroy with statement (well, lose the reference). Should fix bind errors found by Jason Dagit. * Database/ODBC/Enumerator.lhs: Oracle only supports two transaction isolation levels (like Postgres). String output bind parameters have max size 8000 (we use 7999 because module OdbcFunctions adds one to the size). * Database/ODBC/OdbcFunctions.hsc: string parameters have different SQL data types when binding columns (SQL_CHAR) and parameters (SQL_VARCHAR). Oracle only supports two transaction isolation levels. * Database/PostgreSQL/PGFunctions.lhs: fix byteaUnesc and add byteaEsc. = Refactoring = - Jason Dagit: * update urls in cabal file - Alistair Bayley: * Takusen.cabal: fixed QuickCheck version spec. * Takusen.cabal: bump version to 0.8.6. * Database/ODBC/OdbcFunctions.hsc: makeUtcTimeBuffer: pass struct size as both buffer size and data size in call to mkBindBuffer. * Database/ODBC/OdbcFunctions.hsc: mkBindBufferForStorable calls mkBindBuffer (reduces duplicated code). * Database/ODBC/Enumerator.lhs: add instance for EnvInquiry to change session char encoding. * Database/ODBC/Enumerator.lhs: add comments to beginTransaction. * Database/Util.lhs: print printArrayContents, to match function name. * Database/PostgreSQL/Enumerator.lhs: expose byteaEsc and byteaUnesc. = New tests and changes to tests = - Alistair Bayley: * Database/ODBC/Test/OdbcFunctions.lhs: added testBindDouble to test Nothing (null) case for Storable types. * Database/ODBC/Test/OdbcFunctions.lhs: split transaction isolation level tests so there is one test per level. String marshaling tests use 0x10FF40 as max unicode codepoint, because that keeps Oracle happy. Max size for String parameter buffer is 7999 (SQL Server restriction). Don't bury errors raised by tests; print, but continue. Fix fixture cleanup bug in testBindOutput (dropped wrong procedure). * Database/ODBC/Test/Enumerator.lhs: suffix xxx to bindOutput test expected value. * Database/PostgreSQL/Test/PGFunctions.lhs: tests for UUID. * Database/PostgreSQL/Test/Enumerator.lhs: round-trip test for UUID. * Database/PostgreSQL/Test/PGFunctions.lhs: test select of UUID value. *
[Haskell-cafe] Re: what's the best environment for haskell work?
On Aug 1, 12:40 pm, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: rustom rustompm...@gmail.com writes: However I do have an issue regarding debian packaging. At first I installed ghc This brought in ghc6 ghc6-doc libbsd-dev libgmp3-dev libgmpxx4ldbl I also added haskell98-report haskell98-tutorial darcs Then I discovered haskell-platform. I was pleased to discover that the link took me directly to the squeeze repos so there is no version mismatch between haskell-platorm and squeeze. apt-getting haskell-platform gave me alex cabal-install happy haskell-platform libghc6-cgi-dev libghc6-deepseq-dev libghc6-glut-dev libghc6-haskell-src-dev libghc6-html-dev libghc6-http-dev libghc6-hunit-dev libghc6-network-dev libghc6-opengl-dev libghc6-parallel-dev libghc6-parsec2-dev libghc6-quickcheck2-dev libghc6-stm-dev libghc6-xhtml-dev However when trying to compile ghc from source I got an error that wanted ghc6-prof So I got that Why are you trying to compile GHC from source if you have a distribution package and are using that? Well... just stress testing my install but also I am interested in haskell and unicode (squiggol anyone?) so thought I'd muck around a bit in the sources. Maybe premature I guess :-) Actually I started with hugs (because I am a bit familiar with gofer sources) but now that it looks that the most action is on the ghc front I thought I'd look there. As of now I am getting comfortable with ghci inside emacs Looking around in synaptic (gui for apt) I find that there are a large number of libghc-somethings that I still have not got. So then the question: Whats the real point of the haskell-platform package -- if specific libraries have to be got separately? That Platform is a starter kit; there are way too many Haskell packages available for every distribution to ship all of them! (Well, it's possible, but infeasible due to the number of packages that are distro/OS specific, are no longer maintained, etc.). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
On Sun, Aug 1, 2010 at 9:10 AM, David Anderson d...@natulte.net wrote: Congrats on the release. Just one humble suggestion: your email assumes that the reader already knows what Takusen is. Reading the email, all I can infer is that it has something to do with databases, because of the ODBC reference. The only link in the email also does nothing to explain, since it just links to a ball of code. The README there also assumes that I already know that I want Takusen, and so doesn't bother to explain what it does, only how to use it. Sorry about that. The description from hackage: http://hackage.haskell.org/package/Takusen Takusen: Database library with left-fold interface, for PostgreSQL, Oracle, SQLite, ODBC. Takusen is a DBMS access library. Like HSQL and HDBC, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string). Takusen's unique selling point is safety and efficiency. We statically ensure all acquired database resources - such as cursors, connections, and statement handles - are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory, and so can handle queries returning millions of rows in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator. Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL. Ideally, release announcements should always include a 1-sentence executive summary of what the project is, before heading on to what is new. Say, The Takusen team would like to announce the latest release of Takusen, 0.8.6. Takusen is insert description here, 'cos I'm still not quite sure. This is primarily a bugfix release... Thanks, I'll remember that. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
Why are the Takusen module links on Hackage dead? I would also like to take this opportunity to request a Takusen tutorial and to thank you for this innovative library. -deech On Sun, Aug 1, 2010 at 12:59 PM, Jason Dagit da...@codersbase.com wrote: On Sun, Aug 1, 2010 at 9:10 AM, David Anderson d...@natulte.net wrote: Congrats on the release. Just one humble suggestion: your email assumes that the reader already knows what Takusen is. Reading the email, all I can infer is that it has something to do with databases, because of the ODBC reference. The only link in the email also does nothing to explain, since it just links to a ball of code. The README there also assumes that I already know that I want Takusen, and so doesn't bother to explain what it does, only how to use it. Sorry about that. The description from hackage: http://hackage.haskell.org/package/Takusen Takusen: Database library with left-fold interface, for PostgreSQL, Oracle, SQLite, ODBC. Takusen is a DBMS access library. Like HSQL and HDBC, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string). Takusen's unique selling point is safety and efficiency. We statically ensure all acquired database resources - such as cursors, connections, and statement handles - are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory, and so can handle queries returning millions of rows in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator. Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL. Ideally, release announcements should always include a 1-sentence executive summary of what the project is, before heading on to what is new. Say, The Takusen team would like to announce the latest release of Takusen, 0.8.6. Takusen is insert description here, 'cos I'm still not quite sure. This is primarily a bugfix release... Thanks, I'll remember that. Jason ___ 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] ANNOUNCE: Takusen 0.8.6
aditya.siram: Why are the Takusen module links on Hackage dead? Hmm. The links look fine: http://hackage.haskell.org/package/Takusen-0.8.6 this opportunity to request a Takusen tutorial and to thank you for this ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
I meant the links to the API docs. -deech [1] http://hackage.haskell.org/packages/archive/Takusen/0.8.6/doc/html/Database-ODBC-Enumerator.html On Sun, Aug 1, 2010 at 1:46 PM, Don Stewart d...@galois.com wrote: aditya.siram: Why are the Takusen module links on Hackage dead? Hmm. The links look fine: http://hackage.haskell.org/package/Takusen-0.8.6 this opportunity to request a Takusen tutorial and to thank you for this ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
A reasonable guess (I think, anyway): the reason is because support for ODBC, Oracle, Postgres etc isn't compiled in by default. You have to specify it with a flag with cabal install to get support for those things. But the reason they show up in API docs I would guess is because Haddock doesn't check constraints on what modules are 'exposed' given certain flags in the cabal file, it just looks over every 'exposed' module no matter what. In this case, it's not really a huge burden because I believe those modules each have almost identical interfaces, in particular they specify a 'connect' like function to get a database handle, and that's about all. The rest is common code under Database.Enumerator. On Sun, Aug 1, 2010 at 1:49 PM, aditya siram aditya.si...@gmail.com wrote: I meant the links to the API docs. -deech [1] http://hackage.haskell.org/packages/archive/Takusen/0.8.6/doc/html/Database-ODBC-Enumerator.html On Sun, Aug 1, 2010 at 1:46 PM, Don Stewart d...@galois.com wrote: aditya.siram: Why are the Takusen module links on Hackage dead? Hmm. The links look fine: http://hackage.haskell.org/package/Takusen-0.8.6 this opportunity to request a Takusen tutorial and to thank you for this ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- - Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
I think it is just the ODBC backend that didn't generate http://hackage.haskell.org/packages/archive/Takusen/0.8.6/doc/html/Database-Enumerator.html Likely because the required C libs are not on Hackage, so that backend wasn't built. aditya.siram: I meant the links to the API docs. -deech [1] http://hackage.haskell.org/packages/archive/Takusen/0.8.6/doc/html/ Database-ODBC-Enumerator.html On Sun, Aug 1, 2010 at 1:46 PM, Don Stewart d...@galois.com wrote: aditya.siram: Why are the Takusen module links on Hackage dead? Hmm. The links look fine: http://hackage.haskell.org/package/Takusen-0.8.6 this opportunity to request a Takusen tutorial and to thank you for this ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
Hi Jason, I've had my eye on the 'Takusen' approach for a while. In particular I think it's a wonderful idea to use the left-fold based interface. Takusen is also well supported and pretty stable, having been around for a while. Despite this, it seems to have a couple faults: * Few tutorials, aside from the Haddocks in Database.Enumerator * Very crufty old code in some sports (I see lots of references to GHC 6.6 and the 'extensible exceptions' changes in the cabal file among other places, which I believe we're all well beyond now. There also seems to be random tidbits that could be removed in favor of a library/removed because they're not necessary.) This should IMO all be removed under the argument Get a more recent GHC although people may disagree here. * It would be nice if we could make it depend on nicer libraries instead of rolling its own stuff - for example, we have Lato's excellent iteratee package, and Bas van Dijk has written a (IMO woefully underappreciated!) 'regions' package with encapsulate the lightweight monadic regions idea Oleg proposed. Of course, due to design, neither of these may work properly for Takusen's case, and if they did they would very likely facilitate API changes, but it's something I've been thinking about in the name of making the library smaller and more lightweight. These things were somewhat motivating me to perhaps write a small competitor library, but if Takusen is looking for a maintainer, it may certainly be more productive to remove some of the old cruft and modernize a bit of the existing code. Does anybody else have similar feelings? I am somewhat busy, but if someone else has some spare time to dedicate with me - either to coding or simply brainstorming right now - perhaps we could transform Takusen into a much more lightweight, better documented library. If it comes down to this I think I might be willing to maintain it, but I'd like feedback before just going out and wildly making changes to a venerable library like this. On Sat, Jul 31, 2010 at 1:10 PM, Jason Dagit da...@codersbase.com wrote: Hello, The Takusen team would like to announce the latest release of Takusen, 0.8.6. This is primarily a bug fix and test suite enhancement release. The most notable new feature is limited support for string encodings with ODBC. The full list of changes is included at the at the end of this announcement. = Interested in Takusen development? = Takusen is looking for a new long term maintainer. I have agreed to fill the role of maintainer for now, but we are seeking an enthusiastic individual with spare time and a desire to lead Takusen development. = How to get it = This release is available on hackage: cabal update cabal install Takusen The source code is available on code.haskell.org: darcs get http://code.haskell.org/takusen = New features = - Alistair Bayley: * Database/PostgreSQL/PGFunctions.lhs: show instance for UUID prints Word64s in hex. * Database/PostgreSQL/Enumerator.lhs: add UUID and marshaling functions. * Database/PostgreSQL/PGFunctions.lhs: add UUID and marshalling functions. * Database/ODBC/OdbcFunctions.hsc: add support for different String encodings. New functions to marshal to/from various encodings (Latin1, UTF8, UTF16), and bind/get functions changed to use these. - Daniel Corson * binary data with postgres = Bug fixes = - Alistair Bayley: * Database/ODBC/OdbcFunctions.hsc: fix bug in mkBindBufferForStorable for Nothing (null) case: pass -1 (sqlNullData) as value size. * Database/ODBC/OdbcFunctions.hsc: use sqlNullData in bindParamString Nothing case, rather than -1. A bit more descriptive. * Database/ODBC/Enumerator.lhs: store bind buffers in stmt object, so we retain reference to them for lifetime of statement. Destroy with statement (well, lose the reference). Should fix bind errors found by Jason Dagit. * Database/ODBC/Enumerator.lhs: Oracle only supports two transaction isolation levels (like Postgres). String output bind parameters have max size 8000 (we use 7999 because module OdbcFunctions adds one to the size). * Database/ODBC/OdbcFunctions.hsc: string parameters have different SQL data types when binding columns (SQL_CHAR) and parameters (SQL_VARCHAR). Oracle only supports two transaction isolation levels. * Database/PostgreSQL/PGFunctions.lhs: fix byteaUnesc and add byteaEsc. = Refactoring = - Jason Dagit: * update urls in cabal file - Alistair Bayley: * Takusen.cabal: fixed QuickCheck version spec. * Takusen.cabal: bump version to 0.8.6. * Database/ODBC/OdbcFunctions.hsc: makeUtcTimeBuffer: pass struct size as both buffer size and data size in call to mkBindBuffer. * Database/ODBC/OdbcFunctions.hsc: mkBindBufferForStorable calls mkBindBuffer (reduces duplicated code). * Database/ODBC/Enumerator.lhs: add instance for EnvInquiry to
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
On 8/1/10 12:12 PM, austin seipp wrote: Hi Jason, I've had my eye on the 'Takusen' approach for a while. In particular I think it's a wonderful idea to use the left-fold based interface. Takusen is also well supported and pretty stable, having been around for a while. I agree; in fact, I use it for all of my database needs. * It would be nice if we could make it depend on nicer libraries instead of rolling its own stuff - for example, we have Lato's excellent iteratee package, and Bas van Dijk has written a (IMO woefully underappreciated!) 'regions' package with encapsulate the lightweight monadic regions idea Oleg proposed. Of course, due to design, neither of these may work properly for Takusen's case, and if they did they would very likely facilitate API changes, but it's something I've been thinking about in the name of making the library smaller and more lightweight. Making the library depend on more external libraries will actually make it more heavyweight since it will require the user to install more libraries just in order to use Takusen. I'm not saying that this is a bad thing, but I wouldn't automatically count it as a disadvantage that one can install Takusen without requiring lots of other libraries to be installed first. It looks to me like the iteratee package wouldn't be a good fit for Takusen because (as far I understand it) it is designed for the use case of reading raw data where in particular the chunks might not be aligned with the records being processed, whereas Takusen is designed for reading in very structured data. The regions package might work, although there are problems with the way that it handles exceptions that has been discussed previously on this list. Finally, a disadvantage of changing Takusen to use these kinds of external libraries is that it could actually make it *harder* to understand how to use it, since first the user would have to understand the concepts involved in the external libraries. Again, I'm not saying that any of these issues automatically make it a bad idea to modify Takusen to use external libraries, just that the current approach works well and is (in my opinion) already relatively simple and straightforward, and it would be unfortunate if this were lost without a clear benefit. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
At the risk of seeming a bit defensive, I'll respond to some of these points... Despite this, it seems to have a couple faults: * Few tutorials, aside from the Haddocks in Database.Enumerator True. I put a bit of effort in to writing the docs in Database.Enumerator as a sort of tutorial, but it doesn't work as well as a properly written tutorial. Perhaps this would be better placed on the wiki, but it's quite a bit of work, assuming you would prefer something more than a simple cut-n-paste from the generated docs. * Very crufty old code in some spots (I see lots of references to GHC 6.6 and the 'extensible exceptions' changes in the cabal file among other places, which I believe we're all well beyond now. There also seems to be random tidbits that could be removed in favor of a library/removed because they're not necessary.) This should IMO all be removed under the argument Get a more recent GHC although people may disagree here. Maybe... We've put some effort into supporting older versions of ghc, mainly because quite a few distributions have quite long update cycles. If you're stuck in an environment (some unis, some employers?) where you are only allowed tools from the last stable distribution, you may well be many releases behind current ghc. If everyone agrees that 6.8 should be the oldest ghc we should test and support, then that does make things a little simpler. Are there any distros still shipping with ghc-6.6? BTW, I thought extensible-exceptions first shipped with 6.10. I don't think everyone is off 6.8 yet, so we'd want to keep that cabal switch in for a little longer if we intend to support 6.8. * It would be nice if we could make it depend on nicer libraries instead of rolling its own stuff - for example, we have Lato's excellent iteratee package, and Bas van Dijk has written a (IMO woefully underappreciated!) 'regions' package with encapsulate the lightweight monadic regions idea Oleg proposed. Of course, due to design, neither of these may work properly for Takusen's case, and if they did they would very likely facilitate API changes, but it's something I've been thinking about in the name of making the library smaller and more lightweight. iteratee and regions were both released well after Takusen was written. I think iteratee is just the same idea generalised to other types (Binary, ByteStrings, IO, etc). Perhaps it would help to use it and standardise the interface, but I haven't looked into it at all. It looks like it might be a considerable amount of work. Using regions might be more feasible (i.e. easier), but again I haven't considered it. Takusen's implementation also pre-dates regions considerably, and it works well for us as is. The actual implementation is very little code. That is, in both cases I don't see a big benefit from switching over to these libraries, considering the amount of work I think it would take (esp for iteratee). There are plenty of other things on the to-do list which I think should take higher priority e.g. - splitting Takusen into multiple packages: a core interface, and then separate packages for each backend. - better docs, as you've requested. - support for blobs/clobs As Gregory just pointed out, using other libs adds further dependencies to Takusen. One of our earlier goals was to make it easy to install, which in the days before cabal meant fewer dependencies on external libs. cabal now mitigates that concern considerably, so perhaps we should relax more now when it comes to using external libs. Here is the list of things that I can think of right now which are currently internalised in Takusen, but which are also implementated in hackage libs: - extensible exceptions - EMonadIO - regions - iteratee I'm not saying the way it is now is right or best, but it got there through various historical decisions, which were made with the best information available at the time, and in environments that differ from the current. Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
Using the generous resources of community.haskell.org I've created a mailing list for takusen discussions. I encourage interested parties to join that list and maybe move the takusen design discussion there: http://projects.haskell.org/cgi-bin/mailman/listinfo/takusen I've added the list in the CC. I've also created a trac instance for wiki/bug tracking: http://trac.haskell.org/takusen/report My comments are below. On Sun, Aug 1, 2010 at 12:55 PM, Alistair Bayley alist...@abayley.orgwrote: At the risk of seeming a bit defensive, I'll respond to some of these points... Despite this, it seems to have a couple faults: * Few tutorials, aside from the Haddocks in Database.Enumerator True. I put a bit of effort in to writing the docs in Database.Enumerator as a sort of tutorial, but it doesn't work as well as a properly written tutorial. Perhaps this would be better placed on the wiki, but it's quite a bit of work, assuming you would prefer something more than a simple cut-n-paste from the generated docs. More tutorials is a great idea. Perhaps I can write a few simple 'how to get started' examples and post them on my blog. Although, the wiki is a nice place too. Any preference? If I post it on my blog it might be easier to control the formatting and voice, but if it's on the wiki other can update it and it's in a central location. * Very crufty old code in some spots (I see lots of references to GHC 6.6 and the 'extensible exceptions' changes in the cabal file among other places, which I believe we're all well beyond now. There also seems to be random tidbits that could be removed in favor of a library/removed because they're not necessary.) This should IMO all be removed under the argument Get a more recent GHC although people may disagree here. Maybe... We've put some effort into supporting older versions of ghc, mainly because quite a few distributions have quite long update cycles. If you're stuck in an environment (some unis, some employers?) where you are only allowed tools from the last stable distribution, you may well be many releases behind current ghc. If everyone agrees that 6.8 should be the oldest ghc we should test and support, then that does make things a little simpler. Are there any distros still shipping with ghc-6.6? This same issues comes up fairly often on the darcs-users mailing list. My understanding of the way things are handled there, is that if there is ever a good reason to drop support for a version of GHC then the person who wants to drop support is supposed to look and see what is in Debian stable. If debian stable is still covered after the proposed changes then they are accepted automatically. If Debian stable would not be covered, then there is a discussion to reach consensus. The reasons it works are: a) support is dropped lazily when there is a real demand to do so, instead of artificially; b) letting people discuss it case-by-case allows the decision to be made with full context. BTW, I thought extensible-exceptions first shipped with 6.10. I don't think everyone is off 6.8 yet, so we'd want to keep that cabal switch in for a little longer if we intend to support 6.8. * It would be nice if we could make it depend on nicer libraries instead of rolling its own stuff - for example, we have Lato's excellent iteratee package, and Bas van Dijk has written a (IMO woefully underappreciated!) 'regions' package with encapsulate the lightweight monadic regions idea Oleg proposed. Of course, due to design, neither of these may work properly for Takusen's case, and if they did they would very likely facilitate API changes, but it's something I've been thinking about in the name of making the library smaller and more lightweight. iteratee and regions were both released well after Takusen was written. I think iteratee is just the same idea generalised to other types (Binary, ByteStrings, IO, etc). Perhaps it would help to use it and standardise the interface, but I haven't looked into it at all. It looks like it might be a considerable amount of work. I think that iteratees are a wonderful concept and I like them, but...I'm not terribly fond of the iteratee package. I find that with it's full generality that it is somewhat difficult to program with. I've actually found it easier to 'roll your own' when I need iteratees. My preference would be to switch to some later iteration of the iteratee design. I believe John Lato is currently working on a new API. Using regions might be more feasible (i.e. easier), but again I haven't considered it. Takusen's implementation also pre-dates regions considerably, and it works well for us as is. The actual implementation is very little code. I haven't looked at the regions package either, but it certainly sounds like a good idea to switch to it. That is, in both cases I don't see a big benefit from switching over to these libraries,
[Haskell-cafe] Re: ANNOUNCE: Takusen 0.8.6
On Sat, Jul 31, 2010 at 11:10 AM, Jason Dagit da...@codersbase.com wrote: = Interested in Takusen development? = Takusen is looking for a new long term maintainer. I have agreed to fill the role of maintainer for now, but we are seeking an enthusiastic individual with spare time and a desire to lead Takusen development. Some people have asked about the maintainer role. Let me elaborate on that. The maintainer will oversee the project and steer development. For example, this might include splitting up the duties of the maintainer role into more specific jobs such as release manager, wiki gardner, mailing list moderator, etc. More details about these responsibilities below. Some background reading on the topic: * I recommend reading Karl Fogel's Producing Open Source Software as it covers the entire topic of contributing and running projects, and it's available on the web: http://producingoss.com/en/index.html * Wikipedia's description of a Release manager (not the same as a maintainer, but the roles do overlap on many projects): http://en.wikipedia.org/wiki/Release_management Initially I expect the maintainer will need to take on the following responsibilities: * Marketing. Getting the word out about Takusen releases, ensuring users know when to use it and when not to use it, dispelling myths about takusen, etc. * Growing a larger development team (sometimes considered part of marketing). * Fleshing out the infrastructure provided by community.haskell.org (we have a wiki, bug tracker, mailing list, and web site now, but no users or content yet). * Plan the next release. This will probably involve prioritizing suggestions, bug fixes, new features, and finding people to do the work. * Facilitate the next release, eg., make sure release is stable, tag it, write release announcement and upload to hackage. * Setup automated build tests. Takusen has a lot of tests, now we need to run them automatically on all the platforms and databases that takusen supports. * Review patches sent by contributors, or delegate/nominate patch reviewers. If you'd like to study other haskell projects that set good examples for maintainership, I recommend looking at GHC, darcs, and xmonad. There are probably others that would do quite well as examples, but I'm not personally familiar with them. I think you'll notice that in each case, the duties are distributed and decisions are made in IRC or on the mailing list. As for skills that you should have? Being motivated and eager to get up to speed is more important than raw Haskell ability. The current team, including Alistair and Oleg, should continue to be available to assist with technical issues. Communication skills, leadership skills, and the ability to ground your judgements in fact are probably the most important skills overall. Most importantly, don't feel intimidated by the above list. I'm describing all the duties I can think of. Also, I'll be around to help you learn the ropes and get going while you're new. It can be a lot of work, which is why it's important to appoint lieutenants. Successful maintainers tend to be good at documenting the tasks to be done, creating roles, and finding motivated individuals to take on those roles and tasks. Ideally things are so well document that contributors can trade roles as spare time waxes and wanes for people. I hope that helps! Don't hesitate to ask questions. Jason PS I've CC'd the new takusen mailing list, but I don't think it's working yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
On Sun, Aug 1, 2010 at 6:58 PM, Jason Dagit da...@codersbase.com wrote: This same issues comes up fairly often on the darcs-users mailing list. My understanding of the way things are handled there, is that if there is ever a good reason to drop support for a version of GHC then the person who wants to drop support is supposed to look and see what is in Debian stable. If debian stable is still covered after the proposed changes then they are accepted automatically. If Debian stable would not be covered, then there is a discussion to reach consensus. The reasons it works are: a) support is dropped lazily when there is a real demand to do so, instead of artificially; b) letting people discuss it case-by-case allows the decision to be made with full context. Do you know if they test on GHC 6.8? Or do they just avoid extensions and hope it works? =) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Takusen 0.8.6
On Sun, Aug 1, 2010 at 5:11 PM, Felipe Lessa felipe.le...@gmail.com wrote: On Sun, Aug 1, 2010 at 6:58 PM, Jason Dagit da...@codersbase.com wrote: This same issues comes up fairly often on the darcs-users mailing list. My understanding of the way things are handled there, is that if there is ever a good reason to drop support for a version of GHC then the person who wants to drop support is supposed to look and see what is in Debian stable. If debian stable is still covered after the proposed changes then they are accepted automatically. If Debian stable would not be covered, then there is a discussion to reach consensus. The reasons it works are: a) support is dropped lazily when there is a real demand to do so, instead of artificially; b) letting people discuss it case-by-case allows the decision to be made with full context. Do you know if they test on GHC 6.8? Or do they just avoid extensions and hope it works? =) They use a farm of buildbots to test: http://buildbot.darcs.net/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal LD errors
So I'm getting some weird linking errors from cabal-install when doing `cabal configure cabal build` ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o But cabal doesn't quit with an error code or anything. Doing `ghc --make Data/Monoid/Ord/Argmax.hs` works just fine without warnings. Anyone know what could cause them, or how to fix it? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal LD errors
Excerpts from wren ng thornton's message of Sun Aug 01 21:06:07 -0400 2010: So I'm getting some weird linking errors from cabal-install when doing `cabal configure cabal build` Hello Wren, Could you run cabal with -v3 or so and attach the output somewhere? Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal LD errors
wren ng thornton w...@freegeek.org writes: So I'm getting some weird linking errors from cabal-install when doing `cabal configure cabal build` ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o But cabal doesn't quit with an error code or anything. Doing `ghc --make Data/Monoid/Ord/Argmax.hs` works just fine without warnings. Anyone know what could cause them, or how to fix it? If this is on OSX, my understanding is that these messages are harmless. http://hackage.haskell.org/trac/ghc/ticket/2578 Apparently this has been fixed for 6.12, if you have a later version and it's still happening it's a regression and you should re-open the ticket. Cheers, G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: parsec2 - a fork or parsec circa 2.1
Hello, I would like to announce the parsec2 package, which is a maintained fork of the parsec library as of version 2.1.0.1. This project is for folks who would like to use the simpler interface and fewer extensions relative to parsec-3.0+, but don't want to rely on an old version of a package on hackage. Parsec is designed from scratch as an industrial-strength parser library. It is simple, safe, well documented (on the package homepage), has extensive libraries and good error messages, and is also fast. Changes relative to parsec-2.1.0.1: * Added haddocks done for parsec-3 * in Parsec.Token, sort names after accounting for case sensitivity, not before from: Greg Fitzgerald When I say that I'm maintaining the parsec2 package, that means I am accepting bugfix patches and doing work to ensure that the package builds on the current version of GHC. Patches are welcome to support building on any other Haskell implementations. Any inovations in the field of parser combinators will be happening in other venues. Documentation patches are also welcome. I'm not quite sure what to do about the fact that both parsec2 and mainline parsec provide modules of the same name. If there's motion towards using the parsec2 package, we might be able to deprecate and then retire the compatibility layer provided by parsec-3.*. Links: On Hackage: http://hackage.haskell.org/package/parsec2-1.0.0 Source repository: darcs get http://code.haskell.org/parsec2/parsec2 Report a bug: http://trac.haskell.org/parsec2/newticket Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
Thomas Davie tom.da...@gmail.com wrote: On 1 Aug 2010, at 11:43, Ertugrul Soeylemez wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. This is why we badly need a new term, say, io-pure. That means, neither has side effects, nor produces an action that when run by the runtime has side effects. Why? We have terms like 'IO computation' or 'monadic value', and that should hit the nail on the head. People should learn what type of computations the IO monad models, and generally they learn that quite early. I have the impression that to talk about something being impure in Haskell confuses people more than anything else. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 1 August 2010 20:43, Ertugrul Soeylemez e...@ertes.de wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. At code-writing time, yes; at run-time there are side effects... In terms of what a function does, is readFile actually pure? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? In terms of what a function does, is readFile actually pure? -- Ivan Lazar Miljenovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 1 August 2010 20:43, Ertugrul Soeylemez e...@ertes.de wrote: There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. At code-writing time, yes; at run-time there are side effects... In terms of what a function does, is readFile actually pure? Yes, it's a pure function. But it models a computation, which changes the world's state. If you happen to get a real Haskell code representation of 'readFile', you can safely replace its call by its body without messing things up (applying the usual lambda reduction rules, of course). Note that a function is something of type 'a - b' for some type a and some type b. The result of the function 'readFile' is not of type String, but of type IO String. For the same file name parameter, it always gives the same result computation. It is really questionable whether it makes sense to use the term impure for the computations, which are modelled by IO. I don't think we have a useful theoretical foundation for what impure means in this context. You can model IO as State Universe (regardless of the problems with that model), in which case even the computations are perfectly pure and representable as Haskell functions. In fact the Clean language uses this model, whereas Haskell leaves this abstract. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 2 August 2010 14:47, Lyndon Maydwell maydw...@gmail.com wrote: I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? That is what I believe Ertugrul is aiming at, but I believe that that is a rule-lawyering interpretation in trying to argue that all of Haskell is pure. We could use this same argument to state that _all_ programming languages are pure, as they too have implict World state variables that get passed around. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal LD errors
Gregory Collins wrote: wren ng thornton w...@freegeek.org writes: So I'm getting some weird linking errors from cabal-install when doing `cabal configure cabal build` ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o But cabal doesn't quit with an error code or anything. Doing `ghc --make Data/Monoid/Ord/Argmax.hs` works just fine without warnings. Anyone know what could cause them, or how to fix it? If this is on OSX, my understanding is that these messages are harmless. http://hackage.haskell.org/trac/ghc/ticket/2578 Apparently this has been fixed for 6.12, if you have a later version and it's still happening it's a regression and you should re-open the ticket. It's OSX 10.5.8 and GHC 6.12.1 as packaged in haskell-platform-2010.1.0.1-i386.dmg It looks like that bug might only be fixed in 6.12.2? I dunno, Trac really needs some way of telling which non-HEAD version finally includes the fixes that close a ticket. I can never figure that out from reading the ticket... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
That's true I suppose, although since there are no implicit parameters in haskell, it really has to be a DSL in implementation, rather than just theory right? On Mon, Aug 2, 2010 at 12:51 PM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 2 August 2010 14:47, Lyndon Maydwell maydw...@gmail.com wrote: I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? That is what I believe Ertugrul is aiming at, but I believe that that is a rule-lawyering interpretation in trying to argue that all of Haskell is pure. We could use this same argument to state that _all_ programming languages are pure, as they too have implict World state variables that get passed around. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 2 August 2010 14:59, Lyndon Maydwell maydw...@gmail.com wrote: That's true I suppose, although since there are no implicit parameters in haskell, it really has to be a DSL in implementation, rather than just theory right? http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/other-type-extensions.html#implicit-parameters You were saying? ;p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
Lyndon Maydwell maydw...@gmail.com wrote: I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? Yes, but some people argue that there are problems with this model. For example it doesn't really catch the forkIO concept and the interactions between threads. For this model, forkIO is just a side effect like everything else and if you takeMVar a value, then it comes from the world, which isn't very useful. But don't bother, because that model works most of the time. Personally I have switched from your model to the model of an embedded DSL. It's a simpler mental model and doesn't interpret too much. You just get some primitive IO computations and a number of combinators to stick them together. That's it. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Can we come out of a monad?
Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 2 August 2010 14:47, Lyndon Maydwell maydw...@gmail.com wrote: I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? That is what I believe Ertugrul is aiming at, but I believe that that is a rule-lawyering interpretation in trying to argue that all of Haskell is pure. We could use this same argument to state that _all_ programming languages are pure, as they too have implict World state variables that get passed around. Given the definition of a Haskell function, Haskell is a pure language. The notion of a function in other languages is not: int randomNumber(); The result of this function is an integer. You can't replace the function call by its result without changing the meaning of the program. In Haskell, this wouldn't even be a function. It would be a computation, i.e. simply a value. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
