[Haskell-cafe] real haskell difficulties (at least for me)
jamiiecb at googlemail.com
Tue Jan 13 11:21:40 EST 2009
I agree completely. There is not nearly enough documentation on
packaging in haskell and too many hackage packages are broken or do
not install. I know several people are working on improving this but
they seem do be doing so rather quietly. Could someone briefly outline
what improvements are planned and what stage the current work is at? I
remember seeing some demos at anglohaskell during the summer but
On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul
<regis.saint-paul at create-net.org> wrote:
> I've seen many times the monad topic coming around on the cafe and plentiful
> tutorials on monads have been published. However, as a complete Haskell
> newbie coming from OOP, I felt monads were not particularly difficult to
> grasp, and very exciting to work with.
> During my experiments with Haskell so far, the main problems I kept bumping
> into were not related to the language but to its libraries: their
> compilation and installation. Unfortunately, this topic has not received
> nearly as much attention. I was unable to find a comprehensive tutorial on
> how to deal with the variety of problems I get when trying to install
> Hackage packages. This turned out to be (and still is) THE main source of
> wasted time and headaches. And worse, unlike type problems, these are not
> interesting ones to solve.
> Thus, as a beginner, the package management is what is really getting in the
> way of switching to Haskell--not the language. Even books like Real World
> Haskell (otherwise excellent) ignore entirely the topic. Cabal and
> Cabal-install are clearly wonderful applications that make installing most
> packages very straightforward. Unfortunately, whenever this "standard"
> method for package installation fails (or when it is not available as with,
> e.g., gtk2hs), I find myself in complete disarray.
> Below are some of the questions and issues I faced regarding package
> - For a number of packages, cabal-install gets stuck and has to be killed. I
> assume this is due to some difficulties in solving the dependencies and it
> is fine, not all can be automated and cabal-install is not responsible for
> poor packages. But the question then becomes what to do from there? Is their
> some method to solve dependencies? How should we proceed to "debug" a
> package installation? How do gurus deal with that? (maybe some less known
> command line arguments? Or ways to figure out the problem and work out its
> solution (cabal-install is silent in such case)? In particular, how to know
> why did cabal get stuck in the first place?
> - Some packages on Hackage are reported as not building successfully with
> GHC6.10 (e.g., encoding) while others do not build with 6.8 (e.g., salvia)
> and the later might depend on the former...What is one supposed to do in
> such case? For example, is it an appropriate way to proceed to compile a
> package with one version of GHC and then use the compiled package with
> another version of GHC? Is it safe? What could possibly go wrong? If it is
> the right way to go, how should we setup the two GHC versions? For instance,
> should we have a shared package configuration file and choose through the
> path which GHC is used or is there nicer way to set this up?
> - Taking for example the "encoding" package on Hackage. Last time I tried,
> the log was saying it fails to build on GHC 6.10, however, looking inside
> this Hackage log, I could see a successful compilation using "preferred
> versions". So it looks as if the thing can be compiled somehow. What should
> one do with this information? If cabal manages to compile it using this
> method on Hackage, then isn't cabal install just doing it on my disk? Is it
> possible through some command line? Is it possible manually (without
> cabal-install) and, if so, how? (I tried to copy-past the build instruction
> as it appeared on the log...that somehow compiled, but then, I failed to
> figure out how to install...)
> - I'm primarily a windows user and lots of my initial struggles probably
> came from that. After many difficulties, I figured out that installing MinGW
> and MSys was *THE* way to get a bit more of the things working. First, a lot
> of time would be saved by just saying clearly on the GHC download page that
> MinGW and MSys are mandatory installation (or even package that with GHC for
> the windows distribution if license allows, who cares the extra few Mb).
> Even if that is not technically exact, i.e., even if ghci and many trivial
> command line programs can work without, MSys and MinGW turn out to be quiet
> necessary whenever trying to install anything producing side effect. Making
> it plain that these two are necessary would real come has a great time
> savers for newbie like me on windows (personal opinion of course). Or, if
> another path exists to go without these two, I'd be very glad to learn.
> Besides, even these tools basic installation is not enough, you need
> automake and various things of the like. That makes me wonder if the most
> precious skill for programming with Haskell would not be a strong C/C++
> programming background.
> - In face of the difficulties with windows, I switched to Linux. While some
> things worked better, there were still lots of difficulties with package
> compilation. For instance, it is very difficult to figure out which Linux
> packages of a given distribution are needed for compiling this or that
> package. Again, gtk2hs is epitome here: which C development packages are
> needed to compile it is obscure at best (cairo, codeview, etc...). I ended
> up querying the Debian package management with any keyword found after
> running gtk2hs and randomly installing all the dev packages...And when
> gtk2hs finally compiled, it failed to install anyway. As of today, I've
> never been able to compile even the dumbest demo using gtk2hs whether on
> linux or on windows and whether using ghc 6.8.3 or 6.10.1. On windows, the
> automated setup install worked but did not allow me to compile with codeview
> and I still do not know how to add codeview to the install packages. Trust
> that I tried hard and read the docs thoroughly. Gtk2hs is just on of many
> examples; I had problems under Linux also with, e.g., Happs, yi, database
> things, etc. and figured out that the situation was roughly identical to
> windows with MSys and MinGW. So Linux appears not to be the right solution
> here. Maybe it's just that Linux users are more experienced with the GNU
> C/C++ libraries...but it won't help a windows user to switch to Linux since
> this knowledge can't be built out of thin air.
> - Would there be some binary version of cabal targeting various OSs? I
> believe the Haskell platform project is about that. But without waiting for
> a fair and objective selection of the packages (it seems to be the current
> status of the project), I'd be happy working with some authoritative bundle
> produced by a Haskell guru and would trust his subjective choices (who am I
> to question these choices anyway). Or even an image (e.g., virtual box or
> Xen) of a fully setup development environment since there are so many
> dependencies involved in, e.g., simply compiling GHC...
> Now, one might argue that these are not Haskell problems, that they are
> normal when dealing with non-mature packages. So let me explain why I've
> been trying hard to install these packages:
> As a beginner with no experience with emacs, I tried to find some IDE-like
> environment which would, at least, save me from manually reloading files in
> ghci or help me browse the source files. Following the Haskellwiki advice,
> that led to trying out Yi, Leksah, eclipsefp, or a Visual Studio extension.
> To this date, NOT ANY SINGLE ONE of these worked, be it on Linux or Windows.
> I had to resort to learning emacs which seems the only sensible choice
> available today.
> I am particularly unskilled, no question here. But, would a charitable soul
> take the pain of writing a comprehensive package management tutorial instead
> of a monad one, (s)he would have my deepest gratitude :)
> Apologies for the long mail.
> P.S. People on #haskell are wonderful. They helped me solve many issues.
> Unfortunately, solving specific instances of problem did not contribute much
> to a deeper understanding of the internal working. I find myself randomly
> trying things without knowing which would work or why; Hence this plea for a
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe