- Libraries - Haskell.org

problem with xlib binding
by Frederik Eaton 09 May '05

09 May '05

Hi, Hmm, have the new xlib bindings been tested? For instance, when I run the following program: ---------------------------------------------------------------- module Main where import Graphics.X11.Xlib import Graphics.X11.Xlib.Display main :: IO () main = do display <- openDisplay "" root <- rootWindow display $ defaultScreen display getGeometry display root closeDisplay display return () ---------------------------------------------------------------- It prints out: xtest: user error (Error bad status 1 raised in function getGeometry) >From the code it looks like the haskell getGeometry is calling XGetGeometry - which has type Status XGetGeometry(...) - and interpreting the 1 return value as an error (via the internal wrapper 'throwUnlessSuccess' which takes 0 for success). But the Xlib Programming Manual says "Some errors, such as failure to open a font, are indicated by return values of type Status on the appropriate routine ... The returned values are *zero* on failure and *nonzero* on success." (emphasis added) So unless I'm really misinterpreting things, the binding to each and every one of the 13 functions that uses 'throwUnlessSuccess' is wrong. Well, before I realized this I'd gone ahead and written a reasonably significant program against the binding assuming that at least the basics would work, but it seems there is some distance to go before the library is usable. One would think that with a "Stability: provisional" library every function has been run successfully at least once, but I can't imagine that this is the case here. Is there even a working Haskell equivalent of 'basicwin' from the Xlib Programming Manual to test things out? This would also be a helpful example for users. Regards, Frederik -- http://ofb.net/~frederik/

3 3

Should inet_ntoa Be Pure?
by Dominic Steinitz 07 May '05

07 May '05

Does anyone know why these are in the IO monad? Aren't they pure functions converting between dotted-decimal strings and a 32-bit network byte ordered binary value? Dominic. http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.Socke… http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.Socke…

2 1

Cabal and c2hs
by Dominic Steinitz 06 May '05

06 May '05

I am trying to migrate some old code to cabal. It uses c2hs. Now I wasn't sure I had c2hs installed so I ran cabal anyway. 1. Why isn't configure telling me where c2hs is? It tells me where hsc2hs is! 2. Why is cabal telling me it can't find a source when the source is present? Thanks, Dominic. Here's ping.cabal: Name: Ping Version: 0.0 License: BSD3 Author: Dominic Steinitz Synopsis: The Haskell equivalent of ping Executable: ping Main-Is: test.hs Other-modules: IP_ICMP.chs When I run ./Setup configure, I didn't see any message saying whether c2hs was installed and when I run ./Setup build I get the following: [dom@tility ping]$ ./Setup build Preprocessing executables for Ping-0.0... can't find source for IP_ICMP.chs in ["."] But the source is there: [dom@tility ping]$ ls codes.hs dist/ ip_icmp.h ping.cabal Setup* Setup.hs test.hs CVS/ IP_ICMP.chs Makefile ping.cabal~ Setup.hi Setup.o

4 10

RE: Request: Open Module Resolution
by Simon Marlow 05 May '05

05 May '05

On 03 May 2005 23:01, S. Alexander Jacobson wrote: > Proposal: > > 1. Define a standard resolver module > > module Resolve where > > type Resolver = Args -> ModuleName -> IO HaskellSource > resolve::Resolver > > 2. Require that Haskell compilers allow users to supply resolvers > e.g. > > ghci -r ../../Resolve.hs That requires compile-time code generation and execution (i.e. template haskell), so I can't see all compilers implementing it. Instead, let me point you at the place in GHC to insert your resolver. In the module Finder, we have: findModule :: HscEnv -> Module -> Bool -> IO FindResult data FindResult = Found ModLocation PackageIdH -- the module was found | PackageHidden PackageId -- for an explicit source import: the package containing the module is -- not exposed. | ModuleHidden PackageId -- for an explicit source import: the package containing the module is -- exposed, but the module itself is hidden. | NotFound [FilePath] -- the module was not found, the specified places were searched. You can almost replace findModule with your own resolver. However, the question is what do you do for modules like "Prelude": it sounds like you'll need to have pre-compiled code for all the standard libraries around (I assume you want to avoid using packages). Cheers, Simon

