Re: [Haskell-cafe] How to determine correct dependency versions for a library?
* Erik Hesselink hessel...@gmail.com [2012-11-12 20:58:17+0100] And I believe the last base changes included a change to 'catch' which would have broken a lot of packages. The Num changes also caused a lot of code changes, and there were probably more I don't remember. Even if so, upper bounds don't prevent these errors. Cabal can't install an older base for you. (I'm aware that GHC once shipped two versions of base, and dependency bounds were actually useful then. But that's not the case nowadays, as we see.) For example, here's what I get when I try to install virthualenv with GHC 7.6.1: % cabal install virthualenv Resolving dependencies... cabal: Could not resolve dependencies: trying: virthualenv-0.2.1 rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) rejecting: base-4.6.0.0/installed-eac... (conflict: virthualenv = base=4.2.0.0 4.6) rejecting: base-4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (global constraint requires installed instance) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On 14 November 2012 20:35, Roman Cheplyaka r...@ro-che.info wrote: * Erik Hesselink hessel...@gmail.com [2012-11-12 20:58:17+0100] And I believe the last base changes included a change to 'catch' which would have broken a lot of packages. The Num changes also caused a lot of code changes, and there were probably more I don't remember. Even if so, upper bounds don't prevent these errors. Cabal can't install an older base for you. (I'm aware that GHC once shipped two versions of base, and dependency bounds were actually useful then. But that's not the case nowadays, as we see.) For example, here's what I get when I try to install virthualenv with GHC 7.6.1: % cabal install virthualenv Resolving dependencies... cabal: Could not resolve dependencies: trying: virthualenv-0.2.1 rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) rejecting: base-4.6.0.0/installed-eac... (conflict: virthualenv = base=4.2.0.0 4.6) rejecting: base-4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (global constraint requires installed instance) Doesn't this prevent the error of this package won't build (even if the error message doesn't precisely say that)? Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2012-11-14 20:53:23+1100] Doesn't this prevent the error of this package won't build (even if the error message doesn't precisely say that)? Yeah, it replaces one error with another. How is it supposed to help me if I really want to build this package? Instead of fixing just the code, I now have to fix the cabal file as well! Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On Wed, Nov 14, 2012 at 10:57 AM, Roman Cheplyaka r...@ro-che.info wrote: * Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2012-11-14 20:53:23+1100] Doesn't this prevent the error of this package won't build (even if the error message doesn't precisely say that)? Yeah, it replaces one error with another. How is it supposed to help me if I really want to build this package? Instead of fixing just the code, I now have to fix the cabal file as well! The error might be clearer, since it comes up right away, and points you to the right package, together with the reason (doesn't support the right base version). If it started to build instead, it might fail in the middle, with some error that you might not know is caused by changes in base. But the question comes down to numbers: how often do packages break with new base versions, how soon do people need to be able to use the new GHC without changing other packages, etc. Some might argue that packages 'usually' work, so we should leave out upper bounds, even if it gives worse errors. Others say the errors are so bad, or badly timed, that we should have upper bounds, and the work for maintainers, while greater, is not too large. I know what I think, but nobody has concrete numbers about breakages with new base versions, amount of time spent updating packages, unupdated packages etc. Some can be found with a grep over the hackage tarball, but most can't. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] local type denotation
Please, how to correctly set an explicit type for a local value in the body of a polymorphic function? Example (tested under ghc-7.6.1): data D a = D1 a | D2 a (a - a) f :: Eq a = D a - a f (D1 x) = x f (D2 x g) = let -- y :: Eq a = a y = g x in if x == y then x else g y main = putStr $ shows (f (D2 (1 :: Int) succ)) \n This is compiled byghc --make Main Now I need, for a certain reason, to explicitly set the type for y in `let', with the meaning: this very `a' which is in the signature for f (and I think that this type Haskell assignes to y in y = g x). I need to declare this type in a separate line: y :: what ever it is. Both `y :: a' and `y :: Eq a = a' are not compiled. Please, copy the answer to mech...@botik.ru Thanks, -- Sergei ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] local type denotation
{-# LANGUAGE ScopedTypeVariables #-}
Отправлено с iPhone
14.11.2012, в 16:03, Serge D. Mechveliani mech...@botik.ru написал(а):
Please,
how to correctly set an explicit type for a local value in the body of
a polymorphic function?
Example (tested under ghc-7.6.1):
data D a = D1 a | D2 a (a - a)
f :: Eq a = D a - a
f (D1 x) = x
f (D2 x g) = let -- y :: Eq a = a
y = g x
in if x == y then x else g y
main = putStr $ shows (f (D2 (1 :: Int) succ)) \n
This is compiled byghc --make Main
Now I need, for a certain reason, to explicitly set the type for y in
`let', with the meaning:
this very `a' which is in the signature for f
(and I think that this type Haskell assignes to y in y = g x).
I need to declare this type in a separate line: y :: what ever it is.
Both `y :: a' and `y :: Eq a = a' are not compiled.
Please, copy the answer to mech...@botik.ru
Thanks,
--
Sergei
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] local type denotation
Turn on the ScopedTypeVariables extension (e.g. by putting {-#
LANGUAGE ScopedTypeVariables #-} at the top of your file), and add an
explicit 'forall a.' to the type signature of f.
-Brent
On Wed, Nov 14, 2012 at 04:03:57PM +0400, Serge D. Mechveliani wrote:
Please,
how to correctly set an explicit type for a local value in the body of
a polymorphic function?
Example (tested under ghc-7.6.1):
data D a = D1 a | D2 a (a - a)
f :: Eq a = D a - a
f (D1 x) = x
f (D2 x g) = let -- y :: Eq a = a
y = g x
in if x == y then x else g y
main = putStr $ shows (f (D2 (1 :: Int) succ)) \n
This is compiled byghc --make Main
Now I need, for a certain reason, to explicitly set the type for y in
`let', with the meaning:
this very `a' which is in the signature for f
(and I think that this type Haskell assignes to y in y = g x).
I need to declare this type in a separate line: y :: what ever it is.
Both `y :: a' and `y :: Eq a = a' are not compiled.
Please, copy the answer to mech...@botik.ru
Thanks,
--
Sergei
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] local type denotation
You need to enable ScopedTypeVariables, and add a forall to introduce the
type variable at the top level. The local variable will then be the *same*
'a' instead of a fresh one:
{-# LANGUAGE ScopedTypeVariables #-}
data D a = D1 a | D2 a (a - a)
f :: forall a. Eq a = D a - a
f (D1 x) = x
f (D2 x g) = let y :: Eq a = a
y = g x
in if x == y then x else g y
main = putStr $ shows (f (D2 (1 :: Int) succ)) \n
On Wed, Nov 14, 2012 at 1:03 PM, Serge D. Mechveliani mech...@botik.ruwrote:
Please,
how to correctly set an explicit type for a local value in the body of
a polymorphic function?
Example (tested under ghc-7.6.1):
data D a = D1 a | D2 a (a - a)
f :: Eq a = D a - a
f (D1 x) = x
f (D2 x g) = let -- y :: Eq a = a
y = g x
in if x == y then x else g y
main = putStr $ shows (f (D2 (1 :: Int) succ)) \n
This is compiled byghc --make Main
Now I need, for a certain reason, to explicitly set the type for y in
`let', with the meaning:
this very `a' which is in the signature for f
(and I think that this type Haskell assignes to y in y = g x).
I need to declare this type in a separate line: y :: what ever it is.
Both `y :: a' and `y :: Eq a = a' are not compiled.
Please, copy the answer to mech...@botik.ru
Thanks,
--
Sergei
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange behavior with listArray
On Wed, Nov 14, 2012 at 07:39:33AM -, o...@okmij.org wrote: dimensional memo table. Luckily, our case is much less general. We do have a very nice dynamic programming problem. The key is the observation k' : solveR (i+1) k' After a new element, k', is produced, it is used as an argument to the solveR to produce the next element. This leads to a significant simplification: solve2 :: String - Array Int Int solve2 w = pI where h = length w - 1 wa = listArray (0, h) w pI = listArray (0,h) $ 0 : [ solveR i (pI!(i-1)) | i - [1..] ] solveR :: Int - Int - Int solveR i k = let c = wa!i in if k 0 wa!k /= c then solveR i (pI!(k-1)) else let k' = if wa!k == c then k + 1 else k in k' t2s1 = solve2 the rain in spain t2s2 = solve2 t2s3 = solve2 abbaabba My hat's off to you, sir. This is kind of interesting -- I would normally consider this indexing transformation as an approach for defeating memoization, yet in this case it serves as the key that makes the broader memoization possible, lifting it up a level. Thanks! Alex P.S. A side benefit of this approach is that it's easy to switch from listArray to array, since we already have the index handy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does anyone know where George Pollard is?
False alarm. He got back to me. Thanks, Myles On Thu, Nov 8, 2012 at 12:20 AM, Ketil Malde ke...@malde.org wrote: Myles C. Maxfield myles.maxfi...@gmail.com writes: Does anyone know where he is? On GitHub? https://github.com/Porges One of the repos was apparently updated less than a week ago. If not, is there an accepted practice to resolve this situation? Should I upload my own 'idna2' package? You can always upload a fork, but unless you have a lot of new functionality that won't fit naturally in the old package, you can perhaps try a bit more to contact the original author. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtl-2.1 severly broken, cabal needs blacklisting
On Wed, 14 Nov 2012, Jean-Philippe Bernardy wrote: On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel andreas.a...@ifi.lmu.de wrote: On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote: Blacklisting equals releasing a bugfix. Not quite. I propose to *define* blacklisting as such. package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V W (maybe I'm off by one position in the version number scheme here, but you get the idea) This rule is correct for packages following the Package Versioning Policy. Currently cabal-install and Cabal make no assumptions about the employed versioning scheme. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Peter Simons sim...@cryp.to wrote: Hi Clark. I think we just use dependencies [to specify] different things. If dependency version constraints are specified as a white-list -- i.e. we include only those few versions that have been actually verified and exclude everything else --, then we take the risk of excluding *too much*. There will be versions of the dependencies that would work just fine with our package, but the Cabal file prevents them from being used in the build. The opposite approach is to specify constraints as a black-list. This means that we don't constrain our build inputs at all, unless we know for a fact that some specific versions cannot be used to build our package. In that case, we'll exclude exactly those versions, but nothing else. In this approach, we risk excluding *too little*. There will probably be versions of our dependencies that cannot be used to build our package, but the Cabal file doesn't exclude them from being used. Now, the black-list approach has a significant advantage. In current versions of cabal-install, it is possible for users to extend an incomplete black-list by adding appropriate --constraint flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way. In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file. For this reason, dependency constraints in Cabal should rather be underspecified than overspecified. The blacklisting approach has one major disadvantage that noone has mentioned yet: Adding more restrictive constraints does not work, the broken package will be on hackage forever, while adding a new version with relaxed constraints works well. Consider the following example: A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified) B 2.5.3.0 build-depends: C ==3.* (underspecified) C 3.7.1.0 Everything works nice until C-3.8.0.0 appears with incompatible changes that break B, but not A. Now both A and B have to update their dependencies and we have now: A 1.1.5.0 build-depends: B ==2.5.* C =3.7 3.9 B 2.5.4.0 build-depends: C =3 3.8 C 3.8.0.0 And now the following combination is still valid: A 1.1.5.0 B 2.5.3.0 (old version) C 3.8.0.0 Bang! Tobi PS: This is my first post on this list. I'm not actively using haskell, but following this list for quite a while just out of interest. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
To prevent this, I think the PVP should specify that if dependencies get a major version bump, the package itself should bump its major version (preferably the B field). Hopefully, in the future, cabal would make a distinction between packages * used* within another package (such as a hashmap exclusively used to de-duplicate elements in lists) and packages *needed for the public API*(such as Data.Vector needed for aeson). That way, internal packages can update dependencies with impunity, and we still get the major version number bump of packages needed for the public API. - Clark On Wed, Nov 14, 2012 at 2:20 PM, Tobias Müller trop...@bluewin.ch wrote: Peter Simons sim...@cryp.to wrote: Hi Clark. I think we just use dependencies [to specify] different things. If dependency version constraints are specified as a white-list -- i.e. we include only those few versions that have been actually verified and exclude everything else --, then we take the risk of excluding *too much*. There will be versions of the dependencies that would work just fine with our package, but the Cabal file prevents them from being used in the build. The opposite approach is to specify constraints as a black-list. This means that we don't constrain our build inputs at all, unless we know for a fact that some specific versions cannot be used to build our package. In that case, we'll exclude exactly those versions, but nothing else. In this approach, we risk excluding *too little*. There will probably be versions of our dependencies that cannot be used to build our package, but the Cabal file doesn't exclude them from being used. Now, the black-list approach has a significant advantage. In current versions of cabal-install, it is possible for users to extend an incomplete black-list by adding appropriate --constraint flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way. In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file. For this reason, dependency constraints in Cabal should rather be underspecified than overspecified. The blacklisting approach has one major disadvantage that noone has mentioned yet: Adding more restrictive constraints does not work, the broken package will be on hackage forever, while adding a new version with relaxed constraints works well. Consider the following example: A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified) B 2.5.3.0 build-depends: C ==3.* (underspecified) C 3.7.1.0 Everything works nice until C-3.8.0.0 appears with incompatible changes that break B, but not A. Now both A and B have to update their dependencies and we have now: A 1.1.5.0 build-depends: B ==2.5.* C =3.7 3.9 B 2.5.4.0 build-depends: C =3 3.8 C 3.8.0.0 And now the following combination is still valid: A 1.1.5.0 B 2.5.3.0 (old version) C 3.8.0.0 Bang! Tobi PS: This is my first post on this list. I'm not actively using haskell, but following this list for quite a while just out of interest. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Clark Gaebel cgae...@uwaterloo.ca wrote: To prevent this, I think the PVP should specify that if dependencies get a major version bump, the package itself should bump its major version (preferably the B field). No, it has nothing to do with major/minor version bumps. It's just that if you underspecify your dependencies, they may become invalid at some point and you cannot correct them. Overspecified dependencies will always remain correct. Your suggested solution entirely defeats the purpose of underspecified dependencies, namely that you _don't_ have to update your package every time that a dependency is updated. Also, note that in my toy scenario, the maintainer of package A now also has to check the dependencies of package B. He must recognize that B-2.5.3.0 has incorrect dependencies, and exclude this version from the dependencies of B. So just because the maintainer of B was too lazy, all projects that depend on B have to insert special cases for bad versions of B. Hopefully, in the future, cabal would make a distinction between packages * used* within another package (such as a hashmap exclusively used to de-duplicate elements in lists) and packages *needed for the public API*(such as Data.Vector needed for aeson). That way, internal packages can update dependencies with impunity, and we still get the major version number bump of packages needed for the public API. If you reexport an API, you should probably make very tight dependency restrictions, if not just one single version. For packages that are developed in parallel this is even more natural. What is the advantage if cabal recognizes that? What could it do differently that you cannot do already by just setting the appropriate dependencies? Tobi Hi Clark. I think we just use dependencies [to specify] different things. If dependency version constraints are specified as a white-list -- i.e. we include only those few versions that have been actually verified and exclude everything else --, then we take the risk of excluding *too much*. There will be versions of the dependencies that would work just fine with our package, but the Cabal file prevents them from being used in the build. The opposite approach is to specify constraints as a black-list. This means that we don't constrain our build inputs at all, unless we know for a fact that some specific versions cannot be used to build our package. In that case, we'll exclude exactly those versions, but nothing else. In this approach, we risk excluding *too little*. There will probably be versions of our dependencies that cannot be used to build our package, but the Cabal file doesn't exclude them from being used. Now, the black-list approach has a significant advantage. In current versions of cabal-install, it is possible for users to extend an incomplete black-list by adding appropriate --constraint flags on the command-line of the build. It is impossible, however, to extend an incomplete white-list that way. In other words: build failures can be easily avoided if some package specifies constraints that are too loose. Build failures caused by version constraints that are too strict, however, can be fixed only by editing the Cabal file. For this reason, dependency constraints in Cabal should rather be underspecified than overspecified. The blacklisting approach has one major disadvantage that noone has mentioned yet: Adding more restrictive constraints does not work, the broken package will be on hackage forever, while adding a new version with relaxed constraints works well. Consider the following example: A 1.1.4.0 build-depends: B ==2.5.* C ==3.7.* (overspecified) B 2.5.3.0 build-depends: C ==3.* (underspecified) C 3.7.1.0 Everything works nice until C-3.8.0.0 appears with incompatible changes that break B, but not A. Now both A and B have to update their dependencies and we have now: A 1.1.5.0 build-depends: B ==2.5.* C =3.7 amp;amp; 3.9 B 2.5.4.0 build-depends: C =3 amp;amp; 3.8 C 3.8.0.0 And now the following combination is still valid: A 1.1.5.0 B 2.5.3.0 (old version) C 3.8.0.0 Bang! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On Wed, Nov 14, 2012 at 1:01 PM, Tobias Müller trop...@bluewin.ch wrote: Clark Gaebel cgae...@uwaterloo.ca wrote: To prevent this, I think the PVP should specify that if dependencies get a major version bump, the package itself should bump its major version (preferably the B field). No, it has nothing to do with major/minor version bumps. It's just that if you underspecify your dependencies, they may become invalid at some point and you cannot correct them. Overspecified dependencies will always remain correct. This is required if you want to maintain the property that clients don't break. If A-1.0 dependes on B-1.0.* and C depends on both A-1.0.* and B-1.0.*. Bumping dependency in A on B to B-2.0.* without bumping the major version number of A will cause C to fail to compile as it now depends on both B-1.0.* (directly) and B-2.0.* (though A-1.0). -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I killed performance of my code with Eval and Strategies
Dear Haskellers,
I am reading Simon Marlow's tutorial on parallelism and I have problems with
correctly using Eval
monad and Strategies. I *thought* I understand them but after writing some code
it turns out that
obviously I don't because parallelized code is about 20 times slower. Here's a
short example
(code + criterion benchmarks):
{-# LANGUAGE BangPatterns #-}
module Main where
import Control.Parallel.Strategies
import Criterion.Main
main :: IO ()
main = defaultMain [
bench Seq $ nf calculateSeq xs
, bench Par $ nf calculatePar xs ]
where xs = [1..16384]
calculateSeq :: [Double] - [Double]
calculateSeq [] = []
calculateSeq (x:xs) = (sin . sqrt $ x) : xs
calculatePar :: [Double] - [Double]
calculatePar xss = runEval $ go xss
where
go :: Strategy [Double]
go [] = return []
go xs = do
lsh - (rpar `dot` rdeepseq) $ calculateSeq as
lst - go bs
return (lsh ++ lst)
where
!(as, bs) = splitAt 8192 xs
Compiling and running with:
ghc -O2 -Wall -threaded -rtsopts -fforce-recomp -eventlog evalleak.hs
./evalleak -oreport.html -g +RTS -N2 -ls -s
I get:
benchmarking Seq
mean: 100.5990 us, lb 100.1937 us, ub 101.1521 us, ci 0.950
std dev: 2.395003 us, lb 1.860923 us, ub 3.169562 us, ci 0.950
benchmarking Par
mean: 2.233127 ms, lb 2.169669 ms, ub 2.296155 ms, ci 0.950
std dev: 323.5201 us, lb 310.2844 us, ub 344.8252 us, ci 0.950
That's a hopeless result. Looking at the spark allocation everything looks fine:
SPARKS: 202 (202 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
But analyzing eventlog with ThreadScope I see that parallel function spends
most of the time doing
garbage collection, which suggests that I have a memory leak somewhere. I
suspected that problem
might be caused by appending two lists together in the parallel implementation,
but replacing
this with difference lists doesn't help. Changing granularity (e.g. splitAt
512) also brings no
improvement. Can anyone point me to what am I doing wrong?
Janek
PS. This is of course not a real world code - I know that I'd be better of
using unboxed data
structures for doing computations on Doubles.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
Johan Tibell johan.tib...@gmail.com wrote: On Wed, Nov 14, 2012 at 1:01 PM, Tobias Müller trop...@bluewin.ch wrote: Clark Gaebel cgae...@uwaterloo.ca wrote: To prevent this, I think the PVP should specify that if dependencies get a major version bump, the package itself should bump its major version (preferably the B field). No, it has nothing to do with major/minor version bumps. It's just that if you underspecify your dependencies, they may become invalid at some point and you cannot correct them. Overspecified dependencies will always remain correct. This is required if you want to maintain the property that clients don't break. If A-1.0 dependes on B-1.0.* and C depends on both A-1.0.* and B-1.0.*. Bumping dependency in A on B to B-2.0.* without bumping the major version number of A will cause C to fail to compile as it now depends on both B-1.0.* (directly) and B-2.0.* (though A-1.0). I think I misunderstood Clarks suggestion. I thought he was advocating underspecified dependencies like A-1.*, but now when I am rereading it, it's actually the opposite. His proposal would explicitely disallow such dependencies. But it would probably be even too restrictive, since it generally disallows dependencies covering more than one major version, even if all those packages are already available and tested to be compatible. Also it only applies to the PVP. The distinction between blacklisting and whitelisting is more general and applies to all possible versioning schemes. Tobi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On 11/14/2012 09:53 AM, Ivan Lazar Miljenovic wrote: % cabal install virthualenv Resolving dependencies... cabal: Could not resolve dependencies: trying: virthualenv-0.2.1 rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) rejecting: base-4.6.0.0/installed-eac... (conflict: virthualenv = base=4.2.0.0 4.6) rejecting: base-4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (global constraint requires installed instance) Doesn't this prevent the error of this package won't build (even if the error message doesn't precisely say that)? In most cases, it replaces the uncertainty of a build error with an unconditional pre-build error. instead of having either a package built or a meaningful build error, i now have no package with the information that it might or might not cause an error to continue. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] local type denotation
On 15/11/2012, at 1:03 AM, Serge D. Mechveliani wrote: Please, how to correctly set an explicit type for a local value in the body of a polymorphic function? Other people have told you how to do it. I'd like to tell you why you don't need to. Example (tested under ghc-7.6.1): data D a = D1 a | D2 a (a - a) f :: Eq a = D a - a f (D1 x) = x f (D2 x g) = let -- y :: Eq a = a y = g x in if x == y then x else g y You say that you want y to have exactly the type a. Look around. Is there some data in scope with that type? Yes: (D2 x g) :: a = x :: a. So you just want to say y has the same type as x. There's a Prelude function asTypeOf :: a - a - a asTypeOf x y = x So e1 `asTypeOf` e2 gives you the value of e1, having first ensured that e1 and e2 have the same type. So f :: Eq a = D a - a f (D1 x) = x f (D2 x g) = if x == y then x else g y where y = g x `asTypeOf` x You apparently already know that you don't need any of this (thanks to x == y), but want to be explicit. The question is how explicit you want to be. Using asTypeOf is sort of half way between implicit typing and showing the type you want _as_ a type. The other question, I suppose, is _why_ you want to be explicit? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking over ghc-core
Excellent! With ghc-core being maintained again, we can start thinking about compiling Agda to core instead of hs. Andreas On 11.11.12 11:41 AM, Bas van Dijk wrote: Great! On 10 November 2012 16:17, Shachaf Ben-Kiki shac...@gmail.com wrote: With Don Stewart's blessing (https://twitter.com/donsbot/status/267060717843279872), I'll be taking over maintainership of ghc-core, which hasn't been updated since 2010. I'll release a version with support for GHC 7.6 later today. Shachaf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Andreas AbelDu bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.a...@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I killed performance of my code with Eval and Strategies
On Nov 14, 2012 10:44 PM, Janek S. fremenz...@poczta.onet.pl wrote: calculateSeq :: [Double] - [Double] calculateSeq [] = [] calculateSeq (x:xs) = (sin . sqrt $ x) : xs Do you really mean to calculate the 'sin . sqrt' of just the head of the list, or do you mean: calculateSeq = map (sin . sqrt) ? Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
