January 2010 - Libraries

opening a file for writing and reading
by Jeremy Shaw 12 Jan '10

12 Jan '10

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

4 4

Re: [Haskell-cafe] ssh ports for monk and nun?
by Alistair Bayley 12 Jan '10

12 Jan '10

2010/1/12 Jason Dusek <jason.dusek(a)gmail.com>: > Monk and nun? The haskell.org code/project/... servers: http://www.haskell.org/haskellwiki/Haskell.org_domain

1 0

X11 missing source repo(?)
by Evan Martin 12 Jan '10

12 Jan '10

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

4 4

Splitting a Hackage project (was ANN: Streaming Component Combinators 0.4)
by Mario Blazevic 08 Jan '10

08 Jan '10

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-Concur… 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(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Re: Adding Network.URI.escape
by Gwern Branwen 05 Jan '10

05 Jan '10

On Mon, Jan 4, 2010 at 6:15 AM, Graham Klyne <GK-lists(a)ninebynine.org> 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

2 1

Fwd: Network on GHC 6.12 with Windows
by Neil Mitchell 04 Jan '10

04 Jan '10

Hi Johan, I just tried compiling network-2.2.1.5 with GHC 6.12.1rc2 on Windows, under Cygwin. The failures I got were: $ 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... Network\Socket.hsc: In function `main': Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete type `ucred' Network\Socket.hsc:999: error: `SO_PEERCRED' undeclared (first use in this function) Network\Socket.hsc:999: error: (Each undeclared identifier is reported only once Network\Socket.hsc:999: error: for each function it appears in.) Network\Socket.hsc:1000: error: dereferencing pointer to incomplete type Network\Socket.hsc:1001: error: dereferencing pointer to incomplete type Network\Socket.hsc:1002: error: dereferencing pointer to incomplete type compiling dist\build\Network\Socket_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\Socket_hsc_make.c -o dist\build\Network\Socket_hsc_make.o I then tried the darcs version and got: $ 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(a)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(a)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. I was really hoping for a Network package on GHC 6.12, as lots of my stuff depends (indirectly) on it. Is there anything I can do to help? Thanks, Neil

2 4

Re: Adding Network.URI.escape
by Gwern Branwen 04 Jan '10

04 Jan '10

On Fri, Dec 25, 2009 at 4:17 PM, Graham Klyne <GK-lists(a)ninebynine.org> 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.h… >> 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

2 1

cabal install c2hs problem
by Chris Casinghino 03 Jan '10

03 Jan '10

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

2 2

Re: nubBy, groupBy specification
by Cale Gibbard 02 Jan '10

02 Jan '10

2010/1/2 <a.biurvOir4(a)asuhan.com>: > 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(a)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

2 1

cabal sdist doesn't include c headers
by Chris Casinghino 02 Jan '10

02 Jan '10

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

2 2