2 1

NewBinary Library
by Peter Simons 05 May '05

05 May '05

Hi, the NewBinary library used to be available via Darcs at this place: http://www.n-heptane.com/nhlabca/repos/NewBinary It appears, though, that this repository has vanished. Does anyone know what happened? Is anyone aware of the new home of the library? Peter

2 1

RE: Bug in Cabal creating user package.conf
by Simon Marlow 04 May '05

04 May '05

On 30 April 2005 09:06, Ashley Yakeley wrote: > In article <87ekcsr9u0.fsf(a)syntaxpolice.org>, > Isaac Jones <ijones(a)syntaxpolice.org> wrote: > >> Hmm. How sure are you that it was cabal that created the >> package.conf file? This is the code that does so, and it definitely >> seems to add a newline: > > This is on Mac OS X, and it's definitely Setup.hs that's creating the > file, and it definitely has just "[]". > > Transcript (prompt reduced to "$ " for brevity): > > $ cat Setup.hs > import Distribution.Simple > main = defaultMain > $ rm -rf ~/.ghc > $ runghc Setup.hs configure > Warning: Package is copyright All Rights Reserved > Warning: No license-file field. > Configuring TimeLib-0.1... > configure: searching for ghc in path. > configure: found ghc at /usr/local/bin/ghc > configure: looking for package tool: ghc-pkg near compiler in > /usr/local/bin/ghc > configure: found package tool in /usr/local/bin/ghc-pkg > configure: Using install prefix: /usr/local > configure: Using compiler: /usr/local/bin/ghc > configure: Compiler flavor: GHC > configure: Compiler version: 6.4 > configure: Using package tool: /usr/local/bin/ghc-pkg > configure: Using haddock: /usr/local/bin/haddock > configure: Using happy: /usr/local/bin/happy > configure: Using alex: /usr/local/bin/alex > configure: Using hsc2hs: /usr/local/bin/hsc2hs > configure: No cpphs found > configure: Reading installed packages... > cannot parse package list > $ cat ~/.ghc/powerpc-darwin-6.4/package.conf > []$ uname -a > Darwin Avebury.local 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 > 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power > Macintosh powerpc > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.4 > $ ls -Al ~/.ghc/powerpc-darwin-6.4/package.conf > -rw-r--r-- 1 ashley ashley 2 Apr 30 00:57 > /Users/ashley/.ghc/powerpc-darwin-6.4/package.conf It's not a newline issue, something else strange is going on here. Your local package.conf is being created by ghc-pkg (which is a little eager to create it in 6.4; 6.4.1 will be better). The parse error is coming from Cabal (Distribution.Simple.Configure) which is having trouble parsing the list of packages from ghc-pkg list. Could you post your output from "ghc-pkg list" after running the configure step above? Cheers, Simon

2 1

Request: Open Module Resolution
by S. Alexander Jacobson 03 May '05

03 May '05

Problem: Haskell has both no standard way to resolve module names to implementations and no easy way to experiment with different solutions. For example, I would like to experiment with a resolver that uses a lookup table to map module names to URLs of module implementations. Proposal: 1. Define a standard resolver module module Resolve where type Resolver = Args -> ModuleName -> IO HaskellSource resolve::Resolver 2. Require that Haskell compilers allow users to supply resolvers e.g. ghci -r ../../Resolve.hs -Alex- PS This request is the output of discussion I was having with Dimitry Golubovsky (and others). ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Fri, 29 Apr 2005, Dimitry Golubovsky wrote: > Alex, > > Quoting your message in Libraries: > > ================= > > We should think of module names as being like domain names, and module > implementations as being like IP addresses. Just as the owner of a > domain name determines valid IP addresses for it, the owner of a > module name should be able to determine valid implemementations. > Just as you can't provide domain name resolution for domain names you > don't own, you should not be able to provide module name resolution > for module names you don't own. > > We need a Module Name System analogous to the Domain Name System. > Haskell compilers should be able to query a root server to find which > MNS server is authoritative for a particular module name. A query to > that MNS server should result in URLs for implementations of that > module. > > =============== > > Some time ago I wrote up on Haskell-cafe: > > http://www.haskell.org//pipermail/haskell-cafe/2005-March/009515.html > > about proposed mechanism of module name resolution. What do you think? > This can be done flexible enough with minimal changes to the compiler > (just make it open a pipe instead of a file) and letting an external > program do the business. > > Nobody answered though. > > I am writing off-list, but if you find my ideas useful feel free to > move the discussion to Libraries or Cafe. > > -- > Dimitry Golubovsky > > Anywhere on the Web >

