Re: [Haskell-cafe] Hackage haddock not running?
The last package that got haddock'ed is [1]. The first package that isn't haddock'ed is [2]. HTH, =) [1] http://hackage.haskell.org/package/acid-state-0.3 [2] http://hackage.haskell.org/package/text-json-qq-0.3.0 -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Wed, 20 Apr 2011 16:45:27 -0700, Carter Schonwald wrote: Kevin, what version of cabal install are you using? cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library I ask because prior to the 1.10.* version series, cabal would have a much harder time "correctly" choosing versions of dependencies, which at least for me often manifested as such confusions in caba regarding selecting versions. Prior to said cabal version the solution I'd often do is figure out what the "transitive " dependencies were, recompile them together, iterate that, and that would eventually make the problems go away. point being: the issue is probably conflicting versions of the same libraries are being used by different libraries that are among the dependencies, and cabal is getting confused Is it safe to upgrade cabal-install and the cabal library or are those part of the GHC package and I'll end up making things even worse? I may have corrupted libraries; I think a re-install is in order soon, but I've been avoiding that until I get to the end of my current activities. -KQ P.S. I send Rogan the output he requested below privately to avoid spamming this list. On Wed, Apr 20, 2011 at 7:34 PM, Rogan Creswick wrote: On Wed, Apr 20, 2011 at 4:18 PM, Kevin Quick wrote: > > With --verbose=3 this appears to be post-link running cabal-dev itself: > > $ cabal install cabal-dev --verbose=3 > Could you send me (or post to hpaste) the complete output of 'cabal install cabal-dev --verbose=3' ? --Rogan > ... > > *** Deleting temp files: > Deleting: > link: linkables are ... > LinkableM (Wed Apr 20 16:14:58 MST 2011) main:Main > [DotO /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/Main.o] > Linking /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup ... > *** Linker: > ...[verbose GCC output elided]... > rtend.o /nix/store/l8x3fdy1r6zf441vnqa87lzsvxrjbdz9-glibc-2.11.1/lib/crtn.o > link: done > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: /tmp/ghc13224_0 > /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup configure > --verbose=3 --ghc --prefix=/home/kquick/.cabal --user --flags=-build-tests > --flags=-no-cabal-dev --extra-include-dirs=/home/kquick/.nix-profile/include > --extra-lib-dirs=/home/kquick/.nix-profile/lib --constraint=Cabal ==1.10.1.0 > --constraint=HTTP ==4000.1.1 --constraint=base ==4.2.0.2 > --constraint=bytestring ==0.9.1.9 --constraint=directory ==1.0.1.1 > --constraint=filepath ==1.1.0.4 --constraint=mtl ==2.0.1.0 > --constraint=network ==2.3.0.2 --constraint=pretty ==1.0.1.1 > --constraint=process ==1.0.1.3 --constraint=tar ==0.3.1.0 --constraint=zlib > ==0.5.3.1 > cabal: Error: some packages failed to install: > cabal-dev-0.7.4.1 failed during the configure step. The exception was: > ExitFailure 11 > $ > > > -- > -KQ > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about the Monad instance for Iteratee (from the enumerator package)
This is a much cleaner definition of Iteratee and I'm happy to see it. When are you going to move from your FTP site to Github, by the way? :) Regards, John A. De Goes Twitter: @jdegoes LinkedIn: http://linkedin.com/in/jdegoes On Apr 21, 2011, at 12:32 AM, o...@okmij.org wrote: > > Daniel Schuessler wrote: > >> The thing I don't understand yet is the last line: Why is it OK to discard >> the >> leftover input from the (f x) Iteratee and yield just the leftover input from >> the first one (m0)? > > First of all, the question is about an older version of Iteratee. For > example, the following code > http://okmij.org/ftp/Haskell/Iteratee/Iteratee.hs > defines Iteratee a bit differently so the question does not apply. > >> data Iteratee a = IE_done a >> | IE_cont (Maybe ErrMsg) (Stream -> (Iteratee a,Stream)) >> >> instance Monad Iteratee where >> return = IE_done >> IE_done a >>= f = f a >> IE_cont e k >>= f = IE_cont e (docase . k) >>where >>docase (IE_done a, stream) = case f a of >> IE_cont Nothing k -> k stream >> i -> (i,stream) >>docase (i, s) = (i >>= f, s) > > No left-over is discarded any more. > > Your question is about the previous design, called `The second design' > described in Iteratee.hs. The corresponding comment block answers your > question, please search for ``Justification for the case IE_done x > s >>= f''. > > Please see > http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs > for the `production' case of Iteratee in a base monad. The file > IterateeM.hs talks about one more design, and its drawbacks. > > It's all about finding the optimal trade-off, I guess. > > > > ___ > 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
[Haskell-cafe] Indexed monads and MonoLocalBinds
Hi Cafe,
Here is another example of why 'let' should be sometimes generalised.
I've been recently playing with indexed monads (for JSON processing) and
found out that the following code fails to typecheck:
>{-# LANGUAGE MonoLocalBinds #-}
>data M t t' a = M
>ipure :: a -> M t t a
>ipure a = M
>iseq :: M t t' a -> M t' t'' b -> M t t'' b
>iseq a b = M
>np :: M () Bool ()
>np = M
>test = p `iseq` np `iseq` p
> where p = ipure ()
Test.hs:13:27:
Couldn't match expected type `Bool' with actual type `()'
Expected type: M Bool t''0 b0
Actual type: M () () ()
In the second argument of `iseq', namely `p'
In the expression: p `iseq` np `iseq` p
In practice that means that I need to provide a signature for almost
every monadic local binding that is used more than once, which is
unbearable, especially when monad transformers and complex indices are
used.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Thu, Apr 21, 2011 at 8:20 AM, KQ wrote: > On Wed, 20 Apr 2011 16:45:27 -0700, Carter Schonwald > wrote: > >> Kevin, >> what version of cabal install are you using? > > cabal-install version 0.8.2 > using version 1.8.0.6 of the Cabal library > Is it safe to upgrade cabal-install and the cabal library or are those part > of the GHC package and I'll end up making things even worse? It is safe to do this. You will probably need to specify the full version, since despite being included in the latest haskell platform, cabal-install-0.10.x is in the list of things that cabal won't install automatically. (in the same way that it selects versions of parsec...) $ cabal-install Cabal-1.10.1.0 then $ cabal-install cabal-install-0.10.2 should do it. (I haven't had a chance to look at the detailed output you sent yet.) --Rogan > > I may have corrupted libraries; I think a re-install is in order soon, but > I've been avoiding that until I get to the end of my current activities. > > -KQ > > P.S. I send Rogan the output he requested below privately to avoid spamming > this list. > >> >> On Wed, Apr 20, 2011 at 7:34 PM, Rogan Creswick >> wrote: >> >>> On Wed, Apr 20, 2011 at 4:18 PM, Kevin Quick wrote: >>> > >>> > With --verbose=3 this appears to be post-link running cabal-dev itself: >>> > >>> > $ cabal install cabal-dev --verbose=3 >>> > >>> >>> Could you send me (or post to hpaste) the complete output of 'cabal >>> install cabal-dev --verbose=3' ? >>> >>> --Rogan >>> >>> > ... >>> > >>> > *** Deleting temp files: >>> > Deleting: >>> > link: linkables are ... >>> > LinkableM (Wed Apr 20 16:14:58 MST 2011) main:Main >>> > [DotO >>> > /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/Main.o] >>> > Linking /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup >>> ... >>> > *** Linker: >>> > ...[verbose GCC output elided]... >>> > rtend.o >>> /nix/store/l8x3fdy1r6zf441vnqa87lzsvxrjbdz9-glibc-2.11.1/lib/crtn.o >>> > link: done >>> > *** Deleting temp files: >>> > Deleting: >>> > *** Deleting temp dirs: >>> > Deleting: /tmp/ghc13224_0 >>> > /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup >>> > configure >>> > --verbose=3 --ghc --prefix=/home/kquick/.cabal --user >>> --flags=-build-tests >>> > --flags=-no-cabal-dev >>> --extra-include-dirs=/home/kquick/.nix-profile/include >>> > --extra-lib-dirs=/home/kquick/.nix-profile/lib --constraint=Cabal >>> ==1.10.1.0 >>> > --constraint=HTTP ==4000.1.1 --constraint=base ==4.2.0.2 >>> > --constraint=bytestring ==0.9.1.9 --constraint=directory ==1.0.1.1 >>> > --constraint=filepath ==1.1.0.4 --constraint=mtl ==2.0.1.0 >>> > --constraint=network ==2.3.0.2 --constraint=pretty ==1.0.1.1 >>> > --constraint=process ==1.0.1.3 --constraint=tar ==0.3.1.0 >>> --constraint=zlib >>> > ==0.5.3.1 >>> > cabal: Error: some packages failed to install: >>> > cabal-dev-0.7.4.1 failed during the configure step. The exception was: >>> > ExitFailure 11 >>> > $ >>> > >>> > >>> > -- >>> > -KQ >>> > >>> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > > -- > -KQ > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Thu, Apr 21, 2011 at 19:25, Rogan Creswick wrote: > It is safe to do this. You will probably need to specify the full > version, since despite being included in the latest haskell platform, > cabal-install-0.10.x is in the list of things that cabal won't install > automatically. (in the same way that it selects versions of parsec...) It doesn't seem to do this anymore for parsec. The preferred-versions now look like this: base < 4 cabal-install < 0.10 network < 2.2.3 || >= 2.2.4 Or am I looking at the wrong thing? Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Thu, Apr 21, 2011 at 11:37 AM, Erik Hesselink wrote: > It doesn't seem to do this anymore for parsec. The preferred-versions > now look like this: > > base < 4 > cabal-install < 0.10 > network < 2.2.3 || >= 2.2.4 > > Or am I looking at the wrong thing? Oh, interesting. I think you're looking at the right thing. I haven't checked it since cabal-install-0.10 came out (I have the hardest time finding that url...). --Rogan > > Erik > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why not Darcs?
I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for "real" projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the "problems" with Darcs actually are? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 1:29 PM, Andrew Coppin wrote: > I'm sure this must be a VFAQ, but... There seems to be universal agreement > that Darcs is a nice idea, but is unsuitable for "real" projects. Even GHC > keeps talking about getting rid of Darcs. Can anybody tell me what the > "problems" with Darcs actually are? > It's been documented in the GHC discussions, on reddit, and elsewhere. I would encourage you to look at the darcs-users mailing list archives and the ghc archives. My personal summary is as follows: * There is religion/fan-boy-ism around git and in general vcs is subject to network effects. * Github enables a level of collaboration that is hard to get with darcs. Some people say this as: Github is the best thing about git. * Performance concerns (for example, darcs annotate needs too much time/memory). * Conflict merging issues (patch theory has flaws that lead to exponential time merges). Darcs has some additional flaws that people complain about, but which I don't think are core to the issue: * Conflict markers are hard to understand * patches as a set instead of linear history (patch soup complaints) * It's written in Haskell * It's not popular enough * People say they just don't get patch theory I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck, (Ord a)=> [a] -> Property problem
"larry.liuxinyu" writes: > Somebody told me that: > Eduard Sergeev • BTW, more recent QuickCheck (from Haskell Platform > 2011.2.0.X - contains QuickCheck-2.4.0.1) seems to identifies the > problem correctly: > > *** Failed! Falsifiable (after 3 tests and 2 shrinks): > [0,1] > False I don't think this can be true: the problem occurs in GHCi and there's no way for QuickCheck to detect it. And when I tested it I got the same problem. There must be some difference between the properties you both tested... Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
My chief complaint is that it's built on "patch theory", which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure "eat our dogfood" instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Beyond that, the feeling I get of the three major DVCS alternatives is: git: Used by Linux kernel hackers, and Rails plugin developers who think they're more important than Linux kernel hackers hg/bzr: Used by people who don't like git's UI, and flipped heads/tails when picking a DVCS (hg and bzr are basically equivalent) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: HacPhi 2011
Greetings, I am very pleased to officially announce HacPhi 2011, a Haskell hackathon/get-together to be held July 29-31 at the University of Pennsylvania in Philadelphia supported by contributions from Amgen, Jane Street, and Microsoft Research. The hackathon will officially kick off at 2:30 Friday afternoon, and go until 5pm on Sunday (with breaks for sleep, of course). Last year's HacPhi was a lot of fun, drawing an international crowd, and many people have already expressed interest in coming back this year. Come meet your Haskelly brothers-in-arms! I want to stress that everyone is welcome---you do not have to be a Haskell guru. Helping hack on someone else's project could be a great way to increase your Haskell-fu. If you plan on coming, please officially register [1]. Registration, travel, lodging and many other details can be found on the HacPhi wiki [2]. We're also looking for a few people interested in giving short (15-20 min.) talks, probably on Saturday afternoon. Anything of interest to the Haskell community is fair game---a project you've been working on, a paper, a quick tutorial. If you'd like to give a talk, add it on the wiki [3]. Hope to see you in Philadelphia! - The Hac ? team Brent Yorgey (byorgey) Daniel Wagner (dmwit) Chris Casinghino (ccasin) [1] http://haskell.org/haskellwiki/Hac_?/Register [2] http://haskell.org/haskellwiki/Hac_? [3] http://haskell.org/haskellwiki/Hac_?/Talks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 7:16 PM, John Millikin wrote: > My chief complaint is that it's built on "patch theory", which is > ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial > DAG model is much easier to understand and work with. For me its greatest asset is the patch theory. I find it much easier to understand than git's model. I don't know about hg/bzr, but I guess they have a model similar to git's. So I guess this point is up to debate. =) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Andrew Coppin wrote: > I'm sure this must be a VFAQ, but... There seems to be universal > agreement that Darcs is a nice idea, but is unsuitable for "real" > projects. I not sure what constitues a "real" project, but I have found Darcs to be more than satisfactory for Ben Lippmeier's DDC compiler project. Thats 50k lines of Haskell code with a commit history of 2500+ commits. I also do use other VCSs, in order of frequency Bzr, SVN, Git Darcs and Hg. However, my order of preference is Bzr, Darcs, Hg, Git and then SVN. The only reason I slight prefer Bzr over Darcs is that Bzr has a slightly easier and more intuitive (at least for me) user interface. However, I do find Bzr (written in Python) slightly fragile in that I ocassionally get a huge Python backtrace when something blows up Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
John Millikin wrote: > My chief complaint is that it's built on "patch theory", which is > ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial > DAG model is much easier to understand and work with. > > Possibly as a consequence of its shaky foundation, Darcs is much slower than > the competition -- this becomes noticeable for even very small repositories, > when doing a lot of branching and merging. I have two projects, one has about 50k lines of C code thats kept in Bzr and the other has 50k lines of Haskell code thats kept in Darcs. They both have similar sized commit and branch histories. I find the speed on Bzr and Darcs on those two projects to be pretty much the same. Most operations on a local repo take well less than 5 seconds. Git may be faster but if its under 5 seconds who cares. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 3:29 PM, Andrew Coppin wrote: > I'm sure this must be a VFAQ, but... There seems to be universal agreement > that Darcs is a nice idea, but is unsuitable for "real" projects. Even GHC > keeps talking about getting rid of Darcs. Can anybody tell me what the > "problems" with Darcs actually are? Yi, a fairly large and old repository, recently moved to (primarily) Git. Our motivation was not flaws in Darcs, but rather GitHub. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Um, the patch theory is what makes darcs "just work". There is no need to understand it any more than you have to know VLSI design to understand how your computer works. The end result is that darcs repositories don't get corrupted and the order you integrate patches doesn't affect things meaning cherrypicking is painless. I think the main problem with patch theory is with its PR. It is a super cool algorithm and rightly droundy should be proud of it so he highlighted it. I think this caused people to think they had to understand the patch theory rather than just sit back and enjoy it. Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John On Thu, Apr 21, 2011 at 3:16 PM, John Millikin wrote: > My chief complaint is that it's built on "patch theory", which is > ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial > DAG model is much easier to understand and work with. > > Possibly as a consequence of its shaky foundation, Darcs is much slower than > the competition -- this becomes noticeable for even very small repositories, > when doing a lot of branching and merging. > > I think it's been kept alive in the Haskell community out of pure "eat our > dogfood" instinct; IMO if having a VCS written in Haskell is important, it > would be better to just write a new implementation of an existing tool. Of > course, nobody cares that much about what language their VCS is written in, > generally. > > Beyond that, the feeling I get of the three major DVCS alternatives is: > > git: Used by Linux kernel hackers, and Rails plugin developers who think > they're more important than Linux kernel hackers > > hg/bzr: Used by people who don't like git's UI, and flipped heads/tails when > picking a DVCS (hg and bzr are basically equivalent) > > ___ > 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] Why not Darcs?
On Thu, 2011-04-21 at 16:16 -0700, John Meacham wrote: > Um, the patch theory is what makes darcs "just work". There is no need > to understand it any more than you have to know VLSI design to > understand how your computer works. The end result is that darcs > repositories don't get corrupted and the order you integrate patches > doesn't affect things meaning cherrypicking is painless. > While I appriciate the patch theory I don't think darcs fits the workflow of at least some people Assume following changes 1. Feature X - file x.hs 2. Feature Y - file y.hs and x.hs 3. Feature Z - file z.hs and x.hs 4. Fix to feature Y (changes x.hs) 5. Fix to feature X (changes x.hs) Now before pushing I would like to have 3 nice commits. In git I can rewrite history by single command: # git rebase -i origin/master and edit the file to look like pick 1 fixup 5 pick 2 fixup 4 pick 3 Manually/automatically check everything is ok. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 21:29 +0100, Andrew Coppin wrote: > I'm sure this must be a VFAQ, but... There seems to be universal > agreement that Darcs is a nice idea, but is unsuitable for "real" > projects. Even GHC keeps talking about getting rid of Darcs. Can anybody > tell me what the "problems" with Darcs actually are? I believe the biggest problem was (i.e. when migration started) that there is no big-name-hosting supporting darcs. When code.haskell.org went down people were cut off from code. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck, (Ord a)=> [a] -> Property problem
On Thu, 2011-04-21 at 23:56 +0200, Nick Smallbone wrote: > "larry.liuxinyu" writes: > > > Somebody told me that: > > Eduard Sergeev • BTW, more recent QuickCheck (from Haskell Platform > > 2011.2.0.X - contains QuickCheck-2.4.0.1) seems to identifies the > > problem correctly: > > > > *** Failed! Falsifiable (after 3 tests and 2 shrinks): > > [0,1] > > False > > I don't think this can be true: the problem occurs in GHCi and there's > no way for QuickCheck to detect it. And when I tested it I got the same > problem. There must be some difference between the properties you both > tested... > > Nick > There was an additional class contrain (Num a). Num default to Int IIRC. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 6:32 PM, Maciej Marcin Piechotka wrote: > Assume following changes > 1. Feature X - file x.hs > 2. Feature Y - file y.hs and x.hs > 3. Feature Z - file z.hs and x.hs > 4. Fix to feature Y (changes x.hs) > 5. Fix to feature X (changes x.hs) > > Now before pushing I would like to have 3 nice commits. In git I can > rewrite history by single command: > > # git rebase -i origin/master > > and edit the file to look like > > pick 1 > fixup 5 > pick 2 > fixup 4 > pick 3 > > Manually/automatically check everything is ok. % darcs unrec -a -p 'Fix to feature X' Finished unrecording. % darcs amend -a -p 'Feature X' Thu Apr 21 19:11:54 CDT 2011 Jake McArthur * Feature X Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:41 CDT 2011 Jake McArthur * Feature X % darcs unrec -a -p 'Fix to feature Y' Finished unrecording. % darcs amend -a -p 'Feature Y' Thu Apr 21 19:12:12 CDT 2011 Jake McArthur * Feature Y Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:50 CDT 2011 Jake McArthur * Feature Y - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about the Monad instance for Iteratee (from the enumerator package)
On Thu, Apr 21, 2011 at 8:36 AM, John A. De Goes wrote: > > This is a much cleaner definition of Iteratee and I'm happy to see it. > I'm confused by this comment. Isn't John Lato's implementation of Iteratee (on hackage) is based on the example implementation that Oleg pointed you towards? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 19:19 -0500, Jake McArthur wrote: > On Thu, Apr 21, 2011 at 6:32 PM, Maciej Marcin Piechotka > wrote: > > Assume following changes > > 1. Feature X - file x.hs > > 2. Feature Y - file y.hs and x.hs > > 3. Feature Z - file z.hs and x.hs > > 4. Fix to feature Y (changes x.hs) > > 5. Fix to feature X (changes x.hs) > > > > Now before pushing I would like to have 3 nice commits. In git I can > > rewrite history by single command: > > > > # git rebase -i origin/master > > > > and edit the file to look like > > > > pick 1 > > fixup 5 > > pick 2 > > fixup 4 > > pick 3 > > > > Manually/automatically check everything is ok. > > % darcs unrec -a -p 'Fix to feature X' > Finished unrecording. > % darcs amend -a -p 'Feature X' > Thu Apr 21 19:11:54 CDT 2011 Jake McArthur > * Feature X > Shall I amend this patch? [yN...], or ? for more options: y > Finished amending patch: > Thu Apr 21 19:14:41 CDT 2011 Jake McArthur > * Feature X > % darcs unrec -a -p 'Fix to feature Y' > Finished unrecording. > % darcs amend -a -p 'Feature Y' > Thu Apr 21 19:12:12 CDT 2011 Jake McArthur > * Feature Y > Shall I amend this patch? [yN...], or ? for more options: y > Finished amending patch: > Thu Apr 21 19:14:50 CDT 2011 Jake McArthur > * Feature Y > > - Jake Last time I checked it disallowed my as 5 depended on 4 which depended on 3 which depended on 2 which depended on 1 as all changed x.hs: Fri Apr 22 02:30:03 CEST 2011 Maciej Piechotka * Y feature Shall I amend this patch? [yN...], or ? for more options: n Skipping depended-upon patch: Fri Apr 22 02:29:27 CEST 2011 Maciej Piechotka * Feature X Cancelling amend since no patch was selected. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 7:31 PM, Maciej Marcin Piechotka wrote: > Last time I checked it disallowed my as 5 depended on 4 which depended > on 3 which depended on 2 which depended on 1 as all changed x.hs Merely changing the same file is not sufficient for that. In order for Darcs to say patch A depends on patch B they must change the same lines. That said, rebase has its uses. It's due in an upcoming version of Darcs, actually. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to use cabal's data-files feature and run in-place?
I'm running Haskell Platform 2011.2.0.1 on a MacOS 10.6.7 machine (the machine is 64-bit, but I'm running the 32-bit platform). I'm writing an application for personal use, and I'd like to use Cabal to package it up and handle installation. This way, when I'm working on the program, I won't break the reasonably stable installed version and can continue to use it. (I'm not committed to cabal by any means; suggestions for other ways to accomplish the same thing are more than welcome!) I've got some data files I'd like to package with the application, and Cabal's data-files field is the obvious way to do that. The immediate problem, then, is how to access the files -- I can use the generated Paths_pkg module for the "installed" copy of the app, but then I can't run the thing in-place in ghci in the development directory. I did some googling and came across a blog post (http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html) which suggested that I provide my own Paths_pkg.hs file that points to the files' location in the development copy. When I build with Cabal, the generated form of this module would override my hand-written one, and it should therefore work in the installed case as well. Unfortunately, that's not happening. Cabal is clearly generating the module; I can see it in dist/build/autogen. But my copy is overriding the autogenerated one, even for cabal builds -- at least, that's what I'm seeing when I run the binary out of dist/build//. Is there a way to be able to use data files in both contexts? FWIW, I'm running cabal as runhaskell Setup.hs configure --user runhaskell Setup.hs build Thanks much, Richard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
+1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Running a robust scalable public darcs hub is difficult. I think darcs developers are keen to help anyone working on that. FYI codehole seems access-restricted. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Codehole doesn't sound like a good name. Don't lose stuff in codehole! Sent from my iPhone On Apr 21, 2011, at 7:33 PM, Simon Michael wrote: > +1 to what you said. > > On 4/21/11 4:16 PM, John Meacham wrote: >> Incidentally, I wrote a github like site based around darcs a few >> years ago at codehole.org. It is just used internally by me for >> certain projects. but if people were interested, I could resume work >> on it and make it public. > > John, please do - darcs folks are longing for a really good hub. You're > probably aware of patch-tag and darcsden - perhaps you can exceed or reuse > those ? Both are good but have maintainers now focussed elsewhere. Running a > robust scalable public darcs hub is difficult. I think darcs developers are > keen to help anyone working on that. FYI codehole seems access-restricted. > > -Simon > > > ___ > 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] Question about the Monad instance for Iteratee (from the enumerator package)
John Lato's "iteratee" package is based on IterateeMCPS.hs[1]. I used IterateeM.hs for "enumerator", because when I benchmarked them the non-CPS version was something like 10% faster on most operations. The new IterateeM.hs solves some problems with the old encoding, but I haven't switched "enumerator" to it yet because it would break backwards compatibility. [1] http://okmij.org/ftp/Haskell/Iteratee/IterateeMCPS.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thursday, April 21, 2011 4:16:07 PM UTC-7, John Meacham wrote: > > Um, the patch theory is what makes darcs "just work". There is no need > to understand it any more than you have to know VLSI design to > understand how your computer works. The end result is that darcs > repositories don't get corrupted and the order you integrate patches > doesn't affect things meaning cherrypicking is painless. This is how it's *supposed* to work. My chief complaints with PT are: - Metadata about branches and merges gets lost. This makes later examination of the merge history impossible, or at least unfeasibly difficult. - Every commit needs --ask-deps , because the automatic dependency detector can only detect automatic changes (and not things like adding a new function in a different module) - The order patches are integrated still matters (it's impossible for it to not matter), but there's no longer any direct support for ordering them, so large merges become very manual. - If you ever merge in the wrong order, future merges will begin consuming more and more CPU time until the repository "dies". Undoing this requires using darcs-fastconvert and performing manual surgery on the export files. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck, (Ord a)=> [a] -> Property problem
On 22 April 2011 09:36, Maciej Marcin Piechotka wrote: > On Thu, 2011-04-21 at 23:56 +0200, Nick Smallbone wrote: >> "larry.liuxinyu" writes: >> >> > Somebody told me that: >> > *** Failed! Falsifiable (after 3 tests and 2 shrinks): >> > [0,1] >> > False >> >> I don't think this can be true: the problem occurs in GHCi and there's >> no way for QuickCheck to detect it. And when I tested it I got the same >> problem. There must be some difference between the properties you both >> tested... >> > There was an additional class contrain (Num a). Num default to Int IIRC. Integer I believe. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 8:42 PM, John Millikin wrote: > On Thursday, April 21, 2011 4:16:07 PM UTC-7, John Meacham wrote: >> >> Um, the patch theory is what makes darcs "just work". There is no need >> to understand it any more than you have to know VLSI design to >> understand how your computer works. The end result is that darcs >> repositories don't get corrupted and the order you integrate patches >> doesn't affect things meaning cherrypicking is painless. > > > This is how it's *supposed* to work. My chief complaints with PT are: > >- Metadata about branches and merges gets lost. This makes later >examination of the merge history impossible, or at least unfeasibly >difficult. > > That's not an issue with patch theory though. Darcs could still track that and I believe some people have been playing with the idea. > >- Every commit needs --ask-deps , because the automatic dependency >detector can only detect automatic changes (and not things like adding a > new >function in a different module) > > You mean it can only detect dependencies that depend on each other with respect to a diff of the changes. Detecting most anything else would be undecidable in the general case. As a divergent data point, I've been using darcs since 2003 and I have yet to use --ask-deps except to learn how it works. >- The order patches are integrated still matters (it's impossible for >it to not matter), but there's no longer any direct support for ordering >them, so large merges become very manual. > > Can you give an example where you need to control the order of the changes in a merge with git/bzr/svn/etc but that it was not possible with darcs? I'm trying to understand what you mean. > >- If you ever merge in the wrong order, future merges will begin >consuming more and more CPU time until the repository "dies". Undoing this >requires using darcs-fastconvert and performing manual surgery on the > export >files. > > Yes, this is true. Exponential merges still exist, although they are relatively rare with a darcs-2 formated repository. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use cabal's data-files feature and run in-place?
On Thu, Apr 21, 2011 at 8:46 PM, Richard Cobbe wrote:
> I'm running Haskell Platform 2011.2.0.1 on a MacOS 10.6.7 machine (the
> machine is 64-bit, but I'm running the 32-bit platform).
>
> I'm writing an application for personal use, and I'd like to use Cabal to
> package it up and handle installation. This way, when I'm working on the
> program, I won't break the reasonably stable installed version and can
> continue to use it.
>
> (I'm not committed to cabal by any means; suggestions for other ways to
> accomplish the same thing are more than welcome!)
>
> I've got some data files I'd like to package with the application, and
> Cabal's data-files field is the obvious way to do that. The immediate
> problem, then, is how to access the files -- I can use the generated
> Paths_pkg module for the "installed" copy of the app, but then I can't run
> the thing in-place in ghci in the development directory.
>
> I did some googling and came across a blog post
> (http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html)
> which suggested that I provide my own Paths_pkg.hs file that points to the
> files' location in the development copy. When I build with Cabal, the
> generated form of this module would override my hand-written one, and it
> should therefore work in the installed case as well.
>
> Unfortunately, that's not happening. Cabal is clearly generating the
> module; I can see it in dist/build/autogen. But my copy is overriding the
> autogenerated one, even for cabal builds -- at least, that's what I'm
> seeing when I run the binary out of dist/build//.
>
> Is there a way to be able to use data files in both contexts?
>
> FWIW, I'm running cabal as
>
> runhaskell Setup.hs configure --user
> runhaskell Setup.hs build
1. A side note - using the 'cabal' command line tool is easier for
many tasks than 'runhaskell Setup'. In particular, it does a user
install by default.
2. Here's what I do for the paths situation:
In the package description, create a CPP option so you know you're
compiling via Cabal:
> Cpp-options: -DCABAL
Then create a module to wrap around the autogenerated paths module,
making sure to put the CPP Language pragma at the top:
> {-# LANGUAGE CPP #-}
You can then use #ifdef CABAL to decide to re-export the Cabal
autogenerated paths functionality, or to use the ones you've written
yourself (based on the current directory or whatever you need).
I hope that this helps! I don't have any examples on hand at the moment.
Antoine
>
> Thanks much,
>
> Richard
>
> ___
> 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] Why not Darcs?
On 4/21/11 10:33 PM, Simon Michael wrote: +1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Agreed. I'd love to see a good code host for darcs. Actually, for my uses, the code hosting itself isn't that important ---since darcs can fabulously be hosted from any http server--- but rather, what I'd like is someplace to keep my code which also provides a good bugtracker. Unfortunately, neither darcsden nor patchtag offer bugtrackers (AFAIK) and neither github, bitbucket, nor googlecode offer darcs. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
