[Haskell-cafe] Haskell (wiki) Logo license
Hi, We use the Haskell Logo in Fedora OS installer for the Haskell packages group: http://git.fedorahosted.org/git/?p=comps-extras.git;a=tree I trying to get the logo updated to the nice new logo designed by Jeff Wheeler: http://haskell.org/sitewiki/images/a/a8/Haskell-logo-60.png To do that we need to update the license in http://git.fedorahosted.org/git/?p=comps-extras.git;a=blob;f=COPYING Can someone tell me what the correct license for the above image file is? Is it the wiki license or something else? Thank you, Jens -- on behalf of Fedora Haskell SIG https://fedoraproject.org/wiki/Haskell_SIG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell (wiki) Logo license
It was posted to the Wiki, IIUC. Anything posted to the wiki is implicitly licensed by the wiki license: http://haskell.org/haskellwiki/HaskellWiki:Copyrights On 23 April 2010 07:10, Jens Petersen peter...@haskell.org wrote: Hi, We use the Haskell Logo in Fedora OS installer for the Haskell packages group: http://git.fedorahosted.org/git/?p=comps-extras.git;a=tree I trying to get the logo updated to the nice new logo designed by Jeff Wheeler: http://haskell.org/sitewiki/images/a/a8/Haskell-logo-60.png To do that we need to update the license in http://git.fedorahosted.org/git/?p=comps-extras.git;a=blob;f=COPYING Can someone tell me what the correct license for the above image file is? Is it the wiki license or something else? Thank you, Jens -- on behalf of Fedora Haskell SIG https://fedoraproject.org/wiki/Haskell_SIG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] London HUG domain expired
From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Denys Rtveliashvili On the side note, is London HUG still active? The website seems to be down... Looks like the London HUG domain (londonhug.net) registration has expired. Neil Bartlett was the registrant. Neil: do you plan to renew? Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: forkable-monad 0.1
David Anderson wrote: So, it seems that I am reinventing wheels that others have generalized better :-). That's fine, it's the expected result of launching and iterating, especially given my current command of Haskell. So I should now focus on reducing the reinvention. No worries, this MonadMorphIO thing is very recent, I just wanted to mention that it's applicable here as well. :) Most of the discussion that followed the message that you linked is currently beyond my understanding of category theory. However, I should probably go and talk to the maintainer of MonadCatchIO-* about extracting something like MonadMorphIO into a package, and making both their exception handling modules and this forking module reuse it. Sounds good; although I do think that the problem of making monads modular does not yet have a completely satisfactory answer, even with MonadMorphIO. But that should not deter from experimentation. :) Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: c2hs 0.16.2
All, c2hs version 0.16.2 is out and is available from hackage http://hackage.haskell.org/package/c2hs The only significant change in this release is that it works with ghc-6.12. Note that it is not currently possible to bind to C functions that use long double as the corresponding Haskell type (CLDouble) is not provided by the version of the base library that comes with ghc-6.12. See ghc ticket http://hackage.haskell.org/trac/ghc/ticket/3353 What is c2hs The c2hs tool assists in the development of Haskell bindings to C libraries. It extracts interface information from C header files and generates Haskell code with foreign imports and marshaling. The major advantages of using c2hs compared to writing foreign imports by hand (or using hsc2hs) are: * Cross-language type safety: C functions are imported with the correct Haskell types. * Saves time: boilerplate marshaling code is generated. Links = Home page: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ Bug tracker: http://hackage.haskell.org/trac/c2hs/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance reification in TH
I don't think you can: http://www.mail-archive.com/haskell-cafe@haskell.org/msg13057.html I've also looked at the reify function in the latest version of TH and there seems to be no way of reifying instances. /Jonas On 22 April 2010 22:33, Dmitry Olshansky olshansk...@gmail.com wrote: Hello cafe, Could you say can I determine in Template Haskell that datatype X has instance of class Y? Regards, Dmitry ___ 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] memory needed for SAX parsing XML
John Lato wrote: Another (additional) approach would be to encapsulate unsafeInterleaveIO within some routine and not let it go out into the wild. lazilyDoWithIO :: IO a - (a - b) - IO b It would use unsafeInterleave internally but catch all IO errors within itself. I wonder if this is a reasonable idea? Maybe it's already done? So the topic is shifting... doWithIO :: NFData b = IO a - (a - b) - IO b doWithIO m f = liftM (\a - let b = f a in b `deepseq` b) m It works (just stick it in a try block for error handling), but you need to write a lot of NFData instances. You also need to be careful that b is some sort of reduced structure, or you can end up forcing the whole file (or other data) into memory. I meant a different thing. In your example there is no unsafeInterleave at all. I think you mean that 'm' argument is supposed to be an unsafeInterleaved io action, like getContents, and deepseq'ing saves us from it hanging somewhere for a long time. Ok But I meant to have a routine that lets us use ordinary io actions in a lazy way, and restricting that 'hanging' within bounds of this routine. But having thought about it a little more I understood that it's impossible. Lazy io works now because unsafeInterleaveIO is sticked into getContents itself, and is called repeatedly (via recursion). Or at least I can think of this implementation, haven't looked into it. I realised that calling unsafeInterleaveIO for an ordinary io action will not make it run lazily. It will, still, run all-at-once, just not now, but later. So, to cope with it, I can think of exposing a little structure of an io action. Normally it's completely opaque. But if we knew where its recursion point lies, then we could control its course of execution. So, if we had something like type RecIO a = IO a - IO a and io actions were like getContents :: RecIO [Char] getContents rec = do c - readOneChar rest - rec return (c:rest) then we could either run them normally :: RecIO a - IO a normally r = r (normally r) or lazily :: RecIO a - IO a lazily r = unsafeInterleavIO $ r (lazily r) And lazilyDoWithIO :: RecIO a - (a - b) - IO b lazilyDoWithIO m f = do a - lazily m return $ f a Hmm, but then, we would have to take special care to not let it out of this function anyway... So here we come to deepSeq'ing you proposed. And anyway, instead of re-writing pure functions to become iteratees we will have to re-write io functions to adopt continuation passing style. Initially it looked better to me :) But with this approach we can run lazily any io action that has the form of RecIO. Also, we can interleave normally and lazily based on the time of day and other conditions :) It also doesn't help with other IO effects, e.g. writing output. I consider this one of the nicest features of iteratee-based processing. Can you clarify what's the problem with writing? I think I just haven't switched from the topic of gluing code. Because as for gluing code, type signature for io writing d - IO () is perfectly sufficient. -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Curl UTF8
В сообщении от 23 апреля 2010 02:36:07 Rickard Karlsson написал: Hi, I'm trying to download a file in UTF-8 with libcurl(1.3.5) and GHC 6.12: import Network.Curl u = http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt; main = curlGetString u [] = putStrLn . snd Which doesn't print the characters correctly. If i read the file from local storage with getFile it is displayed properly. I think curl knows nothing about encoding and convert one byte to one Char and getFile uses new IO which uses system locale to choose encoding. encodeString from utf8-string package could fix that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy-vs-strict, recursive IO (was: memory needed for SAX parsing XML)
(changed the thread title hoping to get some others to weigh in on the recursive I/O scheme presented here) From: Daniil Elovkov daniil.elov...@googlemail.com John Lato wrote: Another (additional) approach would be to encapsulate unsafeInterleaveIO within some routine and not let it go out into the wild. lazilyDoWithIO :: IO a - (a - b) - IO b It would use unsafeInterleave internally but catch all IO errors within itself. I wonder if this is a reasonable idea? Maybe it's already done? So the topic is shifting... doWithIO :: NFData b = IO a - (a - b) - IO b doWithIO m f = liftM (\a - let b = f a in b `deepseq` b) m It works (just stick it in a try block for error handling), but you need to write a lot of NFData instances. You also need to be careful that b is some sort of reduced structure, or you can end up forcing the whole file (or other data) into memory. I meant a different thing. In your example there is no unsafeInterleave at all. I think you mean that 'm' argument is supposed to be an unsafeInterleaved io action, like getContents, and deepseq'ing saves us from it hanging somewhere for a long time. Ok Yes, that's what I intended. I understand now that it isn't what you meant. But I meant to have a routine that lets us use ordinary io actions in a lazy way, and restricting that 'hanging' within bounds of this routine. But having thought about it a little more I understood that it's impossible. I think it's possible provided you have unsafeInterleaveIO and deepseq. As you discovered, to force evaluation through an unsafeInterleaveIO you need to fully evaluate data, and deepseq is the way to do so. Lazy io works now because unsafeInterleaveIO is sticked into getContents itself, and is called repeatedly (via recursion). Or at least I can think of this implementation, haven't looked into it. I realised that calling unsafeInterleaveIO for an ordinary io action will not make it run lazily. It will, still, run all-at-once, just not now, but later. Yes, exactly. unsafeInterleaveIO needs to be used recursively for getContents to function properly. So, to cope with it, I can think of exposing a little structure of an io action. Normally it's completely opaque. But if we knew where its recursion point lies, then we could control its course of execution. So, if we had something like type RecIO a = IO a - IO a and io actions were like getContents :: RecIO [Char] getContents rec = do c - readOneChar rest - rec return (c:rest) then we could either run them normally :: RecIO a - IO a normally r = r (normally r) or lazily :: RecIO a - IO a lazily r = unsafeInterleavIO $ r (lazily r) And lazilyDoWithIO :: RecIO a - (a - b) - IO b lazilyDoWithIO m f = do a - lazily m return $ f a Hmm, but then, we would have to take special care to not let it out of this function anyway... So here we come to deepSeq'ing you proposed. I think my understanding matches yours at this point, except I'm not sure I follow RecIO. Your getContents, for example, seems to only read one character. I think you mean something like this? recGetContents :: RecIO String recGetContents rec = do c - getChar ise - isEOF if ise then return [c] else liftM (c:) rec normally :: RecIO a - IO a normally = fix lazily :: RecIO a - IO a lazily rec = let f = unsafeInterleaveIO (rec f) in f This works, but I'm not sure that it accomplishes anything. (it doesn't work in ghci because EOF isn't sent through the terminal, but if you test for another character it works fine). And anyway, instead of re-writing pure functions to become iteratees we will have to re-write io functions to adopt continuation passing style. Initially it looked better to me :) Re-writing pure functions to be iteratees doesn't have to be hard; many of the provided iteratees have the same names as standard functions so a lot of the work can be done by just changing imports. But with this approach we can run lazily any io action that has the form of RecIO. Also, we can interleave normally and lazily based on the time of day and other conditions :) Originally I didn't see much use to this scheme, but I'm starting to change my mind. It would be nice for users to be able to control the evaluation of functions like getContents, hGetContents, etc., and this looks like it could be easier to maintain. It also doesn't help with other IO effects, e.g. writing output. I consider this one of the nicest features of iteratee-based processing. Can you clarify what's the problem with writing? I think I just haven't switched from the topic of gluing code. Because as for gluing code, type signature for io writing d - IO () is perfectly sufficient. The problem isn't with writing output per se, but with sequencing I/O effects with lazy data processing. If you wanted to write to a log file after processing each 100kbytes of a file, for example, doing so
Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
From: Barak A. Pearlmutter ba...@cs.nuim.ie ... An invalid comparison evaluating to _|_ is arguably more correct, but I personally find the idea of introducing more bottoms rather distasteful. Too late! NaN is pretty much the _|_ of IEEE Floating Point. That was certainly the intent of the IEEE standard, and is why NaN is so contagious. But they wanted to relax the usual strictness of their languages (FORTRAN, C) when this particular _|_ is around. So NaN is contagious through strict arithmetic (+, *, etc) like _|_. But it has strange behaviour with respect to comparison. In the context of Haskell, which does not have the issue of needing to relax strictness just for NaN, I think the right thing would be to have compare give _|_, and maybe also , , ==. After all, NaN is outside the carefully defined total ordering of all other IEEE floating point values including +/- Infinity. +1 John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
On 23/04/2010, at 01:34, Barak A. Pearlmutter wrote: I'd suggest that compare involving a NaN should yield error violation of the law of the excluded middle Please think of the poor guys trying to write high-performance code in Haskell! Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
On Fri, Apr 23, 2010 at 3:21 AM, Barak A. Pearlmutter ba...@cs.nuim.ie wrote: ... An invalid comparison evaluating to _|_ is arguably more correct, but I personally find the idea of introducing more bottoms rather distasteful. Too late! NaN is pretty much the _|_ of IEEE Floating Point. Yes, of course. But I don't have to like it... What annoys me is that, conceptually, the silently-propagating NaNs more strongly resemble Nothing, with the arithmetic functions lifted into Maybe, Applicative-style. Likewise, comparisons could sensibly be interpreted as returning Maybe Bool or Maybe Ordering. But there's no good way to work that into Haskell without making floats incredibly awkward to use. In the context of Haskell, which does not have the issue of needing to relax strictness just for NaN, I think the right thing would be to have compare give _|_, and maybe also , , ==. After all, NaN is outside the carefully defined total ordering of all other IEEE floating point values including +/- Infinity. The reason this makes me unhappy is that evaluating bottoms is a terrible way to deal with error conditions in pure code. It also makes using floating point values in generic code written for Ord dangerous, because the generic code won't (and can't) do anything to check whether calling compare will produce _|_ even if both arguments are already known to be fully evaluated. (By the stringent criteria some people are giving for allowing something to be Eq and Ord, Char would also be stripped of them, since after all Char includes _|_. Sort of.) The difference, of course, is that getting _|_ as a result of using _|_ is tolerable; getting _|_ as a result of using only non-_|_ values makes me sad. To my mind, the fewer ways there are to accidentally introduce _|_, the better. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unicode strings and runCommand / runProcess
Here is a very interesting little problem. ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :m System.Process Prelude System.Process runCommand echo привет ?...@825b This is a minimal test case for a bug reported in HSH at http://github.com/jgoerzen/hsh/issues#issue/1 It is not entirely clear to me what the behavior here should be. It seems inconsistent with the default behavior of System.IO to, apparently, just strip the bits higher than 0xFF. On the other hand, when it's OS commands we're talking about, it's not entirely clear to me if the default should be to encode in UTF-8. There should almost certainly be an *option* controlling this, and perhaps a version of runProcess that accepts ByteStrings. Thoughts? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The instability of Haskell libraries
It is somewhat of a surprise to me that I'm making this post, given that there was a day when I thought Haskell was moving too slow ;-) My problem here is that it has become rather difficult to write software in Haskell that will still work with newer compiler and library versions in future years. I have Python code of fairly significant complexity that only rarely requires any change due to language or library changes. This is not so with Haskel. Here is a prime example. (Name hidden because my point here isn't to single out one person.) This is a patch to old-locale: Wed Sep 24 14:37:55 CDT 2008 xx...@x. * Adding 'T' to conform better to standard This is based on information found at http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations diff -rN -u old-old-locale/System/Locale.hs new-old-locale/System/Locale.hs --- old-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 +++ new-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 @@ -79,7 +79,7 @@ iso8601DateFormat mTimeFmt = %Y-%m-%d ++ case mTimeFmt of Nothing - - Just fmt - ' ' : fmt + Just fmt - 'T' : fmt A one-character change. Harmless? No. It entirely changes what the function does. Virtually any existing user of that function will be entirely broken. Of particular note, it caused significant breakage in the date/time handling functions in HDBC. Now, one might argue that the function was incorrectly specified to begin with. But a change like this demands a new function; the original one ought to be commented with the situation. My second example was the addition of instances to time. This broke code where the omitted instances were defined locally. Worse, the version number was not bumped in a significant way to permit testing for the condition, and thus conditional compilation, via cabal. See http://bit.ly/cBDj3Q for more on that one. I could also cite the habit of Hackage to routinely get more and more pedantic, rejecting packages that uploaded fine previously; renaming the old exception model to OldException instead of introducing the new one with a different name (thus breaking much exception-using code), etc. My point is not that innovation in this community is bad. Innovation is absolutely good, and I don't seek to slow it down. But rather, my point is that stability has value too. If I can't take Haskell code written as little as 3 years ago and compile it on today's platform without errors, we have a problem. And there is a significant chunk of code that I work with that indeed wouldn't work in this way. I don't have a magic bullet to suggest here. But I would first say that this is a plea for people that commit to core libraries to please bear in mind the implications of what you're doing. If you change a time format string, you're going to break code. If you introduce new instances, you're going to break code. These are not changes that should be made lightly, and if they must be made (I'd say there's a stronger case for the time instances than the s/ /T/ change), then the version number must be bumped significantly enough to be Cabal-testable. I say this with a few hats. One, we use Haskell in business. Some of these are very long-term systems, that are set up once and they do their task for years. Finding that code has become uncompilable here is undesirable. Secondly, I'm a Haskell library developer myself. I try to maintain compatibility with GHC platform versions dating back at least a few years with every release. Unfortunately, this has become nearly impossible due to the number of untestable API changes out there. That means that, despite my intent, I too am contributing to the problem. Thoughts? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. -- Don jgoerzen: It is somewhat of a surprise to me that I'm making this post, given that there was a day when I thought Haskell was moving too slow ;-) My problem here is that it has become rather difficult to write software in Haskell that will still work with newer compiler and library versions in future years. I have Python code of fairly significant complexity that only rarely requires any change due to language or library changes. This is not so with Haskel. Here is a prime example. (Name hidden because my point here isn't to single out one person.) This is a patch to old-locale: Wed Sep 24 14:37:55 CDT 2008 xx...@x. * Adding 'T' to conform better to standard This is based on information found at http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations diff -rN -u old-old-locale/System/Locale.hs new-old-locale/System/Locale.hs --- old-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 +++ new-old-locale/System/Locale.hs 2010-04-23 13:21:31.381619614 -0500 @@ -79,7 +79,7 @@ iso8601DateFormat mTimeFmt = %Y-%m-%d ++ case mTimeFmt of Nothing - - Just fmt - ' ' : fmt + Just fmt - 'T' : fmt A one-character change. Harmless? No. It entirely changes what the function does. Virtually any existing user of that function will be entirely broken. Of particular note, it caused significant breakage in the date/time handling functions in HDBC. Now, one might argue that the function was incorrectly specified to begin with. But a change like this demands a new function; the original one ought to be commented with the situation. My second example was the addition of instances to time. This broke code where the omitted instances were defined locally. Worse, the version number was not bumped in a significant way to permit testing for the condition, and thus conditional compilation, via cabal. See http://bit.ly/cBDj3Q for more on that one. I could also cite the habit of Hackage to routinely get more and more pedantic, rejecting packages that uploaded fine previously; renaming the old exception model to OldException instead of introducing the new one with a different name (thus breaking much exception-using code), etc. My point is not that innovation in this community is bad. Innovation is absolutely good, and I don't seek to slow it down. But rather, my point is that stability has value too. If I can't take Haskell code written as little as 3 years ago and compile it on today's platform without errors, we have a problem. And there is a significant chunk of code that I work with that indeed wouldn't work in this way. I don't have a magic bullet to suggest here. But I would first say that this is a plea for people that commit to core libraries to please bear in mind the implications of what you're doing. If you change a time format string, you're going to break code. If you introduce new instances, you're going to break code. These are not changes that should be made lightly, and if they must be made (I'd say there's a stronger case for the time instances than the s/ /T/ change), then the version number must be bumped significantly enough to be Cabal-testable. I say this with a few hats. One, we use Haskell in business. Some of these are very long-term systems, that are set up once and they do their task for years. Finding that code has become uncompilable here is undesirable. Secondly, I'm a Haskell library developer myself. I try to maintain compatibility with GHC platform versions dating back at least a few years with every release. Unfortunately, this has become nearly impossible due to the number of untestable API changes out there. That means that, despite my intent, I too am contributing to the problem. Thoughts? -- John ___ 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] The instability of Haskell libraries
Don Stewart wrote: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. Yep, it's massive, and it's exciting. We seem to have gone from stodgy old language to scrappy hot one. Which isn't a bad thing at all. Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.org wrote: Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd really like to see hackage separated into a couple of separate instances based on general stability. I think it's wonderful that anyone can easily push a new app/library, and have it available to virtually everyone via cabal-install. However, that ability caters to a completely different use case than John's maintenance / production dev. scenario. Something akin to the Debian stable / unstable / testing division would be nice, so that production code can avoid dependencies on packages that are very quickly evolving, and so that those evolving packages have the freedom to move through a series of breaking API changes before settling on the right solution and moving to a more stable package store. --Rogan I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. -- John ___ 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] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen jgoer...@complete.orgwrote: A one-character change. Harmless? No. It entirely changes what the function does. Virtually any existing user of that function will be entirely broken. Of particular note, it caused significant breakage in the date/time handling functions in HDBC. Now, one might argue that the function was incorrectly specified to begin with. But a change like this demands a new function; the original one ought to be commented with the situation. My second example was the addition of instances to time. This broke code where the omitted instances were defined locally. Worse, the version number was not bumped in a significant way to permit testing for the condition, and thus conditional compilation, via cabal. See http://bit.ly/cBDj3Q for more on that one. This is of course in part due to a strength of cabal (remember that strengths and weaknesses tend to come together). Cabal discourages testing libraries/apis at configure time. The result is that version numbers need to encode this information. We don't (yet), have a tool to help detect when a change in version number is needed or what the next version should be. We leave this up to humans and it turns out, humans make mistakes :) Even once we have an automatic tool to enforce/check the package version policy, mistakes may still sneak in. I would expect the 'T' in the time format to be in this same category.** More about that below. I don't have a magic bullet to suggest here. But I would first say that this is a plea for people that commit to core libraries to please bear in mind the implications of what you're doing. If you change a time format string, you're going to break code. If you introduce new instances, you're going to break code. These are not changes that should be made lightly, and if they must be made (I'd say there's a stronger case for the time instances than the s/ /T/ change), then the version number must be bumped significantly enough to be Cabal-testable. While I haven't participated in the library proposal process myself, I was under the impression that Haskell has a fairly rigorous process in place for modifying the core libraries. Is the above change too small to for that process? Did that process simply fail here? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compressing GHC tarballs with LZMA
Out of curiousity, I downloaded a binary distribution for GHC-6.12.2, and tried compressing and recompressing it with bzip2 and lzma compression, using no command line arguments (all default parameters) file: http://haskell.org/ghc/dist/6.12.2/ghc-6.12.2-x86_64-unknown-linux-n.tar.bz2 bzip2 lzma size106M 72M compression time2:01 9:51 decompression time 0:25 0:12 the time is reported as minutes:seconds. At it default compression level, lzma was almost five times slower than bzip2, but it's approximately twice as fast when decompressing and produced a file nearly a third smaller. Given that many modern variants of the tar command support .tar.lzma files directly, and that both debian's dpkg and red hat's rpm now use lzma, maybe it's time to consider offering .tar.lzma as a download option for GHC's binary (and maybe source-code) bundles. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
1) Folks, what exactly is the situation with buildbots? 2) Easily available images for installing virtualized environments could also ameliorate the pain, no? wrt 1) It seems to me that in an ideal world you could have a candidate for uploading to hackage, but before uploading you could push a magic button and get a message within one hour stating whether this broke any packages on hackage. I start thinking about a (cloneable) community ec2 or slicehost server for buildbot -- 72 bucks a month should be doable for a community in the thousands. Does this make sense? Is it within the realm of possibility? What would it take to make it happen? I made a baby step in the direction of 2) with http://blog.patch-tag.com/2010/02/12/ec2-amis-for-gitit-happstack/ At the very least, what this means for me personally is that I (or anybody) can spin up a working box with gitit installed on it, for some past incarnation of gitit/happstack/haskell platform. Now, what happens when you attempt to cabal update cabal reinstall gitit -- I dunno. Very possibly breakage. But at least you get a working place to start from. I can see how this might apply to other pain points that I have less personal knowledge of, like glut (?) many others. thomas. 2010/4/23 Jason Dagit da...@codersbase.com: On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen jgoer...@complete.org wrote: A one-character change. Harmless? No. It entirely changes what the function does. Virtually any existing user of that function will be entirely broken. Of particular note, it caused significant breakage in the date/time handling functions in HDBC. Now, one might argue that the function was incorrectly specified to begin with. But a change like this demands a new function; the original one ought to be commented with the situation. My second example was the addition of instances to time. This broke code where the omitted instances were defined locally. Worse, the version number was not bumped in a significant way to permit testing for the condition, and thus conditional compilation, via cabal. See http://bit.ly/cBDj3Q for more on that one. This is of course in part due to a strength of cabal (remember that strengths and weaknesses tend to come together). Cabal discourages testing libraries/apis at configure time. The result is that version numbers need to encode this information. We don't (yet), have a tool to help detect when a change in version number is needed or what the next version should be. We leave this up to humans and it turns out, humans make mistakes :) Even once we have an automatic tool to enforce/check the package version policy, mistakes may still sneak in. I would expect the 'T' in the time format to be in this same category. More about that below. I don't have a magic bullet to suggest here. But I would first say that this is a plea for people that commit to core libraries to please bear in mind the implications of what you're doing. If you change a time format string, you're going to break code. If you introduce new instances, you're going to break code. These are not changes that should be made lightly, and if they must be made (I'd say there's a stronger case for the time instances than the s/ /T/ change), then the version number must be bumped significantly enough to be Cabal-testable. While I haven't participated in the library proposal process myself, I was under the impression that Haskell has a fairly rigorous process in place for modifying the core libraries. Is the above change too small to for that process? Did that process simply fail here? 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] Curl UTF8
Thanks, i just used decodeString. import Network.Curl import Codec.Binary.UTF8.String u = http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt; main = curlGetString u [] = putStrLn . decodeString . snd 2010/4/23 Khudyakov Alexey alexey.sklad...@gmail.com: В сообщении от 23 апреля 2010 02:36:07 Rickard Karlsson написал: Hi, I'm trying to download a file in UTF-8 with libcurl(1.3.5) and GHC 6.12: import Network.Curl u = http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt; main = curlGetString u [] = putStrLn . snd Which doesn't print the characters correctly. If i read the file from local storage with getFile it is displayed properly. I think curl knows nothing about encoding and convert one byte to one Char and getFile uses new IO which uses system locale to choose encoding. encodeString from utf8-string package could fix that. ___ 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] Proper Handling of Exceptional IEEE Floating Point Numbers
Please think of the poor guys trying to write high-performance code in Haskell! Like me? (Well, not in Haskell per-se, but in a pure functional context.) In all seriousness, I think it is reasonable when isNaN x for x C x == C x C C x C == x C x to all be False, for all floats C, even C=x, as a sort of efficient weak Bool bottom. This is what the FP hardware does --- so it is very efficient. But if you force the system to choose one of the three, which is what compare x C is doing, I think the result should be _|_. Because there is no way to choose, no reasonable Ordering to return. It is possible to write generic Ord n = code under these conditions, if you're careful to case out ,==, when you don't want a NaN to kill the computation, and when necessary handle the case that all three come out false. That's what good numeric programmers actually do. But compare giving a wrong Ordering is an invitation to get it wrong. --Barak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Thomas Hartman wrote: 1) Folks, what exactly is the situation with buildbots? If that's going to happen, then ideally we would have a way to run tests as part of the hackage acceptance process. For instance, the change to a time format string wouldn't break anything at compile time, but my HDBC test suite sure caught it. I can see difficulty with this, though, particularly with packages that are bindings to C libraries. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
jgoerzen: Don Stewart wrote: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. Yep, it's massive, and it's exciting. We seem to have gone from stodgy old language to scrappy hot one. Which isn't a bad thing at all. Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. Oh, the Platform has very strict standards about APIs, When a package may be added: http://trac.haskell.org/haskell-platform/wiki/AddingPackages and once it is in, only non-API changing bug fixes are during a minor series (12 month release cycle). On 12 month (major) releases, packages may modify their API under the current standard. We just haven't been around long enough to have much of an effect. The 2..5 year plan is that significant new stability is reintroduced via the HP. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode strings and runCommand / runProcess
В сообщении от 23 апреля 2010 21:44:29 John Goerzen написал: Here is a very interesting little problem. ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :m System.Process Prelude System.Process runCommand echo привет ?...@825b This is a minimal test case for a bug reported in HSH at http://github.com/jgoerzen/hsh/issues#issue/1 It is not entirely clear to me what the behavior here should be. It seems inconsistent with the default behavior of System.IO to, apparently, just strip the bits higher than 0xFF. On the other hand, when it's OS commands we're talking about, it's not entirely clear to me if the default should be to encode in UTF-8. There should almost certainly be an *option* controlling this, and perhaps a version of runProcess that accepts ByteStrings. It should just use system locale for encoding like System.IO do. FYI I just submitted bug to GHC trac: http://hackage.haskell.org/trac/ghc/ticket/4006 P.S. Haskell libraries aren't very well designed with respect to unicode and company. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On 23 April 2010 21:14, Jason Dagit da...@codersbase.com wrote: [Snip] We don't (yet), have a tool to help detect when a change in version number is needed or what the next version should be. We leave this up to humans and it turns out, humans make mistakes :) Hi All, Did anyone sign up to work on this as a GSOC project? Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Build problems (hsp, trhsx, ultimately Happstack)
I've had this problem too. I believe trhsx is installed by http://hackage.haskell.org/package/hsx So, you might need to -- upgrade hsx -- make sure that the upgraded trhsx executable is the one being executed by cabal install hsx (maybe deleting/temporarily moving other trhsx exes) thomas. 2010/4/22 Alexander Solla a...@2piix.com: Consider the following bash session: [ a...@kizaru:~/ ]$ which trhsx /home/ajs/.cabal/bin/trhsx [ a...@kizaru:~/ ]$ trhsx Usage: trhsx infile [outfile] [ a...@kizaru:~/ ]$ cabal install hsp Resolving dependencies... Configuring hsp-0.4.5... Preprocessing library hsp-0.4.5... Building hsp-0.4.5... ghc: could not execute: trhsx cabal: Error: some packages failed to install: hsp-0.4.5 failed during the building phase. The exception was: ExitFailure 1 Does anybody have any suggestions? I'm trying to install Happstack on Arch Linux (GHC 6.12.1). ~/.cabal/bin/ is in my path and trhsx runs. I've had this problem before, and I think I ran cabal as root for the HSP package. That's not working this time. I get the same failure. ___ 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] The instability of Haskell libraries
Thomas Hartman wrote: 1) Folks, what exactly is the situation with buildbots? If I'm not mistaken, the buildbots run *after* the package has been pushed to hackage. Thats already too too late. 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
Re: [Haskell-cafe] The instability of Haskell libraries
So the situation is 1) The buildbot will catch dependencies with compile errors, but only after the package has been pushed, and there is no easy way for packagers to check that this won't happen 2) There are many important packages that will pass a compile check but not a runtime check. Well, 2 seems like a hard problem to solve. But 1) could be solved by having a candidate snapshot hackage that can be cloned at will, and buildbotted against, no? 2010/4/23 Erik de Castro Lopo mle...@mega-nerd.com: Thomas Hartman wrote: 1) Folks, what exactly is the situation with buildbots? If I'm not mistaken, the buildbots run *after* the package has been pushed to hackage. Thats already too too late. 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] The instability of Haskell libraries
Don Stewart d...@galois.com writes: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. I think the release early, release often slogan is an affect on this as well: we encourage library writers to release once they have something that _works_ rather than waiting until it is perfect. The fact that we encourage smaller, more modular libraries over large monolithic ones also affects this. When considering Haskell vs Python, I wonder if the stability of Python's libraries is due to their relative maturity in that the fundamental libraries have had time to settle down. -- 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] The instability of Haskell libraries
Thomas Hartman tphya...@gmail.com writes: 1) The buildbot will catch dependencies with compile errors, but only after the package has been pushed, and there is no easy way for packagers to check that this won't happen Don't forget, there are valid reasons why hackage will sometimes fail to build a package: missing C libraries, wrong operating system, etc. Also, it would be nice if the build bot separates the building test from the haddock generation: I've seen quite a few packages where it builds successfully but then _haddock_ fails for one reason or another, thus breaking the package. -- 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] Unicode strings and runCommand / runProcess
John Goerzen jgoer...@complete.org writes: ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :m System.Process Prelude System.Process runCommand echo привет ?...@825b Are you arguing about IO-specific stuff like this, or for all non-ASCII Strings? -- 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] The instability of Haskell libraries
1) The buildbot will catch dependencies with compile errors, but only after the package has been pushed, and there is no easy way for packagers to check that this won't happen An alternate solution that can be done completely outside the hackage loop: Set up a server to poll the Source-Repository head of every hackage package that includes one in it's cabal file, then rerun the build any time a change is detected. This may be a good excuse to implement a pluggable continuous integration server in haskell too along the lines of what Hudson is for java... maybe an idea for the next GSoC Best, Keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Sorry, rerun the build means rebuild my package and all of my package's dependencies... On Fri, Apr 23, 2010 at 7:11 PM, Keith Sheppard keiths...@gmail.com wrote: 1) The buildbot will catch dependencies with compile errors, but only after the package has been pushed, and there is no easy way for packagers to check that this won't happen An alternate solution that can be done completely outside the hackage loop: Set up a server to poll the Source-Repository head of every hackage package that includes one in it's cabal file, then rerun the build any time a change is detected. This may be a good excuse to implement a pluggable continuous integration server in haskell too along the lines of what Hudson is for java... maybe an idea for the next GSoC Best, Keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Keith Sheppard keiths...@gmail.com writes: Set up a server to poll the Source-Repository head of every hackage package that includes one in it's cabal file, then rerun the build any time a change is detected. This may be a good excuse to implement a pluggable continuous integration server in haskell too along the lines of what Hudson is for java... maybe an idea for the next GSoC Several problems with this: 1) Is this going to support every VCS under the sun? 2) Not all head repositories are kept stable/buildable at all times. 3) I can see this getting expensive wrt space and network usage. -- 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] The instability of Haskell libraries
ivan.miljenovic: Don Stewart d...@galois.com writes: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. I think the release early, release often slogan is an affect on this as well: we encourage library writers to release once they have something that _works_ rather than waiting until it is perfect. The fact that we encourage smaller, more modular libraries over large monolithic ones also affects this. When considering Haskell vs Python, I wonder if the stability of Python's libraries is due to their relative maturity in that the fundamental libraries have had time to settle down. Note also that the Python core libraries model is what we are now just starting to do via the Haskell Platform. We're far more immature in that respect -- our stable, core, blessed library suite only just had its 2nd release. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode strings and runCommand / runProcess
Ivan Lazar Miljenovic wrote: John Goerzen jgoer...@complete.org writes: ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :m System.Process Prelude System.Process runCommand echo привет ?...@825b Are you arguing about IO-specific stuff like this, or for all non-ASCII Strings? I'm not sure I understand the question. I consider the behavior in System.IO to be well-documented. The behavior in System.Process is not documented at all. As I said, I'm not certain what the proper answer is, but not documenting what happens probably isn't it. Actually, the behavior of openFile when given a String with characters 0xFF is also completely undocumented. I am not sure what it does with that. It should probably be the same as runCommand, whatever it is. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Keith Sheppard keiths...@gmail.com writes: Set up a server to poll the Source-Repository head of every hackage package that includes one in it's cabal file, then rerun the build any time a change is detected. This may be a good excuse to implement a pluggable continuous integration server in haskell too along the lines of what Hudson is for java... maybe an idea for the next GSoC Several problems with this: 1) Is this going to support every VCS under the sun? We only need to support 3 or 4 to get 99% of the stuff on Hackage that lives in a VCS at all. 2) Not all head repositories are kept stable/buildable at all times. Perfect, meet better. Wait, no no - aw goddammit Perfect! Why do you do this every single time? *You* get to mop the floor this time. 3) I can see this getting expensive wrt space and network usage. Not really. I do much the same thing locally. Most repos hardly ever change. My own local repos - which includes all of patch-tag, a few GHCs, some intermediate builds, and whatnot - is about 4.5G. By my calculations* that's about 25¢ of hard-drive space. * http://forre.st/storage#sata -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
stephen.tetley: On 23 April 2010 21:14, Jason Dagit da...@codersbase.com wrote: [Snip] We don't (yet), have a tool to help detect when a change in version number is needed or what the next version should be. We leave this up to humans and it turns out, humans make mistakes :) Hi All, Did anyone sign up to work on this as a GSOC project? No, there were no proposals to work on PVP, though we have a good one for Hackage 2.0, and a good one for 'cabal test'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
What Gwern said for 1) and 3) 2) Not all head repositories are kept stable/buildable at all times. Isn't it bad practice to not have a buildable repo? In any case package owners would be free to use or ignore the data as they like, but I'm pretty sure it would be useful to many. Best, Keith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 4:49 PM, Don Stewart d...@galois.com wrote: ivan.miljenovic: Don Stewart d...@galois.com writes: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. I think the release early, release often slogan is an affect on this as well: we encourage library writers to release once they have something that _works_ rather than waiting until it is perfect. The fact that we encourage smaller, more modular libraries over large monolithic ones also affects this. When considering Haskell vs Python, I wonder if the stability of Python's libraries is due to their relative maturity in that the fundamental libraries have had time to settle down. Note also that the Python core libraries model is what we are now just starting to do via the Haskell Platform. We're far more immature in that respect -- our stable, core, blessed library suite only just had its 2nd release. Others on this thread have suggested continual integration build systems for *all* of hackage as a way to help with stability. I would argue that CI comes at a high human cost in terms of establishing and maintaining a proper build environment. It's a non-trivial commitment. This mention of the Haskell Platform makes me think: What if we reduced the scope from all of Hackage to just the Haskell Platform? I bet that's the sweet spot in terms of effort in and value produced. The HP is the set of packages that we want to endorse and promote as stable. Hackage on the other hand, is a huge repository of everything that exists. I think this also helps naturally create the unstable/testing/stable distinction of packages that was suggested in this thread as well. We can think of Hackage as unstable, the next unreleased version of the platform as testing, and the most recent stable platform release as stable. Hmm...But who would be willing to take on the hard, tedious, and time consuming work of maintaining the CI build system? I think for this build system effort to really take off a group of a few deadicated volunteers would be necessary. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
dagit: Hmm...But who would be willing to take on the hard, tedious, and time consuming work of maintaining the CI build system? I think for this build system effort to really take off a group of a few deadicated volunteers would be necessary. CI for the HP would be really easy, and extremely high value. As I said on Reddit, the community saw the instability problem 2 years ago, and launched the Haskell Platform effort to address this -- by requiring stability, with long release cycles. However, we're only a few months in, so the impact isn't being felt yet. Wait till we've had 10 years of versioning stability, like the Python core has. Any steps volunteers can take to ensure the HP is both stable and comprehensive, to build that solid foundation, will be greatly appreciated. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode strings and runCommand / runProcess
В сообщении от 24 апреля 2010 03:50:54 John Goerzen написал: Ivan Lazar Miljenovic wrote: John Goerzen jgoer...@complete.org writes: ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude :m System.Process Prelude System.Process runCommand echo привет ?...@825b Are you arguing about IO-specific stuff like this, or for all non-ASCII Strings? I'm not sure I understand the question. I consider the behavior in System.IO to be well-documented. The behavior in System.Process is not documented at all. As I said, I'm not certain what the proper answer is, but not documenting what happens probably isn't it. Actually, the behavior of openFile when given a String with characters 0xFF is also completely undocumented. I am not sure what it does with that. It should probably be the same as runCommand, whatever it is. Under unices file names are just array of bytes. There is no notion of encoding at all. It's just matter of interpretation of that array. There is a problem with FilePath data type. It's String actually but it should be abstract data type. There is relevant bug[1] on GHC trac. P.S. openFile truncates Chars. [1] http://hackage.haskell.org/trac/ghc/ticket/3307 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Keith Sheppard keiths...@gmail.com writes: What Gwern said for 1) and 3) 2) Not all head repositories are kept stable/buildable at all times. Isn't it bad practice to not have a buildable repo? In any case package owners would be free to use or ignore the data as they like, but I'm pretty sure it would be useful to many. I often work on different sub-parts of my packages; as such the interactions between them might not work. I don't see why I should ensure that it does, as the repository is a _development environment_ not a release. That said, there are some projects which generally _are_ buildable/usable for their repositories (e.g. XMonad and XMonad-Contrib). But these are large multi-person projects with moving targets; the stuff i write is being developed by myself only. -- 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] The instability of Haskell libraries
Gwern Branwen gwe...@gmail.com writes: On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: 2) Not all head repositories are kept stable/buildable at all times. Perfect, meet better. Wait, no no - aw goddammit Perfect! Why do you do this every single time? *You* get to mop the floor this time. Sense: this makes none. 3) I can see this getting expensive wrt space and network usage. Not really. I do much the same thing locally. Most repos hardly ever change. My own local repos - which includes all of patch-tag, a few GHCs, some intermediate builds, and whatnot - is about 4.5G. By my calculations* that's about 25¢ of hard-drive space. Yet we have enough complaints about code.haskell.org or hackage being down; you want _another_ possible machine to have people complaining about not being available? :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
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.orgwrote: Don Stewart wrote: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. Yep, it's massive, and it's exciting. We seem to have gone from stodgy old language to scrappy hot one. Which isn't a bad thing at all. Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. I feel your pain John... I try to use Haskell commercially, and sometimes run into things I'm either going to have to re-implement myself or wait for a fix and do some workaround. Luckily I *like* this language enough to care to do it, but it does present a bit of a problem when trying to break it into an ecosystem full of C/C++ and Java when I have to back-peddle to explain why something in this new language that's supposed to help solve some problems with the old languages is not a magic bullet. I think managers expect magic bullets and holy grails... sometimes they just end up with holy cow's (or other more interesting 4 letter words) instead. Dave -- John ___ 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] Bulk Synchronous Parallel
Peter Gammie wrote: Alice/ML is the place to look for this technology. http://www.ps.uni-saarland.de/alice/ The project may be dead (I don't know), but they did have the most sophisticated take on pickling that I've seen. It's an ML variant, with futures, running on top of the same platform used by Mozart/Oz of CTM fame. I seem to recall AliceML decided to move away from the Mozart/Oz runtime and develop their own (and that the project died shortly thereafter). I'd love to be wrong though, AliceML was very nice. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
Casey McCann wrote: The only correct solution would be to strip floating point types of their instances for Ord, Eq, and--therefore, by extension--Num. For some reason, no one else seems to like that idea. I can't imagine why... I'm not terribly opposed to it. But then, I've also defined classes for partial orderings[1] and for types containing transfinite values[2] in order to try to render floats usable. Also, don't forget some of the other bugs[3] in Hugs. [1] http://hackage.haskell.org/packages/archive/logfloat/0.12.1/doc/html/Data-Number-PartialOrd.html [2] http://hackage.haskell.org/packages/archive/logfloat/0.12.1/doc/html/Data-Number-Transfinite.html [3] http://hackage.haskell.org/packages/archive/logfloat/0.12.1/doc/html/Hugs-RealFloat.html -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
David Leimbach wrote: I think managers expect magic bullets and holy grails... sometimes they just end up with holy cow's (or other more interesting 4 letter words) instead. The good news for me, at least, is that *I* am the manager. (Yep, the company is small enough for that.) Actually, it should be stated that Haskell has still been a huge overall win for us, despite this. I by no means am contemplating a switch away from it because of this. It must be said, too, that our core library, while perhaps less stable than Python's, seems to me to be of a much higher quality. Or perhaps I'm jaded after 8 years (!) of working with imaplib.py... -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Ivan Lazar Miljenovic wrote: I think the release early, release often slogan is an affect on this as well: we encourage library writers to release once they have something that _works_ rather than waiting until it is perfect. The fact that we encourage smaller, more modular libraries over large monolithic ones also affects this. That is absolutely a good thing for many libraries here. I'm all in favor of low barriers to entry, and took advantage of such when I was starting out in this community. And I thank those many of you that have been around longer than I for putting up with my early code ;-) On the other hand, there are certain libraries that are very well-established and so popular that they are viewed by many as pretty much part of the language. Here I think of ones such as old-time or time, unix, bytestring, containers, etc. I think that if release early often is to be practiced with these, then there ought to be a separate stable branch that is made widely available, with development releases numbered differently (as the Linux kernel used to do) or only available via version control. When considering Haskell vs Python, I wonder if the stability of Python's libraries is due to their relative maturity in that the fundamental libraries have had time to settle down. It is a funny thing, because our fundamental libraries *have* had time to settle down, in a sense. In another sense, I must say that the innovations we have seen recently have been sorely needed and are unquestionably a good thing. The new time, exceptions, regex improvements, Unicode support in IO, etc. are all things of immediate practical benefit. I guess this is the price of failing to avoid success, to borrow Simon's phrase. And again, not entirely bad. Incidentally, I think that the introduction of the new time was handled very well. No old code had to change (except perhaps for the .cabal file), and yet new development could ignore old-time. My intent here wasn't to stir up some grand new level of QC. Just to request a bit more forethought before changing APIs. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
On 24/04/2010, at 07:15, Barak A. Pearlmutter wrote: In all seriousness, I think it is reasonable when isNaN x for x C x == C x C C x C == x C x to all be False, for all floats C, even C=x, as a sort of efficient weak Bool bottom. This is what the FP hardware does --- so it is very efficient. But if you force the system to choose one of the three, which is what compare x C is doing, I think the result should be _|_. Because there is no way to choose, no reasonable Ordering to return. It is possible to write generic Ord n = code under these conditions, if you're careful to case out ,==, when you don't want a NaN to kill the computation, and when necessary handle the case that all three come out false. That's what good numeric programmers actually do. But compare giving a wrong Ordering is an invitation to get it wrong. And yet a lot of generic code is written in terms of compare. Even deriving(Ord) only produces compare and relies on standard definitions for other methods. Don't get me wrong, I don't think the current situation is ideal (although it doesn't seem all that bad to me). But this change would have far-reaching implications for performance which ought to be evaluated before it can be seriously considered, in my opinion. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
Don Stewart wrote: Oh, the Platform has very strict standards about APIs, When a package may be added: http://trac.haskell.org/haskell-platform/wiki/AddingPackages That looks like a very solid document. Does it also apply when considering upgrading a package already in the platform to a newer version? Also, I notice that http://haskell.org/haskellwiki/Package_versioning_policy does not mention adding new instances, which caused a problem in the past. I would argue that this ought to mandate at least a new A.B.C version, if not a new A.B. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode strings and runCommand / runProcess
Khudyakov Alexey wrote: Actually, the behavior of openFile when given a String with characters 0xFF is also completely undocumented. I am not sure what it does with that. It should probably be the same as runCommand, whatever it is. Under unices file names are just array of bytes. There is no notion of encoding at all. It's just matter of interpretation of that array. Quite right. One must be able to pass binary strings, which contain anything except \0 and '/' to openFile. The same goes for runCommand. I am uncomfortable, for this reason, with saying that runCommand ought to re-encode in the system locale while openFile doesn't. It is preferable to drop characters than to drop the ability to pass arbitrary binary data. So I am not sure I agree with your stance in http://hackage.haskell.org/trac/ghc/ticket/4006 -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote: Don Stewart wrote: Oh, the Platform has very strict standards about APIs, When a package may be added: http://trac.haskell.org/haskell-platform/wiki/AddingPackages That looks like a very solid document. Does it also apply when considering upgrading a package already in the platform to a newer version? Also, I notice that http://haskell.org/haskellwiki/Package_versioning_policy does not mention adding new instances, which caused a problem in the past. I would argue that this ought to mandate at least a new A.B.C version, if not a new A.B. Adding or removing instances requires a new major version. See section 2: | If any entity was removed, or the types of any entities or the definitions of | datatypes or classes were changed, or instances were added or removed, | then the new A.B must be greater than the previous A.B. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
David Menendez wrote: On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote: Don Stewart wrote: Oh, the Platform has very strict standards about APIs, When a package may be added: http://trac.haskell.org/haskell-platform/wiki/AddingPackages That looks like a very solid document. Does it also apply when considering upgrading a package already in the platform to a newer version? Also, I notice that http://haskell.org/haskellwiki/Package_versioning_policy does not mention adding new instances, which caused a problem in the past. I would argue that this ought to mandate at least a new A.B.C version, if not a new A.B. Adding or removing instances requires a new major version. See section 2: | If any entity was removed, or the types of any entities or the definitions of | datatypes or classes were changed, or instances were added or removed, | then the new A.B must be greater than the previous A.B. Ah, sorry. Read it too quickly I guess. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
jgoerzen: David Menendez wrote: On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen jgoer...@complete.org wrote: Don Stewart wrote: Oh, the Platform has very strict standards about APIs, When a package may be added: http://trac.haskell.org/haskell-platform/wiki/AddingPackages That looks like a very solid document. Does it also apply when considering upgrading a package already in the platform to a newer version? Also, I notice that http://haskell.org/haskellwiki/Package_versioning_policy does not mention adding new instances, which caused a problem in the past. I would argue that this ought to mandate at least a new A.B.C version, if not a new A.B. Adding or removing instances requires a new major version. See section 2: | If any entity was removed, or the types of any entities or the definitions of | datatypes or classes were changed, or instances were added or removed, | then the new A.B must be greater than the previous A.B. Ah, sorry. Read it too quickly I guess. But remember, we don't have a tool to enforce or check the policy. And we didn't get a SoC applicant to design it. So there's a challenge to everyone. The tool-to-be is described here: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ In fact, I put it a #1 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
