From jeremy at n-heptane.com Fri Jan 1 12:16:49 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri Jan 1 11:50:00 2010 Subject: ANN: Happstack 0.4.1 In-Reply-To: <4B3B3B6B.3010102@gmail.com> References: <54342.1261377119@n-heptane.com> <694519c50912211933p257746abgca00c46a443264ac@mail.gmail.com> <4B3B3B6B.3010102@gmail.com> Message-ID: Hello Simon, I have seen several manifestations of this issue now. I filed a report here: http://hackage.haskell.org/trac/ghc/ticket/3799 - jeremy On Dec 30, 2009, at 5:37 AM, Simon Marlow wrote: > On 22/12/09 03:33, Antoine Latter wrote: >> On Mon, Dec 21, 2009 at 6:31 AM, wrote: >>> Hello, >>> >>> That sort of missing symbol error at link time is often (but not >>> always) a >>> sign that some libraries got recompiled but not others. So there are >>> references to the old symbol names hanging around. >>> >>> I would try to ghc-pkg unregister syb-with-class and everything >>> that depends >>> on it, and then try cabal install happstack again. >>> >> >> I'm pretty well stumped at this point. I've cleared off everything >> and >> gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives >> me the same symbol not defined error in Happstack.Data.Xml.Base. >> >> But here's the spooky part, if I run it by hand like so: >> >> ghc --make src/Happstack/Data/Xml/Base.hs >> src/Happstack/Data/Default.hs src/Happstack/Data/ >> DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/ >> Migrate.hs >> >> after resolving issues due to CPP not being run, everything runs to >> completion, no errors. Also, the list of things we're pulling in >> during the template-haskell execution is much smaller (see bellow). >> >> Has anyone seen this, where template-haskell behaves different when >> run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? >> >>>>>>> >> 2 of 5] Compiling Happstack.Data.Migrate ( >> src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o ) >> [3 of 5] Compiling Happstack.Data.Default ( >> src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o ) >> [4 of 5] Compiling Happstack.Data.DeriveAll ( >> src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o ) >> [5 of 5] Compiling Happstack.Data.Xml.Base ( >> src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o ) >> Loading package ghc-prim ... linking ... done. >> Loading package integer-gmp ... linking ... done. >> Loading package base ... linking ... done. >> Loading package ffi-1.0 ... linking ... done. >> Loading package array-0.3.0.0 ... linking ... done. >> Loading package bytestring-0.9.1.5 ... linking ... done. >> Loading package containers-0.3.0.0 ... linking ... done. >> Loading package pretty-1.0.1.1 ... linking ... done. >> Loading package syb-0.1.0.2 ... linking ... done. >> Loading package template-haskell ... linking ... done. >> Loading package syb-with-class-0.6.1 ... linking ... done. >> mkUsageInfo: internal name? Element{tc a4av} >> <<<<< > > Did you submit a ticket for this? I don't recall seeing one. > > Cheers, > Simon From martine at danga.com Sat Jan 2 01:08:30 2010 From: martine at danga.com (Evan Martin) Date: Sat Jan 2 00:41:38 2010 Subject: X11 missing source repo(?) Message-ID: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> I'd like to make a patch for the X11 package. I found http://hackage.haskell.org/package/X11 , which references http://code.haskell.org/X11/ , which appears to be empty. Did something go wrong? If it helps any, the change is trivial (just want to get at the Visual pointer from another package, much in the way Display and Screen are exposed). I'd be happy to make a Darcs format patch if you'd prefer that. diff -ur X11-1.5.0.0/Graphics/X11/Xlib/Types.hsc myX11/Graphics/X11/Xlib/Types.hsc --- X11-1.5.0.0/Graphics/X11/Xlib/Types.hsc 2009-12-15 16:40:09.000000000 -0800 +++ myX11/Graphics/X11/Xlib/Types.hsc 2010-01-01 21:56:24.285089794 -0800 @@ -15,7 +15,7 @@ -- #hide module Graphics.X11.Xlib.Types( - Display(..), Screen(..), Visual, GC, GCValues, SetWindowAttributes, + Display(..), Screen(..), Visual(..), GC, GCValues, SetWindowAttributes, Image(..), Point(..), Rectangle(..), Arc(..), Segment(..), Color(..), Pixel, Position, Dimension, Angle, ScreenNumber, Buffer ) where From gwern0 at gmail.com Sat Jan 2 08:32:44 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Jan 2 08:05:51 2010 Subject: X11 missing source repo(?) In-Reply-To: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> References: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> Message-ID: On Sat, Jan 2, 2010 at 1:08 AM, Evan Martin wrote: > I'd like to make a patch for the X11 package. > > I found http://hackage.haskell.org/package/X11 , which references > http://code.haskell.org/X11/ , which appears to be empty. ?Did > something go wrong? > > If it helps any, the change is trivial (just want to get at the Visual > pointer from another package, much in the way Display and Screen are > exposed). > I'd be happy to make a Darcs format patch if you'd prefer that. The old repo is at *darcs*.haskell.org; it's apparently being moved to c.h.o (so as to be able to give more people the commit-bit), but hasn't yet been actually moved. -- gwern From martine at danga.com Sat Jan 2 11:30:35 2010 From: martine at danga.com (Evan Martin) Date: Sat Jan 2 11:03:42 2010 Subject: X11 missing source repo(?) In-Reply-To: References: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> Message-ID: <3a6f89fc1001020830p1d4e8132xce759988c8659bc6@mail.gmail.com> On Sat, Jan 2, 2010 at 5:32 AM, Gwern Branwen wrote: > On Sat, Jan 2, 2010 at 1:08 AM, Evan Martin wrote: >> I'd like to make a patch for the X11 package. >> >> I found http://hackage.haskell.org/package/X11 , which references >> http://code.haskell.org/X11/ , which appears to be empty. ?Did >> something go wrong? >> >> If it helps any, the change is trivial (just want to get at the Visual >> pointer from another package, much in the way Display and Screen are >> exposed). >> I'd be happy to make a Darcs format patch if you'd prefer that. > > The old repo is at *darcs*.haskell.org; it's apparently being moved to > c.h.o (so as to be able to give more people the commit-bit), but > hasn't yet been actually moved. Thanks. Same patch now attached. Having written this, what would probably be even cleaner is to have - Graphics.X11.Xlib.Types expose abstract Display, Visual etc and their typeclass instances - an extra Graphics.X11.Xlib.Internals that provides functions to go from Display -> Ptr Display, etc However, this would be both a non-backwards-compatible change (currently Display is exposed as a newtype) and I lack the Haskell-fu to write such a change (like, the newtype would need to go into .Internals but then the deriving declaration should be in .Types?). -------------- next part -------------- A non-text attachment was scrubbed... Name: expose-visual-pointer.patch Type: text/x-patch Size: 8535 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20100102/66a8e497/expose-visual-pointer.bin From chris.casinghino at gmail.com Sat Jan 2 16:54:35 2010 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Sat Jan 2 16:27:56 2010 Subject: cabal sdist doesn't include c headers Message-ID: Hi all, I have a cabal package which includes some C code. In the library description I have the two fields: include-dirs: contrib/libpuz/include includes: contrib/libpuz/include/puz.h But the file contrib/libpuz/include/puz.h is missing from the tarball generated by running "cabal sdist". There are C sources (mentioned using a "c-sources" line) which depend on this header. I'm not sure if this is a bug or the desired behavior. What is the recommended way to get this file into the sdist tarball? For now, I've added the header to the "extra-source-files" field. This works fine. cabal --version reports: cabal-install version 0.6.2 using version 1.6.0.3 of the Cabal library Thanks for your help! --Chris Casinghino From gwern0 at gmail.com Sat Jan 2 17:29:23 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Jan 2 17:02:29 2010 Subject: cabal sdist doesn't include c headers In-Reply-To: References: Message-ID: On Sat, Jan 2, 2010 at 4:54 PM, Chris Casinghino wrote: > Hi all, > > I have a cabal package which includes some C code. ?In the library > description I have the two fields: > > ?include-dirs: ? ? ?contrib/libpuz/include > ?includes: ? ? ? ? ?contrib/libpuz/include/puz.h > > But the file contrib/libpuz/include/puz.h is missing from the tarball > generated by running "cabal sdist". ?There are C sources (mentioned > using a "c-sources" line) which depend on this header. > > I'm not sure if this is a bug or the desired behavior. ?What is the > recommended way to get this file into the sdist tarball? ?For now, > I've added the header to the "extra-source-files" field. ?This works > fine. > > cabal --version reports: > > cabal-install version 0.6.2 > using version 1.6.0.3 of the Cabal library > > Thanks for your help! > > --Chris Casinghino Perhaps http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#pkg-descr helps? "install-includes: filename list A list of header files from this package to be installed into $libdir/includes when the package is installed. Files listed in install-includes: should be found in relative to the top of the source tree or relative to one of the directories listed in include-dirs. install-includes is typically used to name header files that contain prototypes for foreign imports used in Haskell code in this package, for which the C implementations are also provided with the package. Note that to include them when compiling the package itself, they need to be listed in the includes: field as well." -- gwern From chris.casinghino at gmail.com Sat Jan 2 17:40:57 2010 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Sat Jan 2 17:14:18 2010 Subject: cabal sdist doesn't include c headers In-Reply-To: References: Message-ID: Hi Gwern, Thanks for the reply. I did see this field in the documentation, but I don't want the header file to be installed on the user's computer - it's only for internal use. I need it to show up in the sdist tarball because it's used for building the package. --Chris Casinghino On Sat, Jan 2, 2010 at 5:29 PM, Gwern Branwen wrote: > On Sat, Jan 2, 2010 at 4:54 PM, Chris Casinghino > wrote: >> Hi all, >> >> I have a cabal package which includes some C code. ?In the library >> description I have the two fields: >> >> ?include-dirs: ? ? ?contrib/libpuz/include >> ?includes: ? ? ? ? ?contrib/libpuz/include/puz.h >> >> But the file contrib/libpuz/include/puz.h is missing from the tarball >> generated by running "cabal sdist". ?There are C sources (mentioned >> using a "c-sources" line) which depend on this header. >> >> I'm not sure if this is a bug or the desired behavior. ?What is the >> recommended way to get this file into the sdist tarball? ?For now, >> I've added the header to the "extra-source-files" field. ?This works >> fine. >> >> cabal --version reports: >> >> cabal-install version 0.6.2 >> using version 1.6.0.3 of the Cabal library >> >> Thanks for your help! >> >> --Chris Casinghino > > Perhaps http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#pkg-descr > helps? > > "install-includes: ?filename list > > ? ?A list of header files from this package to be installed into > $libdir/includes when the package is installed. Files listed in > install-includes: should be found in relative to the top of the source > tree or relative to one of the directories listed in include-dirs. > > ? ?install-includes is typically used to name header files that > contain prototypes for foreign imports used in Haskell code in this > package, for which the C implementations are also provided with the > package. Note that to include them when compiling the package itself, > they need to be listed in the includes: field as well." > > -- > gwern > From cgibbard at gmail.com Sat Jan 2 19:03:52 2010 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Jan 2 18:36:58 2010 Subject: nubBy, groupBy specification In-Reply-To: <18531661.1770691262457152299.JavaMail.nabble@isper.nabble.com> References: <18531661.1770691262457152299.JavaMail.nabble@isper.nabble.com> Message-ID: <89ca3d1f1001021603m122193fcm12d68be6ea3df270@mail.gmail.com> 2010/1/2 : > I'm inclined to agree with you. Could you please post the sources to both nubBy > and groupBy to see what has changed? > > Thanks, > Kim-Ee > yeoh@cs.wisc.edu Sure thing, Here is the report's implementation of nubBy: ------------------- nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs) ------------------- And here is the implementation in GHC 6.10.4 and GHC 6.12.1: ------------------- nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a -> a -> Bool) -> a -> [a] -> Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs ------------------- Note that the comment is actually incorrect. The report implementation of nubBy applies the function such that earlier accepted elements of the list are the left parameter to eq. Simply switching the y `eq` x to become x `eq` y in elem_by produces something which passes QuickCheck tests at the very least. I believe it's really the right thing at that point. The implementation of groupBy in 6.10.4 and 6.12.1 is the same as the report version, and I'm happy with it: ------------------- groupBy :: (a -> a -> Bool) -> [a] -> [[a]] groupBy _ [] = [] groupBy eq (x:xs) = (x:ys) : groupBy eq zs where (ys,zs) = span (eq x) xs ------------------- My main concern with it is that the report says: ------------------- When the "By" function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence ------------------- which I think is much too strong an assumption given that these functions have reasonably natural and quite useful extensions to non-equivalence relations, which the code provided by the Report actually implements. - Cale From sebf at informatik.uni-kiel.de Sat Jan 2 21:07:15 2010 From: sebf at informatik.uni-kiel.de (Sebastian Fischer) Date: Sat Jan 2 20:40:23 2010 Subject: nubBy, groupBy specification In-Reply-To: <89ca3d1f1001021603m122193fcm12d68be6ea3df270@mail.gmail.com> References: <18531661.1770691262457152299.JavaMail.nabble@isper.nabble.com> <89ca3d1f1001021603m122193fcm12d68be6ea3df270@mail.gmail.com> Message-ID: On Jan 3, 2010, at 1:03 AM, Cale Gibbard wrote: > nubBy' (y:ys) xs > | elem_by eq y xs = nubBy' ys xs I wonder why the author of this code did not use "any (eq y)" instead of "elem_by eq y" as "elem_by" is not exported anyway. Does "elem_by" compile to more efficient code? The version with "any" could be "fixed" (made equivalent to the report version) easily by using "any (`eq` y)". The comment on "elem_by" gives me the impression that the semantics of "nubBy" was changed by accident in the new version and I agree that it should be fixed. Or maybe the semantics was changed on purpose in order to annoy people that ignore the precondition that Cale proposes to relax (; +1 for the relaxation. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) From chris.casinghino at gmail.com Sun Jan 3 12:14:17 2010 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Sun Jan 3 11:47:36 2010 Subject: cabal install c2hs problem Message-ID: Hi all, This looks like a cabal bug and the folks on the c2hs list haven't responded, so hopefully this is the right place to ask. I ran "cabal install c2hs", which seemed to conclude succesfully. However, then running "cabal list c2hs" shows c2hs as "Not installed". I have observed this behavior on both linux and windows. On linux, despite the fact that cabal reports c2hs is not installed, packages which depend on it install fine. On windows xp, in what may or may not be a related error, cabal installing packages which depend on c2hs causes the error: "c2hs.exe: does not exist" I believe I am running the latest version of cabal on both linux and windows. Thanks in advance for your help. --Chris Casinghino From aslatter at gmail.com Sun Jan 3 12:21:33 2010 From: aslatter at gmail.com (Antoine Latter) Date: Sun Jan 3 11:54:37 2010 Subject: cabal install c2hs problem In-Reply-To: References: Message-ID: <694519c51001030921x67f14829q56116c1b586c288c@mail.gmail.com> On Sun, Jan 3, 2010 at 11:14 AM, Chris Casinghino wrote: > Hi all, > > This looks like a cabal bug and the folks on the c2hs list haven't > responded, so hopefully this is the right place to ask. > > I ran "cabal install c2hs", which seemed to conclude succesfully. > However, then running "cabal list c2hs" shows c2hs as "Not installed". > I have observed this behavior on both linux and windows. > > On linux, despite the fact that cabal reports c2hs is not installed, > packages which depend on it install fine. > > On windows xp, in what may or may not be a related error, cabal > installing packages which depend on c2hs causes the error: > > "c2hs.exe: does not exist" > > I believe I am running the latest version of cabal on both linux and > windows. > Hi Chris, As far as I know, cabal is unable to track which executables we have installed, so any package which is just an executable will always show up as uninstalled. It sounds like your problem on windows is that cabal-install is installing executables into a directory which is not in your path. Antoine From chris.casinghino at gmail.com Sun Jan 3 12:27:47 2010 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Sun Jan 3 12:01:05 2010 Subject: cabal install c2hs problem In-Reply-To: <694519c51001030921x67f14829q56116c1b586c288c@mail.gmail.com> References: <694519c51001030921x67f14829q56116c1b586c288c@mail.gmail.com> Message-ID: Hi Antoine, > It sounds like your problem on windows is that cabal-install is > installing executables into a directory which is not in your path. Thanks for the prompt reply. c2hs.exe is definitely on my path. However, your comment prompted me to try running it manually, and I discovered c2hs itself is what is giving the error. So, it doesn't seem to be a cabal problem. Thanks for your help. --Chris Casinghino From gwern0 at gmail.com Sun Jan 3 18:46:51 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Jan 3 18:19:52 2010 Subject: Adding Network.URI.escape In-Reply-To: <4B352BDF.1080506@ninebynine.org> References: <4B352BDF.1080506@ninebynine.org> Message-ID: On Fri, Dec 25, 2009 at 4:17 PM, Graham Klyne wrote: > Gwern Branwen wrote: >> >> Network.URI.escapeURIString is pretty much always used to make a >> String a URL or a part of a URL. >> >> The existing definition >> >> http://www.haskell.org/ghc/docs/6.10.4/html/libraries/network/Network-URI.html#v%3AescapeURIString >> forces one to do extra work by having to specify a `Char -> Bool`. >> >> More than a few packages & libraries simply define an 'escape' >> function `escapeURIString isAllowedInURI` (either inline or as a named >> function). This sort of repetition is unfortunate. > > Hmmm... I think that's not strictly correct - it should be 'escapeURIString > isUnescapedInURI'. ?The form used above would leave literal '%' characters > unescaped. That's unfortunate! But it also takes care of a long-niggling worry - I had come across an old #haskell log where someone said that that definition is wrong, but they didn't explain how. I guess I ought to go around to every user of that definition, like Gitit, and correct them... >> The name 'escape' is commonly used to express exactly that >> functionality: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:escape >> >> What would people say to adding such a function? > > The reason that the 'escapeURIString' always takes the Char -> Bool function > is that the rules for escaping can very between URI schemes, and between > components within a single URI. ?For example, a literal '/' or '?' appearing > within a path segment in an http: URI would need to be escaped, but that's > not included by the common case of 'escapeURIString isUnescapedInURI'. > > The 'isAllowedInURI' function, IIRC, is a kind of least-common-denominator > function that causes non-URI characters to be escaped so that the resulting > string is at least syntactically valid according to RFC3986. ?But in some > cases (i.e. for some schemes) this may not be enough - see RFC 3986, section > 2.1 ("A percent-encoding mechanism is used to represent a data octet in a > component when that octet's corresponding character is outside the allowed > set or is being used as a delimiter of, or within, the component" -- > http://www.apps.ietf.org/rfc/rfc3986.html#sec-2.1 ); see also section 2.4. > > So, while one could define an additional function as you suggest, I'm not > sure it is necessarily wise, because having the explicit function to > designate characters to be escaped does at least draw attention to exactly > which characters would be escaped in the context of use. ?But OTOH, if > implementations tend to use 'escapeURIString isAllowedInURI' as you say, > maybe this just creates an opportunity for additional errors. > > URI escaping is, to some extent, a necessarily messy and error-prone > business - it's really hard to define a generic escaping mechanism that > neatly covers all eventualities, because of the multiple stages of > interpretation that can take place when actually using a URI. > > #g Thanks for the information; I start to see what you mean by the difficulty. But as you say, while a 'escape' may be dangerous, it's not like people are being safe now without an 'escape'. Is it possible to identify the most common escaping scenarios and come up with the correct shortcuts? For example, perhaps we could defined an 'escapeURL = escapeURIString isUnescapedInURI' which is suitable for garden-variety tasks like `"http://gitit.net"++escapeURL pagename`, and then another for the octets you mention ('escapeOctet'?). -- gwern From GK at ninebynine.org Mon Jan 4 08:35:16 2010 From: GK at ninebynine.org (Graham Klyne) Date: Mon Jan 4 08:08:27 2010 Subject: Adding Network.URI.escape In-Reply-To: References: <4B352BDF.1080506@ninebynine.org> Message-ID: <4B41EE94.90902@ninebynine.org> Gwern Branwen wrote: > On Fri, Dec 25, 2009 at 4:17 PM, Graham Klyne wrote: >> Gwern Branwen wrote: >>> Network.URI.escapeURIString is pretty much always used to make a >>> String a URL or a part of a URL. >>> >>> The existing definition >>> >>> http://www.haskell.org/ghc/docs/6.10.4/html/libraries/network/Network-URI.html#v%3AescapeURIString >>> forces one to do extra work by having to specify a `Char -> Bool`. >>> >>> More than a few packages & libraries simply define an 'escape' >>> function `escapeURIString isAllowedInURI` (either inline or as a named >>> function). This sort of repetition is unfortunate. >> Hmmm... I think that's not strictly correct - it should be 'escapeURIString >> isUnescapedInURI'. The form used above would leave literal '%' characters >> unescaped. > > That's unfortunate! But it also takes care of a long-niggling worry - > I had come across an old #haskell log where someone said that that > definition is wrong, but they didn't explain how. I guess I ought to > go around to every user of that definition, like Gitit, and correct > them... > >>> The name 'escape' is commonly used to express exactly that >>> functionality: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:escape >>> >>> What would people say to adding such a function? >> The reason that the 'escapeURIString' always takes the Char -> Bool function >> is that the rules for escaping can very between URI schemes, and between >> components within a single URI. For example, a literal '/' or '?' appearing >> within a path segment in an http: URI would need to be escaped, but that's >> not included by the common case of 'escapeURIString isUnescapedInURI'. >> >> The 'isAllowedInURI' function, IIRC, is a kind of least-common-denominator >> function that causes non-URI characters to be escaped so that the resulting >> string is at least syntactically valid according to RFC3986. But in some >> cases (i.e. for some schemes) this may not be enough - see RFC 3986, section >> 2.1 ("A percent-encoding mechanism is used to represent a data octet in a >> component when that octet's corresponding character is outside the allowed >> set or is being used as a delimiter of, or within, the component" -- >> http://www.apps.ietf.org/rfc/rfc3986.html#sec-2.1 ); see also section 2.4. >> >> So, while one could define an additional function as you suggest, I'm not >> sure it is necessarily wise, because having the explicit function to >> designate characters to be escaped does at least draw attention to exactly >> which characters would be escaped in the context of use. But OTOH, if >> implementations tend to use 'escapeURIString isAllowedInURI' as you say, >> maybe this just creates an opportunity for additional errors. >> >> URI escaping is, to some extent, a necessarily messy and error-prone >> business - it's really hard to define a generic escaping mechanism that >> neatly covers all eventualities, because of the multiple stages of >> interpretation that can take place when actually using a URI. >> >> #g > > Thanks for the information; I start to see what you mean by the > difficulty. But as you say, while a 'escape' may be dangerous, it's > not like people are being safe now without an 'escape'. > > Is it possible to identify the most common escaping scenarios and come > up with the correct shortcuts? > > For example, perhaps we could defined an 'escapeURL = escapeURIString > isUnescapedInURI' which is suitable for garden-variety tasks like > `"http://gitit.net"++escapeURL pagename`, and then another for the > octets you mention ('escapeOctet'?). It's clearly *possible*, but where do we stop? That said, I guess a *small* number of special cases would make sense, e.g. escapeHttpOrFileUri with carefully written health warnings in the associated documentation; e.g. "This function applies URI escaping to an http: or file: URI on the assumption that the individual path segments within the URI do not contain '/' or '?' or '#' or [...] characters. If any of these characters are present in any path segment then the URI components and path segments should be escaped separately before being assembled into a final URI, and no further escaping should be applied once the URI has been constructed (cf. RFC 3986 [...])", etc., etc. My point here is that crafting a clear description of when the provided escaping is correct to use will be somewhat harder than writing the functions. Also, I suspect that escaping function will need to be a little more subtle than 'escapeURIString isUnescapedInURI', at least to the extent of splitting off the query and fragment before escaping the pieces separately, then re-assembling. Maybe the greatest value in doing this would be to demonstrate concretely the complexities inherent in URI escaping, and provide some code that can be adapted for different schemes and circumstances. #g -- From gwern0 at gmail.com Mon Jan 4 09:53:39 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon Jan 4 09:26:40 2010 Subject: Adding Network.URI.escape In-Reply-To: <4B41CDD2.7050002@ninebynine.org> References: <4B352BDF.1080506@ninebynine.org> <4B41CDD2.7050002@ninebynine.org> Message-ID: On Mon, Jan 4, 2010 at 6:15 AM, Graham Klyne wrote: > It's clearly *possible*, but where do we stop? ?That said, I guess a *small* > number of special cases would make sense, e.g. Yes, a few is what I mean. There are no doubt endless possible cases and layers of interpretation, but in real-life, 2 or 3 use-cases tend to dominate. Libraries can only hope to bundle common special cases, after all. (I recall one information theoretic paper I read arguing that over the space of all possible programs, libraries are a net negative in terms of size; but of course, this is like type safety or no pointers - we don't *want* to write all possible programs.) > ?escapeHttpOrFileUri > > with carefully written health warnings in the associated documentation; e.g. > "This function applies URI escaping to an http: or file: URI on the > assumption that the individual path segments within the URI do not contain > '/' or '?' or '#' or [...] characters. ?If any of these characters are > present in any path segment then the URI components and path segments should > be escaped separately before being assembled into a final URI, and no > further escaping should be applied once the URI has been constructed (cf. > RFC 3986 [...])", etc., etc. > > My point here is that crafting a clear description of when the provided > escaping is correct to use will be somewhat harder than writing the > functions. ?Also, I suspect that escaping function will need to be a little > more subtle than 'escapeURIString isUnescapedInURI', at least to the extent > of splitting off the query and fragment before escaping the pieces > separately, then re-assembling. > > Maybe the greatest value in doing this would be to demonstrate concretely > the complexities inherent in URI escaping, and provide some code that can be > adapted for different schemes and circumstances. > > #g Yes, it does demonstrate that the task is difficult and messy. As it is, the danger can easily be breezed through by someone who wants to get a job done - and that's just not the Haskell way! Can we leave the task to you? Even just your escapeHttpOrFileUri is an improvement. -- gwern From ndmitchell at gmail.com Mon Jan 4 15:14:58 2010 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jan 4 14:48:03 2010 Subject: Network on GHC 6.12 with Windows In-Reply-To: <404396ef0911240740n30825fdakd204bbb9ef363690@mail.gmail.com> References: <0319C4ED2AB1064491EC6A53F1B1556B06B1485B@UKWATXMB101V.zone1.scb.net> <404396ef0911230942m72de3960w826a1a424c707c1b@mail.gmail.com> <90889fe70911231159q3016b094pd38b44cf476b8360@mail.gmail.com> <90889fe70911240556j63627855u4935748d0f63827b@mail.gmail.com> <404396ef0911240740n30825fdakd204bbb9ef363690@mail.gmail.com> Message-ID: <404396ef1001041214k9bf5f93rc2db49d1d5bfbf2e@mail.gmail.com> Hi, For people who were following this thread, we've got a resolution: * Upgrade to the latest network package. * Make sure you have Cygwin or Mingw installed. * Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe. With those changes I was able to install the network package. It's a real shame I can't install it from a standard Windows shell, but I guess I just have to wait for the platform to get that bit working. Thanks, Neil 2009/11/24 Neil Mitchell : > Hi Johan, > > I get a different behaviour, but it's not all good. I seem to fail > during the configure stage now - complete output below. > > Thanks, Neil > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121 > > $ darcs get http://code.haskell.org/network > Copying patch 329 of 329... done. > Applying patch 329 of 329... done. > Finished getting. > > $ cd network > > $ wget http://johantibell.com/gamr7networkpatch.dpatch > --2009-11-24 15:32:54-- ?http://johantibell.com/gamr7networkpatch.dpatch > Length: 3178 (3.1K) [application/octet-stream] > Saving to: `gamr7networkpatch.dpatch' > > 100%[======================================>] 3,178 ? ? ? --.-K/s ? in 0.002s > > 2009-11-24 15:32:54 (1.60 MB/s) - `gamr7networkpatch.dpatch' saved [3178/3178] > > $ darcs apply gamr7networkpatch.dpatch > Finished applying... > > $ autoreconf > > $ runhaskell Setup configure > > Setup.hs:3:0: > ? ?Warning: In the use of `defaultUserHooks' > ? ? ? ? ? ? (imported from Distribution.Simple): > ? ? ? ? ? ? Deprecated: "Use simpleUserHooks or autoconfUserHooks, > unless you need Cabal-1.2 > ? ? ? ? ? ? compatibility in which case you must stick with defaultUserHooks" > Warning: defaultUserHooks in Setup script is deprecated. > Configuring network-2.2.1.5... > configure: WARNING: unrecognized options: --with-hc > checking build system type... i686-pc-cygwin > checking host system type... i686-pc-cygwin > checking for gcc... gcc > checking for C compiler default output file name... a.exe > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... .exe > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for an ANSI C-conforming const... yes > checking how to run the C preprocessor... gcc -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking fcntl.h usability... yes > checking fcntl.h presence... yes > checking for fcntl.h... yes > checking limits.h usability... yes > checking limits.h presence... yes > checking for limits.h... yes > checking for stdlib.h... (cached) yes > checking for sys/types.h... (cached) yes > checking for unistd.h... (cached) yes > checking winsock2.h usability... no > checking winsock2.h presence... yes > configure: WARNING: winsock2.h: present but cannot be compiled > configure: WARNING: winsock2.h: ? ? check for missing prerequisite headers? > configure: WARNING: winsock2.h: see the Autoconf documentation > configure: WARNING: winsock2.h: ? ? section "Present But Cannot Be Compiled" > configure: WARNING: winsock2.h: proceeding with the compiler's result > configure: WARNING: ? ? ## ------------------------------------ ## > configure: WARNING: ? ? ## Report this to libraries@haskell.org ## > configure: WARNING: ? ? ## ------------------------------------ ## > checking for winsock2.h... no > checking ws2tcpip.h usability... no > checking ws2tcpip.h presence... yes > configure: WARNING: ws2tcpip.h: present but cannot be compiled > configure: WARNING: ws2tcpip.h: ? ? check for missing prerequisite headers? > configure: WARNING: ws2tcpip.h: see the Autoconf documentation > configure: WARNING: ws2tcpip.h: ? ? section "Present But Cannot Be Compiled" > configure: WARNING: ws2tcpip.h: proceeding with the compiler's result > configure: WARNING: ? ? ## ------------------------------------ ## > configure: WARNING: ? ? ## Report this to libraries@haskell.org ## > configure: WARNING: ? ? ## ------------------------------------ ## > checking for ws2tcpip.h... no > checking wspiapi.h usability... no > checking wspiapi.h presence... no > checking for wspiapi.h... no > checking arpa/inet.h usability... yes > checking arpa/inet.h presence... yes > checking for arpa/inet.h... yes > checking netdb.h usability... yes > checking netdb.h presence... yes > checking for netdb.h... yes > checking netinet/in.h usability... yes > checking netinet/in.h presence... yes > checking for netinet/in.h... yes > checking netinet/tcp.h usability... yes > checking netinet/tcp.h presence... yes > checking for netinet/tcp.h... yes > checking sys/socket.h usability... yes > checking sys/socket.h presence... yes > checking for sys/socket.h... yes > checking sys/uio.h usability... yes > checking sys/uio.h presence... yes > checking for sys/uio.h... yes > checking sys/un.h usability... yes > checking sys/un.h presence... yes > checking for sys/un.h... yes > checking for readlink... yes > checking for symlink... yes > checking for struct msghdr.msg_control... yes > checking for struct msghdr.msg_accrights... no > checking for struct sockaddr.sa_len... no > checking for in_addr_t in netinet/in.h... yes > checking for SO_PEERCRED and struct ucred in sys/socket.h... yes > checking for _head_libws2_32_a in -lws2_32... yes > checking for getaddrinfo... no > checking for getaddrinfo if WINVER is 0x0501... no > checking for gai_strerror... no > checking whether AI_ADDRCONFIG is declared... no > checking whether AI_ALL is declared... no > checking whether AI_NUMERICSERV is declared... no > checking whether AI_V4MAPPED is declared... no > checking for sendfile in sys/sendfile.h... no > checking for sendfile in sys/socket.h... no > checking for gethostent... no > configure: creating ./config.status > config.status: creating network.buildinfo > config.status: creating include/HsNetworkConfig.h > configure: WARNING: unrecognized options: --with-hc > Setup: Missing dependency on a foreign library: > * Missing header file: HsNet.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > > $ runhaskell Setup build > > Setup.hs:3:0: > ? ?Warning: In the use of `defaultUserHooks' > ? ? ? ? ? ? (imported from Distribution.Simple): > ? ? ? ? ? ? Deprecated: "Use simpleUserHooks or autoconfUserHooks, > unless you need Cabal-1.2 > ? ? ? ? ? ? compatibility in which case you must stick with defaultUserHooks" > Preprocessing library network-2.2.1.5... > In file included from Network\BSD.hsc:17: > include/HsNet.h:78:22: sys/uio.h: No such file or directory > include/HsNet.h:81:25: sys/socket.h: No such file or directory > include/HsNet.h:84:26: netinet/tcp.h: No such file or directory > include/HsNet.h:87:25: netinet/in.h: No such file or directory > include/HsNet.h:90:21: sys/un.h: No such file or directory > include/HsNet.h:93:24: arpa/inet.h: No such file or directory > include/HsNet.h:96:19: netdb.h: No such file or directory > In file included from Network\BSD.hsc:17: > include/HsNet.h:138: error: syntax error before "addr" > include/HsNet.h: In function `my_inet_ntoa': > include/HsNet.h:146: error: storage size of 'a' isn't known > include/HsNet.h:147: error: `addr' undeclared (first use in this function) > include/HsNet.h:147: error: (Each undeclared identifier is reported only once > include/HsNet.h:147: error: for each function it appears in.) > include/HsNet.h:148: warning: return makes pointer from integer without a cast > Network\BSD.hsc: In function `main': > Network\BSD.hsc:149: error: invalid application of `sizeof' to > incomplete type `servent' > Network\BSD.hsc:149: error: invalid application of `sizeof' to > incomplete type `servent' > Network\BSD.hsc:149: error: invalid application of `sizeof' to > incomplete type `servent' > Network\BSD.hsc:153: error: dereferencing pointer to incomplete type > Network\BSD.hsc:154: error: dereferencing pointer to incomplete type > Network\BSD.hsc:157: error: dereferencing pointer to incomplete type > Network\BSD.hsc:158: error: dereferencing pointer to incomplete type > Network\BSD.hsc:253: error: invalid application of `sizeof' to > incomplete type `protoent' > Network\BSD.hsc:253: error: invalid application of `sizeof' to > incomplete type `protoent' > Network\BSD.hsc:253: error: invalid application of `sizeof' to > incomplete type `protoent' > Network\BSD.hsc:257: error: dereferencing pointer to incomplete type > Network\BSD.hsc:258: error: dereferencing pointer to incomplete type > Network\BSD.hsc:265: error: dereferencing pointer to incomplete type > Network\BSD.hsc:343: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:343: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:343: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:347: error: dereferencing pointer to incomplete type > Network\BSD.hsc:348: error: dereferencing pointer to incomplete type > Network\BSD.hsc:351: error: dereferencing pointer to incomplete type > Network\BSD.hsc:353: error: dereferencing pointer to incomplete type > Network\BSD.hsc:452: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:452: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:452: error: invalid application of `sizeof' to > incomplete type `hostent' > Network\BSD.hsc:456: error: dereferencing pointer to incomplete type > Network\BSD.hsc:457: error: dereferencing pointer to incomplete type > Network\BSD.hsc:460: error: dereferencing pointer to incomplete type > Network\BSD.hsc:461: error: dereferencing pointer to incomplete type > compiling dist\build\Network\BSD_hsc_make.c failed > command was: C:\ghc\ghc-6.12.1-rc2\mingw\bin\gcc.exe -c > -D__GLASGOW_HASKELL__=612 -Iinclude -DCALLCONV=ccall -DBASE4 > -IC:\ghc\ghc-6.12.1-rc2\base-4.2.0.0\include > -IC:\ghc\ghc-6.12.1-rc2/include -IC:\ghc\ghc-6.12.1-rc2/include > -IC:/ghc/ghc-6.12.1-rc2/lib/include/ dist\build\Network\BSD_hsc_make.c > -o dist\build\Network\BSD_hsc_make.o > From GK at ninebynine.org Tue Jan 5 09:36:38 2010 From: GK at ninebynine.org (Graham Klyne) Date: Tue Jan 5 09:09:44 2010 Subject: Adding Network.URI.escape In-Reply-To: References: <4B352BDF.1080506@ninebynine.org> <4B41CDD2.7050002@ninebynine.org> Message-ID: <4B434E76.2010103@ninebynine.org> Ironically, even the standards groups have problems with these issues. Cf. http://lists.w3.org/Archives/Public/uri/2010Jan/0001.html Gwern Branwen wrote: > Yes, it does demonstrate that the task is difficult and messy. As it > is, the danger can easily be breezed through by someone who wants to > get a job done - and that's just not the Haskell way! > Can we leave the task to you? Even just your escapeHttpOrFileUri is an > improvement. I can't promise a deadline by which this will be achieved, but I am prepared to add it to my TODO list... #g From mblazevic at stilo.com Fri Jan 8 09:26:06 2010 From: mblazevic at stilo.com (Mario Blazevic) Date: Fri Jan 8 08:58:58 2010 Subject: Splitting a Hackage project (was ANN: Streaming Component Combinators 0.4) In-Reply-To: <.1262910550@magma.ca> References: <.1262910550@magma.ca> Message-ID: <4B47407E.40702@stilo.com> I couldn't find any Hackage policy guideline on the appropriate balance between the package list size and package size, so I'll just ask the question. I have released the version 0.4 of my SCC package yesterday. In this particular release, there is at least one module that's nicely self-contained, providing useful functionality of its own, and not expected to evolve much: http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concurrent-Coroutine.html My question then is if I should split this module into a separate package or leave it where it is? If I split it out, what should I do about the ParallelizableMonad class in the module? > class Monad m => ParallelizableMonad m where > bindM2 :: (a -> b -> m c) -> m a -> m b -> m c This class and its instances would again be something *usable* both outside the SCC package and outside the Control.Concurrent.Coroutine module. But would they be *useful* and would they be *used*? Should I split the class out into a Control.ParallelizableMonad package? I'm sure I'm not the only one with the same dilemma. It would be nice to have some written rules to follow on what belongs on Hackage as a separate package. > Version 0.4 of Streaming Component Combinators, or SCC for short, has > been released on Hackage. Get it at > > http://hackage.haskell.org/package/scc > > There isn't much new high-level functionality compared to the > previous version, but the implementation has been heavily refactored and > the foundations completely replaced. > > I'm particularly happy to have found a way to drop the ugly reliance > on Data.Dynamic and to encode the required constraints in the type > system instead. The foundation of streaming components in this version > is the new Control.Concurrent.Coroutine module, whose main export is the monad > transformer Coroutine. It can transform any monad into a suspendable, resumable, > trampoline-style-runnable monad. Coroutines can be nested, which was the > requirement for streaming and the main stumbling block for the implementation. > The solution, worth at least 10 milliOlegs according to my estimate, was to > parameterize the Coroutine with a functor that wraps the coroutine suspension, > and to use nested functors for suspension from nested coroutines. The type system > automatically figures out how many wrappings to apply to each suspension > depending on how many intermediate coroutines it suspends. > > In other news is the project's Wiki page at > http://trac.haskell.org/SCC/wiki/. It's still rudimentary, but growing. > > All feedback will be appreciated. > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From gwern0 at gmail.com Fri Jan 8 16:53:07 2010 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Fri Jan 8 16:25:57 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () Message-ID: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> Fri Jan 8 16:44:55 EST 2010 gwern0@gmail.com * Control.Monad: +void :: f a -> f () See http://hackage.haskell.org/trac/ghc/ticket/3292 Turns m a -> m (). Lets one call functions for their side-effects without having to get rid of their return values with '>> return ()'. Very useful in many contexts (parsing, IO etc.); particularly good for 'forkIO' and 'forM_', as they demand return types of 'IO ()' though most interesting IO functions return non-(). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 25553 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20100108/feb283ca/attachment-0001.bin From gwern0 at gmail.com Fri Jan 8 16:56:18 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Jan 8 16:29:06 2010 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: An update on the poll: # Nothing - David Menendez - John Meachem (?) # Just ## Control.Monad.ignore :: m a -> m () - Isaac Dupree - Martijn van Steenbergen - Maur??cio - Michael Snoyman - Neil Mitchell ### Control.Monad.ignore:: f a -> f () - Edward Kmett - Henning Thielemann ## Control.Monad.void :: f a -> f () - Don Stewart - Iavor Diatchki - Jeff Wheeler - Johann Tibell - Malcolm Wallace - Michael Snoyman (as well) - Nicolas Pouillard - Stephan Friedrichs - Evan Laforce ## Control.Monad.discard :: f a -> f () - Nicolas Pouillard - Wolfgang Jeltsch - Deniz Dogan I think consensus has been reached to: 1) add X 2) add X :: f a -> () The exact name - whether ignore/void/discard - is not so clear with consensus. So I'm just going to name it 'void' for consistency with Foreign and foreign languages. The patch has been sent here, and has also been attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/3292 I hope we can finally bring this issue to a close! -- gwern From ml at isaac.cedarswampstudios.org Fri Jan 8 19:47:49 2010 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Fri Jan 8 19:20:55 2010 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: <4B47D235.3010804@isaac.cedarswampstudios.org> Gwern Branwen wrote: > ## Control.Monad.ignore :: m a -> m () > - Isaac Dupree (for the record, I wanted to generalize it to Functor, maybe you're counting from early in the discussion before that was brought up :-) > I think consensus has been reached to: > 1) add X > 2) add X :: f a -> () > > The exact name - whether ignore/void/discard - is not so clear with > consensus. So I'm just going to name it 'void' for consistency with > Foreign and foreign languages. yay! -Isaac From jeremy at n-heptane.com Fri Jan 8 21:54:59 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri Jan 8 21:28:25 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> Message-ID: Not sure if this came up already, but there is a less general version of void in Foreign.Marshal.Error: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Foreign-Marshal-Error.html#v%3Avoid void :: IO a -> IO () Discard the return value of an IO action Are there plans to unify the two? Perhaps Foreign.Marshal.Error can just re-export void from Control.Monad? - jeremy On Jan 8, 2010, at 3:53 PM, gwern0@gmail.com wrote: > Fri Jan 8 16:44:55 EST 2010 gwern0@gmail.com > * Control.Monad: +void :: f a -> f () > See http://hackage.haskell.org/trac/ghc/ticket/3292 > Turns m a -> m (). Lets one call functions for their side-effects > without > having to get rid of their return values with '>> return ()'. Very > useful > in many contexts (parsing, IO etc.); particularly good for 'forkIO' > and 'forM_', > as they demand return types of 'IO ()' though most interesting IO > functions > return non-(). > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > New patches: > > [Control.Monad: +void :: f a -> f () > gwern0@gmail.com**20100108214455 > Ignore-this: 4dc07452315f2d1b4941903ff42fc45f > See http://hackage.haskell.org/trac/ghc/ticket/3292 > Turns m a -> m (). Lets one call functions for their side-effects > without > having to get rid of their return values with '>> return ()'. Very > useful > in many contexts (parsing, IO etc.); particularly good for 'forkIO' > and 'forM_', > as they demand return types of 'IO ()' though most interesting IO > functions > return non-(). > ] hunk ./Control/Monad.hs 193 > forever :: (Monad m) => m a -> m b > forever a = a >> forever a > > +-- | @'void' value@ discards or ignores the result of evaluation, > such as the return value of an 'IO' action. > +void :: Functor f => f a -> f () > +void = fmap (const ()) > + > -- > ----------------------------------------------------------------------------- > -- Other monad functions > > > Context: > > [Replace the implementation of mergesort with a 2x faster one. > Malcolm.Wallace@cs.york.ac.uk**20091224152014 > See ticket http://hackage.haskell.org/trac/ghc/ticket/2143. > ] > [Restore previous Data.Typeable.typeOf*Default implementations for > non-ghc. > Malcolm.Wallace@cs.york.ac.uk**20091223142625 > Not all compilers have ScopedTypeVariables. > ] > [Add comments about double bounds-checking, and fast paths for > rectangular arrays > simonpj@microsoft.com**20091218165655 > Ignore-this: ea0849419dc00927aba4bd410b1cc58d > > See Note [Double bounds-checking of index values] for the details. > > The fast paths omit the doubled checks for cases we know about > ] > [Fix Trac #3245: memoising typeOf > simonpj@microsoft.com**20091218155117 > Ignore-this: 5a178a7f2222293c5ee0c3c43bd1b625 > > The performance bug in #3245 was caused by computing the typeRep > once for each call of typeOf, rather than once for each dictionary > contruction. (Computing TypeReps is reasonably expensive, because > of the hash-consing machinery.) > > This is readily fixed by putting the TypeRep construction outside > the lambda. (Arguably GHC might have worked that out itself, > but it involves floating something between a type lambda and a > value lambda, which GHC doesn't currently do. If it happens a lot > we could fix that.) > ] > [Mark 'index' as INLINE in GHC.Arr > simonpj@microsoft.com**20091216170441 > Ignore-this: a4df9d8acf496c8e0e9ce5a520509a2a > > This makes indexing much faster. See Trac #1216 > ] > [Comment the remaining orphan instance modules > Ian Lynagh **20091206125021] > [De-orphan Eq/Ord Float/Double > Ian Lynagh **20091205181238] > [Add comments to "OPTIONS_GHC -fno-warn-orphans" pragmas > Ian Lynagh **20091205165854] > [Data.Either.partitionEithers was insufficiently lazy. > Malcolm.Wallace@cs.york.ac.uk**20091202032807 > Ignore-this: 77e1b3288f66608c71458d8a91bcbe12 > Spotted by Daniel Fischer. > ] > [fix the docs regarding finalizer guarantees > Simon Marlow **20091130144409 > Ignore-this: d1ab9532c74a002b8075ff60febcbe2d > ] > [x86_64 requires more stack > Malcolm.Wallace@cs.york.ac.uk**20091201033745] > [check for size < 0 in mallocForeignPtrBytes and friends (#3514) > Simon Marlow **20091125143822 > Ignore-this: 91077d01da2bbe1dfed5155e8b40da9 > ] > [hGetContents: close the handle properly on error > Simon Marlow **20091125123435 > Ignore-this: bc37ff678acc6e547dc390285e056eb9 > > When hGetContents caught an error it was closing the handle and then > throwing the exception, without updating the handle with the new > closed state. This lead to a double-closed, which was the cause of > > *** glibc detected *** ./Setup: double free or corruption > > when iconv_close was called twice on the decoder. > > See http://hackage.haskell.org/trac/hackage/ticket/609 > ] > [Fix arities of mapFB and zipFB > Roman Leshchinskiy **20091126232219 > Ignore-this: c4e14cd0a92622549c86e67237a40865 > ] > [Remove an unnecessary -fno-warn-orphans flag > Ian Lynagh **20091126123404] > [Tweak layout to work with alternative layout rule > Ian Lynagh **20091125232349] > [Tweak layout to be accepted by the alternative layout rul > Ian Lynagh **20091125194147] > [Make sure zipWithFB has arity 2 > Roman Leshchinskiy **20091125010003 > Ignore-this: 4cf60c55666f03d22a9f5a6e07f52d36 > > It gets 2 arguments in the "zipWith" rule but its arity was higher > and the new > inliner didn't inline it sometimes, for instance here: > > mpp :: [Double] -> [Double] -> [Double] -> [Double] -> [Double] > mpp as bs cs ds = zipWith (*) (zipWith (+) as bs) (zipWith (+) cs ds) > > This was a regression vs. 6.10. > ] > [Remove an old comment > Ian Lynagh **20091124134647] > [De-orphan the Eq/Ord Integer instances > Ian Lynagh **20091124133639] > [Whitespace only > Ian Lynagh **20091124133421] > [Derive some more instances, rather than writing them by hand > Ian Lynagh **20091124011747] > [We can now derive Ord () > Ian Lynagh **20091124011416] > [De-orphan tuple Eq/Ord instances > Ian Lynagh **20091123233343] > [Control.Exception.Base no longer has any orphans > Ian Lynagh **20091123224905] > [De-orphan the MonadFix ST instance for GHC > Ian Lynagh **20091123223544] > [Rearrange the contents of Control.Monad.ST; no functionality changes > Ian Lynagh **20091123222702] > [De-orphan the Eq/Ord [a] instances > Ian Lynagh **20091123215635] > [De-orphan the Eq/Ord Char instances > Ian Lynagh **20091123202253] > [De-orphan the Eq/Ord Bool instances > Ian Lynagh **20091123201817] > [Move Eq/Ord Ordering instances to de-orphan them > Ian Lynagh **20091123194310] > [Remove ffi warnings for nhc98. > Malcolm.Wallace@cs.york.ac.uk**20091123063743] > [Second attempt to fix #1185 (forkProcess and -threaded) > Simon Marlow **20091111151915 > Ignore-this: fa5f5d5e4e080d4b612a37244f937f9c > > Patch 2/2: first patch is to ghc > > This time without dynamic linker hacks, instead I've expanded the > existing rts/Globals.c to cache more CAFs, specifically those in > GHC.Conc. We were already using this trick for signal handlers, I > should have realised before. > > It's still quite unsavoury, but we can do away with rts/Globals.c in > the future when we switch to a dynamically-linked GHCi. > ] > [Rollback #1185 fix > Simon Marlow **20091106140629 > Ignore-this: cd5667e8474e37e01ba26a1984274811 > > rolling back: > > Tue Nov 3 16:05:40 GMT 2009 Simon Marlow > * Fix #1185: restart the IO manager after fork() > > This is the libraries/base part of the patch; there is a > corresponding > patch to GHC itself. > > The main change is that we now keep track of the IO manager's > ThreadId > in a top-level MVar, and ensureIOManagerIsRunning checks whether a > previous IO manager thread is alive before starting one. In the > child > of fork(), we can hence call ensureIOManagerIsRunning to restart the > IO manager. > > M ./GHC/Conc.lhs -46 +44 > > Wed Nov 4 17:49:45 GMT 2009 Ian Lynagh > * Fix the build on Windows > > M ./GHC/Conc.lhs -6 +4 > ] > [Fix the build on Windows > Ian Lynagh **20091104174945] > [Fix #1185: restart the IO manager after fork() > Simon Marlow **20091103160540 > Ignore-this: 6dc05464f1500104554637f4759738cc > > This is the libraries/base part of the patch; there is a corresponding > patch to GHC itself. > > The main change is that we now keep track of the IO manager's ThreadId > in a top-level MVar, and ensureIOManagerIsRunning checks whether a > previous IO manager thread is alive before starting one. In the child > of fork(), we can hence call ensureIOManagerIsRunning to restart the > IO manager. > ] > [improve the documentation for throwErrnoIfRetry > Simon Marlow **20091016112404 > Ignore-this: b77275cacf730e15757946027168f63e > ] > [Don't inline unpackFoldrCString ever > simonpj@microsoft.com**20091029135350 > Ignore-this: 85d672649b1b776efc7e97500b05d4f9 > ] > [Inline more default methods > simonpj@microsoft.com**20091029135330 > Ignore-this: 289c44b0afd6d5631c2a4e0664275ca9 > > Namely Monad: (>>) > Eq: (==), (/=) > Num: (-), negate > Real: quot, rem, div, mod, recip, (/), truncate > Float: (**), logBase, sqrt, tan, tanh > ] > [Move error messages out of INLINEd default methods > simonpj@microsoft.com**20091029135118 > Ignore-this: 9e35dc947f94827a3529eb53a41575fd > > No need to duplicate the error generation! > ] > [Exploit now-working default-method INLINE pragmas for Data.Bits > simonpj@microsoft.com**20091029135041 > Ignore-this: 8adf225f31ca7a3181ee087e9e4fe535 > > * Add INLINE pragmas to default methods for class Bits > > * Remove redundant instance methods elsewhere, now that > the default method will do the job > ] > [Tidy up and comment imports > simonpj@microsoft.com**20091029134414 > Ignore-this: bf2be31035de975d8995e988933cc940 > ] > [Inline foldr and (.) when applied to two arguments not three > simonpj@microsoft.com**20091029134335 > Ignore-this: fccb6f3e90e15f44cb465814be85ede2 > > The new INLINE story is (by design) arity-sensitive, so we must > put fewer argument on the LHS for foldr and (.) > ] > [dirUtils.c no longer available > Malcolm.Wallace@cs.york.ac.uk**20091013093833] > [Make hGetContents throw an exception if an error is encountered > Simon Marlow **20091012152955 > Ignore-this: 9f7a7176193eab25c9daaacd9261f2de > > Strictly speaking this breaks Haskell 98 compatibility, which requires > hGetContents to just end the lazy stream silently if an error is > encountered. However, for a few reasons we think it will make > everyone's life a bit easier if we make this change > > 1. Errors will be a lot more common in GHC 6.12.1, in the form > of Unicode decoding errors. > > 2. When Haskell 98 was designed, we didn't know how to throw > exceptions from inside lazy I/O, but now we do. > > 3. If anyone is actually relying on the previous behaviour, their > code is arguably broken. > ] > [Re-instate System.Console.Getopt for nhc98 builds. > Malcolm.Wallace@cs.york.ac.uk**20091013092843 > Although it was split out of base a while back, that change was > reverted for ghc soon afterwards, but nhc98 never noticed. > ] > [Roll back "Another instance of nhc98's strange import semantics." > Ian Lynagh **20091009185618 > Fri Oct 9 14:50:51 BST 2009 Malcolm.Wallace@cs.york.ac.uk > GHC (correctly) warns about the unused import, which breaks the > validate > build. > ] > [Roll back "Cope with nhc98's (occasionally-strange) import semantics" > Ian Lynagh **20091009184704 > Fri Oct 9 14:43:51 BST 2009 Malcolm.Wallace@cs.york.ac.uk > GHC (correctly) warns about the unused import, which breaks the > validate > build. > ] > [It seems that nhc98 needs defaulting in Data.Fixed. > Malcolm.Wallace@cs.york.ac.uk**20091009135242] > [Another instance of nhc98's strange import semantics. > Malcolm.Wallace@cs.york.ac.uk**20091009135051] > [Make Data.Functor compatible with non-GHC compilers. > Malcolm.Wallace@cs.york.ac.uk**20091009134821] > [Cope with nhc98's (occasionally-strange) import semantics. > Malcolm.Wallace@cs.york.ac.uk**20091009134351] > [Fix gratuitous breakage of nhc98 in System.IO. > Malcolm.Wallace@cs.york.ac.uk**20091009134001] > [Fix gratuitous breakage of nhc98 in Control.Exception.Base. > Malcolm.Wallace@cs.york.ac.uk**20091009133615] > [Fix gratuitous breakage of non-GHC in Data.Fixed. > Malcolm.Wallace@cs.york.ac.uk**20091009133330] > [Fix gratuitous breakage for non-GHC in Data.Bits. > Malcolm.Wallace@cs.york.ac.uk**20091009133257] > [Use UTF-32LE instead of UTF32LE > Simon Marlow **20091006100207 > Ignore-this: 7f881e36543d250ef848c9f60d67655a > The latter is not recognised by some iconv implementations. > ] > [Strip any Byte Order Mark (BOM) from the front of decoded streams. > Ben.Lippmeier@anu.edu.au*-20090930084229 > Ignore-this: d0d0c3ae87b31d71ef1627c8e1786445 > When decoding to UTF-32, Solaris iconv inserts a BOM at the front > of the stream, but Linux iconv doesn't. > ] > [use UTF32BE/UTF32LE instead of UCS-4/UCS-4LE > Simon Marlow **20091005101554 > Ignore-this: 2aef5e9bec421e714953b7aa1bdfc1b3 > ] > [Strip any Byte Order Mark (BOM) from the front of decoded streams. > Ben.Lippmeier@anu.edu.au**20090930084229 > Ignore-this: d0d0c3ae87b31d71ef1627c8e1786445 > When decoding to UTF-32, Solaris iconv inserts a BOM at the front > of the stream, but Linux iconv doesn't. > ] > [Add traceEvent :: String -> IO () > Simon Marlow **20090925141257 > Ignore-this: 8b1888bbf9682ffba13f815b6000e4b1 > For emitting an event via the RTS tracing framework > ] > [Fix the error message when flushing the read buffer of a non- > seekable Handle > Simon Marlow **20090923090536 > Ignore-this: 4342026df93759d99480f4e13f80a492 > ] > [Fix #3534: No need to flush the byte buffer when setting binary mode > Simon Marlow **20090923090445 > Ignore-this: 625817ed7ae2c12291eb993a99dc640a > ] > [Use let !y = x in .. x .. instead of seq in $! and evaluate (#2273) > Simon Marlow **20090916140454] > [make some Applicative functions into methods, and split off > Data.Functor (proposal #3335) > Ross Paterson **20090915173109 > Ignore-this: a0cff4de6dfdbcbd56a66101bc4855a9 > > The following functions > > (<$) :: Functor f => a -> f b -> f a > (*>) :: Applicative f => f a -> f b -> f b > (<*) :: Applicative f => f a -> f b -> f a > some :: Alternative f => f a -> f [a] > many :: Alternative f => f a -> f [a] > > are moved into the corresponding classes, with the existing > implementations > as default definitions. This gives people creating instances the > option of > defining specialized implementations of these functions, though they > should > be equivalent to the default definitions. > > Although (<$) is now a method of the Functor class, it is hidden in > the > re-export by the Prelude, Control.Monad and Monad. The new module > Data.Functor exposes the full class, plus the function (<$>). These > are > also re-exported by Control.Applicative. > ] > [On Windows, use the console code page for text file encoding/ > decoding. > Judah Jacobson **20090913022126 > Ignore-this: 86c2f2db8ef92b751599795d3195187b > > We keep all of the code page tables in the module > GHC.IO.Encoding.CodePage.Table. That file was generated automatically > by running codepages/MakeTable.hs; more details are in the comments > at the > start of that script. > > Storing the lookup tables adds about 40KB to each statically linked > executable; > this only increases the size of a "hello world" program by about 7%. > > Currently we do not support double-byte encodings (Chinese/Japanese/ > Korean), since > including those codepages would increase the table size to 400KB. > It will be > straightforward to implement them once the work on library DLLs is > finished. > ] > [Fix "init" docs: the input list need not be finite. Fixes trac #3465 > Ian Lynagh **20090911210437] > [Bump base version to 4.2.0.0 > Ian Lynagh **20090911153913] > [Address #3310 > Simon Marlow **20090830152850 > Ignore-this: 40c7f7c171ee299a83092fd360a952b7 > > - Rename BlockedOnDeadMVar -> BlockedIndefinitelyOnMVar > - Rename BlockedIndefinitely -> BlockedIndefinitelyOnSTM > - instance Show BlockedIndefinitelyOnMVar is now > "blocked indefinitely in an MVar operation" > - instance Show BlockedIndefinitelyOnSTM is now > "blocked indefinitely in an STM transaction" > > clients using Control.OldException will be unaffected (the new > exceptions are mapped to the old names). However, for base4-compat > we'll need to make a version of catch/try that does a similar > mapping. > ] > [Fix unicode conversion for MSB architectures > Ben.Lippmeier@anu.edu.au**20090830130028 > This fixes the SPARC/Solaris build. > ] > [Fix #3441: detect errors in partial sequences > Simon Marlow **20090830075909 > Ignore-this: d12a75d95e0cae5eb1555266810ec281 > ] > [Fix hWaitForInput > Simon Marlow **20090827152116 > Ignore-this: 2550e911f1a4d4357a5aa8d1764238ce > It was erroneously waiting when there were bytes to decode waiting in > the byte buffer. > ] > [fix debugging code > Simon Marlow **20090827150628 > Ignore-this: e1c82fdc19a22e247cd69ff6fa11921d > ] > [Allow for configurable iconv include and library locations. > Matthias Kilian **20090826154406 > Ignore-this: be95fab611a5534cf184b508964ed498 > This should help to fix the build on OpenBSD. > ] > [typo in comment > Simon Marlow **20090826085252 > Ignore-this: 1903ee0f354157a6ed3871c100f6b1b9 > ] > [un-hide some modules from the Haddock docs > Simon Marlow **20090825152457 > Ignore-this: dce6606f93cf977fb24ebe99082dfa62 > ] > [Apply fix for #1548, from squadette@gmail.com > Simon Marlow **20090819120700 > Ignore-this: 31c237c46a6445f588ed4b8c51bb6231 > ] > [improvements to Data.Fixed: instances for Typeable and Data, more > predefined types > Ashley Yakeley **20090812055058 > Ignore-this: feeece36d5632f02a05d137d2a39ab78 > ] > [Fix "Cabal check" warnings > Ian Lynagh **20090811215856] > [Add a GHC.Constants module; fixes trac #3094 > Ian Lynagh **20090809183252] > [Apply proposal #3393 > Ian Lynagh **20090809134717 > Add openTempFileWithDefaultPermissions and > openBinaryTempFileWithDefaultPermissions. > ] > [Add some more C wrappers; patch from Krister Walfridsson > Ian Lynagh **20090807200631 > Fixes 21 testsuite errors on NetBSD 5.99. > ] > [Fixing configure for autoconf 2.64 > Alexander Dunlap **20090805060748 > Ignore-this: 992ab91ae3d68c12dbb265776e33e243 > ] > [add INLINE toList > Ross Paterson **20090806142853 > Ignore-this: aba16aabb17d5dca44f15d188945680e > > In anticipation of the fixing of #2353. > ] > [fix a copyright > Simon Marlow **20090805134045 > Ignore-this: b0ffbdd38fbba121e8bcba37c4082a60 > ] > [Tweak the BufferedIO class to enable a memory-mapped file > implementation > Simon Marlow **20090805134036 > Ignore-this: ec67d7a0a6d977438deaa342503f77e0 > We have to eliminate the assumption that an empty write buffer can be > constructed by setting the buffer pointers to zero: this isn't > necessarily the case when the buffer corresponds to a memory-mapped > file, or other in-memory device implementation. > ] > [Deprecate Control.OldException > Ian Lynagh **20090804143910] > [Windows build fix, following RTS tidyup > Simon Marlow **20090803131121 > Ignore-this: ce862fb91c2b234211a8757f98690778 > ] > [Updates to follow the RTS tidyup > Simon Marlow **20090801220743 > Ignore-this: 6e92412df93a66c12d75344053d5634 > C functions like isDoubleNaN moved here (primFloat.c) > ] > [Add integer-simple as a build option > Ian Lynagh **20090722013151] > [Use shift[LR]Integer in the Bits Integer instance > Ian Lynagh **20090721222440] > [depend directly on integer-gmp, rather than indirecting through > integer > Ian Lynagh **20090721185228] > [Move the instances of Functor and Monad IO to GHC.Base, to avoid > orphans > Simon Marlow **20090722102130 > Ignore-this: a7d85ac0025d559674249de0108dbcf4 > ] > [move "instance Exception Dynamic" so it isn't an orphan > Simon Marlow **20090721093854 > Ignore-this: 5ede91ecfec2112c91b699d4de87cd02 > ] > [Improve the index checking for array accesses; fixes #2120 #2669 > Ian Lynagh **20090719153228 > As well as checking that offset we are reading is actually inside the > array, we now also check that it is "in range" as defined by the Ix > instance. This fixes confusing behaviour (#2120) and improves some > error > messages (#2669). > ] > [Make chr say what its argument was, if it's a bad argument > Ian Lynagh **20090718151049] > [remove unused warning > Simon Marlow **20090715124416 > Ignore-this: 31f613654089d0f4a44363946087b41e > ] > [warning fix: -fno-implicit-prelude -> -XNoImplicitPrelude > Simon Marlow **20090715122839 > Ignore-this: dc8957249731d5bcb71c01899e5adf2b > ] > [Add hGetEncoding :: Handle -> IO (Maybe TextEncoding) > Simon Marlow **20090715122519 > Ignore-this: 14c3eff996db062da1199739781e4708 > as suggested during the discussion on the libraries list > ] > [Add more documentation to mkTextEncoding > Simon Marlow **20090715122414 > Ignore-this: 97253b2624267df3a246a18121e8ea81 > noting that "//IGNORE" and "//TRANSLIT" suffixes can be used with GNU > iconv. > ] > [Add the utf8_bom codec > Simon Marlow **20090715122257 > Ignore-this: 1c9396cd805201fe873a39382ced79c7 > as suggested during the discussion on the libraries list. > ] > [Export Unicode and newline functionality from System.IO; update > Haddock docs > Simon Marlow **20090713113104 > Ignore-this: c3f017a555335aa55d106253393f72e2 > ] > [add a comment about the non-workingness of CHARBUF_UTF16 > Simon Marlow **20090707124406 > Ignore-this: 98d00411b68d688b3b4cffc9507b1f35 > ] > [Fix build on Windows > Ian Lynagh **20090711004351] > [Fix some "warn-unused-do-bind" warnings where we want to ignore the > value > Ian Lynagh **20090710204513] > [Use throwErrnoIfMinus1_ when calling getrusage > Ian Lynagh **20090710204221] > [Remove an unused import > Ian Lynagh **20090710153345] > [reportStackOverflow now returns IO () > Ian Lynagh **20090710153257 > It used to do "return undefined" to return IO a. > ] > [GHC.Conc.reportError now returns IO () > Ian Lynagh **20090710152646 > It used to return IO a, by "return undefined". > ] > [Fix some "warn-unused-do-bind" warnings where we want to ignore the > value > Ian Lynagh **20090710152526] > [Minor SampleVar refactoring > Ian Lynagh **20090710151438] > [Fix "warn-unused-do-bind" warnings in GHC/IO/Handle/Text.hs > Ian Lynagh **20090710122905] > [Fix some "warn-unused-do-bind" warnings where we just want to > ignore the result > Ian Lynagh **20090710005638] > [Use the result of writeCharBuf in GHC/IO/Encoding/Latin1.hs too > Ian Lynagh **20090710004032] > [Minor code tidyups in GHC.Conc > Ian Lynagh **20090710003801] > [Fix "warn-unused-do-bind" warning in GHC.Conc > Ian Lynagh **20090710003530 > If we fail to communicate with the IO manager then we print a warning > using debugErrLn from the ghc-prim package. > ] > [Fix "warn-unused-do-bind" warnings in System.Posix.Internals > Ian Lynagh **20090709164546] > [Fix "warn-unused-do-bind" warnings where we really do want to > ignore the result > Ian Lynagh **20090709163912] > [Add back imports needed on Windows > Ian Lynagh **20090707181924] > [Remove unused imports > Ian Lynagh **20090707115810] > [Remove unused imports from base > simonpj@microsoft.com**20090706111842 > Ignore-this: f9b5f353e3bb820f787c56d615b28765 > > These unused imports are detected by the new unused-import code > > ] > [Use the result of writeCharBuf > Simon Marlow **20090706133303 > Ignore-this: 52288dd559bf4c4f313df6197091d935 > > This only makes a difference when CHARBUF_UTF16 is in use, which it > normally isn't. I suspect CHARBUF_UTF16 doesn't currently work for > other reasons (CHARBUF_UTF16 was an experiment before I wrote the > GHC.IO.Encoding.UTF* codecs), but this patch at least makes it > slightly closer to working. > ] > [Remove some cruft from Data.HashTable > Ian Lynagh **20090706181630] > [Add 'eof' to Text.ParserCombinators.ReadP > simonpj@microsoft.com**20090706111801 > Ignore-this: 2aea7b848e00c894761bc4011adaa95d > > Add a ReadP parser that succeeds at the end of input. Very useful! > > ] > [Don't export CLDouble for GHC; fixes trac #2793 > Ian Lynagh **20090705155120 > We never really supported CLDouble (it was a plain old double > underneath), > and pretending that we do does more harm than good. > ] > [a byte between 0x80 and 0xBF is illegal immediately (#3341) > Simon Marlow **20090702081415 > Ignore-this: dc19ef59a1a21118d5a7dd38aa2f611c > ] > [avoid a warning > Simon Marlow **20090630084134 > Ignore-this: c92a45ee216faf01327feae9fe06d6e2 > ] > [Add a wrapper for libiconv. > Matthias Kilian **20090629183634 > Ignore-this: 23c6047c0d71b745b495cc223574a47f > ] > [#include if we have it (should fix build problems) > Simon Marlow **20090629085351 > Ignore-this: a35e93b37ca9595c73460243180f4b9d > ] > [set binary mode for existing FDs on Windows (fixes some GHCi test > failures) > Simon Marlow **20090626120522 > Ignore-this: 580cf636e9c77d8427aff6861d089481 > ] > [Move directory-related stuff to the unix package > Simon Marlow **20090625120325 > Ignore-this: b997b3cbce0a46ca87ad825bbdc0a411 > now that it isn't used on Windows any more. > ] > [TAG 2009-06-25 > Ian Lynagh **20090625160056] > Patch bundle hash: > e934807d5e23dd06c0f5be2a213b0806d2fd4810 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEAREKAAYFAktHqCAACgkQvpDo5Pfl1oJfFwCeOmXae1y/6CH9/OJgHjvsHbab > 2QwAoISiWb+2BMZcFiOthLO//z88mHqs > =vKR7 > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From gwern0 at gmail.com Fri Jan 8 22:08:07 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Jan 8 21:40:53 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> Message-ID: On Fri, Jan 8, 2010 at 9:54 PM, Jeremy Shaw wrote: > Not sure if this came up already, but there is a less general version of > void in Foreign.Marshal.Error: > > http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Foreign-Marshal-Error.html#v%3Avoid > > void :: IO a -> IO () > ? ? Discard the return value of an IO action > > Are there plans to unify the two? Perhaps Foreign.Marshal.Error can just > re-export void from Control.Monad? > > - jeremy Don brought it up, and it's a consideration behind picking the name 'void'. Re-exporting with the type signature (ie. rewrite it to be void :: IO a -> IO (); void = Control.Monad.void) is easy and won't break anything; it's something that can be done after Control.Monad.void has been added. One thing at a time. -- gwern From ekmett at gmail.com Fri Jan 8 22:21:07 2010 From: ekmett at gmail.com (Edward Kmett) Date: Fri Jan 8 21:53:53 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> Message-ID: <7fb8f82f1001081921nfec84b5x82188202d4719807@mail.gmail.com> Yes, though if you add the type signature in Foreign.Marshal.Error then if someone had existing code that looks like: import Foreign.Marshal.Error import Control.Monad blah blah void blah then it'll conflict. Left with the more permissive type signature that would just work. -Edward Kmett On Fri, Jan 8, 2010 at 10:08 PM, Gwern Branwen wrote: > On Fri, Jan 8, 2010 at 9:54 PM, Jeremy Shaw wrote: > > Not sure if this came up already, but there is a less general version of > > void in Foreign.Marshal.Error: > > > > > http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Foreign-Marshal-Error.html#v%3Avoid > > > > void :: IO a -> IO () > > Discard the return value of an IO action > > > > Are there plans to unify the two? Perhaps Foreign.Marshal.Error can just > > re-export void from Control.Monad? > > > > - jeremy > > Don brought it up, and it's a consideration behind picking the name 'void'. > > Re-exporting with the type signature (ie. rewrite it to be void :: IO > a -> IO (); void = Control.Monad.void) is easy and won't break > anything; it's something that can be done after Control.Monad.void has > been added. One thing at a time. > > -- > gwern > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20100108/fe7d8b05/attachment.html From dons at galois.com Sat Jan 9 20:38:08 2010 From: dons at galois.com (Don Stewart) Date: Sat Jan 9 20:10:59 2010 Subject: X11 missing source repo(?) In-Reply-To: <3a6f89fc1001020830p1d4e8132xce759988c8659bc6@mail.gmail.com> References: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> <3a6f89fc1001020830p1d4e8132xce759988c8659bc6@mail.gmail.com> Message-ID: <20100110013808.GP32473@whirlpool.galois.com> Send patches to me against the new X11 repo at http://code.haskell.org/X11 martine: > On Sat, Jan 2, 2010 at 5:32 AM, Gwern Branwen wrote: > > On Sat, Jan 2, 2010 at 1:08 AM, Evan Martin wrote: > >> I'd like to make a patch for the X11 package. > >> > >> I found http://hackage.haskell.org/package/X11 , which references > >> http://code.haskell.org/X11/ , which appears to be empty. ?Did > >> something go wrong? > >> > >> If it helps any, the change is trivial (just want to get at the Visual > >> pointer from another package, much in the way Display and Screen are > >> exposed). > >> I'd be happy to make a Darcs format patch if you'd prefer that. > > > > The old repo is at *darcs*.haskell.org; it's apparently being moved to > > c.h.o (so as to be able to give more people the commit-bit), but > > hasn't yet been actually moved. > > Thanks. Same patch now attached. > > > Having written this, what would probably be even cleaner is to have > - Graphics.X11.Xlib.Types expose abstract Display, Visual etc and > their typeclass instances > - an extra Graphics.X11.Xlib.Internals that provides functions to go > from Display -> Ptr Display, etc > > However, this would be both a non-backwards-compatible change > (currently Display is exposed as a newtype) and I lack the Haskell-fu > to write such a change (like, the newtype would need to go into > .Internals but then the deriving declaration should be in .Types?). > Sat Jan 2 08:21:30 PST 2010 Evan Martin > * Expose Visual pointer > > We already expose the underlying Ptr for Display; I'd like > to be able to get at the Ptr for Visual as well. > > > New patches: > > [Expose Visual pointer > Evan Martin **20100102162130 > Ignore-this: 104a378b987382b583a1add6cf6fb460 > > We already expose the underlying Ptr for Display; I'd like > to be able to get at the Ptr for Visual as well. > > ] hunk ./Graphics/X11/Xlib/Types.hsc 18 > > -- #hide > module Graphics.X11.Xlib.Types( > - Display(..), Screen(..), Visual, GC, GCValues, SetWindowAttributes, > + Display(..), Screen(..), Visual(..), GC, GCValues, SetWindowAttributes, > Image(..), Point(..), Rectangle(..), Arc(..), Segment(..), Color(..), > Pixel, Position, Dimension, Angle, ScreenNumber, Buffer > ) where > > Context: > > [Remove weird character in comment. May fix building with hsc2hs on 6.12 > Spencer Janssen **20091125002712 > Ignore-this: ef1b32d6bb9ed22cb09a63b35a64d231 > ] > [Add XGetModifierMapping binding > Spencer Janssen **20091103214200 > Ignore-this: c22c6efc472d3a2d9bdd6c81b7d84f4d > ] > [KeyCode should be a byte, not a Unicode Char > Spencer Janssen **20091103211642 > Ignore-this: e53bc8b64fd12247ce907c710e293b67 > ] > [Escape path / from haddock > Adam Vogt **20091115212213 > Ignore-this: 2ccd8b59a6c75beb609abf3e7b4ca722 > ] > [De-orphan the Read Rectangle instance > Adam Vogt **20091115212115 > Ignore-this: 2ac94627adef450b7aec291a50878f43 > ] > [ExportScreenDataConstructor > arsenm2@rpi.edu**20091107202100 > Ignore-this: 4b8c1886a9f0acfcfb13fa7f421d0c13 > ] > [Move build-type from wrong stanza > Don Stewart **20091005014719] > [Add minimum cabal version > Don Stewart **20091005014343] > [Refactor cabal file. And enable support for syb generics. > Don Stewart **20091005013359] > [We can relax the versioning constraint on base. > Don Stewart **20091004231553] > [Bump configure.ac to 1.4.6 > Don Stewart **20091004225102] > [haskell-x11: export Cursor in Xlib.hs > Andres Salomon **20090915162318 > Ignore-this: 77e1afa7994d1d0a3396dac2f7b37d27 > > Whoops, I forgot to export the cursors along w/ the rest of Xlib. > > ] > [Some extra fields, bump the version. > Don Stewart **20090915161044] > [haskell-x11: add and export the list of cursors > Andres Salomon **20090915155708 > Ignore-this: 995cede8cdd8830a2c0bb6c63b8229b9 > > Pulled in from X11/cursorfont.h, export things like xC_X_cursor and > xC_left_ptr for things like createFontCursor to use. > > ] > [TAG 1.4.5 > Spencer Janssen **20081203050348 > Ignore-this: d8112e4ff25ec56fe5ac2cdc9fa1ead > ] > [Bump version to 1.4.5 > Spencer Janssen **20081203050251 > Ignore-this: 665f8093d82bef9e6b13bf1e4db74e1d > ] > [Bump configure.ac to 1.4.4 as well > Spencer Janssen **20081203050154 > Ignore-this: ef3fabf26fc7dbfdb6dfaa92073e3c9e > ] > [Fix memory leak in getWMHints > Spencer Janssen **20081125221512 > Ignore-this: dacc19acbb60e13d945509cde0551bc8 > ] > [more precise X11 deps > Don Stewart **20081011211930] > [TAG 1.4.3 > Spencer Janssen **20080921082528] > [Bump version to 1.4.3 > Spencer Janssen **20080921054954] > [getCommand > Marco T?lio Gontijo e Silva **20080712154521] > [X implementation dependent keysyms from X.org > zythmer@gmail.com**20080528004224 > > Added all of the X keysyms from X.org except the groups XK_MISCELLANY and > XK_LATIN1 as well as skipped XK_VoidSymbol since it is not in any group. > The above groups and symbol are already in Graphics.X11.Types > ] > [Make sure both --with-xinerama and --without-xinerama works > Lennart Kolmodin **20080524112224 > Use the builtin variable with_xinerama instead of our want_xinerama. > This gives us ability to use both --with-xinerama and --without-xinerama. > ] > [Use -auto-all when profiling > Don Stewart **20080413112039] > [Update configure.ac with new version number > Lennart Kolmodin **20080331184021] > [Add setKeyEvent to Graphics.X11.Xlib.Extras > J?r?my Bobbio **20080328214753] > [TAG 1.4.2 > Spencer Janssen **20080327193813] > [Bump version number to 1.4.2 > Spencer Janssen **20080327193755] > [Handle a NULL retrun from XGetWMHints correctly, fixes a segfault bug > Spencer Janssen **20080327192702] > [update version info > Don Stewart **20080307190921] > [comments > Don Stewart **20080307190910] > [Remove -O2 from ghc-options > Spencer Janssen **20071216001612] > [TAG 1.4.1 > Spencer Janssen **20071211042441] > [Bump version to 1.4.1 > Spencer Janssen **20071211042430] > [Check the return value of XGetWindowProperty, this fixes crash bugs when the requested Window/Property does not exist > Spencer Janssen **20071211041940] > [Update installation instructions to use newer Cabal's --configure-option > Alec Berryman **20071120214634] > [Remove obsolete INSTALL file; installation instructions are in README > Alec Berryman **20071120203353] > [Remove redundant XIconifyWindow binding > Spencer Janssen **20071208084849] > [Added haddock docs to setErrorHandler; added XIconifyWindow and XMapRaised bindings > hoelz@wisc.edu**20071202043806] > [use a working header file for XSetErrorHandler > Lukas Mai **20071129174529] > [Implemented a full binding to XSetErrorHandler > hoelz@wisc.edu**20071127011847] > [TAG 1.4.0 > Don Stewart **20071125032528] > [bump X11 version to 1.4.0 > Don Stewart **20071125032135] > [add copyright info and year for Graphics/X11/Xlib/Extras.hsc > Don Stewart **20071121024752] > [bump to snapshot tag > Don Stewart **20071111200531] > [Fix bug in the type of functions dealing with properties > Mats Jansborg **20071101190154 > > The documentation for XGetWindowProperty and XChangeProperty states > that the data must be represented as an array of char, short and long > for a format of 8, 16 and 32 respectively. Previously Word8, Word16 > and Word32 were used, resulting in bugs on platforms where char is not > 8 bits, short 16 bits and long 32 bits wide. > ] > [home instead of $USER > Don Stewart **20071101212016] > [space in CPPFLAGS will break .buildinfo file > Don Stewart **20071031172720] > [add CPPFLAGS and LDFLAGS to buildinfo file > Don Stewart **20071031172436] > [formatting > Don Stewart **20071031171257] > [license header for Xinerama > Don Stewart **20071031165900] > [untabify > Don Stewart **20071031165743] > [#!-able Setup.lhs > Don Stewart *-20071030173235] > [bump version > Don Stewart **20071030213949] > [Bump version number > Ian Lynagh **20071027124814] > [#!-able Setup.lhs > Don Stewart **20071030173235] > [TAG X11-1.3.0 > Don Stewart **20071030172832] > [wall police > Don Stewart **20071030171430] > [cabal tweaks > Don Stewart **20071030171341] > [wall police > Don Stewart **20071029205511] > [Bug fix: not storing height in XSizeHints.resize_inc > Don Stewart **20071029202844] > [-Wall police > Don Stewart **20071029202542] > [clean up warnings > Don Stewart **20071029201214] > [wrong header included, hidden by -fasm > Don Stewart **20071029184208] > [no .lhs Setup script > Don Stewart **20071029183618] > [Xutils.h -> Xutil.hs > Don Stewart **20071029183435] > [more info in readme > Don Stewart **20071029182528] > [more typos in the merged .cabal file > Don Stewart **20071029182349] > [duplicate line in .cabal file > Don Stewart **20071029181942] > [Merge in X11-extras package, bump to 1.3.0. Adds Xinerama and X event support. > Don Stewart **20071029175855] > [TAG 1.2.3 > Don Stewart **20071012181748] > Patch bundle hash: > 1d5bd93f53f363a8d3703a443424750517f6ad58 > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From dominic at steinitz.org Sun Jan 10 06:07:42 2010 From: dominic at steinitz.org (Dominic Steinitz) Date: Sun Jan 10 05:43:03 2010 Subject: Make Happy Explicitly Depend on Perl Message-ID: <4B49B4FE.4010802@steinitz.org> Probably no-one has ever built happy on a machine without perl so this has never been noticed. I think it's more polite to fail at the configure stage rather than the build stage. In the cabal file I think we should have > build-tools: perl Here's a patch. Regards, Dominic. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch040110v1 Type: application/octet-stream Size: 16521 bytes Desc: not available Url : http://www.haskell.org/pipermail/libraries/attachments/20100110/c4fa0c18/patch040110v1-0001.obj From allbery at ece.cmu.edu Sun Jan 10 14:44:56 2010 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Jan 10 14:17:49 2010 Subject: Make Happy Explicitly Depend on Perl In-Reply-To: <4B49B4FE.4010802@steinitz.org> References: <4B49B4FE.4010802@steinitz.org> Message-ID: On Jan 10, 2010, at 06:07 , Dominic Steinitz wrote: > Probably no-one has ever built happy on a machine without perl so this > has never been noticed. I think it's more polite to fail at the More likely, it's because until fairly recently ghc required perl (for the Evil Mangler). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/libraries/attachments/20100110/0d47b696/PGP.bin From ndmitchell at gmail.com Sun Jan 10 16:44:44 2010 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Jan 10 16:17:28 2010 Subject: Make Happy Explicitly Depend on Perl In-Reply-To: References: <4B49B4FE.4010802@steinitz.org> Message-ID: <404396ef1001101344k401ce097n3e7adf643226a349@mail.gmail.com> >> Probably no-one has ever built happy on a machine without perl so this >> has never been noticed. I think it's more polite to fail at the > > More likely, it's because until fairly recently ghc required perl (for the > Evil Mangler). I have noticed and reported this in the past. On Windows GHC installs Perl, but doesn't put it on the %PATH%, which causes building happy to fail on a default Windows install of GHC. Thanks, Neil From duncan.coutts at googlemail.com Mon Jan 11 11:09:51 2010 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon Jan 11 10:42:33 2010 Subject: Make Happy Explicitly Depend on Perl In-Reply-To: <4B49B4FE.4010802@steinitz.org> References: <4B49B4FE.4010802@steinitz.org> Message-ID: <1263226191.4399.25831.camel@localhost> On Sun, 2010-01-10 at 11:07 +0000, Dominic Steinitz wrote: > Probably no-one has ever built happy on a machine without perl so this > has never been noticed. I think it's more polite to fail at the > configure stage rather than the build stage. In the cabal file I think > we should have I've been meaning for some time to exorcise perl from the happy build. The little bit of substituting could fairly easily be done in Haskell code in the Setup.hs rather than calling perl. As Neil says, this would also help Windows users. Perhaps someone else has the time to give that a go. In the mean time "build-tools: perl" is of course correct. Duncan From jeremy at n-heptane.com Mon Jan 11 22:49:07 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Mon Jan 11 22:21:47 2010 Subject: opening a file for writing and reading Message-ID: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> Hello, I am trying to write a program which logs an IRC channel, and makes the log life available via HTTP. Currently I open the log file for writing in AppendMode, and keep it open, writing new lines as they come. I open the file for reading using withBinaryFile and ReadMode. Alas, I get the error, openBinaryFile: resource busy (file is locked). What is the proper work around for this? I could only open the file for writing when I actually have something to write, and then close it afterwards. But that still leaves a race condition if I try to write the file while it is being served or read the file while it is being updated. The read and writing are both done in the same application, but in different parts of the code. There is no way to share the file handle between the two parts. Thanks! - jeremy From bos at serpentine.com Mon Jan 11 23:22:38 2010 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Jan 11 22:55:20 2010 Subject: opening a file for writing and reading In-Reply-To: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> References: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> Message-ID: On Mon, Jan 11, 2010 at 7:49 PM, Jeremy Shaw wrote: > Alas, I get the error, openBinaryFile: resource busy (file is locked). > > What is the proper work around for this? > This behaviour is specified in the Haskell standard. I don't know what the rationale is intended to be, but I don't like the behaviour either. I believe you can work around it by using System.Posix.IO to open a file, then convert the Fd to a Handle. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20100111/8d7af1fc/attachment.html From duncan.coutts at googlemail.com Tue Jan 12 06:03:05 2010 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Jan 12 05:35:45 2010 Subject: opening a file for writing and reading In-Reply-To: References: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> Message-ID: <1263294185.4399.31894.camel@localhost> On Mon, 2010-01-11 at 20:22 -0800, Bryan O'Sullivan wrote: > On Mon, Jan 11, 2010 at 7:49 PM, Jeremy Shaw > wrote: > Alas, I get the error, openBinaryFile: resource busy (file is > locked). > > What is the proper work around for this? > > > This behaviour is specified in the Haskell standard. I don't know what > the rationale is intended to be, but I don't like the behaviour > either. I think in general it's to help you not shoot yourself in the foot by having one part of the code write over stuff you're in the middle of reading. In particular this would help for programs of the form $ ./prog foo -o foo where it ends up using the same file as both input and output. If this was what you actually intended to do then of course you can use the same single read/write file handle. There's also a specific case where it stops you shooting yourself in the foot. A file handle that you're using with hGetContents really should not change underneath you. That's why it gets put into the semi-closed state. But if you could have other open write handles to the same file then you can still shoot yourself in the foot and write weirdy non-deterministic programs. > I believe you can work around it by using System.Posix.IO to open a > file, then convert the Fd to a Handle. Right, you can bypass the safety mechanism that way. Duncan From duncan.coutts at googlemail.com Tue Jan 12 06:05:14 2010 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Tue Jan 12 05:37:54 2010 Subject: X11 missing source repo(?) In-Reply-To: <20100110013808.GP32473@whirlpool.galois.com> References: <3a6f89fc1001012208s3f1e37bfv34c5ddd4de70db77@mail.gmail.com> <3a6f89fc1001020830p1d4e8132xce759988c8659bc6@mail.gmail.com> <20100110013808.GP32473@whirlpool.galois.com> Message-ID: <1263294314.4399.31912.camel@localhost> On Sat, 2010-01-09 at 17:38 -0800, Don Stewart wrote: > Send patches to me against the new X11 repo at http://code.haskell.org/X11 If you feel you can make X11 require "cabal-version: >=1.6" then you can add a source repo section to the .cabal file and thereby reduce confusion about where the sources live (the link also gets displayed on the hackage page). Duncan From bulat.ziganshin at gmail.com Tue Jan 12 07:08:46 2010 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jan 12 06:41:27 2010 Subject: opening a file for writing and reading In-Reply-To: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> References: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> Message-ID: <1424457140.20100112150846@gmail.com> Hello Jeremy, Tuesday, January 12, 2010, 6:49:07 AM, you wrote: > different parts of the code. There is no way to share the file handle > between the two parts. that's technique used to make this impossible? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From alistair at abayley.org Tue Jan 12 15:43:11 2010 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 12 15:15:53 2010 Subject: ssh ports for monk and nun? Message-ID: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> Trying to get ssh working via putty from behind my company firewall. Had some success in the past with sourceforge because they had ssh daemons listening on ports 80 and 443, to aid prisoners like myself. Does anyone know if the monk (darcs.haskell.org) and nun (code.haskell.org) servers accept ssh on ports other than 22? Thanks, Alistair From alistair at abayley.org Tue Jan 12 15:54:31 2010 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 12 15:27:12 2010 Subject: [Haskell-cafe] ssh ports for monk and nun? In-Reply-To: <42784f261001121247p1cb93c11o6edaeecddb3c8887@mail.gmail.com> References: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> <42784f261001121247p1cb93c11o6edaeecddb3c8887@mail.gmail.com> Message-ID: <79d7c4981001121254y66b435fbjdac170a28dcb18a9@mail.gmail.com> 2010/1/12 Jason Dusek : > ?Monk and nun? The haskell.org code/project/... servers: http://www.haskell.org/haskellwiki/Haskell.org_domain From alistair at abayley.org Tue Jan 12 15:57:44 2010 From: alistair at abayley.org (Alistair Bayley) Date: Tue Jan 12 15:30:30 2010 Subject: ssh ports for monk and nun? In-Reply-To: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> References: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> Message-ID: <79d7c4981001121257i2a8a230elad85ba04b45b2ec6@mail.gmail.com> > Trying to get ssh working via putty from behind my company firewall. > Had some success in the past with sourceforge because they had ssh > daemons listening on ports 80 and 443, to aid prisoners like myself. > Does anyone know if the monk (darcs.haskell.org) and nun > (code.haskell.org) servers accept ssh on ports other than 22? I should also have said: I'm open to suggestions and advice on using darcs+cabal+ssh with restrictive firewalls and http proxies. I currently have cntlm (an authenticating proxy server) installed, so I can use cabal (and darcs get will work with this too), but I want to be able to push patches too. Alistair From jeremy at n-heptane.com Tue Jan 12 17:29:56 2010 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Jan 12 17:02:33 2010 Subject: opening a file for writing and reading In-Reply-To: <1263294185.4399.31894.camel@localhost> References: <9021781B-8BD5-4903-85C2-6D842C72A1E2@n-heptane.com> <1263294185.4399.31894.camel@localhost> Message-ID: On Jan 12, 2010, at 5:03 AM, Duncan Coutts wrote: >> I believe you can work around it by using System.Posix.IO to open a >> file, then convert the Fd to a Handle. > > Right, you can bypass the safety mechanism that way. Opening as Fd works, but converting to a Handle causes the error to come back. Fortunately, it was easy to modify the code to just stick with Fd, and portability to Windows is not a concern. thanks everyone! - jeremy From gwern0 at gmail.com Tue Jan 12 18:56:04 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Jan 12 18:28:40 2010 Subject: Adding an ignore function to Control.Monad In-Reply-To: References: <29bf512f0907111303o494a8cadgb139b7997de5bd49@mail.gmail.com> <1247392338-sup-3371@ausone.home> <200907171543.08914.g9ks157k@acme.softbase.org> Message-ID: I'm pleased to note that thanks to Malcolm Wallace, the patch has been pushed: http://hackage.haskell.org/trac/ghc/ticket/3292#comment:7 Y'all can look forward to a 'void' in GHC 6.14, likely. -- gwern From twhitehead at gmail.com Wed Jan 13 10:26:19 2010 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed Jan 13 09:59:07 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> Message-ID: <201001131026.32107.twhitehead@gmail.com> On January 8, 2010 16:53:07 gwern0@gmail.com wrote: > Fri Jan 8 16:44:55 EST 2010 gwern0@gmail.com > * Control.Monad: +void :: f a -> f () > See http://hackage.haskell.org/trac/ghc/ticket/3292 > Turns m a -> m (). Lets one call functions for their side-effects without > having to get rid of their return values with '>> return ()'. Very useful > in many contexts (parsing, IO etc.); particularly good for 'forkIO' and > 'forM_', as they demand return types of 'IO ()' though most interesting IO > functions return non-(). I was wondering why forM_ cares about the return type, but then, when I checked the type signature, it seems to me like it doesn't forM_ :: Monad m => [a] -> (a -> m b) -> m () Perhaps forkIO and friends should be like this as well. Replace them with something like the following forkIO . (>> return ()) :: IO a -> IO ThreadId (presumably this would be optimized away?) Cheers! -Tyson PS: Note that I'm not saying there should be a void function, just wondering why all these functions that don't care about return type force it to be ()? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/libraries/attachments/20100113/9c658597/attachment.bin From gwern0 at gmail.com Wed Jan 13 10:48:39 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Jan 13 10:21:14 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: <201001131026.32107.twhitehead@gmail.com> References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> <201001131026.32107.twhitehead@gmail.com> Message-ID: On Wed, Jan 13, 2010 at 10:26 AM, Tyson Whitehead wrote: > I was wondering why forM_ cares about the return type, but then, when I > checked the type signature, it seems to me like it doesn't > > ?forM_ :: Monad m => [a] -> (a -> m b) -> m () > > Perhaps forkIO and friends should be like this as well. ?Replace them with > something like the following > > ?forkIO . (>> return ()) :: IO a -> IO ThreadId > > (presumably this would be optimized away?) > > Cheers! ?-Tyson > > PS: ?Note that I'm not saying there should be a void function, just wondering > why all these functions that don't care about return type force it to be ()? I think the idea is that the type forces the caller to explicitly deal with the return value, to avoid issues such as space leaks. Neil Mitchell has made a similar argument for >> forcing an explicit ignoring: http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.html -- gwern From dave at zednenem.com Wed Jan 13 12:07:20 2010 From: dave at zednenem.com (David Menendez) Date: Wed Jan 13 11:39:53 2010 Subject: darcs patch: Control.Monad: +void :: f a -> f () In-Reply-To: References: <4b47a943.1708c00a.3e0f.ffff9d4b@mx.google.com> <201001131026.32107.twhitehead@gmail.com> Message-ID: <49a77b7a1001130907t67147842wf52c78b461c7331d@mail.gmail.com> On Wed, Jan 13, 2010 at 10:48 AM, Gwern Branwen wrote: > On Wed, Jan 13, 2010 at 10:26 AM, Tyson Whitehead wrote: >> I was wondering why forM_ cares about the return type, but then, when I >> checked the type signature, it seems to me like it doesn't >> >> ?forM_ :: Monad m => [a] -> (a -> m b) -> m () >> >> Perhaps forkIO and friends should be like this as well. ?Replace them with >> something like the following >> >> ?forkIO . (>> return ()) :: IO a -> IO ThreadId >> >> (presumably this would be optimized away?) >> >> Cheers! ?-Tyson >> >> PS: ?Note that I'm not saying there should be a void function, just wondering >> why all these functions that don't care about return type force it to be ()? > > I think the idea is that the type forces the caller to explicitly deal > with the return value, to avoid issues such as space leaks. Neil > Mitchell has made a similar argument for >> forcing an explicit > ignoring: http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.html I've never found this argument particularly convincing. I'd much rather generalize the types of fork and forM_ than introduce more trivial functions like void. -- Dave Menendez From monnier at iro.umontreal.ca Wed Jan 13 11:01:15 2010 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Wed Jan 13 13:12:40 2010 Subject: ssh ports for monk and nun? References: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> <79d7c4981001121257i2a8a230elad85ba04b45b2ec6@mail.gmail.com> Message-ID: >> Trying to get ssh working via putty from behind my company firewall. My recommendation is to get access to an outside machine where you run an OpenVPN server on port 80 or 443. This will solve it "once and for all". But first, please complain loudly and repeatedly about the firewall being closed to port 22. Stefan From vvv at mts.com.ua Thu Jan 14 08:59:14 2010 From: vvv at mts.com.ua (Valery V. Vorotyntsev) Date: Thu Jan 14 08:31:46 2010 Subject: Iteratee (take, takeR): identical types, different signatures Message-ID: <87ockw9499.fsf@takeshi.umc.com.ua> On Thu, Jan 14, 2010 at 12:39 PM, Valery V. Vorotyntsev wrote: > I've noticed inconsistency in type signatures of take* functions > (Data.Iteratee.Base). > > Compare > take :: (SC.StreamChunk s el, Monad m) => > Int -> EnumeratorN s el s el m a > with > takeR :: (SC.StreamChunk s el, Monad m) => > Int -> > IterateeG s el m a -> > IterateeG s el m (IterateeG s el m a) > > The latter type is equivalent to > takeR :: (SC.StreamChunk s el, Monad m) => > Int -> EnumeratorN s el s el m a > since > type EnumeratorN s_outer el_outer s_inner el_inner m a = > IterateeG s_inner el_inner m a -> > IterateeG s_outer el_outer m (IterateeG s_inner el_inner m a) > > `take' and `takeR' functions are almost similar: the only difference > is that `take' always consume all the stream while `takeR' can finish > early. > > Iteratee library should not obscure the fact that type signatures of these > functions are identical. Please consider replacing > IterateeG s el m (IterateeG s el m a) > with > EnumeratorN s el s el m a Dear John, I've refactored `take' and `takeR'. The changes are: - Int argument removed from `step' sub-function - null, length and splitAt belong ListLike (LL), not StreamChunk (SC) - consistent naming used in both functions (s/chk/s/, s/stream/str/) -----BEGIN PATCH----- -------------- next part -------------- A non-text attachment was scrubbed... Name: iteratee-0.3.1_take-refactoring.patch Type: text/x-diff Size: 2732 bytes Desc: iteratee-0.3.1_take-refactoring.patch Url : http://www.haskell.org/pipermail/libraries/attachments/20100114/2628b0f1/iteratee-0.3.1_take-refactoring.bin -------------- next part -------------- -----END PATCH----- Code compiles. Proposed change does not affect semantics, AFAICT. I tested behavior with the following code snippet: -----BEGIN TEST----- module XXX where import Data.Iteratee import qualified Data.Iteratee as It test :: IO () test = sequence_ [ putStr (desc ++ " " ++ show n ++ " " ++ show c ++ "\t") >> runIter (joinI $ f n $ It.break (== c)) stream >>= print | n <- [7, 100], c <- "3cX", (f, desc) <- [(It.take, "take "), (takeR, "takeR")] ] where stream = Chunk "0123456789abcdef" -----END TEST----- PS: BTW, what does `R' suffix stand for (in takeR function name)? -- Best regards, vvv From valery.vv at gmail.com Thu Jan 14 09:08:40 2010 From: valery.vv at gmail.com (Valery V. Vorotyntsev) Date: Thu Jan 14 08:47:22 2010 Subject: Iteratee (take, takeR): identical types, different signatures In-Reply-To: <87ockw9499.fsf@takeshi.umc.com.ua> References: <87ockw9499.fsf@takeshi.umc.com.ua> Message-ID: > -----BEGIN PATCH----- > > -----END PATCH----- Gmail's web UI does strange things to inlined text attachments... Don't worry, the patch is still there. Just scroll to the bottom of the previous email. Thanks. -- vvv From bos at serpentine.com Fri Jan 15 17:36:16 2010 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Jan 15 17:08:46 2010 Subject: Recommended way to conditionally compile modules? Message-ID: I have a source base that contains a number of source files that use APIs that vary by platform: every platform provides select, most provide poll, BSDs provide kqueue, and Linux provides epoll. I already have autoconf tests for these functions, and I'd like to use the results of those autoconf checks to determine which modules to compile, but I am unable to figure out how to do this in my .cabal or .buildinfo file. (I *could* have explicit os conditionals in there, but that's ugly.) Right now, I'm just building all of the modules, and conditionally giving them bodies as follows: module System.Event.EPoll where #if defined(HAVE_EPOLL) ... #endif The trouble with this is twofold. I have to export everything in the module (because its contents vary depending on where I compile it), and the CPP macros there are ugly. Is there a better solution? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20100115/13059a8e/attachment.html From gracjanpolak at gmail.com Sat Jan 16 10:03:41 2010 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Sat Jan 16 09:36:31 2010 Subject: ANN: haxr 3000.5 and haxr-th 3000.5 Message-ID: Hello fellow haskellers, New release of HaXR 3000.5 availalble! HaXR is a library for writing XML-RPC client and server applications in Haskell. HaXR consists of two packages: haxr and haxr-th. The latter package contains the Template Haskell code used for automatically deriving XML-RPC struct representations for Haskell records. http://hackage.haskell.org/package/haxr Goodies in this release include: * UTF-8 encoding * HTTP 4000 and ByteStrings * HaXml dependency upgrade to 1.20 My request to The Powers: since I have no access rights to the HaXR home page http://www.haskell.org/haxr/ could we please move it to haskellwiki? Also the old repository http://darcs.haskell.org/haxr is now stale. Can we do something about this? Happy hacking! -- Gracjan From schlepptop at henning-thielemann.de Sat Jan 16 13:31:37 2010 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Sat Jan 16 13:04:35 2010 Subject: Recommended way to conditionally compile modules? In-Reply-To: References: Message-ID: <4B520609.3060506@henning-thielemann.de> Bryan O'Sullivan schrieb: > I have a source base that contains a number of source files that use > APIs that vary by platform: every platform provides select, most > provide poll, BSDs provide kqueue, and Linux provides epoll. I already > have autoconf tests for these functions, and I'd like to use the > results of those autoconf checks to determine which modules to > compile, but I am unable to figure out how to do this in my .cabal or > .buildinfo file. (I /could/ have explicit os conditionals in there, > but that's ugly.) > > Right now, I'm just building all of the modules, and conditionally > giving them bodies as follows: > > module System.Event.EPoll where > #if defined(HAVE_EPOLL) > ... > #endif > > The trouble with this is twofold. I have to export everything in the > module (because its contents vary depending on where I compile it), > and the CPP macros there are ugly. Is there a better solution? This means that modules with the same name have different set of functions, depending on OS? I think this is generally unsafe, because other packages would have to check what API to expect according to the OS. Whereever possible I try to use conditional Hs-Source-Dirs in Cabal for selecting OS specific modules, but all of the directories must contain the same set of module names and modules with the same name must have the same interface. If modules have different APIs then I would give them different names and put them even in different packages. Then, say, presence of package poll-bsd means to the package user, that BSD functionality is available. Whether he is actually running BSD or whether the package simulates BSD functions doesn't matter. From gracjanpolak at gmail.com Sat Jan 16 18:16:13 2010 From: gracjanpolak at gmail.com (Gracjan Polak) Date: Sat Jan 16 17:49:03 2010 Subject: ANN: haxr 3000.5 and haxr-th 3000.5 References: Message-ID: Gracjan Polak gmail.com> writes: > Also the > old repository http://darcs.haskell.org/haxr is now stale. Can we do something > about this? I did not make myself clear enough here, there is now a new repository at: http://code.haskell.org/haxr so the old one at d.h.o can be safely demolished to make more place for an intergalactic highway. From petersen at haskell.org Sun Jan 17 04:33:12 2010 From: petersen at haskell.org (Jens Petersen) Date: Sun Jan 17 04:05:35 2010 Subject: packedstring Message-ID: <9436bffe1001170133y6d7b8ba4h986e27287a59f0fd@mail.gmail.com> I needed to apply the follow patch to packedstring to install it with ghc-6.12.1 and cabal-install-0.8.0 on my machine: diff -u packedstring-0.1.0.1/packedstring.cabal\~ packedstring-0.1.0.1/packedstring.cabal --- packedstring-0.1.0.1/packedstring.cabal~ 2010-01-17 16:23:32.000000000 +1000 +++ packedstring-0.1.0.1/packedstring.cabal 2010-01-17 19:18:15.000000000 +1000 @@ -9,7 +9,7 @@ (Deprecated) Packed Strings. build-type: Simple Library - build-depends: base, array + build-depends: base >=4, array exposed-modules: Data.PackedString extensions: CPP (sorry gmail is probably going to mess I the patch header) Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20100117/95066112/attachment.html From leather at cs.uu.nl Sun Jan 17 16:37:47 2010 From: leather at cs.uu.nl (Sean Leather) Date: Sun Jan 17 16:10:27 2010 Subject: Recommended way to conditionally compile modules? In-Reply-To: <4B520609.3060506@henning-thielemann.de> References: <4B520609.3060506@henning-thielemann.de> Message-ID: <3c6288ab1001171337t3a5ef7a8k6af043b0ad46a94b@mail.gmail.com> Henning Thielemann wrote: > Bryan O'Sullivan schrieb: > > I have a source base that contains a number of source files that use APIs >> that vary by platform: every platform provides select, most provide poll, >> BSDs provide kqueue, and Linux provides epoll. I already have autoconf tests >> for these functions, and I'd like to use the results of those autoconf >> checks to determine which modules to compile, but I am unable to figure out >> how to do this in my .cabal or .buildinfo file. (I /could/ have explicit os >> conditionals in there, but that's ugly.) >> >> Right now, I'm just building all of the modules, and conditionally giving >> them bodies as follows: >> >> module System.Event.EPoll where >> #if defined(HAVE_EPOLL) >> ... >> #endif >> >> The trouble with this is twofold. I have to export everything in the >> module (because its contents vary depending on where I compile it), and the >> CPP macros there are ugly. Is there a better solution? >> > This means that modules with the same name have different set of functions, > depending on OS? I think this is generally unsafe, because other packages > would have to check what API to expect according to the OS. > I agree. This definitely causes problems. In fact, I believe just such CPP results in difficulty using the network package with Happstack on the Mac by ifdef-ing out the IPv6 support. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/64540 Whereever possible I try to use conditional Hs-Source-Dirs in Cabal for > selecting OS specific modules, but all of the directories must contain the > same set of module names and modules with the same name must have the same > interface. > If modules have different APIs then I would give them different names and > put them even in different packages. Then, say, presence of package poll-bsd > means to the package user, that BSD functionality is available. Whether he > is actually running BSD or whether the package simulates BSD functions > doesn't matter. > Another option is to move the CPP to Haskell, so that all the functions are the same and the capability check is dynamic. This isn't necessarily better, of course. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20100117/534b27f4/attachment.html From gwern0 at gmail.com Mon Jan 18 19:35:41 2010 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Mon Jan 18 19:08:00 2010 Subject: darcs patch: System.Posix.Temp: improve haddocks for ... (and 2 more) Message-ID: <4b54fe5d.9753f10a.65f6.72a6@mx.google.com> Mon Jan 18 19:27:55 EST 2010 gwern0@gmail.com * System.Posix.Temp: improve haddocks for mkstemp to explain what that returned String actually is Mon Jan 18 19:30:22 EST 2010 gwern0@gmail.com * System.Posix.Temp: pad input filenames with 6 Xs If the argument doesn't terminate in capital Xs, the C mkstemp will simply bomb out with zero warning. This was not documented. By arbitrarily sticking a bunch of Xes at the end of all arguments, we guarantee that this exception will not be thrown, the type signature will not change, and no existing code can break (since if it was manually avoiding the exception by adding "XXX" itself, the temp files will now be simply 3 random characters longer, nothing worse). Mon Jan 18 19:34:37 EST 2010 gwern0@gmail.com * System.Posix.Temp: rm whitespace -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 6520 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/libraries/attachments/20100118/9dcdd7dd/attachment-0001.bin From v.dijk.bas at gmail.com Tue Jan 19 13:13:07 2010 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Jan 19 12:45:42 2010 Subject: Recommended way to conditionally compile modules? In-Reply-To: References: Message-ID: On Fri, Jan 15, 2010 at 11:36 PM, Bryan O'Sullivan wrote: > ...I have to export everything in the module (because its contents vary depending on where I compile it)... You could of course conditionally export symbols using CPP: module System.Event.EPoll ( #if defined(HAVE_EPOLL) ... #endif ) where #if defined(HAVE_EPOLL) ... #endif Bas From gwern0 at gmail.com Thu Jan 21 18:15:49 2010 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Jan 21 17:48:17 2010 Subject: darcs patch: System.Posix.Temp: improve haddocks for ... (and 2 more) In-Reply-To: <4b54fe5d.9753f10a.65f6.72a6@mx.google.com> References: <4b54fe5d.9753f10a.65f6.72a6@mx.google.com> Message-ID: On Mon, Jan 18, 2010 at 7:35 PM, wrote: > Mon Jan 18 19:27:55 EST 2010 ?gwern0@gmail.com > ?* System.Posix.Temp: improve haddocks for mkstemp to explain what that returned String actually is > > Mon Jan 18 19:30:22 EST 2010 ?gwern0@gmail.com > ?* System.Posix.Temp: pad input filenames with 6 Xs > ?If the argument doesn't terminate in capital Xs, the C mkstemp will simply bomb out > ?with zero warning. This was not documented. > ?By arbitrarily sticking a bunch of Xes at the end of all arguments, we guarantee that > ?this exception will not be thrown, the type signature will not change, and no existing > ?code can break (since if it was manually avoiding the exception by adding "XXX" itself, > ?the temp files will now be simply 3 random characters longer, nothing worse). > > Mon Jan 18 19:34:37 EST 2010 ?gwern0@gmail.com > ?* System.Posix.Temp: rm whitespace Any thoughts by anyone? The changes seem straightforward enough to me that I'd rather not file bugs (if Trac is even working again). -- gwern From Alistair.Bayley at invesco.com Fri Jan 22 05:38:37 2010 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Fri Jan 22 05:10:55 2010 Subject: ssh ports for monk and nun? In-Reply-To: References: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com><79d7c4981001121257i2a8a230elad85ba04b45b2ec6@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911026698@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Stefan Monnier > > >> Trying to get ssh working via putty from behind my company > firewall. > > My recommendation is to get access to an outside machine where you run > an OpenVPN server on port 80 or 443. This will solve it "once and for > all". > But first, please complain loudly and repeatedly about the firewall > being closed to port 22. Tried and failed. Our firewall will be closed to port 22 for the forseaable future. I'll give the OpenVPN thing a go, if I can find some time. I'm wondering about a couple of things: 1. how many people (in the haskell community) have the same problem? How have they solved or worked around the problem? 2. is it possible to run SSH daemons on monk and nun on ports 80 or 443? I'm wondering both from a technical feasability POV, and also an administrative POV i.e. if it were technically feasible, would the admins be open to the idea, if there was sufficient demand? Thanks, 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. ***************************************************************** From marlowsd at gmail.com Fri Jan 22 06:01:27 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 22 05:33:46 2010 Subject: Make Happy Explicitly Depend on Perl In-Reply-To: <4B49B4FE.4010802@steinitz.org> References: <4B49B4FE.4010802@steinitz.org> Message-ID: <4B598587.40102@gmail.com> On 10/01/2010 11:07, Dominic Steinitz wrote: > Probably no-one has ever built happy on a machine without perl so this > has never been noticed. I think it's more polite to fail at the > configure stage rather than the build stage. In the cabal file I think > we should have > >> build-tools: perl > > Here's a patch. Applied, thanks. Simon From marlowsd at gmail.com Fri Jan 22 06:17:21 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 22 05:49:40 2010 Subject: darcs patch: System.Posix.Temp: improve haddocks for ... (and 2 more) In-Reply-To: <4b54fe5d.9753f10a.65f6.72a6@mx.google.com> References: <4b54fe5d.9753f10a.65f6.72a6@mx.google.com> Message-ID: <4B598941.6090203@gmail.com> On 19/01/2010 00:35, gwern0@gmail.com wrote: > Mon Jan 18 19:27:55 EST 2010 gwern0@gmail.com > * System.Posix.Temp: improve haddocks for mkstemp to explain what that returned String actually is > > Mon Jan 18 19:30:22 EST 2010 gwern0@gmail.com > * System.Posix.Temp: pad input filenames with 6 Xs > If the argument doesn't terminate in capital Xs, the C mkstemp will simply bomb out > with zero warning. This was not documented. > By arbitrarily sticking a bunch of Xes at the end of all arguments, we guarantee that > this exception will not be thrown, the type signature will not change, and no existing > code can break (since if it was manually avoiding the exception by adding "XXX" itself, > the temp files will now be simply 3 random characters longer, nothing worse). > > Mon Jan 18 19:34:37 EST 2010 gwern0@gmail.com > * System.Posix.Temp: rm whitespace I'll validate and apply; thanks. Simon From marlowsd at gmail.com Fri Jan 22 06:18:46 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 22 05:51:06 2010 Subject: darcs patch: fixed 'cabal sdist' In-Reply-To: <4b26c417.0f0db80a.561f.ffffa5d8@mx.google.com> References: <4b26c417.0f0db80a.561f.ffffa5d8@mx.google.com> Message-ID: <4B598996.7060804@gmail.com> On 14/12/2009 23:04, Sergei Trofimovich wrote: > Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich > * fixed 'cabal sdist' > > It actually fixes './configure' regeneration for such > distros, like gentoo, wich had to patch configure.ac and > regenerate script toolchain. I'll validate and apply; thanks. Simon From marlowsd at gmail.com Fri Jan 22 06:19:31 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 22 05:51:46 2010 Subject: darcs patch: lower base requirement down to base-2 In-Reply-To: <4b2952de.100db80a.2658.3481@mx.google.com> References: <4b2952de.100db80a.2658.3481@mx.google.com> Message-ID: <4B5989C3.6060501@gmail.com> On 16/12/2009 21:37, Sergei Trofimovich wrote: > Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich > * lower base requirement down to base-2 > At least ghc-6.6.1 is able to build it without problems. > (package can be used in cabal-1.8, which is known to work > on ghc-6.4+) I'll validate and apply; thanks. Simon From Alistair.Bayley at invesco.com Fri Jan 22 06:49:33 2010 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Fri Jan 22 06:21:48 2010 Subject: [Haskell-cafe] RE: ssh ports for monk and nun? In-Reply-To: References: <79d7c4981001121243j708b6127r5cd5312f0cb97246@mail.gmail.com> <79d7c4981001121257i2a8a230elad85ba04b45b2ec6@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA911026698@GBLONXMB02.corp.amvescap.net> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA91102669B@GBLONXMB02.corp.amvescap.net> > From: cristiano.paris@gmail.com > [mailto:cristiano.paris@gmail.com] On Behalf Of Cristiano Paris > > On Fri, Jan 22, 2010 at 11:38 AM, Bayley, Alistair > wrote: > > ... > > Tried and failed. Our firewall will be closed to port 22 for the > > forseaable future. I'll give the OpenVPN thing a go, if I > can find some > > time. > > Trying to ask how to pierce your company's firewall in a public > mailing list, even from your company's email address, may not be > advisable. Well, I wasn't necessarily looking for that kind of advice, more along the lines of how to work with what I have (which is ports 80 and 443, via an http proxy server). I have been able to use CVS+SSH with sourceforge in the past, because they had cvs servers that listened for SSH connections on port 443. 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. ***************************************************************** From marlowsd at gmail.com Fri Jan 22 07:00:51 2010 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Jan 22 06:33:18 2010 Subject: Minor inefficiency in Data.Map and Data.Set? In-Reply-To: <404396ef0912271024i3e7183fakc6d4f7c88671e68f@mail.gmail.com> References: <200912210038.25647.twhitehead@gmail.com> <404396ef0912231331u2fdbb330tdd18c81220732a0c@mail.gmail.com> <7fb8f82f0912231823k422317e6w96b7a52d1fdc1af7@mail.gmail.com> <404396ef0912271024i3e7183fakc6d4f7c88671e68f@mail.gmail.com> Message-ID: <4B599373.8040905@gmail.com> On 27/12/2009 18:24, Neil Mitchell wrote: > Hi, > > Sounds like we should apply then - unless anyone has a really good > reason why not to. The code should be simple and correct, and we > shouldn't ever rely on things like CSE. On the other hand, it sounds like it adds a new invariant, which at the least should be documented in comments. If someone sends a darcs patch, I'll apply. Cheers, Simon > Thanks, Neil > > 2009/12/24 Edward Kmett: >> On Wed, Dec 23, 2009 at 4:31 PM, Neil Mitchell wrote: >>> >>> Hi Tyson, >>> >>> Whenever I see the word inefficiency, I look for the benchmark that >>> proves it :-) >> >> Hey Neil, >> I've spent quite a bit of time poring over the code in question trying to eke out performance when I was looking at ways to get it to perform nicely for unboxed data structures, so I'll try to serve as an independent set of eyes. >>> >>> Have you benchmarked these two alternatives? If you can show that >>> >>> there is a measurable difference I'm sure someone will sit up and take >>> >>> note. Personally, I know nothing about the code involved, so you'd >>> >>> need to find someone who did to check your optimisation is valid >> >> I'll vouch for the validity of the code change. Basically his code avoids trying to do the top level rotation when gluing 2 trees that are already within 1 level of each other together -- the invariant to be able to call 'glue'. Its a good point, and it checks out as correct that the call to balance is superfluous. I even quickchecked about a hundred thousand trees to make sure that the behavior doesn't change, but you can get there by programmatic transformation to satisfy for more rigorous among us: >> A 'sufficiently smart compiler' could spot that if it inlines balance in both locations, then CSE's the comparison between sizes, that the case for the comparison between sizes has already been done, then it could simplify the balance cases to just construct the Bin without rebalancing, and another CSE would then do the rest of the transformation, but it seems like a needlessly complex path, and while I haven't gone through the resulting STG output to see if it is actually occurring with optimizations enabled on the containers library, I'm somewhat dubious, given the number of phases that would have to happen in just the right order for this to be the case. >> More interestingly, if you start playing around with variants on these modules, like the one I was working on that unboxed the key/values using some fancy view machinery, the compiler would have to work ridiculously hard to spot the correct invariants across the inlining of both the call and the particular view, so I've already applied this patch to unboxed-containers in my working repository. >> I think that relying on the compiler to get that right seems a lot less straightforward than just fixing the algorithm to do the right amount of work. Considering that it is true to the style of the rest of the code in those modules to be explicit about what work is actually necessary and where by calling special case rebalancing combinators only when appropriate. >>> >>> (if it makes things go faster. >> >> As for benchmarks, frankly it'll vanish in the noise, the worst case is a few of extra stack frames getting constructed, a redundant addition, and some unnecessary comparisons in balance once per operation, and not at each level of the tree. I do support patching it just for correctness though. >> Glue gets called internally across a very wide array of operations, and in some sense the Data.Map/Data.Set code has become the de facto reference implementation for how to implement trees of bounded balance, so it'd be nice to have them be correct. >> -Edward Kmett >>> >>> >>> Thanks, Neil >>> >>> On Mon, Dec 21, 2009 at 5:38 AM, Tyson Whitehead wrote: >>>> I was looking at the Data.Map and Data.Set implementations and I think there >>>> is a slight inefficiency. Consider the Data.Map code >>>> >>>> {-------------------------------------------------------------------- >>>> [glue l r]: glues two trees together. >>>> Assumes that [l] and [r] are already balanced with respect to each other. >>>> --------------------------------------------------------------------} >>>> glue :: Map k a -> Map k a -> Map k a >>>> glue Tip r = r >>>> glue l Tip = l >>>> glue l r >>>> | size l> size r = let ((km,m),l') = deleteFindMax l in balance km m l' r >>>> | otherwise = let ((km,m),r') = deleteFindMin r in balance km m l r' >>>> >>>> The call to balance should not be needed as subtracting one item from the non- >>>> smaller of them cannot thrown them out of balance given they are already in >>>> balance with one another. The only way they could be made out of balance >>>> would be to subtract an item for smaller one. The replacement code is >>>> >>>> glue l r >>>> | sizeL> sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' r >>>> | otherwise = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l r' >>>> where >>>> sizeL = size l >>>> sizeR = size r >>>> sizeX = sizeL + sizeR >>>> >>>> The Data.Set code is identical except for the key. >>>> >>>> Cheers! -Tyson >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@haskell.org >>>> http://www.haskell.org/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >> >> > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries From jon.fairbairn at cl.cam.ac.uk Thu Jan 28 11:34:02 2010 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Jan 28 11:06:11 2010 Subject: cabal user guide character set Message-ID: http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/ is served as Content-Type: text/html; charset=utf-8 but the content appears to be iso8859-1 Perhaps someone could correct one or the other? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) From dons at galois.com Thu Jan 28 14:35:25 2010 From: dons at galois.com (Don Stewart) Date: Thu Jan 28 14:07:20 2010 Subject: Distro mappings script still running? Message-ID: <20100128193525.GD27572@whirlpool.galois.com> Hey all, Did the distro mappings script for Hackage (the one that tracks lists of what is in each distro) survive the move to abbott? I'm not sure its updated recently. -- Don From ross at soi.city.ac.uk Thu Jan 28 15:43:32 2010 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jan 28 15:16:00 2010 Subject: Distro mappings script still running? In-Reply-To: <20100128193525.GD27572@whirlpool.galois.com> References: <20100128193525.GD27572@whirlpool.galois.com> Message-ID: <20100128204332.GA18372@soi.city.ac.uk> On Thu, Jan 28, 2010 at 11:35:25AM -0800, Don Stewart wrote: > Did the distro mappings script for Hackage (the one that tracks lists of > what is in each distro) survive the move to abbott? I'm not sure its > updated recently. I think it's still going. Can you pick out something that's missing? From dons at galois.com Thu Jan 28 17:27:31 2010 From: dons at galois.com (Don Stewart) Date: Thu Jan 28 16:59:20 2010 Subject: Distro mappings script still running? In-Reply-To: <20100128204332.GA18372@soi.city.ac.uk> References: <20100128193525.GD27572@whirlpool.galois.com> <20100128204332.GA18372@soi.city.ac.uk> Message-ID: <20100128222730.GK27572@whirlpool.galois.com> ross: > On Thu, Jan 28, 2010 at 11:35:25AM -0800, Don Stewart wrote: > > Did the distro mappings script for Hackage (the one that tracks lists of > > what is in each distro) survive the move to abbott? I'm not sure its > > updated recently. > > I think it's still going. Can you pick out something that's missing? Yep, looks ok now. Sorry for the noise. -- Don