1 0

RE: Data.Dynamic
by Simon Peyton-Jones 03 May '05

03 May '05

Here's a rather long-ago message from John Meacham that I failed to reply to. Simon M and I talked about this. While we aren’t rabidly against hashTypeRep (with an IO type), if you are going to have an IO type you might as well have typeRepId :: TypeRep -> IO Int, which gives a unique Int, distinct for each TypeRep. But beyond that, it's very inconvenient to have to do IO. One way to sidestep the determinacy issue is to provide TypeRepMap as part of the interface to TypeRep data TypeRepMap a insertTR :: TypeRepMap a -> TypeRep -> a -> TypeRepMap a union, get elts, etc etc The downside is that it needs a pretty big interface to be useful. The upside is that it can be purely functional. My suggestion would be for someone to bite the bullet, design the interface, and implement it efficiently (not difficult). Though I hate offering such a big interface, TypeReps are useful, and should be efficient, and this is a way to get that without compromising with determinacy. So a) do others agree b) any volunteers to do the legwork? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 08 March 2005 00:05 | To: libraries(a)haskell.org | Subject: Re: Data.Dynamic | | On Mon, Mar 07, 2005 at 12:52:53PM -0000, Simon Peyton-Jones wrote: | > but typeRepIndex :: TypeRep -> IO Int | > looks stranger. It breaks the TypeRep abstraction. Would you care to argue for it? | | Mainly the reasons Geore Russell brought up a while ago, fast maps via | an compare or Hash on TypeReps are needed for various type-indexed | structures. | | http://www.haskell.org//pipermail/haskell-cafe/2004-November/007734.html | | We had no consensus on creating an Ord instance, since it could differ | between runs so was 'unsafe' in a weak sense, but adding something in IO | would be good enough for most applications and would sidestep the whole | issue :). | | Perhaps calling it hashTypeRep :: TypeRep -> IO Int and only | guarenteeing the weaker many-to-one semantics of hash functions would be | more appropriate and future-safe. | | Another alternative would be | compareTypeRep :: TypeRep -> TypeRep -> IO Ordering | but I prefer the hash version. | | I still think we should have two ordering classes, one for the natural | ordering in the prelude, and one for an efficient ordering for creating | maps or sets with the side condition that code may not depend on the | particular order it gives, just that it is a total order. But that is | another discussion :) | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Re: Who maintains haskell-src?
by Niklas Broberg 03 May '05

03 May '05

Seems there's some trouble with your mail server, I keep getting 'delivery failure'. Hopefully mails through the list will get through. Anyway, I've now merged my repo with the changes to haskell-src in CVS. There were no merge conflicts. > I'd also like to parameterize the parser over the Extensions > type currently in Distribution.Extension (maybe it should move to > Language.Haskell.Extension) so that users could selectively enable > extensions. I agree that the parser (and the lexer too) should be parametrized over extensions. The Extensions type in Distribution.Extension looks a bit messy, but I guess that's a different issue entirely, I suppose once that's stable we'll have no problems using it. I've started adding some infrastructure to my lib for doing this parametrization, it seems to be fairly straight-forward (but tedious). I'll keep working on it. There are a few non-conservative changes introduced in haskell-src-exts, so I guess it's best to wait until all the extension parametrization is there before adding my stuff to the official cvs. /Niklas

3 2

Who maintains haskell-src?
by Niklas Broberg 03 May '05

03 May '05

The reason I ask is my haskell-src-exts (http://www.cs.chalmers.se/~d00nibro/haskell-src-exts) library that extends the haskell-src modules with support for syntactic extensions. I believe this functionality is something that most users of haskell-src are interested in, so perhaps it might be a good idea to actually add my extensions to the standard package. It won't be this very minute since there are some issues, but if I get a clearance I'll make an effort to work them out. /Niklas

3 3