Re: [arch-haskell] ghc-vis

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@therning.org jabber: magnus@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.