October 2005 - Libraries

RE: Network Exception
by Simon Marlow 13 Oct '05

13 Oct '05

On 12 October 2005 17:14, Arias wrote: > My name Iván Arias, I'm trying to connect to a server using the > Network library, the code that I'm using is something like this: > > --- BEGIN --- > module Main where > import System.IO > import Network > > main = do > handle <- connectTo "localhost" ( PortNumber 8080 ) > hClose handle > --- END --- > > It compiles correctly, but when I try to run this code, it throws an > exception at connectTo. The exception message is this: > > - getServiceEntry: does not exists (No such service entry) I can't see any reason that would happen. Is that the actual code you are using? Cheers, Simon

2 1

RE: [Haskell] setSocketOption unusable?
by Simon Marlow 13 Oct '05

13 Oct '05

[ moved to libraries(a)haskell.org from haskell(a)haskell.org] On 12 October 2005 21:01, John Goerzen wrote: > I'm wanting to set the SO_RCVTIMEO and SO_SNDTIMEO options on a socket > from Haskell. socket(7) say that these take a struct timeval ad a > parameter. (Other options, such as SO_LONGER, also could have this > problem.) > > In Haskell, we see: > > setSocketOption :: Socket -> SocketOption -> Int -> IO () > > Now, there are SocketOption constructors (RecvTimeOut and SendTimeOut) > for what I want. But there is no way to give it a proper timeval (and > yes, I checked the source.) > > setSocketOption definately wants an Int, and is passing the length of > the Int to setsockopt(2) as well, so it appears to me that there is > absolutely no way to correctly specify SO_RCVTIMEO or SO_SNDTIMEO > through Haskell's socket layer. > > Is that correct? > > If so, how can we fix it? Looks like that interface is fairly broken to me. SocketOption should be an albebraic type with the appropraite parameters to each constructor. Fortunately everything is exported non-abstractly from Network.Socket so you can implement your own setSocketOption. If you come up with some code, I'll incorporate it, or just submit a bug report. Cheers, Simon

1 0

Network Exception
by Arias 12 Oct '05

12 Oct '05

Hi, My name Iván Arias, I'm trying to connect to a server using the Network library, the code that I'm using is something like this: --- BEGIN --- module Main where import System.IO import Network main = do handle <- connectTo "localhost" ( PortNumber 8080 ) hClose handle --- END --- It compiles correctly, but when I try to run this code, it throws an exception at connectTo. The exception message is this: - getServiceEntry: does not exists (No such service entry) Do somebody know why this happens and how to fix it? Thanks

1 0

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 12 Oct '05

12 Oct '05

On 23 September 2005 08:45, Johannes Waldmann wrote: >> Another way to look at both issues is that if ghc can figure out >> other modules and packages itself, the user shouldn't be required to >> specify them in a cabal file. ... > > Definitely. Having the list of modules in the .cabal is unnecessary > duplication of information (because it's in the sources already). > This is bound to get out-of-sync during development - > unless you use some kind of Makefile to generate the .cabal file, > which defeats the very purpose of Cabal itself. I know how to do this using GHC, but I'm not sure about other compilers. With GHC, we can generate the dependencies using 'ghc -M' and then parse the generated Makefile (a bit of a long way around, but I can't think of an easier way). Of course we'd avoid splatting an existing Makefile by redirecting the dependencies to a temporary file. How would we do this with nhc98 or Hugs? Perhaps because these systems don't actually need to know the value of other-modules we can get away with it. Comments? > Unrelated question: can someone please share an example that shows > how to put user-defined options for haddock in a .cabal? There's no good way to do it right now. You can override the whole haddock command using hooks, but you'd have to write quite a bit of code to do this. I plan to add something to allow extra Haddock args to be given (the Haddock support is a very bare-bones right now, it should get better). Cheers, Simon

4 6

making with profiling, 6.4.1, cabal-1.1.3
by Serge D. Mechveliani 11 Oct '05

11 Oct '05

