Apparently package archives are retained by cabal.
Try deleting ~/.cabal/packages/hackage.haskell.org/zlib-conduit-0.4.0.2.tar.gz
and try again.
Regards
Alexander Foremny
2012/7/3 Eric Macaulay :
> I tried running cabal install again, but just got the same error.
>
>
> On Mon, Jul 2, 2012 at 10:
I tried running cabal install again, but just got the same error.
On Mon, Jul 2, 2012 at 10:34 PM, Alexander Foremny <
alexanderfore...@gmail.com> wrote:
> Hello Eric,
>
> most packages fail to install because zlib-conduit fails to install.
> The reason for this -- as can be seen in the last line
Hello Eric,
most packages fail to install because zlib-conduit fails to install.
The reason for this -- as can be seen in the last line -- is that the
tar archive from which the source is extracted is corrupted. Simply
run cabal install to try again. I suspect the source archives are
re-downloaded
Hi,
another related package seems to be my ghc-heap-view package, which is a
bit lower level than vaccuum, as it does not try to build a consistent
graph image but rather be more verbose about the heap objects, in
particular about closures referenced by thunks:
http://www.joachim-breitner.de/blog/
Hello all!
I trust tried to install yesod using "cabal install yesod-platform" but the
installation aborted with the following error:
cabal: Error: some packages failed to install:
authenticate-1.2.1.1 depends on zlib-conduit-0.4.0.2 which failed to
install.
http-conduit-1.4.1.10 depends on
Hello Balazs,
thank you for the explanation. It is clear to me now and obvious from
the description. I haven't had a detailed understanding of the BMP
format and interpreted pixel rectangles as BMP files which they are
clearly not. I then thought stb-image was necessary for compressed
image format
On Mon, Jul 2, 2012 at 7:33 AM, Ivan Lazar Miljenovic
wrote:
> I'm OK with BSD for this. And I understand that copy-pasting
> boilerplate could mess things up ;-)
I think I'll change it then, thanks :)
> There is a 2999.13.* series of graphviz out, I haven't actually tested
> this but I think f
On 2 July 2012 22:17, Austin Seipp wrote:
> On Mon, Jul 2, 2012 at 6:56 AM, Ivan Lazar Miljenovic
> wrote:
>> If you've taken over maintainership, should we remove it from
>> haskell-pkg-janitors?
>
> I haven't removed it from haskell-pkg-janitors because I haven't made
> a release and the curren
On Mon, Jul 2, 2012 at 6:56 AM, Ivan Lazar Miljenovic
wrote:
> If you've taken over maintainership, should we remove it from
> haskell-pkg-janitors?
I haven't removed it from haskell-pkg-janitors because I haven't made
a release and the current package points there as the homepage and
source repo
Hi Rico,
This is certainly a possibility I have not considered. However, I
still think the Right Way Forward is to ultimately deprecate the
current package as quickly as possible and move its outstanding
functionality into GHC. Vacuum is still undeniably useful for older
GHCs, so I would be willin
On 2 July 2012 20:04, Austin Seipp wrote:
> Hi,
>
> Just a word of note: a while back, I decided to take up maintainership
> of Vacuum and some associated stuff. In the process of doing this, I
> realized that the ClosureType code in vacuum may not accurately model
> reality depending on the GHC v
=
Call for Participation
The 17th ACM SIGPLAN International Conference
on Functional Programming (ICFP 2012) and
affiliated events
http://
Hi,
Johannes Waldmann wrote:
> s2 :: Int -> Int
> s2 n = sum $ do
> x <- [ 0 .. n-1 ]
> y <- [ 0 .. n-1 ]
> return $ gcd x y
This code shows some interesting behaviour: its runtime depends heavily
on the allocation area size.
For comparison, with main = print $ s1 1000
Dear Austin,
Wouldn't it be a good idea to link the Vacuum version-number to the
related ghc version number directly as it's functionality is directly
tied to the ghc version anyway.
vacuum 7.4 for ghc 7.4; vacuum 7.2 for ghc 7.2 aso.
Best regards,
Rico Moorman
On Mon, Jul 2, 2012 at 12:04 PM,
Hi,
Just a word of note: a while back, I decided to take up maintainership
of Vacuum and some associated stuff. In the process of doing this, I
realized that the ClosureType code in vacuum may not accurately model
reality depending on the GHC version. In particular, the definition of
ClosureType i
There is also the 'isevaluated' package (which depends on vacuum, but
seems to do something more involved than your code).
Erik
On Mon, Jul 2, 2012 at 7:40 AM, Chaddaï Fouché wrote:
> On Mon, Jul 2, 2012 at 5:29 AM, Kazu Yamamoto wrote:
>> Hello,
>>
>> Are there any ways to see if a value is a
On Mon, Jul 2, 2012 at 7:54 AM, Kazu Yamamoto wrote:
> Hello,
>
>> vacuum allow that and much more though I don't know if it still works
>> correctly on GHC 7.4. Anyway your isThunk is
>>
>>> isThunk a = fmap GHC.Vacuum.ClosureType.isThunk GHC.Vacuum.closureType
>
> Great. I confirmed that this wo
17 matches
Mail list logo
