[arch-haskell] ghc-vis

[Magnus Therning]

On Fri, Oct 16, 2015 at 03:07:18AM -0600, stef204 wrote:
> 
> 
> 15.10.2015, 16:04, "Magnus Therning" <magnus at therning.org>:
> 
> 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: <http://mail.haskell.org/pipermail/arch-haskell/attachments/20151016/a16161fa/attachment-0001.sig>