People, I need help on making for profiling, and cannot decide whether the question is on GHC or on Cabal. I have ghc-6.4.1, and Cabal-1.1.3-September-12 installed in my user directory, under Debian Linux, and need to make a project for profiling. ghci -package Cabal says ... Loading package base-1.0 ... linking ... done. ... Loading package Cabal-1.1.3 ... linking ... done. I start with a contrived example project of M1.hs, M2.hs, Main.hs: --------------------------------------- module M1 where m1 = True module M2 where import M1; m2 = m1 && m1 Main.hs: import M2l; main = putStr $ shows m2 "\n" --------------------------------------- For this, ghc --make -prof -auto-all Main works as needed -- without packages. Now, try to make a package for profiling: foo.cabal: name: foo version: 1.0 build-depends: base, haskell98, data exposed-modules: M2 other-modules: M1 ghc-options: -prof -auto-all -hisuf p_hi -osuf p_o The aim is to build foo (of M2) as a library, then to make Main under the package foo, and with profiling. Then, runhaskell Setup configure --ghc --prefix=$source/inst runhaskell Setup build produces a report ------------------------------------------------------------------- ... configure: Using compiler: /home/mechvel/ghc/6.4.1/inst/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /home/mechvel/ghc/6.4.1/inst/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /home/mechvel/ghc/6.4.1/inst/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Dependency base-any: using base-1.0 configure: Dependency haskell98-any: using haskell98-1.0 configure: Dependency data-any: using data-1.0 scico:~/t> make build runhaskell Setup.hs build Preprocessing library foo-1.0... Building foo-1.0... Chasing modules from: M2,M1 Skipping M1 ( M1.hs, dist/build/M1.p_o ) Skipping M2 ( M2.hs, dist/build/M2.p_o ) /usr/bin/ar: creating dist/build/libHSfoo-1.0.a /usr/bin/ar: dist/build/M2.o: No such file or directory make: *** [build] Error 1 ------------------------------------------------------------------- The directory ~/t/dist/build contains at this moment M1.p_hi M1.p_o M2.p_hi M2.p_o Main.p_hi Main.p_o , and indeed, no M2.o file. If I remove -hisuf p_hi -osuf p_o (by the way, why should the user think of these wise suffixes, maybe, -prof should be sufficient? ), then it reports ... /usr/bin/ld: cannot find -lHSfoo-1.0_p collect2: ld returned 1 exit status What I am missing, please? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

cabal question / feature request
by Johannes Waldmann 10 Oct '05

10 Oct '05

