From stef204 at yandex.com Tue Oct 13 09:12:44 2015 From: stef204 at yandex.com (stef204) Date: Tue, 13 Oct 2015 03:12:44 -0600 Subject: [arch-haskell] ghc-vis Message-ID: <1705771444727564@web18m.yandex.ru> Hi, I am learning Haskell, following various tutorials, etc. Trying to install ghc-vis to help me better understand how Haskell works. "ghc-vis is a tool to visualize live Haskell data structures in GHCi." And trying to follow this guide to install it, specifically as it relates to Arch: Installation fails. I have installed haskell-gtk but am unable to find the graphviz haskell bindings haskell-graphviz. (I do have Arch's regular graphviz installed from official repos.) During 'cabal install ghc-vis --disable-library-profiling' several libraries fail with messages: failed to install glib-0.12.5.4 Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/glib-0.12.5.4.log ): Failed to install cairo-0.12.5.3 Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/cairo-0.12.5.3.log ): The log files above are empty, so no help there. I have done 'cabal install gtk2hs-buildtools' successfully but does not seem to help above errors. I am doing all of the above in a sandbox, which is probably not the best for ghc-vis but since I have no experience with cabal and didn't want to make errors and possibly pollute my system with difficult to track files, I figured I'd try to build in a sandbox, at first--which could be the cause of the problem? Or possibly I should remove the official haskell-gtk and let cabal take care of this? Would very much appreciate some feedback as to how to resolve. Thanks. PS These are the messages occurring at end of failed build: cabal: Error: some packages failed to install: cairo-0.12.5.3 failed during the configure step. The exception was: user error ('/usr/bin/ghc' exited with an error: /tmp/cabal-tmp-20619/cairo-0.12.5.3/SetupWrapper.hs:91:17: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at /tmp/cabal-tmp-20619/cairo-0.12.5.3/SetupWrapper.hs:8:1-32 or ?System.Exit.die?, imported from ?System.Exit? at /tmp/cabal-tmp-20619/cairo-0.12.5.3/SetupWrapper.hs:21:1-18 ) ghc-vis-0.6 depends on cairo-0.12.5.3 which failed to install. gio-0.12.5.3 depends on glib-0.12.5.4 which failed to install. glib-0.12.5.4 failed during the configure step. The exception was: user error ('/usr/bin/ghc' exited with an error: /tmp/cabal-tmp-20624/glib-0.12.5.4/SetupWrapper.hs:91:17: Ambiguous occurrence ?die? It could refer to either ?Distribution.Simple.Utils.die?, imported from ?Distribution.Simple.Utils? at /tmp/cabal-tmp-20624/glib-0.12.5.4/SetupWrapper.hs:8:1-32 or ?System.Exit.die?, imported from ?System.Exit? at /tmp/cabal-tmp-20624/glib-0.12.5.4/SetupWrapper.hs:21:1-18 ) gtk-0.12.5.7 depends on cairo-0.12.5.3 which failed to install. pango-0.12.5.3 depends on cairo-0.12.5.3 which failed to install. svgcairo-0.12.5.2 depends on cairo-0.12.5.3 which failed to install. xdot-0.2.4.8 depends on cairo-0.12.5.3 which failed to install. From magnus at therning.org Tue Oct 13 12:44:04 2015 From: magnus at therning.org (Magnus Therning) Date: Tue, 13 Oct 2015 14:44:04 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <1705771444727564@web18m.yandex.ru> References: <1705771444727564@web18m.yandex.ru> Message-ID: <20151013124404.GB4614@sobel.cipherstone.com> On Tue, Oct 13, 2015 at 03:12:44AM -0600, stef204 wrote: > Hi, > > I am learning Haskell, following various tutorials, etc. > > Trying to install ghc-vis to help me better understand how Haskell > works. "ghc-vis is a tool to visualize live Haskell data structures in > GHCi." > > And trying to follow this guide to install it, specifically as it > relates to Arch: > > > Installation fails. > > I have installed haskell-gtk but am unable to find the graphviz > haskell bindings haskell-graphviz. (I do have Arch's regular graphviz > installed from official repos.) The package `haskell-graphviz` is no longer in [haskell-core]. Right now I can't recall why I removed it, but most likely it was a lack of upstream updates resulting in other packages being kept back. > During 'cabal install ghc-vis --disable-library-profiling' several > libraries fail with messages: > > failed to install glib-0.12.5.4 > Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/glib-0.12.5.4.log ): > Failed to install cairo-0.12.5.3 > Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/cairo-0.12.5.3.log ): When installing `haskell-gtk` you should have gotten `haskell-glib` and `haskell-cairo` too (as well as `haskell-pango`). `cabal` ought to have picked that up. > The log files above are empty, so no help there. > > I have done 'cabal install gtk2hs-buildtools' successfully but does > not seem to help above errors. You can find `gtk2hs-buildtools` in [haskell-core]. > I am doing all of the above in a sandbox, which is probably not the > best for ghc-vis but since I have no experience with cabal and didn't > want to make errors and possibly pollute my system with difficult to > track files, I figured I'd try to build in a sandbox, at first--which > could be the cause of the problem? > > Or possibly I should remove the official haskell-gtk and let cabal > take care of this? In general I try to avoid mixing use of [haskell-core] and `cabal`. > Would very much appreciate some feedback as to how to resolve. Personally I'm so familiar with the tools we se for [haskell-core] that I often build proper Arch packages for everything :) I very rarely use `cabal` for anything. I've lately had a closer look at `stack` (available in [haskell-core] as `haskell-stack-bin`) and if ghc-vis produces one or more binaries (i.e. no libs that you are interested in) then it might be a good way to build it. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Finagle's Sixth Law: Don't believe in miracles -- rely on them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stef204 at yandex.com Tue Oct 13 13:45:52 2015 From: stef204 at yandex.com (stef204) Date: Tue, 13 Oct 2015 07:45:52 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: <20151013124404.GB4614@sobel.cipherstone.com> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> Message-ID: <1445931444743952@web26g.yandex.ru> 13.10.2015, 06:44, "Magnus Therning" : > > The package `haskell-graphviz` is no longer in [haskell-core]. Right > now I can't recall why I removed it, but most likely it was a lack of > upstream updates resulting in other packages being kept back. > >> ?During 'cabal install ghc-vis --disable-library-profiling' several >> ?libraries fail with messages: >> >> ?failed to install glib-0.12.5.4 >> ?Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/glib-0.12.5.4.log ): >> ?Failed to install cairo-0.12.5.3 >> ?Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/cairo-0.12.5.3.log ): > > When installing `haskell-gtk` you should have gotten `haskell-glib` and > `haskell-cairo` too (as well as `haskell-pango`). `cabal` ought to have > picked that up. > Yes, I did--but cabal does not seem to pick it up. I am thinking it is because I am trying to install ghc-vis in a sandbox and cabal is not seeing the other packages installed via haskell-core with pacman but if I understand you correctly, this should not the case. Correct or incorrect? >> ?The log files above are empty, so no help there. >> >> ?I have done 'cabal install gtk2hs-buildtools' successfully but does >> ?not seem to help above errors. > > You can find `gtk2hs-buildtools` in [haskell-core]. Installed it. cabal still wants to install newer versions, amongst other things: % cabal install --dry-run ghc-vis --disable-library-profiling Resolving dependencies... In order, the following would be installed (use -v for more details): colour-2.3.3 dlist-0.7.1.2 fgl-5.5.2.3 ghc-heap-view-0.5.4 polyparse-1.11 stm-2.4.4 transformers-compat-0.4.0.4 exceptions-0.8.0.2 temporary-1.2.0.3 utf8-string-0.3.8 (latest: 1.0.1.1) cairo-0.12.5.3 (latest: 0.13.1.0) glib-0.12.5.4 (latest: 0.13.2.1) gio-0.12.5.3 (latest: 0.13.1.0) pango-0.12.5.3 (latest: 0.13.1.0) gtk-0.12.5.7 (latest: 0.13.9) svgcairo-0.12.5.2 (latest: 0.13.0.3) wl-pprint-text-1.1.0.4 graphviz-2999.18.0.1 xdot-0.2.4.8 ghc-vis-0.6 (latest: 0.7.2.7) And re-trying % cabal install ghc-vis --disable-library-profiling, I get same errors re. glib and and cairo..... Are we sure it isn't because of the sandbox issue? > >> ?I am doing all of the above in a sandbox, which is probably not the >> ?best for ghc-vis but since I have no experience with cabal and didn't >> ?want to make errors and possibly pollute my system with difficult to >> ?track files, I figured I'd try to build in a sandbox, at first--which >> ?could be the cause of the problem? >> >> ?Or possibly I should remove the official haskell-gtk and let cabal >> ?take care of this? > > In general I try to avoid mixing use of [haskell-core] and `cabal`. I would like to avoid using cabal but to do that, I would need an alternative solution, e.g. find ghc-vis somewhere else, in this particular case. >> ?Would very much appreciate some feedback as to how to resolve. > > Personally I'm so familiar with the tools we se for [haskell-core] that > I often build proper Arch packages for everything :) I would love to do that as well but am so new to this whole haskell/cabal issue that not so easy to take the plunge, while trying to focus on learning the basics or haskell.... I saw some info about cblrepo which didn't sound very encouraging to someone just starting out: How would I go about building the Arch package before installing it...? > > I very rarely use `cabal` for anything. > Again, I would like to not have to use cabal and be able to integrate everything with pacman so that I can keep track of all dependencies and packages easily. > I've lately had a closer look at `stack` (available in [haskell-core] as > `haskell-stack-bin`) and if ghc-vis produces one or more binaries (i.e. > no libs that you are interested in) then it might be a good way to build > it. > Can you please explain in more detail what you mean by that exactly? How would I go about it? 1) pacman -S haskell-stack-bin 2) then? How do I find out if "ghc-vis produces one or more binaries"? The only thing I see so far is: Thanks a lot for your feedback. From barry_fishman at acm.org Tue Oct 13 18:51:24 2015 From: barry_fishman at acm.org (Barry Fishman) Date: Tue, 13 Oct 2015 14:51:24 -0400 Subject: [arch-haskell] ghc-vis References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> Message-ID: On 2015-10-13 07:45:52 -0600, stef204 wrote: > 13.10.2015, 06:44, "Magnus Therning" : >> >> The package `haskell-graphviz` is no longer in [haskell-core]. Right >> now I can't recall why I removed it, but most likely it was a lack of >> upstream updates resulting in other packages being kept back. >> >>> ?During 'cabal install ghc-vis --disable-library-profiling' several >>> ?libraries fail with messages: >>> >>> ?failed to install glib-0.12.5.4 >>> ?Build log ( >>> /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/glib-0.12.5.4.log >>> ): >>> ?Failed to install cairo-0.12.5.3 >>> ?Build log ( >>> /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/cairo-0.12.5.3.log >>> ): Arch runs the new GHC 7.10 release. When GHC went from 7.8 to 7.10 there were incompatible changes made to the base packages. ghc-vis has issues with the updated base packages, described in its bug report list (with possible workarounds): https://github.com/def-/ghc-vis/issues/7 Your builds are failing when trying to build old versions of glib and cairo (prior to their ghc 7.10 fixes). It also seem graphviz has also not yet been updated: http://hub.darcs.net/ivanm/graphviz/issue/5 -- Barry Fishman From stef204 at yandex.com Tue Oct 13 21:53:28 2015 From: stef204 at yandex.com (stef204) Date: Tue, 13 Oct 2015 15:53:28 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> Message-ID: <2671961444773208@web24g.yandex.ru> 13.10.2015, 13:55, "Barry Fishman" : > > Arch runs the new GHC 7.10 release. When GHC went from 7.8 to 7.10 > there were incompatible changes made to the base packages. ghc-vis > has issues with the updated base packages, described in its bug report > list (with possible workarounds): > > ??https://github.com/def-/ghc-vis/issues/7 > yes, saw that when digging some more and this but fails as well. > Your builds are failing when trying to build old versions > of glib and cairo (prior to their ghc 7.10 fixes). > I believe I do have the new versions but cabal wants to pull in the old version based on the deps listed by ghc-vis, I imagine. > It also seem graphviz has also not yet been updated: > > ??http://hub.darcs.net/ivanm/graphviz/issue/5 > I see that now, thanks. All of this is very frustrating for someone eager to lean Haskell and running into this. I have now looked at stack and stackage and better understand the differences and similarities and will probably try to favor stack over cabal. As well I have looked further into cblrepo and the ability to create an Arch package to install via pacman, but I guess that\s further down the line. As an alternative to ghc-vis, I looked at vacuum but running into similar problems. I was basically looking at a way both to visualize data and so stepwise evaluation in Haskell, to help me better understand the language, functions and expressions, etc. I guess I will focus on the debugger for that and see if I can find my way around. Any other suggestions, please feel free. From magnus at therning.org Thu Oct 15 10:26:06 2015 From: magnus at therning.org (Magnus Therning) Date: Thu, 15 Oct 2015 12:26:06 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <1445931444743952@web26g.yandex.ru> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> Message-ID: <20151015102606.GA13923@sobel.cipherstone.com> On Tue, Oct 13, 2015 at 07:45:52AM -0600, stef204 wrote: > > > 13.10.2015, 06:44, "Magnus Therning" : > > > > The package `haskell-graphviz` is no longer in [haskell-core]. Right > > now I can't recall why I removed it, but most likely it was a lack of > > upstream updates resulting in other packages being kept back. > > > >> ?During 'cabal install ghc-vis --disable-library-profiling' several > >> ?libraries fail with messages: > >> > >> ?failed to install glib-0.12.5.4 > >> ?Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/glib-0.12.5.4.log ): > >> ?Failed to install cairo-0.12.5.3 > >> ?Build log ( /home/($user)/Documents/hs/hswork/projects/101/.cabal-sandbox/logs/cairo-0.12.5.3.log ): > > > > When installing `haskell-gtk` you should have gotten `haskell-glib` and > > `haskell-cairo` too (as well as `haskell-pango`). `cabal` ought to have > > picked that up. > > > > Yes, I did--but cabal does not seem to pick it up. I am thinking it is > because I am trying to install ghc-vis in a sandbox and cabal is not > seeing the other packages installed via haskell-core with pacman but > if I understand you correctly, this should not the case. Correct or > incorrect? The little experience I have with cabal sandboxes suggest that it should pick them up -- as long as they have acceptable versions! > > Personally I'm so familiar with the tools we se for [haskell-core] that > > I often build proper Arch packages for everything :) > > I would love to do that as well but am so new to this whole > haskell/cabal issue that not so easy to take the plunge, while trying > to focus on learning the basics or haskell.... > > I saw some info about cblrepo which didn't sound very encouraging to > someone just starting out: > That post completely misses the fact that there already is a base DB to use: . I you clone that you'll only need to add the packages beyond what's already in [haskell-core]. > How would I go about building the Arch package before installing > it...? 1. clone 2. install `cblrepo` from [haskell-core] 3. run `cblrepo sync` 4. move into the `habs` repo and run `cblrepo add ...` to add packages (one or many at once) 5. run `cblrepo pkgbuild ` to generate source packages for the packages you added 6. build all packages, in order (you can use `cblrepo build` to generate a good build order) 7. install your new packages > > I've lately had a closer look at `stack` (available in > > [haskell-core] as `haskell-stack-bin`) and if ghc-vis produces one > > or more binaries (i.e. no libs that you are interested in) then it > > might be a good way to build it. > > > > Can you please explain in more detail what you mean by that exactly? > How would I go about it? > 1) pacman -S haskell-stack-bin > 2) then? How do I find out if "ghc-vis produces one or more binaries"? I'd start with `stack unpack ghc-vis`, then `stack init --resolver ghc-7.8` and see where that leads. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus I would rather use Java than Perl. And I'd rather be eaten by a crocodile than use Java. -- Trouser -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stef204 at yandex.com Thu Oct 15 17:23:58 2015 From: stef204 at yandex.com (stef204) Date: Thu, 15 Oct 2015 11:23:58 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: <20151015102606.GA13923@sobel.cipherstone.com> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> Message-ID: <2145221444929838@web26m.yandex.ru> 15.10.2015, 04:26, "Magnus Therning" : >> ?How would I go about building the Arch package before installing >> ?it...? > > 1. clone > 2. install `cblrepo` from [haskell-core] > 3. run `cblrepo sync` > 4. move into the `habs` repo and run `cblrepo add ...` to add > ???packages (one or many at once) > 5. run `cblrepo pkgbuild ` to generate source packages for the > ???packages you added > 6. build all packages, in order (you can use `cblrepo build` to generate > ???a good build order) > 7. install your new packages > >> ?> I've lately had a closer look at `stack` (available in >> ?> [haskell-core] as `haskell-stack-bin`) and if ghc-vis produces one >> ?> or more binaries (i.e. no libs that you are interested in) then it >> ?> might be a good way to build it. >> ?> >> >> ?Can you please explain in more detail what you mean by that exactly? >> ?How would I go about it? >> ?1) pacman -S haskell-stack-bin >> ?2) then? How do I find out if "ghc-vis produces one or more binaries"? > > I'd start with `stack unpack ghc-vis`, then `stack init --resolver > ghc-7.8` and see where that leads. > Thanks Magnus, much appreciated. I have installed cblrepo, have read and will run through the above steps, Hope you don't mind if I follow-up on this thread if I run into problems I cannot solve with cblrepo. Thanks again. From magnus at therning.org Thu Oct 15 19:23:11 2015 From: magnus at therning.org (Magnus Therning) Date: Thu, 15 Oct 2015 21:23:11 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <2145221444929838@web26m.yandex.ru> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <2145221444929838@web26m.yandex.ru> Message-ID: <20151015192311.GA2500@tatooine> On Thu, Oct 15, 2015 at 11:23:58AM -0600, stef204 wrote: > > > 15.10.2015, 04:26, "Magnus Therning" : > > >> ?How would I go about building the Arch package before installing > >> ?it...? > > > > 1. clone > > 2. install `cblrepo` from [haskell-core] > > 3. run `cblrepo sync` > > 4. move into the `habs` repo and run `cblrepo add ...` to add > > ???packages (one or many at once) > > 5. run `cblrepo pkgbuild ` to generate source packages for the > > ???packages you added > > 6. build all packages, in order (you can use `cblrepo build` to generate > > ???a good build order) > > 7. install your new packages > > > >> ?> I've lately had a closer look at `stack` (available in > >> ?> [haskell-core] as `haskell-stack-bin`) and if ghc-vis produces one > >> ?> or more binaries (i.e. no libs that you are interested in) then it > >> ?> might be a good way to build it. > >> ?> > >> > >> ?Can you please explain in more detail what you mean by that exactly? > >> ?How would I go about it? > >> ?1) pacman -S haskell-stack-bin > >> ?2) then? How do I find out if "ghc-vis produces one or more binaries"? > > > > I'd start with `stack unpack ghc-vis`, then `stack init --resolver > > ghc-7.8` and see where that leads. > > > > Thanks Magnus, much appreciated. > I have installed cblrepo, have read > and will run through the above > steps, > Hope you don't mind if I follow-up on this thread if I run into > problems I cannot solve with cblrepo. That's fine, of course. I'm not sure if I got it right though, but does ghc-vis require ghc 7.8? In that case you'll only have limited success with cblrepo I'm afraid. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stef204 at yandex.com Thu Oct 15 20:14:29 2015 From: stef204 at yandex.com (stef204) Date: Thu, 15 Oct 2015 14:14:29 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: <20151015102606.GA13923@sobel.cipherstone.com> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> Message-ID: <160841444940069@web14g.yandex.ru> 15.10.2015, 04:26, "Magnus Therning" : Magnus, Comment: while I haven't yet had success with it in installing the packages targeted (hopefully this will happen after this post), cblrepo looks like great work. Back to issue at hand, inline below. > > 1. clone > 2. install `cblrepo` from [haskell-core] > 3. run `cblrepo sync` > 4. move into the `habs` repo and run `cblrepo add ...` to add > ???packages (one or many at once) > 5. run `cblrepo pkgbuild ` to generate source packages for the > ???packages you added > 6. build all packages, in order (you can use `cblrepo build` to generate > ???a good build order) > 7. install your new packages > In addition to Barry's earlier comments re. ghc-vis and graphviz, the fact that ghc-vis seems to require ghc 7.8.3 and the following, I had to switch to a different package than ghc-vis since I am getting the following while trying to add ghc-vis' dependencies: % cat error.log Failed to satisfy the following dependencies for base: ghc-prim >=0.3.1 && <0.4 integer-simple >=0.1.1 && <0.2 Adding base 4.7.0.2 would break: QuickCheck : base >=4.8 && <5 cblrepo : base ==4.8.* xmonad-contrib : base >=4.8 && <5 I don't know how to deal with using a different base, I guess sandbox might be the right way, not sure. So, at least for now, I switched to vacuum-opengl as an alternative to ghc-vis: For vacuum-opengl, done steps 1 through 5 above, stuck on step 6. Here is the PKGBUILD generated: Question 1) When I added the dependencies to cblrebo.db, I used the *exact* version as specified for the package on hackage, so I used: cblrepo add package_name,exact version -> all the digits, so versions generated for PKGBUILD look a bit weird (to me) like "haskell-glut=2.7.0.2_0-4. Is this correct? (The "release" is just called "04"?) Question 2) dependencies depends=("ghc=7.10.2-1" "haskell-glut=2.7.0.2_0-4" "haskell-opengl=2.13.0.0_0-4" "haskell-bitmap=0.0.2_0-1" "haskell-bitmap-opengl=0.0.1.5_0-1" "haskell-network=2.6.2.1_0-3" "haskell-stb-image=0.2.1_0-1" "haskell-vacuum=2.2.0.0_0-1") So, besides ghc-7.10.2-1, already installed obviously, haskell-glut and haskell-opengl both of which I found in the haskell-core repo, it seems I need to go through the same 1-7 steps for each missing individual packages haskell-{bitmap, bitmap-opengl, network, stb-image, vacuum} one at a time, correct? > I'd start with `stack unpack ghc-vis`, then `stack init --resolver > ghc-7.8` and see where that leads. > here, I get a failure error message on stack build after having run stack setup. ghc.mk:901: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 127 Makefile:24: recipe for target 'install' failed make: *** [install] Error 2 From magnus at therning.org Thu Oct 15 22:04:48 2015 From: magnus at therning.org (Magnus Therning) Date: Fri, 16 Oct 2015 00:04:48 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <160841444940069@web14g.yandex.ru> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <160841444940069@web14g.yandex.ru> Message-ID: <20151015220447.GA28592@tatooine> On Thu, Oct 15, 2015 at 02:14:29PM -0600, stef204 wrote: > > 15.10.2015, 04:26, "Magnus Therning" : > Magnus, > > Comment: while I haven't yet had success with it in installing the > packages targeted (hopefully this will happen after this post), > cblrepo looks like great work. > > Back to issue at hand, inline below. > > > 1. clone > > 2. install `cblrepo` from [haskell-core] > > 3. run `cblrepo sync` > > 4. move into the `habs` repo and run `cblrepo add ...` to add > > ???packages (one or many at once) > > 5. run `cblrepo pkgbuild ` to generate source packages for the > > ???packages you added > > 6. build all packages, in order (you can use `cblrepo build` to generate > > ???a good build order) > > 7. install your new packages > > In addition to Barry's earlier comments re. ghc-vis and graphviz, the > fact that ghc-vis seems to require ghc 7.8.3 and the following, I had > to switch to a different package than ghc-vis since I am getting the > following while trying to add ghc-vis' dependencies: > % cat error.log > Failed to satisfy the following dependencies for base: > ghc-prim >=0.3.1 && <0.4 > integer-simple >=0.1.1 && <0.2 > Adding base 4.7.0.2 would break: > QuickCheck : base >=4.8 && <5 > cblrepo : base ==4.8.* > xmonad-contrib : base >=4.8 && <5 > > I don't know how to deal with using a different base, I guess sandbox > might be the right way, not sure. Yes, the fact that it requires 7.8 is a deal-breaker for building on top of `[haskell-core]`, unfortunately. > So, at least for now, I switched to vacuum-opengl as an alternative to ghc-vis: > > For vacuum-opengl, done steps 1 through 5 above, stuck on step 6. > > Here is the PKGBUILD generated: > > > Question 1) When I added the dependencies to cblrebo.db, I used the > *exact* version as specified for the package on hackage, so I used: > cblrepo add package_name,exact version -> all the digits, so versions > generated for PKGBUILD look a bit weird (to me) like > "haskell-glut=2.7.0.2_0-4. Is this correct? (The "release" is just > called "04"?) > > Question 2) dependencies > > depends=("ghc=7.10.2-1" > "haskell-glut=2.7.0.2_0-4" > "haskell-opengl=2.13.0.0_0-4" > "haskell-bitmap=0.0.2_0-1" > "haskell-bitmap-opengl=0.0.1.5_0-1" > "haskell-network=2.6.2.1_0-3" > "haskell-stb-image=0.2.1_0-1" > "haskell-vacuum=2.2.0.0_0-1") > > So, besides ghc-7.10.2-1, already installed obviously, haskell-glut > and haskell-opengl both of which I found in the haskell-core repo, it > seems I need to go through the same 1-7 steps for each missing > individual packages haskell-{bitmap, bitmap-opengl, network, > stb-image, vacuum} one at a time, correct? First, I thought I'd pushed up a version of `cblrepo` that generated files with a dependency on "7.10.2-2" (the one from `[haskell-core]`), but apparently I didn't get around to it yet. Until I do please use `--ghc-release 2` to generate the proper dependency on ghc. You only need to go through the steps above for the packages you need to add. > > I'd start with `stack unpack ghc-vis`, then `stack init --resolver > > ghc-7.8` and see where that leads. > > here, I get a failure error message on stack build after having run stack setup. > > ghc.mk:901: recipe for target 'install_packages' failed > make[1]: *** [install_packages] Error 127 > Makefile:24: recipe for target 'install' failed > make: *** [install] Error 2 I just did that exercise now and it seems to have worked fine. These are the steps I took % stack unpack ghc-vis % cd ghc-vis-0.7.2.7 % stack init --resolver ghc-7.8 % echo 'system-ghc: false' >> stack.yaml % stack solver --modify-stack-yaml % sudo pacman -S ghtk2hs-buildtools % stack --install-ghc build (Yes, it seems to be all right to use the gtk2hs-buildtools from `[haskell-core]`.) My guess though is that ghc-vis won't actually be usable in anything but ghci from ghc-7.8.4, which I suppose means it's of rather limited value. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. -- J.R.R Tolkien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stef204 at yandex.com Fri Oct 16 09:07:18 2015 From: stef204 at yandex.com (stef204) Date: Fri, 16 Oct 2015 03:07:18 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: <20151015220447.GA28592@tatooine> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <160841444940069@web14g.yandex.ru> <20151015220447.GA28592@tatooine> Message-ID: <2724711444986438@web6j.yandex.ru> 15.10.2015, 16:04, "Magnus Therning" : Thanks for your feedback. >> ?So, besides ghc-7.10.2-1, already installed obviously, haskell-glut >> ?and haskell-opengl both of which I found in the haskell-core repo, it >> ?seems I need to go through the same 1-7 steps for each missing >> ?individual packages haskell-{bitmap, bitmap-opengl, network, >> ?stb-image, vacuum} one at a time, correct? > > First, I thought I'd pushed up a version of `cblrepo` that generated > files with a dependency on "7.10.2-2" (the one from `[haskell-core]`), > but apparently I didn't get around to it yet. Until I do please use > `--ghc-release 2` to generate the proper dependency on ghc. > Yes, I had to edit the PKGBUILD's manually to change to ghc-7-10.2-2 but I see that in such cases I can use the --ghc-release x. (In any case, I have reversed everything and will start building with cblrepo again today, from scratch, so should be fine.) > You only need to go through the steps above for the packages you need to > add. > Right so that can mean the targeted package + any of its dependencies not found in habs, (making sure I have first done a "cblrepo udpate") correct? Yesterday, when I tried to build vacuum-opengl with the PKGBUILD generated by cblrepo, it failed based on dependencies. I either did something wrong with the step "cblrepo build" which I believe I ran without arguments (but didn't get an error message on) when perhaps I should have used "cblrepo build vacuum-opengl"? (I noticed that after updating cblrepo later on, it started to give me the error message on the "cblrepo build" without arguments.) So to try to resolve the pacman failure on vacuum-opengl, I had to repeat the cblrepo steps 1-7 you had described for ALL of the chain, except for 1 or 2 packages which were already in haskell-core. Which I believe is normal? Comparing this to using "configure" and "make", one does get into these chains at times, when missing dependencies. This brings me to the following: * Doesn't using cblrepo as above (well, the proper way, without mistakes) create an out-of-sync state with haskell-core where at some point, we will have different versions/releases of same packages and pacman -Syu will fail? This happened to me yesterday (after you updated habs.) Which would mean I'd have to "ignore" those packages in pacman.conf.... Probably more true with packages not included in habs, but that I add locally, and at some point later, you include them in habs and we're out of sync. * I see that installing haskell packages, generally. pulls in a LOT of dependencies, which, installed via cblrepo + pacman, are installed "globally" on my box (as opposed to confined to a sandbox.) Even if being able to track everything through pacman (which is just great), am I not better off installing these in sandboxes or at least via stack in my home dir where, if something really goes wrong , as a last resort I can rm -rf ~/.stack/* (or something similar)? I am literally spreading haskell deps all over my system otherwise...which I have to question. It could be because I am just getting started and am missing the most basic dependencies so this will taper off soon. Or perhaps not and it will continue to spread _lots_ of deps globally, I don't know yet. Lastly, on the subject of visualizing data/expressions/stepwise evaluation, I tried to install Hoed, with cblrepo + pacman. Here's what happens: % cblrepo add Hoed,0.3.0 Failed to satisfy the following dependencies for Hoed: RBTree ==0.0.5 libgraph ==1.5 threepenny-gui ==0.6.* % cblrepo add RBTree,0.0.5 % cblrepo add libgraph,1.5 Failed to satisfy the following dependencies for libgraph: union-find -any % cblrepo add union-find,0.2 % cblrepo add libgraph,1.5 % cblrepo add Hoed,0.3.0 Failed to satisfy the following dependencies for Hoed: threepenny-gui ==0.6.* % cblrepo add threepenny-gui,0.6.0.3 Failed to satisfy the following dependencies for threepenny-gui: aeson >=0.7 && <0.9 snap-core ==0.9.* snap-server ==0.9.* websockets >=0.8 && <0.10 websockets-snap >=0.8 && <0.10 % cblrepo add aeson,0.8.1.1 Adding aeson 0.8.1.1 would break: cblrepo : aeson ==0.9.* How do I get out of the above, if at all possible? I am able to build Hoed using stack, though, but sticking to the cblrepo / Arch approach to use pacman, would need to resolve the above. >> ?> I'd start with `stack unpack ghc-vis`, then `stack init --resolver >> ?> ghc-7.8` and see where that leads. >> > > I just did that exercise now and it seems to have worked fine. These > are the steps I took > > ????% stack unpack ghc-vis > ????% cd ghc-vis-0.7.2.7 > ????% stack init --resolver ghc-7.8 > ????% echo 'system-ghc: false' >> stack.yaml > ????% stack solver --modify-stack-yaml > ????% sudo pacman -S ghtk2hs-buildtools > ????% stack --install-ghc build > > (Yes, it seems to be all right to use the gtk2hs-buildtools from > `[haskell-core]`.) OK, thanks a lot, will do this today. I was missing the 'stack init --resolver ghc-7.8' [I had done 'stack init --solver' instead and was also missing the 'echo 'system-ghc: false' >> stack.yaml' . > > My guess though is that ghc-vis won't actually be usable in anything but > ghci from ghc-7.8.4, which I suppose means it's of rather limited value. > That would be fine as I my objective is to use it to help me better understand how haskell evaluates expressions and do, in as far as is possible or meaningful, stepwise evaulation, seeing the different steps and values would help learn, I believe. It should probably be OK for very simple code which I use to learn, etc. From magnus at therning.org Fri Oct 16 11:38:25 2015 From: magnus at therning.org (Magnus Therning) Date: Fri, 16 Oct 2015 13:38:25 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <2724711444986438@web6j.yandex.ru> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <160841444940069@web14g.yandex.ru> <20151015220447.GA28592@tatooine> <2724711444986438@web6j.yandex.ru> Message-ID: <20151016113825.GD7251@sobel.cipherstone.com> On Fri, Oct 16, 2015 at 03:07:18AM -0600, stef204 wrote: > > > 15.10.2015, 16:04, "Magnus Therning" : > > Thanks for your feedback. > > >> ?So, besides ghc-7.10.2-1, already installed obviously, haskell-glut > >> ?and haskell-opengl both of which I found in the haskell-core repo, it > >> ?seems I need to go through the same 1-7 steps for each missing > >> ?individual packages haskell-{bitmap, bitmap-opengl, network, > >> ?stb-image, vacuum} one at a time, correct? > > > > First, I thought I'd pushed up a version of `cblrepo` that generated > > files with a dependency on "7.10.2-2" (the one from `[haskell-core]`), > > but apparently I didn't get around to it yet. Until I do please use > > `--ghc-release 2` to generate the proper dependency on ghc. > > > > Yes, I had to edit the PKGBUILD's manually to change to ghc-7-10.2-2 > but I see that in such cases I can use the --ghc-release x. I've just pushed up a new version to Hackage with that change included. It'll get to `[haskell-core]` soon-ish. > > You only need to go through the steps above for the packages you > > need to add. > > Right so that can mean the targeted package + any of its dependencies > not found in habs, (making sure I have first done a "cblrepo udpate") > correct? Indeed. > Yesterday, when I tried to build vacuum-opengl with the PKGBUILD > generated by cblrepo, it failed based on dependencies. > I either did something wrong with the step "cblrepo build" which I > believe I ran without arguments (but didn't get an error message on) > when perhaps I should have used "cblrepo build vacuum-opengl"? (I > noticed that after updating cblrepo later on, it started to give me > the error message on the "cblrepo build" without arguments.) Maybe `build` is badly named, it doesn't *perform* a build, it only outputs an order for a successful build. > So to try to resolve the pacman failure on vacuum-opengl, I had to > repeat the cblrepo steps 1-7 you had described for ALL of the chain, > except for 1 or 2 packages which were already in haskell-core. > Which I believe is normal? > > Comparing this to using "configure" and "make", one does get into > these chains at times, when missing dependencies. I usually operate on *all added packages* at once through the whole upgrade/add process. > This brings me to the following: > > * Doesn't using cblrepo as above (well, the proper way, without > mistakes) create an out-of-sync state with haskell-core where at some > point, we will have different versions/releases of same packages and > pacman -Syu will fail? This happened to me yesterday (after you > updated habs.) Which would mean I'd have to "ignore" those packages in > pacman.conf.... > > Probably more true with packages not included in habs, but that I add > locally, and at some point later, you include them in habs and we're > out of sync. That is completely correct. `pacman -Su` won't let you take your system into an inconsistent state though. > * I see that installing haskell packages, generally. pulls in a LOT of > dependencies, which, installed via cblrepo + pacman, are installed > "globally" on my box (as opposed to confined to a sandbox.) Even if > being able to track everything through pacman (which is just great), > am I not better off installing these in sandboxes or at least via > stack in my home dir where, if something really goes wrong , as a last > resort I can rm -rf ~/.stack/* (or something similar)? > > I am literally spreading haskell deps all over my system > otherwise...which I have to question. > It could be because I am just getting started and am missing the most > basic dependencies so this will taper off soon. Or perhaps not and it > will continue to spread _lots_ of deps globally, I don't know yet. You are correct. The massive list of dependencies is largely due to the tendency in the Haskell community to use small targeted libraries. We've then, due to historic reasons and the good fit with Arch in general, decided to not use split packages. I'm currently experimenting with a split package for stack though. Also, I've found that pacman is *really* good with handling packages, so having lots of them isn't a big issue. Also, if you want to clean out your system you can use `pacman -Rncs ghc` to do it (you'll be left with exe-only packages, like cblrepo, though). You have to make up your own mind on the issue of system-wide vs. sandboxes. :-) Do note though that if you do go to a only-using-stack you can conceptually get away with having nothing but the stack executable installed (system-wide or locally). Yes that's all you really need. However, stack can't handle packages that require data files yet (ghc-mod, pandoc, ...). > Lastly, on the subject of visualizing data/expressions/stepwise > evaluation, I tried to install Hoed, with cblrepo + pacman. > > Here's what happens: > > % cblrepo add Hoed,0.3.0 > Failed to satisfy the following dependencies for Hoed: > RBTree ==0.0.5 > libgraph ==1.5 > threepenny-gui ==0.6.* > > % cblrepo add RBTree,0.0.5 > % cblrepo add libgraph,1.5 > Failed to satisfy the following dependencies for libgraph: > union-find -any > % cblrepo add union-find,0.2 > % cblrepo add libgraph,1.5 > % cblrepo add Hoed,0.3.0 > Failed to satisfy the following dependencies for Hoed: > threepenny-gui ==0.6.* > % cblrepo add threepenny-gui,0.6.0.3 > Failed to satisfy the following dependencies for threepenny-gui: > aeson >=0.7 && <0.9 > snap-core ==0.9.* > snap-server ==0.9.* > websockets >=0.8 && <0.10 > websockets-snap >=0.8 && <0.10 > % cblrepo add aeson,0.8.1.1 > Adding aeson 0.8.1.1 would break: > cblrepo : aeson ==0.9.* > > How do I get out of the above, if at all possible? This is due to upstream depending on an old version of `aeson`. You can patch the `.cabal` file (have a look in habs `patches` dir). In surprisingly many cases you can just bump the upper limit without any code changes. In a few cases you'll have to do the work of the upstream devs and modify the code too. If that's the case have a look in their VCS, I've often found exactly the patch needed already checked in but not release, or as an attachment to a ticket. > > My guess though is that ghc-vis won't actually be usable in anything > > but ghci from ghc-7.8.4, which I suppose means it's of rather > > limited value. > > That would be fine as I my objective is to use it to help me better > understand how haskell evaluates expressions and do, in as far as is > possible or meaningful, stepwise evaulation, seeing the different > steps and values would help learn, I believe. It should probably be OK > for very simple code which I use to learn, etc. Just note that `stack runghci` is marked as "experimental". /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Finagle's Fourth Law: Once a job is fouled up, anything done to improve it only makes it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From stef204 at yandex.com Fri Oct 16 14:13:56 2015 From: stef204 at yandex.com (stef204) Date: Fri, 16 Oct 2015 08:13:56 -0600 Subject: [arch-haskell] ghc-vis In-Reply-To: <20151016113825.GD7251@sobel.cipherstone.com> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <160841444940069@web14g.yandex.ru> <20151015220447.GA28592@tatooine> <2724711444986438@web6j.yandex.ru> <20151016113825.GD7251@sobel.cipherstone.com> Message-ID: <2796671445004836@web3m.yandex.ru> 16.10.2015, 05:38, "Magnus Therning" : > > I've just pushed up a new version to Hackage with that change included. > It'll get to `[haskell-core]` soon-ish. > Thanks a lot. Got it and upgraded. > > Maybe `build` is badly named, it doesn't *perform* a build, it only > outputs an order for a successful build. > It is just fine the way it is; all one has to do is read the doc or use --help , nothing wrong with the name, it was clear all along it addresses the order. I just thought I might not have used it properly and may not have been installing in the proper order, making it more difficult to resolve the dep chain. > > I usually operate on *all added packages* at once through the whole > upgrade/add process. > Here above ^^ I am not completely sure what you mean.... Are you referring to using just one single pacman -S command with all of the packages needing installation at once? > > That is completely correct. `pacman -Su` won't let you take your system > into an inconsistent state though. > Yes, a point in favor of the cblrepo + pacman approach. > I'm currently experimenting > with a split package for stack though. This should be interesting. > Also, I've found that pacman is > *really* good with handling packages, so having lots of them isn't a big > issue. Agreed, pacman is indeed *really* good and it helps to know one can always reverse whatever was installed/done previously > Also, if you want to clean out your system you can use `pacman > -Rncs ghc` to do it (you'll be left with exe-only packages, like > ?cblrepo, though). > OK, thanks for that info, I guess it all depends on ghc so removing it would remove all haskell packages except binaries.. Hopefully, won't ever come to that. > You have to make up your own mind on the issue of system-wide vs. > sandboxes. :-) > Yes. Will consider all of the info you provided and try to decide on best approach, i.e. one which suits me. ? >> ?% cblrepo add aeson,0.8.1.1 >> ?Adding aeson 0.8.1.1 would break: >> ???cblrepo : aeson ==0.9.* >> >> ?How do I get out of the above, if at all possible? > > This is due to upstream depending on an old version of `aeson`. You can > patch the `.cabal` file (have a look in habs `patches` dir). In > surprisingly many cases you can just bump the upper limit without any > code changes. In a few cases you'll have to do the work of the upstream > devs and modify the code too. If that's the case have a look in their > VCS, I've often found exactly the patch needed already checked in but > not release, or as an attachment to a ticket. > Thanks for this clear explanation. Will follow those steps and try to resolve it. > Just note that `stack runghci` is marked as "experimental". > np, we'll see how it goes. Thanks a lot for the informative feedback, very pertinent and helpful. From magnus at therning.org Sun Oct 18 19:54:42 2015 From: magnus at therning.org (Magnus Therning) Date: Sun, 18 Oct 2015 21:54:42 +0200 Subject: [arch-haskell] ghc-vis In-Reply-To: <2796671445004836@web3m.yandex.ru> References: <1705771444727564@web18m.yandex.ru> <20151013124404.GB4614@sobel.cipherstone.com> <1445931444743952@web26g.yandex.ru> <20151015102606.GA13923@sobel.cipherstone.com> <160841444940069@web14g.yandex.ru> <20151015220447.GA28592@tatooine> <2724711444986438@web6j.yandex.ru> <20151016113825.GD7251@sobel.cipherstone.com> <2796671445004836@web3m.yandex.ru> Message-ID: <20151018195442.GF1231@tatooine> On Fri, Oct 16, 2015 at 08:13:56AM -0600, stef204 wrote: > 16.10.2015, 05:38, "Magnus Therning" : > > I usually operate on *all added packages* at once through the whole > > upgrade/add process. > > > > Here above ^^ I am not completely sure what you mean.... > Are you referring to using just one single pacman -S command with all > of the packages needing installation at once? Nope, I'm talking about `cblrepo add`. > > I'm currently experimenting with a split package for stack though. > > This should be interesting. I'm not so sure ;) It's been brought up before that it'd be nice to have a separate package for the pandoc binary. Splitting does need quite a bit of knowledge of the package though, but my initial fear of maintaining a pkgbuild patch longterm was rather exaggerated I think. > > Also, if you want to clean out your system you can use `pacman > > -Rncs ghc` to do it (you'll be left with exe-only packages, like > > ?cblrepo, though). > > > > OK, thanks for that info, I guess it all depends on ghc so removing it > would remove all haskell packages except binaries.. Exactly! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: