Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 121, Issue 8
> Hi all, > > On behalf of the cabal maintainers and contributors I'm proud to announce the > Cabal (and > cabal-install) 1.18.0 release. To install run > > cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 > > With 854 commits since the last release there are two many improvements and > bug fixes to > list them here, but two highlights are: > > * Hermetic builds using sandboxes. This should reduce the number of > "dependency hell" and > broken package DB problems. > [>>] I was quite happy to hear of the new cabal - and the chance to escape the various mazes of cabal-dependency problems. But I seem to have a bootstrapping problem, the new cabal won't install to help me get out of its messes! I tried to install what I thought were its complaints (below), and they seemed OK - any hints? The key problem seems to be: " mtl-2.1.2-5337caef659244e51e2f5fb2e944d97f is shadowed by package mtl-2.1.2-678980f6077e9f83a86186556aa2a425" Not sure how this happened, or how to remedy it. Cabal FAQ says to unregister the user database version, but that notes that it would break about 20+ other packages, but do it anyway. So yes, I did and now have a bigger mess it seems. Now mtl install gives: Building mtl-2.1.2... Preprocessing library mtl-2.1.2... Bad interface file: E:\Plang\Haskell Platform\lib\extralibs\transformers-0.3.0.0\ghc-7.4.2\Control\Monad\Trans\Error.hi mismatched interface file versions (wanted "7063", got "7042") Failed to install mtl-2.1.2 cabal: Error: some packages failed to install: mtl-2.1.2 failed during the building phase. The exception was: ExitFailure 1 I am reluctant to do a clean restart install, since it was so much trouble building some packages like wx and other graphics .dll packages. Argh... --- C:\Users\guthrie>cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install C:\Users\guthrie>cabal install cabal-install Resolving dependencies... Downloading Cabal-1.18.0... [ 1 of 70] Compiling Distribution.PackageDescription.Utils ... [70 of 70] Compiling Main ( C:\Users\guthrie\AppData\Local\Temp\Cabal-1.18.0-13108\Cabal-1.18.0\Setup.hs, C:\Users\guthrie\AppData\Local\Temp\Cabal-1.18.0-13108\Cabal-1.18.0\dist\setup\Main.o ) Linking C:\Users\guthrie\AppData\Local\Temp\Cabal-1.18.0-13108\Cabal-1.18.0\dist\setup\setup.exe ... Configuring Cabal-1.18.0... Building Cabal-1.18.0... Preprocessing library Cabal-1.18.0... [ 1 of 72] Compiling Paths_Cabal ... Distribution\Version.hs:125:1: Warning: Orphan instance: instance Data Version In-place registering Cabal-1.18.0... Installing library in C:\Users\guthrie\AppData\Roaming\cabal\i386-windows-ghc-7.6.3\Cabal-1.18.0 Registering Cabal-1.18.0... Installed Cabal-1.18.0 Downloading cabal-install-1.18.0... Configuring cabal-install-1.18.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. ... package mtl-2.1.2 requires transformers-0.3.0.0 package mtl-2.1.2 requires transformers-0.3.0.0 Building cabal-install-1.18.0... Preprocessing executable 'cabal' for cabal-install-1.18.0... : cannot satisfy -package-id mtl-2.1.2-5337caef659244e51e2f5fb2e944d97f: mtl-2.1.2-5337caef659244e51e2f5fb2e944d97f is shadowed by package mtl-2.1.2-678980f6077e9f83a86186556aa2a425 (use -v for more information) Failed to install cabal-install-1.18.0 cabal: Error: some packages failed to install: cabal-install-1.18.0 failed during the building phase. The exception was:ExitFailure 1 C:\Users\guthrie>cabal install mtl Resolving dependencies... All the requested packages are already installed: mtl-2.1.2 Use --reinstall if you want to reinstall anyway. C:\Users\guthrie>cabal install transformers Resolving dependencies... All the requested packages are already installed: transformers-0.3.0.0 Use --reinstall if you want to reinstall anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal errors...
I am trying to run ecliseFP to use with Haskell, but it gives an error: SO I tried to rebuild the buildwrapper rogram to get the update, but it fails as below. Any hints or help on what to do next? I think that from some past problems, that the"shadowed" problem is from global and usr-local library clashes, but I have never done anything fancy, I always just use "cabal install xxx" for any packages, so had hoped/assumed that it would keep everything straight. TIA. Eclipse startup error: Trying to upgrade from exlipse 4.2 to 4.3, the eclipseFP plugin gives me these errors: On startup, The version of helper executable buildwrapper at: ...\users\me\AppData\Roaming\cabal\bin\buildwrapper.exe is 0.71 but at least version version 0.7.2 is required. Choose Install to download and install from hackage, or Cancel to set it up manually in the Haskell preferences page. -- Then, it tries to do the update, and fails: Resolving dependencies... In order, the following would be installed: List-0.5.1 (new package) base64-bytestring-1.0.0.1 (new package) bktrees-0.3.1 (new package) blaze-builder-0.3.1.1 (new package) blaze-markup-0.5.1.5 (new package) blaze-html-0.5.1.3 (new package) colour-2.3.3 (new package) cpphs-1.16 (new package) data-default-class-0.0.1 (new package) data-default-instances-base-0.0.1 (new package) data-default-instances-containers-0.0.1 (new package) data-default-instances-old-locale-0.0.1 (new package) digest-0.0.1.2 (new package) dlist-0.5 (new package) data-default-instances-dlist-0.0.1 (new package) data-default-0.5.3 (new package) extensible-exceptions-0.1.1.4 (reinstall) changes: base-4.5.1.0 -> 4.6.0.1 haskell-src-exts-1.13.5 (new package) multiset-0.2.2 (new package) polyparse-1.8 (new package) regex-pcre-builtin-0.94.4.7.8.31 (new package) highlighting-kate-0.5.5 (new package) syb-0.3.7 (reinstall) changes: base-4.5.1.0 -> 4.6.0.1 hs-bibutils-5.0 (new package) json-0.7 (new package) pandoc-types-1.10 (new package) tagsoup-0.12.8 (new package) temporary-1.1.2.4 (new package) utf8-string-0.3.7 -bytestring-in-base (new package) hexpat-0.20.3 (new package) citeproc-hs-0.3.8 (new package) wl-pprint-text-1.1.0.0 (new package) graphviz-2999.16.0.0 (new package) xml-1.3.13 (new package) texmath-0.6.3 (new package) zip-archive-0.1.3.4 (new package) pandoc-1.10.1 (new package) Graphalyze-0.14.0.1 (new package) SourceGraph-0.7.0.5 (new package) cabal.exe: The following packages are likely to be broken by the reinstalls: cgi-3001.1.7.4 haskell-platform-2012.4.0.0 haskell-src-1.0.1.5 Use --force-reinstalls if you want to install anyway. C:\Users\guthrie>cabal install buildwrapper Resolving dependencies... Configuring aeson-0.6.1.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package deepseq-1.3.0.0 requires array-0.4.0.0 package text-0.11.3.1 requires array-0.4.0.1 package deepseq-1.3.0.1 requires array-0.4.0.1 package containers-0.5.0.0 requires array-0.4.0.1 package attoparsec-0.10.4.0 requires array-0.4.0.1 package vector-0.10.0.1 requires base-4.5.1.0 package transformers-0.3.0.0 requires base-4.5.1.0 package primitive-0.5.0.1 requires base-4.5.1.0 package mtl-2.1.2 requires base-4.5.1.0 package deepseq-1.3.0.0 requires base-4.5.1.0 package array-0.4.0.0 requires base-4.5.1.0 package unordered-containers-0.2.3.0 requires base-4.6.0.1 package time-1.4.0.1 requires base-4.6.0.1 package text-0.11.3.1 requires base-4.6.0.1 package template-haskell-2.8.0.0 requires base-4.6.0.1 package syb-0.4.0 requires base-4.6.0.1 package pretty-1.1.1.0 requires base-4.6.0.1 package old-locale-1.0.0.5 requires base-4.6.0.1 package hashable-1.1.2.5 requires base-4.6.0.1 package dlist-0.5 requires base-4.6.0.1 package deepseq-1.3.0.1 requires base-4.6.0.1 package containers-0.5.0.0 requires base-4.6.0.1 package bytestring-0.10.0.2 requires base-4.6.0.1 package blaze-builder-0.3.1.1 requires base-4.6.0.1 package attoparsec-0.10.4.0 requires base-4.6.0.1 package array-0.4.0.1 requires base-4.6.0.1 package aeson-0.6.1.0 requires base-4.6.0.1 package Win32-2.3.0.0 requires base-4.6.0.1 package vector-0.10.0.1 requires deepseq-1.3.0.0 package unordered-containers-0.2.3.0 requires deepseq-1.3.0.1 package time-1.4.0.1 requires deepseq-1.3.0.1 package text-0.11.3.1 requires deepseq-1.3.0.1 package containers-0.5.0.0 requires deepseq-1.3.0.1 package bytestring-0.10.0.2 requires deepseq-1.3.0.1 package attoparsec-0.10.4.0 requires deepseq-1.3.0.1 package aeson-0.6.1.0 requires deepseq-1.3.0.1 package vector-0.10.0.1 requires ghc-prim-0.2.0.0 package primitive-0.5.0.1 requires ghc-prim-0.2.0.0 package integer-gmp-0.4.0.0 requires ghc-prim-0.2.0.0 package base-4.5.1.0 requires ghc-prim-0.2.0.0 package text-0.11.3.1 requires ghc-prim-0.3.0.0 package integer-gmp-0.5.0.0 requires ghc-prim-0.3.0.0
Re: [Haskell-cafe] Control.bimap?
Yes, thanks, I've seen this; why can't cabal find the package? Is the fact that it is filed under "archive" an indicator?! I have tried Control.Bifunctor, and also Control.Categorical.Bifunctor, and Data.Bifunctor. Certainly it is an easy thing to define myself, but I'm both trying to be minimalistic, and to understand what failed. --- From: Clark Gaebel [mailto:cgae...@uwaterloo.ca] Sent: Wednesday, December 12, 2012 3:12 PM Subject: Re: [Haskell-cafe] Control.bimap? http://hackage.haskell.org/packages/archive/categories/0.59/doc/html/Control-Categorical-Bifunctor.html . And found a nicer approach: (ns,ne) = (nub***nub) unzip g Or perhaps: (ns.ne) = bimap nub nub $ unzip g -- from Control.Bifunctor The SO reference I saw described bimap as a way to map a function over a pair, and it seemed like a great match, but I cannot find the bimap function, and cabal reports no package Control.Bifunctor. ?? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Control.bimap?
I found a nice idiom for a graph algorithm where the pairs of nodes representing links could be merged into node lists by something like: ns = nub $ map fst g--head nodes ne = nub $ map snd g -- tail nodes And found a nicer approach: (ns,ne) = (nub***nub) unzip g Or perhaps: (ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor The SO reference I saw described bimap as a way to map a function over a pair, and it seemed like a great match, but I cannot find the bimap function, and cabal reports no package Control.Bifunctor. ?? --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install... Trying to recover
Thanks. I’ll try to do another cleanup, but not sure what more I can uninstall or clean out! I did a system search for *ghc* and came up empty before reinstall; will try again. I have now managed to get from some broken packages to a broken system! ☺ --- Subject: Re: [Haskell-cafe] cabal install... Trying to recover This is the important part, and what I noted immediately afterward --- did you happen to notice there was anything in the message after that first part? (Although I'm not asking this first so it also may not actually exist, I guess) One thing I notice; Ghc reports: G:\Cabal>ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.2 There is more going on than just that environment variable; this is what the "base" stuff that you have been ignoring is trying to tell you. You still have both compilers installed, and their packages are somehow jumbled together. This is breaking your installation. Unfortunately, as I am neither particularly familiar with Windows nor able to access your system (which is probably for the best for both of us), I can't really help you with figuring out why you have two GHC versions' packages mixed together. But as long as you do, cabal will be trying to upgrade the "base" package, which is the actual source of the breakage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install... Trying to recover
OK; I took HTTP out, but still get the same error; cabal: The following packages are likely to be broken by the reinstalls: QuickCheck-2.4.2 haskell-platform-2012.4.0.0 Use --force-reinstalls if you want to install anyway. One thing I notice; Ghc reports: G:\Cabal>ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.2 But I did notice that I had an environment variable (from some previous install, I think openCV?) of: GHC_VERSION=7.4.1 So I updated that to 7.4.2 And retried, same results. But then, ghc-pkg check reports: The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. HTTP-4000.2.3 haskell-platform-2012.2.0.0 I have no idea where the 2012.2 comes from. Any suggestions? --- From: Brandon Allbery [mailto:allber...@gmail.com] Subject: Re: [Haskell-cafe] cabal install... Trying to recover So I split it into sections, and tried the first one; it lists a lot of new installs, and then fails (full list at http://pastebin.com/5ywdUjgX) You're explicitly asking it for a new version of HTTP, which is asking for trouble. More worrisome is that it's still asking for new versions of base, which means it's still confused about what version of ghc is installed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install... Trying to recover
Thanks for the suggestion, I’ll do that. Here goes: I deleted the ../user/appdata/roaming/ghc and ../cabal files, an uninstalled Haskell-platform. (No trace of anything "ghc" on the disk.) Then reinstalled Haskell, and ran “cabal update”, it said there was a new cabal-install, but trying to install it fails (below), so I went ahead with the current version. The error seems odd to me (cabal-install-1.16.0.2 depends on Cabal-1.16.0.3 which failed to install.), that an older version depends on a newer one? So now I have; (from Windows - Haskell-platform 2012.4.0.0) GHCi = The Glorious Glasgow Haskell Compilation System, version 7.4.2 Cabal = cabal-install version 0.14.0, using version 1.14.0 of the Cabal library I then tried to reload all my previous packages, (all at once?!), but it fails, "out of memory" (w/8GB of memory!) So I split it into sections, and tried the first one; it lists a lot of new installs, and then fails (full list at http://pastebin.com/5ywdUjgX) The first chunk of installs gives this: ... cabal: The following packages are likely to be broken by the reinstalls: QuickCheck-2.4.2 haskell-platform-2012.4.0.0 Use --force-reinstalls if you want to install anyway. I don't understand how it can want to break the Haskell-platform, sounds dangerous! And the second this: G:\Cabal>cabal install Boolean Craft3e Craft3e GLFW GLURaw GLUT HTTP IORefCAS Me moTrie MonadCatchIO-mtl NumInstances ObjectName OpenGL OpenGLRaw QuickCheck SDL SHA StateVar Tensor abstract-deque abstract-par active aeson alex ansi-terminal array asn1-data attoparsec attoparsec-conduit base-unicode-symbols base64-bytest ring bits-atomic blaze-builder blaze-builder-conduit blaze-html blaze-markup bla ze-svg bmp buildwrapper byteorder cabal-dev case-insensitive cereal certificate clientsession cmdargs colour comonad conduit contravariant cookie cpphs cprng-ae s cpu criterion crypto-api crypto-conduit crypto-pubkey-types cryptocipher crypt ohash css-text data-default date-cache diagrams-core diagrams-lib diagrams-svg d list email-validate entropy erf failure fast-logger file-embed filepath filesyst em-conduit ghc-paths gloss gtk2hs-buildtools Resolving dependencies... In order, the following would be installed: Boolean-0.1.1 (new package) ... cabal: The following packages are likely to be broken by the reinstalls: regex-posix-0.95.1 regex-compat-0.95.1 regex-posix-0.94.4 regex-compat-0.93.1 parsec-3.1.1 fgl-5.4.2.4 fgl-5.4.2.3 QuickCheck-2.4.0.1 network-2.3.1.0 haskell-platform-2012.4.0.0 cgi-3001.1.7.4 HTTP-4000.2.5 regex-posix-0.95.2 regex-compat-0.95.1 regex-posix-0.95.1 regex-compat-0.95.1 Use --force-reinstalls if you want to install anyway. So I have a typical situation where it won't install, and gives an option to –force, but that seems to lead to more problems? Do I just have some packages which are intrinsically incompatible, and I have to choose between them? Not sure how to proceed. Any help or hints appreciated! :-) –––- > Cabal install cabal-install Configuring Cabal-1.16.0.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package process-1.1.0.1 requires base-4.5.0.0 package pretty-1.1.1.0 requires base-4.5.0.0 package old-time-1.1.0.0 requires base-4.5.0.0 package old-locale-1.0.0.4 requires base-4.5.0.0 package filepath-1.3.0.0 requires base-4.5.0.0 package directory-1.1.0.2 requires base-4.5.0.0 package deepseq-1.3.0.0 requires base-4.5.0.0 package containers-0.4.2.1 requires base-4.5.0.0 package bytestring-0.9.2.1 requires base-4.5.0.0 package array-0.4.0.0 requires base-4.5.0.0 package Win32-2.2.2.0 requires base-4.5.0.0 package filepath-1.3.0.0 requires base-4.5.1.0 package Cabal-1.16.0.3 requires base-4.5.1.0 package Cabal-1.16.0.3 requires filepath-1.3.0.0 package process-1.1.0.1 requires filepath-1.3.0.0 package directory-1.1.0.2 requires filepath-1.3.0.0 package integer-gmp-0.4.0.0 requires ghc-prim-0.2.0.0 package bytestring-0.9.2.1 requires ghc-prim-0.2.0.0 package base-4.5.0.0 requires ghc-prim-0.2.0.0 package integer-gmp-0.4.0.0 requires ghc-prim-0.2.0.0 package base-4.5.1.0 requires ghc-prim-0.2.0.0 package base-4.5.1.0 requires integer-gmp-0.4.0.0 package base-4.5.0.0 requires integer-gmp-0.4.0.0 Building Cabal-1.16.0.3... Preprocessing library Cabal-1.16.0.3... : cannot satisfy -package-id array-0.4.0.0-3cf1bc3f5cd0078adea24752c18081b9 (use -v for more information) cabal: Error: some packages failed to install: Cabal-1.16.0.3 failed during the building phase. The exception was: ExitFailure 1 cabal-install-1.16.0.2 depends on Cabal-1.16.0.3 which failed to install. (more -v details at: http://pastebin.com/Y2BuMjBP ) ---
Re: [Haskell-cafe] Cabal failures...
No; the first sentence says that someone else had reported that testing on Windows was hard to do because of (a perceived) lack of access to Windows by Haskell developers... The implication is that Haskell developers (only/mainly) use *nix. I commented that if true this lack of Windows testing could limit the availability of Haskell to the largest market share of users. --- > Subject: Re: [Haskell-cafe] Cabal failures... > To: haskell-cafe@haskell.org > On 12-11-20 08:48 AM, Gregory Guthrie wrote: > > It was also interesting to note a comment that most developers don't > > have access to a Windows machine for testing. With Windows at >90% of > > the computing market (Linux = 1.6%), this seems like a problem which > > might limit growth of Haskell usage. Just an observation. :-) > > There is a paradox in that sentence. > > The first sentence says, most developers don't have access to Windows > machines for > testing. But they have access to Linux machines. Then Windows machines must > be a scarcity > compared to Linux machines, no? So scarce, you even have difficulty borrowing > or renting. > > Then the next sentence says, the scarcity is the other way round, Linux > machines are scarce, > Windows machines are abundant. OK, so why is it so hard to access something > abundant, and > so easy to access something scarce? > -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal install...
Hmm,
Now when I tried to run Leksah, I get not only some broken packages (which I
can avoid for my current project), but:
: cannot satisfy -package-id
base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917:
base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917 is unusable due to missing or
recursive dependencies:
integer-gmp-0.4.0.0-c15e185526893c3119f809251aac8c5b
(use -v for more information)
So I tried to install base, then re-install it, but both fail;
Any hints?
---
C:\Users\guthrie>cabal install base
Resolving dependencies...
All the requested packages are already installed:
base-4.5.1.0
Use --reinstall if you want to reinstall anyway.
C:\Users\guthrie>cabal install --reinstall base
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: base (user goal)
rejecting: base-3.0.3.2 (conflict: base => base>=4.0 && <4.3)
rejecting: base-3.0.3.1 (conflict: base => base>=4.0 && <4.2)
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 (only already installed instances
can be used)
C:\Users\guthrie>ghc-pkg list base
WARNING: there are broken packages. Run 'ghc-pkg check' for more details.
e:/Plang/Haskell Platform\lib\package.conf.d:
base-4.3.1.0
base-4.5.0.0
base-4.5.1.0
The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
HTTP-4000.2.3
haskell-platform-2012.2.0.0
Can I just unregister the old Haskell platform, I now use a newer one?
Ghc-pkg list : ...
{haskell-platform-2012.2.0.0}
haskell-platform-2012.4.0.0
haskell-src-1.0.1.4
haskell-src-1.0.1.4
haskell-src-1.0.1.5
haskell-src-1.0.1.5
(haskell2010-1.0.0.0)
(haskell2010-1.1.0.1)
(haskell2010-1.1.0.1)
haskell98-1.1.0.1
(haskell98-2.0.0.1)
(haskell98-2.0.0.1)
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal failures...
Thanks to all for the comparisons between apt & cabal. Your reply basically explains why it is broken, and gives a rationale (cost and trouble to do it), but no prognosis for repair. My interest is in using Haskell for teaching, and so far the package system failures often present problems that I can't solve for all but the simplest examples, so I couldn't much pass this onto students! My libraries may have gotten corrupted, so when I get time I will try to reset and clean out everything and start over, but that will of course break a lot of things and take a lot of time for some re-installs, most particularly things depending on underlying C libraries. Any hints for a simple way to do this are welcome. I look forward to the outcomes from the current cabal discussions. It was also interesting to note a comment that most developers don't have access to a Windows machine for testing. With Windows at >90% of the computing market (Linux = 1.6%), this seems like a problem which might limit growth of Haskell usage. Just an observation. :-) Thanks for your article on the topic of Cabal - interesting! -- Date: Tue, 20 Nov 2012 01:03:20 -0500 From: "Albert Y. C. Lai" Subject: Re: [Haskell-cafe] Cabal failures... At least I paid my 3 hours to explain some cabal stuff at http://www.vex.net/~trebla/haskell/sicp.xhtml -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] code length in Haskell, a comparison
They also have other comparisons at the referenced site, including for different sizes of programs, and for counting characters or tokens instead of lines over each of these program example groups. The data source does include APL & REBOL (& 483 different languages!), so one could run this analysis with most any languages you liked. Analysis from: http://blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/ Data from: http://rosettacode.org/wiki/Rosetta_Code Re: [Haskell-cafe] code length in Haskell, a comparison > I find myself wondering where Rebol would stand in this. Or APL. Greets, Ertugrul --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal failures...
Thanks for looking at this and the help; Trying with "topdown" changes things, but as often is the case warns that it will break another ~60 packages if I force it, not sure if this will help me or cause the ruin of the rest of the local Haskell library universe. Should I force it?! :-) C:\Users\guthrie>cabal install -v --solver=topdown cabal-install Reading available packages... Resolving dependencies... In order, the following would be installed: Win32-2.2.2.0 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 array-0.4.0.0 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 deepseq-1.3.0.0 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 containers-0.4.2.1 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 old-locale-1.0.0.4 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 old-time-1.1.0.0 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 directory-1.1.0.2 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 pretty-1.1.1.0 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 process-1.1.0.1 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 Cabal-1.16.0.3 (new version) text-0.11.2.3 (reinstall) parsec-3.1.3 (reinstall) network-2.4.0.1 (new version) HTTP-4000.2.5 (reinstall) changes: network-2.3.1.0 -> 2.4.0.1 time-1.4 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 random-1.0.1.1 (reinstall) changes: base-4.5.0.0 -> 4.5.1.0 cabal-install-1.16.0.2 -bytestring-in-base (new package) cabal: The following packages are likely to be broken by the reinstalls: QuickCheck-2.4.2 haskell98-2.0.0.1 ghc-7.4.1 Cabal-1.14.0 bin-package-db-0.0.0.0 hpc-0.5.1.1 haskell-platform-2012.4.0.0 QuickCheck-2.5.1.1 haskell98-2.0.0.1 ghc-7.4.2 Cabal-1.14.0 bin-package-db-0.0.0.0 hpc-0.5.1.1 text-0.11.2.0 parsec-3.1.2 stm-2.3 regex-posix-0.95.1 regex-compat-0.95.1 regex-base-0.93.2 parallel-3.2.0.2 haskell2010-1.1.0.1 haskell-src-1.0.1.5 fgl-5.4.2.4 template-haskell-2.7.0.0 hoopl-3.8.7.3 binary-0.5.1.0 GLUT-2.1.2.1 network-2.3.1.0 cgi-3001.1.7.4 blaze-builder-0.3.1.0 stm-2.4 async-2.0.1.3 regex-posix-0.95.2 regex-compat-0.95.1 regex-base-0.93.2 parallel-3.2.0.3 haskell2010-1.1.0.1 haskell-src-1.0.1.5 fgl-5.4.2.4 vector-0.10.0.1 vector-algorithms-0.5.4.2 math-functions-0.1.1.2 template-haskell-2.7.0.0 hoopl-3.8.7.3 binary-0.5.1.0 GLUT-2.1.2.1 HUnit-1.2.5.1 Use --force-reinstalls if you want to install anyway. --- From: Johan Tibell [mailto:johan.tib...@gmail.com] Cc: haskell-cafe@haskell.org; Andres Löh Subject: Re: [Haskell-cafe] Cabal failures... I'm not quite sure what's going on. I've CCed Andres, who wrote the new constraint solver. One especially confusing part is this: C:\Users\guthrie\AppData\Local\Temp\Cabal-1.16.0.3-12392\Cabal-1.16.0.3\dist\set up\setup.exe configure --verbose=2 --ghc --prefix=C:\Users\guthrie\AppData\Roaming\cabal --user --flags=base4 --flags=base3 --constraint=process ==1.1.0.1 --constraint=pretty ==1.1.1.0 --constraint=old-time ==1.1.0.0 --constraint=filepath ==1.3.0.0 --constraint=directory ==1.1.0.2 --constraint=containers ==0.4.2.1 --constraint=base ==4.5.1.0 --constraint=array ==0.4.0.0 --disable-tests --disable-benchmarks Configuring Cabal-1.16.0.3... Flags chosen: base3=True, base4=True Dependency array ==0.4.0.0: using array-0.4.0.0 Dependency base ==4.5.1.0: using base-4.5.1.0 Dependency containers ==0.4.2.1: using containers-0.4.2.1 Dependency directory ==1.1.0.2: using directory-1.1.0.2 Dependency filepath ==1.3.0.0: using filepath-1.3.0.0 Dependency old-time ==1.1.0.0: using old-time-1.1.0.0 Dependency pretty ==1.1.1.0: using pretty-1.1.1.0 Dependency process ==1.1.0.1: using process-1.1.0.1 Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. Why is Cabal setting both base3 and base4 to True? P.S. You can try the same command with --solver=topdown and see if that works. On Mon, Nov 19, 2012 at 8:22 PM, Gregory Guthrie wrote: Johan, thanks for the note and information. My setup is: (Windows 7) cabal-install version 0.14.0 using version 1.14.0 of the Cabal library The Glorious Glasgow Haskell Compilation System, version 7.4.2 Haskell Platform 2012.4.0.0 . cabal-install-1.16.0.2 depends on Cabal-1.16.0.3 which failed to install. --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal errors
I did a package check, and I always get a ton of these things:
Warning: haddock-html: E:\Plang\Haskell
Platform\lib\extralibs\doc\haskell-src-1.0.1.4\html doesn't exist or isn't a
directory
Which I think is just missing documentation, so I ignore them.
But this time I also got this:
The following packages are broken, either because they have a problem listed
above, or because they depend on a broken package.
HTTP-4000.2.3
haskell-platform-2012.2.0.0
ghc-pkg list shows:
Cabal-1.10.1.0
Cabal-1.10.2.0
Cabal-1.14.0
Cabal-1.14.0
GLUT-2.1.2.1
GLUT-2.1.2.1
GLUT-2.1.2.1
{HTTP-4000.2.3}
HTTP-4000.2.5
...
{haskell-platform-2012.2.0.0}
haskell-platform-2012.4.0.0
haskell-src-1.0.1.4
haskell-src-1.0.1.4
haskell-src-1.0.1.5
haskell-src-1.0.1.5
(haskell2010-1.0.0.0)
(haskell2010-1.1.0.1)
(haskell2010-1.1.0.1)
haskell98-1.1.0.1
(haskell98-2.0.0.1)
(haskell98-2.0.0.1)
Not sure what it all means, but looks somewhat goofy to me.
I always just do "cabal installs", and an occasional "-force-reinstalls" when
told that it is the only option, but recently when they might fail tried a
"cabal-dev install" a few times, I assume that is what the "{}" entries are,
but am not sure if they can all peacefully coexist.
Do I need to do a reset and start over? I hope not, as it took me many hours of
fiddling to install some packages like glut, wxcore, and a few others.
Argh.
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] code length in Haskell, a comparison
There is some interesting data in the article at:
Code Length Measured in 14 Languages
http://blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/
basically comparing program lengths in various languages, and some ensuing
discussion of how this relates to language expressiveness, etc.
(He does all of his analysis in Mathematica, which is the goal of the article.)
It is interesting to see how well Haskell showed in the data; and it would also
be interesting to see how well it could replicate the analysis example which
was a nice example of web data scraping!
The data is the length of a series of programs written in a number of languages
(data from: http://rosettacode.org/wiki/Rosetta_Code).
(The columns don't map well to text only, Haskell column marked with (Why
doesn't this list support HTML?)).
See nicer version at: http://pastehtml.com/view/ciy7woohv.rtxt
The average for Haskell of 1.89 means that on the average the same program in
Haskell takes ~2x in the other languages.
Given the correlation of size to clarity, complexity, effort, and errors, this
is a good thing! :-)
Code Size relative to Mathematica
Larger numbers indicate that the language on top needs more code.
C C++ Fortran JavaCLisp Python C# JavaScript
R MATLAB Clojure Pascal Haskell RubyAverage
???
Mathematica 17.09.1 8.1 6.4 6.3 7.2 6.4
5.0 3.2 3.2 1.6 5.8 3.5 5.2 6.29
Ruby2.7 1.8 1.9 1.3 1.1 1.1 1.5
1.0 0.7 0.9 0.4 1.4 0.7 1.27
Haskell 3.6 2.7 2.5 2.0 1.6 1.7 2.2 1.5
1.1 1.5 0.7 2.1 1.4 1.89
Pascal 2.2 1.5 1.2 0.8 0.8 0.8 1.0
0.8 0.5 0.6 0.2 0.5 0.7 0.89
Clojure 8.8 5.3 5.2 3.6 3.7 3.3 3.8 2.5
1.9 2.9 5.0 1.5 2.6 3.85
MATLAB 3.6 2.4 1.8 1.1 1.4 1.1 1.7 0.9
0.8 0.3 1.6 0.7 1.1 1.42
R 4.7 3.3 2.4 1.9 1.8 1.7 2.1
1.5 1.3 0.5 2.2 0.9 1.4 1.98
JavaScript 2.8 2.1 1.9 1.2 1.2 1.1 1.6
0.7 1.1 0.4 1.3 0.7 1.0 1.31
C# 2.0 1.4 1.3 0.9 0.8 0.8
0.6 0.5 0.6 0.3 1.0 0.5 0.7 0.87
Python 2.2 1.6 1.5 1.1 0.9 1.2
0.9 0.6 0.9 0.3 1.3 0.6 0.9 1.07
Common Lisp 2.8 1.8 1.6 1.3 1.1 1.3
0.8 0.6 0.7 0.3 1.3 0.6 0.9 1.16
Java2.1 1.4 1.5 0.8 0.9 1.1
0.8 0.5 0.9 0.3 1.2 0.5 0.8 0.98
Fortran 1.4 1.0 0.7 0.6 0.7 0.8 0.5
0.4 0.6 0.2 0.8 0.4 0.5 0.66
C++ 1.4 1.0 0.7 0.6 0.6 0.7
0.5 0.3 0.4 0.2 0.7 0.4 0.6 0.61
C 0.7 0.7 0.5 0.4 0.5 0.5
0.4 0.2 0.3 0.1 0.5 0.3 0.4 0.41
Overall:4.1 2.582.3 1.681.561.611.85
1.270.851.140.411.860.831.29
Overall Ranking:
Clojure 0.41
Haskell 0.83
R0.85
MATLAB 1.14
JavaScript 1.27
Ruby 1.36
Common Lisp 1.56
Python 1.61
C++ 1.68
C# 1.85
Pascal 1.86
Fortran 2.33
C++ 2.58
C4.09
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal failures...
I follow the Cabal-messes threads with some interest, since that is the hardest area for me since starting to use Haskell. Probably 40-60% of all package install fail for some mysterious reason, with threats that trying to fix them will break more things, which generally is true. :-) I am not exert in the area, but I wonder how /why/ this is different than other package managers, like apt in Linux, I have never had any problems with it, and I would think that their dependencies are of at least similar complexities. In any case; Trying to do a cabal update" I was told to try to update "cabal-install", which I think means actually updating cabal (since I actually run installs via cabal install...), but that fails with this message below, and I don't know how to proceed. Linking C:\Users\guthrie\AppData\Local\Temp\Cabal-1.16.0.3-13880\Cabal-1.16.0.3\dist\setup\setup.exe ... Configuring Cabal-1.16.0.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package process-1.1.0.1 requires base-4.5.0.0 package pretty-1.1.1.0 requires base-4.5.0.0 package old-time-1.1.0.0 requires base-4.5.0.0 package old-locale-1.0.0.4 requires base-4.5.0.0 package filepath-1.3.0.0 requires base-4.5.0.0 package directory-1.1.0.2 requires base-4.5.0.0 package deepseq-1.3.0.0 requires base-4.5.0.0 package containers-0.4.2.1 requires base-4.5.0.0 package bytestring-0.9.2.1 requires base-4.5.0.0 package array-0.4.0.0 requires base-4.5.0.0 package Win32-2.2.2.0 requires base-4.5.0.0 package filepath-1.3.0.0 requires base-4.5.1.0 package Cabal-1.16.0.3 requires base-4.5.1.0 package Cabal-1.16.0.3 requires filepath-1.3.0.0 package process-1.1.0.1 requires filepath-1.3.0.0 package directory-1.1.0.2 requires filepath-1.3.0.0 package integer-gmp-0.4.0.0 requires ghc-prim-0.2.0.0 package bytestring-0.9.2.1 requires ghc-prim-0.2.0.0 package base-4.5.0.0 requires ghc-prim-0.2.0.0 package integer-gmp-0.4.0.0 requires ghc-prim-0.2.0.0 package base-4.5.1.0 requires ghc-prim-0.2.0.0 package base-4.5.1.0 requires integer-gmp-0.4.0.0 package base-4.5.0.0 requires integer-gmp-0.4.0.0 Building Cabal-1.16.0.3... Preprocessing library Cabal-1.16.0.3... : cannot satisfy -package-id array-0.4.0.0-3cf1bc3f5cd0078adea24752c18081b9 (use -v for more information) cabal: Error: some packages failed to install: Cabal-1.16.0.3 failed during the building phase. The exception was: ExitFailure 1 cabal-install-1.16.0.2 depends on Cabal-1.16.0.3 which failed to install. --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Book?
I've seen a book: "The Practice Of Monadic Interpretation" Dan Popa Nov. 2008 Or "Practical Monadic Interpretation" Dan Popa Which seem that they might be the same book? As reported on Haskell Wiki/books as published in 2008, but Don't find it available anywhere under either title. Any pointers or references? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 94, Issue 34
--- > Subject: Re: [Haskell-cafe] Best platform for development with GHC? > On Wed, 15 Jun 2011, Dmitri O.Kondratiev wrote: > > Since I maintain the gnuplot binding for Haskell - what are the particular > problems with that package on Windows? > > [Guthrie] I installed gnuplot using cabal on Windows, and get this: :m + Graphics.Gnuplot.Simple plotFunc [] (linearScale 1000 (-10,10)) sin Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\guthrie>ghci GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> :m + Graphics.Gnuplot.Simple Prelude Graphics.Gnuplot.Simple> plotFunc [] (linearScale 1000 (-10,10)) sin Loading package bytestring-0.9.1.10 ... linking ... done. Loading package Win32-2.2.0.1 ... linking ... done. Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package filepath-1.2.0.0 ... linking ... done. Loading package old-time-1.0.0.6 ... linking ... done. Loading package directory-1.1.0.0 ... linking ... done. Loading package process-1.0.1.5 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package monoid-transformer-0.0.2 ... linking ... done. Loading package utility-ht-0.0.7 ... linking ... done. Loading package gnuplot-0.4.2 ... linking ... done. *** Exception: gnuplot: createProcess: does not exist (No such file or directory) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
Yes, agree. Thanks. But still this adds a coupling that I did not need in the SML versions. And in this case, the analysis is word oriented, so the algorithm is intrinsically tied to a dictionary. --- Gregory Guthrie -- > -Original Message- > From: Arlen Christian Mart Cuss [mailto:cel...@sairyx.org] > Sent: Wednesday, June 08, 2011 10:50 PM > To: Gregory Guthrie > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58 > > > An option I suppose would be to read the dictionary at the top level, > > and then pass it all the way down to the analysis routine that uses > > it, but that exposes the details of how the analysis is done, and > > couples the top and bottom levels of the previously modular functions. > > It would seem to me that having the analysis routine do the I/O itself is > more coupling than > designing it to be datasource-agnostic! > > I'd expect it to be much neater to thread the data through the various > functions comprising > the analysing functions, perhaps monadically, as a part of its design; and > then to feed the > data in at a single entry point. Thus the entire analysis is pure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 93, Issue 58
An earlier note on students reactions to the imperative style forced on them by
some Haskell libraries ("do ...") is interesting, and seems similar to an
observation in a project I was developing for students; making a version of a
simple lab from previous SML assignment.
It uses a dictionary to do some statistics for a text analysis, but since the
dictionary is read at a leaf node of the analysis algorithm, that function must
be IO(), and thus the analysis using it also, ... etc. all the way up to the
top.
So the implication of the rules:
1) all IO must start from the top level, and there is only one IO
2) you cannot extract anything from an IO
Seems to be that the whole program structure becomes a series of do... blocks,
which is basically a sequential imperative looking style.
The general advice of "Strive to keep as much of the program pure as possible"
thus seems difficult.
An option I suppose would be to read the dictionary at the top level, and then
pass it all the way down to the analysis routine that uses it, but that exposes
the details of how the analysis is done, and couples the top and bottom levels
of the previously modular functions.
While this is all logical and understandable, it is quite different than how I
did this in SML; where I could encapsulate the IO in the analysis function. It
was a local secret of the analysis what data it needed, and where it came from.
Note that (of course...) if the dictionary was static and an internal data
structure, then this would all go away. It is interesting to me (and curious at
first) that one could not somehow treat a "constant" data definition file
resource in a more encapsulated manner, and not have it ripple all the way up
through the program because it was "impure" once converted to an external
definition (=IO). My first impulse was to read the dictionary in a do... and
then try to extract it and go merrily on, but that won't work - by design of
course!
Considering something like a properties file in Java, it thus seems like every
part of a program wanting to use these, must either be passed some global
definition, or become a leaf on a hierarchy of do.. blocks if it does its own
IO to read the properties.
Anyway, while the more precise treatment and isolation of IO in Haskell seems
valuable, it also seems to have a notable impact on the lack of ability to
encapsulate and decouple parts of the program, and keep things pure between
them. I suppose this is because that by definition, once you have touched IO at
any leaf of a program, the whole thing is impure all the way up the functional
tree.
I rather had the feeling expressed by Robert Harper:
" Once you're in the IO monad, you're stuck there forever, and are reduced to
Algol-style imperative programming."
(http://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads/)
Just an observation, in case I am missing something - being fairly new to
Haskell. I suppose this is just an adjustment to proper treatment of the
impurity of IO, but the effect on program structure was not good. :-)
---
> -Original Message-
> Subject: Haskell-Cafe Digest, Vol 93, Issue 58
> Now, I have a personal pedagogical comment.
>A few months ago I gave to some 30 students an
>The results? A true DISASTER!
> The OpenGL bindings in Haskell are hardly "functional".
> You make us sweat with generic functional patterns, laziness, exquisite
> typing, non-determinism monad, parsing tools, etc.,
> and then you throw us into this ugly imperativism !
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
Thanks! I’ll wait, and then try this later today. And another previous note also described a successful install, I can also try that. It seems to me that having easy install of such common libraries is a big advantage of C++/C#/.. even SML(!), and is important to wider usage of Haskell. From: Ville Tirronen [mailto:alea...@gmail.com] Sent: Tuesday, May 17, 2011 11:33 PM To: Gregory Guthrie Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows? Hi, Yes, I understand that - but if there is some install or usage dependency, or install procedure, I would hope to see it documented somewhere; perhaps I missed that? The only installation procedure I can document is how to do this in linux. My guess is that it must be similar with windows. 1. Get the opencv library from opencv.willowgarage.com<http://opencv.willowgarage.com> 2. Install it and make a note where it installs 3. cabal install CV. If this fails with missing C libraries, then, (4). cabal install CV --with-extra-lib-dirs=where_the_opencv_libs_are --with-extra-include-dirs=where_the_opencv_includes_are However, wait few hours so I can push a new version to hackage. There are few things I've already discovered that fail to work with other people and I think I can fix them. Disclaimer: The CV package is something I threw together, originally in pre-cabal times. Back then I arguably wasn't a very good haskell-programmer and the whole thing was under an nda. Since then I've casually evolved the library to suit my needs. After I saw CV-combinators library released I made a petition to publish my codes in hopes that it would help other people doing similar things. In short, although CV package is very very useful for me, it is not a perfect binding, and the implementation isn't really smart at places. I would like to make it great, however. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
Yes, I understand that - but if there is some install or usage dependency, or install procedure, I would hope to see it documented somewhere; perhaps I missed that? The end result is that from the project page and install, it fails. :-) Earlier in the thread I noted that this was a Windows (w7 enterprise) system. (I have first installed the standard Opencv distribution which should provide the cv libraries, but that did not help.) The HOpenCv package page at hackage only describes Linux installation. --- > -Original Message- > From: Antoine Latter [mailto:aslat...@gmail.com] > The error isn't referring to a Haskell package - it is saying that it cannot > find the libraries > installed on your computer. > > Note the line "Missing C libraries: cv, highgui, cv, highgui". These are not > referring to Haskell > packages - they are referring to libcv and libhighgui, whatever those are. > > What sort of computer are you using? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
Below is the install result. It does claim that "You must install OpenCV (development packages) prior to installing this package." I don't' see any Haskell /cabal opencv package, so am not sure what this means one has to do. I am not familiar enough with the Haskell install and make environment to go hacking into it, I was hoping for a simple cabal install! Thanks for the note and pointers. I am a bit surprised at the lack of graphics and Image processing libraries. I found several for Unix/Linux only, and their installs on Windows fail. I also love Linux, but windows is the 93% market share, and our student labs are all windows. I am trying to advocate using FP in more of our undergraduate level courses, and thought this might be a good area; perhaps not. Are the two packages for Hopencv the two on the hackage page? It looked to me like only one was claimed to be current and mostly complete. --- C:\Users\guthrie>cabal install hopencv Resolving dependencies... Configuring HOpenCV-0.1.2.2... Warning: 'include-dirs: /usr/include/opencv' directory does not exist. Warning: 'include-dirs: /usr/include/opencv' directory does not exist. cabal: Missing dependencies on foreign libraries: * Missing C libraries: cv, highgui, cv, highgui This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. cabal: Error: some packages failed to install: HOpenCV-0.1.2.2 failed during the configure step. The exception was: ExitFailure 1 C:\Users\guthrie>cabal install cv Resolving dependencies... Configuring unix-2.4.2.0... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: CV-0.3.0.1 depends on unix-2.4.2.0 which failed to install. JYU-Utils-0.1.1.1 depends on unix-2.4.2.0 which failed to install. unix-2.4.2.0 failed during the configure step. The exception was: ExitFailure 1 C:\Users\guthrie>cabal install highgui cabal: There is no package named 'highgui'. You may need to run 'cabal update' to get the latest list of available packages. --- > -Original Message- > From: Casey McCann [mailto:syntaxgli...@gmail.com] > Sent: Monday, May 16, 2011 1:18 PM > To: Gregory Guthrie > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Open CV or alternate image processing library for > Haskell on > windows? > > On Mon, May 16, 2011 at 8:37 AM, Gregory Guthrie wrote: > > I wanted to look into using Haskell for an introductory Image Processing > > class, but the main > package used for such things (OpenCV) does not appear to be available for > windows systems. > > > > Is there some other good option for image processing in Haskell, or has > > anyone ported > openCV to a windows Leksah environment? > > Which package are you having difficulty with? OpenCV is a library written in > C/C++ and > appears to work on Windows, and there looks to be two different packages on > Hackage > providing bindings to it, neither of which seems to have any issues with > Windows. One does > rely on the unix package, but my understanding is that Cygwin is sufficient > for that--not > certain about the details, though. I haven't used any of these packages or > OpenCV itself > personally, so there may be further issues I'm not seeing, but I would guess > that any > difficulty you've encountered was a matter of build tools and system > configuration, not the > libraries themselves. > > I have found it necessary on multiple occasions to do manual tweaks and > jury-rigging when > installing FFI bindings from Hackage on Windows, as opposed to the typically > seamless > process of installing an external library from standard repositories on > Ubuntu and then > bindings from Hackage. Admittedly this may be due in large part to the > horrendous condition > of build tools on my Windows system. I believe I have two different GHCs and > no less than > four copies of GCC in different locations and I've given up on making sense > of it since I'm > rarely on my Windows machine when coding Haskell anyway. > > Incidentally, have you looked at what functionality the bindings packages > offer? Both that I > saw on Hackage seem to advertise themselves as emphatically not > production-ready code and > probably don't expose all the features of OpenCV. Before you put a lot of > time into fix
[Haskell-cafe] Open CV or alternate image processing library for Haskell on windows?
I wanted to look into using Haskell for an introductory Image Processing class, but the main package used for such things (OpenCV) does not appear to be available for windows systems. Is there some other good option for image processing in Haskell, or has anyone ported openCV to a windows Leksah environment? --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell from SML - referrential Transparency?!
Thanks. It was the "no computation needed" difference that I was missing, and was including (falsely) in my expectations for "same result", i.e. including the same traces. ------- Dr. Gregory Guthrie Computer Science Department School of Computer Science & Mathematics Maharishi University of Management --- > -Original Message- > From: Daniel Fischer [mailto:daniel.is.fisc...@googlemail.com] > Sent: Tuesday, April 19, 2011 3:28 PM > To: Gregory Guthrie > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Haskell from SML - referrential Transparency?! > > On Tuesday 19 April 2011 21:38:18, Gregory Guthrie wrote: > > I did post the code - but don't expect anyone to really wade through > > and debug for me! :-) > > Oh, wow. Haskell looking like Lisp :( > > > (The issues that I am asking about are a9b, a9bb at line 435, 438) > > http://hpaste.org/45851/haskell_from_sml_question > > Can't reproduce, I get the same result from all invocations. > But see below > > > > > thanks for the help. > > > > > > and it does seem to show every allocation on the first run of f1, but > > then nothing on the second. SO it is not just a first call to > > allocate, but all calls under an invocation of f1 that don't show. > > Makes me wonder if f1 is even being re-evaluated. > > > > Interpreted or compiled without optimisations, the first invocation of a9b > produces debug- > output, the second not, both yield the same result, Output (IntValue 11,Halt). > The invocation of a9bb produces the same, with the debug output, like the > first invocation of > a9b. > Since a9b is a simple monomorphic value, it is evaluated only once, hence > further uses refer > simply to the result, not the computation made to achieve it. > If you compile with optimisations, a9bb doesn't produce debug output *because > it doesn't > exist*. The compiler sees that it's the same as a9b and unites them, all > references to a9bb > are rewritten to references to a9b (that's what referential transparency > gives you :). > Hence, when that value is asked for, it is already evaluated, no computation > needed, no > debug- output. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell from SML - referrential Transparency?!
Perhaps the description was unclear; F1;f1 gives result r1;r2 (not the same) F1;f2gives r1;r2 F2,f1gives r1;r2 --- > -Original Message- > From: Felipe Almeida Lessa [mailto:felipe.le...@gmail.com] > Sent: Tuesday, April 19, 2011 2:26 PM > To: Gregory Guthrie > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Haskell from SML - referrential Transparency?! > > On Tue, Apr 19, 2011 at 4:10 PM, Gregory Guthrie wrote: > > and I get different results from the two executions (f1,f2), even > > though they have exactly the same definition. Reversing their order, > > gives the exact same results (i.e. the results are still different, > > and in the same original order as f2;f1). Even doing (f1;f1) gives two > > different results. > > This shows that referential transparency is working nicely. > > -- > Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell from SML - referrential Transparency?!
Oops;
No - my (further) mistake. It is not IO() - f1 returns a data structure which
implements Show, and the test is really:
Test1 = do print "Test1:"
print f1
(etc..)
Thanks for the alert on trace.
I used it like this:
allocate :: Store -> (Store, Location)
allocate ( Store(bot,top,sto) ) |
trace("allocate "++ show bot ++ show top)
False = undefined
allocate ( Store(bot,top,sto) ) =
let newtop = top+1
and it does seem to show every allocation on the first run of f1, but then
nothing on the second.
SO it is not just a first call to allocate, but all calls under an invocation
of f1 that don't show.
Makes me wonder if f1 is even being re-evaluated.
I did post the code - but don't expect anyone to really wade through and debug
for me! :-)
(The issues that I am asking about are a9b, a9bb at line 435, 438)
http://hpaste.org/45851/haskell_from_sml_question
thanks for the help.
---
> -Original Message-
> From: Daniel Fischer [mailto:daniel.is.fisc...@googlemail.com]
> Sent: Tuesday, April 19, 2011 2:16 PM
> To: haskell-cafe@haskell.org
> Cc: Gregory Guthrie
> Subject: Re: [Haskell-cafe] Haskell from SML - referrential Transparency?!
>
> On Tuesday 19 April 2011 21:10:09, Gregory Guthrie wrote:
> > I am pretty new to Haskell, so need some clarification.
> > I am porting some code from SML, and getting a result that surprises me.
> >
> > I basically have some functions which work like this:
> > f1 = fa fb fc
> > test1 = do print "test1:"
> > f1
>
> So f1 :: IO something
>
> Being an IO-action, f1 can return different things in different invocations
> since the world in
> which it runs has changed (it might read a file which was modified between
> the first and the
> second invocation, for example).
>
> >
> > But I ran a few tests, and got odd results - so I ran the same test
> > function twice, and got different results - that was my surprise. I
> > did
> > this:
> > f1 = fa fb fc
> > f2 = fa fb fc
> > test2 = do print "test1:"
> > f1
> > f2
> >
> > and I get different results from the two executions (f1,f2), even
> > though they have exactly the same definition. Reversing their order,
> > gives the exact same results (i.e. the results are still different, and in
> > the
> > same original order as f2;f1). Even doing (f1;f1) gives two different
> > results.
>
> Depending on what f1 does, that may be perfectly normal or a serious bug.
> We'd need to see more of the code to determine which.
>
> >
> > Seems to me that by referential transparency, I should always get the
> > same result from the function(s).
> >
> > So, I added some Debug.trace to the argument functions which are used,
> > and I get a trace from the first call(s), but none from the second
> > one(s), although I do get the result from each.
>
> Did you do it in the form
>
> fa = trace ("fa") realFa
>
> ?
>
> Then the trace is only evaluated the first time fa is evaluated, even if fa
> is called later
> again.
>
> >
> > It is as if because of the laziness, it someone cached some of the
> > intermediate results, so did not re-invoke the functions.
> >
> > Anyway, totally confused. I must be missing something significant here.
> > Thanks for any clarification! (The original code is a bit long, so I
> > did not include here...)
>
> http://hpaste.org/
>
> perhaps?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell from SML - referrential Transparency?!
I am pretty new to Haskell, so need some clarification. I am porting some code from SML, and getting a result that surprises me. I basically have some functions which work like this: f1 = fa fb fc test1 = do print "test1:" f1 But I ran a few tests, and got odd results - so I ran the same test function twice, and got different results - that was my surprise. I did this: f1 = fa fb fc f2 = fa fb fc test2 = do print "test1:" f1 f2 and I get different results from the two executions (f1,f2), even though they have exactly the same definition. Reversing their order, gives the exact same results (i.e. the results are still different, and in the same original order as f2;f1). Even doing (f1;f1) gives two different results. Seems to me that by referential transparency, I should always get the same result from the function(s). So, I added some Debug.trace to the argument functions which are used, and I get a trace from the first call(s), but none from the second one(s), although I do get the result from each. It is as if because of the laziness, it someone cached some of the intermediate results, so did not re-invoke the functions. Anyway, totally confused. I must be missing something significant here. Thanks for any clarification! (The original code is a bit long, so I did not include here...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