Dear all. is there a way to get the preprocessed sources of a project from Cabal? Is this what "Setup copy" is for? (I guess not.) If I do "runhaskell Setup.hs sdist", I get a tarball with the original sources (macros not expanded). If I do "runhaskell Setup.hs haddock" it seems the preprocessed sources are built - but then deleted, so I only get what haddock makes of them (and this I don't like - I need more control over haddock options, so I need to run it outside cabal.) Can I get the desired effect by doing Setup configure for hugs and then Setup install? (Would this install preprocessed sources?) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

Cabal: versioning of the hooks API
by Simon Marlow 10 Oct '05

10 Oct '05

Folks, I've made some changes that affect the hooks API. It occurs to me that changes in this API will automatically break any Cabal Setup.lhs that is using the old API, and there isn't a good workaround, since when you say 'runhaskell Setup.lhs' you're at the mercy of whatever packages are visible to the default compiler. I wonder, should we explicitly version this API? That is, should we provide defaultMainWithHooks2, defaultMainWithHooks3...? That would at allow us some backwards compatibility, and make things break earlier and more predictably if the required version of Cabal isn't available. On the down side, it requires us to support multiple versions of the API simultaneously. We could use DEPRECATED pragmas to encourage people to update their Setup.lhs scripts. Thouhts? Cheers, Simon

1 0

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 10 Oct '05

10 Oct '05

On 07 October 2005 13:06, Ross Paterson wrote: > On Fri, Oct 07, 2005 at 01:05:04PM +0100, Ross Paterson wrote: >> On Fri, Oct 07, 2005 at 12:35:21PM +0100, Simon Marlow wrote: >>> Paths.hs-inc is auto-generated, and contains >>> >>> getBinDir :: IO FilePath >>> getLibDir :: IO FilePath >>> getDataDir :: IO FilePath >>> getLibexecDir :: IO FilePath >> >> Does this have to be #include'd, or could it be a module? > > Oops, forget I said that. Paths.hs-inc is a pain, but the problem with making it a module is that you have to pick a non-conflicting module name, as I'm sure you realised. So how about incorporating the package name into the module name, to avoid the conflict - eg. import Paths_alex? or Cabal.Paths_alex? Cheers, Simon

1 0

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

On 07 October 2005 12:08, Ross Paterson wrote: >> So we could actually make $libextradir visible and explicit, i.e. >> change the scheme to this: >> >> libdirrel = lib (by default) >> libextradir = $package/$compiler >> libInstDir = $prefix/$libdirrel/$libextradir >> >> Is that what you want? > > Yes, setting libdirrel independently from libextradir gives > interoperability with autoconf, and also means installers don't have > to mess with Cabal's placement policy unless they really want to. > One could specify libdirrel with a new option or with --libdir > (possibly extended with substitutions). Ok, so I take it you'd prefer --libdir instead of --libdirrel. We can do that, but (a) we have to change --copy-prefix and (b) we have to give an error on Windows if you use --libdir to specify a path that doesn't begin with $prefix, at least for an executable. Both of these are fine by me. So, here's the plan. options to ./setup configure: --prefix=<dir> --libdir=<dir> --libsubdir=<dir> --datadir=<dir> --datasubdir=<dir> --bindir=<dir> --libexecdir=<dir> where <dir> can include $(prefix), $(package), $(compiler). libs are installed in $libdir/$libsubdir. Paths.hs-inc is auto-generated, and contains getBinDir :: IO FilePath getLibDir :: IO FilePath getDataDir :: IO FilePath getLibexecDir :: IO FilePath Executables on Windows are prefix-independent, the above functions assume they are being called by a binary in $bindir. On Unix, and for libraries on Windows, the above functions all return fixed values. On Windows, specifying any --*dir value which does not begin with $(prefix) for an executable elicits an error. I'm still not quite sure how to implement this, because the Windows version of the code is non-trival and requires a bunch of imports & flags. Additionally, we add --copy-root=<dir> with the old meaning of --copy-prefix, and deprecate --copy-prefix (or just change --copy-prefix back again?). Cheers, Simon

2 2

RE: Cabal: bindir/libdir/datadir
by Simon Marlow 07 Oct '05

07 Oct '05

On 07 October 2005 10:07, Ross Paterson wrote: > On Thu, Oct 06, 2005 at 11:29:30AM +0100, Simon Marlow wrote: >> [...] >> How can the package itself find out what these paths are? As >> discussed previously, Cabal generates a file Paths.hs-inc containing >> >> prefix = "<dir>" >> binDirRel = "<dir>" >> libDirRel = "<dir>" >> ... etc ... >> >> which can be #included into Haskell source. Additionally I have the >> function: >> >> getPrefix :: FilePath{-binDirRel-} -> IO (Maybe FilePath) >> >> which figures out prefix when called from a binary installed in >> $prefix/$bindirrel. If it returns Nothing, then you can fall back to >> the hard-coded value of prefix from Paths.hs-inc. > > Can you show the client code to find data files under any system and > compiler? Ok, here's what I use in Alex: #include "Paths.hs-inc" getDataDir :: IO FilePath getDataDir = do m <- getPrefix binDirRel return (fromMaybe prefix m `joinFileName` dataDirRel) getPrefix :: FilePath -> IO (Maybe FilePath) -- always returns Nothing on Unix, on Windows calculates -- prefix from the path of the executable, assuming the current -- executable is in $prefix/$bindirrel. This code is always the same, so as Krasimir pointed out we should provide it to the executable via Paths.hs-inc somehow. Good ideas for how to do this are welcome. >> There's one thing I'm not sure about yet: the default $libdirrel on >> Unix systems is lib/<pkgid>/<compiler>, eg. lib/pkg-0.2/ghc-6.4, and >> you might want to change just the "lib" bit, eg. to get >> lib64/pkg-0.2/ghc-6.4. It's annoying to have to specify the <pkgid> >> and <compiler> when Cabal knows them, so we might want a simple >> substitution syntax, such as --libdirrel=lib64/%p/%c. Sound >> reasonable? > > There's a difference between the package libdir's you're talking about > (e.g. $prefix/lib/$PackageId/$CompilerId) and --libdir in autoconf > (default $prefix/lib). You couldn't easily generate the options to > configure from *dirrel. But do we really need an option to specify > the package libdir, or just --libdir (in the autoconf sense)? > "lib64/%p/%c" is easier than the full thing, but it still exposes > Cabal's placement policy to lots of installers. Similarly bindir, > datadir, libexecdir and maybe includedir. There would be no problem > with generalizing the autoconf options, though, say to allow > substitutions (e.g. of prefix). Hmm. *scratches head* *gets coffee* We have slightly different views on the world, I think. I'm going to try to describe both, so that at least I can understand what's going on. So there's a directory I'll call libInstDir, where the libraries for a package actually get installed. In my scheme, libInstDir is constructed like this: libdirrel = lib/$package/$compiler (by defualt) libInstDir = $prefix/$libdirrel in your view of the world, it is constructed like this: libdir = $prefix/lib (by default) libextradir = $package/$compiler libInstDir = $libdir/$libextradir so there's an extra layer, namely the "$package/$compiler" that gets added by the build system (or something) when installing libraries. (GHC does this, and I don't like it much). The actual value of libInstDir needs to be visible to the program/library, especially for dataInstDir, which is why perhaps having the hidden $libextradir layer is not so good. Also it's desirable to have the whole of libInstDir configurable. So we could actually make $libextradir visible and explicit, i.e. change the scheme to this: libdirrel = lib (by defualt) libextradir = $package/$compiler libInstDir = $prefix/$libdirrel/$libextradir Is that what you want? Cheers, Simon

2 1