15.10.2015, 16:04, "Magnus Therning" <mag...@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.
(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.
_______________________________________________
arch-haskell mailing list
arch-haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell
