Re: [Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)
Speaking of which, I haven't been tracking this lately. Does it support having multiple environments using a shared sandbox? For example, if I'm writing multiple parser-based things, can I have a 'parsec' sandbox that lives in someplace like ~/.cabalenv/parsec and have both project1 and project2 use it? On Thursday, October 4, 2012 at 10:13 PM, Johan Tibell wrote: On Thu, Oct 4, 2012 at 7:11 PM, Tim Docker t...@dockerz.net (mailto:t...@dockerz.net) wrote: Does this new release included the sandbox functions discussed in this blog post: http://blog.johantibell.com/2012/08/you-can-soon-play-in-cabal-sandbox.html ? It doesn't. The sandbox feature requires a little UI work still. I expect to have it out by the end of the year. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org (mailto: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] ANNOUNCE: test-framework-golden-1.1
Hi, I am glad to announce the first public release of test-framework-golden — a golden testing library. Nice! The library is integrated with test-framework, so you can use golden tests in addition to SmallCheck/QuickCheck/HUnit tests. I would suggest to rename the modules to Test.Framework.Golden and Test.Framework.Golden.Advanced to more clearly represent that fact. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
* Simon Hengel s...@typeful.net [2012-10-05 09:07:19+0200] Hi, I am glad to announce the first public release of test-framework-golden — a golden testing library. Nice! The library is integrated with test-framework, so you can use golden tests in addition to SmallCheck/QuickCheck/HUnit tests. I would suggest to rename the modules to Test.Framework.Golden and Test.Framework.Golden.Advanced to more clearly represent that fact. According to the test-framework convention, they ought to be named Test.Framework.Providers.Golden and Test.Framework.Providers.Golden.Advanced respectively, and you can see that it was the case in the early versions: http://hackage.haskell.org/package/test-framework-golden-1.0 But it's just too much to type. My justification (which you may or may not buy) is that, unlike, say, Test.Framework.Providers.HUnit, this is not an adaptation of an existing testing library to test-framework, but is a new library that just happens to use test-framework. So it's more like Test.HUnit, although it already subsumes what would become Test.Framework.Providers.Golden. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
* Gianfranco Alongi gianfranco.alo...@gmail.com [2012-10-05 06:57:41+0200] I'm a big fan of TDD and tend to approach all languages by learning how to TDD in them. As such, you mention that this is similar, could you please send some links about this? Sorry, I'm not sure I understand the question. Links about what? The library documentation is available on Hackage (the first link below). If you're asking about TDD in Haskell in general, I doubt I can tell you anything that Google can't. Roman On Thu, Oct 4, 2012 at 11:55 PM, Roman Cheplyaka r...@ro-che.info wrote: I am glad to announce the first public release of test-framework-golden — a golden testing library. Hackage: http://hackage.haskell.org/package/test-framework-golden GitHub: https://github.com/feuerbach/test-framework-golden Golden tests are similar to unit tests (as implemented in HUnit), but the idea is to store the expected result in files (called «golden» files). I was introduced to the idea of golden testing by Bohdan Vlasyuk at ZuriHac in 2010. Since then I've discovered that this is a nice approach and it is already used in variety of projects (e.g. ghc, haddock). Surprisingly, not much is written about golden testing, and I've been unable to find any golden testing libraries for Haskell or any other programming language. Every project has its own ad-hoc implementation in Haskell/Python/Shell/etc. The closest match on the market is Simon Michael's shelltestrunner. But to use it you have to expose the tested functionality via command line, which may be inconvenient. So this is my attempt at a general golden testing library. It consists of two modules. Test.Golden has a simple interface that helps you get started very quickly. Test.Golden.Advanced provides a very generic testing function that you can use to implement the testing system you dream about. The library is integrated with test-framework, so you can use golden tests in addition to SmallCheck/QuickCheck/HUnit tests. In future there's a plan to support some golden test management capabilities. Roman ___ 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] ANNOUNCE: test-framework-golden-1.1
* Tim Docker t...@dockerz.net [2012-10-05 12:19:40+1000] Hi Roman, This sounds like a great idea. As you suggest, I've put this kind of thing together in scripts many times, without a consistent framework. I haven't tried it yet, but have one question. When you call a function like goldenVsString I assume one generally provides a relative path. what is the file path relative to? How does one arrange a package of haskell code and associated golden files, and reference the golden files from within the haskell so that the tree works from any location? The paths are naturally relative to the working directory of the test executable. In my projects, I typically have ./test.hs ./tests/case1.golden ./tests/case2.golden ./tests/case3.golden And so test.hs refers to test cases by relative paths like tests/case1.golden. Of course, that'll only work if you run test.hs from its directory, but it is the case most of the time anyway. Also, since paths are relative to the directory containing the project.cabal file, cabal test works, too. If, for some reason, you want to be able to run tests from any location, you could provide the path to golden paths e.g. via an environment variable. Roman On 05/10/12 07:55, Roman Cheplyaka wrote: I am glad to announce the first public release of test-framework-golden — a golden testing library. Hackage: http://hackage.haskell.org/package/test-framework-golden GitHub: https://github.com/feuerbach/test-framework-golden Golden tests are similar to unit tests (as implemented in HUnit), but the idea is to store the expected result in files (called «golden» files). I was introduced to the idea of golden testing by Bohdan Vlasyuk at ZuriHac in 2010. Since then I've discovered that this is a nice approach and it is already used in variety of projects (e.g. ghc, haddock). Surprisingly, not much is written about golden testing, and I've been unable to find any golden testing libraries for Haskell or any other programming language. Every project has its own ad-hoc implementation in Haskell/Python/Shell/etc. The closest match on the market is Simon Michael's shelltestrunner. But to use it you have to expose the tested functionality via command line, which may be inconvenient. So this is my attempt at a general golden testing library. It consists of two modules. Test.Golden has a simple interface that helps you get started very quickly. Test.Golden.Advanced provides a very generic testing function that you can use to implement the testing system you dream about. The library is integrated with test-framework, so you can use golden tests in addition to SmallCheck/QuickCheck/HUnit tests. In future there's a plan to support some golden test management capabilities. Roman ___ 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] ANNOUNCE: test-framework-golden-1.1
My justification (which you may or may not buy) is that, unlike, say, Test.Framework.Providers.HUnit, this is not an adaptation of an existing testing library to test-framework, but is a new library that just happens to use test-framework. So it's more like Test.HUnit, although it already subsumes what would become Test.Framework.Providers.Golden. Unless HUnit, it's unlikely that this will be integrated into other testing frameworks. So I think it is less general. Anyway, it's up to you. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
Talking about good timing - I was just finishing my post on code testing in Haskell when your announcement came up, so your library made it as a last minute news :) I never used golden approach to testing but it is good to know that it exists. *I* think that it might be a good idea to separete your library into two parts: the golden functionality itself and test-framework provider. Right now it seems impossible to use your library outside of test-framework. For me that's not a big deal, cause I use test-framework anyway, but I suspect you could get more users that way. According to the test-framework convention, they ought to be named Test.Framework.Providers.Golden and Test.Framework.Providers.Golden.Advanced respectively, and you can see that it was the case in the early versions: http://hackage.haskell.org/package/test-framework-golden-1.0 But it's just too much to type. Well, I'm already typing Test.Framework.Providers.QuickCheck2, so that's not a big deal really :) Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] total Data.Map.! function
Hi Henning,
Am Mittwoch, den 03.10.2012, 19:52 +0200 schrieb Henning Thielemann:
I wondered whether there is a brilliant typing technique that makes
Data.Map.! a total function. That is, is it possible to give (!) a type,
such that m!k expects a proof that the key k is actually present in the
dictionary m? How can I provide the proof that k is in m?
I think it is possible to do this using the same trick that ST is using,
i.e. rank 2 types. The problem is that this code is likely to be
unwieldy to use, as the variable needs to change with every change to
the map – but I guess if you create your map once and then use it in
various places without modification, this can actually work.
So we need to tag values (maps and keys) with variables. We could use
Edward Kmett’s tagged library, but for now lets just roll our own (full
code in the right order attached):
newtype Tagged a x = Tag { unTag :: x }
retag :: Tagged t1 x - Tagged t2 x
retag (Tag x) = (Tag x)
The idea is that if you have a Tagged a (Map k v) and a Tagged a k,
where the a’s are the same variable, then you have a guarantee that the
key is in the map. In the code we are writing now we can easily break
that, e.g. using retag, but hopefully not via the functions that we are
going to export in the end.
The lookup function just ensures that the tags agree, if all goes well
the fromJust will never fail:
lookup :: Ord k = Tagged t k - Tagged t (Map k v) - v
lookup (Tag k) (Tag m) = fromJust $ M.lookup k m
We want a function that takes an existing map and tags it. As with most
of the functions that follow, we use continuation passing style with a
rank-2-function to ensure that no assumptions can be made about the tag
variable at all.
fromMap :: Map k v - (forall t. Tagged t (Map k v) - c) - c
fromMap m f = (f (Tag m))
The user of this code has no tagged keys of this type yet, so he cannot
use lookup yet. Let’s allow him to add an entry:
insert :: Ord k =
k - v - Tagged t1 (Map k v) -
(forall t2. Tagged t2 (Map k v) - Tagged t2 k - (Tagged t1 k -
Tagged t2 k) - c) -
c
insert k v (Tag m) f = f (Tag (M.insert k v m)) (Tag k) retag
Besides the usual arguments (key, value, map), it takes a continuation.
This receives the updated map with a /new/ tag – after all, our
knowledge about it has changed. We also return the tagged key; this is
the proof (or the certificate) that the key is in the map that can be
passed to lookup. And finally we pass a function that takes a proof „k
is in the original map“ and turns it into a proof „k is in the update
map“.
We can also allow the programmer to check if a key is present, and
obtain a proof if that is the case:
check :: Ord k = k - Tagged t1 (Map k v) -
(forall t2. Tagged t2 (Map k v) - Maybe (Tagged t2 k) - (Tagged
t1 k - Tagged t2 k) - c) -
c
check k (Tag m) f = f (Tag m) (if M.member k m then Just (Tag k) else
Nothing) retag
This would be useful when a non-empty map is converted with fromMap. The
type of this function could be varied, e.g. by not creating a new tag at
all if the type is not present.
Finally we need to select the functions that are safe to use for the
export list:
module SafeMap (Tagged, unTag, fromMap, insert, lookup, check)
More functions need to be added, e.g. an adjust (which luckily would not
require a continuation-style type).
Here is some code that uses the library to implement fromList (it is
nice to see that this is possible given the primitives above):
{-# LANGUAGE Rank2Types #-}
import Data.Map (Map, empty)
import SafeMap
fromList :: Ord k = [(k,v)] - (forall t. Tagged t (Map k v) -
[Tagged t k] - c) - c
fromList [] f = fromMap empty $ \m - f m []
fromList ((k,v):l) f = fromList l $ \m tks -
insert k v m $ \m' tk rt -
f m' (tk : map rt tks)
And here is it in use:
*Main fromList [(1,1),(2,2)] (curry show)
(Tag {unTag = fromList [(1,1),(2,2)]},[Tag {unTag = 1},Tag {unTag =
2}])
The map rt will make this quadratic, as GHC does not detect if you map
an (operationally speaking) identity over a list. Hopefully that will be
fixed eventually: http://hackage.haskell.org/trac/ghc/ticket/2110
Is this anything like what you wanted?
Greetings,
Joachim
--
Joachim nomeata Breitner
m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C
xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
{-# LANGUAGE Rank2Types #-}
module SafeMap (Tagged, unTag, fromMap, insert, lookup, check) where
import qualified Data.Map as M
import Data.Map (Map)
import Data.Maybe
import Prelude hiding (lookup)
newtype Tagged a x = Tag { unTag :: x }
deriving (Show)
retag :: Tagged t1 x - Tagged t2 x
retag (Tag x) = (Tag x)
fromMap :: Map k v - (forall t.
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
* Janek S. fremenz...@poczta.onet.pl [2012-10-05 10:51:35+0200] Talking about good timing - I was just finishing my post on code testing in Haskell when your announcement came up, so your library made it as a last minute news :) I never used golden approach to testing but it is good to know that it exists. Cool, looking forward to reading it! I hope you won't forget to cover SmallCheck in your article as well. Being also the maintainer of SmallCheck, I want it to steal some fame from QuickCheck :) *I* think that it might be a good idea to separete your library into two parts: the golden functionality itself and test-framework provider. Right now it seems impossible to use your library outside of test-framework. For me that's not a big deal, cause I use test-framework anyway, but I suspect you could get more users that way. In theory I totally agree, but: 1. It's hard to guess at the moment how a good interface to the pure golden part should look like. 2. I'd rather avoid doing work when there's no demand. So when I see someone interested in using it outside of test-framework, I'm sure we'll figure something out. Roman According to the test-framework convention, they ought to be named Test.Framework.Providers.Golden and Test.Framework.Providers.Golden.Advanced respectively, and you can see that it was the case in the early versions: http://hackage.haskell.org/package/test-framework-golden-1.0 But it's just too much to type. Well, I'm already typing Test.Framework.Providers.QuickCheck2, so that's not a big deal really :) Jan ___ 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] ANNOUNCE: test-framework-golden-1.1
* Janek S. fremenz...@poczta.onet.pl [2012-10-05 11:50:53+0200] Cool, looking forward to reading it! Well, the post is already finished: http://ics.p.lodz.pl/~stolarek/blog/2012/10/code-testing-in-haskell/ I was just going to publish it and then your email came up on the list. I hope you won't forget to cover SmallCheck in your article as well. Being also the maintainer of SmallCheck, I want it to steal some fame from QuickCheck :) Sorry to disappoint you, but I did not mention SmallCheck. So far I'm relying on QuickCheck and didn't feel like I need to look for other testing library. I might be wrong of course. There are some technical advantages to SmallCheck (determinism, no need to shrink etc.), but the main reason I prefer it is because it gives me more confidence. With quickcheck, I know that it generated 100 tests, but I've no idea what those tests are, and whether the RNG missed some important corner cases. With SmallCheck I know that it tried *all* cases up to certain depth, so it's much more reassuring. (Except for cases when the notion of depth isn't that informative, like floating-point numbers.) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] does try force evaluation of IO value
if i have some lazy io action, assuming (maction :: IO a) which may raise exceptions while running, will try force evaluation of a to determine is exception raised or not ? Sorry for my broken english. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
Cool, looking forward to reading it! Well, the post is already finished: http://ics.p.lodz.pl/~stolarek/blog/2012/10/code-testing-in-haskell/ I was just going to publish it and then your email came up on the list. I hope you won't forget to cover SmallCheck in your article as well. Being also the maintainer of SmallCheck, I want it to steal some fame from QuickCheck :) Sorry to disappoint you, but I did not mention SmallCheck. So far I'm relying on QuickCheck and didn't feel like I need to look for other testing library. I might be wrong of course. In theory I totally agree, but: 1. It's hard to guess at the moment how a good interface to the pure golden part should look like. 2. I'd rather avoid doing work when there's no demand. I guess these are valid points. Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
There are some technical advantages to SmallCheck (determinism, no need to shrink etc.), but the main reason I prefer it is because it gives me more confidence. With quickcheck, I know that it generated 100 tests, but I've no idea what those tests are, and whether the RNG missed some important corner cases. With SmallCheck I know that it tried *all* cases up to certain depth, so it's much more reassuring. (Except for cases when the notion of depth isn't that informative, like floating-point numbers.) I looked at documentation of SmallCheck and I guess it deserves more attention from me :) Test repeatibility sounds very good - that's something I actually miss in QC. Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does try force evaluation of IO value
* s9gf4...@gmail.com s9gf4...@gmail.com [2012-10-05 16:02:03+0600] if i have some lazy io action, assuming (maction :: IO a) which may raise exceptions while running, will try force evaluation of a to determine is exception raised or not ? Sorry for my broken english. No, it won't force the return value. To do that, use evaluate http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Exception-Base.html#g:7 Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does try force evaluation of IO value
No, it won't force the return value. To do that, use evaluate http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Exc eption-Base.html#g:7 But what is happening when exception is raised when consuming value from result of try ? try has signature try :: Exception e = IO a - IO (Either e a) so it must return either exception value either evaluated value and must not raise exceptions, but how can try return (Right a) wthout making sure that action will not raise any exception ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does try force evaluation of IO value
* s9gf4...@gmail.com s9gf4...@gmail.com [2012-10-05 16:52:52+0600]
No, it won't force the return value. To do that, use evaluate
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Exc
eption-Base.html#g:7
But what is happening when exception is raised when consuming value from
result of try ?
try has signature
try :: Exception e = IO a - IO (Either e a)
so it must return either exception value either evaluated value and must not
raise exceptions, but how can try return (Right a) wthout making sure that
action will not raise any exception ?
There's no promise that the returned lazy value won't throw any
exceptions. Example:
Prelude Control.Exception r - try (return $ error bam) :: IO (Either
SomeException Int)
Prelude Control.Exception r
Right *** Exception: bam
try will only catch exceptions that arise from executing the IO action.
If you need to be sure that no exception will be raised, you need to
force it yourself, like this:
Prelude Control.Exception r - try (evaluate $ error bam) :: IO (Either
SomeException Int)
Prelude Control.Exception r
Left bam
If the return type is a lazy structure, you may also need to use deepseq
('evaluate' only evaluates to WHNF).
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] referential transparency? (for fixity of local operators)
I was really surprised at the following: *Main 1 + 2 * 3 7 *Main ( \ (+) (*) - 1 + 2 * 3 ) (+) (*) 9 because I was somehow assuming that either a) the Prelude fixities of the operators are kept b) or they are undefined, so the parser rejects. but the Haskell standard says Any operator lacking a fixity declaration is assumed to be infixl 9. This really should be infix 9? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does try force evaluation of IO value
Prelude Control.Exception r - try (return $ error bam) :: IO (Either SomeException Int) Prelude Control.Exception r Right *** Exception: bam Wow, this is realy breaking news for me. Where can i read more about this magic ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] referential transparency? (for fixity of local operators)
* Johannes Waldmann waldm...@imn.htwk-leipzig.de [2012-10-05 11:11:48+] I was really surprised at the following: *Main 1 + 2 * 3 7 *Main ( \ (+) (*) - 1 + 2 * 3 ) (+) (*) 9 because I was somehow assuming that either a) the Prelude fixities of the operators are kept b) or they are undefined, so the parser rejects. but the Haskell standard says Any operator lacking a fixity declaration is assumed to be infixl 9. This really should be infix 9? This behaviour is really handy when you use functions as operators (using backticks notation). They typically lack infix annotations, but having to put parentheses would be very annoying. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
1. It's hard to guess at the moment how a good interface to the pure golden part should look like. Maybe just produce HUnit assertions, e.g.: goldenVsFile :: FilePath - FilePath - IO () - Assertion That way it works with plain HUnit main = runTestTT $ TestLabel someAction produce desired output $ goldenVsFile ref.txt out.txt someAction test-framework main = defaultMain [ testGroup someAction [ testCase produces some desired output $ goldenVsFile ref.txt out.txt someAction ] ] Hspec main = hspec $ do describe someAction $ do it produces some desired output $ do goldenVsFile ref.txt out.txt someAction and probably every other current or future Haskell test framework. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] referential transparency? (for fixity of local operators)
Compile with -Wall and the flaw becomes obvious: interactive:2:5: Warning: This binding for `+' shadows the existing binding imported from `Prelude' (and originally defined in `GHC.Num') interactive:2:9: Warning: This binding for `*' shadows the existing binding imported from `Prelude' (and originally defined in `GHC.Num') interactive:2:16: Warning: Defaulting the following constraint(s) to type `Integer' (Num a0) arising from the literal `1' In the first argument of `(+)', namely `1' In the first argument of `(*)', namely `1 + 2' In the expression: 1 + 2 * 3 interactive:2:16: Warning: Defaulting the following constraint(s) to type `Integer' (Num a0) arising from the literal `1' at interactive:2:16 (Show a0) arising from a use of `print' at interactive:2:1-34 In the first argument of `(+)', namely `1' In the first argument of `(*)', namely `1 + 2' In the expression: 1 + 2 * 3 Shadowing is bad, and tends (as in this case) to be confusing. - Clark On Fri, Oct 5, 2012 at 7:22 AM, Roman Cheplyaka r...@ro-che.info wrote: * Johannes Waldmann waldm...@imn.htwk-leipzig.de [2012-10-05 11:11:48+] I was really surprised at the following: *Main 1 + 2 * 3 7 *Main ( \ (+) (*) - 1 + 2 * 3 ) (+) (*) 9 because I was somehow assuming that either a) the Prelude fixities of the operators are kept b) or they are undefined, so the parser rejects. but the Haskell standard says Any operator lacking a fixity declaration is assumed to be infixl 9. This really should be infix 9? This behaviour is really handy when you use functions as operators (using backticks notation). They typically lack infix annotations, but having to put parentheses would be very annoying. Roman ___ 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] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)
The very day before this announcement, I was porting my buildwrapper
library to GHC 7.6.1, and then noticed that I couldn't get a version
of cabal-install built with the Cabal library shipped with GHC. I
thought I'm not going to bother anybody, I'll just wait, and the
next day, hop, there it is! Thanks guys, much appreciated!
Installed on a Windows XP with GHC 7.6.1 with no issue. Even network
installed first time with a properly configured MSYS shell.
After porting buildwrapper, 100% of the test cases pass, I'm happy.
Thanks to all for this release!
JP
On Wed, Oct 3, 2012 at 6:06 PM, Johan Tibell johan.tib...@gmail.com wrote:
On the behalf of the many contributors to cabal, I'm proud to present
cabal-install-1.16.0. This release contains almost a year worth of
patches. Highlights include:
* Parallel installs (cabal install -j)
* Several improvements to the dependency solver.
* Lots of bugfixes
We're also simultaneously releasing Cabal-1.16.0.1, which address a few bugs.
To install:
cabal update
cabal install cabal-install-1.16.0 Cabal-1.16.0.1
Complete list of changes in cabal-install-1.16.0:
* Bump cabal-install version number to 1.16.0
* Extend the unpack command for the .cabal file updating
* On install, update the .cabal file with the one from the index
* Make compatible with `network-2.4` API
* Update ZLIB_VER in bootstrap.sh for ghc-7.6 compatibility
* cabal-install.cabal: add Distribution.Client.JobControl and
Distribution.Compat.Time
* Adapt bootstrap.sh to ghc-7.6 changes
* Move comment that was missed in a refactoring
* cabal-install: Adapt for GHC 7.6
* Ensure that the cabal-install logfile gets closed
* Make cabal-install build with Cabal-1.16.
* Initialise the 'jobs' config file setting with the current number of
CPU cores.
* Update version bounds for directory.
* Update bootstrap.sh to match platform 2012.2.0.0
* Relax dependency on containers.
* Bump versions.
* Better output for parallel install.
* Fix warnings.
* Remove 'tryCachedSetupExecutable'.
* Redundant import.
* Use a lock instead of 'JobControl 1'.
* Comments, cosmetic changes.
* Implement the setup executable cache.
* Add the missing JobControl module
* Fix missing import after merge of par build patches
* Fix impl of PackageIndex.allPackagesByName
* Drop the ghc-options: -rtsopts on cabal-install. We do not need it.
* Parallelise the install command This is based on Mikhail Glushenkov's
patches.
* InstallPlan: Add a Processing package state.
* Add a '-j' flag for the 'install' command.
* Add -threaded and -rtsopts to cabal-install's ghc-options.
* Fix typos.
* Fix warnings.
* 80-col violation.
* Spelling.
* Fix warnings.
* Extended a comment.
* Force the log for the error to be printed in parallel with the complete
trace.
* Remove goal choice nodes after reordering is completed.
* Make modular solver handle manual flags properly.
* Store manual flag info in search tree.
* Maintain info about manual flags in modular solver.
* Fix cabal-install build.
* Merge pull request #6 from pcapriotti/master
* Adapt to change in GHC package db flags.
* Merge pull request #1 from iustin/master
* Add support for Apache 2.0 license to cabal-install
* Handle test and bench stanzas without dependencies properly in modular
solver.
* Updated repo location in cabal files.
* last-minute README changes
* updated copyright year for Duncan
* updated changelog
* added deepseq to bootstrap.sh
* handling the solver options properly in config file
* handling the optimization option properly in config file
* Update cabal-install bootstrap.sh
* treat packages that are unknown no longer as an internal error in
modular solver
* minor wording change when printing install plans
* no longer pre-filter broken packages for modular solver
* for empty install plans, print the packages that are installed
* make the reinstall check less noisy
* disable line-wrapping for solver debug output
* adding a solver flag for shadowing of installed packages
* adding the possibility for index-disabled packages
* choose default solver based on compiler version
* Added a comment
* Use the new --package-db flag stuff in cabal-install
* head cabal-install requires head Cabal
* Fix ticket #731
* Add brief description of PVP to cabal init generated .cabal files
* Bump versions to 1.15 and 0.15 This is the head branch, the 1.14.x
and 0.14.x are in the 1.14 branch.
* init: guess at filling in deps in the build-depends: field
* init: see whether source directory 'src' exists.
* init: improve prompt: enclose y/n in parens
* init: improve prompt: 'homepage' field is not for repos.
* bootstrap with --global should still respect $PREFIX
* Update cabal-install boostrap.sh package versions
* Fix 'cabal configure --enable-{tests,benchmarks}'. 'cabal configure'
was not adding optional stanza constraints when checking dependencies,
causing '--enable-{tests,benchmarks}' to be
Re: [Haskell-cafe] referential transparency? (for fixity of local operators)
On 10/5/12 7:11 AM, Johannes Waldmann wrote: I was really surprised at the following: *Main 1 + 2 * 3 7 *Main ( \ (+) (*) - 1 + 2 * 3 ) (+) (*) 9 because I was somehow assuming that either a) the Prelude fixities of the operators are kept After dealing with how Coq handles infix operators, I'm profoundly glad that Haskell doesn't do this. The fixity of an operator is a property of the operator itself, not of the notation used to display the operator. There's no reason for my (+) operator to have the same fixity as your (+) operator, regardless of whether we happen to use the same notation or not. b) or they are undefined, so the parser rejects. but the Haskell standard says Any operator lacking a fixity declaration is assumed to be infixl 9. This really should be infix 9? Yep, default fixity. As Roman Cheplyaka mentioned, this is especially helpful for ad hoc uses of backticks. (For non-adhoc uses, it's best to give an explicit fixity just like for other infix operators.) As for whether the default should be infix 9 instead of infixl 9, I dunno... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: luachunk-0.1
Hi all, I just released luachunk-0.1 on Hackage (http://github.com/ajnsit/luachunk). Luachunk is a small library to read and write Lua 5.1 bytecode chunks. It is modeled after ChunkSpy.lua (http://luaforge.net/projects/chunkspy/) though the code is written from scratch. A pretty listing printer for lua bytecode is in the works. I used LuaChunk in a project to generate Lua bytecode via a DSL, and then interpret it with HsLua. I hope to release the DSL itself sometime in the future. -- Anupam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: test-framework-golden-1.1
I can do that indeed, and I guess I could reimplement everything I have at the moment on top of HUnit. However, an important part of functionality isn't there at the moment — golden file management. You should be able to say, for this test, take its current output and write it to the corresponding golden file. In order to do that, you need to have access to the list of golden tests in the suite. This is where implementation details of different test frameworks start to matter. Probably one can make an abstraction over test frameworks that would give the list of all golden tests. (Although when you start abstracting over test frameworks, which are abstractions themselves, it becomes somewhat funny.) Speaking of such functionality, correct me if I'm wrong, but neither HUnit nor hspec won't be able to support it anyway, because they represent tests as opaque IO actions. Nor can HTF provide such support — although its TestSort type could be extended to indicate that the test is a golden test, still there's no way to get hold of the golden file name. test-framework will support this once the Typeable constraint is added for tests. Roman * Simon Hengel s...@typeful.net [2012-10-05 13:43:57+0200] 1. It's hard to guess at the moment how a good interface to the pure golden part should look like. Maybe just produce HUnit assertions, e.g.: goldenVsFile :: FilePath - FilePath - IO () - Assertion That way it works with plain HUnit main = runTestTT $ TestLabel someAction produce desired output $ goldenVsFile ref.txt out.txt someAction test-framework main = defaultMain [ testGroup someAction [ testCase produces some desired output $ goldenVsFile ref.txt out.txt someAction ] ] Hspec main = hspec $ do describe someAction $ do it produces some desired output $ do goldenVsFile ref.txt out.txt someAction and probably every other current or future Haskell test framework. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Panic loading network on windows (GHC 7.6.1)
Hello, I've installed Cabal and cabal-install 1.16 (which required network) on a new GHC 7.6.1 install and everything went well, except now when building a package requiring network I get: Loading package network-2.4.0.1 ... ghc.exe: Unknown PEi386 section name `.idata $4' (while processing: c:/ghc/ghc-7.6.1/mingw/lib\libws2_32.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.1 for i386-unknown-mingw32): loadArchive c:/ghc/ghc-7.6.1/mingw/lib\\libws2_32.a: failed I have done something wrong while building network on my Windows XP machine? What can I check? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Panic loading network on windows (GHC 7.6.1)
On Fri, Oct 5, 2012 at 5:31 PM, JP Moresmau jpmores...@gmail.com wrote: Hello, I've installed Cabal and cabal-install 1.16 (which required network) on a new GHC 7.6.1 install and everything went well, except now when building a package requiring network I get: Loading package network-2.4.0.1 ... ghc.exe: Unknown PEi386 section name `.idata $4' (while processing: c:/ghc/ghc-7.6.1/mingw/lib\libws2_32.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.1 for i386-unknown-mingw32): loadArchive c:/ghc/ghc-7.6.1/mingw/lib\\libws2_32.a: failed I have done something wrong while building network on my Windows XP machine? What can I check? I'm not quite sure what's going on. We did test cabal-install (and thus network) on a Windows machine before the release. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Windows - Creating FreeGLUT DLL
I'm trying OpenGL on Haskell and couldn't create the FreeGLUT DLL myself. I did follow this tutorial: http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/ But when I put my DLL on the folder of the binary, it complains about initGlut. Using the DLL pointed by FreeGLUT official site, created by other person, works fine. I don't know what I did wrong. Anyone had this problem? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Panic loading network on windows (GHC 7.6.1)
Well, cabal-install installed and works fine. Not sure why on my own package that I'm trying to port to GHC 7.6 it doesn't work... I'll try to investigate further. Thanks JP On Fri, Oct 5, 2012 at 6:02 PM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Oct 5, 2012 at 5:31 PM, JP Moresmau jpmores...@gmail.com wrote: Hello, I've installed Cabal and cabal-install 1.16 (which required network) on a new GHC 7.6.1 install and everything went well, except now when building a package requiring network I get: Loading package network-2.4.0.1 ... ghc.exe: Unknown PEi386 section name `.idata $4' (while processing: c:/ghc/ghc-7.6.1/mingw/lib\libws2_32.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.1 for i386-unknown-mingw32): loadArchive c:/ghc/ghc-7.6.1/mingw/lib\\libws2_32.a: failed I have done something wrong while building network on my Windows XP machine? What can I check? I'm not quite sure what's going on. We did test cabal-install (and thus network) on a Windows machine before the release. -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does try force evaluation of IO value
* s9gf4...@gmail.com s9gf4...@gmail.com [2012-10-05 17:19:21+0600] Prelude Control.Exception r - try (return $ error bam) :: IO (Either SomeException Int) Prelude Control.Exception r Right *** Exception: bam Wow, this is realy breaking news for me. Where can i read more about this magic ? See chapter 19 of Real World Haskell, especially section Laziness and Exception Handling. http://book.realworldhaskell.org/read/error-handling.html Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
