Wow, totally ++ this idea! 2009/1/13 Peter Verswyvelen <[email protected]>
> What could be done is letting the community rate the quality of the modules > for each platform? Maybe with user comments? Like amazon.com (so we > hackazon.org ;-) And using lambdas instead of stars for giving the rating > :) > > > On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart <[email protected]> wrote: > >> >> Well, the number one thing is to use Cabal and the cabal-install tool. >> That is the simplest way to avoid headaches. >> >> Regarding libraries in general, the platform project is underway, aiming >> to bless a set of stable, "batteries included" packages, saving >> duplicated work determining which, say, json library to use. >> >> -- Don >> >> >> jamiiecb: >> > 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 >> > nothing since. >> > >> > Jamie >> > >> > On Tue, Jan 13, 2009 at 3:33 PM, Regis Saint-Paul >> > <[email protected]> wrote: >> > > Hi, >> > > >> > > 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 >> > > management: >> > > >> > > - 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. >> > > >> > > -Regis >> > > >> > > 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 >> > > tutorial. >> > > >> > > >> > > >> > > _______________________________________________ >> > > Haskell-Cafe mailing list >> > > [email protected] >> > > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > [email protected] >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
