November 2009 - Libraries

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 23 Nov '09

23 Nov '09

> Valery V. Vorotyntsev wrote: >> Sorry, Sigbjorn, it didn't work. Sigbjorn Finne wrote: > Thanks - that's good, now we know :) I'm not so sure any more. >> I've rolled back to patched HTTP-4000.0.8, the one with connection >> closing commented out in `sendHTTP_notify'. I need this proxy >> downloading thing to just work... Cabal client reinstalled with "patched" HTTP-4000.0.8 was still having occasional failures today. My proxy-POC.hs always succeeded, while cabal failed quite often with familiar cabal: Codec.Compression.Zlib: premature end of compressed stream This means that proxy-POC.hs is not trustworthy: it doesn't expose the bug in 100% cases. I am going to roll back even further tomorrow: I'll patch [1] cabal-install to use strict ByteStrings and see if /that/ does the job. (I'm not sure in anything any more.) [1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9447#a9504 > I suspect tempering the notion of close and doing a socket shutdown > is the way forward here. So do I... If my suspicions are of any significance after several delusive "Wolf!" cries [2,3]. [2] http://hackage.haskell.org/trac/hackage/ticket/562#comment:9 [3] http://trac.haskell.org/http/ticket/8#comment:7 > I'll see if I can play with this some tonight. I've installed squid proxy server. Gotta make this bug exposable... -- Regards, vvv

1 1

Cabal and Hsc2hs Build Phase Options
by Matthew William Cox 20 Nov '09

20 Nov '09

Hello, Firstly, is there any way to specify (statically) options to be passed to Hsc2hs to be used during the build phase? Ideally, extending the --$PROGNAME-options command line argument to a cabal directive would be ideal, so that hsc2hs-options: would be a valid directory for use in .buildinfo/.cabal files. Is there a way to specificy the compiler and linker to be used in the invocation of hsc2hs? Secondly, there is a problem with how command line arguments are passed to hsc2hs. Running build with the command line argument: --hsc2hs-options="--cc=mpicc --ld=mpicc" -v yields the following call to hsc2hs: > Creating dist/build/dllg/dllg-tmp/System (and its parents) > /usr/bin/hsc2hs --cc=mpicc -ld=mpicc --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cflag=-D__G... Two compilers and two linkers are passed to Hsc2hs, but the later arguments (the default compilers) take precedence, as can be seen if the /bin/false is passed instead of mpicc. Cheers, Matt

2 2

ANNOUNCE: parallel-2.0.0.0
by Simon Marlow 19 Nov '09

19 Nov '09

I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon --------------------------------------------------------------------- Version 1.x The original Strategies design is described in <http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html> and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \"Runtime Support for Multicore Haskell\" <http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf>. This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a -> Done@ and is now @a -> a@. This change helps to fix the space leak described in \"Runtime Support for Multicore Haskell\". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \"new\" value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead.

3 4

Re: Could iteratee depend on mtl instead of transformers?
by John Lato 18 Nov '09

18 Nov '09

> Date: Tue, 17 Nov 2009 11:59:56 +0100 (CET) > From: Henning Thielemann <lemming(a)henning-thielemann.de> > > On Tue, 17 Nov 2009, Valery V. Vorotyntsev wrote: > >> Thus, the question is: are there any transformers-specific features >> iteratee package needs, or can it just go with mtl? > > The question is, whether Iteratee needs functions of MTL that transformers > does not provide? 'Transformers' is the more basic package, entirely > Haskell 98, thus should be prefered. It is however sad, that Transformers > cannot easily be used with GHCi in parallel with MTL installed. I was > always against that ... Renaming Control.Monad.Trans and > Control.Monad.Identity to something else would solve the conflict. I'm > also not happy, that you have to choose between monads-fd and monads-tf. I > think it would be better to be able to have both type class approaches. Iteratee does not need any MTL functions that transformers does not provide. It does the following: 1) implement instances of MonadTrans and MonadIO 2) uses lift and liftIO (polymorphically) There's no technical reason iteratee couldn't use mtl, and as Erik mentions, if you change the dependency it works just fine. For myself, I can be swayed by user demand, although I'd like to see the outcome of this discussion before committing to any changes. In all honesty, I never thought iteratee would generate enough interest for this to matter. It's not a particularly popular package. Cheers, John

2 1

iteratee (was: Could iteratee depend on mtl instead of transformers?)
by Valery V. Vorotyntsev 18 Nov '09

18 Nov '09

>> Valery V. Vorotyntsev wrote: >> >>> Thus, the question is: are there any transformers-specific features >>> iteratee package needs, or can it just go with mtl? > Henning Thielemann wrote: > >> The question is, whether Iteratee needs functions of MTL that transformers >> does not provide? 'Transformers' is the more basic package, entirely >> Haskell 98, thus should be prefered. It is however sad, that Transformers >> cannot easily be used with GHCi in parallel with MTL installed. I was >> always against that ... Renaming Control.Monad.Trans and >> Control.Monad.Identity to something else would solve the conflict. I'm >> also not happy, that you have to choose between monads-fd and monads-tf. I >> think it would be better to be able to have both type class approaches. John Lato wrote: > Iteratee does not need any MTL functions that transformers does not > provide. It does the following: > > 1) implement instances of MonadTrans and MonadIO > 2) uses lift and liftIO (polymorphically) > > There's no technical reason iteratee couldn't use mtl, and as Erik > mentions, if you change the dependency it works just fine. For > myself, I can be swayed by user demand, although I'd like to see the > outcome of this discussion before committing to any changes. I for one have no demand any more. I'm doing fine with the following lines in module: {-# LANGUAGE PackageImports #-} -- ... import "transformers" Control.Monad.Trans > In all honesty, I never thought iteratee would generate enough > interest for this to matter. It's not a particularly popular > package. I thought it was. :) http://comonad.com/reader/2009/iteratees-parsec-and-monoid/ http://therning.org/magnus/archives/735 http://stackoverflow.com/questions/1319705 http://www.johantibell.com/Left_fold_enumerators.pdf -- vvv

1 0

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

> Valery V. Vorotyntsev wrote: >> Could you please notify me, if you make any commits tomorrow in day time? >> >> git port is not accessible for me in working hours: the proxied LAN allows >> outbound connection to 80 and 443 ports only. But when I know there are >> new commits, I'll establish GPRS connection and download 'em. Sigbjorn Finne wrote: > Certainly, but no immediate plans to do so -- you can see repo updates via > http://code.galois.com/ > (and subscribe to feeds to be notified that way.) Oh, I didn't know about these feeds. Thanks! > It'd be nice if code.galois allowed clone/pulls via http.. It would be, yes. Only few sites seem to care. I start to wonder, whether proxied [office] LANs are so rare nowadays? :) -- vvv

1 0

Re: Proposal: System.FilePath: current directory should be ".", not ""
by wren ng thornton 16 Nov '09

16 Nov '09

Ben Moseley wrote: > Duncan Coutts wrote: >> My intuition with file paths in Cabal, is that this distinction would >> catch more bugs. Ideally cabal's building code would be independent of >> the current directory, but the fact that relative paths get >> automagically completed to being relative to the current directory means >> that it's very easy to break this property. > > [...] > >> There are various other distinctions one could try to make, the question >> becomes which type distinctions are useful and when does it just become >> too much. > > I think this is a very important point. It's definitely a balancing > act. I have > ondered whether even capturing Abs/Rel was overkill, but my current > feeling > (not yet based on much real-world experience) is that it is worth it. Having done a lot of system administration and metaprogramming of system administration, I can certainly say that making the relative/absolute distinction is helpful for tracking down bugs. From the same set of experience I'd say that Duncan's incomplete/complete distinction would be even more helpful. With a lot of sysadmin metaprogramming (which includes package installers) what people are really working on is grafting different trees together. It's important to distinguish which paths/trees are being created and don't yet refer to an actual or potential file on the disk, from those paths/trees which refer to actual/potential files on the disk. To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing. With the complete/incomplete distinction we distinguish names which aren't yet grounded from names that refer to files, regardless of where they're mounted. With the relative/absolute distinction we don't know when a path is finished being constructed, and we also have no real vocabulary for expressing paths relative from some point other than the current directory. Most sysadmins don't seem to realize they're doing tree grafting when they mess with this stuff, so I can see why it might seem foreign, but viewing it that way really does help clean code up and find bugs. Tree grafting also forms a monad, which could be helpful for some folks. -- Live well, ~wren

3 2

Re: #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

On Mon, Nov 16, 2009 at 3:26 PM, Sigbjorn Finne <sigbjorn.finne(a)gmail.com> wrote: > Thanks - that's good, now we know :) I suspect tempering the notion of > close and doing > a socket shutdown is the way forward here. I'll see if I can play with this > some tonight. Good luck with that! :) -- vvv

1 0

Re: Advance warning to package authors of breakage
by Duncan Coutts 16 Nov '09

16 Nov '09

On Mon, 2009-11-16 at 12:28 +0100, Mikhail Glushenkov wrote: > Hi, > > On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: > > > > These packages all use "build-depends: base >= 3 && < 5" (except for > > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > > we will ban if it becomes any more popular). > > I have one question. It looks like the recommended way to solve the > problem is to use something like: > > Flag separateSYB > Description: Data.Generics available in separate package. > > [...] > if flag(separateSYB) > build-Depends: base >= 3 && < 4 > else > build-Depends: base >= 4 && < 5, syb > > When the user types 'cabal install pointful' (without providing > -fseparateSYB), which version of base will be the executable built > against? It prefers the default value of the flag. If that's impossible then it tries with the non-default flag value. When you do not specify a default flag value, the default is True. So as you've written it, in the absence of any constraints it'll pick the separateSYB=True configuration, which as you've written it, will *not* use the separate syb package. I think you intended to write it the other way around. Duncan

1 0

Fwd: Advance warning to package authors of breakage
by Mikhail Glushenkov 16 Nov '09

16 Nov '09

Hi, On Mon, Nov 16, 2009 at 1:47 AM, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > > These packages all use "build-depends: base >= 3 && < 5" (except for > ghc-core which cheekily uses "build-depends: base < 10" --- a practise > we will ban if it becomes any more popular). I have one question. It looks like the recommended way to solve the problem is to use something like: Flag separateSYB Description: Data.Generics available in separate package. [...] if flag(separateSYB) build-Depends: base >= 3 && < 4 else build-Depends: base >= 4 && < 5, syb When the user types 'cabal install pointful' (without providing -fseparateSYB), which version of base will be the executable built against? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 0