- Libraries - Haskell.org

Cabal doesn't echo commands with -v on Windows
by Simon Peyton-Jones 18 Oct '05

18 Oct '05

Cabal with -v should echo the commands it is executing. But on Windows it doesn't. See the error log below. (This is when compiling the FastPackedString Cabal package, in fact.) Simon M thinks it might be a buffering issue. Flush before calling any command? Simon sh-2.04$ runghc Setup.hs -v build Preprocessing library fps-0.1... Building fps-0.1... <Windows pops up the GHC-has-crashed window>

2 1

holy frijoles: constant factors matter.
by John Meacham 14 Oct '05

14 Oct '05

these differences in jhc runtimes were the result of a single line change. < total time = 44.32 secs (2216 ticks @ 20 ms) < total alloc = 9,372,965,276 bytes (excludes profiling overheads) --- > total time = 36.74 secs (1837 ticks @ 20 ms) > total alloc = 6,621,233,076 bytes (excludes profiling overheads) the odd thing is, the change should not have changed the order of the algorithm at all. the change was (effectivly) Map.fromAscList . map f . Map.toAscList being changed to Map.map f both are O(n). but those constant factors matter. a lot. in any case, the reason I mention it is because if there were routines for converting between Set and Map that preserved the binary tree structure, I think their use could dramatically speed up many routines. In jhc (and other programs), I convert between them all the time and I'd hate to have to fall back on type Set a = Map a (). Map already has a keysSet, but it does the same inefficient thing building an intermediate list. all that is needed is a setToMap :: (a -> b) -> Set a -> Map a b the keysSet could be made more efficient in the next point release, but I guess adding setToMap would have to wait til the next major one. John -- John Meacham - ⑆repetae.net⑆john⑈

3 3

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 11 Oct '05

11 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