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 <d...@galois.com> 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 > > <regis.saint-p...@create-net.org> 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 > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe